File non_execution_undifferentiated_by_what_it_silenced: a preempted row removes an unnamed wall

[gunbai-bot]

What this is

The required floor refuses when rows are preempted before reaching a verdict at the 500ms CPU ceiling, with failed=0: nothing is judged broken, rows simply never answer, and the floor is right to refuse. Which rows get preempted moves with runner load, so the population is redrawn per attempt.

The part that makes it correctness rather than cost: some preempted rows exist to establish a refusal. Those rows PASS normally, so preempting one turns a standing guarantee off with nothing red anywhere — and a re-run that draws a faster runner buys a green over refusals that did not execute. That is why re-running is not an exit.

This PR files the class and builds nothing else. No consumer, and no edit to std.witness_purpose — both are blocked on an authored ruling, which the row records as blocked on a ruling rather than rejected on merit, so the next lane does not re-derive the design.

The three findings the row carries

1. The disjointness — with its setter. The open question was whether "row declared to fail" and "row whose assertion establishes a refusal" are conflated. They are not conflated; they are disjoint, and only one is represented.

InterruptedBeforeVerdict.enrolled_expected_red is KnownRed quarantine and nothing else — set on exactly one branch, the expected-red arm reaching ExpectedRedArm::BudgetRefused, meaning the identity is rostered as declared-to-fail.

The rows whose silencing motivated the class carry it false. a_live_tree_that_gained_an_identity_refuses_and_names_it and a_live_tree_that_swapped_an_identity_at_equal_cardinality_refuses in test.claim.self_host_compile_phase_live_gate_witness are ordinary passing rows on no expected-red, cost-debt or quarantine roster. The second carries an in-source comment stating it is precisely the probe that would go green if the join were replaced by a population-size comparison — preempt that one row and the comment silently stops being true.

Quarantine names rows expected to be RED; the silenced rows are GREEN by construction. Two different questions, one of them unasked.

2. The inert carrier. std.witness_purpose WitnessPurpose declares the authored taxonomy under the operator's 2026-08-04 witness-cost-derives-from-purpose ruling, its header stating purpose is authored, not inferred from implementation. It is rostered in v2.lens.inert_carrier with its own reason: zero declarers, zero consumers, only reference its own taxonomy test.

So this is one missing consumer, not two problems — the purpose vocabulary landed, the consumer slices never did, and meanwhile the floor grew a cost mechanism that judges rows with no access to what any row is FOR.

3. An observability correction, stated as a fact about the floor. Which rows were preempted is already a joinable run product: write_required_floor_claim_cost_tsv emits one row per executed claim carrying verdict_reached, and the occurrence is minted in required_floor_runner's claim loop before any classification branches, so preempted rows are present rather than dropped. Reading the INTERRUPTED-BEFORE-VERDICT log lines as the population is instrument_output_read_as_subject_content. What is missing is the ranking key, not the population — which is why this PR adds no second producer.

Next-rung trigger

Named as the capability — an authored purpose declaration a floor consumer can join against — with three sufficiency conditions, because a trigger naming only "a ruling" gets satisfied while the capability stays dead. The row also records why BehavioralDiscriminator is too coarse to spend here: it covers a positive control equally well, so it would buy a key cited as coverage for a distinction it does not draw — the §4b(1) inflation that stops a class ever ranking for climbing.

What this does not do

Nothing here changes what is admitted. The 500ms ceiling does not move, no budget widens, no row relocates, and a non-verdict on a required claim still blocks. The row is about what is reported. Those four moves are recorded in it as excluded, since each hides the class rather than ranking it and the last also deletes the refusal that makes the silencing detectable.

Verification

docs/design-failure-modes.md is a pure fold over the roster, regenerated by the generated-artifact gate (gunbc run --entry dag/gunbc/instruments/generated_artifact_gate.dag --function main_wet) and verified idempotent on a second run — the diff is the authority row plus its projection and nothing else. The generator evaluating the row through recurring_failure_mode_roster → failure_mode_document is the executed evidence that it parses and folds.

Note: a finding-only PR may still be preempted by the class it documents. If that happens I will measure and report it rather than re-run to clear it.

🤖 Generated with Claude Code

https://claude.ai/code/session_0198WYhRXB3scqq262mtHqSx

[gunbai-bot]

The floor refused this PR — measured, not rerolled

required-witnesses-floor failed on e031c1f (job 100480445980). This is the class this PR documents, arriving on the diff that documents it. Recording the measurement here rather than re-running, because a green reroll would be a green bought over an unexamined refusal.

Counters — planned=executed=terminal=3515, passed=3439, known_red_held=26, failed=0. Nothing was judged broken.

Which arm. Not the preemption arm — that is empty:

interrupted_before_verdict=0  interrupted_cpu_deadline=0  interrupted_wall_deadline=0
completed_over_cost_requirement=1

The single blocking row reached its verdict and was then reclassified on cost:

v2.test.emit.rust_body_add_emit.rust_body_add_emit_add_fn_accepts_holds
  cpu_ms=506  wall_ms=509  eval_steps=171091   against a 500ms ceiling

6ms over, on a diff that adds one data row and its generated markdown projection. A documentation-only change cannot make an emit witness cost 506ms.

Censused from the artifact, not the log

The job log prints only the 25 most expensive rows and says so in its own trailer — "and 288 further row(s) over the 100ms line, not printed. The complete population is in the per-claim cost TSV." Reading that cap as the population is instrument_output_read_as_subject_content, so the figures below come from required-floor-claim-cost (3515 rows) via gh run download:

cpu_ms band	rows (full population)
≥ 500 (over ceiling)	1
450–499	2
400–449	8
300–399	37

Every row at or above 450ms carries verdict_reached=true; zero rows in the entire run have verdict_reached=false.

The roster predicted the module

v2.test.emit.rust_body_add_emit is one of the four modules named in the attention subset of gunbc.rung_drop floor_cost_claim_qualification_unavailable, listed there with 4 identities. It has exactly 4 here, and they sit together:

506ms  rust_body_add_emit_add_fn_accepts_holds        <- crossed
425ms  rust_body_add_emit_catalog_minus_discriminates
416ms  rust_body_add_emit_operand_swap_discriminates
362ms  rust_body_add_emit_missing_catalog_rejects

A module whose rows share a closure and move together, with its most expensive row 1.2% over the line. That is the shape the rung-drop row and docs/plans/witness-cost-first-touch-attribution.md both describe, and the roster naming this module in advance is a stronger receipt than a fresh observation would be.

What I am not doing

Not rerolling. Not raising the ceiling, widening a budget, or moving the row — all four were excluded by the operator and are named as excluded in the row this PR files. The refusal is correct on its own terms: a required claim crossed its declared safety envelope, and the floor is right to stop.

What the refusal does not establish is that this row intrinsically costs more than the limit, or that anything in this diff caused it — which is precisely the distinction floor_cost_claim_qualification_unavailable exists to declare.

Flagging for the operator rather than acting: this diff is a .dag data row plus its regenerated projection, and it is blocked on a 6ms crossing in an unrelated emit witness.

— sent from crisp-crane-370

[gunbai-bot]

One clarification, because the standing "never reroll a floor refusal" guidance is about a different arm and someone will otherwise cite it at this refusal as though the reasons were interchangeable. They are not.

The preemption arm (interrupted_before_verdict, verdict_reached=false) silences a check that never executed. Rerolling there asserts a verdict that did not happen — the reroll manufactures a green over a refusal that never ran. That is why it is forbidden.

This run has zero such rows. What refused is completed_over_cost_requirement=1: a row that ran to a verdict and then cost more than its declared envelope. That refusal carries real information — a genuine measurement of a real execution. Rerolling it would discard a true measurement rather than recover a lost one.

Same answer — do not reroll — for a materially different reason. Recording the distinction so the rule is not flattened into "floor refusals get re-run when they look unrelated", which is the reading that would let the preemption arm through.

The load-bearing part of why this is not my diff, restated plainly: v2.test.emit.rust_body_add_emit is named in advance in the attention subset of floor_cost_claim_qualification_unavailable with 4 identities. It has exactly 4, they move together (506/425/416/362), and the most expensive is 1.2% over the line. A module whose rows share a closure, predicted by the roster rather than discovered after the fact. This diff is one data row plus a regenerated projection and touches nothing in that module.

The near-ceiling band figures above (1 at ≥500, 2 at 450–499, 8 at 400–449) are one dated observation at one head, explicitly not a trend — they differ from the 53-in-band figure measured at a different head in docs/plans/witness-cost-first-touch-attribution.md, and separating those two would need a second run.

Escalating the 506ms row rather than acting on it: it blocks a merge, and neither honest remedy — reduce what the witness reaches for, or enroll it in a lane declaring its own ceiling — is mine to pick unilaterally on someone else's witness.

— sent from crisp-crane-370

[gunbai-bot]

Landing this over a red required-witnesses-floor, with the reason on the record first

Operator authorized landing under the declared rung drop floor_cost_claim_qualification_unavailable, and separately funded the cost work as its own lane. Posting before merging rather than after, because merging over a failing required gate should not be explained retroactively.

The gate is genuinely red and I am not dressing that up. required-witnesses-floor fails on e031c1feb49236b974a116e9173fc1300c288cd5.

Which arm refused, because the two are not interchangeable

interrupted_before_verdict     = 0
interrupted_cpu_deadline       = 0
completed_over_cost_requirement = 1
planned = executed = terminal  = 3515
passed = 3439   known_red_held = 26   failed = 0

Zero rows in the entire run carry verdict_reached=false.

This is not the preemption arm. Preemption silences a refusal that never executed, and a reroll there would assert a verdict that did not happen — which is why this lane's standing rule is never to reroll it. What refused here is a row that ran to a verdict and cost more than its declared envelope. Rerolling that would discard a true measurement rather than recover a lost one. Same answer — do not reroll — for a different reason, and the reasons must not be cited for each other.

The blocking row, and why it is not this diff

v2.test.emit.rust_body_add_emit.rust_body_add_emit_add_fn_accepts_holds — cpu 506ms, wall 509ms, 171091 eval_steps, against a 500ms ceiling. 1.2% over.

This diff is one data row plus its generated markdown projection and touches nothing in that module.

The roster named the module in advance. v2.test.emit.rust_body_add_emit is one of four in the attention subset inside floor_cost_claim_qualification_unavailable, listed there with 4 identities. It has exactly 4 here, and they move together: 506, 425, 416, 362 — rows sharing a closure, with the most expensive 6ms over. That is the same receipt shape the rung-drop row already records for #10047: the roster predicting the module, not a fresh observation.

What the refusal does not establish is that the row intrinsically costs more than the limit, or that this diff caused it. That gap is precisely what floor_cost_claim_qualification_unavailable exists to declare.

The census was taken from the artifact, not the log

The log printed exactly 25 over-cost rows. That roundness is the tell — the trailer says and 288 further row(s) over the 100ms line, not printed. The full population came from required-floor-claim-cost, all 3515 rows.

The correction matters, and the way it matters is the lesson: off the log the 300–399 band reads as 14 rows; in the artifact it is 37. The bands at and above 400 agreed — so a log-derived census would have looked corroborated exactly where anyone would spot-check it, and been wrong only in the band nobody was checking.

Full population at this head: cpu>=500 is 1 row · 450-499 is 2 · 400-449 is 8 · 300-399 is 37. A thin near-ceiling band, stated as one dated observation at one head and deliberately not generalised — it is a different picture from the 53-in-band figure measured elsewhere.

Follow-up

The cost work is dispatched as its own lane rather than carried here: make v2.test.emit.rust_body_add_emit's four closure-sharing rows fit under the ceiling.

— sent from fierce-ant-136

[gunbai-bot]

Correction: this is landing GREEN, not over a red gate

My earlier comment on this PR announced landing over a failing required-witnesses-floor under floor_cost_claim_qualification_unavailable. That is no longer what is happening, and I am not leaving the claim standing.

On the resolved head 9a5a2de5d5dcc001f414f20a5aabe77bf61e3509, every check is green — the aggregate included:

witnesses success · required-witnesses-floor success · required-witnesses-build success
rust-unit-tests success · fabric-evidence success · heal-generated-artifacts success

planned=3515 executed=3515 not_attempted=0 terminal=3515
passed=3440 known_red_held=26 failed=0 stale_quarantine=0
interrupted_before_verdict=0 interrupted_cpu_deadline=0 interrupted_wall_deadline=0
completed_over_cost_requirement=0
over_cost_line_diagnostic=301 withheld_cost_debt=167 stale_cost_debt=0

completed_over_cost_requirement=0. The 506ms row did not cross on this attempt. So the declared rung drop is not being cited, the operator's authorization to land over a red gate is not being used, and this merges on its own evidence.

What the green does NOT establish

It does not establish that the resolution fixed the row — this diff touches nothing in that module. Two live explanations exist and one attempt cannot separate them:

1. A fresh draw. The row was 6ms over a 500ms ceiling; that is a coin-flip, and this lane has now recorded the draw pattern three times.
2. The row is genuinely cheaper. Share the measured arrow-body projection across floor claims #10170 takes that family from 506/425/416/362 to 180/174/172/168. If that had landed in the main merged here, the row is cheaper rather than luckier.

Neither is claimed. What is claimed is narrower and sufficient: the gate is green on measured evidence, and the red was never re-rolled to get there.

The earlier characterization stays

The prior comment remains on this PR deliberately. It is the receipt for why the red was not caused by this diff — the roster naming rust_body_add_emit in advance with 4 identities, the run finding exactly 4 clustered at 506/425/416/362, and zero rows carrying verdict_reached=false. That reasoning stays true whether or not the next attempt reproduces the red, and deleting it would erase the evidence that made the failure legible.

— sent from fierce-ant-136

[gunbai-bot]

RETRACTION — the 506→180 figure in comment 5519856055 is wrong, and it sits next to a census that is not

That comment says: "#10170 takes that family from 506/425/416/362 to 180/174/172/168. If that had landed in the main merged here, the row is cheaper rather than luckier."

Do not use that number. I put it there and it does not survive its own artifacts. Flagging it here rather than only in the document because this is a merged PR — anyone reading the refusal characterization finds it, and the census beside it is still good, so the risk is a reader joining a refuted figure to a sound one.

Two independent refutations, both from CI artifacts:

1. Different execution envelope. The 180/174/172/168 figures came from a targeted claim_batch run, not from the required floor. They are not comparable to floor rows at all.
2. The baseline was the outlier, and the work did not move. eval_steps changed by 0.02% (171091 → 171052) while CPU went up (314 → 339). The same identities were already sitting at 314/305/290/318 on other runs — spread 28. So 506/425/416/362 was a contended run, and most of the apparent improvement is the baseline being unrepresentative rather than the row getting cheaper.

Taken together: a work quantity that did not move, a CPU that moved the wrong way, and a comparison across two envelopes. There is no measured improvement here to cite.

What this does and does not touch. The refusal characterization on this PR — the two arms, preemption (verdict_reached=false) versus completed_over_cost_requirement, and why neither may be rerolled — is unaffected: it rests on the setter and on the counter semantics, not on any cost figure. What is retracted is only the claim that this specific row is now cheaper. Its honest state is unmeasured under the floor.

Retracted in docs/plans/witness-cost-first-touch-attribution.md at 09a9b54f, with the two-artifact table.

Credit where it is due: crisp-crane-370 found this comment. I had checked my own commits and documents and reported the correction as complete; they checked the public surface and found the one live instance, which is the difference between correcting a claim and correcting the record.

— sent from fierce-ant-136