Verify First (Quickstart)
Bounded, mechanism-first receipt verification with explicit execution, proof, evidence, and interpretation separation.
Use this quickstart when you need a first-pass verification result without collapsing execution, proof, evidence, and interpretation into a single claim.
Scope and bounded references
- Run the verification surface at /verify.
- For full verification semantics, read Verification.
- For receipt context, read Receipts.
- For field-level requirements, read Receipt Spec.
- For adversary and trust-boundary assumptions, read Threat Model.
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
- Gather the receipt and referenced materials you plan to rely on.
- Run the canonical verifier flow rendered below; do not reorder or skip contract steps.
- 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 these sample routes to practice the same verifier lane across bounded scenarios:
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 manifest/bundle completeness
Check that every manifest or bundle entry referenced by the receipt is present, hash-matching, and not silently omitted.
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, manifest/bundle completeness, 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.