Chains: How a Model’s History Gets Tied Down | Geometry of Trust | Protocol - Episode 2
This is the second post in the Geometry of Trust protocol series. This post covers what happens when you need more than a snapshot: a full history that can’t be quietly edited.
A snapshot isn’t a history
The last post introduced attestations: signed snapshots of a model’s value geometry at a point in time. Each one is a proof that the enclave measured these readings on this model at this moment. Verifiable, tamper-evident, cryptographically bound to the enclave that produced it.
That’s enough if the question is “what does this model look like right now?” It isn’t enough if the question is “has this model been behaving itself?”
A single attestation says: at 09:14 UTC, this model had these readings. It says nothing about what the readings were yesterday, last week, or when the model was first deployed. And without history, governance loses most of what makes the measurements useful. You can’t detect drift without comparing to an earlier baseline. You can’t investigate an incident without seeing what the readings looked like in the run-up. You can’t audit behaviour without being able to walk backwards through what was claimed and when.
Governance needs the whole history, not just the latest snapshot. And the history has to be as tamper-evident as individual attestations are. A simple list of attestations isn’t enough — someone could delete an inconvenient entry, insert a fake one, or quietly edit an old reading. What’s needed is a way to bind attestations together so that any change to any one of them breaks verification of every attestation that came after.
Each attestation points to the previous
The construction is simple. Every attestation, as part of the content it signs over, includes the hash of the previous attestation. The first attestation in the chain — the anchor — has no parent.
Attestation #1: hash = abc123, parent = (none)
Attestation #2: hash = def456, parent = abc123
Attestation #3: hash = ghi789, parent = def456
Attestation #4: hash = jkl012, parent = ghi789
The hash of each attestation is computed over all of its content — model ID, timestamp, geometry hash, readings, causal scores, Merkle root, and crucially the parent hash. That’s then signed by the enclave. So the parent hash is inside the signature, and any change to any earlier attestation in the chain ripples forward: change the content of #2, and its hash is no longer def456, which means #3’s parent pointer no longer matches what’s signed into #3, which means #3’s signature no longer verifies.
What the chain prevents
Three specific attacks the chain blocks, and it’s worth being precise about each.
Delete an attestation. Remove #2 from the chain. Now #3’s parent pointer references abc123 (#1) but the chain is missing the link between them. A verifier walking the chain sees the gap immediately — #3’s parent is abc123, but abc123 is the hash of #1, which already existed before #3 was issued. The timestamps and sequence don’t line up.
Insert a fake attestation. Slip a forged #2.5 between #2 and #3. The fake would need #2’s hash as its parent (fine, that’s public) and would need to hash to whatever #3 declares as its parent. Producing a hash that equals a specific target value is a preimage attack on SHA-256 — infeasible by design. The fake can’t fit.
Change an old attestation. Quietly edit #1 after #2 has already been issued. Changing #1’s content changes its hash from abc123 to something else. But #2’s signed content still contains parent = abc123, which no longer matches. #2 is now orphaned, #3 is orphaned through it, and the entire chain after #1 breaks.
When a verifier walks the chain and finds that a parent hash doesn’t match, or a signature doesn’t verify, the chain is rejected. The verifier can see exactly where the break happened and can distinguish “malicious tampering” from “legitimate gap in history I don’t have access to.”
A broken chain isn’t just an error — it’s evidence. A regulator seeing a broken chain knows something happened and can investigate. This is why the chain is stronger than a database of attestations. A database can be quietly edited; a chain tells you when it has been.
Walking the chain backwards
Once you have a verified chain, you have a timeline. Reading it backwards turns the sequence of attestations into an investigative tool.
A concrete case. A clinical deployment triggers a drift alert. The governance system looks at the chain:
#3 2026-04-15 11:42 UTC patient_safety = 0.91 → DEVIATED
#2 2026-04-15 09:14 UTC patient_safety = 1.29 → NORMAL
#1 2026-04-14 08:00 UTC patient_safety = 1.31 → BASELINE
By walking backwards from the alert (#3), the investigator can immediately locate the transition: the readings were normal through #2 and deviated by #3. The drift happened between 09:14 and 11:42 on the 15th. That’s a roughly two-and-a-half-hour window to investigate: what changed, what inputs came in, what updates were applied.
The chain turns into:
An audit trail. Every claim the agent ever made about its own value geometry is signed, linked, and timestamped.
An incident timeline. When something goes wrong, the chain tells you when it started going wrong.
A compliance record. Continuous evidence that the agent met its thresholds across the whole deployment, not just at point-in-time checks.
A history that can be investigated at leisure. The chain persists, so regulators coming in months after the fact can still reconstruct what was happening.
None of this requires the chain to be public, or synchronised across the world, or posted to any central registry. It just has to exist, be signed, and be available when someone with authority asks to see it.
The blockchain comparison
The construction above — hash-linked records, tamper-evident by the chaining itself — is the same basic idea that underlies blockchains. It’s worth being precise about what’s borrowed and what isn’t, because “blockchain” is a word that arrives with a lot of attached baggage and most of it isn’t relevant here.
Element In a public blockchain In this protocol
Hash-linked records Yes Yes — same mechanic
Tamper-evidence Yes, via the linking Yes — same property
Mining / proof-of-work Yes, to order blocks None. Not needed.
Tokens / currency Yes, incentivises miners None. No incentives.
Global consensus Yes — defining property None. Per-agent chain.
Public, global ledger Yes, by design No. Local; shared on demand.
Energy cost Often significant Negligible — SHA-256 + Ed25519
The right way to describe what this protocol uses: a hash-linked chain of signed attestations, maintained per-agent, verified when demanded. It borrows the tamper-evidence property from the blockchain world — and nothing else.
Everything blockchain solves by being expensive and global, this chain doesn’t need to solve. The signing key is already anchored in an enclave (more on that later in the series). The governance layer already decides who counts as an authoritative verifier. There’s no adversarial network of unknown validators to convince. The chain is a much simpler thing doing a much narrower job.
This matters for governance because the word “blockchain” usually brings up concerns about cost, scalability, and complexity. Those concerns don’t apply here. The chain costs essentially nothing to maintain — one SHA-256 per attestation and one Ed25519 signature per attestation, both of which are already being done for the attestation itself. The parent pointer is just another field that gets signed over. The chain is as cheap as the attestations are.
How the chain works in practice
Who keeps the chain. The agent keeps its own chain. Each new attestation extends the chain the agent has been maintaining since it was first deployed. A regulator, auditor, or peer agent doesn’t need to hold the chain themselves — they just need to be able to request it (or a relevant slice of it) when they need to verify something.
How far back does it go. The anchor — the first attestation in the chain — is typically set at deployment. A clinical advisor’s chain starts when it goes live in the hospital. An agricultural agent’s chain starts when it’s first configured for the cooperative. Before that point, the model was in development and a different set of governance rules applied.
Re-anchoring happens when something significant changes — a major model update, a change of primary domain (with recertification, as covered in the governance series), a change of governance regime. The old chain doesn’t disappear; it just ends at a known point, and a new chain starts from a new anchor. The transition between chains is itself auditable.
What happens when a chain breaks. A broken chain isn’t a catastrophic failure. It’s a finding. The protocol surfaces it; governance decides what to do about it. Possible responses range from mild (investigate, log, re-anchor with an audit note) to severe (suspend the agent, require recertification, revoke its trust registry entry). The protocol doesn’t prescribe which response is appropriate — that’s governance’s call. What the protocol guarantees is that the break is detectable and that the detection itself is cryptographically sound.
The point
A single attestation is a claim about a moment. A chain is a claim about a lifetime. Governance needs the lifetime.
The mechanic is simple — each attestation points to the previous one, and the parent pointer is signed into the attestation. But the property that falls out of that simplicity is exactly what governance needs: a history that can be audited, that can be walked backwards, and that can’t be quietly edited without someone noticing.
No mining. No tokens. No global ledger. Just hash-linked signed attestations, doing a narrow job well.
Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK