evidence.v1 · ed25519

The receipt, explained

Every governed change produces one signed receipt: evidence.v1. This page is the full detail: what it contains, why it is signed the way it is, and how anyone verifies it without trusting us.

The receipt, annotated

// evidence.v1: a real receipt from our own repo, abridged. { "schemaVersion": "rootblocks.evidence/v1", "evidenceId": "observed-pr-57-d1aea6afcbf1", "operationType": "code.merge", "status": "passed", "assurance": "observed", "actor": { "type": "tool", "id": "rootblocks-scan" }, "checks": [ { "id": "review-gap", "status": "failed", "severity": "error" } ], "provenance": { "pullRequest": "Rootblocks/rootblocks-cloud#57", "review": { "decision": "merged", "reviewer": "anrasi" } }, "redaction": { "status": "not-needed", "rules": [] } } // + a detached ed25519 signature { keyId, value }
Verify a receipt offline, with only the public key: $ npx rootblocks-verify rootblocks-receipt.json --key rootblocks.pub ✓ signature valid · schema evidence.v1 · not tampered

Yes: this receipt records a failed check: an agent-authored PR that self-merged with no review, in our own repo. The scan completed (status: passed) and honestly recorded the gap. That gap is exactly what RootBlocks exists to expose.

Hand this file to anyone. They do not need us to verify it.

Apache-2.0 The receipt format is an open specification, published at standards.rootblocks.com, and so is the verifier: run it with npx, no account and no signup. Read it, fork it, or write your own from the schema. If we disappeared tomorrow, every receipt you already hold still verifies. Evidence that depends on its vendor staying alive is not evidence.
  • operationType the governed event: a merge, a run, a release.
  • provenance.agent which agent produced the change, and the model it ran. Distinct from the operation actor.
  • decisionRefs the human decision this change was authorized by, referenced by id. The anchor of the trace.
  • assurance the seal: how strongly the receipt is backed. observed, proven, traced, enforced.
  • checks gates and the enforced path scope, as they actually ran.
  • redaction what was withheld from the receipt, declared, so absence is auditable too.
  • signature detached: ed25519 over the canonical bytes, plus the signing key id.

Why ed25519

Signatures are made over the canonical bytes of the receipt, so any change to any field breaks the signature. There is no room for a receipt that says one thing and proves another.
ed25519 is a modern, widely audited signature scheme: small keys, small signatures, deterministic signing, and no certificate authority required. Verification is a single public-key operation that runs anywhere, including air-gapped machines.
The private key is generated per install and never leaves the daemon host. Every receipt carries its keyId, so rotation and revocation are part of the evidence format, not an afterthought.

Why offline verification matters

An auditor, a customer, or a regulator should not have to trust RootBlocks to check your evidence. rootblocks verify takes a receipt and the public key, and answers with mathematics, not with our word.
That is the difference between a log and evidence. A log lives inside a system that can edit it. A receipt is signed into an append-only ledger and verifies anywhere, on any machine, with no account and no network.

A policy, in full

policy: payments-tier scope: allow: ["src/payments/**", "test/payments/**"] deny: ["**/secrets/**", "infra/**"] gates: [ typecheck, test, lint ] # all required allowedTools: [ Edit, Read, "Bash(npm *)" ] limits: { maxFiles: 40, maxRuntime: "20m" } onGateFail: block # no commit, no receipt

Failure modes

Daemon down configurable per policy: fail-closed (agents cannot merge un-proven) or fail-open (run, mark observed, reconcile later).
Control plane down receipts are written locally first, into the append-only ledger, which is what runs today. Cloud sync (rolling out with design partners) resumes on reconnect.
Gate fails no commit, no receipt. The attempt itself is logged as evidence.

What leaves your infra

Leaves
Never leaves
content hashes
source code
ed25519 signatures
diffs
check metadata (pass/fail)
agent prompts
decision and PR IDs
file contents

Keys, and what the signature proves

Generated per install, on first run. The private key never leaves the daemon host.
Rotation every receipt carries its keyId, so rotation and revocation are built into the evidence format. The re-anchoring procedure ships with the enterprise program.
We prove that this execution, under this policy, was bound to this ratified human decision. We do not certify the agent internal reasoning, which is exactly why we anchor evidence in the human decision, not in the model narrative.
checks.* + decisionRefs maps to ISO 42001 Clause 8 (operational control) and SOC 2 CC8.1 (change management).