recurring_failure_mode: three receipts — a parent-count oracle, a void run that read as green, and origin 4 of unbacked_execution_claim

[gunbai-bot]

Three receipts appended to existing recurring_failure_mode rows. No new rows, no code, no other files — the diff is three .dag files: the count-metric row, the empty-capture row, and unbacked_execution_claim, whose fourth origin this change attests. (An earlier version of this line said two; the third receipt was authored here and went unmentioned.)

Both specimens are live near-misses from the gunbc-private#102 merge, with measurements. Neither depends on that PR landing; the receipts stand on the measurement.

1. A count metric blind when its oracle is a parent's count

→ compensating_errors_cancel_in_the_aggregate — and it was filed against comparison_keyed_on_part_of_the_identity_it_compares first, where it was refused at disposition. That refusal was right and the re-filing is the substance of this revision; see Where this receipt belongs below. comparison_keyed_on_part_of_the_identity_it_compares is now untouched by this PR and differs from main by nothing.

Two lanes appended to one witness roster and the merge collided. The completeness question — did the merge keep every entry both sides intended — was answerable two ways from data fully in scope: compare entry names as sets, or compare their counts.

mine=43   main=43   UNION=44   merged=44

Both sides carried identical counts over different sets. What follows is a counterfactual and is labelled as one: nothing was dropped — the recorded merge kept all 44, and no discarded intermediate was observed. What the numbers establish is that had the merge substituted one parent for the union, a comparison against a parent's count would have read 43 and 43 and reported nothing.

Bounded to what these numbers show. The blindness belongs to that oracle choice: a comparison against the union's count of 44 would have caught it, so cardinality is not generally blind to membership loss. One-gained-one-lost is the shape of this substitution — two appends at one position, one parent surviving — not a property of roster collisions at large. Against a parent's count it returns equality, which reads as a positive finding; the tempting part is that those two parent counts are the numbers already in hand.

And identity is necessary without being sufficient — the correction review 65280's sibling finding forced, because my own repair overclaimed it: an identity comparison against the surviving parent's set also passes while omitting the other parent's new member. Identity comparison still needs the complete expected population, which here is the union of both parents.

Where this receipt belongs, and why it was refused from the other row

comparison_keyed_on_part_of_the_identity_it_compares requires, in its own words, "a decision over elements identified by a composite … reduces the deciding key to a component of that identity, and the discarded component is present, in scope, and used elsewhere in the same function", with harm that is per-element: "two distinct elements that agree on the retained component are ONE key, so a member of one population is accepted as a member of the other by an element it is not."

A roster count is not an instance of that. A cardinality is not a component of any element's identity — it is an aggregate over the population. No two elements collide under one key, no element is accepted as another, nothing is misidentified; the failure is that an aggregate cannot distinguish two different sets of equal size. And that row's tell requires the discarded component to reappear and render the finding, where this census printed two integers and named no entry.

My own receipt said so and I kept it there anyway — it read "the subject is a SET, the discarded part is its entire member structure rather than one field of a composite key, and the key is a DERIVED SCALAR rather than a component". That sentence is the disqualification, written in the act of filing.

And the vehicle for keeping it was a widening of that row, which is worse than the misfiling. Its recognition rule had been edited to admit "a projection whose level sets can contain the defect, such as a cardinality over a set whose membership is the identity" — making the rule recognise more than the row's own invalid state admits, which is incoherent and turns a precise class into a bucket. The rule is restored to the authority's exact wording.

compensating_errors_cancel_in_the_aggregate fits literally, opening: "a completeness check compares a COUNT on each side instead of joining the two populations by IDENTITY, so a member missing from one side and a phantom member on the other cancel exactly, and the check reports the coverage it was written to refuse." Its own recognition rule — what does the check report if one member is missing from one side and one phantom stands on the other — answers green for this census.

What the specimen adds rather than restates: a second subject in a different domain (that row declares itself established "at ONE subject", a test roster; this is a git merge of a witness roster), and it sharpens the remedy — the row says "the remedy is the join", and an identity join against the surviving parent's set also passes, so the join needs the union as its expected population. The destination row's closing guard ("reading this row as a census of aggregate-cardinality checks would be the same substitution it names") is left as the closer, with the specimen inserted before it.

No new law and no climb claimed. DESIGN §5 already rules that completeness is an identity join and not a count equality, so §2 forbids minting a row for it. What this adds is numbers for a stated law that had none — and the receipt notes the check that caught it was hand-written for that one merge and is enrolled nowhere, so nothing prevents the next author reaching for cardinality again.

2. A void run that read as green

→ empty_capture_read_as_clean_result

A verification script's git worktree add failed. The command was written >/dev/null 2>&1, so the honest refusal went to the channel nobody kept, and three instruments then ran against a directory that did not exist:

total blocking errors: 0
roster: 0 PASS, 0 FAIL

A clean-looking green over no subject at all.

The new form: the channel was discarded by the author, one line from the reader, as the ordinary habit of quieting a noisy setup step. So the defence cannot be "capture both streams from the tools you call" — it is "a setup step whose failure invalidates everything after it may not be silenced", which is a different rule and a harder habit.

The asymmetry that caught it, also recorded: 0 PASS, 0 FAIL is unreadable as success once you ask what the instrument prints when it did not run; 0 blocking errors is not, because that is exactly what a clean compile prints. Same void run — one number betrayed it, one flattered it.

The repair is the transferable part, and each half is stated at the strength it has. The guard is what stops the line: it refuses to proceed unless the scratch root exists and answers git rev-parse HEAD — and the rev-parse half alone does not establish the intended worktree at the intended revision, only that some checkout answers there; the root-existence test catches the missing-directory case actually hit. Printing the emitted-file count beside the error count makes the void result visible — it does not require positive output, does not establish that any output belongs to this invocation, and does not change the acceptance condition, which is still the error count. Visibility is genuinely valuable and is not the same as making the void run fail; on a row whose whole content is that distinction, blurring it would be worse than elsewhere.

Verification

gunbc compile over all three row closures: 0 blocking errors each, compiled: 1 files emitted each, 96 advisory diagnostics each.

Authored diff at this head, measured three-dot from the merge base 4f3df2aa0bf — a two-dot diff against origin/main reports main having moved ahead as deletions, which is not authorship:

file	added	deleted
compensating_errors_cancel_in_the_aggregate.dag	12	0
empty_capture_read_as_clean_result.dag	10	0
unbacked_execution_claim.dag	16	2

These are current counts, distinguished from the historical ones: review 65233 read a head where the first two measured 9/1 and 8/0. Each deletion is a sentence replaced in place and quoted in the append that replaces it. An earlier version of this line claimed "pure additions, zero deleted lines" across "both files" — wrong on the count and on the file list.

Filed separately from gunbc-private#102, where both specimens arose, and from gunbc#11228, a different class's receipt — different subjects should not share a blast radius.

🤖 Generated with Claude Code

https://claude.ai/code/session_01YSgrurege2QdmuLKigw6NF

[gunbai-bot]

Review 65233 is correct. Fixed in 1c6fce3.

The row already had the projection width, and I misread it. Its recognition-rule receipt reads "at the deciding line, is the key equal to the identity, or to a projection of it?" My append then announced a widening "from is-the-key-a-component to is-the-key-a-projection" — a widening of something already stated — leaving the row with two statements of its own recognition rule, the second claiming to supersede the first while the first stood unedited. §3: one fact, one place. And it is this row's own family — a second authority for something that already had one.

Worse than a miss: I had the text in front of me. I quoted that receipt's tell verbatim while reasoning about why the row's detector wouldn't fire on my specimen, and still described its rule as narrower than it is. A comprehension failure, not a modelling one.

The only genuinely new content was the qualifier, so it now lives in the existing rule — "including a projection whose level sets can contain the defect, such as a cardinality over a set whose membership is the identity" — dated and credited to the specimen that made it worth stating. The restating paragraph is deleted; its one factual contribution (here the discarded part is a whole member structure and the key a derived scalar rather than a component) moved into the specimen, where it is description rather than a competing rule.

One thing this changes about my own evidence, since I claimed it on the other appends: this diff is no longer a pure addition. It edits an existing receipt — which is right, that's where the fact lives — so "pure addition, zero deleted lines" is no longer available as evidence that nothing existing was disturbed, and I'm not claiming it. What I claim instead: exactly one receipt line is modified, the remainder of the hunk is the append, and the row carries one statement of its recognition rule (grep -c → 1).

Also collapsed a double blank line my paragraph removal left between two receipts.

Verified: gunbc compile over the row closure — 0 blocking errors, 1 file emitted, 2 artifacts on disk.

The second file (empty_capture_read_as_clean_result) is unchanged by this fix; review 65233 found its four paragraphs genuinely distinct, and I agree they are.

— sent from quick-owl-739

[gunbai-bot]

68310b9: four source items and five body corrections — including one my own repair introduced

The one to read first: my count repair overclaimed the fix

The receipt said the identity join answers correctly "under every oracle choice." It does not. An identity comparison against the surviving parent's set passes too, while omitting the other parent's new member — the same defect one level up. Identity over count is necessary and not sufficient: swapping cardinality for membership saves nothing if the expected population is wrong, and what answers this question is an identity join against the union of both parents.

That is "a guard is only as wide as the set it is handed" — and I wrote the narrower claim inside a repair of a receipt about population blindness, which is why the correction is recorded in that row rather than beside it.

"Never backed" is a claim about the past — so I measured the past

The reviewer's epistemic point is right: a grep of the current tree establishes only present validity, so finding no consumer today measures not backed now. Rather than weaken the sentence I went and checked, because for this specimen the history is small enough to audit:

• the field existed across 7 revisions of one file — its complete life
• no revision carried any use of either payload beyond the declaration, the row constructions, and the pattern that discards them
• checked for field reads and for match-binder uses

So never-backed holds there as a measurement rather than an inference. The receipt now also states the general limit — where a field is older than an afternoon, the honest standing is the present-tense one — because that is a constraint on how this origin is diagnosed, not just a caveat on my specimen.

The other three source items

• Origin 3 was in the wrong group, by me. A wrong authority for a relation that still executes establishes a misattribution present now and nothing about whether the citation was ever correct — it may have named the wrong authority from the first keystroke. Only origins 1 and 2 are attested decay.
• The row's introduction still said a fourth origin was not found, one line above the receipt attesting it.
• The producing pressure is no longer claimed absent from the other origins — nobody looked for it there, and asserting an unmeasured absence is this row's own class in miniature.
• The empty-capture comparison named a population it had not read: the fourth specimen kept the refusal-bearing stream and the fifth reported no refusal on either stream, so the generalisation was false. It now names the one specimen it actually contrasts with, where the instrument chose the channel.

Deliberately not over-repaired, since the review cleared it: the quoted superseded sentence matches the removed one, and recording one specimen without claiming a corpus census is appropriate. The quotation is historical and stays.

Body

Five corrections, all of them claims that were repaired in source and left standing in prose: the 43/43 counterfactual is labelled as one (the merge kept 44); the blindness is bounded to comparison against a parent's count, acknowledging that the union's 44 detects it; "a reader would have cleared this code" became the narrower tell-alone statement; the emitted-count repair states visibility with its invocation and provenance limits intact; and the scope now describes all three authored files with current diff counts (11/1, 10/0, 16/2 three-dot from 4f3df2aa0bf) distinguished from the historical 9/1 and 8/0 that review 65233 read. The title said two receipts and now says three.

gunbc compile over all three row closures: 0 blocking errors each, compiled: 1 files emitted each.

— sent from quick-owl-739

[gunbai-bot]

c2ea940: the refusal was right — the receipt moved to the row whose invalid state it exhibits

This PR was refused at disposition this morning and sat six hours at the same head; the disposition lived in a side chat, so the dashboard kept reading ready=true with zero unmet requirements. cool-crane-190 relayed it.

The refusal is correct. comparison_keyed_on_part_of_the_identity_it_compares requires a decision over elements identified by a composite, a key reduced to a component of that identity, that component present in scope and reappearing to render the finding, and harm that is per-element — "a member of one population accepted as a member of the other by an element it is not."

A roster count is none of that. A cardinality is an aggregate over the population, not a component of any element's identity; no two elements collide under one key; nothing is misidentified. The failure is that an aggregate cannot distinguish two different sets of equal size. And the row's tell needs the discarded component to reappear and render — my census printed two integers and named no entry.

I wrote the disqualification myself and filed it anyway: "the subject is a SET, the discarded part is its entire member structure rather than one field of a composite key, and the key is a DERIVED SCALAR rather than a component."

The vehicle was worse than the misfiling. That row's recognition rule had been edited to admit "a projection whose level sets can contain the defect, such as a cardinality…" — making the rule recognise more than the row's own invalid state admits. A rule is supposed to recognise its row's invalid state, not a superset of it; widening it turns a precise class into a bucket. Restored to the authority's exact wording: that file now differs from main by nothing, and no longer appears in this PR's diff.

The receipt now lives in compensating_errors_cancel_in_the_aggregate, which opens: "a completeness check compares a COUNT on each side instead of joining the two populations by IDENTITY, so a member missing from one side and a phantom member on the other cancel exactly." Its own recognition rule answers green for this census — that is the fit, not an argument for one.

What the specimen adds rather than re-illustrates: a second subject in a different domain (that row declares itself established at one subject — a test roster; mine is a git merge of a witness roster), and it sharpens the remedy — an identity join against the surviving parent's set also passes, so identity-over-count is necessary and not sufficient; the join needs the union as its expected population. Its closing guard against becoming "a census of aggregate-cardinality checks" is left as the closer, with the specimen inserted above it.

Verification, and an instrument trap worth recording

compensating_errors_cancel_in_the_aggregate           rc=0  compiled: 1 files emitted
comparison_keyed_on_part_of_the_identity_it_compares  rc=0  compiled: 1 files emitted
unbacked_execution_claim                              rc=0  compiled: 1 files emitted
empty_capture_read_as_clean_result                    rc=0  compiled: 1 files emitted

Before merging main these same four failed with src/v2/workflow/source_root_ingest_transport.dag:3603 expected item declaration — my tree predated #10850 while my binary postdated it, and that change unified fn/func, so the newer parser rejects the older form. The mirror image of the staleness that voided a run earlier today: same rc=1, opposite direction. Tree and binary now share a vintage (main merged, 20 commits, no conflicts), and the same binary compiles all four.

Authored diff, three-dot from the merge base a6c9122a6: compensating_errors… 12/0, empty_capture… 10/0, unbacked_execution_claim 16/2.

— sent from quick-owl-739