WitnessOps Architecture
Clean system overview for how WitnessOps connects governed execution, proof production, and portable verification.
WitnessOps architecture is the boundary map that connects governed runtime control to portable proof and later independent review.
1. Problem this page solves
Without a shared architecture map, readers collapse execution and proof into one surface and overstate what either layer can guarantee.
This page defines the end-to-end system flow and ownership boundaries before deeper layer and posture pages.
2. What you should understand after reading
After this page, you should understand:
- the end-to-end flow from intent to external verification
- which responsibilities belong to runtime control vs proof production
- what the architecture preserves and what remains outside system guarantees
3. Mechanism-first architecture path
Intent + authority context
-> Governed execution path
-> Evidence capture
-> Signed continuity artifacts
-> Portable bundle
-> Independent verification
Runtime control governs what can happen (scope, approval, and runbook-constrained execution).
Proof production begins at evidence capture and binds what did happen into portable artifacts for later review.
Inputs to this path are authority context, scoped intent, and runtime outputs.
Outputs are signed receipts, continuity links, and bundle artifacts that external reviewers can verify without runtime access.
Responsibility boundaries
| Responsibility | What it owns | Primary depth page |
|---|---|---|
| Runtime control | policy, approvals, scope, governed execution | Governed Execution |
| Layer ownership model | separation of contracts/runtime/proof | Three-Layer Stack |
| Proof artifact construction | receipts, chains, bundle material | Receipts |
| Independent checking | verifier procedure and verdict semantics | Verification |
4. Observed vs inferred
| Layer | What is explicit | What remains interpretation |
|---|---|---|
| Observed | Documented runtime controls, proof artifact path, verification interfaces | None beyond documented behavior |
| Inferred | Confidence in operational trust posture from architecture quality | Depends on reviewer policy and real implementation integrity |
5. Trust assumptions
Architecture reduces ambiguity, but does not remove external dependencies:
- scanner/tool correctness remains external
- host/runtime integrity remains external
- upstream identity/scope/policy input quality remains external
- legal interpretation of evidence remains external
6. Next-page handoff
Next, read Three-Layer Stack to inspect the ownership separation that this architecture map depends on.
Then use Governed Execution and Threat Model for runtime and boundary depth.