Where: the first draft of DouJou’s own Enterprise Brain master plan.
Symptom: a two-week phase of security work, scheduled and justified, for a capability that had shipped four pull requests earlier.
What it actually was
Writing the master plan, I needed to know whether Kai enforced per-person access control on every retrieval path. I found a detailed comment in the identity code stating plainly which paths still searched without enforcement. I cited it. I wrote a two-week phase around closing that gap.
The comment was false on all three of its claims. The enforcement had shipped the previous day across four separate changes, including a substantial one closing a wider hole than the one I was worried about. The engineers who did that work had been careful: each of them added a dated “built” note to the section of the specification they touched. None of them updated the status line at the top of the document, which still read “proposed, not built.” Nobody owns that line.
Worse than being stale, the comment was stale in the most dangerous possible direction. It described a security gap that had been closed, while failing to mention the one place enforcement genuinely is still disabled. It pointed at a solved problem and away from an open one.
- Time hidden: one day for the enforcement change. The comment had been accurate when written.
- What it cost: a wrong plan, caught only because a human read it and said, “a worker was already doing something like this, check.” Without that, we would have dispatched an agent to rebuild working security machinery. That has already happened once on this codebase: an earlier attempt at the same feature was later recorded as a disconnected duplicate of an identity system that already existed.
What we found when we went looking properly
Of 14 design documents whose header says “design draft”, “proposed” or “not built”, 12 had already shipped. That included the document describing the system our largest pilot customer uses in production every day, which still read “design draft v1.”
The mechanism is precise and slightly beautiful. Section-level status is maintained diligently at merge time. The line at the top is written once, on day one, and never revisited. For 30 of 31 documents, the last edit to that status line is the document’s own creation. And for 8 of the 12, the code shipped within a day of the specification being written: the document was a scratchpad for a build that immediately followed, but it is filed, and read, as a durable record.
About these numbers. The 12 of 14 and 30 of 31 counts are Kai’s own from 20 August 2026. They have not been recomputed since, and we will republish them with the method written out.
The lesson
A single global status claim, at the top of a document describing many independently shipping parts, is structurally guaranteed to become wrong. The only specification in our repository that stayed honest is the one that carries dated per-section status next to the thing that changed. We deleted top-level status lines and made per-section status the only surface. This diary follows the same rule.
