Proof-Carrying Work
Proof-carrying work means every agent deliverable carries enough evidence for a human or later agent to verify what happened, why it happened, and whether it is safe to build on.
Core idea
An agent should not merely produce an answer, diff, or wiki page. It should leave a verifiable bundle:
- sources consulted;
- commands run;
- tests and doctors executed;
- screenshots, traces, logs, or artifacts produced;
- decisions made and alternatives rejected;
- files changed;
- unresolved risks.
This is the work-output version of provenance. W3C PROV defines provenance around the entities, activities, and people involved in producing a thing, so that quality, reliability, and trust can be assessed. Agent work needs the same shape, just adapted to tool calls, traces, files, approvals, and generated artifacts. Source: W3C PROV Overview, https://www.w3.org/TR/prov-overview/, 2026-06-19
The failure mode
The default agent failure is polished opacity: the output looks complete, but nobody can reconstruct it. A future agent cannot tell whether a claim came from memory or a primary source. A reviewer cannot tell whether tests passed or were skipped. A user cannot tell whether a risky command actually ran.
That destroys compounding. The next session must re-investigate everything, or worse, trust an untraceable artifact.
What counts as proof
| Work type | Minimum proof |
|---|---|
| Wiki synthesis | sources, changed pages, graph links, build-index, doctor, qmd update/embed, log entry |
| Code change | diff summary, tests/lints run, failing checks disclosed, behavior verified |
| UI change | screenshots or browser checks, interaction path, accessibility/performance notes |
| Agent run | trace or step log, tool calls, approvals, artifacts, cost/latency if material |
| Research | search queries, primary sources, date checked, uncertainty and contradictions |
| Automation | trigger, inputs, idempotency behavior, state writes, retry/failure path |
Proof is not an essay about confidence. It is a reproducible trail.
IRL comparison
Current agent frameworks are converging on this primitive. OpenAI's Agents SDK tracing records an end-to-end workflow with spans for LLM generations, tool calls, handoffs, guardrails, and custom events, while also warning that trace data can contain sensitive inputs/outputs and must be controlled. That is the product-grade version of "leave proof": traces are useful only if they preserve enough detail without leaking the wrong data. Source: OpenAI Agents SDK tracing, https://openai.github.io/openai-agents-python/tracing/, 2026-06-19
The important distinction:
- trace: chronological execution record;
- artifact: output a user can inspect or reuse;
- citation: source backing a factual claim;
- validation: check that proves a property;
- provenance: relationship between source, action, actor, and produced thing.
Good agent systems need all five. A test log without citations does not prove a factual research claim. Citations without a run log do not prove what the agent actually did. A trace without a final artifact is archaeology.
Kevin-stack version
In Kevin's wiki and agent stack, proof-carrying work means:
- Search first. Use the wiki before web or memory.
- Cite claims. Use primary sources when claims can rot.
- Update the graph. Related pages and routers must reflect new knowledge.
- Run doctors.
build-index,doctor,routing-doctor, section audit, qmd. - Log operations.
wiki/log.mdtells the next agent what changed. - Report skipped checks. Silence around verification is not proof.
- Promote recurrence. Repeated manual proof should become a doctor, skill, or automation.
This is the practical form of Agent Ethos's "leave proof." It keeps Knowledge Compilation honest and gives Agentic Quality System something to inspect.
Decision model
Ask three questions before closing work:
| Question | If no |
|---|---|
| Can a future agent find the source of each important claim? | Add citations, timeline evidence, or a source note. |
| Can a reviewer reproduce the verification path? | Name commands, checks, screenshots, and failures. |
| Can the system prevent this mistake next time? | Add or update a doctor, skill, workflow, or router. |
Failure modes
- Proof theater: dumping commands without saying what they proved.
- Citation laundering: citing a secondary blog when the official doc or paper was available.
- Trace hoarding: recording everything but never surfacing a human-readable summary.
- Sensitive proof leakage: storing secrets, prompts, customer data, or private files in traces.
- Artifact drift: proof points to an old state after files or docs change.
- Unindexed proof: the evidence exists but is not linked, logged, or searchable.
Design implications
Agent products should expose proof as a first-class surface:
- run timeline;
- source drawer;
- artifact list;
- command/test log;
- approvals and denials;
- cost/latency summary;
- "what changed" diff;
- one-click copy/share for the proof bundle.
Proof must be inspectable without forcing Kevin to replay an entire transcript. The artifact should carry the important evidence with it.
Concept Position
| Field | Value |
|---|---|
| Concept family | Brain, memory, and retrieval |
| Concept owned | Proof-carrying work means every agent deliverable carries enough evidence for a human or later agent to verify what happened, why it happen... |
| Category map | Concept System Map |
Timeline
- 2026-07-01 | Concepts category refresh added this page to the Brain, memory, and retrieval family, linked it to Concept System Map, and kept it standalone because it owns this reusable mental model: Proof-carrying work means every agent deliverable carries enough evidence for a human or later agent to verify what happened, why it happen... Source: User request, 2026-07-01
- 2026-06-19 | Created to name the recurring "leave proof" primitive across agent traces, wiki citations, doctors, artifacts, and user-facing run summaries. Grounded against W3C PROV and OpenAI Agents SDK tracing. Source: User request; W3C PROV Overview; OpenAI Agents SDK tracing, 2026-06-19