The Evidence Graph — Plates

Evidence graph · component plates

What the parts are, and what moves between them

Two drawings. The first is one action being governed. The second is a proof leaving the system and being checked by someone who does not trust us. Every box below is real code with a real file behind it.

PLATE 1 One action, governed

Left to right in time. The grant is sealed before any work — that ordering is the product. An envelope written afterwards can be shaped to excuse whatever happened.

BEFORE ANY WORK AUTHORITY GRANT who · what verbs · where valid until · sealed grounding: prior_decision AGENT PROPOSES verb · environment resource · derived from THE GATE 7 predicates vs the grant same inputs → same verdict, forever refused REFUSAL, SEALED every failed predicate, expected vs actual gate version · hash of the exact inputs the action never runs a refusal is evidence, not an absence permitted PERMIT + PROPOSAL sealed. the permit cannot be forged by a caller THEN, AND ONLY THEN ACTION RUNS the executor does the thing EXECUTION, SEALED what we ASSERT changed POST-CONDITION, SEALED read the world back. agrees, or not. The last two boxes are separate on purpose: one records what the tool SAID it did, the other records what the world SAYS happened. A tool that reports success and changes nothing is caught exactly here — and the disagreement seals as a failure. Everything sealed in this plate is written by something OTHER than the agent.
Four claims per action, and the agent authors none of them. If the thing being investigated writes its own record, you have a log. The grant is sealed by whatever opens the session, the proposal and refusal by the gate, the execution by the executor, the post-condition by an independent read.

This plate is no longer hypothetical — a real production refusal, walked step by step with claim IDs and sequences, is in the reference doc under A production refusal, sealed. It governs work driven through the agent harness; the platform's own in-cluster autonomous routes are a separate build.

PLATE 2 How a proof leaves the building

Sealed entries take two independent paths: one builds meaning, the other builds proof. They answer different questions and neither substitutes for the other.

SEALED ENTRIES hash-linked, append only + each new entry Ed25519-signed MEANING PROOF PROJECTOR builds claims + the 4 edge types THE GRAPH claims bound to their neighbours COHERENCE VERIFIER does this contradict itself? answers: was it ever SOUND? CHECKPOINTER many entries → one Merkle root TIMESTAMP AUTHORITY signs the root — outside, not us ANCHORED ROOT 514 of 514 checkpoints, today answers: UNCHANGED, and WHEN? EXPORT BUNDLE entries + proofs + anchors AUDITOR · STATIC VERIFIER checks the bundle in their browser NOT BUILT YET PUBLIC JWKS the signing key + the exact payload template. no login. live today.
Two paths, two different questions. The proof path answers is this unchanged, and when did it exist. The meaning path answers was it ever sound. A record can pass the first and fail the second — one did, in production, for four days.

Three separate properties, and it's worth keeping them apart when you talk. The chain says the record is unaltered. The external timestamp says it existed by a moment we don't control. The per-entry signature — added 16 August 2026 — says who attested to it, and the key needed to check that is published at an unauthenticated URL, so a stranger fetches it once and verifies offline from then on. The bundle carries all three today. The verifier page still does not exist, which is why the auditor box is dashed: an auditor can verify the bundle, but today they need their own tooling to do it.