Verify First (Quickstart)
Bounded, mechanism-first receipt verification with explicit execution, proof, evidence, and interpretation separation.
Public job: open /verify, upload or paste receipt JSON, and read the result.
Use this quickstart when you need a first-pass receipt check without collapsing execution, proof, evidence, and interpretation into a single claim.
Start here (public tool)
- Go to Verify a receipt.
- Upload a
.jsonreceipt or paste the JSON. - Select Verify receipt.
- Read the verdict, checks passed, and limitations on the result.
A valid public result confirms the checks named in that receipt. It does not prove that every underlying action was correct.
Scope and bounded references
- Public tool: /verify (receipt JSON only).
- Full verification semantics: How to Verify a Receipt.
- Receipt context: Receipts.
- Field-level requirements: Receipt Spec.
- Trust-boundary assumptions: Threat Model.
Public verifier boundary
Default path (this quickstart): use public /verify only against supported receipt JSON. A public valid result means the receipt-scoped checks for that input passed (including when the adapter maps internal limited-pass → valid). It does not mean artifact bytes were recomputed, the proof bundle is complete, or every outside trust condition was established.
Optional offline extension: bundle-complete checks (manifest integrity, artifact-byte revalidation, full timestamp-token validation) require offline tooling and the full package. They are not what /verify performs. See How to Verify a Receipt procedures A vs B.
Execution, proof, evidence, and interpretation are separate lanes
| Lane | Question answered | Output |
|---|---|---|
| Execution | What action was performed and by whom? | Operational event record. |
| Proof | Did deterministic verifier checks pass on supplied artifacts? | Per-check pass/fail/indeterminate status. |
| Evidence | Which artifacts were actually available to verify? | Receipt and referenced materials with integrity status. |
| Interpretation | What decision should a reviewer make? | Human policy and risk conclusion with assumptions documented. |
Treat these lanes independently. A strong proof result does not replace interpretation, and interpretation without verified evidence is unsupported.
Procedure (public /verify first)
- Start with the receipt JSON only for the public path.
- Run the public receipt-first flow at
/verify(or the flow rendered below for this quickstart). Do not treat optional bundle materials as part of the public result. - If you later perform offline bundle-complete checks, record them as a separate procedure (verification doc procedure B).
- Record outcomes per step and tie each outcome to the inspected evidence.
- Make policy or incident conclusions only after listing unresolved assumptions.
Verify First sample paths
Use the live library and verifier surfaces to inspect current sample cases and move into the receipt-first verification lane:
Canonical verifier flow
This sequence is rendered from the shared verifier-flow contract used across verify-first surfaces.
1. inspect operation claim
Read the claimed operation fields (actor, target, scope, action, and policy identifiers) and confirm they match the event under review.
2. inspect raw receipt
Inspect the unmodified receipt payload, including proof stage, schema version, and signed body bytes before any normalization.
3. verify signature and timestamp
Verify receipt signature material and validate timestamp token binding, issuer chain, and accepted time window.
4. verify referenced artifact completeness
Check that every artifact referenced by the receipt is present, hash-matching, and not silently omitted. If a manifest or proof bundle is available, include those completeness checks here.
5. inspect chain continuity
Follow predecessor links across receipts to confirm continuity, expected ordering, and absence of chain breaks.
6. review remaining trust assumptions
List unresolved assumptions (key custody, timestamp authority trust, host/tool integrity, identity binding) before relying on the result.
What this proves
- The receipt can be inspected as claimed input, including raw fields used by the verifier.
- Signature, timestamp, referenced-artifact integrity, and continuity checks passed under the configured verification policy.
What this does not prove
- It does not prove the operation was correct, safe, or authorized beyond evidence represented in the receipt and referenced artifacts.
- It does not prove external organizations, identity providers, or infrastructure are trustworthy.
Remaining trust assumptions
- Signing key custody, rotation, and revocation handling remain trusted.
- Timestamp authority operation and certificate trust remain trusted.
- Verifier implementation, hash/signature primitives, and runtime integrity remain trusted.
- Identity-to-subject mapping and policy configuration remain trusted.