---
name: amendment-falsifies-more-than-named
description: "A ruling that amends one clause usually falsifies other claims in the same entry — sweep the whole entry for every sentence the change touched, not just the one the ruling named."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 5893ae58-5dde-49e3-bcfd-5aab31b20008
  modified: 2026-08-22T10:10:44.596Z
---

When a build wave amends a documented invariant, the dispatch names ONE clause to fix. That is the clause someone noticed — not the extent of the damage. Re-read the WHOLE entry against the shipped change and find every other sentence the same change made false.

BAROMETER W2 (2026-08-02, releases#78): doyle's dispatch named the class-(c) clause of KNOWN-HAZARDS 2.6 (the wake reconciler's raw-status read, re-based onto the corpse-boot discriminant). Fixing only that would have shipped a second false sentence in the same bullet: 2.6's recycled-pid caveat said "a reused pid reads alive, so the heal is missed, never mis-fired" — true until W2 parked a launch birth stamp and made `shell_pid_provably_dead` run a pair test, which reads a reused pid as GONE wherever a stamp exists. And a restart is precisely the event that recycles pids, so the stale caveat was wrong exactly where the new hazard lives. Both got amended; doyle confirmed the second was the find.

**Why:** an amendment's blast radius is the set of claims that rested on the OLD mechanism, and those are scattered through prose written when the mechanism was true. The named clause is a starting point, not a scope. This compounds with [[doc-audit-reads-whole-file]]: diff-scoped audits cannot see it, because the entry was not in the changed-file set at all.

**How to apply:** after making the named amendment, re-read the full entry (and its conformance-table row, and its `spt-core mapping` line) asking of each sentence "does the new code still make this true?" — checking against the SHIPPED functions, not the requirement text. Then update the summary row too; a table row is a second copy of the claim and goes stale independently ([[every-return-arm-is-a-copy]] is the same shape for code).

Related: [[correct-by-replacement-not-annotation]], [[stale-carried-forward-sentence]], [[doc-audit-reads-whole-file]], [[barometer-triaged]].

## A CORRECTED FIGURE SURVIVES WHERE IT WAS *USED* (2026-08-22, #212, found in MY file by todlando)

I published a wrong coverage figure (88,030 / 54.4% / 102 files), was corrected, and fixed it **at the
entry where I had REPORTED it** — adding the qualification the rule demands. todlando then grepped my
ledger and found TWO more, both UNQUALIFIED, both in the **RULING** text where the number was being
USED as a premise: "then RE-CENSUS the newly-opened 88,030 lines" and "the A/B/C partition over 88,030
previously unscanned lines". The tree's source was clean; my own file was not.

**The mechanism, and it is why this class outlives its own correction:** a figure is corrected where it
was STATED, because that is where the correction feels owed — and it is left standing everywhere it was
USED, because a use does not look like a claim. The used copies are the dangerous ones: they are the
instructions somebody executes.

**How to apply:** correcting a number is not an edit, it is a SWEEP — grep every artifact for the
digits (all spellings: `88,030`, `88030`, the percentage, the file count), and read each hit for whether
it STATES the figure or USES it. Run the sweep on YOUR OWN records with the same grep you asked anyone
else to run; I put the tree-wide grep in the gate script and did not point it at my ledger. A figure
appearing as the SUBJECT OF ITS OWN CORRECTION is the one legitimate survivor.