Serialized Event Kernel — NCFCA Determinism

A real, single-writer event-sourced kernel implementing the four-channel architecture, built to make one specific property checkable: same logical input, same result, every time. Distinct from STATE_ESTIMATION_KERNEL_v8.py — that one drives the estimator/backtest pipeline; this one governs transition determinism for the reality/cognitive/observer/integrating channels.

What it actually does

The kernel processes CapturedInputEvent objects — the only way data enters it, whether external input or an AI proposal — through a formal transition table with named, deterministic guard functions. State mutation happens in exactly one place, in strict sequence order. AI output is proposal-only: a DeterministicValidator re-checks every proposal at processing time against the channel's allowed actions, required payload fields, and pre-approved strategy list — it does not trust a pre-packaged decision sitting in the event payload, which closes off the obvious forgery path. Every function that could introduce non-determinism — datetime.now(), random, uuid4(), Python's built-in hash() — is absent from the kernel, confirmed by an actual AST scan of the source, not a comment promising it.

Verified by independent re-execution, not taken on faith

Every result on this page was produced by running the code myself, separately from however it was first generated. Fresh output, this session:

Final state:  {'reality': 'env_rest', 'cognitive': 'cog_updating', 'observer': 'obs_contested', 'integrating': 'int_idle'}
State hash:   483a9195872070fd
Log hash:     1c6e1504ab75923d

Replay Gate (100 trials):
  pure_replay      : PASS  (unique_state_hashes: 1)
  delivery_order   : PASS  (unique_state_hashes: 1, unique_log_hashes: 1)
  live_vs_replay   : PASS  (live_state_hash == replay_state_hash)

Unit test suite: 112/112 passed

The Replay Gate runs three checks worth being precise about, not just citing as "1000 trials passed": pure replay confirms that replaying the same committed log repeatedly reconstructs the same state — a real regression check, though close to guaranteed once a function is proven side-effect-free, not a dramatic empirical discovery. Delivery-order invariance is the more meaningful one — it submits the same events in randomly shuffled arrival order and confirms the kernel's seq-based canonicalization actually produces an identical committed log regardless, which is a genuine test of a specific, breakable piece of logic. Live-vs-replay is a single structural check, not a repeated trial, confirming the live kernel and a full replay of its own log agree.

What's deliberately not on this page

An earlier report paired this kernel against two other "profiles" — an unconstrained baseline and a partially-constrained middle profile — with headline numbers like 99.9% and 9.3% divergence rates. Checked against the actual code: only the kernel profile above ran real logic. The other two ran a separate, hand-rolled toy simulation with hardcoded probabilities — a 30% chance of a "stale read," a 20% chance of a "conflict," a 40% chance the "AI" diverges — authored constants, not measurements. The reported divergence rates are direct, calculable consequences of those constants (the ~90% match rate for the middle profile is just (0.95)^k for a few independent 5%-probability draws), not findings about any real concurrent system. Presenting all three side by side, at matching statistical precision, implied a rigor the comparison didn't have for two of its three rows. Left off this page for that reason — real work belongs here, a simulation dressed as measurement doesn't.

What replaces it is in progress: essential variables anchored to actual physics — conservation laws and closed-form trajectories that hold regardless of what any software architecture does around them — instead of invented failure probabilities. That's a harder, slower thing to build, and it isn't done yet.

Extension: directional consistency (added after initial verification)

The kernel now tracks a kinematic_trace in its shared state — additive, only populated when perturbation events carry real kinematic fields, so existing usage is unaffected. A new directional_consistency_report() method checks whether finite-difference velocity between consecutive samples, computed in the kernel's own canonical processing order, agrees in sign with each sample's own reported velocity.

Tested against a real exact-closed-form trajectory (simple harmonic motion), submitted to two separate kernel instances — one in true time order, one with the identical events delivered in shuffled order. Both produced identical results: 18/20 sign agreements (90%), not merely similar numbers. That's the real claim being tested — that seq-canonicalization recovers true order regardless of delivery sequence — verified on real kinematic data, not asserted.

true order:        18/20 sign agreements (90.00%)
shuffled delivery: 18/20 sign agreements (90.00%) — identical to true order

Building this surfaced a real bug in the test itself, not the kernel: the reality channel's state machine requires a full env_rest→perturbed→sane→rest cycle before it accepts another perturbation event, so an early version of this test silently checked only 6 of 20 intended pairs. Left visible here rather than quietly fixed upstream, consistent with how errors are handled everywhere else on this site.

Get the real files