Version. 0.2 · Date. 2026-08-10 · Author. Claude Code.
Occasioned by. CR-2026-195, which was drafted, approved, and executed against a defect that had been fixed roughly a hundred change requests earlier.
Changes from v0.1. A fourth instance, found while filing v0.1 — and it was the assistant's own persistent memory, which is the copy nothing checks at all. §"The fourth instance" is new, and it sharpens the remedy: the question is not only which descriptions are load-bearing but which have any reader who would notice them going false.
Companion to. loomworks-standing-note-observe-the-failure-before-trusting-the-check and loomworks-standing-note-a-comment-that-averages-two-problems — the same family, one level up: not a check that cannot fail, but a description nothing checks.
An artefact that describes work outlives the work, and is then acted on as though it were the state of the work.
Four instances, all inside one week, in four different kinds of artefact — the fourth added at v0.2:
| Artefact | What it said | What was true | How it surfaced |
|---|---|---|---|
| Architecture specification :613 | A Contributor speaking is labelled as the Operator; role-aware labels need wiring. | Wired by CR-2026-094 Step 5, and the symptom was unreachable anyway — conversation history is scoped to the caller's own turns. | It generated a change request. CR-2026-195 was written, approved and executed; it halted at Step 1. |
| Build list, six items (v0.34) | READY. | Done — some for six versions, three written in the same session that recorded them. | Incidental discovery, while opening items to build them. Three were opened for building and turned out already built. |
| Code comment, uploads.py (B-74) | Multi-file aggregation is "a Step 1 follow-on". | Nobody filed it. It was never tracked anywhere. | Found by accident while fixing the neighbouring line in the same statement. |
| The assistant's own memory (added v0.2) | Contributors see themselves labelled (Operator); here is the file, the line, and two candidate fixes. | Fixed by CR-2026-094 Step 5; the symptom was unreachable anyway. | Incidental. A size limit fired, the index needed compacting, and the entry happened to concern the defect being closed that same hour. See below — this one had no reader who could have caught it. |
None was a lie when written. Every one was true on the day it was written. That is what makes the pattern hard: there is no careless moment to point at, and no author to correct.
While filing v0.1 of this note, a fourth was found: the assistant's own persistent memory.
A memory file recorded — in detail, with file and line references, a dev-database survey, and two candidate fix shapes — that conversation author labels hardcoded (Operator) and that contributors saw themselves mislabelled. It was accurate on 2026-05-19. It described the same defect the architecture specification described, and it went stale the same day the specification did, and it survived all three of the instances above. It was deleted on 2026-08-09.
Why this instance is worse than the other three, and it is not because the memory was more wrong.
The other three artefacts have readers who can notice. A build-list status is read when somebody opens the item. An architecture line is read in review. A code comment is read by whoever touches the function. Each has a moment where a human meets it holding independent knowledge, which is how all three were eventually caught.
A memory index has exactly one reader, and that reader is the same process that wrote it. It is loaded as background context and believed by default — that is its entire purpose. Nothing external ever meets it. So a false memory is not merely unchecked; it is structurally uncheckable by the mechanism that uses it. The three catches above were: a deliberate sweep, an accident, and a read-first CR step. None of those touches memory.
> What actually caught it was luck of the most incidental kind — a size limit fired, the index needed compacting, and the entry happened to be about the very defect being closed that hour. Absent that coincidence it would still be there, and the next session would still have believed it.
The remedy that follows is not "check your memory more". It is narrower and it is achievable:
The general lesson the fourth instance adds: the earlier framing asked which descriptions are load-bearing enough that somebody would act on them without checking. That was the wrong half of the question. The sharper one is which descriptions have any reader positioned to notice them going false — because a description with no such reader will not be caught by diligence at all, only by accident, and it should therefore be written so it cannot go false rather than trusted to be corrected later.
The artefact and the thing it describes are updated by different acts, and only one of them is forced. Closing a defect requires changing code, and the code will not run wrong forever without somebody noticing. Updating the sentence that described the defect requires nothing, is nobody's step, and has no failure mode — a stale description simply sits there reading plausibly.
A description of state is indistinguishable from state at the point of reading. Nobody re-derives an architecture line, a build-list status, or a code comment against the system before believing it — that is the entire reason those artefacts exist. Their value is that they can be trusted without checking. Which is exactly why a stale one is expensive rather than merely untidy: it is trusted the same way a true one is.
The failure mode scales with how authoritative the artefact is. A stale comment misleads whoever reads that function. A stale build-list status wastes an opening. A stale architecture-specification line generates change requests — it is the most authoritative document in the record, so it is the one most likely to be acted on without a check, and the one whose staleness costs the most.
1. When you close something, close its descriptions in the same act. Not afterwards, not as a follow-on — the follow-on is the failure mode. Ask directly: what documents say this is broken? Grep for the item's identifier across the record before calling it done.
2. Correct by superseding, not by overwriting. A corrected line that reads as though the gap never existed destroys the evidence that the gap existed — and the evidence is what lets the next reader tell a description that was checked from one that was merely never wrong. Keep the original text visible, name what closed it, date it. (The architecture specification v0.8 entry is the worked example.)
3. Treat "this document says X is broken" as a claim to verify, never as a finding. CR-2026-195's Step 1 existed precisely because its author would not assert the current behaviour from the document — the CR said so in as many words: "the :613 quotation is from CC's own architecture-document read… Everything else about the current behaviour is unestablished and Step 1 must find it." That instruction is what stopped the CR from building something unnecessary. It is the general remedy, not a courtesy: a read-first step in front of any work sourced from a description.
4. Do not park unbuilt work in an architecture document. A planned-gap note in an architecture specification is read as architecture. Track work where work is tracked, and let the specification describe what is, so that "the specification says so" can mean something.
> The open question, recorded rather than answered. All four instances were caught by luck or by a deliberate read-first step — never by a mechanism. What would make a description of state checkable against the state? Some are (a build-list status can be checked against the tag that closed it — that is the v0.34 remedy). Some are not obviously checkable at all: no test can tell you an architecture paragraph has gone false. The narrower and more useful question may be: which descriptions in this record are load-bearing enough that somebody would act on them without checking? Those are the ones worth a mechanism. There are probably not many, and they are probably identifiable in an afternoon.
DUNIN7 — Done In Seven LLC — Miami, Florida Descriptions of state are not state — v0.2 — 2026-08-10