Proof

A completed task is not a verified task

Completion and verification are not the same signal. How Avorelo captures structured proof that the next run can trust, not just a status that says it worked.

Field Notes May 2026 3 min read

The problem with done

AI coding tasks generate a lot of done. The task completes, the status updates, the agent reports success. But done is a claim about what happened. It is not evidence of what was produced.

The difference matters most in chained work, where one run's output becomes the next run's starting assumption. When the prior run was done but not verified, the assumption is wrong and nobody caught it yet.

This is not a trust problem. It is a structural gap between what AI agents naturally produce (completions) and what engineering workflows actually need (verification records).

From change to reusable proof

Change made
Task complete
agent reports done
Validated
Tests pass
scope confirmed
Captured
Receipt stored
structured, queryable
Next run
Context ready
no re-explanation needed

What a receipt actually contains

Each Avorelo run that exits cleanly produces a session receipt. It is not a log. It is a structured record designed to be consumed by the next run, by a reviewer, or by a team report.

Example: session receipt summary
TaskRefactor auth middleware
Files changed2 of 2 in scope
Tests run14 passed, 0 failed
Scope driftNone detected
Safe fix applied1 (unused import removed)
Approval requiredNone
StatusVerified

Why done is not enough

A completion status answers one question: did the agent finish? It does not answer whether the output was correct, whether the scope was respected, whether any tests caught regressions, or whether a reviewer needs to see it.

Teams compensate for this by asking the agent to explain what it did, re-reading diffs manually, or running validation steps that should have been part of the run. Each of those is overhead that compounds with team size and task frequency.

The cost of unverified completion is not the failed task. It is the correct task that becomes the wrong assumption for the next run.

Proof as a first-class output

Avorelo treats the receipt as a first-class output of every run, not an optional attachment. If a run cannot produce a clean receipt, it does not exit with a done status. It exits with a needs attention status and surfaces the gap.

This makes verification a property of the run, not a separate step. The next agent that picks up the task does not need to ask what the prior run did. The answer is in the receipt, structured, queryable, and trustworthy.

The compounding effect

In a single task, the gap between completion and verification is small. Across a day of work in a busy repo, it accumulates. Teams that run frequent AI tasks without structured proof end up re-explaining the same context repeatedly, because each new run cannot trust the prior one's output without checking manually.

Structured proof closes that loop. The receipt from run N becomes context for run N+1. The AI does not re-read the same files to understand what changed. It reads the receipt.

Proof is not about auditing AI behavior. It is about giving the next run something real to start from instead of having to reconstruct what already happened.

What to look for in your own work

Each of these is a verification gap. The work was done. The evidence was not kept.

← Broad access is the unsafe default The wrong tool for the job costs more →

Turn every run into a verified receipt.

Avorelo captures structured proof automatically. Your next run starts with context, not questions.

Start free in your repo