Touchstone

Products · Verification Bundles

A verdict you can recompute yourself

Every published verdict ships as one self-contained bundle: the signed report, the exact bytes that were signed, the approval ledger behind its control set, the compilation artifacts the controls came from, the policy manifest it answers, and a digest for every piece of evidence. Nothing in it depends on this site being honest — recompute it on your own machine and the answer is the same or it is wrong.

BUNDLES

23 downloadable

FORMAT

bundle v5, one file per verdict

NETWORK ACCESS

none required to verify

REPORTING KEY

Ed25519, carried in the bundle

Contents

What travels inside a bundle

Each section is an input to a check, not a summary of one. Together they are everything needed to reproduce the verdict from first principles.

signed_report

The report with its Ed25519 signature and the key id it was signed under. The canonical bytes travel alongside as report_canonical, so the signature is checked against exactly what was signed rather than against a re-serialisation that might differ by a byte.

approval_ledger

Every control a human approved and every candidate a human declined, with reasons. As of ledger version 2 each decision also carries the approver's EIP-712 signature over the exact proposal it decides, so the identity behind a decision is recoverable from the bundle alone. Its digest must match the one inside the signed report.

compilations

The compilation artifacts, keyed by their own digest. Each control names the artifact it was accepted in — including the model, prompt and provider response digests behind the proposal — and the report's provenance digests must be exactly this set.

control_records

The approved controls in full: subject, cited span, operator, expected value, cadence, effective period, approval state. Rehashing each record's canonical bytes must reproduce the content hash the report references it by.

policy_manifest

The policy this verdict answers — its id, version, the consumer question in plain language, and the control ids it draws on. Its digest is the policyRoot a gate pins on chain.

evidence_digests

The digest of every evidence capture the engine retrieved, with source id, role and retrieval time. These chain into the report's evidence root in a domain-separated order.

published_key

The Ed25519 public key and its key id. The report names the same key id as its publisher, so lineage checks need no external lookup — and a bundle from any date still verifies years later.

registry_v2_attestation where present

The publisher's EIP-712 attestation as submitted to a v2 registry. When a bundle carries one, verification additionally recovers the attesting address and checks that every attested field matches the signed report — the same digest the registry contract recomputes on chain.

Three ways

Verify it however you work

In the browser

Drop a bundle into the Policy Terminal. It checks the signature, the canonical bytes, the ledger digest and every approver signature, the policy manifest digest, the compilation artifacts and any v2 attestation — locally, with no upload, and it names the checks it did not run rather than implying a clean sweep.

Open the Policy Terminal →

From the CLI

One command, no network access, standard library plus a signature package. It prints a single line naming the asset key, epoch, sequence and state — or fails with the first check that did not hold.

Set it up →

By hand

Short recipes that recompute each commitment separately: the signature, the ledger digest, the compilation artifacts, every control content hash and both roots. For an auditor who would rather trust their own code.

Read the recipes →

CLI

python -m touchstone.verify bundle.json

# PASS: <asset key> epoch=<epoch id> sequence=<n> state=<state>
# FAIL: <the first check that did not hold>

Corrections

What a correction does to verification

A correction never edits a published report — it restates an epoch at a new sequence and names the sequence it corrects. Both bundles remain valid and both keep verifying: the original proves what was signed then, the correction proves what was signed after. Verification tells you a bundle is authentic, not that it is current.

Two things keep that from being a loophole. The tool that builds a correction refuses to sign one unless it reproduces the original's control-set root, evidence root and approval-ledger digest exactly — so a correction can restate a conclusion but never quietly swap the inputs it was judged against. And currency is answered by the report itself: every report carries a validUntil, and the on-chain record says which sequence corrects which, so a consumer that wants “the current verdict” reads the chain rather than the file it happens to hold.

Browse the published bundles How corrections are recorded

Limits

What the checks do not cover

The bundle carries evidence digests, not the evidence artifacts themselves, so the checks confirm which captures were used without replaying retrieval or normalisation. And no check proves an issuer's figures are true — only that they were published, evaluated against a cited predicate by an approved control, and signed. The limitations that apply to a specific report travel inside its signed bytes, where removing one would break the signature.

These pages run no JavaScript, enforced at the server with script-src 'none'; the one scripted page is the Policy Terminal, whose code is served from this host. Nothing here computes an answer on your behalf: every check runs on your machine or not at all.

Verify a report Read the limitations