Receipts

A receipt is a portable signed claim about one bounded workflow result. It carries declared context and evidence references; it is not the evidence package and it is not proof merely because its JSON has the expected shape.

App outputs differ: External Exposure snapshots are unsigned, reports are derived presentations, and Local Audit Proofpacks have a separate signed-package checking path. Start with Understand results and reports. This page focuses on receipt profiles, not every app result.

1. Legacy review receipt profile

The canonical legacy-named public_exposure_review receipt uses:

• envelope witnessops.receipt.v0
• profile witnessops.verification_context.v1
• workflow class public_exposure_review

For this review profile, the documented sequence is:

1. request
2. scoped review
3. evidence collection
4. verification result
5. signed receipt
6. verification page

The receipt binds the final record to the declared subject, scope, method, timestamps, limitations, claim set, manifest digest, and signer identifier. Claim evidence references are real offsec_<24 lowercase hex> manifest artifact IDs produced from exported OffSec records.

2. What a receipt contains

At a high level, the public_exposure_review compatibility profile contains:

1. workflow and proof-run identity
2. subject and bounded scope
3. the frozen review method and acceptance criteria
4. observation, performance, issuance, and optional expiry times
5. the fixed product limitations
6. six required workflow claims with manifest artifact references
7. a manifest SHA-256 declaration
8. an Ed25519 signature declaration and key ID

The exact field contract is in Receipt Specification.

3. Declaration is not independent proof

A receipt can declare that evidence was collected, scope was authorized, or artifacts were hash-bound. Those statements become independently testable only when the verifier has the matching request, authority, workflow, manifest, artifact, signature, and trust inputs.

The public /verify surface currently receives receipt JSON only. For the public_exposure_review profile it checks the profile and declared relationships, but it does not receive the full package or an active production trust snapshot. A conforming receipt therefore remains indeterminate.

4. What stronger verification can establish

When a complete package is independently verified against authentic trust inputs, the checks can establish, within the declared scope:

• the signature matches the canonical receipt bytes
• the signer is authorized by the pinned production policy
• the manifest bytes match the receipt digest
• referenced artifact bytes match the manifest
• evidence references resolve and support the recorded claim status
• required limitations and unresolved states were preserved

Each conclusion must name the checks and inputs that produced it. A producer-generated verification_result.json is package output; it is not automatically an independent verification result.

5. What a receipt never proves on its own

A receipt does not by itself prove:

• that a finding is correct or exploitable
• that the reviewed system is secure
• that no vulnerability exists
• that the source tools or host were uncompromised
• that the target and approval records were truthful
• that the signer was authorized or unrevoked
• that referenced manifest and artifact bytes exist or match
• that the review is complete outside its declared scope

The legacy receipt profile also preserves the explicit non-claims that the associated review is not a penetration test, certification, attestation, compliance determination, proof of security, proof of completeness, proof of third-party acceptance, or proof of absence of vulnerabilities.

6. Compatibility receipt families

The web verifier retains bounded adapters for PV/QV/WV receipts and local-server-audit structural receipts. They are compatibility surfaces, not alternate definitions of the canonical public_exposure_review receipt.

Do not infer one universal ledger, timestamp, DSSE, or continuity layout across all accepted families. Read the adapter name, scope, artifact-revalidation field, named checks, and limitations in the actual result.

7. Next-page handoff

Read Receipt Specification for the field contract, then Verification for the public result semantics.