Getting Started

This page answers one question: how do you go from first read to one governed run and one receipt you can check?

If you are evaluating the public request path before submitting work, read the Buyer path for catalogue, sample, verifier and non-secret fit-check order.

1. Problem this page solves

Most consequential work leaves behind fragmented evidence. After execution, teams often cannot answer clearly:

• what ran
• what scope and policy applied
• who approved intrusive actions
• whether another person can verify the record outside the original system

WitnessOps addresses that by enforcing policy at runtime and emitting signed receipts linked to execution artifacts.

2. What you should understand after reading

After this page, you should understand:

• the minimum setup for a first governed run
• the exact order of the first path
• which artifact marks success
• what another person can verify independently
• what still depends on trust

3. Minimum setup and assumptions

Before running anything:

• You have an authorized target scope (domain, IP, or asset list).
• You have a runbook describing tools, steps, and gates. See Runbooks.
• You have policy and approval requirements defined. See Policy Gates.
• You know who can approve the run. See Authorization Model.
• You can export the receipt and related artifacts for outside review.

4. First governed path (exact order)

1. Define the runbook. Name the targets, tools, gates, and expected artifacts.
2. Set scope and approval. Make the authorized boundary and the approver path explicit before execution.
3. Execute the runbook. WitnessOps enforces the gates at each step. A failed gate stops the run.
4. Record approvals or exceptions. If approval is required, execution pauses until the approval is recorded.
5. Complete the run and emit artifacts. On success, the receipt and evidence artifacts are written.

If no receipt is emitted, treat the run as incomplete for proof purposes.

5. Artifact you should expect at the end

A successful first run should produce:

• receipt.json — signed record with the execution binding and continuity link
• manifest.json — list of produced artifacts and hashes
• state.json — execution context for replay and investigation

The minimum success condition is one valid signed receipt linked to the governed action that ran.

6. What can be verified independently

Independent verification should confirm:

• receipt signature validity
• execution-binding fields and artifact references
• continuity link to prior receipt state, when present
• artifact hash integrity against the manifest

Use Verify a receipt to check receipt JSON on the public tool. For procedure detail, read How to Verify a Receipt and Receipt Specification.

7. What is proven vs what is still trusted

Proven by artifacts

• A governed action completed with recorded scope and policy context.
• Approval and gate events were recorded for that run.
• The receipt and referenced artifacts are cryptographically consistent.

Still trusted

• Underlying tool correctness and finding quality.
• Human judgment quality from operators and approvers.
• Key distribution and timestamp authority continuity.

8. Next-page handoff

Next, read How It Works to move from the first run to the full mechanism model.

After that, continue to Governed Execution for runtime authority boundaries.