Coldstart has not been released. This section describes how the development build behaves; there is no release you can install today, so read it as a description of the method rather than instructions you can follow tonight.
The previous section ended at the pointer, which is an address and nothing more. This section is about what the address leads to: the project's own record, and the maps that make it findable without anyone maintaining a second list by hand.
The question is practical. A fresh session opens the order app after the terminal that planned it has gone. Can it find the approved export fields, the rejected background-job idea, the historical ID exclusion and the next route without trusting somebody's recollection?
The two pages
| # | Concept | What it covers |
|---|---|---|
| 3.1 | The project record | Where a durable fact lives, what makes it a typed fact rather than a note, and why exactly one place owns it |
| 3.2 | Generated maps | Why the index is regenerated rather than maintained, and what a parity check does and does not prove |
Why memory is a filing problem, not a recall problem
The instinct is to make the agent remember more. That is the wrong axis. An agent's recall of a conversation is not evidence about the project; it is a report about a conversation that has already ended, and it cannot be checked against anything.
So the method treats memory as filing instead. A durable fact goes somewhere with a name, in a shape a parser can read, and it stays there until someone deliberately retires it. Retrieval then becomes a read, and a read can be verified: either the file says that or it does not.
That trade is deliberate and it costs something. Filing is work at the moment you least want to do it, at the end of a session, about something you currently remember perfectly well. The whole argument for paying that cost is that in three months nobody will.
The one rule both pages obey
Everything in this section follows from a single division: one fact has one owner, and anything derived from it is regenerated rather than maintained.
The first half is what 3.1 is about. If the same decision is recorded in two places, they will disagree, and the disagreement will be discovered by someone acting on the stale one.
The second half is what 3.2 is about. An index is derived from the things it lists, so writing it by hand creates a second source of truth that goes wrong the first time someone adds something and forgets a row. Regenerating it from what is actually on disk lets a parity check detect represented disagreement instead of asking someone to compare two lists by eye. It does not establish correctness, currency or wise ownership.
The same facts without Coldstart
You can keep the approved fields, rejected option and deferred ID work in a design note and maintain an index by hand. For a small project with one active reader, that may be enough. The repeated cost arrives when facts move, several people add notes, or fresh sessions search from different starting points.
Coldstart gives those facts typed homes and regenerates the map from them. It improves findability and makes one kind of disagreement checkable. It does not turn files into human memory, prove the filing is complete or notice a decision that stayed in chat.
What this section does not cover
It covers what the project remembers, not how the right instruction reaches a session. Those are different shelves with different disciplines: a project fact normally has one owning subject, while a reusable method may be looked for from several directions at once. Routing is the next section.
It also does not cover what is enforced rather than remembered. A rule that matters must not depend on any part of this section working, and that is section 5.
Next
Start with what is written by hand: the project record.