Documentation as infrastructure

9.1 Three entry levels, one per reader

Good docs serve three readers at three depths: the newcomer who needs the map, the builder who needs the how, the maintainer who needs the why. One page can't serve all three well, so you layer: a top-level overview, then the practical guide, then the deep reference. Give each reader the door that fits.

9.2 One source of truth per topic

Every topic has exactly one home. When two docs describe the same thing, they drift, and the reader can't tell which is right. If information must appear in two places, one is the source and the other points to it. A fact with two owners is a fact with none.

9.3 A decision is written with its rejected alternatives

Law 3, applied to docs. A decision record isn't "we chose X." It's "we chose X over Y and Z, because, on this date." The rejected options are the valuable part: they stop the re-debate six months later, and they explain the choice to someone who wasn't there.

9.4 Freeze, don't delete

An obsolete plan or doc is not deleted. It's marked obsolete, dated, and left with a pointer to the living version. Deletion loses the reasoning, and the next person rediscovers the dead end from scratch. Freezing keeps the history cheap and the lesson intact.

9.5 The trap: text that describes code is verified by no one

A comment or a doc that says "this function returns X" is checked by nobody. The code can change and the sentence stays, now lying with total confidence. Prefer descriptions that can be checked (a test, a type, an example that runs) over prose, and treat any doc you wrote yourself as a dated hypothesis until you've re-verified it against the real thing (Law 7).

9.6 The self-sufficiency test: a cold newcomer

There's one test for whether your docs are infrastructure and not decoration: can a cold newcomer, a new teammate or a fresh AI agent with no memory of the project, become productive from the docs alone. If they have to ask you, the docs failed, and you have become the single point of failure. Write so the person who wasn't there can start without you. Self-sufficient documentation is what lets you hand off, step away, or bring someone in without re-explaining the whole world.