OpenWorkProof Protocol Specification

This specification is the product of a public design conversation (2026-08-08 → 2026-08-12) across LinkedIn and Dev.to. Every primitive below was shaped by named community contributions; each section cites its origin. The protocol's governing principle, stated by the community and adopted here:

Verification must itself be tested. A check that never fails has never been checked.

1. Purpose

OpenWorkProof is a protocol for verifying AI agent work: producing signed, auditable evidence that a piece of agent execution happened as claimed, and that the verifier producing that evidence is capable of detecting failure.

Two distinct claims are always separated in this protocol:

Signatures alone prove the first. They say nothing about the second — the ln.strip() lesson (Section 4.1).

2. Scope & Non-Goals

In scope:

• Receipt formats for verified executions (positive arm + negative arm).
• Guard definitions and guard inventory semantics.
• Negative control contracts (provocation contract, digest pinning).
• Population manifests (sampling honesty).
• Temporal validity: retraction, policy state, scope change.
• Trust model and bootstrap.

Non-goals (for now):

• Model evaluation or benchmarking (evals measure models; we measure executions).
• Tracing / observability (logs record what happened; receipts let third parties verify it).
• Attestation of environment (TEE / enclave proofs prove where something ran, not that it was correct).
• Policy judgment semantics (that is the JPS layer; OWP carries authorization bindings).

3. Terminology

4. Failure Model

The protocol exists because verification can be green and structurally meaningless. The failure model is explicit.

4.1 Structural death (ln.strip())

A production gateway ran a signed, audited check that reported verified: true on every run for months. The bug: a stray newline pushed an assert below a return, so the assertion never executed. Exit code 0. Verdict verified.

Measured impact (fintech engineer's post, 2026-08-09):

Five of eight caller-test shapes produced false passes. The agent had "passed 2,283 tests" and failed in production.

Lesson: the verifier is part of the system being verified. It must be tested with inputs designed to make it fail.

4.2 The three decay modes (rot)

Even with negative controls in place, a check can go silently dead three ways (community taxonomy, 2026-08-12):

All three can produce a green checkmark while being structurally meaningless. All three need different countermeasures.

4.3 Catch-rate measurability (23 of 41)

Production data (Ethan Walker, 2026-08-12): a gate caught 23 of 41 known degradations — a 56% catch rate — across eleven green weeks in which nobody asked what fraction it catches.

Lesson: every guard must be measurable against known-bad inputs. The negative control is the cheap, proactive version of the expensive forensic replay Ethan had to do retroactively.

5. Core Primitives

5.1 Guard & Guard Inventory

A guard is a check plus a control:

guard:
  id: gw_check_response_shape
  description: "Every gateway response matches the documented schema"
  command: "check_response.sh"
  assertion: "schema_validate $INPUT"
  status: unproven        # proven | unproven | broken — set by control runs
  controls: [gw_control_null_handling]

The guard inventory is a published, versioned list — not a private detail. It is the unit of honesty:

guard_inventory:
  schema_version: "1.0"
  generated_at: 2026-08-12T00:00:00Z
  totals:
    guards: 40
    proven: 7
    unproven: 33
    broken: 0
  guards: [ ... ]

"Proven" is defined operationally: a guard is proven only while its negative control fails as expected. The moment the control passes (green on broken input), the guard is reclassified unproven or broken. Proven is a time-decaying label, not a permanent badge (Max Quimby: guard rot).

5.2 Negative Control (provocation contract)

A negative control pins the exact broken input and the exact expected failure, and scopes itself to schema versions (Skillselion: control rot / digest pinning):

negative_control:
  fixture_digest: sha256:abc123...            # The exact broken input
  expected_failure_digest: sha256:def456...   # The exact failure signature
  control_schema_version: 2                   # For schema migration tracking
  control_spec:
    target_schema_version: ">=1.0, <3.0"      # Valid for these schema versions
    provocation_type: null_handling           # What class of failure it tests
    expected_exit_code: non-zero              # Minimum bar
    expected_stderr_pattern: "NullPointerException"  # Specific signal

Rules:

1. Pin by digest, never by path. The fixture and the expected failure are referenced by digest so "proven" is a verifiable claim, not a historical observation.
2. Every control declares its provocation type. A control that stops testing the right failure class (recall) or that tolerates wrong failures (precision) is control rot — detected by comparing control_schema_version and expected_failure_digest over time.
3. A control is valid only within its target_schema_version range. Two schema migrations later, the old control is not silently reused — it must be re-blessed.

5.3 Population Manifest (sampling honesty)

A guard's scope must be auditable. The manifest distinguishes what reached the gate from what passed selection (Tom Jones, third round):

population_manifest:
  selection_rule: "threads we have commented in"   # What we HOLD
  eligible_seen: 400                               # What reached the gate (pre-selection)
  population_size: 12                              # What passed selection (post-selection)
  population_digest: <merkle_root>                 # Tamper-evident enumeration
  sampling_rate: 1.0                               # 100% = no sampling
  effective_from: <timestamp>                      # When the rule was authoritative

Semantics:

• eligible_seen — pre-selection count: did the collector even see the things it was supposed to check?
• population_size — post-selection count: of the things it saw, how many passed the filter?
• The gap is selection loss — the auditable delta that turns a silent failure into a detectable one.

Canonical decision table (Tom Jones):

Without eligible_seen, both scenarios produce the same receipt. With it, the broken case is a live, self-reporting rot signal on the day it happens — not at the next review.

Operational rule: check the set you HOLD, not the set you FETCHED. The selection_rule must be defined over the population you intend to cover, and eligible_seen proves the collector reached it.

Reference scenarios (included in Appendix A with attribution): the thread monitor and the sampler.

5.4 Receipt — DualArmReceipt v1

The signed unit of verification. One payload, two arms (Cophy Origin: the receipt–content gap; Mikhail: dual-arm verification):

dual_arm_receipt:
  schema_version: "1.0"
  claim:
    task_id: owp-task-20260812-001
    description: "Refund processed for order R-4491"
    result: done
    output_digest: sha256:9f8e...               # What was actually produced
  positive_arm:
    test_suite_digest: sha256:77aa...
    test_result: pass
    population_manifest:                       # 5.3 — what the pass covered
      selection_rule: "refunds with amount > 0"
      eligible_seen: 113
      population_size: 113
      population_digest: sha256:31cd...
      sampling_rate: 1.0
      effective_from: 2026-08-12T00:00:00Z
  negative_arm:                                # 5.2 — would the verifier catch a lie?
    control_fixture_digest: sha256:abc123...
    control_result: fail-as-expected
    control_schema_version: 2
    control_target: guard:gw_check_response_shape
  signature:
    algorithm: ed25519
    key_id: owp-key-issuer-01
    value: 0x...

Rules:

1. A receipt without a negative arm is a log, not evidence. The negative arm is what lets a third party check the verifier's capability — it answers "would this receipt have screamed on a lie?"
2. File existence ≠ content correctness. A receipt must pin output_digest (what was produced), not merely record that a file exists.
3. control_target ties the control to the specific guard it proves, so arm and guard cannot drift apart.

5.5 Temporal Validity — RetractionReceipt v0.2

A receipt is a bounded claim: "this was true under these conditions at this time" (Suraj Suradkar). Obsolescence is tracked, not hidden.

retraction_receipt:
  parent_receipt_id: owp-receipt-20260812-001
  retraction_auth: <PolicyDecision>            # Independent trust boundary; co-signed
  propagation_class: none | downstream_causal | same_predicate
  semantic_cause:                              # Open, versioned enum
    category: superseded_by | refuted_by | scope_changed
    superseding_receipt_id: owp-receipt-20260812-009
    valid_until: 2026-08-20T00:00:00Z

Categories (Suraj, refining Mikhail's v0.2):

Design constraints (Mikhail):

• REVOKED / SUPERSEDED / EXPIRED are overlapping flags, not a mutually exclusive enum — a receipt can be superseded and expired simultaneously.
• retraction_auth is an independent trust boundary: the key that issued a guarantee should not be able to unilaterally cancel it (co-signed by a non-issuer).
• propagation_class lives in the protocol layer; semantic_cause in the application layer.

5.6 Policy-State Registry & PolicyAnchor

Policies and their checkpoints are versioned in a monotonic registry (Brian Jin, rounds 2–3):

policy_checkpoint:
  policy_id: pol-refund-eligibility
  revision: 4
  artifact_digest: sha256:e0b1...
  effective_from: 2026-08-12T00:00:00Z
  previous_checkpoint_digest: sha256:c2a9...    # Monotonic chain
  signature:
    key_id: owp-key-policy-01
    value: 0x...

• Monotonic revision chain: every checkpoint references its predecessor, so policy authority has a tamper-evident history.
• Dual timestamps on receipts: a receipt's validity has an execution time (when the agent ran) and a policy time (which policy revision was authoritative). If a policy is retracted, anchored receipts become retrospectively scoped — bounded, not invalid.
• PolicyAnchor sits at Layer −1 of the stack (Section 8): it is the point where authority itself is pinned, not an output of the verification pipeline.

6. Verification Flow (end-to-end)

┌─ Every CI pass ─────────────────────────────────────────────┐
│ 1. Define  guard + negative_control (provocation contract)   │
│ 2. Run positive arm:   suite → test_result, population_manifest
│ 3. Run negative arm:   broken fixture → control_result        │
│    — control must FAIL as expected, else guard reclassified   │
│ 4. Package DualArmReceipt (claim + positive + negative)       │
│ 5. Sign with issuer key; publish to registry                  │
│ 6. On policy/scope change: emit RetractionReceipt             │
└──────────────────────────────────────────────────────────────┘

Outputs:

• A guard inventory updated every run (proven/unproven/broken counts).
• A receipt chain with temporal validity.
• A policy registry with monotonic revisions.

7. Trust Model & Bootstrap

• Minimal bootstrap: a trusted authority key + a signed initial checkpoint. Nothing more is required to start; nothing less is honest.
• Single-operator registry is a consistency proof, not a uniqueness proof: it proves all checkpoints descend from one chain; it does not prove no other chain exists. Multi-operator/multi-key registries are a future work item.
• Transparency log: checkpoints are appended publicly so that retroactive editing is detectable even by parties who do not trust the operator.
• Retraction authority is independent (5.5): the issuer cannot unilaterally revoke its own guarantees.

8. Layered Architecture

Causal order (community-corrected model; PolicyAnchor is Layer −1, not the top):

Evidence is the result of the pipeline; authority is its input. Confusing the two was the original ln.strip() error — evidence was signed while authority was dead.

9. Verification Maturity Model (Level 0–5)

(Glen Allen: "verification must itself be tested".)

Target for production adoption: Level 4, with Level 5 as the differentiator.

10. Adoption Path (two tiers)

(Sri Ramya: layered adoption — execution evidence first, signed receipts second.)

• Tier 1 — Human-verifiable evidence: logs, video, replay. Zero protocol cost; establishes the habit of "show the work."
• Tier 2 — Machine-verifiable receipts: signed DualArmReceipts, continuous controls, published inventory. What this specification defines.

Teams adopt Tier 1 first; Tier 2 is the upgrade path, not the entry requirement.

11. Open Questions

1. eligible_seen: is it total events or matched events? Do we need a third count, total_seen?
2. Multi-operator registry: how do independent signers converge on one chain?
3. control_schema_version migration: what is the deprecation protocol for a control whose target_schema_version range expires?
4. Interaction between TEE attestation and the negative arm: does environment attestation strengthen or complicate control claims?
5. The semantic_cause enum: who curates versions, and how do downstream consumers handle unknown values?

12. Acknowledgements

This specification was co-designed in public. Contributions by:

• The fintech engineer behind ln.strip() — the 40/7/33 guard inventory and the negative control that exposed structural death
• Ethan Walker — 23 of 41, eleven green weeks, catch-rate measurability (4.3)
• JinHyuk Sung — false-Done measurements motivating verifier capability as a first-class claim
• Max Quimby — guard rot, continuous negative control (4.2)
• Tom Jones — population manifest, eligible_seen, FETCHED vs HOLD, reference scenarios (5.3, Appendix A)
• Skillselion — control rot, digest pinning, provocation contract (5.2)
• Glen Allen — verification must itself be tested, maturity model (§9)
• Suraj Suradkar — decision lifecycle, bounded claims, retraction categories (5.5)
• Cophy Origin — receipt–content gap, DualArmReceipt (5.4)
• Brian Jin — Policy-State Registry, bootstrap, PolicyAnchor (5.6, §7)
• Mikhail — RetractionReceipt v0.2, dual-arm verification, independent retraction auth (5.5)
• Sri Ramya — two-tier adoption path (§10)

Appendix A. Reference Scenarios (population manifest)

Attributed to Tom Jones (2026-08-12), canonical for the population manifest:

Scenario 1 — The thread monitor. A sampler configured to measure, on 100% of eligible events, how often two models agree on correctness. Four days produced zero rows, while the box served 113–209 requests/day. Every part of the receipt was valid: selection rule correct, tool ran, exit 0, signature valid. The population was empty because the eligible shape was too narrow. eligible_seen = 400, population_size = 0 exposes the broken collector the day it happens.

Scenario 2 — The sampler. An invite sampler claims to have sampled 12 threads. Without a manifest, the claim is unfalsifiable. With selection_rule + eligible_seen + population_size:

"You sampled 12 of 400" invites an argument. "You sampled 12" ends one.

Appendix B. Schema Versioning Policy

• Every YAML primitive carries a schema_version.
• negative_control.control_schema_version tracks migration of control fixtures; a control is only valid within control_spec.target_schema_version.
• Receipts pin the schema versions of both arms, so old receipts remain interpretable after migration.
• Breaking changes require a new major schema version; old versions remain valid for verification but are deprecated for issuance.