NodeVersion is immutable, by construction
Append-only, hash-linked: the world at any past moment is reconstructable.
A world model that overwrites its own history cannot answer the question an auditor asks: what did the world look like when you made this decision? The NodeVersion is the answer — an immutable, append-only, hash-linked record of every change, so the state of the world at any past moment is reconstructable bit-for-bit.
Every node in the GNL carries versions. A version is immutable — change does not overwrite; it creates a new NodeVersion that links to the previous one. The chain is hash-linked (BR-842), which means the state of the graph at any past moment is reconstructable by walking the chain to that point. That is the property that makes the manifest provenance claim meaningful: when the manifest says the model read NodeVersion v42 of node X, that version still exists, unchanged, and a third party can read it.
Append-only, not update-in-place
The database row for a node is not the node; it is the latest version of the node. The history is a sequence of immutable NodeVersion rows, each linking to its predecessor. An update is an insert, not an UPDATE. That is more expensive in storage and simpler in reasoning — you never have to wonder whether a value changed since you read it, because the value you read is a version, and versions do not change. The trade is storage for integrity, and for a world model whose entire value is you can replay the past, it is the only trade that works.
Hash-linked (BR-842)
Each NodeVersion carries a hash of its content and a hash-link to the previous version. Tampering is detectable by construction: change a past version and the chain breaks at the next link. That is what makes the chain an audit artifact, not a log file. A log file can be edited; a hash chain cannot be edited without breaking. The manifest records which NodeVersions the model read; the chain lets a third party verify that those versions are the ones that existed at that time, unmodified.
An update is an insert, not an UPDATE. You never wonder whether a value changed since you read it — the value you read is a version, and versions do not change.
- Immutable by construction: change creates a new NodeVersion, never overwrites.
- Hash-linked (BR-842): tampering breaks the chain; the past is verifiable, not just stored.
- Replayable: the manifest records which versions the model read; the chain still has them.
What this costs, and what it buys
Append-only storage costs disk and query complexity — give me the current state is now give me the latest version, which is a query, not a read. The payoff is that the world model is a historical record, not a present-state cache. A regulator asking what did the system know when it made this call on March 3rd gets an answer, not a reconstruction. The manifest provenance field points at NodeVersions that still exist.
Why immutability is the substrate property
The manifest attests reproducibility. Reproducibility requires that the inputs the model read are the same inputs a third party can read now. If the inputs can change in place, the manifest is attesting a computation against inputs that no longer exist — which is a signed record of something that cannot be checked. Immutability is what makes the manifest honest: the versions it points at are the versions that are there. We are pre-revenue, building the POC; the versioning is built, the chain is built, and the graph is inert until calibration fills it with real data.
A world model that overwrites its past cannot answer what did you know when. A world model that appends can. The trade is storage for integrity, and for an auditable oracle, integrity is the product.
— NodeVersion design note