Repository navigation
The attribution class had a rung and a trigger but no carrier: file claim-forced-and-unbracketed - #10231
Merged
Conversation
…laim-forced-and-unbracketed `gunbc.shared_fill_attribution_seed_growth` (landed 2026-08-27, #9477) names a defect precisely — a shared memoized host artifact that is claim-forced and records no fill bracket, so its whole cost lands on whichever claim reached it first. It declares its own rung honestly (mitigatable, on review diligence) and authors a well-formed §4b(3) next-rung trigger naming a capability. All of that is a `//` annotation. §4c is explicit that no `Accepted` program can read one, and the file says so about itself: nothing refuses this state, and the next memo reintroduces it. The typed row in that module is a `SeedGrowthJustification` whose trigger is to DELETE two hand-Rust functions once the memoized compiles are modeled — a different subject, dischargeable while this state stays exactly as writable as it is today. The class appeared in neither ledger §4b names, so this row forks nothing; it is the first carrier. The trigger is copied verbatim rather than re-coined, because re-wording an existing well-formed trigger is the nicknaming §3 forbids. Two things the row records that the annotation does not. The recognition rule is NOT available from the cost log: regime membership is a property of the construction, decidable by reading the producer, and a row's absence from shared-fill accounting is equally consistent with preparation-forceable, with not-shared-at-all, and with this class. The specimen is a misclassification rather than the class — one subject placed in four regimes in three hours, every placement from floor output, settled by reading the call site — and it carries the warning that admitting a correctly-billed row to a misattribution census corrupts the population. Nesting is stated in both directions so the triggers cannot drift: `gunbc.rung_drop` `floor_cost_claim_qualification_unavailable` declares the general capability loss, and this is one named mechanism defeating that invariance, filed separately because it has its own narrower and independently satisfiable trigger. Buried inside the capability row, discharging this mechanism would read as discharging the capability, which it does not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V
gunbai-bot Bot
pushed a commit
that referenced
this pull request
Sep 3, 2026
…tion one-way, and enumerate #10231 Three corrections, two of them to claims I made. "Stated in both directions so the two triggers cannot drift apart silently" was an overclaim. `RecurringFailureMode` and `RungDrop` carry no typed relation field, so editing either trigger invalidates nothing and refuses nothing. Cross-citation makes the relationship REVIEW-VISIBLE; it does not make drift mechanically impossible, and saying otherwise is the rung inflation §4b(1) forbids applied to a relationship instead of a guarantee. So the backlink is removed and the citation is one-way: the narrower row cites this one as the capability it blocks, and this row stays cause-agnostic. That also restores this row's own opening discipline — it declares that it NAMES NO CAUSE, and enumerating a mechanism here starts undoing the rename that removed a refuted attribution from its identity. Adds the explicit refusal of the reading the planned-cardinality finding most invites: a differing planned count weakens comparability between two attempts and lowers confidence they covered the same claims. It does NOT expand the allowance, which stays at one per head per signature, consumed on actuation. An attempt outside this row's domain spends nothing and EARNS nothing — an ineligible red is not a free retry. Enumerates the #10231 episode, which is the sharpest instance this row carries: a ledger-only prose PR, refused at `completed_over_cost_requirement=1` with every other counter zero, on `rust_produced_decl_name_discriminates` at cpu_ms=523; one reroll actuated and consumed; pass at cpu_ms=404 — while `eval_steps` is IDENTICAL at 169297 on both. Same head, same tree, same identity, opposite verdicts, and the measured work did not move by one step. An independent lane had named that identity hours earlier at 81% of budget on green main (406ms) with the arithmetic that a 1.27× envelope crosses 500; the reroll reproduces that figure to within 2ms. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V
…the annotation as trigger authority Three corrections from review, all to claims this PR made. "Stated in both directions so the triggers cannot drift" was false twice. It was false on this PR's own head — the reverse citation lived only on a separate branch, so this tree asserted a relationship half of which it did not contain. And it would have been an overclaim even after both landed: `RecurringFailureMode` and `RungDrop` carry no typed relation field, so editing either trigger invalidates nothing and refuses nothing. Cross-citation makes a relationship review-visible and nothing stronger; a typed parent reference is what a mechanical anti-drift claim would require. The citation is now ONE-WAY, from the narrower row to the capability row it blocks, and the row says what the citation does and does not buy. One-way is also the right design on its own terms: the parent declares in its opening that it NAMES NO CAUSE, so enumerating mechanisms there would start undoing the rename that removed a refuted attribution from its identity. The corresponding backlink is removed on the other branch. Retires the `//` annotation in `gunbc.shared_fill_attribution_seed_growth` as the trigger's authority. Two statements of one trigger in two places is the §3 fork, and the survivor is the one something can consume — a typed row a fold can read, not a §4c annotation no `Accepted` program can. The reasoning stays as the rationale for that change's shape, with an explicit rule that the row wins if the two ever disagree. `docs/design-failure-modes.md` conflicted on the merge and was NOT hand-resolved: it is a projection, so it was reset to main and regenerated from the resolved authority. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V
briansrls
pushed a commit
that referenced
this pull request
Sep 3, 2026
… the episode is admitted only in part (#10228) * floor cost: one complete mitigation episode by run id, and missing item (b) measured at corpus grain — it refutes `floor_cost_claim_qualification_unavailable` gains the gunbc#10192 episode enumerated in full, including the two attempts that do NOT qualify, because an episode listing only the qualifying attempts overstates the mitigation's hit rate. Attempt 1 executed zero jobs (awaiting workflow approval); attempt 2 refused semantically with both cost arms at zero, so it is outside this row's domain; attempt 3 qualifies with one row on each arm; attempt 4 is the consumed reroll. The row's missing item (b) — an identity join of `eval_steps` across two attempts of one identical tree, cpu allowed to move and steps required not to — is now MEASURED, and it REFUTES rather than discharges. Attempts 3 and 4 join totally at 3519 rows: cpu disagrees on 1394, `eval_steps` on 18. The step measure reproduces exactly on 99.49% of the corpus against cpu's 60.4% — far more stable, and not invariant. The job log says the opposite. Its printed over-cost list shows identical `eval_steps` on every identity while cpu swings by a third, so (b) reads as satisfied from the log alone. That list is ranked BY COST and truncated at 25, and 17 of the 18 disagreeing rows are too cheap to appear in it. A subset selected by the variable you are not testing cannot test the one you are — so (b) must be joined on the uploaded artifact, never on the printed summary. The 18 are two classes. Seventeen are pass/pass with deltas under 0.43%, and 16 of those sit in three modules of one partition/unit witness family — clustered, not uniform. That establishes module-clustered variance EXISTS in the corpus, which is the mechanism a module-clustered redraw would require; it does NOT establish that the refused set redraws by module, and the row says so. The eighteenth is the interrupted row, whose step count is a partial at the stop rather than the claim's work — the step-domain twin of the printed ms being the budget — which bears directly on missing item (a): a step-denominated line would compare against that partial for precisely the rows it exists to judge. Net: (ii) moves from unmeasured to measured-and-failing. The trigger is a conjunction of three, (i) and (iii) are untouched, so nothing here retires the row or raises the ceiling. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V * The planned population is not a function of the tree, and attempt 2 was not a toolchain incident Two corrections to the episode just filed, both measured from the same three jobs. First: on the single head b65a0eb the three attempts carrying a floor job report planned=executed of 3534, 3519 and 3519. Fifteen claims of difference across attempts of one head with no change to the source. No cause is asserted — if the plan is computed relative to a moving main rather than to the head under test, this is expected rather than anomalous, and that is the first thing to check. What it establishes regardless of cause is that EXACT HEAD DOES NOT BY ITSELF FIX THE POPULATION A REROLL IS DRAWN FROM, so the bounded per-head-per-signature rule this row admits must say whether a changed planned count is receipt detail or a fresh signature. Left open deliberately: answering it by preference would be the unmeasured narrowing this row exists to refuse. It does not contaminate the (b) join in the previous commit — attempts 3 and 4 both planned 3519 and their identity join is total at 3519 with zero rows on either side. Second: attempt 2 was characterised elsewhere as a cargo/toolchain incident belonging to a runner population. Its own summary reports `host_tool_unresolved=0` beside `claims_failed=33`, so it is an ordinary red floor and belongs to no such population. The disposition is unchanged — both cost arms are zero and the failed=0 precondition does not hold — but the ground for excluding it from the mitigation is the cost-arm test, not a tooling attribution. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V * The moving-base explanation is refuted: all three attempts ran one synthetic merge — and the missing back-citation The previous commit named a likely cause for the differing planned counts and said to check it first. Checked, and it is dead. Actions evaluates a synthetic merge rather than the branch head, and all three attempts checked out THE SAME synthetic merge commit — each job log carries the identical "Merge b65a0eb… into 3547b3f" line. So the three ran a byte-identical tree, the base did not move between them, and the planned population varies across attempts of a genuinely fixed tree. The counters that do NOT vary narrow it further, and they are the ones a reader reaches for first: `known_red_held`, `route_gap_held` and `stale_quarantine` are identical across all three. Only planned/executed/terminal move, together, by fifteen. What cannot be said, and it is an artifact gap rather than a judgement: WHICH fifteen identities differ is not recoverable, because the 3534-attempt uploaded no per-claim cost artifact. So this is a COUNT-grain finding, which is the weaker form this row elsewhere refuses to accept as a population — recorded as a count because that is what was measured. One conjecture, labelled as one and carrying its own test: the same unpinned iteration order that would explain the module-clustered `eval_steps` variance could also change how many claims a generator emits, giving both observations one root. Nothing establishes that; the discriminating test is named in the row so the next lane need not invent it. Also adds the back-citation to `claim_forced_and_unbracketed` that the mechanism row's own filing claimed was "stated in both directions" and was not — only the forward direction had landed. Both now cite each other, so the two triggers cannot drift apart silently. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V * The backlink overclaimed and the parent names no cause: make the citation one-way, and enumerate #10231 Three corrections, two of them to claims I made. "Stated in both directions so the two triggers cannot drift apart silently" was an overclaim. `RecurringFailureMode` and `RungDrop` carry no typed relation field, so editing either trigger invalidates nothing and refuses nothing. Cross-citation makes the relationship REVIEW-VISIBLE; it does not make drift mechanically impossible, and saying otherwise is the rung inflation §4b(1) forbids applied to a relationship instead of a guarantee. So the backlink is removed and the citation is one-way: the narrower row cites this one as the capability it blocks, and this row stays cause-agnostic. That also restores this row's own opening discipline — it declares that it NAMES NO CAUSE, and enumerating a mechanism here starts undoing the rename that removed a refuted attribution from its identity. Adds the explicit refusal of the reading the planned-cardinality finding most invites: a differing planned count weakens comparability between two attempts and lowers confidence they covered the same claims. It does NOT expand the allowance, which stays at one per head per signature, consumed on actuation. An attempt outside this row's domain spends nothing and EARNS nothing — an ineligible red is not a free retry. Enumerates the #10231 episode, which is the sharpest instance this row carries: a ledger-only prose PR, refused at `completed_over_cost_requirement=1` with every other counter zero, on `rust_produced_decl_name_discriminates` at cpu_ms=523; one reroll actuated and consumed; pass at cpu_ms=404 — while `eval_steps` is IDENTICAL at 169297 on both. Same head, same tree, same identity, opposite verdicts, and the measured work did not move by one step. An independent lane had named that identity hours earlier at 81% of budget on green main (406ms) with the arithmetic that a 1.27× envelope crosses 500; the reroll reproduces that figure to within 2ms. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V * The receipt contradicted its own row four times: restore the keys this row had already ruled on Review caught that my appended receipt reintroduced spellings this same row had already refuted, and asserted a cause its counters do not establish. All four are mine. "The refusal is semantic" exceeds the measurement. `claims_failed` enumerates ordinary claim-failure dispositions and does not say why they failed — a missing host capability surfacing as a runtime error lands in the same counter as a genuine false assertion. Now: ordinary claim-failure floor refusal, cause unestablished. Attempt 2's role was wrong. I kept it to avoid overstating the mitigation's hit rate, but a mitigation's eligible population is the attempts satisfying its admission predicate, so an attempt outside the class can no more count as a failed use of it than an ordinary compile error can. It is a NEGATIVE ELIGIBILITY CONTROL — kept because it proves the predicate excludes something real. The attempt 2 → attempt 3 transition was unadjudicated, and calling the whole sequence "one complete episode" laundered it. Outside this row's budget means attempt 2 SPENT no reroll; it does not mean it EARNED one. That re-run was not admitted by this row and no other authority is named for it, so the sequence is an unadmitted retry of an ordinary red on byte-identical input, then a cost-only refusal this row does admit, then its one reroll. A clean attempt 4 does not retroactively discharge attempt 2. `failed=0` is not the eligibility key and is no longer restated as one: this row already ruled that test defective because it reads the floor's own COST disposition counters, which cannot report that anything else failed and so could only confirm themselves. The current surface is the run's phase verdict. "One per head per SIGNATURE" is not the budget: the row already ruled the signature an ADMISSION PREDICATE and never a budget key. The planned-count finding makes exact head insufficient as a COMPARABILITY identity while leaving it intact as the deliberately coarse BUDGET key — and I had left that "open" when the row had already decided it, which invited the reading it forbids. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V --------- Co-authored-by: Brian Searls <briansearls1@gmail.com> Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
gunbc.shared_fill_attribution_seed_growth(landed 2026-08-27, #9477) already names this defect precisely: a shared memoized host artifact that is claim-forced and records no fill bracket, so its whole cost lands on whichever claim reached it first while every later claim reads it free. It declares its own rung honestly — mitigatable, on review diligence — and authors a §4b(3) trigger that names a capability rather than an artifact.All of that is a
//annotation. §4c is explicit that noAcceptedprogram can read one, and the file says so about itself: "nothing refuses it; the next memo reintroduces the defect and this paragraph will not stop it."The typed row in that module is a
SeedGrowthJustificationwhosetriggeris to delete two hand-Rust functions once the memoized compiles are modeled — a different subject, dischargeable by a change that leaves this state exactly as writable as today. Fork-check before writing: zero occurrences indocs/design-rung-drops.md, no matching identity among thegunbc.rung_droprows, zero ingunbc.recurring_failure_mode. This row forks nothing; it is the class's first typed carrier.The trigger is copied verbatim rather than re-coined — re-wording an existing well-formed trigger is the nicknaming §3 forbids. This PR also retires the annotation as the trigger's authority, pointing it at the typed row, with an explicit rule that the row wins if the two ever disagree. Two statements of one trigger in two places is the §3 fork, and the survivor is the one something can consume.
Why the harm hides
The number that lands is real — a true measurement of something, charged to a row that does not own it — so nothing looks wrong. The reported cost becomes a function of discovery order, and because the floor's safety limit is a fail-stop, an order-dependent number decides whether the line stops. Prior incident with a number: the census memo sat in this state from #9428 and refused the required floor at 5812ms against a 5000ms fail-stop while two later claims read the same compiles free.
Compounding risk: #9517 proposes freezing rows above the line in a shrink-only contract, and a row frozen for cost it does not own can never be made cheap, so it can never leave.
Two things the row adds that the annotation does not
The recognition rule is not available from the cost log. A log reports what a run observed; regime membership is a property of the construction. A row's absence from shared-fill accounting is equally consistent with preparation-forceable, with not-shared-at-all, and with this class. Absence of a bracket is not evidence of a defect — for a preparation-forceable artifact it is correct.
The specimen is a misclassification, not the class: one subject placed in four regimes in three hours, every placement derived from floor output, settled by reading the call site. Admitting a correctly-billed row to a misattribution census corrupts the population.
Nesting — one-way, and honest about what it buys
The citation runs one way: this row cites
gunbc.rung_dropfloor_cost_claim_qualification_unavailableas the capability it blocks, and that row is not edited to cite back.An earlier revision of this PR said the relation was "stated in both directions so the triggers cannot drift." That was false twice, and both are corrected here. It was false on this PR's own head — the backlink lived only on a separate branch, so this tree asserted a relationship half of which it did not contain. And it would have been an overclaim even after both landed:
RecurringFailureModeandRungDropcarry no typed relation field, so editing either trigger invalidates nothing and refuses nothing. Cross-citation makes the relationship review-visible and nothing stronger; a typed parent reference is what a mechanical anti-drift claim would require.One-way is also right on its own terms: the parent declares in its opening that it names no cause, so enumerating mechanisms there would start undoing the rename that removed a refuted attribution from its identity.
No landing dependency in either direction. This PR cites a row already in main, and #10228 no longer mentions this row at all. The two are independently landable in either order.
Ledger-only: one authority row, its roster entry, its projection, and the annotation retirement. No code, types, or gates.
🤖 Generated with Claude Code
https://claude.ai/code/session_01RDCRC6CKcQGBSx3JcaGe3V