Proof Model
What gets signed, timestamped, and checked in the WitnessOps proof chain.
The proof model explains how a governed action becomes evidence another person can carry, challenge, and check later.
1. Problem this page solves
Execution alone does not preserve trust. A step can run and succeed, but still be hard to challenge later if the proof artifacts are missing or weak.
This page explains the exact proof path in WitnessOps from governed action to independent verification given trusted keys or anchors.
2. What you should understand after reading
After this page, you should understand:
- what gets signed
- what gets timestamped
- what gets chained
- what another person can verify later
- what still depends on outside trust
3. Mechanism-first proof sequence
WitnessOps proof flow works in this strict order:
- A governed action happens. Runtime policy, scope, and approvals decide whether the step can run.
- Execution artifacts are captured. The system records the result and the proof-relevant references.
- A receipt is issued. A structured statement is signed to bind intent, actor, result, and continuity references.
- Proof layers are attached. Optional timestamp and publication or continuity material strengthen the claim set.
- Proof is packaged for transport. Bundle artifacts and trust material let a third party replay checks locally.
- A later challenge or review happens. A verifier checks integrity, signatures, time or publication layers, and continuity based on the 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 | Existence-before-time only if the RFC 3161 token and TSA chain fully verify (not structural field presence alone in receipt-first mode) |
| Continuity or publication layer | Receipt sequence linkage and log or checkpoint references, when present | The claim is connected to an append-only continuity story |
Execution creates events. The proof model decides which of those events stay 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 it does not remove all trust:
- Origin-system assumptions: upstream systems feeding identity, scope, and context are accurate.
- Execution-environment assumptions: the runtime host, key custody, and pipeline controls were not compromised outside the captured proof layers.
- Operator and input assumptions: the provided intent and target context were truthful and policy-aligned.
- Trust-root assumptions: the verifier has authentic key and trust-anchor material.
6. Next-page handoff
Next, read Evidence Bundles to see the concrete package that carries this proof model to independent reviewers.
Then use Verification to run the deterministic checking sequence and read valid, invalid, and indeterminate correctly.