How It Works

This page explains the path from a governed action to proof another person can check.

1. Problem this page solves

Security teams often have logs, but no clear chain from approval to execution to proof.

When challenged, they need to answer:

• what ran
• who allowed it to run
• whether scope controls were applied
• what another person can verify independently

This page explains 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 created at each stage
• where independent verification starts
• 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. Choose the runbook step, target scope, and required gates.
2. Evaluate policy gates. Check scope, approvals, and preconditions before execution.
3. Execute the governed step. The tool action runs only if the gates pass.
4. Capture and hash artifacts. Write the execution outputs and hash them.
5. Emit the signed receipt. Sign a structured statement of what ran.
6. Attach outside proof layers. Add timestamp and log/inclusion material when available.
7. Publish continuity state. Link the receipt to prior state so the sequence can be replayed.
8. Export the proof bundle. Hand the receipt and supporting artifacts to an independent reviewer.

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 the configured proof layers, the bundle may also include timestamp and log inclusion material.

5. Independent verification path

A reviewer can verify the bundle without calling WitnessOps by checking:

• receipt signature validity
• structure and digest bindings
• timestamp token validity, if present
• log inclusion and 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 can prove that a governed execution claim was recorded with cryptographic integrity and linked evidence when verified against trusted keys (and higher layers when present and fully checked).

It does not, by itself, prove:

• that every tool result is correct
• that every human decision was right
• that outside trust roots are uncompromised

7. Remaining trust assumptions

The model still depends on a few trust inputs:

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

These are named 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 proof strength.

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

If you need standards mapping details, read Standards Alignment.