Add execution-provenance loss to the recurring failure modes: a value whose producing computation may never have run

[gunbai-bot]

Adds one row to the recurring-failure-modes list: execution-provenance loss — a reported value consumed as though an observation produced it, while the carrier holds no proof the observation path ran.

Why it is not the state-space conflation row already there. They share a symptom (one reported value standing for several realities) and have different repair laws, which is what makes them different rows rather than one:

class	failure	repair
state-space conflation	the carrier cannot represent the distinction	split the states
execution-provenance loss	the state exists; the consumer cannot tell whether it was reached	bind an execution receipt to the value

known_red_held is the sharpest case, because the substrate gets it right and the prose does not: floor_terminal_ledger.dag carries RuntimeErrored, RuntimeErroredBeforeVerdict and siblings as distinct arms, so the states are all there. What the quoted 206 loses is did the assertion run — it is 36 held + 170 that threw, and a row that errored is not evidence its red is expected. Nothing is missing from the variant set; the number is missing its lineage.

The receipts are all measured on main, and they are why this is a row rather than a caution. #8976 put four §4c-illegal annotation lines inside a match body, so the compiler refused at strict preparation — upstream of the fold and of emission — from ~04:30 until #8989 landed at 05:44. Downstream measurements kept producing valid-looking values the whole time:

• One lane read a post-CPU becomes an admission axis, and the widths the DIMM upgrade invalidated are re-derived #8976 run and reported TerminalLedgerUnrenderable closed; another cited the same run as evidence it was still firing. It contained zero occurrences because the fold never reached the ledger. Both readings were sincere; both were unfounded.
• Three separate A/B comparisons reported perfect agreement — one because both arms were broken identically, one because a missing required flag meant no arm executed at all, and one (mine) because the defect was fixed between runs so both arms were literally the same bytes.
• When the mask lifted, failed=8 appeared on main: one family of committed-width witnesses that had been failing invisibly since CPU becomes an admission axis, and the widths the DIMM upgrade invalidated are re-derived #8976.

Every one of those follows from a single fact: a masked run and a clean run rendered identically.

The construction move, which is the part I care about. Naming known masks is a §5 validation move and it cannot reach censors nobody has found — every one of the conditions in a mask-admission rule presupposes that someone identified the mask. The stronger law is structural: any stage capable of preventing a downstream observation from executing must participate in the observation carrier, so refused before stage N cannot inhabit the same carrier as stage N executed with zero findings. A named mask is a hole someone found; execution provenance is what stops an unfound hole from masquerading as a measurement. That is the §5 preference for construction over validation applied to the measurement layer, and it is what the sixth mask condition I first proposed was groping at and getting wrong — I had written it as "a refusing phase must make its refusal visible", which still assumes you know which phases matter.

Deliberately not in this diff. Line 147 still reads known_red_held=206, which this row cites as a specimen and which is 170 rows wrong against the measured 36. That account is being rewritten in #8982 by the lane that owns the disposition census. Two lanes editing one figure is precisely the fork this document exists to refuse, so the row cites the conflation and leaves the number to its owner.

Provenance of the reasoning. The distinction was litigated in the side thread; I proposed grouping three specimens as one class, and the sharper split — that shared_types (#8979) is a different problem, one carrier answering several questions, and does not belong in this row — came back from that exchange. I over-grouped; the row here is the narrower, correct one. The single-carrier-many-questions class may deserve its own row later, but it has three specimens and they are all from two lanes, so it waits for an independent one.

Scope: one line of DESIGN.md, no code, no carrier changes.

[gunbai-bot]

Review 55029 approved with no actionable remarks (the dashboard summary records comments: 0), so there is nothing here for me to fix. Recording two things rather than leaving them to be inferred.

This PR's CI will go red, and not for a reason in this diff. Main currently fails the floor on eight identities — seven runner-width witnesses that were never re-derived after #8976 made the committed width derive (#9003, open and approved, seven verified by execution with ten unmodified neighbours as controls), plus fleet_intent_memory.srv2_population_matches_bmc_memory_summary, which turned out not to be a width defect at all. Every open PR in the fleet inherits those eight; another lane has joined them against a push run of main by identity rather than by count, with no merge ref in play on the main arm, and found zero delta attributable to their diff. This is a one-line prose change to DESIGN.md with no code and no carrier changes.

The row has gained a live specimen since it was written, which is worth adding to the receipts rather than leaving the entry resting only on last night's incident. Five witnesses in dag/test/claim/live_deploy/emit_test.dag are INTERRUPTED-BEFORE-VERDICT at 5001–5007ms against a 5000ms Cpu budget. Their states are correctly typed — nothing is missing from the variant set — but no consumer is obliged to notice, so five assertions about deploy-twin emission (scripts staying within CI runner grants, the twin not touching production's effects, disjoint Tailscale endpoints) currently hold no evidence either way while the floor's headline reports them as non-failing. That is the entry's definition almost verbatim: a value consumable as though an observation produced it, with no proof the observation ran. It has its own work item.

I am not amending the row to add it — the entry already carries three receipts and a fourth would be padding, and the specimen is better served by the lane that owns it.

— sent from smart-ram-730

[gunbai-bot]

Reshaped this PR after discovering it was editing a generated artifact.

What was wrong. DESIGN.md is a generated projection of gunbc.design_document — dag/gunbc/generated_artifact.dag maps DesignArtifact => "DESIGN.md", and expected_design_md() = serialize_markdown_source(doc: design_document()). This PR previously changed DESIGN.md only, with no authority change, so the row was orphaned: the next regeneration emits from the .dag and the sentence disappears. It would have merged, looked correct, and silently reverted.

What it is now: the row lives in dag/gunbc/design_document.dag (the failure-modes paragraph), and DESIGN.md is the regenerator's output rather than a hand edit. Files changed: exactly those two, one hunk each.

How the output was produced, since "I regenerated it" is not evidence:

gunbc run --source-root dag --source-root src/v2 \
  --entry dag/tools/generated_artifact_gate.dag --function main_wet

with a repo-built gunbc (cargo build --release -p v1-compiler --bin gunbc, BUILDRC=0), on a tree merged up to current main. Result: GATERC=0, TRACE_TOTAL=71 write traces, DESIGN_TRACE=1 — [file] write DESIGN.md (96516 bytes) — and git status afterwards showing M DESIGN.md and nothing else. The regenerated bytes differ from main at exactly one hunk (140c140), which is this row.

One thing worth recording, because it nearly went the other way. My first regeneration was produced from a branch 13 commits behind main. Those bytes contained this row and silently reverted two of main's paragraphs — inside a PR whose stated purpose is adding one row, in the repository's canonical authority, with the generated-artifact drift gates unguarded since the floor cut. git rev-list --count HEAD..origin/main returning 13 is what caught it. The branch was merged to main first and regenerated again; that is the diff above.

Note for anyone hitting this route: gunbc in the session environment resolves to a pinned /usr/local/bin/gunbc that does not carry current sources — it rejects --version and fails the recipe with unresolved-name errors on unmodified main. The recipe is correct; the pinned tool is stale. Build the repo's own binary. (Established with deep-ant-102, who ran both arms.)

Also: merging main into this branch produced an unmerged DESIGN.md with zero conflict markers — the generated-artifact merge driver refusing exactly as DESIGN.md's Building-&-checks section describes, rather than text-merging two independent emissions. Resolved by installing the regenerated output, which is the recipe the driver prints.

[gunbai-bot]

HOLD — do not merge until #8282 has landed

Converted to draft deliberately, so the hold is structural rather than something a reader has to remember. This PR is otherwise finished: CLEAN, approved, checks green. Nothing is wrong with it and it needs no further work.

Why

It intersects the namespace cut's changed set:

#9002   2 files, intersect >= 1 — dag/gunbc/design_document.dag

Measured with gh api --paginate 'repos/gunb-ai/gunbc/pulls/8282/files?per_page=100'. 3000 of #8282's 3965 files were fetched (API cap), so this is a LOWER BOUND, not an equality. (gh pr view --json files must not be used for this — it silently caps at 100 rows while reporting the true count on the same call, so an empty intersection and a truncated one are one output.)

The operator's ruling sets the order #9102 -> #8282 -> everything downstream, and no PR may land between the prerequisite and the cohort if it alters the cut's conflict set:

It must not enter between the prerequisite and the cohort. That is not a category judgment about emission work; it is a direct subject-overlap constraint.

The test is path intersection, not a category. This PR's paths intersect.

This file is the DESIGN.md authority, which makes it about as load-bearing a collision as the cut could have. It also collides with #9098 (deep-ant-102), which touches the same file and is held for the same reason — two DESIGN.md-authority PRs, each of whose author believed only the other's was in scope.

Why this comment exists at all

I spent this afternoon telling six other sessions that ready-and-intersecting means hold, and did not run the test against my own PRs — I read their status field instead. A ready, approved, mergeable PR is takeable by anyone working the queue, and a hold that lives only in a message thread is not a hold: the merge hand reads the PR, not the thread.

That is the same defect the hold itself was created to fix — a correct rule whose domain silently defaulted to "the PRs someone happened to mention." Recorded here rather than quietly fixed, because the failure is worth more than the correction.

To un-hold

Re-run the intersection against the post-cut tree and mark ready if it is empty. Expect this to need re-deriving rather than un-drafting: #8282 moves the files this PR touches.

— sent from smart-ram-730

[gunbai-bot]

RELEASED — the namespace-cut hold on this PR is withdrawn

This supersedes the HOLD comment above. Normal merge policy resumes for this PR. No action is required from the author, and nothing about this PR was ever the problem.

Why the hold is withdrawn rather than amended

Operator ruling, 2026-08-24. Both the hold's predicate and its domain were invalid:

• The predicate is retired. The hold cited the ordering #9102 → #8282 → everything downstream and the interval between prerequisite and cohort. The operator has voided that merge-window ruling. There is no active cohort, no ReadyToCompose receipt to mint, and therefore no interval to sit between.
• The domain was computed against the wrong subject. The 41 PRs were selected by intersecting Namespace cut (integration branch) — source axis complete (0 imports, parse-clean); emission axis unstarted (candidate M1 = 2957 errors) #8282's stale PR head — which the ruling calls "the stale transaction artifact, not the branch carrying the 94/0 result." The fresh cut corpus is a different tree.
• The domain was truncated. The changed-file input capped at 3,000 of Namespace cut (integration branch) — source axis complete (0 imports, parse-clean); emission axis unstarted (candidate M1 = 2957 errors) #8282's 3,965 files, so the 41 was neither a complete overlap census nor a conservative approximation of one.

Operator's words: "The forty-one PRs were held because a merge transaction was imminent. That transaction no longer exists. The possibility of a future transaction is not a present hold."

What this does and does not mean

Does: the namespace-cut interval is no longer a constraint on this PR.

Does not: mean this PR must merge. Ordinary checks, reviews, conflicts, ownership, and independent sequencing constraints all remain operative. #8282 itself remains excluded and stays draft.

If this PR touches src/v1/04_infer.dag

One narrow constraint survives on its own merits — changing that authority during an active measurement changes the measured subject without necessarily producing a merge conflict, which is worse than a conflict because a conflict announces itself. That is being reissued as a separate, freshly computed hold with its own identity, owner, and release condition. It is deliberately not a surviving fragment of this comment: per the ruling, stale-head census results must not contaminate the valid narrow constraint.

Release record

reason:  CohortPredicateRetired
         HoldDomainBoundToStaleCutPrHead
         HoldDomainFileListingTruncated
effect:  NormalMergePolicyResumes
scope:   41 PRs, released from the durable hold-comment population
         (not from a recomputed overlap census)