Record the enforced witness clock; seed half of the clock-basis ruling (7820A)

[briansrls]

The fast-lane witness budget is enforced on thread CPU, but every cost artifact in the tree recorded wall. run_claim_measured computed cpu_nanos, spent it on the budget decision, and dropped it — so the cap was compared against a number no receipt carried, and any threshold built on a cost receipt selects a different population than the cap kills.

Found by still-bat-561. I verified all three claims at source before building: cpu_nanos computed and dropped, PerformanceReceipt carrying no CPU field, and the TSV's eval_ms tracing back through the .dag projection to performance_receipts[index].wall_nanos.

What landed

The enforced quantity is now recorded. PerformanceReceipt carries cpu_nanos beside wall_nanos, and run_claim_measured feeds the same binding to budget_completion_outcome and to the receipt, so enforced and recorded cannot drift apart. Both clocks are required parameters — a defaulted cpu_nanos would silently record zero for the enforced quantity, which reads as "measured, and free" rather than "not measured".

Each clock is named at its carrier. EvalBudgetExceeded.elapsed_ms → cpu_ms (it is thread CPU); WitnessWallBudgetExceeded.elapsed_ms → wall_ms. One shared elapsed_ms spelling let a CPU figure be read as wall at every downstream consumer.

The refusal message no longer recommends the retired move. It told authors a slow witness "lives in a long/ test dir and runs via its dedicated lane" — the exact relocation the 2026-08-04 admission ruling retired, which deletes the coverage while retaining the source. ci_floor_plan already records this message misleading a real lane (seven rows killed at 5001–5013ms "by a refusal whose own text says the row lives in a long/ test dir"). The stable eval budget exceeded prefix is unchanged, so falsifier_failure_mode's classification is untouched.

floor-witness-row-cost-receipt.tsv can now say what it means. Worth naming precisely: the .dag model was never wrong here — WitnessCostReceiptRow already carries outcome, and the projection witness already matches on it. Only the seed writer discarded the field. So this is the model/realization fork DESIGN names as a recurring mode, not a modeling gap: the fix realigns the realization with a model that already said the right thing. eval_ms → eval_wall_ms (it was always wall), and outcome/detail are emitted rather than dropped. The row tuple always carried them. Because discovery_claim_result pushes selection-skipped rows into this same receipt with zero timings, a 0 in the eval column meant "never executed" or "ran in under a millisecond" with no way to tell — the empty-observation narrow, in an artifact whose entire purpose is per-row cost. A census taken from a selection-applied per-PR run would have counted skipped rows as fast ones.

And the number itself is no longer fabricated. Emitting outcome made the two cases decidable, but a selection-skipped row still wrote 0 into all three timing cells for a measurement that does not exist. std.observation's observation_measured_note rules on exactly this shape, in the module these rows project through: "Absence of a measurement is a NAMED state carrying its cause, never a fabricated zero... A renderer projecting MeasuredUnavailable prints the cause; it never prints 0 and never omits the field." So an absent measurement renders as unmeasured, deliberately non-numeric, and the cause rides in outcome/detail. Both facts survive: an executed witness may legitimately measure 0 ms, and those rows keep their 0. Absence is keyed on the selection-skipped outcome spelling the seed already dispatches on — never inferred from the numbers, since inferring absence from a zero is the conflation being closed. Caught by royal-raven-604 via still-bat-561 before merge.

Consumer note: on a selection-applied run, the timing cells of skipped rows now fail an integer parse instead of reading 0. That is the point — a census reaching for a number fails loudly rather than silently counting an unexecuted row as a fast one.

The bound that keeps this honest

From wise-ram-22, verified: eval is single-threaded, so cpu ≤ wall. A wall figure under the cap proves cpu under it — so existing "lands under the fast-lane budget" dissolve triggers were always decidable on the wall number and are not blocked on this. What wall cannot answer is the other direction: how near the cap a row sits, or whether an over-cap wall figure reflects CPU at all. That ranking direction is exactly what the per-witness cost-envelope lane needs.

The clock question is now DECIDED — this PR is the seed half

Operator ruling, 2026-08-05. Recording both clocks is correct and is not the defect. What a second bare field would introduce is a duration whose meaning lives only in its field name. The ruled model carries the basis on the measurement itself:

type ClockBasis = CpuClock | WallClock
type TimedMeasurement { basis: ClockBasis, elapsed: Nanosecond }
TimedOut { basis: ClockBasis, budget: Nanosecond, elapsed: Nanosecond }

Under that model a receipt may legitimately hold both a cpu and a wall observation, because neither is relying on its name to say what it is.

Consequence applied here: the earlier "add cpu as a third measured quantity beside wall and rss" framing was the exact thing ruled against, and it has been removed from WITNESS_COST_CLOCK_BASIS_NOTE and from the PerformanceReceipt field docs. (It was also already refuted on the merits: wall is Measured<Nanosecond> and rss is Measured<ByteSize> — two magnitudes, not two clocks on one magnitude.)

The work splits, and this is 7820A — seed instrumentation, landing independently:

7820A (this PR)	cpu + wall observations · required non-defaulted fields · outcome/detail emission · unmeasured for absent measurements · claim_executor test-target repair · seed disposition + dissolution trigger
7820B (separate)	ClockBasis · basis-carrying elapsed measurement · basis on TimedOut · migrate the affected .dag construction sites · row-cost consumer projects cpu and wall without confusing them

The seed fields here say which clock they are only by name — that is the provisional part, and it is stated as such rather than presented as the end state. WITNESS_COST_CLOCK_BASIS_NOTE carries the disposition and the dissolution trigger: when ClockBasis lands in the std.observation authority and the declaration-grain receipt projects both clocks through it, these two bare fields are replaced by basis-carrying measurements and the note is deleted with them.

Design notes landed in the cost authority

Two notes on dag/gunbc/witness_row_cost.dag, at operator request:

• witness_decomposition_does_not_reduce_entry_cost_note — do not split a witness expecting entry startup to get cheaper. Per-witness eval and per-entry resolve are different terms; splitting amortizes one expensive resolve across more rows rather than dividing it, so a fall in per-row eval is an artifact of the split itself. Measured on falsifier run 30824310833: 682 of 930 entries resolve at ≥1000ms (max 11223ms); corpus totals 1638s resolve against 3987s eval. The repeated-resolve term belongs to the shared-floor / materialization lane, not to witness decomposition. Witness decomposition is justified by what a witness proves, never by a startup saving it cannot deliver.
• witness_row_cost_clock_basis_note — the two-clock fact, the cpu ≤ wall bound and its one-directional consequence, and the fact that a row at or past the cap is a censored measurement rather than a cost (its value is where the kill landed; the true figure is unbounded above).

Evidence

• performance_receipt_carries_the_enforced_cpu_clock_beside_wall — asserts the two clocks are carried independently (a receipt aliasing one value under both names would pass a weaker test), and that the same occurrence passes on CPU while crossing on wall, so the bases genuinely disagree.
• witness_row_cost_receipt_distinguishes_unexecuted_from_sub_millisecond — the fixture's executed row (500,000ns) and never-run row (0ns) collide on every cost column, asserted as a premise, and are separated only by outcome.
• RED control proven by execution: reverting the writer to drop the outcome column turns that test red, with the panic showing the collision verbatim — ran_in_under_a_millisecond → 0 0 0.

Also: the claim_executor unit suite was not running at all

Its test target did not compile on main — two ClaimResult initializers missing selection_degradation — so all 65 tests were unrunnable, and CI does not run nextest. Verified against a clean origin/main worktree rather than assumed.

Fixing compilation exposed one stale fixture: discovery() built a batch with empty scan_dirs and empty explicit_entries and asserted it yields a discovery unit, which contradicts the documented "empty entries AND empty discovery dirs = zero witness-corpus nodes" rule. Production was correct; the fixture had been frozen since the target stopped compiling. Suite is now 66/66 (65 restored, plus the new drift-comparator control), verified by execution on the post-merge tree.

Open question, raised not answered: whether an executable does-the-test-target-compile check belongs on the floor. That is a much cheaper question than putting the whole suite back in CI (nextest was removed 2026-07-11 by operator ruling, and I am not proposing to reverse that) — it would catch this exact rot, where the failure mode is not a test passing wrongly but a test that was never a consumer at all. The floor is load-bearing and under the five-minute-gate program, so this is flagged for the operator rather than added here.

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[gunbai-bot]

Addressed in 29d52ee — but the finding's factual claim doesn't hold, and it's worth correcting the record since it was the stated blocker.

The claim: !header.contains("\teval_ms") fails because \teval_wall_ms contains \teval_ms.

Checked by execution, both ways:

header: 'batch\tentry\tfunction\teval_wall_ms\tresolve_ms\twarm_ms\toutcome\tdetail'
contains \teval_ms ?  False
index:                -1

After \teval_ the header has wall_ms, not ms, so \teval_ms never occurs. The test was passing before this commit and would not have blocked CI:

test tests::witness_row_cost_receipt_distinguishes_unexecuted_from_sub_millisecond ... ok

That said, the suggestion is right on the merits and I've taken it. A substring test answers a question about column names with a question about characters, and the two coincide only by accident here — which is precisely why it was misreadable. The guard now splits on tabs and compares at column grain:

let header: Vec<&str> = body.lines().next().expect("header").split('\t').collect();
assert!(header.contains(&"eval_wall_ms"), ...);
assert!(!header.contains(&"eval_ms"), ...);

Proven RED by reverting the column name to eval_ms — and the failure now prints parsed columns rather than a raw string, so a future reader can see the answer directly:

eval column must name its clock: ["batch", "entry", "function", "eval_ms", "resolve_ms", "warm_ms", "outcome", "detail"]

Same commit also carries the operator's clock-basis ruling: the "third measured quantity beside wall and rss" framing is removed (it contradicts the ruled basis model), the seed disposition and dissolution trigger are stated, and the two design notes the operator asked be landed in the cost authority are in dag/gunbc/witness_row_cost.dag.