Proof Artifact Classes
Current WitnessOps artifact names, authorities, and status across live docs, app surfaces, and retained-reference material.
This page is the artifact-class naming contract for operators, approvers and reviewers, and integrators. Use it to keep artifact names consistent across public docs, /verify, /api/verify, and retained-reference verifier or corpus material.
Quick reference links
- Reference
- Commands
- Proof Artifact Classes (current page)
- Glossary
- man witnessops(7) — draft; not published as a primary public page
1. Problem this page solves
Artifact labels drift fastest at the boundaries between execution, verification, and review. This page prevents drift by defining the current class names, ownership authorities, status labels, and where each class is used.
2. Who uses this reference and expected outcome
After this page:
- operators can map run outputs to the correct artifact-class names
- reviewers and approvers can separate live and public classes from retained-reference-only classes
- integrators can avoid promoting internal or corpus-only terms into public contracts
3. Current artifact classes (public vocabulary)
| Artifact class | Current authority | Status label | Where it appears now | Contract note |
|---|---|---|---|---|
receipt | WitnessOps receipt contract | live / public | Receipts, Receipt Spec, How to Verify a Receipt, /verify, /api/verify | Atomic proof statement for governed events in the current public lane. |
proof bundle | WitnessOps bundle + verification contract | live / public | Evidence Bundles, How to Verify a Receipt, /verify explanatory copy | Portable package for receipt-linked trust artifacts. /verify v1 does not accept bundle uploads. |
manifest | Bundle-verification lane (MANIFEST.json) | current verifier / bundle term | Evidence Bundles, Receipt Spec verification model | Inventory and digest anchor inside a proof bundle. |
verification result | Verification contract + verify response contract | live output term | How to Verify a Receipt, Receipt Spec, /api/verify responses | Output semantics are valid, invalid, indeterminate at contract level. |
witness record | Retained-reference verifier or corpus vocabulary | retained-reference / corpus class | Retained-reference fixtures, corpus vocabulary, and internal taxonomy surfaces | Not a first-class live or public artifact class for operator-facing docs. |
runtime trace | Retained-reference verifier or corpus vocabulary | retained-reference / corpus class | Retained-reference fixtures, corpus vocabulary, and internal taxonomy surfaces | Keep as retained-reference terminology unless a live lane freezes it. |
proof-object | Retained-reference verifier or corpus vocabulary | retained-reference / corpus class | Retained-reference fixtures, corpus vocabulary, and internal taxonomy surfaces | Do not equate this class with generic prose "proof object" without an explicit lane freeze. |
delivery record | Control-plane delivery lifecycle (witnessops-control-plane) | planned, not live | Internal delivery lifecycle code and tests | Not a public proof-artifact class in the current docs contract. |
acknowledgment | Control-plane post-delivery lifecycle (witnessops-control-plane) | planned, not live | Internal delivery lifecycle code and tests | Delivery-state term, not a frozen live or public artifact class. |
4. Status semantics and verification-result semantics
Artifact-class status labels
| Status label | Meaning | Interpretation boundary |
|---|---|---|
live / public | Current class name for public docs and operator or reviewer-facing surfaces | Safe to use in current public documentation and route-level explanations |
live output term | Current public output vocabulary from verification-facing surfaces | Use for result reporting; do not expand beyond stated verification scope |
current verifier / bundle term | Active term inside bundle-verification structure | Treat as bundle-contract vocabulary, not a generic runtime-event label |
retained-reference / corpus class | Observed in retained-reference verifier or corpus material | Do not present as guaranteed live or public class behavior |
planned, not live | Name appears in internal or planning lanes but is not frozen publicly | Must be marked non-live; not a public contract claim |
Verification-result status semantics
For verification output interpretation:
valid: required checks for the declared scope passedinvalid: one or more proof-bearing checks failedindeterminate: an external trust requirement was declared but could not be established locally
Current /api/verify v1 for supported receipt inputs is receipt-first and returns deterministic receipt-lane verdicts, while malformed or unsupported input classes are reported separately (FAILURE_INPUT_MALFORMED, FAILURE_INPUT_UNSUPPORTED).
5. Explicit scope limits and non-claims
This page is a naming and status reference only. It does not:
- freeze a full, universal proof-object ontology
- widen
/verifyv1 into full bundle-upload or artifact-byte revalidation claims - promote retained-reference or corpus-only terms into live or public operator contracts
- replace Verification, Receipt Spec, or Threat Model
- expose internal-only proof implementation detail through operator-facing surfaces
6. Operator and reviewer crosslinks
Operator lane
Reviewer / approver lane
7. Next-page handoff
Next, read the FAQ for common interpretation questions before applying this taxonomy in reviews or operator reports.