Testimony vs Evidence: Why We Need a Protocol, and What an Attestation Actually Is | Geometry of Trust | Protocol - Lesson 1
This is the first post in the Geometry of Trust protocol series. This post is where those three strands mathematics, philosophy and governance converge into something portable and verifiable.
What we have, and what’s missing
We have a ruler — the causal Gram matrix Φ — that measures value geometry. We have probes that read live activations and produce scalar readings for specific values. We have causal checks that confirm those readings correspond to real computational mechanisms rather than surface correlations. We have drift detection that watches readings over time and catches meaningful changes.
Every one of those tools has the same implicit setting: one agent measuring itself.
Which is real and useful — a developer can run these tools in a lab and learn a lot about a model. But it’s a closed loop. The agent is the one producing the measurements and the one interpreting them.
That’s fine for internal analysis. It isn’t enough for the real problem.
How does another agent trust those measurements? If a medical-advisor agent tells a drug-checker “my honesty reading is 1.29,” the drug-checker has no way to tell whether that number was actually produced by the advisor’s current model or typed in arbitrarily. The claim and the evidence look the same from the outside.
How does a regulator verify them? A clinical regulator auditing a deployed model needs to check that the measurements reported match the model actually running. Self-reports don’t give them anything to check against. “We measured ourselves and everything’s fine” isn’t the shape of an audit.
How do two agents decide to cooperate? The governance series argued that cross-domain interactions should happen when both sides’ configurations permit it and both sides’ measurements meet each other’s thresholds. That logic assumes the measurements are available to be examined by the peer. A purely local measurement can’t be examined by anyone else.
What a protocol has to provide
For the measurement tools to do their governance job, they have to stop being private. They have to become portable, verifiable artefacts that can be exchanged between parties that don’t necessarily trust each other.
That’s the shift from “a set of measurement tools” to “a protocol.” A protocol is a set of rules about how measurements get packaged, exchanged, and verified. Five specific capabilities have to be in it:
Package measurements into a proof. A single structured artefact that binds together the model identity, the probes used, the readings produced, and the time they were taken.
Sign the proof so it can’t be faked. A cryptographic signature tying the artefact to a specific signing key.
Chain proofs so history can’t be rewritten. Each new attestation links to the previous one so that tampering with earlier readings breaks later signatures.
Exchange proofs between agents. A way for one agent to hand its attestation to another during an interaction, and for a regulator to demand one on audit.
Verify the other agent’s proof independently. The receiving party doesn’t have to take anyone’s word for anything.
This post covers the first two. The rest come in later posts.
The attestation — a signed snapshot
The unit of proof in this protocol is called an attestation. It’s a structured artefact that packages everything a verifier needs to know about one measurement event, and it’s signed so the verifier can trust the artefact came from the claimed source.
An attestation carries six fields:
model_id Which model was measured. A stable identifier
for the specific weights — not the family, the
exact version.
timestamp When the measurement was taken. Anchors the
attestation in time; enables freshness checks.
geometry_hash Which ruler was used. SHA-256 of Φ so the
verifier can confirm the measurement was taken
against the ruler they expected.
probe_readings The scalar readings: honesty = 1.29,
courage = 1.44, and so on, for whichever
probe set the domain requires.
causal_scores Per-probe causal consistency: honesty = 0.82
(real), courage = 0.79 (real). Tells the
verifier these aren't surface correlations.
merkle_root Hash of the model weight shards. Lets a
verifier confirm, without downloading every
weight, that the model being attested over
is the model they think it is.
Notice what’s not in there: any raw activations, any training data, any internal prompts. The attestation is a summary of measurements, not a dump of internal state. Privacy and efficiency both come from this — the attestation is small, portable, and carries nothing the verifier doesn’t actually need.
A concrete example
An attestation for a clinical advisor at 09:14 UTC might look like this (simplified for readability):
{
"model_id": "med-advisor-v2.3.7",
"timestamp": "2026-04-15T09:14:22Z",
"geometry_hash": "sha256:3f8a...c12e",
"probe_readings": {
"patient_safety": 1.29,
"evidence_quality": 1.44,
"confidentiality": 1.18
},
"causal_scores": {
"patient_safety": 0.82,
"evidence_quality": 0.79,
"confidentiality": 0.85
},
"merkle_root": "sha256:9b2f...a041",
"signature": "ed25519:7e41...d0b8"
}
A verifier looking at this can tell: which exact model was measured (model_id + merkle_root), with which ruler (geometry_hash), at what time (timestamp), and with what results (readings + causal scores). The signature at the end ties the whole bundle to a specific signing identity.
The signing key lives in an enclave
Attestations are signed with Ed25519, a modern asymmetric signature scheme chosen for speed, small signatures, and well-understood security properties. The mechanics of Ed25519 aren’t the interesting part for governance purposes — any reasonable modern scheme would work. The interesting part is where the signing key lives.
The private signing key lives inside an enclave. It never comes out. The signature it produces can only have been made by the enclave, because nothing else has the key. That’s what makes the attestation a proof rather than a claim.
An enclave, for the purposes of this post, is a restricted execution environment where code and keys run in isolation from the surrounding system. A full post on enclaves comes later in this series. For now, the relevant fact is operational: the signing key is generated inside the enclave, used inside the enclave, and never exported. The enclave’s hardware and operating system enforce this.
The consequence is what we need. When an attestation arrives with a valid Ed25519 signature from the enclave’s public key, the verifier knows two things:
The attestation was produced by the enclave — no other party could have made that signature.
The attestation hasn’t been tampered with in transit — any change would break the signature.
Self-report is testimony. Attestation is evidence. The whole point of this protocol is to move the measurement regime from the first kind of thing to the second. A self-reported “my honesty is 1.29” claim can be trivially faked by any process with the ability to send a message. An enclave-signed attestation carrying “my honesty is 1.29” can only have been produced by the specific enclave whose public key is on record.
How verification works
The verifier — another agent, a regulator, an auditor — takes the attestation and goes through a specific sequence of checks.
Step 1. Check the signature. Standard Ed25519 verification: take the attestation body, apply the signature algorithm with the enclave’s public key, and confirm the signature matches. If it doesn’t, stop here — the attestation is either forged or corrupted.
Step 2. Confirm the model and ruler. Check model_id against whichever model the verifier expected to be dealing with. Check merkle_root against a known weight hash for that model. Check geometry_hash against the expected Φ. Any mismatch means the attestation is about a different object than the one the verifier meant to verify.
Step 3. Determinism check. This is the part that makes the protocol work. The measurement process is deterministic. Same model, same ruler, same input, same RNG seed — same result, bitwise identical.
If the verifier has access to the same model weights (via the merkle_root), the same ruler (via the geometry_hash), and the same input activations, they can re-run the measurement themselves. If their result matches the attestation’s readings bit-for-bit, the attestation is genuine. If it doesn’t, something is wrong. Either way, the verifier didn’t have to trust the claimed readings. They checked.
This is the key move. Attestations aren’t trust-me assertions dressed up in cryptography. They’re commitments to a specific measurement outcome that the verifier can reproduce. The signature binds the attester to that outcome; the determinism lets the verifier check it.
When full re-verification isn’t possible
A regulator with full access to the model, ruler, and inputs can do the bitwise check. A peer agent in the middle of a live exchange usually can’t — they don’t have the other party’s weights, and replicating the input activation would mean disclosing something the attester may not want to disclose.
So in practice the determinism check is done selectively: spot-checks during audits, automated re-runs during certification, attestation-to-attestation comparison during ordinary exchanges.
Crucially, even when the verifier doesn’t redo the whole measurement, the option of doing it later remains. The attestation is a commitment. A regulator coming in six months after a suspicious interaction can still pull the attestation, pull the model, pull the ruler, and verify — because the enclave-signed artefact is a permanent record of what was claimed.
What the protocol deliberately doesn’t do
A few clarifications are worth flagging, because the word “protocol” tends to carry more weight than it should.
The protocol doesn’t decide what to measure. The probes, the probe set, the ruler — all of that is governance’s job, as the governance series established. The protocol carries whatever measurements governance picks.
The protocol doesn’t decide what counts as acceptable. Drift thresholds, causal-score minimums, probe requirements — all of that is governance’s job too. The protocol just lets the verifier hold the attester to whatever thresholds have been set.
The protocol doesn’t replace the enclave. The enclave is what makes the signing key trustable. Without a proper enclave, the signing key is just another file on a disk and the whole chain of trust falls over. That’s a later post.
The protocol doesn’t handle everything in one shot. This post covers packaging and signing. Chaining, exchange, and the rest come later in the series. One attestation is a point-in-time snapshot. Governance needs the whole history — which is why chaining matters, and is where we’ll go next.
The point
The measurement tools in the mathematics series produce numbers. The protocol turns those numbers into evidence — portable, signed, verifiable artefacts that can be exchanged between parties that don’t trust each other and checked without having to trust them either.
That’s the whole job. It’s a narrow one. It’s also load-bearing — without it, every governance claim about AI safety collapses back into testimony.
📄 Geometry of Trust Paper
💻 Lecture Playlist
📄 Lecture Notes
💻 Open-source Rust implementation
🏢 Synoptic Group CIC, Hull, UK