GETTING STARTED
Entry Surface

Getting Started

Go from first contact to one governed run and one verifiable receipt.

This page solves one specific problem: how a serious reader gets from first contact to one governed run and one verifiable receipt.

1. Problem this page solves

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

  • what ran
  • under what scope and policy
  • who approved intrusive actions
  • whether the record can be verified outside the originating system

WitnessOps addresses this 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 needed for a first governed run
  • the exact order of the first governed path
  • which artifact marks success
  • what is independently verifiable
  • what is still a trust assumption

3. Minimum setup and assumptions

Before running anything:

  • You have an authorized target scope (domain/IP/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 the approval authority model for the run. See Authorization Model.
  • You can export the resulting receipt and related artifacts for independent review.

4. First governed path (exact order)

  1. Define the runbook. Declare targets, governed tools, gate requirements, and expected artifacts.
  2. Set scope and approval path. Ensure authorized boundaries and approver expectations are explicit before execution.
  3. Execute the runbook. WitnessOps enforces gates at each step; failed gates stop progression.
  4. Record approvals/exceptions. If a gate requires approval, execution pauses until approval is recorded.
  5. Complete the run and emit artifacts. On successful completion, 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 governance record with execution binding and continuity link
  • manifest.json — inventory of produced artifacts and hashes
  • state.json — execution state context for replay and investigation

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

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 How to Verify a Receipt, Receipt Specification, or the public Verifier for receipt-first checks.

7. What is proven vs what is still trusted

Proven by artifacts

  • A governed action completed with recorded scope/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 (operator and approver decisions).
  • Key distribution and timestamp authority continuity.

8. Next-page handoff

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

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