What Travels in the Exchange, and What the Verifier Checks | Geometry of Trust | Protocol - Episode 4
This is the fourth post in the Geometry of Trust protocol series. This post zooms in on the payload. Showing every field in the attestation and how it corresponds to a specific check.
Two sides of the same coin
When Alice and Bob exchange messages, what actually crosses the wire? And when the verifier takes the payload apart, what does each piece prove?
Those two questions are tightly coupled. Every field in the attestation corresponds to a specific check. Every check depends on a specific field. The attestation carries nothing that doesn’t get checked, and the verifier can’t check anything that isn’t carried.
Understanding the correspondence is understanding why the protocol is the specific shape it is.
What the attestation carries
A complete attestation carries seven pieces. Six live in the attestation body, one is the signature over it. Together they make up the unit of evidence one agent offers another.
Probe readings The scalar readings — honesty = 1.29, courage = 1.44,
and so on, for whichever probes the domain specifies.
Causal scores Per-probe causal-consistency scores. Tells the verifier
the reading isn't just surface correlation — it's tied
to a real computational mechanism.
Geometry hash SHA-256 of Φ, the causal Gram matrix. Identifies which
ruler was used to produce the readings.
Model hash Merkle root of the model weight shards. Identifies
exactly which model was measured.
Chain The history of previous attestations, each link carrying
the hash of its parent.
Domain scope The agent's declared primary domain, plus permitted and
excluded patterns and interaction modes.
Signature Ed25519 signature over everything above, produced by the
enclave's signing key.
Notice what’s still not in there: no raw activations, no training data, no internal prompts, no weights themselves. The attestation is a summary of measurements and the identifying hashes that tie those measurements to specific artefacts — not a dump of internal state.
What the verifier checks — field by field
For each piece the attestation carries, the verifier runs a specific check. The two tables read as pairs: what was packaged, and what it lets the verifier confirm.
Field Check the verifier runs Question it answers
Signature Signature verification with Was this really signed
the enclave's public key by the enclave on record?
Geometry hash Compare against registry's Is this the same ruler
expected Φ hash we agreed to use?
Model hash Compare against registry's Is this the model we
expected model hash expected — weights
unchanged since cert?
Probe readings Evaluate drift against Has the geometry moved
governance threshold further than rules allow?
Causal scores Check each score meets the Are readings genuine
minimum for "causal" mechanisms, not surface
artefacts?
Chain Walk links from anchor Is the history intact —
forward, verify each no deletions, insertions,
or silent edits?
Domain scope Match against verifier's Is this agent allowed to
own registry rules talk to us, and how?
Timestamp Compare to current time, Is this fresh — or an
(in envelope) check freshness window old attestation replayed
into a new conversation?
Why each check has to be its own thing. Checking the signature doesn’t tell you the model is right — a genuine signature on a swapped-in model is still genuine. Checking the model doesn’t tell you the measurements are fresh — the right model could still be the subject of a replayed attestation. Checking the chain doesn’t tell you the current reading is within threshold — a clean chain still needs the tip to satisfy the governance rules.
Each check catches a different failure mode. Dropping any one of them leaves an attack surface.
Everything is independently reproducible
The move at the heart of the whole protocol — the one that turns attestations from signed assertions into verifiable proofs — is that every value in the attestation can be reproduced by someone with sufficient access.
If a regulator has access to the same model weights (identified by the Merkle root), the same ruler (identified by the geometry hash), and the same input activations, they can re-run the measurement end to end and check that the readings they produce match the attestation bit-for-bit.
The re-run:
Give me the same model, same probes, same input.
I compute Φ myself, run the probes myself, get the same readings myself.
I check them against the attestation.
Bitwise identical → the attestation is truthful.
Doesn’t match → something is wrong. Forged attestation, swapped model, different ruler, tampered inputs. Any one of them would show up.
This is what makes attestations evidence rather than testimony. A self-report is something you either believe or you don’t. A bitwise-reproducible measurement is something you check. The protocol doesn’t ask verifiers to trust the readings. It asks them to verify a commitment to those readings, made by an enclave-held key, that anyone with the right access can re-run at any time.
In practice, full re-runs happen selectively — during audits, during certification, and when something looks wrong. In the middle of a live exchange, the verifier trusts the cryptographic checks on the attestation (signature, chain, freshness, thresholds) and the deeper re-run option stays in reserve for when it’s needed. That’s fine. The commitment is permanent: the attestation stays in the chain, and an auditor coming in six months later can still reach back and verify.
Links:
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK