Bounded proof packs for technical trust

One bounded action. One scoped proof pack.

Bring one workflow, patch, finding, access change, or approval-gated action for review. WitnessOps packages the boundary, available evidence, receipt artifacts, named limits, and inspection path when the scope supports it.

Request one proof runInspect sample package

What you get

We name the scope, package available evidence references, record what changed, and show what is still outside scope.

If evidence is incomplete, the package says so.

Not ready to submit work? Inspect the public sample first.

  • Code patches
  • Security findings
  • AI-assisted review
  • Access changes
  • Receipt artifacts and limits
ScopeEvidenceReceiptLimitsInspection path

How a proof-backed run works

One action. One scoped package. Clear limits.

Scope it. Review available evidence. Package only what can be named. Make the limits inspectable.

  1. 01

    Scope

    Pick one action. Name what is in and out.

  2. 02

    Review

    Separate evidence from assumptions.

  3. 03

    Package

    Return evidence references, receipt artifacts where produced, limits, and next step.

  4. 04

    Challenge

    Make the result easy to inspect, reject, or strengthen.

The output says what changed, what supports it, and what remains unproven or outside scope.

→ Read the package offer

REPRESENTATIVE WORKFLOWS

Bring one bounded action

Start with work you already need to explain or hand off.

How workflows are run and inspected

Scope map
Name the action, system, and boundary.
Evidence package
List the artifacts, commands, receipts, hashes, reports, or records.
Decision record
Separate finding, fix, blocked state, and follow-up gate.
Challenge path
Show what another reviewer can inspect, reject, or strengthen.
Internal-only surfaces

Some operational surfaces remain internal, including policy authoring, receipt query, and operator administration.

Request one proof run
→ Inspect sample package

WHAT IS VERIFIABLE TODAY

What can be inspected

The page is not the proof. A scoped package points to the evidence references and limits.

  1. What was actually in scope

    The named action, system, and boundary.

    CheckableOpen bundle (new tab)

  2. What evidence supports it

    The receipts, manifests, commands, artifacts, or review records referenced by the package.

    CheckableOpen bundle (new tab)

  3. What remains unproven

    The limits, assumptions, and decisions still outside the package.

    CheckableOpen bundle (new tab)

The public sample demonstrates receipt shape and verifier path only. It does not claim production deployment. It is not a legal compliance claim or complete AI governance program.

Inspect sample package
→ Read the verification contract

WHERE TRUST ASSUMPTIONS REMAIN

What is not claimed

Proof packs reduce trust assumptions. They do not erase them.

  1. ASSUMPTION

    Runtime integrity

    The execution environment must be operated correctly. A compromised runtime could produce bad records.

  2. ASSUMPTION

    Key management

    Receipt signatures depend on key custody, rotation, and revocation discipline.

  3. ASSUMPTION

    Schema continuity

    Historical verification depends on stable, versioned receipt schemas.

  4. ASSUMPTION

    Policy enforcement

    Policy gates can record that evaluation happened. They do not prove every policy is perfect.

Trust should be named, bounded, and kept as small as possible.

Make one technical action reviewable.

Bring one workflow, patch, finding, or access change for review. If scope and evidence support it, get a proof pack naming boundary, evidence references, receipt artifacts, limits, and inspection path.

Request one proof runInspect sample package