The system
How the system worksThe DirectoryDispatchThe LedgerAI modelsAI agentsYour installationThe appThe research libraryWhat changes for your businessUse it from your softwareEverything it can do
Messaging
iMessageWhatsApp
Ads and leads
AdsCreativeLeads
Devices
Devices
Industries
RealtorsRestaurantsHome services
Explore
How it worksPermissions and limitsCompareSet upQuestionsText me

Proven work: the base unit — a claim, a record, and a door

This page defines the base unit this whole system is built around: proven work. It settles whether the reframe is correct, reduces the object to its smallest true structure, states the standard as a checklist — what qualifies, what does

This page defines the base unit this whole system is built around: proven work. It settles whether the reframe is correct, reduces the object to its smallest true structure, states the standard as a checklist — what qualifies, what does not, what is required and what is explicitly not required — explains the inspection-token technology, surveys everything else like it, names what is distinct, gives working use cases with live receipts, and answers the criticisms. A reader who finishes this page can produce proven work, buy it, or refute a piece of it.

The verdict

Yes. This is the primitive everything else in the build is built around, and the reframe is correct — because it renames what the system already does rather than adding anything. The canonical definition exists. The ledger exists. The sealed panels exist. The delegated tokens exist. Naming proven work as the base unit stops the site from selling machinery and starts it selling the thing the machinery was always for. Under the logic law that is the cheapest move with the largest effect: subtract the framing, keep the plant.

The competitive sentence is one line. Everyone ships agents, frameworks, and ontologies. They have no proof.

The definition

Proven work is a claim about completed work, bound to the complete record of that work's formation, with standing authority for any stranger to inspect the record and test the claim.

Two parts and a door:

The claim. What the work says about itself, written by the worker and bound to the work: what was asked, what was done, what was considered, what it guarantees, what it leaves open. The claim is the only part a human normally reads.

The record. Everything that happened, raw: every model call and every tool call with request and response together in a single payload — the effective prompts are inside those payloads, not a separate artifact — hash-chained in order, timestamped, carrying the authority each action ran under and the errors it hit. Not curated. Not summarized. Not written after the fact. On this site the record is the public ledger.

The door. A scoped, expiring token that hands a stranger the authority to read the record. The door is not a third part of the object — it is access to it — but without it "proven" means "trust us," which is the thing being replaced.

Work is proven when every sentence of the claim resolves against the record. Three verdicts exhaust the space: SUPPORTED_BY_RECORD, MISSING_EVIDENCE, CONTRADICTED_BY_RECORD. A claim sentence with no bearing record is a named gap or it is a lie. There is no third state.

Why not nine fields, and why not three

Ask a model to define a primitive and it returns a taxonomy. Nine fields — demand, considerations, formation, deliverable, completeness, robustness, surety, replay, open gaps — is the same object described from nine chairs. Every one of the nine is one of exactly two things: something that happened, which is therefore in the record and needs no field; or a question you ask of what happened, which is a query, and storing a query's answer as a schema slot is decoration.

The three-field reduction — input, execution trace, output boundary — is closer but still double-counts. On this build's ledger a request and its response are one payload. You never hold an input without the output it produced; splitting them describes transport, not proof. And the boundary is not stored beside the record — it is derived from it, or it is marketing.

"Was it complete?" — diff the claim's scope against the record. "Did the worker know about X?" — search the record's payloads. "Would it replay?" — rerun the recorded calls and diff. "What would change the result?" — read the recorded assumptions. All of the nine collapse into queries against two parts.

The standard, as a checklist

Work qualifies as proven work when all five hold:

  1. A written claim — request, actions, considerations, guarantees, open gaps — bound to the work object, authored before or during the work. A claim reconstructed afterward is itself work product and says so.
  2. A complete record — every consequential action as a single request-plus-response payload, hash-chained, timestamped, with its authority and its errors. Model deliberations count as payloads. Tool calls count as payloads. Edits, sends, and deployments count as payloads.
  3. Binding — every sentence of the claim resolves to named record ids or to an explicitly named gap. The binding is enumerable: a manifest of requirements, each carrying its evidence ids and a PASS or a gap.
  4. Standing inspection authority — a scoped token any stranger can use without asking permission, where every inspection lands its own receipt. Proof that cannot be checked by an adversary is reputation, not proof.
  5. Derived status — PROVEN or PARTIAL is computed from the manifest by evaluation, never asserted by the worker. PARTIAL printed honestly outranks PROVEN asserted loudly.

What the standard does not require:

  • A vendor or framework. Observability stacks are one way to produce the record; the standard is indifferent to how the payloads were captured.
  • Correctness. Proven work proves what happened, not that it was right. Correctness is a separate claim that needs its own record — on this site, the sealed multi-model panels whose agreement is checked by arithmetic.
  • Human review. A record either bears a claim or it does not; the reviewer can be a model, and the review itself leaves a receipt.
  • Disclosure of secrets. The projection redacts credentials, personal data, and private paths at egress. Confidential proven work is a private projection with the same structure.
  • The worker's later cooperation. The record was written as the work happened. The worker cannot improve it afterward, which is the point.
  • Nine fields.

The token technology

The inspection door is a scoped delegated capability, and its properties are what make publishing proof safe:

  • Row-scoped and body-fixed — the token can invoke exactly one thing: a GET of one work object's proof projection. It cannot read anything else, write anything, or spend anything.
  • Expiring — seven days by default; a stale link dies on its own.
  • Unlimited uses inside the window — proof does not ration its readers.
  • Fingerprinted and receipted — every inspection returns its own invocation id and public receipt, so reading the proof is itself recorded work. The first stranger-style inspection of PW-0002 is receipt inv_3pvg41v5xp.
  • Minted on demand, never stored in prose — the write path of this site refuses to store a live bearer token inside an article body; that refusal was verified while building this page. Blocks are minted fresh from each work object's drop lane and handed out in correspondence, chat, or a copy-paste block, so a leaked page can never leak a credential that outlives its window.

The projection the token opens is self-explaining: it carries its schema, its manifest with per-requirement evidence, its formation records, the redaction rule, and the response contract — the three allowed verdicts and the citation rule. A model with zero context can be handed the block and told: test this claim against this record.

The working examples, live

PW-0002 — the sealed statutory panel. Claim: five AI models from four vendors adjudicated one EU AI Act Article 50 question in parallel, blind to one another, under a fixed machine-parseable shape; four structurally valid findings across three model lineages sealed a unanimous record-bound APPROVE; the fifth was discarded for a malformed shape, in public. Eight requirements, eight PASS, status PROVEN — computed, not asserted. Projection: https://miscsubjects.com/api/proven-work/three-models-deliberate-one-statutory-question. The receipts: inv_gte0gtx31p, inv_mr0y1mcw8f, inv_t61klfgq4u, inv_lffvxuzad4, inv_804vr5xvdj; the strict seal's honest escalation inv_tkj82c7m1v; the APPROVE inv_qmxwk924vw. The full account: the panel record.

PW-0001 — the honest counterexample. The first object records status PARTIAL because its consideration inventory was reconstructed after the work. Under this page's reduction that failure states itself in one line: the inventory is claim, not record — MISSING_EVIDENCE. A standard that cannot fail its own first example is not a standard.

Everything else like it

Every serious proof discipline arrived at the claim-and-record shape, under different names. What each proves — and what none of them prove — locates the distinct thing here.

  • Interactive and zero-knowledge proofs — a statement and the interaction that convinces a verifier; knowledge is measured over the transcript (Goldwasser–Micali–Rackoff, 1985). Proves mathematical statements; says nothing about open-ended work.
  • Software attestation — in-toto, SLSA — a subject artifact bound to a signed predicate about how it was built, with resolved dependencies and builder identity. Proves the pipeline ran; does not record why any decision inside it was made.
  • Reproducible builds — the same inputs yield bit-identical outputs, so the binary proves its own source. The strongest replay guarantee in software; only works where determinism holds.
  • TEE remote attestation — hardware signs a measurement of the code it runs, proving the environment. Proves where work ran, not what the work considered.
  • C2PA content credentials — signed provenance metadata travels with a media file. Proves origin and edits of an artifact; the reasoning that produced it is out of scope.
  • W3C PROV — entities, activities, and agents as a provenance data model. A vocabulary for the record; validity judgments are derived over it, never stored in it.
  • Financial audit — ISA 500 — management's assertions versus the evidence obtained to test them; completeness and accuracy are properties to be tested. The oldest living claim-versus-record industry.
  • Chain of custody — the exhibit and its unbroken record of holders; admissibility is judged over the record.
  • Preregistration in science — the claim (hypothesis, method) filed before the work, so the record can contradict it. The strongest known cure for after-the-fact claims.
  • Flight data recorders — the total raw record, kept precisely because nobody knows in advance which question will matter.
  • Double-entry bookkeeping — the statement and the journal; the audit profession exists because the two are separable and must be reconciled.

None of these store robustness, surety, or completeness as fields. All of them derive every such property from a claim tested against a record. That is the whole argument for two parts.

What is distinct here

Every scheme above proves an artifact, an environment, or provenance metadata. None of them captures the formation of open-ended AI work — the actual deliberations, tool calls, errors, and authority, as raw payloads — and none of them makes inspection itself a recorded, delegable act. The distinct move is threefold:

  1. The record includes the reasoning. Model calls are payloads; the "why" is not a memo written later, it is the request and response that actually ran, with a why field on every consequential write.
  2. Inspection is recorded work. Every read of the proof leaves a receipt. The proof of the work accumulates proofs of its reading — an audit trail of audits.
  3. Interrogation is delegable to machines. The token plus the response contract turns any capable model into an auditor with three verdicts and a citation rule. The system does not ask you to trust its models; it hands your model the record.

Use cases

  • A regulator defers to documentation. A statutory question is adjudicated on the record — the Article 50 panel — and the standing offer on the compliance guide lets any legislator or private party request a demonstration, an audit, or a compliance schematic, free, with the reasoning published.
  • A buyer traces a research report. Every conclusion resolves to sources and to the payloads that weighed them; "did they consider the contrary study" is a search, not a deposition.
  • A failed task keeps its value. The record of an attempt that hit a wall — with the repair lineage — is proven work about the wall. Failures stop being embarrassments and become records.
  • Outbound correspondence proves itself. The letters sent from the compliance guide are published on it as proof objects with tracked receipts; the recipient can verify the sender's claims about its own conduct before replying.
  • Disputes collapse to record checks. "Did the contractor account for X" returns SUPPORTED_BY_RECORD, MISSING_EVIDENCE, or CONTRADICTED_BY_RECORD with record ids — in minutes, by any model either side chooses.
  • Agents trust agents by record, not reputation. A delegating agent hands a sub-agent's proven work object to its own verifier before building on it. Delegation chains stop being faith chains.

The criticisms, answered

"Records can be fabricated." Inside one operator's ledger, yes — hash chains prove order and integrity, not honesty at the moment of writing. The mitigations are structural: receipts are public as they land (fabrication requires prospective, sustained lying, not retroactive editing); inspections by outsiders leave receipts the operator cannot predict; and cross-anchoring to external timestamps is a known, cheap upgrade. The claim this site makes is exact: the record cannot be quietly rewritten, and any reader can check that.

"Complete records are huge and expensive." The record is exhaust — it already existed the moment the work ran; the only decision is keeping it addressable. Storage is the cheapest component of AI work by orders of magnitude.

"Proof of process is not proof of quality." Correct, and the standard says so. Proven work proves what happened. Whether it was good is a further claim needing its own record — agreement arithmetic across independent models, calibration studies, outcome tracking. Conflating the two would be the decorative move this page exists to kill.

"Confidentiality." Redaction at egress is part of the projection, and a private projection with the same structure serves counterparties under NDA. Proof and secrecy compose; what does not compose is proof and editing.

"Replay will drift." Models version, APIs change. The record pins model identifiers, timestamps, and full payloads, so drift is measurable and disclosed rather than hidden. Replay proves what replays; the record proves the rest.

"Nobody pays for proof." Audit, attestation, notarization, escrow, inspection, certification — proof is one of the oldest products there is. What did not exist is proof native to AI-performed work. That is the gap.

"It will be gamed." The standard measures the presence and binding of record, not virtue. Gaming it means writing more of the truth down. That is the only Goodhart failure worth having.

Bringing work up to the standard

Existing work migrates in four steps, none of which require rebuilding it: write the claim as a requirement manifest; bind each requirement to the records that already exist; name every gap where the record is missing (that names it PARTIAL, which is correct); mint the door. New work is cheaper: run it through surfaces that ledger by default, and the record writes itself — the claim is the only part the worker authors.

Sources

  • https://dl.acm.org/doi/10.1145/22145.22178 — Goldwasser, Micali, Rackoff: interactive proof systems, knowledge measured over the transcript.
  • https://slsa.dev/spec/v1.0/provenance — SLSA v1.0 provenance: subject bound to signed predicate.
  • https://github.com/in-toto/attestation — in-toto attestation framework.
  • https://reproducible-builds.org/docs/definition/ — reproducible builds definition.
  • https://www.w3.org/TR/prov-dm/ — W3C PROV data model.
  • https://c2pa.org/specifications/specifications/2.1/specs/C2PA_Specification.html — C2PA content credentials.
  • https://www.iaasb.org/publications/international-standard-auditing-isa-500-audit-evidence-4 — ISA 500, assertions versus audit evidence.
  • https://csrc.nist.gov/glossary/term/chain_of_custody — NIST: chain of custody.
  • https://www.cos.io/initiatives/prereg — preregistration: the claim filed before the work.

The product is work. With proof. A claim, a record, and a door any stranger can walk through.

References (10)
  1. The knowledge complexity of interactive proof-systems
  2. SLSA v1.0 provenance specification
  3. in-toto attestation framework
  4. W3C PROV-DM
  5. ISA 500, Audit Evidence
  6. NIST glossary: chain of custody
  7. PW-0002: the sealed panel record
  8. Reproducible builds definition
  9. C2PA content credentials specification
  10. Preregistration (Center for Open Science)