Proof Model
What gets signed, timestamped, and verified in the WitnessOps proof chain.
The proof model defines how governed actions become portable, challengeable evidence instead of one-time runtime events.
1. Problem this page solves
Execution alone does not preserve trust. A step can run, succeed, and still be impossible to challenge later if proof artifacts are missing or weak.
This page defines the exact proof path in WitnessOps from governed action to independent verification.
2. What you should understand after reading
After this page, you should understand:
- what gets signed
- what gets timestamped
- what gets chained
- what can be verified independently later
- what still requires external trust
3. Mechanism-first proof sequence
WitnessOps proof flow works in this strict order:
- Governed action occurs. Runtime policy, scope, and approvals determine whether the step executes.
- Execution artifacts are captured. The system records the operation result and proof-relevant references.
- Receipt is issued. A structured statement is signed by the issuer key to bind intent, actor, result, and continuity references.
- Proof layers are attached. Optional timestamp and publication/continuity material strengthen the claim set.
- Proof is packaged for transport. Bundle artifacts and trust material enable local replay by a third party.
- Later challenge/review is performed. A verifier checks integrity, signatures, time/publication layers, and continuity based on declared claims.
What each proof layer adds
| Layer | What is bound | What it proves |
|---|---|---|
| Issuer signature | Structured receipt statement | Issuer-bound claim integrity |
| Timestamp layer | Digest of signed receipt envelope | Claimed signed object existed before declared time |
| Continuity/publication layer | Receipt sequence linkage and log/checkpoint references when present | Claim is connected to an append-only continuity story |
Execution creates events. The proof model determines which of those events remain challengeable later.
4. Observed vs inferred
| Category | Included material | Confidence boundary |
|---|---|---|
| Directly captured | Signed receipt fields, digest bindings, continuity links, declared bundle artifacts | Cryptographically or structurally testable |
| Derived claims | Operational narrative assembled from artifact order and relationships | Depends on correct interpretation of captured artifacts |
| Presentation summaries | Dashboards, status rollups, human summaries | Useful for operations, not proof-bearing by default |
5. Trust assumptions
The proof model reduces trust requirements, but does not remove all trust:
- Origin-system assumptions: upstream systems feeding identity/scope/context are accurate.
- Execution-environment assumptions: runtime host, key custody, and pipeline controls were not compromised outside captured proof layers.
- Operator/input assumptions: provided intent and target context were truthful and policy-aligned.
- Trust-root assumptions: verifier has authentic key and trust anchor material.
6. Next-page handoff
Next, read Evidence Bundles to see the concrete container that carries this proof model to independent reviewers.
Then use Verification to run the deterministic checking sequence and interpret valid, invalid, and indeterminate.