Verifying a receipt is a fixed sequence of checks. The verifier walks the gates in order and stops at the first one that fails, returning that gate’s verdict. If every gate passes, the verdict is valid. The same Rust core runs everywhere — Python, Node, and the browser all call it — so you get the same verdict no matter where you check. See Offline verification for the full walkthrough.
The gates
The verifier resolves at the first failing gate, in this order. Each gate maps to one verdict on failure.
- Algorithm recognized — the
algstring is one this checker understands. On failure:wrong_algorithm. - Version recognized — the
action_versionis one this checker supports. On failure:unsupported_version. - Hash matches — the recomputed
action_hash(BLAKE3 of the canonical bytes) equals the embedded value. On failure:hash_mismatch. - Operator signature verifies— the operator’s Ed25519 signature checks out against its public key. On failure:
invalid_signature. - Approver signature verifies — if an approver co-signature is present, its Ed25519 signature checks out. On failure:
invalid_approver. - Redaction markers well-formed — every redaction marker is valid for its mode. On failure:
redaction_malformed. - Trust level re-derived — the trust level re-derived from which signatures actually passed equals the embedded
trust_level. On failure:trust_mismatch.
When all seven gates pass, the verdict is valid. Note that trust is never trusted as written — it is re-derived from the signatures that verified. A receipt that claims L1 but carries only a passing operator signature fails at the last gate with trust_mismatch.
Verdict states
Every result the verifier can return, with the plain-language copy the console shows.
| Verdict | Meaning |
|---|---|
valid | The content matches its signature. |
wrong_algorithm | The algorithm is not recognized, so this cannot be checked. |
unsupported_version | This version is newer than this checker understands. |
hash_mismatch | The content changed after it was signed. |
invalid_signature | The content does not match the operator key. |
invalid_approver | The approver co-signature does not check out. |
redaction_malformed | A redaction marker is not valid for its mode. |
trust_mismatch | The receipt claims a higher trust level than its signatures support. |
pending | UI only — the check is still running in the browser. |
A valid verdict proves the bytes match their signature: the operator authorized this exact action under a known policy, and at L1 that a person approved it with a device-held key. It records what was authorized, not whether the action succeeded downstream.
Core outcome strings
The Rust core returns its own outcome strings. Each maps to one verdict state. Some carry a detail suffix after a colon — for example TrustLevelMismatch:embedded=L1,derived=L0 — so a failure tells you exactly what was claimed versus what the signatures supported.
| Core outcome | Verdict state |
|---|---|
Valid | valid |
WrongAlgorithm | wrong_algorithm |
Unsupported | unsupported_version |
HashMismatch | hash_mismatch |
InvalidSignature | invalid_signature |
MalformedRedaction | redaction_malformed |
TrustLevelMismatch | trust_mismatch |
Malformed | A hard structural failure — the receipt could not be parsed. |
The approver gate has no distinct core outcome string of its own; invalid_approver surfaces in the console as the verdict for a failed approver co-signature. The pending state never comes from the core — it exists only in the UI while the browser check is in flight.
Reading a failure
Because the verifier stops at the first failing gate, the verdict tells you more than one fact: it also tells you which gates already passed. A later verdict means every earlier gate succeeded.
For example, an invalid_signature verdict means the algorithm was recognized, the version was supported, and the action_hash recomputed correctly — the bytes are intact, but they were not signed by the operator key. A trust_mismatch verdict implies the most: every signature that was checked verified, the content is intact, and the only problem is that the receipt claimed a trust level higher than those passing signatures support.
This ordering is why a hash_mismatch never tells you anything about the signatures: the verifier stopped before it checked them. There is no point checking a signature over bytes that have already changed. Read the verdict, then treat the gates above it as proven. The full gate order, and why the math runs in your browser, lives in Offline verification.
Each verdict points at a specific part of the artifact. Pair this page with the receipt schema to see exactly which field a gate reads — the alg string, the embedded action_hash, the signatures array, the redaction markers, and the embedded trust_level.