What an Evidence Receipt Proves and What It Does Not

TL;DR

An evidence receipt proves that named checks and decisions were recorded for a specific change. It should identify the requirement, commit, tests, reviewers, exceptions and known gaps. It cannot prove that the requirement was correct, the tests were complete or the change is safe in every environment. Use it as a review map and audit record, not as a certificate of correctness.

In this article

1. What belongs in the receipt
2. Read one receipt from top to bottom
3. What hashes prove
4. What a passing command proves
5. What model review proves
6. What human approval proves
7. Use three honest terminal messages
8. How paqad-ai uses receipts
9. Source notes
10. Make the receipt readable during an incident
11. Frequently Asked Questions

6 min read

These two reader concerns frame the article: What does an AI code evidence receipt prove? and What evidence should an AI-generated pull request include?. The links show the wording and context of the questions; the answer below uses primary or official sources for material claims.

That is useful navigation.

It is not yet an evidence receipt.

A receipt lets another person inspect the chain from approved intent to production verdict without replaying the full conversation.

What belongs in the receipt

Identity

• workflow and run identifier;
• repository and revision;
• specification and plan versions;
• artifact hashes;
• provider and relevant configuration;
• time and environment.

Identity establishes which exact run and bytes the receipt describes.

Target

• owned product goal;
• acceptance criteria;
• invariants;
• risk lane;
• scope and exclusions.

The receipt needs the answer key used by the workflow.

Change

• changed files and modules;
• public contracts and data affected;
• dependencies added or changed;
• migrations and operational impact;
• out-of-scope discoveries.

Evidence

• commands and exit codes;
• test, type, lint, build, schema, registry, mutation, health, or other results;
• measured results with method and environment;
• traceability from criteria to evidence;
• specialist findings;
• documentation status.

Decisions

• human question;
• owner;
• alternatives;
• evidence considered;
• answer and reason;
• time;
• affected artifacts.

Limits

• inconclusive findings;
• checks not run;
• model-judged conclusions;
• accepted risk;
• assumptions;
• remaining work.

Recovery and verdict

• rollback or recovery path;
• final state;
• accountable verdict owner;
• required next action.

Read one receipt from top to bottom

Consider an illustrative pull request that changes an API validation error from 409 to 422. A useful receipt names the approved behavior, starting and ending revisions, changed route and schema, contract tests, documentation update, reviewer and remaining compatibility risk. It also records that the staging smoke test was not run and who must decide whether that gap blocks release.

The receipt should let a reviewer answer four questions without reopening the agent transcript:

1. What behavior was approved, and which artifact contains it?
2. Which exact revision and environment produced each result?
3. Which findings came from deterministic checks, model judgment or a person?
4. Which uncertainty remains, and who owns the next decision?

A receipt becomes stale when the approved target, revision, check implementation or environment changes. Mark invalidated entries and issue fresh evidence. Copying a green result to a later commit breaks the chain the receipt is meant to preserve.

What hashes prove

A cryptographic hash can bind approval to exact content.

If one byte changes, the fingerprint changes. The workflow can require a fresh preview and approval.

This proves artifact identity and helps make history tamper-evident.

It does not prove:

• the specification is correct;
• the tests are meaningful;
• the code is secure;
• the reviewer understood it;
• the product decision is wise.

Hashes answer a narrow and valuable question: are these the same bytes?

What a passing command proves

A recorded command and exit code show that the command ran in the stated environment and returned that result.

They do not show that:

• the command covered every relevant path;
• the environment matches production;
• the test intent came from the approved specification;
• the check itself is correctly designed.

The receipt should preserve method and limitation.

What model review proves

A model review can surface useful findings and challenge assumptions.

It proves that a specific model, context, and instruction produced an assessment. It does not establish a deterministic fact or remove the need for human ownership of consequential decisions.

Record model-judged findings as judgement.

What human approval proves

Approval proves that the recorded person approved the exact package at the recorded time.

Meaningful oversight also requires evidence, authority, and timing.

The receipt should show the options, reason, and scope so the approval is more than a name beside a button.

Use three honest terminal messages

A receipt should be able to conclude:

Safe to merge

Required evidence and decisions are complete within the stated scope.

Needs attention

A known finding or decision blocks the current verdict.

Inconclusive

Available evidence cannot support a responsible verdict.

These messages are more useful than forcing every run into done or failed.

How paqad-ai uses receipts

paqad-ai’s feature-development design includes structured artifacts, an append-only evidence ledger, decision records, hashes, checks, review outputs, documentation state, and a final human-readable receipt.

The receipt should not claim certainty the evidence cannot support.

Its value is answerability: what changed, why, what proved it, what remained uncertain, who decided, and which exact artifacts the decision covered.

Source notes

• NIST AI RMF Playbook, Measure, voluntary accountability and audit guidance.
• Product mechanism: first-party details from the current Eliyce/paqad-ai repository.

Make the receipt readable during an incident

A receipt is most valuable when the original author is unavailable. Give it a stable location and a predictable order: target, identity, evidence, decisions, limits, verdict and recovery. Link to detailed logs instead of copying thousands of lines into the summary, but preserve enough context to interpret each result. Redact secrets without removing the command, environment or failure meaning.

Test the receipt by giving it to a reviewer who did not follow the agent session. Ask them to identify the changed behavior, last trustworthy revision, checks not run, accepted exception and safest recovery action. Any answer that requires the chat history reveals a missing field or unclear link.

Do not let the receipt become a ceremonial attachment generated after approval. Produce it throughout the workflow, append evidence at the point of origin and require the final owner to inspect its limitations before deciding. A compact honest receipt is more useful than a complete-looking record that hides uncertainty in raw logs.

Keep the human-facing summary short enough to review and the underlying evidence accessible enough to audit. The receipt should point to authoritative artifacts, not duplicate them. When a linked artifact is deleted or access changes, the receipt must show that loss rather than continuing to imply the evidence is available.

Paqad is a first-party Eliyce product. Teams that want to test these controls on their own repository can explore the AI Delivery Programme.

Frequently Asked Questions