← Articles
Proof

What is an AI coding proof receipt?

A proof receipt is the structured record an AI coding run leaves behind: what happened, what changed, what was validated, what evidence exists, and what is still uncertain. It is not a log of every step. It is a compact artifact designed to be trusted now and reused later.

Avorelo Topic: Proof Topic: Receipts Topic: Continuity 3 min read

A receipt, not a log

A log answers "what did the agent do, step by step." A receipt answers "what is the state of this work, and how much can I trust it." The distinction matters. A log is exhaustive and hard to act on. A receipt is selective and decision-ready.

The point of a receipt is that someone, including a future AI session, can read it and know where things stand without replaying the entire run.

What happened
Fixed token refresh race in the auth client
What changed
2 files, scoped diff: auth-client.ts, auth-client.test.ts
Validated
New test passes; type check and lint clean
Evidence
Test name, diff, build output attached
Uncertain
Behavior under 3+ concurrent refreshes not yet exercised

The five fields

A useful receipt answers five questions, each one a field a reader can scan:

  • What happened. The intent of the run, in one line.
  • What changed. The concrete edits, ideally as a scoped diff.
  • What was validated. The checks that ran and passed.
  • What evidence exists. The artifacts a reviewer can inspect: tests, diffs, output.
  • What remains uncertain. The honest gaps: what was not tested, what assumptions were made.

Why the uncertainty field matters most

The easiest field to omit is the one about what is still uncertain, and it is the most valuable. A receipt that only lists successes invites overconfidence. A receipt that names its gaps tells the reader exactly where to focus and tells the next session what work is left.

Honest uncertainty is what separates a receipt from marketing. It is also what makes the receipt safe to build on: the next run knows which assumptions are load-bearing and which have been verified.

Receipts as reusable context

A receipt's second life is as the starting context for the next session. Instead of re-explaining the project or rediscovering the state of a feature, the next run reads the receipt and begins from a known position: here is what was done, here is what holds, here is what is open.

This is what makes proof an investment rather than overhead. The evidence captured at the end of one run is the head start at the beginning of the next.

A receipt is written to be reused. It is structured so a reviewer can trust it today and a future session can build on it tomorrow, without replaying the work in between.

How Avorelo helps

Every clean Avorelo run produces a proof receipt with these fields: what happened, what changed, what was validated, what evidence exists, and what remains uncertain. The receipt stays local, attached to the work, and is available both for review and as the starting context for the next session.

That is the mechanism behind faster reviews and faster restarts: proof captured once, trusted now, and reused later.

Proof captured once, reused later.

Avorelo produces a proof receipt on every clean run: what changed, what was validated, what is still uncertain. Local-first.

Start free See how Avorelo works