A Fast Answer for the Wrong Agent: Reachability Cache Identity and Honest Nanosecond Benchmarking

The final campaign in the Kernel Hardening Triptych followed Part I (the causal resolver) and Part II (portable topology). Throughout this series, “kernel” refers to the deterministic Rust evaluation core of the KAIROS safety substrate rather than an operating-system kernel. Once causal resolution is bounded by a domain proof and procedural topology generation is bit-identical across target architectures, the remaining source of silent divergence is state reuse.

In practice, repairing a reachability cache and measuring its performance cost cannot be separated. Eliminating unsafe cache shortcuts makes certain workloads slower on paper simply because they stop returning wrong answers quickly, while adding nanoseconds of identity verification to every legitimate cache hit. Only a controlled benchmarking protocol can separate an apparent regression caused by doing required work from the true overhead of the verification check.

What This Article Leaves Out

One part of this work is deliberately missing. How the engine establishes that a stored frame belongs to the live request is part of an invention we are preparing to patent. Until the application is filed, we describe what the cache now guarantees, how we test that guarantee, and what it costs, but not the mechanism that provides it. What we can say is what the check must establish: that the stored frame was computed for the same origin, grid, seed, special nodes, and committed locks as the live request. How it establishes that is the part we hold back. In Europe, any public disclosure before filing counts against novelty, so publishing first would give the invention away.

Eight Ways a Cached Frame Could Lie

Computing a forward reachability field over a 100-tick horizon takes hundreds of microseconds, so the evaluation engine reuses computed frames wherever possible, holding a primary frame for the agent under evaluation alongside a small set of secondary frames for other actors. The governing invariant is straightforward: a reused reachability frame must equal a fresh solve for the requested origin, grid shape, seed, special nodes, and committed lock set.

Probing every execution path through the reachability facade and cache uncovered eight distinct mechanisms capable of violating that invariant:

#	What could go wrong	Fix
1	Partial match. A legacy branch returned the primary frame whenever the time step and column width matched and the cached horizon was at least as long, ignoring the branch origin, seed, special nodes, and locks.	Branch deleted.
2–4	Unverified reuse. Three shortcuts across primary lookup, secondary lookup, and incremental frame advancement allowed a frame to be reused without verifying that it had been computed for the current special nodes and committed locks.	All three removed. Every reuse is now verified against the frame’s complete identity.
5	Mutations that did not invalidate. Public mutators (set_state, set_primary_agent_id, reset_agents, and a primary-replacing add_agent) could move the primary origin or alter the agent roster while leaving the active cached frame in place. Two broader mutable accessors, state_mut and special_nodes_mut, permitted the same drift.	Explicit invalidation on every origin- or roster-changing mutation. state_mut is now private and special_nodes_mut has been removed. Visual-only updates (set_marker) still cost nothing.
6	Previews answering for the wrong agent. A warning preview for a non-primary actor, or one evaluated after a lock commit, could be served from the primary agent’s frame or a pre-lock frame. Although the preview queried the right actor, the shortcuts in rows 1–4 answered from the wrong frame.	Fixed by the repairs in rows 1–4. The preview now performs the secondary solve it always requested.
7	Identity blind to tie order. When two special nodes shared an ID, the solver’s output depended on their input order, whereas the cache identity check did not, allowing two distinct solver inputs to alias in the cache.	Identity now distinguishes every input the solver distinguishes.
8	Bookkeeping drift. Cache invalidation could leave stale column data behind, and shrinking the secondary cache capacity could leave the active output pointer paired with an already-evicted frame.	Explicit frame-initialization tracking. Active-frame and output pointers are synchronized on every eviction, invalidation, and capacity change.

The remaining audit probes passed without issue: incremental frame advances matched fresh solves bit for bit, and edge cases such as nodes outside the horizon window or masses containing signed zeros, NaN, subnormals, or values equal in f32 produced only safe cache misses rather than false hits.

Proving the Repair Cannot Regress

To lock the invariant against future regressions, we introduced a testing-only oracle entry point, ReachabilitySystem::reference_full_recompute, which constructs a fresh reachability system, bypasses the cache dispatcher entirely, and populates a reference frame straight through the stateless solver kernel. Every positive, negative, and mutation test compares the cached output against that reference frame bit for bit (f64::to_bits) across map entries, scores, and basins.

We then validated the test suite itself by reintroducing the defects. In the first qualification round, seven fault-injected build variants restored the cache bypasses one at a time, while an eighth variant stripped out a release-build guard. In the second round, eight mutator variants each removed a required cache invalidation or injected an unnecessary one. Every fault-injected variant caused its corresponding regression test to fail with the expected diagnostic.

Why Fixing a Stale Cache Breaks Naive Benchmarks

Following the repair, an eight-agent warning preview for a non-primary actor (preview_warning_nonprimary_8agent) moved from roughly 310 µs to 1.3 ms, appearing at first glance to be a 4.1× performance regression.

Inspecting what the baseline actually executed explained the jump: the legacy build never ran a non-primary solve during that benchmark. Instead, it cloned the reachability system and handed back the primary agent’s cached frame, delivering a fast answer for the wrong agent. Under the repaired cache, the preview now performs the one secondary full fill it always asked for, and costs 0.975–0.997 ms more per run. (While the stateless kernel solve in the ledger below takes around 642 µs, that benchmark solves an unscored field, whereas the warning preview requires a scored fill.) The 4.1× is not a slowdown at the same task: the legacy number measures a shortcut that returned another agent’s frame, so there is no like-for-like baseline. We assessed the 1.3 ms as an absolute cost instead. We have not yet measured what it adds at application level, where previews run once per actor.

Evaluating legitimate exact cache hits posed the opposite measurement challenge. Because both the baseline and repaired binaries return the exact same cached frame on a true hit, any additional latency is pure identity-verification overhead. In our initial full non-turbo scoring run, that overhead measured +115–126 ns on a warm primary hit and +149–153 ns on a warm secondary hit. We suspected the cost of building an owned identity value on every lookup, and rewrote the exact-hit check to avoid that allocation when the hit verifies. Quantifying the remaining overhead after that rewrite required resolving latency deltas of 53 to 349 ns without host-level noise swamping the signal.

Measuring Nanoseconds Honestly

Before executing the final qualification campaign (D6), we had to eliminate three sources of host and build contamination:

1. Build provenance and disk headroom. Identical git trees across two worktrees do not guarantee that Cargo compiled a binary exclusively from the intended checkout: shared target directories reuse artifacts based on relocation-stable paths and file timestamps, and our audit caught one dependency that had been compiled in a different worktree. We isolated build provenance by assigning each lineage its own dedicated target directories across debug, release-native, Python, and WebAssembly builds. At the same time, available disk space on the workstation’s root partition dropped within roughly 130 MiB of the campaign’s abort floor. We migrated the benchmark harness to a dedicated NVMe volume with a free-space check prior to every write, mirroring every evidence packet across two storage locations backed by SHA-256 manifests.

2. Pre-registered noise bars and balanced interleaving. Prior to timing the candidate binary, we ran an A/A baseline campaign benchmarking the unmodified baseline binary against itself across 26 workloads and six runs (156 medians). Each workload’s noise bar was fixed as the maximum absolute log-ratio across three paired baseline comparisons: $\text{bar}_{\ln} = \max_{p \in \{1,2,3\}} \left|\ln\!\left(\frac{\text{median}_{A2,p}}{\text{median}_{A1,p}}\right)\right|$ The bar is a screen, not a confidence bound. Workloads whose baseline bars were too noisy to screen against (the shortest operations among them) were reviewed individually instead. Six warm-use workloads, added because the original runs could not resolve the shortest operations, took bars of the same construction from a separate baseline pilot. The screen is one-sided: it fires only when a candidate’s slowdown exceeds the workload’s pre-registered bar, so a workload that does not trip the screen has not been proven to be at parity or faster. Each benchmark suite then executed twelve times across three balanced blocks (B,C,C,B / C,B,B,C / B,C,C,B, where B is the baseline binary and C is the candidate), taking the median of the three block effects as the headline metric to cancel linear run-position drift. Running seven Criterion benchmark binaries across two workload sets at twelve runs apiece yielded 84 scored commands and 384 workload-run cells.

3. Thermal throttling. We had already pinned RAYON_NUM_THREADS=1, so that Criterion’s post-measurement analysis would not load every core between workloads. The pin could not help with what came first: during cargo start-up and the first workload’s warm-up, roughly one busy core took the package from 45 °C to about 100 °C in 1.5 seconds. That tripped the CPU’s package-throttle counter on the sixth command of our first 84-command campaign with turbo enabled. We halted the campaign immediately, sealing the five accepted rows and the failed sixth row as unscored evidence and leaving the remaining 78 commands unexecuted. Repeating the campaign with Intel Turbo Boost disabled (/sys/devices/system/cpu/intel_pstate/no_turbo = 1) ran without a single throttle event (package peak 59 °C) and produced the overheads quoted above, which prompted the exact-hit rewrite. The final qualification run (D6) executed inside a reserved six-hour window under continuous thermal monitoring, completed in under three hours with zero throttle events, and restored turbo boost upon completion.

These controls were built for this campaign. The lessons from it are now part of how we plan future measurement work.

The Final Ledger in Tick-Budget Context

On that non-turbo qualification host, a standard single-agent evaluation tick (single_tick_standard) takes 944–967 µs across both binaries, and an eight-agent tick (8agent_single_tick) takes 7.43–7.66 ms across both binaries. In the ledger below, share-of-tick percentages are normalized against a 960 µs single-agent tick; the B and C columns report the range of run medians, while the paired delta column reports the per-run paired differences:

Workload	Baseline (B)	Repaired (C)	Paired delta	C/B	Share of 960 µs tick
Warm primary exact hit (repeated)	6.29–6.33 ns	60.57–63.51 ns	+54.2 to +57.2 ns	9.81×	0.006%
Warm secondary exact hit (alternating)	40.99–49.50 ns	101.25–110.89 ns	+53.0 to +69.9 ns	2.48×	0.006–0.007%
Cloned-fixture primary exact hit	32.00–46.00 ns	305.37–359.55 ns	+265.5 to +318.9 ns	8.21×	0.028–0.033%
Cloned-fixture secondary exact hit	397.27–451.31 ns	716.81–777.62 ns	+280.0 to +349.3 ns	1.72×	0.029–0.036%
Non-primary 8-agent warning preview	310.36–315.36 µs (wrong agent)	1.286–1.312 ms (correct solve)	+975 to +997 µs	4.14×	corrected output
Warm single-agent decision	186.23–191.67 ns	179.33–179.90 ns	−6.4 to −11.8 ns	0.960×	below screen
Stateless 100-horizon solve (reachability_dp_100h_25x17)	641.96–645.00 µs	633.92–648.91 µs	−9.9 to +6.5 µs	0.995×	below screen
Standard single-agent tick	955.62–967.34 µs	944.44–958.93 µs	−21.2 to −3.2 µs	0.988×	below screen
Standard eight-agent tick	7.443–7.516 ms	7.432–7.657 ms	−0.046 to +0.194 ms	0.999×	below screen

“Below screen” means the slowdown stayed within the workload’s noise bar; it does not prove parity. On the warm primary exact hit, the legacy hit took a shortcut that skipped most of the check; the repaired hit verifies the full request, so the ratio is large while the absolute cost stays near 54 ns.

Of the 32 workloads, 24 were screened against their noise bar. Seven, whose baseline bars were too noisy to screen against, were reviewed individually. The last is the corrected preview. Two screened rows tripped their bar: the warm exact hits. Two reviewed rows showed resolved overhead: the cloned-fixture exact hits. The other 22 screened rows stayed below their bars, which does not prove parity. The other five reviewed rows were inconclusive. Fourteen workloads also changed sign depending on which binary ran first; we recorded them as unresolved rather than as either a regression or parity. In a written owner decision on 15 October 2026 we accepted the four exact-hit costs, the corrected preview’s cost, and the documented uncertainty, with no claim of parity.

Placed in the context of a 960 µs evaluation tick, a warm exact cache hit now spends roughly 54 ns (0.006% of the tick budget) proving that the cached reachability frame belongs to the live request, while a cloned-fixture exact hit spends 266–349 ns (0.028–0.036%). Meanwhile, a non-primary warning preview spends roughly 985 µs more per run computing the queried actor’s actual reachability field instead of returning a fast answer for the wrong agent.

Closing the Triptych

Across Part I, Part II, and Part III, we added no product features. Instead, a stateful replay ceremony was replaced by a five-step domain proof, four divergent runtime sine families were converged onto a single bit-exact implementation across a qualified corpus, and every reachability cache reuse was bound to the complete identity of the request it answers. Every metric reported in this series traces directly to a committed verification artifact, a benchmark ledger row, or a signed engineering decision.