Retire the batch-fed witness-cost materialization at the root: three writers and two census rows

[briansrls]

X of the R/X pair (operator ruling, 2026-08-22).

What is deleted

write_witness_row_cost_receipt, write_witness_row_cost_drift_receipt_at, and write_witness_row_cost_migration_disclosure_receipt_at all projected one field — ClaimResult.witness_row_costs — populated at exactly one site on the discovery/batch path the floor cut removed. Required CI never reached any of them: required_floor_mode returns before run_walk. Their only remaining production reachability was run_perturb_check and the ordinary run() fall-through, and the TSV they wrote has zero programmatic consumers anywhere in the tree.

This is a declared capability removal, not dead-code cleanup

Those two modes lose an output they could still produce. It is admitted because retaining the writers would leave WitnessRowCost/BatchRecord standing as a second semantic representation of witness cost beside std.observation ObservationEvent — which gunbc.witness_row_cost already rules is the record, not a TSV schema. That is the §3 parallel-authority state, waiting for the two to disagree about clock treatment or unavailable-vs-zero.

What the delete-first census surfaced

Two of the three writers’ print markers were enrolled in gunbc.observation_emit_census as CountedFrontierSite rows. Deleting the emits deletes the rows, so observation_emit_frontier_count shrinks by exactly two — monotonically toward the zero its expected-red acceptance test waits for. Precedent is recorded in that same census: gate-warm-cost and witness-row-cost-drift rows went the same way when their emits did.

And one thing the census caught that I had wrong. I first cut the shared basis parser and witness_row_cost_verdict_via_authority along with the writers, assuming they were materialization-only. They are not — write_compile_clean_cost_drift_receipt_at shares them wholesale (same basis schema, same parser, same 2× authority) and is a live, separate capability. cargo check refused, the shared block was restored, and only genuinely batch-only code stayed deleted. That refusal is exactly what delete-first buys.

TASK #20 is dispositioned, not orphaned

It named these receipts as its reproduction evidence, and its own clause forbids silent closure. It stays OpenUnknown; what is recorded is that its evidence is now ReproductionProducerRetiredPendingEquivalentProtocol — a typed, cited refusal — with the re-binding trigger named: the required floor’s fold-native identity-grain cost receipt (R).

The frontier enumeration in the acceptance note is corrected without restating a count, because that note itself records the time its enumeration went false while the number beside it stayed right.

Verification

By execution, not inspection:

check	result
cargo build --release -p v1-compiler --bin claim_executor --bin gunbc	exit 0 — CI's literal build command, which denies warnings
control cargo check -Z definitely-not-a-real-flag	exit 101 — proves a real compiler was reached
cargo fmt --all --check (pre-commit + pre-push)	clean

Net: −771 / +8 lines.

Why this table changed. It previously listed only cargo check runs. That was not CI's build: the release build denies warnings and cargo check did not, so an unused-parameter warning left by this PR's deletion passed locally and turned CI red. The row above is now the exact command CI runs. Recorded rather than swapped, because "verified locally" against a weaker command than the gate is the failure, not the warning itself.

The .dag half (census rows, witness assertions, acceptance note, TASK #20) is verified by CI, which I cannot run locally.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PgpEN2jnUGsLhM5vRKH6fD

[gunbai-bot]

Fixed in e1ef1bff. review 54784 is correct and the finding is a real defect, not a wording preference.

Verified against this head before fixing: witness_row_costs is declared (claim_executor.rs:1837), populated (:4309), and consumed by two live capabilities — emit_slowest_witness_attribution (:3868) and write_floor_wet_witness_row_outcome_receipt_at (:6081). My disposition clause said the field was removed. It was not.

On the two offered repairs, I took the second. Deleting the field would remove those two capabilities, and X was admitted to remove the batch-fed witness-cost materialization — not every consumer of the row type. Widening the deletion to make my sentence true would be repairing prose by breaking code. So the sentence changed.

The corrected clause names what was actually removed (three writers, their support helpers and tests, and the two observation_emit_census rows their markers occupied) and states that the field survives, naming both consumers so the next reader can check the claim rather than trust it. I also dropped "one field" from the PR title, which carried the same overstatement.

I recorded the false version in place rather than swapping it silently. It is the precise premise-contamination class DESIGN forbids — a session reading it would have planned against a deleted field and found it populated — and it is worth the extra sentence because I wrote it on a day spent correcting that same class in other carriers. The earlier APPROVE on this PR had even noted the field intentionally survives; I did not reconcile that against my own prose.

No code changed by the fix commit. cargo check --bin claim_executor --profile test remains exit 0 on this head.

— sent from fierce-hawk-734

[gunbai-bot]

Pushed a repair that post-dates the approvals on this PR, so flagging it rather than letting it ride.

Two of the deletions in this PR were taken by line range, and two of those ranges ended inside a doc comment whose function survived. The fragment then re-attached to the next function and described it falsely:

• walk_attempt_id_segment_is_safe lost its own §7 SCAFFOLD block — the one naming std.types path_segment_is_safe as the single law for "safe as ONE path segment", with its dissolve-on — and inherited the deleted drift writers prose in its place.
• batch_is_wet gained 40 lines about MeasuredUnavailable and observation_measured_note. On main it carries no doc comment at all.

Restored the first from main and removed the second. I then swept every surviving top-level fn in the file, comparing its preceding doc block against origin/main: zero differences. So this is the class closed, not two instances patched.

The first was caught by my side chat, not by me — worth naming, because a deletion that eats adjacent authority prose leaves the code compiling and the annotation lying, which is exactly the §4c state no Accepted program can detect.

— sent from fierce-hawk-734

[gunbai-bot]

Two more repairs pushed (7283ff4583), both from the side chat's review. Naming them because the approvals — including the most recent one — predate both, and the most recent approval specifically reads the acceptance note as already clean.

X-2 — a stale count recital, missed by name-level reading. The acceptance note's closing paragraph still said the census suite asserts == 8, a fact about today. Both halves had gone false: this PR removed the frontier assertions from observation_emit_census_witness_test (it now asserts roster membership, dissolve-on presence, and bidirectional classification — no count), and the population moved when the two batch-fed sites retired.

Worth stating plainly, since a review here concluded the opposite: the note's earlier paragraph was corrected without restating a count, and that is what a reader checking the correction sees. The recital sat further down, in the paragraph explaining why this row exists separately from the census suite. Same file, same data row, different claim. I deleted it rather than re-pinning it to six — observation_emit_frontier_count folds the roster and is the only authority for how many there are, so reciting another file's assertion was a second, positional naming of something that file already states.

That makes it the mirror of the failure this same row already records one paragraph up: there, an enumeration went false while the count beside it stayed correct; here, a count outlived both its population and the assertion it attributed elsewhere. A count-based check cannot catch either.

X-3 — the migration policy needed a disposition, not silence. witness_row_cost_migration_threshold_ms and witness_row_cost_migration_verdict lost their last non-test consumer when the migration-disclosure writer was deleted. They are not inert: witness_row_cost_migration_disclosure_witness_test still calls both and pins the threshold at 500, exercising the verdict on either side of it. So this is test-only policy, not dead code — deleting it would be reachability read as occupancy, removing a live wall because nothing production-side currently lands in it.

Declared RetainedPurePolicyPendingRequiredFloorProjection, with the required floor's fold-native identity-grain cost receipt named as the next consumer (the same construction task #20 names as its re-binding trigger) and a two-armed dissolve-on: the projection consumes them, or it is shown to need a different judgment and they retire with their witness. The retirement this PR was admitted to make was of the Rust realization; the judgment it realized is a separate fact and I did not take it.

Verification is weaker than I would like and I am labelling it rather than rounding up: these are prose-only .dag edits, compile.frontend and compile.normalize both completed — the parse stage a prose edit can actually break — before the run was OOM-killed at a later stage under host load 27. No new string escapes.

— sent from fierce-hawk-734

[gunbai-bot]

Addressed review 54810 (f433d6c01d). Two of the three findings were real and are fixed. The third does not hold, and checking it turned up a defect in this PR that the requested fix would have cemented.

The one that inverts

[witness-row-cost] is still live in the seed. A production eprintln!("[witness-row-cost] refused: {msg}") survives in discovery_claim_result, reached from five non-test call sites. Only [witness-row-cost-migration-disclosure] and [witness-row-cost-drift] are actually gone.

So the premise that "the two witness-row-cost* markers no longer exist in the seed" is false for one of the two, and removing witness_row_cost_site from the roster was itself the defect — it broke the bidirectional rule the census states one sentence above the recital: a live tag family absent from the roster. Editing the notes to agree with the roster would have made the prose consistent with a wrong roster.

Restored the row and the bidirectional assertion. The row carries a rewritten reason rather than the old one, because what emits under that tag genuinely changed: the per-witness TSV join projection is deleted, and what survives is the refusal line. Same tag, different population.

Executed evidence, discriminating pair:

real marker    → w_post_snapshot_live_tags_are_rostered_bidirectional = true
bogus marker   → false

The negative ran against a throwaway copy of dag/ (the source root must sit under the workspace root, so it lived inside the worktree briefly); the copy is removed and git status is clean of it. The witness visibly reads claim_executor.rs, so this is the file being read, not a roster self-agreement.

The two that hold, fixed

• observation_emit_roster_completeness_note — the Frontier count = 8 recital plus enumeration is deleted, not re-pinned to six. observation_emit_frontier_count folds the roster and is the only authority for how many there are.
• observation_emit_census_sequencing_note — [witness-row-cost] no longer listed as post-census growth alongside the retired siblings; each now carries the date its emit went.
• w_post_snapshot_live_tags_are_rostered_bidirectional_note — corrected, and it now records why this one matters more than the other two.

One more, found while verifying

Both the completeness note and the acceptance note listed selection-degradation as a frontier family. It has no emit in the seed and has never been on the roster. So the enumeration was carrying a family that does not exist beside a count computed from families that do — the two errors partially cancelled, which is why neither showed.

What I would take from this

The removal was reviewed, the review agreed the marker was gone, and nothing would have caught it: the hand-maintained conjunction covering that tag was deleted in the same diff. A conjunction cannot object to its own deletion — removing an assertion and removing the fact it protected are the same diff shape. That is the durable argument for the source-level marker census the witness note already names as its own residue: a check that DISCOVERS markers in the seed and joins them against the roster would have refused this edit without anyone remembering the tag.

Frontier rows on the roster now: 6, and the enumerations name exactly those six.

— sent from fierce-hawk-734