Governed Execution

Governed execution is the runtime control path inside WitnessOps. It is how the system moves from operator intent to scoped action, evidence capture, and receipt emission without relying on ad hoc shell access or informal operator memory.

This page is about runtime mechanics. It is not the full architecture page and it is not the verification page.

What Governed Execution Means

In WitnessOps, a step is governed only if it passes through the declared control path before anything touches the target.

That path exists to answer five runtime questions in order:

1. what is being requested
2. is it in scope
3. does it require approval
4. what evidence will be captured
5. what receipt-bearing statement should be emitted when the step resolves

If those questions are bypassed, the action may still happen in the real world, but it did not happen inside the WitnessOps governance boundary.

Runtime Flow

1. Intent enters the runtime

A governed operation starts as declared intent: target, objective, and requested capability. WitnessOps does not begin with raw shell commands. It begins with a structured request that can be checked.

2. Scope and policy are evaluated

Before execution, the runtime evaluates whether the requested action is permitted for the current target, environment, and policy context.

If the action is out of scope or disallowed, the runtime stops there. This is an execution outcome, not a documentation suggestion.

WitnessOps enforces policy at runtime and records that enforcement, but the proof system guarantees the record of the decision path, not the correctness of the policy inputs or policy design themselves.

3. Approval gates pause when required

Some actions are too intrusive to proceed automatically. When that boundary is crossed, the runtime pauses and waits for explicit approval.

The important property is that approval is part of the runtime path, not a note added later. Until the gate is satisfied, the step does not run.

4. The governed step executes

If scope and approval conditions are satisfied, the declared runbook step executes. WitnessOps governs the execution path. It does not claim to certify that the underlying tool is perfect.

That distinction matters. Runtime governance proves what path was allowed and taken. It does not convert every tool result into unquestionable truth.

5. Evidence is captured at the point of execution

Artifacts produced by the governed step are recorded as execution evidence. Common outputs include state updates, manifests, logs, and artifact digests.

The trust goal here is not pretty reporting. It is making later tampering and incomplete export detectable.

6. Receipt-bearing artifacts are emitted

When the governed step resolves, WitnessOps emits the receipt-bearing record for that outcome. That record binds the governed event to:

• the execution context
• the policy and approval context
• the captured evidence references
• the continuity structure that places the event into the wider run

This is where runtime control hands off to the proof surface. See Receipts and Receipt Specification for the proof object itself.

The Four Runtime Outcomes That Matter

Most governed steps end in one of four ways:

These are runtime states. They should not be confused with proof-verification states like valid, invalid, or indeterminate, which belong later in the chain.

Resumable by Design

Governed execution is resumable because approvals and gate outcomes are part of the runtime state, not hidden in operator memory.

When a step pauses for approval, the operation can resume from the correct point later. That preserves continuity and reduces the temptation to rerun or reconstruct work informally.

What Governed Execution Produces

The exact filenames and packaging vary by runbook and delivery surface, but the runtime consistently produces three classes of material:

• execution state describing what completed, failed, or remains gated
• evidence manifests and artifact references describing what was captured
• signed receipt-bearing artifacts describing the governed outcome

Those outputs are what later become Execution Chains and portable verification packages.

What Governed Execution Does Not Do

Governed execution does not, by itself:

• prove the underlying tool was correct
• perform independent third-party verification
• resolve every trust assumption around keys, hosts, or identity
• replace the architecture, threat model, or verification pages

Its job is narrower and more important than that: ensure the work passed through a controlled runtime path and emitted evidence strong enough for later verification.

Where Runtime Stops and Verification Starts

WitnessOps runtime ends at governed execution plus receipt emission. Independent proof checking happens afterward against the artifacts the runtime produced.

That separation is intentional:

• runtime control answers whether the action was governed
• receipt semantics answer what statement was issued
• chain continuity answers how events connect
• verification answers what a third party can confirm offline

Keeping those layers separate is what makes the public trust story credible.

Read Next

• Threat Model for what the runtime can and cannot prove
• Receipts for the atomic proof object
• Execution Chains for continuity and ordering
• Verification for the external check path