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:

$ ana proof security-hardening

╭───────────────────────────────────────────────────────╮
│  ✓ PASS · security-hardening                          │
│  cli · 74 min                             2026-05-04  │
╰───────────────────────────────────────────────────────╯

── Contract ──────────────────────────────────── 27/27 ✓
  ███████████████████████████████████████████████████
  ✓ 27 satisfied · 0 unsatisfied · 0 deviated

── Timing ─────────────────────────────────────────────
  Total      74 min
  Think       2 min
  Plan       15 min
  Build      53 min
  Verify      5 min

── Findings ──────────────────────────────── 3 debt · 7 obs
  [debt · scope] No dedicated integration tests for injection rejection
  [obs · monitor] getCurrentBranch still uses execSync
  8 more — see `ana proof security-hardening --json`

ana work complete now ends with a View the full proof: ana proof <slug> hint, so the command to read what you just shipped is always one copy away. To skip naming the slug, ana proof --last (alias --latest) shows the most recently completed proof — handy right after a run, or in scripts that always want the newest entry.

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 213 proofs: 11m think, 10m plan, 17m build, 6m verify.

#The assertion ledger

Every contract assertion, independently evaluated. The says field is human-readable; the status is mechanical.

✓ A001  Slugs with shell injection characters are rejected before any operation
✓ A003  Valid kebab-case slugs pass validation
✓ A023  No direct shell execution calls remain in command or utility files
  ...24 more, all satisfied

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 ana run learn. See Using ana-learn.

#Provenance

Below the findings, the proof records who did the work and at what cost. For each pipeline session it captures the model, turns, tool calls, input/output and cached tokens, and a derived cost — totaled across sessions — plus the code churn (files touched, lines added and removed) and a completeness check that every expected session was captured.

── Provenance ──────────────────────────────────────────
  model  claude-opus-4-8
  session  turns  tools    in    out  cache   cost
  ana         51     21  7.4k  26.0k   1.4M  $1.74
  plan        70     30  7.3k  53.1k   1.9M  $2.98
  build      115     52  7.8k  62.6k   5.1M  $4.92
  verify     120     53  8.1k  37.3k   4.6M  $3.97
  churn  9 files · +1638/−0
  completeness  ✓ complete (plan 1/1 · build 1/1 · verify 1/1)

Provenance is display-only. It tells you what the run cost, not whether it was correct — none of these numbers affect the PASS/FAIL verdict.

#Session attestation

The last section is behavioral attestation, produced by the anatrace-core engine from each agent's session transcript. For every captured session it checks the agent's claims — that it ran the commands it said it ran, touched the files it said it touched, consulted the skills it was told to — and marks each satisfied, violated, or unverifiable.

── Session Attestation ───────────────────── 3 transcripts
  core v0.4.0 · framework anatomia
  plan · 49 claims   ✓ 1 satisfied · 0 violated · 48 unverifiable
        coverage 1/49 checked · 48 unverifiable

Most claims read unverifiable — attestation only asserts what the transcript can prove, and abstains otherwise rather than guessing. Like provenance, session attestation is informational and does not gate the verdict — with one exception: if an agent's transcript shows it read a forbidden artifact (Verify reading the build report), that is a process violation that vetoes the run.

#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.

scope      sha256:13f7bad7930a...
contract   sha256:b9e52761c704...
build-report  sha256:67bc172dade8...
verify-report sha256:9f0dd78e9f3a...
...4 more artifacts

These are the real hashes from the security-hardening proof.