Coldstart has not been released. The behavior on this page runs in the development build; there is no release you can install today.
You queue the historical-ID work as an item in the record. Now something has to list it, or nobody will find it. A map is that list — what is filed and where — sitting at the root of the record and at the root of each room.
Nobody writes it. It is regenerated from the files it describes, which is what stops a filed fact and a contents page from being two edits you have to remember to make together.
The ordinary alternative
A hand-maintained contents list does the same job. For a small record it is cheaper, and there is no reason to prefer machinery over it.
The cost arrives with the second edit. Adding the historical-ID item means adding the item and updating the index, and it needs a reviewer who notices when the second half is missing. Here, regeneration adds the row mechanically. If the saved map still lacks it, the parity check reports the difference rather than leaving it for someone to spot.
Regenerate, or check
The generator has two modes, and the second is what makes the first trustworthy.
| Mode | What it does | Result |
|---|---|---|
| Regenerate | Rewrites every map from the current tree | Safe at any time; running it twice changes nothing, because the output is a function of the input |
| Check | Runs the same derivation without writing, then compares against disk | Fails when they differ, naming the file that moved |
That comparison is the parity check. It converts "someone may have edited a map" and "someone may have forgotten to regenerate" into a red result that a close or a maintenance pass can act on.
There is a second projection built the same way: the index that routes a request to a reusable capability, derived wholesale from each routable item's own declared metadata rather than a separately authored row. It has the same regenerate-and-compare boundary. What that index is used for is the next section's subject.
What a map is allowed to contain
Every value in a generated map is one of four things: a name, a path, an item's own one-line subject, or a count. There is no field through which anything else could arrive.
That is stronger than a rule against writing prose in a map. A map with a paragraph in it is not a map that broke a rule; it is a string the generator cannot produce. So comparing a file on disk against a fresh regeneration catches two different problems in one operation — an item missing from the list, and payload added to it by hand.
The same restraint governs scope. Each map lists only its own children: the record root lists its rooms, and each room lists its own items by compartment. No map covers another map's territory, so there is never a question of which list is authoritative for a given item.
What the generator refuses to do
The generator re-lists, and nothing else. Each boundary is drawn on purpose.
| It refuses to | Because |
|---|---|
| Half-generate — if any item cannot be parsed, nothing is written and the defect is reported with its path | Writing the maps anyway would silently drop that item from the list, which is the exact drift the mechanism exists to prevent |
| Create a room, move an item, or decide a room has grown too big | Those are structural changes needing judgment; a tool that reorganises your record while updating its index is doing two jobs with one announced |
| Edit an authored file | The maps are machine-owned and the items are yours; that separation is what makes it safe to run the generator without reading its diff first |
Splitting a room stays a deliberate act you take. Regenerating the map afterwards is the mechanical half that follows.
When it runs
Regeneration is mechanical and cheap, so it runs as part of a normal close rather than being something to remember. The parity check runs alongside the project's other checks, which means a stale map surfaces as a red check in the ordinary flow rather than as a discovery weeks later.
Run it by hand after anything that moved or renamed a lot of files, and after any pass where you edited the record heavily. It is also the correct first response to a map that looks wrong: regenerate, and read what changed.
Limits
At the moment parity runs, a match says the saved list equals a fresh derivation from the disk. That is all it establishes.
It is not evidence that the record is complete, that the items are current, or that anything filed is correct. A regenerated map over a set of stale decisions is a perfectly accurate index of stale decisions, and it will pass every check on this page while doing it.
It cannot see what was never filed. The projection lists what exists; nothing in it can notice a decision that was made in conversation and never written down, which is the most common way a record goes wrong.
The parity check is only as useful as its running. It is wired into the close and into the maintenance pass, so a project whose sessions close properly gets it automatically. A project where closes are skipped gets stale projections and no signal, and no part of this mechanism can compel the close to happen.
Parity is about represented agreement, not quality. It detects when the stored view and a fresh derivation disagree. It does not establish that the source represents reality, that the map contains every fact the project needs, or that the chosen owner is wise.
Next
That is what a fresh session can find. The next question is what instruction reaches it, and why the answer is not "load everything": guidance.