# Zincrom Evidence Ledger

**Status date:** 2026-07-25
**Rule:** Historical files are preserved. This ledger controls what may be
claimed until a newer reproducible result supersedes it.

| Claim | Status | Evidence and limitation |
|---|---|---|
| OLMoE router/top-K is accessible | Supported | The real NIF loads OLMoE tensors and executes the f32 gate/top-K graph. |
| BEAM dispatch to eight no-op workers is inexpensive | Supported, narrow | Recorded p99 is 37 us. Workers perform no I/O or math. |
| 8B OEF collapses to 0.270 | Superseded | The denominator compares four one-thread workers with four copies of a four-thread baseline on a four-core host. Re-run with matched isolated controls. |
| One thread saturates the 8B memory bandwidth | Unsupported | Four-thread throughput is materially higher than one-thread throughput. Hardware counters were not collected. |
| Two-call isolated MoE expert execution works | Supported through causal batch 16; batch-32 strict gate rejected | All 16 layers reproduced pinned llama.cpp expert IDs, weights, and outputs exactly for three single tokens and causal batches 2/4/8/16. Batch 32 retained exact expert IDs and stayed within the weight tolerance, but layer 2 output max-absolute delta was `1.1444e-5`, above the preregistered `1.0e-5` limit. Autoregressive generated-token equivalence remains open. |
| A 26.6 ms expert intercept window exists | Unsupported | 26.6 ms is full-model dummy-token decode time, not per-layer selected-expert compute or overlapped slack. |
| Pure NIF route latency is measured | Supported, narrow | The latest provenance-complete isolated run measured route p50 68.24 us and p99 284.439 us across 1,000 iterations. |
| BEAM coordination fits within selected-expert compute | Supported, narrow | In the latest 1,000-iteration isolated OLMoE run, coordination p99 was 74 us versus compute p99 2,205.553 us (3.36%). The workers performed confirmation only, without weight I/O or expert math. |
| Real selected-expert page readiness fits matched compute | Supported, narrow | Across batches 1/2/4/8 and layers 0/7/15, ExpertSupervisor fan-out touched every page of the selected experts' real gate/up/down mmap tensors. Resident p99 was at most 0.453 ms; forced-nonresident p99 was at most 6.129 ms, and all 12 conditions were below matched compute p99. `MADV_DONTNEED` does not guarantee physical-disk reads or remote-storage behavior. |
| Same-host oracle lookahead hides page readiness | Rejected on current host | Although all selected future pages became resident and outputs remained exact, concurrent prefetch p99 exceeded the sequential control in 7 of 12 batch/layer-pair conditions. Unconditional page-touch prefetch competes with four-thread compute on this four-core host. |
| Kernel `MADV_WILLNEED` lookahead avoids the overlap regression | Rejected on current host | Selected future pages became fully resident and outputs remained exact, but kernel-readahead overlap p99 exceeded the sequential control in 11 of 12 conditions. Advisory readahead did not isolate the four-thread compute path from contention/scheduling effects. |
| Reserving one of four cores' worth of compute capacity makes local lookahead safe | Rejected without affinity | With ggml reduced from four to three threads, residency and exact-output gates passed, but overlap p99 still regressed in 7 of 12 conditions. An unused thread slot is not CPU affinity or process isolation. |
| Strict CPU/process affinity makes lookahead universally safe | Rejected; batch-size signal | BEAM/ggml was verified on cores 0-2 and a persistent GGUF mmap helper on core 3. Two identical runs passed 7/12 and 11/12 p99 conditions, so the universal gate failed and small-batch behavior is unstable. All three batch-8 conditions improved in both runs. |
| Strict-affinity lookahead is repeatably safe for batch 8 | Rejected | Three independent 100-trial repetitions were required to pass all three layer pairs. Two repetitions passed; one regressed at layer 14->15 (0.949x). The aggregate all-repetitions gate failed. |
| Expert RSS scales exactly with the 8/64 logical active fraction | Rejected, but sparse | Logical selected-expert bytes were exactly 12.5% of the all-expert control, but PTE-present bytes and RSS delta were 27.7% because file-backed fault-around mapped neighboring pages. Active RSS was 1.089 GB versus 3.921 GB for all experts. |
| `MADV_RANDOM` restores near-logical active expert RSS scaling | Supported, narrow | With identical routing and gates, active PTE presence was 12.88% and active/all RSS delta was 12.98% (506 MB vs 3.899 GB), close to the theoretical 12.5%. Scope is expert gate/up/down weights for one routed hidden state per layer on one model/host. |
| Shared-model concurrent requests scale below independent model copies | Supported, narrow | Fresh 1/2/4-context, 8-token decodes had peak RSS deltas of 2.439/2.881/3.531 GB. Four requests used 1.45x the one-request delta, or 36.2% of four isolated copies. |
| `MADV_RANDOM` alone bounds concurrent expert residency near active top-K | Rejected | Expert PTE presence accumulated across token/request route unions: 61.0% for one 8-token request, 71.3% for two, and 86.0% for four. Explicit lifecycle eviction is required. |
| Token-boundary expert eviction sufficiently bounds concurrent residency | Rejected, improved | Eviction after every decoded token cut peak RSS by 27%-53%, but expert PTE presence was still 28.0%/46.2%/61.4% for 1/2/4 requests, above the 20%/35%/55% limits. |
| Layer-completion eviction bounds concurrent expert residency | Supported, narrow | A synchronized decoder callback evicted a layer only after every concurrent request finished it. Fresh 1/2/4-request runs passed with expert PTE fractions of 3.53%/4.67%/6.11% and peak RSS deltas of 223/272/407 MB. |
| Layer-completion eviction remains bounded under staggered request churn | Supported, narrow | Eight 16-token requests arriving four rounds apart peaked at four active contexts. Layer eviction held peak RSS delta to 364 MB and expert PTE presence to 2.87%, versus 3.957 GB and 98.19% for the matched accumulating control; elapsed time was 1.73x control. |
| Layer-completion eviction has bounded latency overhead without page accounting | Supported, narrow | In the same staggered schedule with repeated `pagemap` scans removed, layer eviction retained 90.8% of control throughput. Its p50/p95/p99 latency ratios were 1.70x/1.20x/1.22x and total elapsed time was 1.10x control. |
| Staggered layer-eviction latency overhead is repeatable | Supported, narrow | Three independent matched pairs all passed. p99 overhead ratios were 1.224x/1.215x/1.215x and elapsed ratios were 1.102x/1.118x/1.102x; their cross-run spreads were 1.008x and 1.015x. |
| Layer-eviction overhead remains bounded at 64 tokens/request | Supported, narrow | With eight requests arriving every 16 rounds and four active at peak, 512 samples gave p50/p95/p99 ratios of 1.67x/1.19x/1.23x, 86.4% throughput retention, and a 344 MB peak RSS delta versus 4.040 GB control. |
| Layer-eviction overhead remains bounded at 256 tokens/request | Supported, narrow | Explicitly sized 256-token contexts produced 2,048 samples. p50/p95/p99 ratios were 1.61x/1.17x/1.17x, throughput retention was 86.6%, and peak RSS delta was 356 MB versus 4.048 GB control. |
| Dynamic barrier membership handles uneven lifetimes and token-boundary cancellation | Supported, narrow | Eight 64-256-token requests arriving every 48 rounds completed all 1,200 samples without deadlock. Layer eviction had 1.18x p99 overhead, retained 85.4% throughput, and peaked at 340 MB RSS delta versus 4.048 GB control. |
| Dynamic membership is stable across seeded start/stop schedules | Supported, narrow | Seeds 101/202/303 all passed with four active requests maximum. p99 overhead was 1.176x-1.184x, throughput retention 84.6%-85.3%, and p99 cross-schedule spread 1.007x. |
| Eight active requests should be admitted on the four-core host | Rejected by latency gate | Peak-8 remained memory-safe and raised layer throughput 1.21x versus peak-4, but layer p99 rose 1.73x, above the 1.5x admission limit. The tested host should cap active requests at four. |
| A four-active FIFO queue is preferable to unrestricted eight | Supported, narrow | For eight simultaneous 128-token requests, FIFO cap-4 reduced service p99 35.7% and peak RSS 34.8%, retained 81.5% throughput, and increased end-to-end request p99 22.7%; all predeclared tradeoff bounds passed. |
| FIFO cap-4 remains preferable across seeded arrival bursts | Supported, narrow | Seeds 11/22/33 all passed. The queue reduced service p99 35.7%-40.4% and RSS 30.4%-33.7%, retained 86.0%-86.6% throughput, and limited request-p99 inflation from arrival to 18.4%-19.5%. |
| FIFO cap-4 is fair under a deep mixed-length queue | Rejected | A deterministic 16-request run completed all 2,104 tokens and passed queue-depth, wait-tail, request-tail, throughput, and RSS gates, but slowdown Jain fairness was 0.739, below the predeclared 0.80 minimum. |
| Aging size-aware cap-4 corrects deep-queue unfairness | Supported, narrow | On the identical 16-request schedule, priority `token budget - rounds waited` raised slowdown Jain fairness from 0.739 to 0.901, reduced wait p99 from 71.584 to 65.016 seconds, and increased throughput from 18.64 to 19.26 token/s; all original gates passed. |
| Aging size-aware cap-4 is stable across mixed-length schedules | Supported, narrow | Two seeded schedules and a long-job stress schedule all passed. Fairness was 0.857-0.899, throughput 18.47-18.81 token/s, worst wait p99 68.388 seconds, and cross-run fairness/throughput spreads 1.049x/1.018x. |
| Redpanda can supply selected-expert weight shards inside the per-layer compute window | Rejected on current host | Real 31.1 MiB selected-expert shards had native p99 of 86.96–119.47 ms and persistent-brod p99 of 95.14–138.68 ms. Fetch p99 exceeded matched compute p99 in all nine batch-1/4/8 layer cases, and no case passed the every-trial overlap gate. A 64 MiB control measured 260.95–269.44 ms p99, replacing the unsupported historical ~50 ms extrapolation. |
| Causal FFT convolution trains at toy scale | Supported, narrow | Three Shakespeare-character seeds average ~5.9% lower best validation loss than the matched attention baseline. |
| FFT magnitude supports spectral semantic routing | Inconclusive | The initial test crossed its kill threshold, while applying FFT to arbitrary embedding-coordinate order and discarding phase. |

## OCI source snapshot

- Host class: Oracle A1, four Neoverse-N1 cores, 24 GiB RAM.
- llama.cpp commit observed: `6e9007ae6` (build 9641 lineage).
- Models observed: Llama 3.2 3B Q4_K_M, Llama 3.1 8B Q4_K_M,
  OLMoE 1B-active/7B-total Q4_K_M.
- The local `zincrom_nif/` directory was synchronized from OCI on 2026-07-22.

## Promotion rule

A claim moves to **Supported** only when its result directory contains:

1. `manifest.json` with code/model/hardware identity and exact commands;
2. raw per-trial samples;
3. a generated summary with uncertainty;
4. matched controls and a predeclared pass/kill condition.

## Corrected concurrency baselines

The canonical runs used five independent trials per condition, identical
512-token prompts and 256-token generation, disjoint CPU pinning, and matched
isolated controls. At four one-thread workers they measured:

| Model | Aggregate t/s | Capacity efficiency (95% CI) | Contention efficiency (95% CI) |
|---|---:|---:|---:|
| Llama 3.2 3B | 15.479 | 1.099 (1.096–1.104) | 0.967 (0.965–0.969) |
| Llama 3.1 8B | 6.944 | 1.074 (1.069–1.079) | 0.963 (0.960–0.965) |
| OLMoE 1B-active/7B-total | 40.763 | 1.155 (1.141–1.172) | 0.964 (0.961–0.966) |

These results supersede the old normalization and provide no evidence of an 8B
contention collapse. Capacity efficiency above one reflects the relative
efficiency of the pinned thread allocation; it is not a BEAM result. These runs
do not identify memory bandwidth as the limiting resource because hardware
counters were not collected. The table uses the provenance-complete 3B rerun
ending `T231513Z`; the smoke run and interrupted directory ending `T014021Z`
remain historical evidence and are not used in the table.

## Isolated MoE correctness and overhead

The real-isolated implementation passed its internal-equivalence gate with
zero fused/split output delta. All four sensitivity checks exceeded their
predeclared `1e-6` minimum. In the subsequent 1,000-iteration matched overhead
benchmark, selected-expert compute p99 was 2,205.553 us, coordination p99 was
74 us, and their ratio was 3.36%, below the 10% gate. Maximum output delta
across fused, split, and BEAM paths was zero.

## External llama.cpp equivalence

The pinned decoder reference uses llama.cpp's public `cb_eval` scheduler hook
to capture its own `ffn_norm`, top-K IDs, scaled gate weights, and
`ffn_moe_out`. Zincrom then receives that exact normalized hidden state. Across
three token IDs (`50279`, `42`, and `1000`) and layers 0, 7, and 15, expert IDs
matched exactly and both weight and 2,048-element output maximum absolute
deltas were zero.

This establishes numerical equivalence for the nine selected single-token
cases on llama.cpp commit `6e9007ae6`.

## Multi-token llama.cpp equivalence

The same decoder-callback comparison passed causal batches of 2, 4, and 8
tokens at layers 0, 7, and 15. All expert IDs, gate weights, and complete MoE
outputs matched exactly in all nine cases.

The first multi-token run is retained as a failed artifact. It exposed that
Zincrom copied a strided `ggml_argsort_top_k` view with one flat `memcpy`, so
only token zero received valid expert IDs. Copying each token row using
`nb[1]` fixed the routing and output mismatch. Every intermediate layer,
longer batches, and full end-to-end decoding remain outside this gate's scope.

## Real selected-expert page fan-out

The ExpertSupervisor now dispatches unique routed experts to independent
workers that touch every page in each expert's real gate, up, and down mmap
tensor spans. The provenance-complete run ending `T013444Z` covered batches of
1, 2, 4, and 8 tokens at layers 0, 7, and 15, with 30 resident and three
forced-nonresident trials per condition.

All conditions passed the predeclared readiness-p99 <= matched-compute-p99
gate. The largest resident p99 was 0.453 ms (34 unique experts); the largest
forced-nonresident p99 was 6.129 ms versus 11.415 ms compute p99. This validates
local mmap page readiness and concurrent BEAM fan-out on this host. It does not
establish physical storage latency: Linux may retain file-backed pages in the
system page cache after `MADV_DONTNEED`. It also does not yet demonstrate
latency overlap because the harness waits for readiness before same-layer
compute.

## Oracle lookahead overlap

The follow-up run ending `T014000Z` used oracle future-layer routes to isolate
overlap mechanics from prediction accuracy. Every paired trial evicted and
verified the selected future pages with `mincore`, then compared sequential
prefetch-plus-current-compute against asynchronous prefetch concurrent with
current compute. Trial order alternated to reduce ordering bias.

The residency and numerical gates passed: all selected pages were resident
after prefetch and the current-layer output maximum absolute delta was zero.
The latency gate failed in 7 of 12 conditions. Overlap p99 ranged from a 1.23x
speedup to a 0.75x slowdown relative to sequential execution. This rejects
unconditional same-host page-touch lookahead on the four-core OCI shape. It
does not reject resource-isolated prefetch, kernel readahead, or remote I/O
overlap, and it says nothing about future-route prediction accuracy.

## Kernel-readahead overlap

The successor run ending `T014557Z` replaced per-page user-space reads with
`MADV_WILLNEED`, polling `mincore` for actual readiness. It retained the same
oracle routes, explicit eviction, alternating paired controls, and numerical
checks. Full selected-page residency and exact output equivalence passed.

The latency gate failed in 11 of 12 conditions. Only batch 1 at layers 7->8
improved at p99; the worst ratios were 0.49x and 0.50x relative to sequential
execution. Kernel advice therefore does not make same-host lookahead safe on
this saturated four-core shape. Both local overlap mechanisms are rejected;
the next overlap experiment must isolate compute resources or move I/O work
off-host/off-path rather than add a route predictor to the current design.

## Reserved-capacity overlap

The run ending `T015149Z` repeated the user-space page-prefetch oracle gate with
ggml reduced from four compute threads to three, leaving one core's worth of
host capacity available. Its sequential control used the same three-thread
compute configuration. Full selected-page residency and exact numerical output
passed.

Latency still failed in 7 of 12 conditions. The result was mixed: all three
batch-8 layer pairs improved at p99, while most batch-2 and batch-4 pairs
regressed; the worst ratio was 0.72x. Merely reducing ggml thread count does not
control Linux placement of dirty schedulers and compute workers. The next valid
isolation test requires explicit CPU affinity and preferably a separate helper
process, with compute pinned to cores 0-2 and prefetch pinned to core 3.

## Strict-affinity external prefetch

The runs ending `T020219Z` and `T020353Z` moved prefetch into a persistent native process. The
NIF resolved exact gate/up/down GGUF file ranges for each oracle-selected
expert; the helper mmap-read those ranges on core 3 while the entire BEAM VM
and three-thread ggml compute were restricted to cores 0-2. Runtime `taskset`
evidence confirmed both masks. Full selected-page residency and exact output
equivalence passed.

The universal latency gate failed in both runs. The first improved 7 of 12
conditions; the provenance-complete rerun, which also records the helper binary
SHA-256, improved 11 of 12. This run-to-run spread makes the small-batch result
unstable. All batch-8 layer pairs passed in both runs, with 1.02x–1.11x p99
speedups across the observed cases. This is only a post-test signal, not
permission to enable conditional lookahead. The next gate should predeclare
batch 8 only, increase samples and independent repetitions, and require every
repetition/layer pair to pass before implementing a batch-size policy.

## Batch-8 repeatability gate

The predeclared follow-up ran three independent BEAM/helper processes with 100
paired trials for each batch-8 layer pair, for 900 paired trials total. Every
repetition had to pass affinity, residency, numerical equivalence, and overlap
p99 for all three layer pairs; results were not pooled.

Repetitions 2 and 3 passed. Repetition 1 failed layer 14->15: overlap p99 was
15.533 ms versus 14.733 ms sequential, a 0.949x ratio. The aggregate artifact
ending `T021010Z` therefore failed. This rejects a batch-8-conditioned local
lookahead policy on the tested host. Route-prediction work should not proceed
for this local mechanism because even oracle routes do not yield repeatable
latency benefit. The next independent systems question is active-parameter
memory residency/RSS, not further post-hoc slicing of the latency results.

## Active-parameter RSS and resident pages

The fresh-process run ending `T021609Z` evicted every gate/up/down expert range
across all 16 layers, verified zero present PTEs through `/proc/self/pagemap`,
then compared routed top-8 experts per layer with an all-64-expert control.
Process RSS and PSS came from `/proc/self/smaps_rollup`.

Logical active bytes were 487,587,840 versus 3,900,702,720 for all experts,
exactly the theoretical 8/64 (12.5%) fraction. Actual present bytes were
1,085,272,064 versus 3,913,285,632 (27.7%); RSS deltas closely matched at
1,089,163,264 versus 3,921,063,936 bytes (27.8%). Baseline and post-active reset
both returned to zero expert PTEs, and the all-expert control reached 100%.

The predeclared <=25% RSS and <=20% PTE gates therefore failed. Sparse mmap
residency is real and materially below total expert size, but normal sequential
file faults map neighboring pages and more than double the logical active
working set. The next test should apply `MADV_RANDOM` (or an equivalent
fault-around-suppressing access policy) before selected-page touches and retain
this run as the matched default-advice control.

## Random-advice active-memory scaling

The matched rerun ending `T022138Z` applied `MADV_RANDOM` to each selected
expert range before the same page touches. All other routing, eviction,
pagemap, RSS, and all-expert control procedures and thresholds were unchanged.

Active PTE-present bytes fell to 504,152,064 (12.88% of all expert pages), and
the active RSS delta fell to 506,138,624 bytes versus 3,899,248,640 bytes for
all experts (12.98%). Logical touched bytes remained exactly 12.5%. Baseline
and reset PTE presence were zero, and the all-expert control reached 100%.
Every predeclared gate passed.

Compared with default advice, `MADV_RANDOM` removed roughly 583 MB of active
RSS amplification and brought physical process residency within 0.48
percentage points of the logical active fraction. This supports near-logical
active expert-weight residency for the tested single-request access pattern;
it does not yet cover dense weights, KV cache, concurrent requests, allocator
peaks, or end-to-end decoding.

## Concurrent shared-model memory scaling

Fresh processes measured one, two, and four independent llama contexts sharing
one model. Each context decoded eight causal tokens with one native thread;
the probe sampled RSS every millisecond and included context/KV allocation,
graph allocator peaks, dense weights, and expert mappings. Expert ranges used
`MADV_RANDOM`.

Peak RSS deltas were 2,438,885,376, 2,880,929,792, and 3,530,952,704 bytes.
Thus four requests consumed 1.448x the one-request delta and 36.2% of four
isolated one-request deltas, passing the shared-model sublinear-scaling bounds.
Context-allocation RSS grew nearly linearly at about 36 MB per request.

The overall predeclared gate nevertheless failed because expert PTE fractions
were 60.97%, 71.32%, and 85.96%, above their bounds. Unlike the prior
one-hidden-state test, eight tokens select a union of experts at every layer,
and touched mappings remain present after their work ends. The next test must
decode token by token and evict experts that are no longer in the retained
active set; advice alone cannot enforce an active working-set lifecycle.

## Token-boundary lifecycle eviction

The lifecycle successor retained each request's KV cache, decoded one token at
a time, and evicted all expert mappings after every token. Fresh 1/2/4-request
processes reduced peak RSS deltas from 2.439/2.881/3.531 GB to
1.146/1.891/2.563 GB. Post-decode RSS returned to approximately 450/486/561 MB.
The four-request peak was 2.24x the one-request peak, equivalent to 55.9%
sharing efficiency versus four isolated one-request processes.

The strict gate still failed: maximum expert PTE fractions were
27.96%/46.17%/61.43%, above the 20%/35%/55% bounds. Token-at-a-time decoding,
accounting, and whole-expert eviction also increased elapsed time to 5.2-5.9 s
from 0.8-1.0 s for the accumulating control. Token-boundary eviction proves
that lifecycle management materially lowers residency, but it acts too late
and too broadly. The next test should evict completed-layer expert mappings
through the decoder evaluation callback.

## Layer-completion lifecycle eviction

The callback successor synchronized all concurrent requests at each MoE layer,
measured that layer's resident expert pages after computation, evicted its
expert mappings only after the final request arrived, and then released every
request into the next layer. This avoids evicting weights still in use by a
slower request.

Fresh 1/2/4-request processes all passed. Maximum expert PTE fractions were
3.53%/4.67%/6.11%, well below the predeclared 20%/35%/55% limits. Peak RSS
deltas were 223/272/407 MB; four requests used 1.824x the one-request delta and
45.6% of four isolated one-request deltas. Elapsed time was 1.87/1.87/2.26 s,
substantially below the 5.2-5.9 s token-boundary implementation, though still
above the accumulating control's 0.8-1.0 s.

This supports bounded expert residency and shared-model scaling for short,
eight-token concurrent decodes on this host. It does not establish sustained
generation behavior, long-context KV scaling, request churn, remote storage,
or production-safe callback overhead. The next test should run a longer
steady-state generation with staggered request arrival and departure.

## Sustained staggered request churn

The successor used eight persistent-KV requests of 16 generated tokens each,
started four token rounds apart. The 44-round schedule reached four concurrent
requests, then repeatedly added and retired contexts. Fresh matched processes
used identical tokens, one thread per context, `MADV_RANDOM`, page accounting,
and 1 ms RSS sampling; only layer-completion eviction differed.

The aggregate gate passed. The accumulating control reached a 3.957 GB peak
RSS delta and 98.19% expert PTE presence in 30.53 s. Layer eviction reached
364 MB and 2.87% in 52.90 s: 9.20% of control peak RSS, 2.93% of control expert
residency, and 1.73x control elapsed time. These clear the predeclared 50%,
25%, and 3x comparison bounds as well as the absolute 1 GB and 10% layer
bounds.

This establishes bounded expert residency under one deterministic staggered
schedule, not arbitrary production arrivals. The elapsed values include heavy
`pagemap` instrumentation, and the experiment does not cover long-context KV
growth, cancellation mid-layer, latency tails, remote storage, or admission
control. The next test should separate callback/eviction overhead from page
accounting and report per-token latency distributions under the same churn.

## Staggered per-token latency without page accounting

The timing successor retained the same eight-request, 16-token, four-round
arrival schedule and 1 ms RSS monitor but removed repeated `pagemap` scans from
the generation path. It captured all 128 individual `llama_decode` durations;
layer samples include barrier waiting and synchronous eviction.

The gate passed. Control p50/p95/p99 were 110.3/166.0/167.9 ms; layer eviction
measured 187.7/198.4/205.5 ms, ratios of 1.70x/1.20x/1.22x. Aggregate
throughput was 18.93 versus 17.18 token/s (90.8% retained), and total elapsed
time was 1.10x control. All latency and elapsed ratios stayed below the
predeclared 3x ceiling and throughput exceeded the one-third floor.

The earlier 1.73x instrumented elapsed ratio therefore substantially included
resident-page measurement cost rather than eviction alone. This remains an
in-process deterministic benchmark: it excludes queueing, network latency,
arbitrary arrivals, remote storage, and cancellation. The next useful gate is
repeatability across independent runs and longer contexts before broadening the
claim.

## Staggered latency repeatability

Two additional fresh control/layer pairs repeated the timing-only protocol and
were aggregated with the original pair. All three source gates passed. Their
p99 latency ratios were 1.224/1.215/1.215x, elapsed ratios were
1.102/1.118/1.102x, and throughput retention was 90.8%/89.4%/90.8%.

The p99-overhead cross-run spread was 1.008x and elapsed-overhead spread was
1.015x, well within the predeclared 1.5x limits. This supports repeatability on
the same host and deterministic schedule only. The next test should increase
the persistent KV horizon while retaining staggered arrivals; 64 tokens per
request with arrivals every 16 rounds preserves four active requests and gives
512 latency samples without changing peak concurrency.

## 64-token persistent-KV horizon

The longer-horizon successor increased each of eight requests from 16 to 64
tokens and the arrival interval from four to 16 rounds, preserving four active
requests at peak. It captured 512 individual decode samples without repeated
page accounting in the timed path.

The gate passed. Control p50/p95/p99 were 112.8/168.9/170.9 ms; layer eviction
measured 188.8/200.9/209.6 ms, ratios of 1.67x/1.19x/1.23x. Throughput was
20.43 versus 17.66 token/s (86.4% retained), total elapsed time was 1.16x
control, and peak RSS delta was 344 MB versus 4.040 GB.

This extends the evidence to a four-times-longer request horizon without a
material tail-latency regression, but 64 tokens is still far below production
context lengths. The next test requires lifting the probe's 64-token cap,
sizing each llama context explicitly, and running 256 tokens/request with
arrivals every 64 rounds while retaining four-request peak concurrency.

## 256-token persistent-KV horizon

The probe cap was raised to 512 tokens. Staggered contexts are now explicitly
sized to at least the retained-token horizon while their batch and microbatch
buffers remain one token, matching the token-at-a-time workload. Eight
256-token requests arrived every 64 rounds, preserving four active requests
and producing 2,048 latency samples per condition.

The gate passed. Control p50/p95/p99 were 118.8/174.8/177.3 ms; layer eviction
measured 190.9/203.8/208.2 ms, ratios of 1.61x/1.17x/1.17x. Throughput was
20.20 versus 17.50 token/s (86.6% retained), total elapsed time was 1.15x
control, and peak RSS delta was 356 MB versus 4.048 GB.

This supports the mechanism through a 256-token retained KV horizon on this
host, but all requests still have identical lengths and enter on a fixed
schedule. The next test should use uneven request lengths and cancellation at
token boundaries to validate dynamic barrier membership without deadlock or
unsafe early eviction.

## Uneven request lifetimes and cancellation

The churn successor used request lengths of
256/96/192/64/224/128/80/160 tokens with arrivals every 48 rounds. Requests
shorter than the planned 256-token maximum retired at token boundaries, which
changed the layer barrier's active membership repeatedly while preserving a
four-request peak.

Both fresh processes completed all eight requests and exactly 1,200 latency
samples without deadlock. The gate passed: control p50/p95/p99 were
112.8/166.7/171.4 ms and layer eviction measured 138.7/196.0/201.5 ms, ratios
of 1.23x/1.18x/1.18x. Throughput retention was 85.4%, total elapsed time was
1.17x control, and peak RSS delta was 340 MB versus 4.048 GB.

This validates membership changes between token rounds, not interruption while
a layer is executing. The next coverage step should parameterize request start
and stop arrays and replay several seeded random schedules; mid-layer
cancellation should remain deferred until the current layer barrier completes.

## Seeded start/stop schedule replay

The native probe now accepts explicit per-request start and length arrays.
Three deterministic seeds varied eight arrivals and 64-256-token lifetimes,
with 1,232-1,264 samples per condition and at most four active requests. Each
seed used fresh matched control and layer processes.

All three pair gates and the aggregate gate passed. Seeds 101/202/303 produced
p99 overhead ratios of 1.184x/1.176x/1.176x, elapsed ratios of
1.172x/1.182x/1.174x, and throughput retention of 85.3%/84.6%/85.2%.
Layer peak RSS deltas were 332/345/331 MB versus approximately 4.04 GB for the
controls. The p99 cross-schedule spread was only 1.007x.

This broadens dynamic-membership evidence beyond one schedule but remains
limited to a four-core host and four active requests. The next test should
increase peak active membership to eight and measure overload behavior, tail
latency, and whether admission control is needed.

## Eight-request overload and admission boundary

Matched workloads processed eight 128-token requests and 1,024 total tokens.
The peak-4 schedule ran two groups of four; the peak-8 schedule started all
requests together. Both control/layer safety gates passed.

At peak four, layer p99 was 206.9 ms, throughput 20.06 token/s, and peak RSS
delta 347 MB. At peak eight, layer p99 was 358.3 ms, throughput 24.29 token/s,
and peak RSS delta 525 MB. Thus eight active requests improved throughput by
21.1% but inflated p99 by 73.1% and RSS by 51.5%.

The predeclared admission rule required at least 10% throughput gain and no
more than 50% p99 inflation. Memory safety passed, but admission failed on
latency. The recommended active limit is four for this four-core host. The next
test should implement a four-active admission queue and measure end-to-end
request latency, including queue wait, against unrestricted peak eight.

## Four-active FIFO admission queue

All eight 128-token requests arrived at a common time zero. The unrestricted
policy activated all eight; FIFO cap-4 admitted four and released the second
group after the first completed. Native completion timestamps measured
end-to-end request latency including queue wait.

The queue tradeoff gate passed. FIFO cap-4 reduced token service p99 from
323.2 ms to 207.8 ms (35.7%) and peak RSS delta from 529 MB to 345 MB (34.8%).
It retained 81.5% of unrestricted throughput. End-to-end request p99 increased
from 41.49 s to 50.92 s, a 22.7% queueing cost within the 25% limit.

The recommended policy for this four-core host is therefore FIFO with four
active requests. This is one simultaneous-arrival burst; the next test should
replay the policy under several seeded arrival bursts and verify end-to-end
latency and queue-depth stability.

## Seeded arrival-burst validation

Native timing now records each request's arrival and completion separately.
Three deterministic patterns covered a second four-request burst, paired
arrivals, and evenly staggered arrivals. FIFO admission starts were derived for
four active slots; unrestricted controls admitted each request at arrival.

All three tradeoff gates passed. Seeds 11/22/33 produced queued/unrestricted
service-p99 ratios of 0.643/0.596/0.635, throughput ratios of
0.860/0.866/0.861, and peak-RSS ratios of 0.663/0.687/0.696. End-to-end request
p99 ratios measured from each arrival were 1.188/1.184/1.195, remaining below
the 1.25 bound.

This supports FIFO cap-4 across several eight-request burst shapes.

## Deep mixed-length queue

A deterministic 16-request, 2,104-token run exercised FIFO cap-4 with mixed
56-224-token request lengths and staggered arrivals. All requests completed.
Maximum queue depth was 11, wait p99 was 71.584 seconds, request p99 was
100.095 seconds, throughput was 18.64 token/s, and peak RSS delta was 343 MB.
Those five predeclared gates passed. Slowdown Jain fairness was 0.739, below
the predeclared 0.80 minimum, so the overall verdict was FAIL.

FIFO cap-4 therefore remains a useful resource cap but is not a sufficiently
fair production scheduler for deep mixed-length queues. The next comparison
should keep the four-active cap and test an aging size-aware admission policy
against FIFO using the same schedule and gates.

That comparison passed without changing the gates. The aging size-aware policy
selects the arrived request minimizing `token budget - rounds waited`. On the
identical workload, slowdown Jain fairness rose from 0.739 to 0.901, wait p99
fell from 71.584 to 65.016 seconds, and throughput rose from 18.64 to 19.26
token/s. Request p99 increased slightly from 100.095 to 101.746 seconds and
peak RSS delta from 343 to 351 MB; both remained within their original limits.

Repeatability then passed across two seeded schedules and one long-job stress
schedule. Fairness stayed between 0.857 and 0.899, throughput between 18.47 and
18.81 token/s, and maximum wait p99 was 68.388 seconds. Cross-run fairness and
throughput spreads were 1.049x and 1.018x. In the stress schedule, a deliberately
deferred 224-token request was admitted after 176 scheduler rounds and completed.

The next gap is online operation: the current harness supplies declared token
budgets to the admission policy. Validate estimation error and unknown-length
requests before treating size-aware priority as a production interface.

## Unknown-length quantum scheduling and routed-expert LRU

An eight-token quantum scheduler removed the declared-length dependency and
completed the all-unknown mixed-length workload. On OLMoE, full layer eviction
used 770 MB versus 4.476 GB for the accumulating control while retaining 85.7%
of throughput. Router-driven per-layer LRU then found cache size eight to be
the best measured OLMoE point: repeatability passed across two seeds and a
long-job stress schedule with 828-875 MB peak RSS and 19.45-20.02 token/s.

The second-model Qwen1.5-MoE validation did not reproduce OLMoE's absolute
memory result. Full eviction used 978 MB at 7.60 token/s; LRU-8 reached 2.073 GB
at 8.18 token/s. LRU-4 provided the better measured compromise at 1.522 GB and
7.92 token/s: 4.2% faster than full eviction with 55.6% more RSS, and 26.6%
less RSS than LRU-8 for only 3.2% less throughput.

Qwen LRU-4 repeatability passed on relative stability: throughput spread was
1.55%, RSS spread 4.15%, request-p99 spread 4.44%, and minimum slowdown Jain
fairness 0.99917. A matched ARM PMU pair modestly favored LRU-4 over full
eviction: memory accesses fell 1.9%, bus accesses 1.2%, L2 refills 2.2%, and
cycles 2.7%, consistent with the approximately 4% throughput improvement.

The current recommendation is therefore opt-in and model-specific: LRU-8 for
the measured OLMoE configuration and LRU-4 for the measured Qwen configuration.
Do not infer an automatic policy from architecture or parameter count yet.
Qwen shared-expert tensors are not managed by the routed-expert LRU, and only
two models on one host have been measured. A third MoE model is the next
promotion gate for a model-metadata-driven default.

That third-model gate used Granite 3.1 3B-A800M, an independent Granite MoE
architecture. Full eviction passed at 355 MB and 17.00 token/s. LRU-4 passed
at 531 MB and 17.43 token/s, improving throughput 2.6% and request p99 2.7%;
LRU-8 reached 18.57 token/s but doubled RSS to 710 MB. LRU-4 repeatability
passed two alternate seeds and a long-job stress schedule: throughput spread
was 2.18%, RSS spread 3.52%, request-p99 spread 4.03%, and minimum fairness
0.99916.

Granite metadata reports 40 total experts and eight routed experts per token;
therefore experts-selected-per-token alone cannot choose the measured cache:
Granite favored LRU-4 while OLMoE, also routing eight, favored LRU-8. Automatic
selection is limited to an exact allowlist of the three validated
`{total experts, routed experts}` tuples. Unknown tuples fall back to full
eviction. This is deliberately narrower than a general model-size heuristic.

The exact resolver passed runtime tests through both stub and real NIF builds,
including two unknown tuples resolving to zero (full eviction) and malformed
metadata returning `invalid_arg`. End-to-end auto-mode runs selected LRU-8 for
OLMoE and LRU-4 for Granite and Qwen. Qwen auto measured 7.88 token/s,
1.534 GB RSS, and 250.8-second request p99, within 0.8% of its explicit LRU-4
baseline on all three metrics. Its absolute verdict remains FAIL because the
harness thresholds were calibrated for OLMoE, not because auto selection
diverged from the explicit policy.

## Router-locality hypothesis

The native top-k callback now counts a route hit only when the selected expert
was already in that layer's LRU set before recency was updated. Counter totals
matched the expected `tokens × MoE layers × routed experts`, providing an
internal completeness check.

All three configured-policy runs showed genuine reuse: OLMoE LRU-8 hit 43.1%
(116,003/269,312), Granite LRU-4 hit 27.2% (146,727/538,624), and Qwen LRU-4
hit 17.1% (34,506/201,984). This supports the existence of temporal router
locality, but disproves the stronger hypothesis that hit rate alone predicts
the cross-model throughput gain. The ordering is reversed: OLMoE had the
highest hit rate but the smallest measured gain, while Qwen had the lowest hit
rate but the largest. Expert span, page-fault cost, and shared-expert traffic
remain plausible interacting variables.

## Cost-weighted locality hypothesis

A follow-up measured seven `MADV_DONTNEED`-plus-touch trials for one routed
expert at the first, middle, and final layers. Mean logical expert spans were
3.90 MB for OLMoE, 1.46 MB for Granite, and 5.95 MB for Qwen. Median cold-fault
latencies were 41.4, 153.7, and 501.6 microseconds respectively. OLMoE was
bimodal by layer (p95 530.6 microseconds), so this is a page-cache/PTE proxy,
not a stable storage-service-time estimate.

Weighting median fault latency by observed LRU hit rate produced approximately
17.8 microseconds avoided per route for OLMoE, 41.9 for Granite, and 85.7 for
Qwen. This ordering matches their measured LRU throughput gains of roughly
1.8%, 2.6%, and 4.2%. The result directionally supports fault cost per hit,
rather than hit rate alone, as the more useful explanatory variable. It does
not establish causality: there are only three models, the fault proxy is
bimodal for OLMoE, and shared-expert traffic is not included.

## Qwen shared-expert RSS hypothesis

Qwen's 24 shared-expert branches contain 503.0 MB of logical gate/up/down
weights. Initial `mincore` accounting showed them resident both before and
after decode, but that only established host page-cache residency. A corrected
`/proc/self/pagemap` measurement showed the same 503.4 MB of present PTE pages
immediately after model initialization and after the queue run.

Therefore shared experts contribute substantially to Qwen's absolute process
baseline, but contribute zero new present bytes to the measured 1.53 GB
run-time RSS delta. This disproves the hypothesis that unmanaged shared-expert
page accumulation explains that delta. Because the shared branch executes on
every token, it may still contribute compute and memory traffic; this test did
not isolate its PMU cost.

## Qwen routed-working-set RSS hypothesis

The configured LRU-4 queue run retained 134,936 routed-expert PTE-present
pages after decode, or 552.7 MB. That is 36.5% of the 1.514 GB peak RSS delta.
After decoder cleanup, process RSS remained 530.4 MB above its initial value,
close to the retained routed working set, while shared-expert presence was
unchanged at 503.4 MB.

This supports routed-expert residency as the explanation for nearly all of the
persistent post-run increase, but disproves the stronger hypothesis that it
accounts for most of peak growth. The remaining 961.6 MB peak attribution gap
is transient and is consistent with overlapping decoder/context, KV, graph,
and in-flight expert pages. It is an upper-bound residual rather than a clean
allocation measurement because peak RSS and the post-run routed-page scan are
different time points. Artifact:
`results/deep-queue-baseline-configured-all-unknown-cap-4-20260724T215123Z`.

## Qwen decoder-allocation residual hypothesis

A fresh-process allocation probe created four 256-token Qwen decoder contexts
and sampled RSS before the first decode. All three repetitions produced the
same 221,732,864-byte increase. This is consistent with the four reported
48 MiB KV buffers plus roughly 30.0 MB of graph/context overhead.

Decoder/KV/graph allocation therefore accounts for only 23.1% of the 961.6 MB
transient attribution gap above. The hypothesis that clean decoder allocation
dominates that gap is rejected. Approximately 739.9 MB remains attributable to
decode-time overlap: in-flight routed pages, non-expert model pages faulted by
execution, temporary compute storage, or timing mismatch between the RSS peak
and post-run page snapshot. The probe's decode-side expert result is not used
for this conclusion because this allocation probe does not install the LRU
layer-lifecycle callback.

## Qwen peak component and context-retention hypotheses

A readiness-gated `smaps` sampler classified memory at 99.9% of the harness's
independently observed peak. For configured LRU-4, peak growth decomposed into
642,961,408 model-backed bytes (42.4%), 874,098,688 anonymous bytes (57.6%),
and 589,824 other-file bytes. The adjacent baseline's model component was
derived by subtracting the sampled anonymous and other-file components from
the harness `smaps_rollup` baseline; the component total differs from the
harness peak delta by only 0.03%.

The matched full-eviction run had 94,666,752 bytes of model-backed growth and
872,955,904 bytes of anonymous growth. Anonymous growth differed from LRU-4 by
only 1.14 MB (0.13%), while LRU-4 added 548,294,656 model-backed bytes. That
increment agrees within 0.8% with the independently measured 552.7 MB retained
routed-expert set. Thus the routed LRU explains essentially all incremental
LRU memory, while the large anonymous component is policy-independent.

A one-request, one-token-at-a-time autoregressive control added only
53,723,136 anonymous bytes. Inspection of the quantum scheduler showed why the
four-active queue was much larger: preempted requests retain their decoder and
KV state, so all sixteen contexts can coexist despite only four decoding at a
time. A clean sixteen-context pre-decode probe measured 885,096,448 bytes,
within 1.4% of the queue's 872,955,904-byte anonymous increase. This supports
parked decoder/KV contexts, not transient compute workspace, as the dominant
anonymous peak source. The earlier 128-token batch control reached 1.51 GB of
anonymous RSS and is excluded because its batch shape was not autoregressive.

## Qwen context-residency mitigation hypothesis

A matched non-preemptive FIFO/full-eviction run retained at most four decoder
contexts. Its peak RSS delta was 305,852,416 bytes, 68% below the approximately
968 MB component-sampled quantum/full-eviction run. Sampled anonymous growth
was about 207 MB, consistent with four roughly 54-55 MB contexts and far below
the quantum queue's 873.0 MB from sixteen parked contexts.

The reduction has the predicted scheduling cost. Slowdown Jain fairness fell
from approximately 0.999 under quantum scheduling to 0.741 under FIFO, and
instrumented throughput fell from about 7.05 to 6.62 token/s. Thus limiting
resident contexts solves the memory peak but rejects the hypothesis that a
non-preemptive policy can preserve quantum fairness. Improving both requires a
new state-management mechanism—KV/context suspension, compression, or replay—
rather than another admission-order parameter. Artifacts:
`results/qwen-rss-components-20260724` and
`results/deep-queue-baseline-fifo-all-unknown-cap-4-20260724T223557Z`.

## Qwen KV suspension hypothesis set

An in-memory llama.cpp sequence-state probe tested 16/64/128/224-token
checkpoints. F16 snapshots grew from 3.15 to 44.04 MB. Retaining the snapshot
while freeing the decoder released 46.6/37.1/24.6/5.7 MB respectively, so
suspension is feasible but its memory value declines late in a 256-token
context. Export plus import took 0.69-7.78 ms, while prefix replay took
3.64-52.63 seconds. Restored F16 logits were bit-exact at every checkpoint.

Q8 KV snapshots were 46.9% smaller and their own export/restore was exact, but
Q8 versus F16 changed the top token at two of four checkpoints and had mean
absolute logit error 0.099-0.130. It therefore failed the output-equivalence
gate. `/dev/shm`, `/tmp`, and the local results filesystem all read snapshots
in 0.36-7.9 ms; storage access remained negligible relative to replay on this
host, though the file test did not force durable media with `fsync`.

Two quantum queue modes then exported state and freed a decoder at quantum
expiry, restoring it when rescheduled. Always-suspend completed all 2,104
tokens with 0.999 fairness and reduced LRU-4 peak RSS from 1.516 GB to
965.1 MB (36.3%). The stronger hypothesis that it would approach FIFO's
305.9 MB peak was rejected because the routed LRU and serialized snapshots
remain resident. Adaptive suspension—skipping suspension when nobody else was
waiting—measured 971.4 MB, 7.186 token/s, and 0.999 fairness, effectively the
same as always-suspend's 965.1 MB and 7.189 token/s because this deep queue
almost always had another waiter.

Matched throughput was 7.901 token/s for ordinary LRU-4, 7.609 for full
eviction, and 7.189 for suspension plus LRU-4. Thus current context creation
and state transfer cost 9.0% versus LRU-4 and 5.5% versus full eviction. The
end-to-end hypothesis that suspension preserves LRU's throughput advantage is
rejected. At this workload, suspension plus LRU uses approximately the same
peak memory as full eviction while running slower. Artifacts:
`results/kv-suspension-probe-20260724` and the matched queue directories dated
`20260724T235632Z` through `20260725T001206Z`.

## Qwen optimized suspension hypothesis set

The public llama.cpp memory API can clear KV metadata but cannot independently
deallocate or remap the context-owned KV buffer. Clearing metadata and restoring
the F16 snapshot into the same decoder was bit-exact and imported in 1.24 ms,
but released no RSS. A fresh decoder took 20.17 ms to create; export plus import
took about 2.45 ms, and the first restored token took the same approximately
232 ms with either a reused or fresh context. Context reconstruction is thus
the dominant controllable suspension overhead, while KV-only eviction is not
available through the current public API.

Larger quanta reduced reconstruction frequency. Q16 measured 7.502 token/s,
0.996 fairness, and 981.0 MB peak RSS. Q24 measured 7.648 token/s, 0.994
fairness, and 970.9 MB. Q32 reached 7.694 token/s and 956.1 MB but fairness fell
to 0.974. This supports quantum sensitivity and identifies Q24 as the tested
sub-1-GB fairness boundary.

Suspending only through token 128 modestly improved Q16 throughput from 7.502
to 7.587 token/s, with 0.996 fairness and 990.0 MB RSS. It did not outperform
full eviction's 7.609 token/s, so the fixed early-prefix threshold is useful
but not sufficient. Raising the live-context cap produced stronger throughput
at higher memory: live-6 reached 8.599 token/s, 0.995 fairness, and 1.078 GB;
live-8 reached 8.875 token/s, 0.997 fairness, and 1.211 GB. Both are Pareto
points but fail the sub-1-GB objective.

LRU route hit rates remained between 17.0% and 17.5% across Q8/Q16/Q24/Q32,
selective, and live-cap variants. This rejects routed-cache disruption as the
explanation for suspension overhead; reconstruction frequency explains the
observed recovery with larger quanta. Q24 is the only tested configuration to
meet all predeclared final objectives: fairness >=0.98, peak RSS <1 GB, and
throughput above matched full eviction (7.648 versus 7.609 token/s). Its margin
is only 0.5%, so repeatability remains required before making it the default.

## Q24 robustness and promotion hypothesis set

Five fresh Q24 runs were tightly repeatable: mean throughput was 7.648
token/s with 0.63% range spread, mean peak RSS was 967.7 MB with 1.19% spread,
mean fairness was 0.99388 with 0.009% spread, and request-p99 spread was 0.60%.
Five matched full-eviction runs averaged 7.607 token/s. The 0.536% Q24 mean
advantage exceeded observed noise in this sample (Welch t approximately 4.09),
supporting a small host-local throughput improvement rather than a single-run
artifact.

Arrival-pattern robustness was mixed. Long-job-stress reached 7.662 token/s,
945.9 MB, and 0.996 fairness. Seed-202 reached 7.521 token/s, 965.3 MB, and
0.995 fairness. Seed-101 reached 7.509 token/s, 1.006 GB, and 0.993 fairness.
Fairness generalized, but the strict sub-1-GB and above-full-eviction throughput
objectives did not hold for every schedule.

The quantum neighborhood showed that Q24 is not a local throughput optimum.
Q20 measured 7.606 token/s, 979.2 MB, and 0.993 fairness. Q28 measured 7.717
token/s, 966.8 MB, and 0.982 fairness, clearing the stated thresholds with a
narrow fairness margin. Q28 requires its own repeatability and schedule suite
before it can supersede Q24.

Q24 failed memory scaling stresses. Sixteen 224-token requests reached 1.279
GB despite 7.641 token/s and 0.999 fairness. A safely extended 24-request burst
completed all 3,160 tokens at 7.624 token/s and 0.992 fairness but reached
1.059 GB. Suspended snapshot bytes therefore remain workload-dependent and
cannot be bounded from model metadata alone.

Single-run cross-model portability was positive for memory and fairness. OLMoE
with automatic LRU-8 measured 19.42 token/s, 523.7 MB, and 0.994 fairness;
Granite with LRU-4 measured 16.97 token/s, 314.1 MB, and 0.994 fairness. These
are narrow validations, not repeatability results. Because Qwen itself exceeded
1 GB under valid schedule, prefix, and queue-depth variants, the hypothesis
that model metadata alone is sufficient for automatic Q24 selection is
rejected. Production defaults remain unchanged; Q24 stays experimental.

## Q28 matched-control and suspension correctness

Five Q28 suspension runs passed the preregistered repeatability gates with
7.7095 token/s mean throughput, 0.98188 minimum fairness, 973.1 MB maximum
peak RSS, and throughput/RSS/request-p99 spreads of 0.50%/1.63%/0.51%.
Five newly added quantum-28 full-eviction controls averaged 7.6217 token/s.
The Q28 ratio was 1.0115 with a bootstrap 95% interval of 1.0099-1.0130,
removing the earlier quantum-8 control mismatch. Schedule and prefix/queue
stress gates remain open, so this is not a universal policy promotion.

A separate autoregressive correctness probe compared an uninterrupted Qwen
decoder with one destroyed, recreated, and restored every 28 tokens. The
64- and 256-step runs completed two and nine suspension cycles respectively,
with zero full-vocabulary logit delta and zero generated-argmax mismatches.
This closes the repeated F16 state-transfer correctness prerequisite for the
token-at-a-time Q28 scheduler path.

The five-schedule matched stress gate rejected universal Q28 promotion. Every
candidate completed, retained fairness >=0.988, and was 0.89%-1.33% faster
than its quantum-28 full-eviction control. Long-job, seed-101, and seed-202
passed every criterion at 950.3/999.0/955.5 MB. Maximum-prefix and 24-request
queue workloads failed only the strict memory gate, reaching 1.241 GB and
1.056 GB. Q28 is therefore supported for the bounded 16-request workload
profile, not as a workload-independent sub-1-GB policy.