Coldstart is in final cutover and has not been released. The behavior on this page runs in the development build; there is no release you can install today.
The floor holds descriptions and the card library holds methods. Most of the actual written discipline is neither: it is a body of explanatory files, each covering one idea, grouped into families by subject.
The rule governing them is a single sentence, and it is stated inside the routers themselves: read only the one file that matches, not the folder.
[Visual 4.3 — The tall stack from the section opener, enlarged. On the left, a router is drawn as a two-column table: the left column holds situations phrased as questions, the right column holds one file name each, with a note under the table reading "read exactly one row". A single arrow leaves one row and crosses to the right of the frame, where a family is drawn as a labelled shelf of small, equally-sized files; the arrow lands on one of them and it is lifted clear of the shelf, solid, while every other file in the shelf stays greyed and in place. Above the lifted file sits a small tag with four fields — "heat", "owner", "writer", "budget" — labelled "declared in one manifest, for every file in the tree". A caption reads "the shelf can grow; what a session pays is one file".]
Why single-concept files
The alternative is the long chapter, and it fails on arithmetic rather than on style.
A file covering four ideas is pulled in whenever any one of them is relevant, which means the other three arrive as well, every time. Do that across a body of guidance and the cost of consulting it stops tracking what the session actually needs. Worse, it stops being obvious that this is happening: the file was relevant, it was correctly selected, and three quarters of what it brought had nothing to do with the job.
Splitting at the concept makes the cost proportional to the need. It also makes the router's job possible: a table mapping situations to files is only useful if each file answers one situation. Measured in the development build on 10 August 2026, that body runs to a little over eighty files across ten families — none of which is loaded until a router names one of them.
The router names the file; it does not summarise it
A router's body is an index — a list of situations, each with exactly one file beside it — followed by an instruction to read that file and act on it rather than paraphrase it back.
Both halves matter. Naming one file is what keeps the family dormant; a router that opened with "here is the general shape of this topic" would have put a summary on a surface that is read every time the router fires, which is the resident-floor problem returning one level down.
Every file's cost is declared, not assumed
"Loaded on demand" is easy to claim and easy to lose. What keeps it true here is a single manifest that classes every file in the tree, and it is checked: a file that no class claims is a failure, so the manifest cannot fall behind by omission.
Each class declares four things about the files it matches.
Heat — whether the file is always present, pulled in when the work calls for it, cold, or off the session's context entirely. This is where the on-demand claim is actually recorded, per class rather than per intention.
Owner — whether the file belongs to the product, is generated from something else, or belongs to the user. This is the distinction that stops a product update from overwriting knowledge you wrote.
Writer — whether a human, a machine, or both are permitted to change it.
Budget — a byte cap.
The rule that keeps the budgets honest
A class may declare itself exempt from its byte cap, and exemption is legal only for the classes that are cold or out of context. The two hot classes — the always-present files and the ones pulled in during ordinary work — may not be exempt. A hot class with no cap is recorded in the product's own design notes as the escape hatch that sank the previous version: everything that grew, grew there, because that was the one place growth cost nothing to declare.
A second rule supports the first. Class patterns must not overlap, so no file is claimed twice. That sounds like tidiness and is not: a file matched by two classes has two budgets, and a budget that depends on which rule you read first is not a budget.
The combined effect is narrow and worth stating plainly. It does not make the guidance small. It makes every file's size a declared number that something checks, and it makes the set of files a session can pull in during ordinary work a bounded, named set rather than "whatever is in the folder".
Limits
A budget caps bytes, not relevance. A file can sit comfortably inside its cap and still be the wrong file for the situation the router matched, and nothing here would notice.
Nor does classification say the split is in the right place. Whether a concept is one file or two is an editorial judgment made when the file is written; the manifest records the outcome and has no opinion about it.
And the read-one-file instruction is an instruction. It is stated in every router and it is not enforced by anything — a session that reads a whole family gets no complaint from the machinery. What the mechanism guarantees is that the family is not resident, so reading all of it has to be a choice someone makes.
Next
Guidance is something a session consults. The next section is about what must hold whether or not anything is consulted: boundaries.
How current this page is
Checked on 10 August 2026 against the product's current file-class manifest, its budget rules and its recorded release state. The file count is what the development build carried on that date. To ask whether a claim here still holds, or to report one that does not, write to [email protected].