Version. 0.1 · Date. 2026-08-09 · 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.
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.
Three instances, all inside one week, in three different kinds of artefact:
| 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. |
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.
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 three 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.1 — 2026-08-09