On 26 August 2026 we wrote a rule into the file that every working session reads first: each fact has exactly one document that owns it, and every other document points there. The same day, that file was cut down from about 1,900 lines. By 29 August it was 2,247 lines, longer than before we cut it.
Every session that grew the file had read the rule first.
Why the rule did not hold
The rule was read at the start of each session. The mistake happened hours later, one reasonable paragraph at a time, long after the rule had scrolled out of view. The next session, or the next person, will not be reading a rule at the moment it matters.
An agent makes this sharper, not different. It reads what it is given at the start and then works on whatever is in front of it. A rule in prose is something it can recall. It is not something that stops it.
So on 29 August we cut the file again, to 627 lines, and this time turned the rule into something that fails. A script. Today it checks the budget on that file, that every path a document mentions exists, and that the index of known traps matches the catalogue. It exits 0 when clean and 1 when something needs fixing, and every failure names the fix. In its first four days it forced content out to its owning document on 30 August, 31 August, 1 September and 2 September, and on the last of those it refused three drafts.
Writing a rule down is a reminder. Making it fail is a rule.
Watch it fail first
The checker’s first automated run, on 30 August, failed. It had been committed without permission to execute, so the checker had silently never run, which is the exact defect it exists to prevent.
That set a habit: a check is not trusted until someone has seen it fail. When we built a guard to stop a restore rehearsal touching the real Git server, we pointed it at the real server first and watched it refuse. A check nobody has seen fail is just another thing that looks healthy.
The checker still only sees what it checks. On 14 September it passed clean on a session log that had just gone from 5,122 lines of history to a single entry, overwritten by a one-line append written the wrong way. Paths still resolved and the index still matched, so every check passed, and it merged. The checker now has a section that fails when a history file shrinks. On 15 September it gained another: the render and fact check for this site, which is why every number on this page has a source.
The number that corrected the story
A budget can be wrong too. The cap on that file started at 700 lines. The operator raised it to 750 on 2 September, to 800 on 3 September, and to 820 on 7 September. Each raise was right for its moment: a cap with no slack stops rejecting bloat and starts rejecting updates, and a session that has found a real defect should not have to delete a true line to record it.
The problem was the comment beside the cap. It said, in bold, that every raise happened because the index of traps grew, never because the prose did, and it recommended moving the index into its own file. On 8 September someone finally measured it from the file’s own history. The index had grown 34 lines. The narrative had grown 86, two and a half times faster. The claim that justified all three raises was backwards.
It nearly cost more than a budget. A session read that comment, believed it, and came within one approval of moving the index out, which the file’s own design forbids: an agent that does not know a trap exists will never go looking for it.
The fix was not another cap. The script now prints the split between index and narrative on every run, and enforces nothing about it. What had been missing was never enforcement. It was numbers in front of the person deciding.
What it cost
- A second cut of the file every session reads, three days after the first.
- A checker that never ran on its first automated outing, because of a missing permission.
- Three budget raises made on a false paragraph, and one near miss that would have broken the file’s design.
- A history file overwritten and merged while the checker reported clean.
The rule it bought
Assert, don’t remind. Turn a rule into something that fails at the moment of the mistake: a checker, an assertion, a refusal. Watch it fail before you trust it. And when the right call is a judgement, don’t enforce it; put the measurement where the person making the call will see it.
Where we might be wrong
Every checker is code that has to be maintained, and a checker nobody runs looks like enforcement and enforces nothing. The operator switched automatic runs off the day they started, because running one script three times per change was waste, so today the local run is the only run and nothing enforces it. That works because one person runs it reliably. It is not obviously something that scales.
What would settle it: whether the checker is still being run in three months, and whether a second one ever earns its place.
And not every habit here should become a checked rule. The operator sizes each working session and decides when to hand over, by judgement, and there is deliberately no rule for it. Choosing what stays a person’s judgement is part of the method, not a gap in it.
None of this is new
In 2007 Atul Gawande wrote about Peter Pronovost’s checklist for putting central lines into intensive-care patients. The steps were basic hygiene. “These steps are no-brainers; they have been known and taught for years.” When nurses watched, though, the doctors who knew them still missed some: “In more than a third of patients, they skipped at least one.”
Knowing the rule was not the fix. The fix was getting the hospital to “authorize nurses to stop doctors if they saw them skipping a step on the checklist”: a refusal, at the moment of the mistake, by someone whose job was to check. Line infections all but disappeared.
The difference here is who forgets. A doctor forgets a step under pressure. An agent starts every session without whatever the last one learned. For both, the rule that holds is the one that can stop the work.