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, adapter, checks, and limitations on the result.
The default example is indeterminate: its receipt-scoped checks run, but artifact bytes are not revalidated. Passed checks do not become a valid verdict when required evidence or trust inputs were not independently checked.
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. An internal limited-pass maps to public indeterminate. The result names the receipt-scoped checks that ran and the required evidence, artifact, authorization, workflow, signature, or trust checks that remain incomplete.
Separate internal package path: manifest integrity, artifact-byte revalidation, signature verification, and production trust evaluation require the full package and explicit trust inputs. They are not what /verify performs, and the canonical full verifier is not currently a supported public distribution.
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-only 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.
For receipts using the legacy-named public_exposure_review profile, the public adapter validates the witnessops.receipt.v0 workflow profile and real OffSec manifest artifact-ID syntax. The result remains indeterminate while the request, authority, full workflow, manifest and artifact bytes, evidence support, signature, and production key authorization are not independently checked.
Verify First sample paths
Use the live library and verifier surfaces to inspect current sample cases and move into the receipt-only 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.