Reading a proof
Every pipeline run produces a proof — a JSON record committed to your repo that captures what was built, how it was verified, and whether it can be trusted. This guide walks through security-hardening so you know what each part means.
What you see in the terminal
After ana work complete, run ana proof <slug> to see the summary:
The proof page on the docs site shows the same data with more detail. Each section below maps to a part of that page.
The hero
Six numbers at the top of every proof page:
Monorepo projects show one additional label: the surface that was verified.
Score is contract assertions satisfied. Findings are independent observations from Verify — they don't block shipping. Rejections count how many times Build had to fix and re-verify. A proof with rejection cycles shows a longer build and a Previous Findings Resolution section — see proof-promote for that story.
The timeline
Four bars showing Think, Plan, Build, and Verify. The shape tells you what kind of work this was. Security-hardening: Think 2m, Plan 15m, Build 53m, Verify 5m — a heavy build, light verification. Compare with worktree-isolation: Think 3m, Plan 22m, Build 63m, Verify 11m — similar build but double the verification time because the contract had 45 assertions.
What each phase measures. Each bar spans from session start to artifact save for that agent. Think begins when Ana opens the scope conversation and ends when the scope is committed. Plan begins when AnaPlan starts and ends when the spec and contract are saved. Build and Verify follow the same pattern — session open to artifact save.
Why duration exceeds the sum of phases. The header duration is wall-clock time from the first _started_at timestamp to the last artifact save. The bars show active session time only. Idle time between sessions — the gap between Plan finishing and Build starting, lunch breaks, overnight pauses — inflates the header but doesn't appear in any bar. A proof showing 2h 9m in the header and 21m in the bars means 1h 48m was idle time between sessions.
Multi-phase timing. Some proofs split Build or Verify into numbered phases (Build 1, Build 2). Each phase gets its own bar, measured from that phase's session start to its artifact save. The bars are proportional to active time — a 3-minute verify phase next to a 53-minute build renders at roughly 5% width, not stretched to fill the remaining space.
The median across all 163 proofs: 9m think, 9m plan, 16m build, 6m verify.
The assertion ledger
Every contract assertion, independently evaluated. The says field is human-readable; the status is mechanical.
The ledger shows 27/27 SATISFIED. If any assertion were UNSATISFIED, the verdict would be FAIL and the work would go back to Build. The assertions are the mechanical definition of "done" — what the contract said, what Verify found.
The findings
Each finding has a severity and a suggested action, rendered as a two-part tag:
debt · scope means: the codebase is getting worse (debt) and this needs engineering work (scope). obs · monitor means: worth knowing (observation) but watch it, don't act now (monitor). Findings enter the proof chain and are triaged by Learn between cycles.
Security-hardening's findings focus on test coverage gaps. Other proofs surface different catches: process.exit(1) on a rebase conflict without running git rebase --abort, leaving dirty state. JSON.parse on CLI stdout with no try/catch — malformed response crashes. Path normalization that breaks on Windows backslashes. A race condition where a file deleted between filter and readFileSync crashes completeWork.
To triage findings after shipping, run claude --agent ana-learn. See Using ana-learn.
The integrity seal
SHA-256 hashes of every artifact — scope, spec, contract, both reports, both data files. If any artifact changes after shipping, the hashes won't match.
These are the real hashes from the security-hardening proof.