How It Works

This page explains the mechanism path from governed execution to verifiable evidence. It is the model page for how WitnessOps moves from runtime controls to proof artifacts.

1. Problem this page solves

Security teams often have logs but no cryptographic chain from authorization to execution to proof.

When challenged, they need to answer:

• what ran
• under what authority and policy
• whether scope controls were applied
• what can be verified independently

This page defines the mechanism that connects those answers.

2. What you should understand after reading

After this page, you should understand:

• the exact stage order for a governed run
• which artifacts are generated at each stage
• where independent verification begins
• what this mechanism proves and what it does not prove

3. Mechanism sequence (exact order)

Every governed operation follows this sequence:

1. Declare intent and scope. Runbook step, target scope, and gate requirements are selected.
2. Evaluate policy gates. Scope, approvals, and preconditions are checked before execution.
3. Execute governed step. Tool action runs only if gates pass.
4. Capture and hash artifacts. Execution outputs are materialized and hashed.
5. Emit signed receipt. A structured execution statement is signed.
6. Attach external proof layers. Timestamp and log/inclusion material are attached when available.
7. Publish continuity state. Receipt links to prior state so sequence integrity can be replayed.
8. Export proof bundle. Receipt plus supporting artifacts can be handed to an independent verifier.

4. Artifacts produced by the mechanism

For a successful governed run, expect:

• receipt.json — signed execution statement
• manifest.json — artifact inventory with hash bindings
• state.json — execution state for replay and investigation

Depending on configured proof layers, bundles may also include timestamp and log inclusion material.

5. Independent verification path

A reviewer can verify without calling WitnessOps by checking:

• receipt signature validity
• structure and digest bindings
• timestamp token validity (if present)
• log inclusion/checkpoint consistency (if present)
• continuity links to prior state (if provided)

Start with How to Verify a Receipt, then use Anchored Replay when reviewer-supplied trust anchors are required.

6. What this mechanism proves

This mechanism proves that governed execution claims were recorded with cryptographic integrity and linked evidence.

It does not, by itself, prove:

• that every tool result is correct
• that human judgment was always optimal
• that external trust roots are uncompromised

7. Remaining trust assumptions

The model still depends on explicit trust inputs:

• key distribution and rotation posture
• timestamp authority trust
• transparency-log trust root continuity
• policy authoring quality and approval quality

These assumptions are explicit design boundaries, not hidden guarantees.

8. Next-page handoff

Next, read Governed Execution for runtime authority boundaries and gate behavior under real execution pressure.

Then continue to Proof Model for authority layers, signature layers, and strength hierarchy.

Then review Evidence Bundles for the portable package exported from this mechanism path.

If you need standards mapping details, read Standards Alignment.