Main idea

The context that absorbs a building's emails begins with a context.md file and one sentence: aggregate and split into topics. That level holds until you notice the current state has erased the history of the works — and you add a chronological log. It holds again until shared surnames and double names produce duplicate records — and you write business directives. Then the file passes a thousand lines and the model's window gets lost in it — you pull the directives out, then you split by topic. Then the technical vocabulary repeats itself in every file — you centralize it in a glossary.md.

Every step therefore has a nameable cause, and that cause is always a breakdown of the previous level, never an improvement desired in the abstract. That is what separates a rise in complexity from over-engineering: the first answers a need that has shown itself, the second an architecture you found elegant. The test is available before each storey — which concrete problem, already encountered, does this storey remove?

The resulting order isn't interchangeable either: you can only split cleanly by topic after pulling out the processing rules, otherwise you don't know what has to be copied into each piece. And at every step you have a system that works — not a half-finished building site that will only be useful once completed.

Why it matters

This reverses the way you approach a system described by someone else. Faced with a complete model — folders, load manifests, linked atomic notes — the natural reading is that of a blueprint to install; the useful reading is that of a trajectory, from which you take only the storeys whose breakdown you have already met.

It also gives a decision criterion for the versions that follow: you change version because the needs have grown, and observing that a need hasn't grown is sufficient reason to stay where you are.

Nuances and limits

Some breakdowns are predictable for anyone who has already built a comparable system, and waiting for them to happen costs a migration you could have avoided. The rule protects against over-engineering, not against naivety.

And not every breakdown shows up as a gap. A model's loss of precision on a long file raises no alert: it slowly degrades answers that stay plausible, and the next step is only taken if someone has named the mechanism in advance.

Open questions

• What, in a system already in place, indicates that it is no longer enough, when the breakdown doesn't take the form of a manifestly wrong answer?