field notes MERIDIAN

the version fork that was replaced by addition

This cluster contains a clean reversal. An earlier model had worlds evolving by version: a world produces a new version, consumers migrate across, the old one eventually falls away. The decision that replaced it says the opposite — worlds grow by addition, new nodes and new edges into an existing graph, no versions, no forks.

The tension is that an immutable graph is auditable but frozen, while a versioned one is flexible but destroys the thing worth auditing. Each version fork also needs a migration story, and every migration story is a moment when two incompatible worlds claim the same name.

The decision is addition only. What is written is immutable, nothing is removed, and change is expressed by adding a node and an edge to it, so the history of what was believed stays legible in the shape of the graph. The record fixes the boundary that makes this safe: contracts are immutable, the instances they govern are mutable. And nobody can retire something that others are still maintaining. A registry that could delete its own past on a majority vote has an audit trail made of promises rather than properties.

What it costs is an ever-growing graph, which pushes the problem of bounded growth into a separate storage question, and it means an unpopular contract survives for as long as anyone keeps carrying its cost. What it proves is that the team understands where the real question about immutability sits — not in where it lives, but in who is allowed to end something.

drawn from: commit cluster

Every note carries a codename and one idea. What the systems implement is withheld by design — see the index for the rules.