Docs · Proof
Understanding proof
The proof gate is the core of Zero's credibility model. This page explains why it exists.
The problem
“Done” is a statement, not evidence. AI coding tools mark Work items done quickly. Without a trace, the same problem reopens in six weeks and you restart from scratch — no record of what was tried, what worked, or why the resolution held.
The proof gate exists because memory without evidence is just a log. Evidence without structure can't be found when the issue returns.
What proof does
Proof creates a chain of evidence from problem to resolution. When the same issue reopens, the past resolution is trustworthy because it has an attached trace — not just a note that says “we fixed this in March.”
Zero's regression memory uses proof records to recognize when a new Work item resembles a previously resolved one. Without proof, that match is unreliable.
Proof is not overhead
If your session produced test output, attaching it takes 10 seconds. The constraint is intentional: if you can't produce evidence, the Work item shouldn't close.
The proof gate is not a bureaucratic checkpoint. It's a forcing function that distinguishes a resolved Work item from a Work item that was declared resolved.
Minimum viable proof
For most Work items, a test log with the key tests passing is sufficient. Zero doesn't require a comprehensive audit — just enough evidence to defend the resolution if it's challenged later.
- Bug fix: test log showing relevant tests pass.
- Feature: test output or a short operator note confirming behavior matches spec.
- Refactor: before/after benchmark output, or test log confirming no regressions.
- Greenfield: passing test suite or a spec-to-implementation diff showing completeness.
Proof for non-code outcomes
For outcomes like IntendedBehavior or Unreproducible, a code change never happened — so test output isn't available. An operator note explaining the investigation is valid proof: what was checked, what was found, and why the Work item can be closed.