computedriven computedriven/docs/fcb-model.md
Status: model for the round opened by GPT's direction of 2026-09-16 (~/Documents/Codex/2026-09-16/are-we-at-a-state-with/outputs/FLOOR_COMPETITIVE_BENCHMARK.md, copied beside th…

FCB — the floor competitive benchmark: the model, written before the mechanism

Status: model for the round opened by GPT's direction of 2026-09-16 (~/Documents/Codex/2026-09-16/are-we-at-a-state-with/outputs/FLOOR_COMPETITIVE_BENCHMARK.md, copied beside this file as fcb-direction-2026-09-16.md). Rules nothing; receipts/FCB-R0-OPEN.md is the contract. Every numeral here is a definition or a prediction, never a measurement. Stage 0 of this round builds adapters and correctness controls only. No official performance battery is run, and nothing produced by a development smoke is a result.

Stage 0.1 (2026-09-16, the stage-0 review's four blockers, `FCB_STAGE0_REVIEW_AND_FABLE_ASSIGNMENT.md`): the window is closed by an armed deadline every worker knows before demand begins (§9); the semantic metrics are separated and computed from the last queued intent (§10); the physical instruments are partitioned by domain and a zero is never an observation (§6); and the ComputeDriven row is named for what executes — the `computedriven-policy` cd-core policy adapter, not the production cd-kernellet (§11, and fcb-kernellet-cost-contract.md for the real floor's own campaign). Wire format v1; one clock (CLOCK_MONOTONIC) in every process.

R7 established, against ComputeDriven's own policies, that transition-denominated selection with explicit residency (CLOCK-AGE) admits more semantic progress per physical cost than fair round-robin while keeping a finite progress bound. That is a comparison of one system's policies with each other. Nothing in this tree yet compares ComputeDriven with a native scheduler, and the R7 prior-art section (progress-model.md §10) maps concepts; it is not a shootout. This round asks the question GPT stated:

Given identical deterministic readiness traces and identical semantic transitions, which scheduling model — transition-denominated admission with explicit residency, or CPU-time / reduction / task-quota scheduling with everything resident and preemption allowed — produces the most fair semantic progress per physical cost?

The objective is R7's, unchanged: optimize semantic progress per Locus, not occupancy of Carriers. One unit of progress is one admitted, complete semantic transition. Migration, refusal, occupancy and CPU busy time are never progress.

0. Standing rulings adopted (permanent)

  • A semantic transition is never split. ComputeDriven refuses an over-long

transition at admission; it never interrupts one. The other systems may interrupt. That difference is the semantic difference this round preserves and reports; it is never papered over by giving the floor a preemption it does not have (F-FCB-1 below).

  • Migration is not progress; a refusal is counted; an event executes nothing.

  • Utilization is a diagnostic. A runtime does not win by keeping a core busy

while one entity receives no progress. The ranking objective is the Pareto frontier of semantic progress, worst-Locus delay and physical cost; there is no composite score.

  • Arrival is recorded independently of service (the coordinated-omission

rule). Every latency in this round is measured from the instant the trace intended the event, never from the instant a system noticed it.

  • No number from this stage is a result. The official battery runs only

under docs/battery-host-profile.md, after the round authorises it.

1. Vocabulary

termdefinitionwhat it is not
systemone complete runtime under its own native scheduler on one execution carrier: `computedriven-policy` — the cd-core POLICY ADAPTER (a benchmark-local home over cd-core's lifecycle with explicit parking, in one thread of a standard Rust process; not the production cd-kernellet image, §11); one Linux CPU with N pthreads under the fair class (EEVDF); one Go P (GOMAXPROCS=1); one BEAM scheduler (+S 1:1); one Seastar shard (--smp 1)not a language; the C row of the R2 census is a denominator, this round's Linux row is the kernel's scheduler; the policy adapter is not the floor
entitythe system's own unit of concurrency holding exactly one Locus's lineage (the R2 312-byte layout, or cd-core's 144-byte record in the ComputeDriven arm): a floor slot or parked record, a pthread, a goroutine, a BEAM process, a Seastar coroutine
semantic transitionone ATTACH or DETACH on a lineage under the class-S check set of Floor Census R2 (possession, generation, copy-in/copy-out with the original surviving a refusal); the same code in every language, the same code the R2 witness battery passednot the naked step (class N)
event(seq, locus, op, count, length, t_sched): the trace's intent that a Locus perform count transitions of kind op, arriving at the nominal instant t_schednot a command; not a message the system may reorder within a Locus
opNEXT (the admissible transition by possession), FLIP (the inadmissible one — a refusal by construction), ATTACH / DETACH (fixed), LONG (NEXT with a declared work length)
mailboxthe per-Locus bounded queue of admitted intents, depth D (D = 0: unbounded); admission of an event whose count would exceed D is refused whole as MAILBOX_FULL, counted, never a dropnot a thread's stack
closed-loop demandan event with count = *: the Locus is ready from that instant until STOP, performing NEXT transitions as fast as the system serves it (R7's UNIFORM)not an infinite queue: it is a flag; the mailbox is served first
readythe Locus's mailbox is non-empty, or its closed-loop flag is setready ≠ resident (ComputeDriven); ready ≠ running (everyone)
progressone transition the system reports as admitted and whose digest step the oracle can reproducenot a refusal, not a mailbox-full, not a migration, not the reported count alone (§5, C2)
ready-to-progress latencyt − t_sched of an event's first counted `ST_OK` transition, computed by the harness from the sample file, never by the adapter (§10)not t_admit − t_read: the adapter has no field to report a latency; not a refusal's resolution — that is ready-to-resolution, a separate column
ready-to-resolution latencyt − t_sched of an event's first counted terminal outcome: OK, REFUSED, BAD, or MAILBOX_FULL at admission (§10)not progress
oldest-ready agethe maximum age of any actually ready Locus before its next counted completion, or at the window's end: for the k-th completion t_k − max(t_sched(intent k), t_{k−1}), so the LAST queued intent of a multi-count event is seen; a closed-loop Locus's later completions are the adapter's recorded gap maximum (§10)a mean hides starvation; only the max is the instrument; a sampled 64-transition gap is not an age
windowthe interval [t0, deadline] the ARM frame names before any demand exists; a transition counts only if it completed at or before the deadline (§9)not "until STOP is read": the stage-0 review found Go counting 639 ms past it
physical costretired user-space instructions and cycles of the whole system process (perf_event_open, inherit, exclude_kernel forced by perf_event_paranoid = 2 — the domain is printed with the number); context switches from rusage via wait4 (every thread, kernel-accounted: the uniform instrument) and from the software event only when it opened without exclude_kernel; wall time; peak RSS from wait4; fabric bytes moved for the systems that move statekernel work is invisible to the instruction column on this host (§6); a row whose scheduler runs in the kernel is never ranked by it
refusal amplificationrefused ÷ admitted, per system; MAILBOX_FULL reported beside, not summed in

2. The two tiers

Tier A — native scheduler outcome. Every system receives the same trace through the same pipe from the same source process and serves it with its own scheduler, preemption model and residency model. ComputeDriven runs at density N / S with S floor slots and explicit parking; the others keep every entity resident. This answers which complete system produces the best outcomes and preserves the semantic difference of §0.

Tier B — matched residency budget. Every system is given the same hot-state capacity S and an explicit backing store; every transfer of a lineage between the two is a copy of the record the adapter counts (312 bytes in the C, Go and BEAM rows — the R2 layout; 144 bytes in the ComputeDriven arm, whose lineage is cd-core's own types without the authority ring — each row reports its record_bytes, and no comparison assumes parity). This isolates ComputeDriven's selection/residency policy from the advantage a conventional runtime gets by leaving everything resident. Tier B never substitutes for Tier A. In stage 0, Tier B exists in the ComputeDriven arm (natively), in the Go and Linux adapters (--slots S), and is named and unbuilt in the BEAM and Seastar adapters.

3. The trace — one file, one source process, one pipe

A trace is a text file (tools/fcb_trace.py gen): a header, --, then one event per line tick locus op count [length], with the body's SHA-256 in the header. Ticks are nominal instants t0 + tick × tick_ns. Two modes:

  • drain — finite events, D = 0, no budget: the system serves every event

and stops on STOP. Scheduling cannot change what is offered or what is served, so the final semantic state and per-Locus ledger are determined by the trace alone; the oracle computes them and every system must reproduce them (§5, C1).

  • timed — a budget of ticks, D > 0, closed-loop events allowed: what is

served depends on the scheduler, so there is no ledger oracle; the harness checks conservation and re-derives each Locus's digest from the served sequence the adapter recorded (§5, C2).

The five workloads are R7's, re-expressed as traces so that no system is handed a round (a scheduler pass is not a system-independent unit):

workloadtrace
UNIFORMdrain: each Locus receives K NEXT events, one per tick; timed: each Locus receives count = * at tick 0 (R7's every-Locus-always-ready)
SKEW-7/8draws draws per tick from the BENCHZC generator (r7_progress.Skew: the LCG, v % 8 != 0 → hot, hot = N // 8, the cold index from the next word), each draw one NEXT event; seven of eight land in the first eighth of the population
WAITINGeach Locus emits a burst of run NEXT events every run + wait ticks from a seeded phase; the next burst's instant is fixed by the trace, not by when the previous burst finished (open loop: a stall shows as mailbox occupancy, never as a delayed arrival)
REFUSING-pUNIFORM in which each event is FLIP with probability p (seeded); a FLIP is refused BAD_POSSESSION and consumed
LONG-nUNIFORM in which a seeded fraction of events are LONG with declared length n; the header carries long_bound

The source (fcb/source/fcb_source.c) is one C process, pinned to its own core, that writes 32-byte frames down a pipe at the nominal instants (or as fast as possible in drain mode): wire v1 — a HELLO frame first (version, population, depth, mode, bound), then, after the adapter's readiness byte, one ARM frame (t0 and the absolute deadline, §9), then the events, then STOP at the deadline. t_sched in every frame is the nominal instant and t_write the instant the write returned, both `CLOCK_MONOTONIC` nanoseconds — one shared monotonic clock domain in every process: not stepped by wall-clock changes; its rate may be adjusted, which every process sees alike (stage 0 used CLOCK_REALTIME; the review asked for one cross-process monotonic clock; Go reads it through runtime.nanotime, BEAM through os:perf_counter/1, both verified against the C reading to within a call's latency). Source lateness (t_write − t_sched) is reported by the source and subtracted by nobody: a late source is a labelled run in the smoke and a rejected row beyond a predeclared bound in the official runner, never a scheduler result (R7.1's rule).

4. What every adapter must do, and must not do

An adapter is PROG [--samples FILE] [--slots S] [--long-mode refuse|admit] [--policy P] [--mutant NAME], reads frames from fd 0 (refusing any wire version but 1), serves them with its native scheduler under the armed window (§9), and writes one JSON document to fd 1 at STOP:

  • counts: events_read, admitted, refused, refused_by (BAD_POSSESSION,

LENGTH), mailbox_full, closed_transitions, and for the systems that move state installs, evictions, bytes_moved, record_bytes;

  • the window: t0_ns, deadline_ns, last_counted_transition_ns,

post_deadline_progress (0 unless the ignore-deadline mutant), inflight_at_deadline and inflight_closed, cleanup_after_deadline_ns, closed_gap_max_ns;

  • the ledger: per Locus admitted, refused, generation, possession,

digest, inflight_at_deadline, last_counted_ns, closed_gap_max_ns; and final_digest;

  • the runtime's own view (GOMAXPROCS, schedulers, reductions, context

switches, Go's /sched/latencies:seconds, the Seastar task quota, the kernel version) as runtime, diagnostics only;

  • and, into --samples, one 16-byte record per served intent

(seq, locus, status, code, t) — seq = 0 for closed-loop transitions, of which the first and every closed_sample_every-th are sampled — plus one record with status 3 (REFUSED_ADMISSION) per event the reader refused as MAILBOX_FULL, so the harness can tell an event that was never owed service from one that starved, plus one record with the AFTER_DEADLINE bit (0x80) for the completion that closed the window on that entity (§9).

An adapter may not compute a latency, a rate or a percentile — there is no field for one. It records exactly two timings the sample file cannot carry: the gap maximum between its consecutive counted closed-loop completions (closed_gap_max_ns, at every transition, because sampling every k-th would make a 64-transition gap the "age"), and each Locus's last counted completion instant. It reads the clock once per transition, after it, on the source's clock. It may not count a MAILBOX_FULL, a FLIP refusal, a length refusal, an install or an eviction as admitted. It must serve one Locus's intents in arrival order and one at a time (a Locus is a lineage, not a queue of independent jobs). Its --mutant knob exists only so the controls can show the harness catches each of those violations; a run with a mutant set is non-evidentiary by its own output.

The digest is how the oracle knows a reported admission happened: per Locus, d ← splitmix64(d ⊕ (op | status≪4 | code≪8 | generation≪16) ⊕ (transitions≪32) ⊕ spin) after every served intent, d₀ = splitmix64(i+1); final ← splitmix64(final ⊕ dᵢ ⊕ (i+1)) over Loci in index order. spin is the result of LONG's declared work, a deterministic mixing loop of length steps, so a transition reported before its work completed changes the digest.

5. The controls (stage 0's deliverable) — each with its non-vacuity

controlwhat it establisheshow it is shown able to fail
C1 ledger equivalenceon every drain trace, every built system's ledger and final digest equal the oracle's (for LONG, the oracle of the system's declared long-mode)the two long-modes' oracles differ on the same trace; the skip-order mutant differs from the oracle
C2 served-sequence replayon every run, timed included, each Locus's reported digest equals the digest the harness re-derives from the sample file's served sequence, and admitted equals the OK samples (closed-loop transitions scaled by their sampling)mutants count-refusal, count-migration, partial-work, skip-order each caught, at a named Locus
C3 conservationevents_read = admitted_events + refused_events + mailbox_full + unserved_at_stopthe drop-event mutant is caught
C4 starvation is visibleHOT-RESIDENT on UNIFORM-timed at density 4 shows zero_progress_loci > 0 and unbounded oldest-ready age while its transitions/s is high; the scorecard flags itCLOCK-AGE on the same trace shows 0 starved (the exhibit's pair)
C5 arrival, not servicewith the source delayed by δ (--late-us), latency from t_sched grows by ≥ δ on every system; latency from t_write does nota harness that measured from t_write would show no change
C6 instrumentshardware counters open unmultiplexed or say why not; the software switch event is opened without exclude_kernel or reported unavailable with its errno — a zero is never an observation; rusage switches (the uniform instrument) are nonzero on the switch-inducing control (the Linux row: N threads on one CPU); RSS per entity is a Theil–Sen slope over three populations × two repeats, with its dispersionthe Linux row must show ≥ N switches; a null with no reason fails; a perf zero beside a nonzero rusage fails
C7 window closureon every timed trace, no row counts progress past the armed deadline — by the adapter's own post_deadline_progress and by the harness reading the sample file; inflight_at_deadline and cleanup are reported and add nothingthe ignore-deadline mutant (count until STOP, as stage 0 did) is caught on every row where STOP arrives after any completion, and is required to be caught on Go and Seastar
C8 metric semanticsready-to-progress holds only ST_OK completions; refusal-only events sit in ready-to-resolution and never in the progress population; oldest-ready age sees the last queued intent and the unserved tailtwo harness mutants — count-refusal-latency, first-intent-only — provably differ from the metric on a hand-built fixture, and on every row's live REFUSING and WAITING runs
C9 counter domainthe instrument's software switch event carries its domain; the instruction-cost frontier combines only rows whose scheduler runs where the counter can see itstage 0's mask (exclude_kernel on the switch event) reads zero beside a nonzero rusage: caught; a frontier that ignores domains ranks the kernel-scheduled row by user-only instructions: caught

6. What the instruments cannot see (inherited from R2, re-stated for the new rows; repaired in stage 0.1)

  • perf_event_paranoid = 2 forces exclude_kernel on hardware events. **The

Linux-EEVDF row's scheduler runs in the kernel and is invisible to the instruction column. Its user-only instructions are printed as a diagnostic and it is excluded from the instruction-cost frontier** (C9); it competes on the outcome frontier. No row may be read from instructions alone.

  • The software context-switch event is attributed to the kernel (perf_event_open(2):

after 2.6.34 context switches "are reported as happening in the kernel"). Opened with exclude_kernel it reads zero — stage 0 did exactly that and C6 passed on the zero (the review's FCB-R2). Opened without exclude_kernel it is refused with EACCES at paranoid 2. So on this host the event is unavailable with a reason, and the uniform switch instrument is `rusage` from `wait4` (voluntary + involuntary, every thread of the adapter), which counts in the kernel regardless. The Linux row's per-thread schedstat stays as its own diagnostic. If a narrowly provisioned launcher later grants kernel-inclusive counting, the receipt records the capability and the exact event domain; no general performance-monitoring capability is granted to an interpreter.

  • RAPL energy files are root-only on this host (/sys/class/powercap/*/energy_uj

mode 0400). Energy per admitted transition is named and not measured here.

  • The BEAM and Go rows spawn threads (I/O poll, sysmon, GC); inherit counts

them all, and the runtime's own reductions / GC counters are printed beside as the runtime's own view, never substituted for the hardware count.

  • CLOCK_MONOTONIC is one shared monotonic clock domain across processes with no

offset exchange: not stepped by wall-clock changes, its rate adjustable and seen alike by every process (wire v1 replaced CLOCK_REALTIME). The source reports its lateness; a run whose source was late is labelled in a smoke and rejected in the official runner.

7. Falsifiers (this round's; numbering continues the tree's F-series by name)

  • F-FCB-1 — any adapter that lets the floor interrupt a transition, or lets

a preemptive system refuse one it could have run, has changed the systems into each other; the LONG workload's two ledgers must differ.

  • F-FCB-2 — a system whose reported admitted is not reproduced by C2 is

reporting something other than progress.

  • F-FCB-3 — a latency that shrinks when the source is late is measured from

the wrong instant.

  • F-FCB-4 — a scorecard row without its instruction-column caveat (§6) on a

kernel-scheduled system is an overclaim.

  • F-FCB-5 — a run with any --mutant set, or the source --late-us set,

that is quoted as a result.

  • F-FCB-6 — a row whose counted progress includes a completion after the

armed deadline, or whose window is "until STOP is read" (§9).

  • F-FCB-7 — a refusal's resolution in the ready-to-progress population, or

an oldest-ready age that cannot see the last queued intent (§10).

  • F-FCB-8 — an instruction-cost frontier that ranks a row whose scheduler

runs where the counter cannot see, or a switch count read from a zero the instrument could not have produced (§6).

  • F-FCB-9 — any sentence that lets the computedriven-policy row's result

stand for the production cd-kernellet (§11).

8. Predictions, made before any run

Stated so the eventual battery cannot drift toward the number it likes: on UNIFORM-timed at density 4, Go and Seastar will report the most transitions in the budget (everything resident, cheap handoff), ComputeDriven CLOCK-AGE fewer but with bounded age and the fewest bytes moved, RR-FAIR fewest of the ComputeDriven arms; Linux-EEVDF will show the largest p99.9 and the most context switches per admitted; BEAM will sit between Go and Linux. On LONG with n above the bound, ComputeDriven's refusal amplification will be the fraction of LONG events and its tails unchanged, while every preemptive system admits them and its tails grow with n. On SKEW at density 8, Tier B will narrow the gap between ComputeDriven and the resident systems and Tier A will not. Any of these being wrong is a finding, not a failure of the round.

9. The window (stage 0.1; the review's FCB-R1)

Stage 0 wrote STOP at the intended deadline and let each adapter count until its own runtime scheduled the reader and processed it: Go counted for 639 ms past a 100 ms deadline, Seastar 32 ms, BEAM 2.4 ms, Linux 0.75 ms — the systems were measured over different windows, and the marginal-instruction slope was the difference of two runtime-dependent overruns. The scheduler under test was deciding how long it was measured.

Wire v1 closes the window independently of scheduling:

  • After the readiness handshake and before any event, the source writes an ARM

frame carrying t0 and the absolute deadline t0 + budget_ticks × tick_ns (0 on a drain trace). Every worker knows the deadline before demand begins: the reader stores it before it queues the first event; BEAM forwards it as a message that precedes every event by BEAM's per-pair ordering.

  • Every entity reads the clock twice per transition in timed mode: **t_begin

immediately before anything irreversible — before the intent is consumed, a residency move, LONG work, the step, the fold — and t_complete after it**.

  • t_begin > deadline: nothing happens. No mutation, no digest step, no

sample, no move; the intent stays queued (it is unserved_at_stop) and the entity is done. Reported as not_begun_after_deadline (at most one per entity). This is the start boundary the stage-0.1 review's FCB-R5 asked for: stage 0.1 approximated "begun before" by the previous completion and so let fresh work begin after the deadline and called it in flight.

  • t_begin ≤ deadline < t_complete: the entity's one in-flight transition.

It is executed — in the digest, so the replay (C2) steps it — but not counted: sampled with the AFTER_DEADLINE bit, reported as inflight_at_deadline, its residency moves uncredited, and the entity begins nothing more. One entity, at most one; the policy adapter, one thread, at most one in total.

  • t_complete ≤ deadline: counted normally (admitted or refused, sampled, in

the ledger's counts, credited with its moves).

  • late_begin_executed is reported and is 0 on every honest row: a transition

that began after the deadline and executed anyway can only come from the prev-completion mutant, which restores stage 0.1's check so C7's start-boundary control can fail.

  • The source still writes STOP at the deadline so every reader drains its

control traffic and exits; the reader keeps admitting into mailboxes after the deadline (those intents are unserved_at_stop), and serves nothing.

  • Reported: deadline_ns, last_counted_transition_ns, post_deadline_progress

(the adapter's own count of counted OK completions past the deadline: 0 by construction, nonzero only under the ignore-deadline mutant), inflight_at_deadline, inflight_closed, not_begun_after_deadline, late_begin_executed, cleanup_after_deadline_ns.

  • C7 checks both the adapter's count and the harness's own reading of every

sample's instant; the ignore-deadline mutant restores stage 0's behaviour and must be caught. C7's start-boundary control arms a 100 ms window and releases the demand ~200 ms after its nominal instant (a deliberately late source, non-evidentiary), so everything the demand could cause begins after the deadline: every row must show served = inflight = admitted = 0, an untouched digest and no moves; the prev-completion mutant must be caught wherever stage 0.1's check ever let work through (Linux and Seastar do; Go, BEAM and the policy adapter never reached that path because STOP stops them first, and say so).

The counter window (the review's FCB-R5, second half). Physical counters were enabled at exec and ran to exit, so runtime boot, the in-flight tail, cleanup and result serialization all entered the instruction total. The harness now opens the events disabled, learns t0 and the deadline from the source's ARM frame through a side-channel (--arm-fd), enables them at `t0` and disables them at the deadline by ioctl on the parent event — which the kernel applies to every inherited child, so every thread — independently of any adapter. Both edges' intended and actual instants and their lateness are recorded, the kernel's own time_enabled / time_running are read back beside them (for a per-task event they accrue task time, so they equal the window only for a row that never idles — 200.0 ms on a busy 200 ms closed loop, 1.1 ms on a mostly idle 20 ms open loop — and their inequality is the multiplexing check), and the official runner rejects an edge outside its tolerance. A drain trace has no deadline: its counters are enabled when ARM is seen and run to exit, and it is never a cost number.

Conservation with the window: intents_queued = (served − closed_transitions − inflight_closed) + unserved_at_stop, where served counts every executed intent.

10. The semantic metrics (stage 0.1; the review's FCB-R3)

Stage 0's "latency" population held every event's first served intent whatever its outcome: on the policy adapter's LONG run, 2,782 admitted transitions and 418 length refusals made a population of 3,200 labelled progress. And its oldest-ready age saw only an event's first intent and a sampled 64-transition gap. Both were the harness's reading. tools/fcb_metrics.py computes, from the trace, the source log, the sample file and two adapter-recorded timings:

metricdefinition
ready_to_progressper event with a counted ST_OK completion: t(first OK) − t_sched
ready_to_resolutionper event: t(first counted terminal outcome) − t_sched; MAILBOX_FULL resolves at admission
refusal latency, reasonsthe resolution latency of events whose first terminal is a refusal; the distribution over REFUSED/code, BAD/code, MAILBOX_FULL
oldest_ready_age_maxmax over: every counted completion's t_k − max(t_sched(intent k), t_{k−1}) (a later intent of a multi-count event ages from the previous completion; the last queued intent is seen); every Locus with intents unserved at the window's end, window_end − max(t_sched(first unserved), t_last); a closed-loop Locus's first completion from its event; the adapter's closed_gap_max_ns; a closed-loop Locus at the window's end from its last_counted_ns
max_inter_progress_gapthe largest gap between consecutive counted OK completions of one Locus that was ready throughout, and the adapter's closed-loop gap maximum

The window audit rides beside: counted samples past the deadline (must be 0), after-deadline samples, the latest of them, cleanup. C8's two harness mutants (count-refusal-latency, first-intent-only) are stage 0's readings, kept so the control can fail.

11. The subject's name (stage 0.1; the review's FCB-R4), and the two campaigns

The row is `computedriven-policy`: the cd-core policy adapter — cd-core's lifecycle types, the kernellet's step shape, a benchmark-local home and parking, one thread, a standard Rust process. It does not execute the production cd-kernellet image or its 48-byte command / 32-byte outcome ABI. Every receipt, table and JSON names it so (system, subject). It supports a claim about ComputeDriven's scheduling policy and residency mechanism against the four native schedulers. It cannot support a claim that the shipped no_std floor beats anyone on transition price or footprint.

That second claim is a second campaign with its own contract, fcb-kernellet-cost-contract.md: the real cd-kernellet ELF built from the reviewed source, driven through its own ABI and census path, against semantically equivalent transition loops that pass the same witness battery. No code exists for it until Codex has reviewed the contract. No single winner claim combines the two campaigns.

Open in the interactive atlas