Governed Execution
How WitnessOps moves from intent to scope, approval, execution, evidence capture, and receipt emission.
What actually happens when I run something through WitnessOps, and where does runtime control stop and proof begin?
This page answers one boundary question: what happens inside runtime control, and where proof and verification start afterward.
1. Problem this page solves
Security teams need a deterministic execution path, not a story rebuilt after the fact. Without governed runtime control, teams cannot reliably prove:
- which action was requested
- whether it was in scope
- whether approvals were satisfied before execution
- what evidence was captured at execution time
Governed execution is the control layer that enforces those checks before work touches the target.
2. What you should understand after reading
After this page, you should understand:
- the exact runtime sequence for a governed step
- the execution outcomes (
executed,denied,paused,failed) - what artifacts are emitted at the runtime boundary
- what this layer proves and what remains outside it
3. Runtime mechanism (exact order)
- Intent enters runtime. The requested step, target, and capability are declared.
- Scope and policy gates evaluate. Preconditions are checked before execution.
- Approval pauses if required. Intrusive work stops until explicit approval is recorded.
- The step executes under governance. The tool action runs only if the gates pass.
- Evidence is captured at execution time. Artifacts and digests are recorded.
- A receipt-bearing statement is emitted. The outcome is bound to the execution context and continuity references.
If this sequence is bypassed, the action may still happen operationally, but it did not happen inside WitnessOps governance.
4. Runtime outcomes and their meaning
| Outcome | Meaning |
|---|---|
| Executed | The step was permitted and completed under governance |
| Denied | Scope or policy blocked execution before the run |
| Paused | Approval or another required gate is still pending |
| Failed | The step ran but did not complete successfully |
These are runtime outcomes, not verification verdicts such as valid, invalid, or indeterminate.
5. Artifacts emitted at the runtime boundary
A governed run emits runtime evidence that later supports proof checks:
- execution state
- evidence manifests and artifact references
- signed receipt-bearing artifacts
Those materials are used by Receipts, Execution Chains, and How to Verify a Receipt.
6. What this layer proves
Governed execution proves a signed claim that emission followed the declared gate path as recorded by that runtime, and that the resulting evidence and receipt were emitted from that path. It does not prove host honesty on its own.
It does not prove:
- tool correctness
- perfect human judgment
- outside trust-root integrity on its own
7. Remaining trust assumptions
This layer still depends on assumptions outside runtime enforcement:
- correctness of configured scope and policy inputs
- integrity of the host and tooling environment
- key and trust-root management outside the single step
These assumptions are explicit boundaries, not hidden guarantees.
8. Next-page handoff
Next, read How to Verify a Receipt to move from runtime emission to independent proof checking.
Then read Threat Model and Trust Boundaries for the full limits and dispute posture.