Operate · Chapter 5
Prove it
Establish Evidence continuously. Shipping proves something changed; it does not prove the Outcome.
Understand
Prove is not "after Build". It happens throughout Build.
Claims require Evidence proportional to their consequences.
Use three questions.
Did we build it correctly?
Use deterministic verification where the fact is knowable: tests, type checks, linting, schema validation, build checks, reproducible assertions.
Never ask judgment to do the work of determinism.
Is it good enough?
Some claims require judgment: UX quality, coherence, architectural fitness, copy quality, whether the result solves the problem you designed for.
Use genuinely independent review where independence matters.
Another agent repeating the author's reasoning is not automatically independent Evidence.
Confidence comes from independent Evidence, not repeated agreement.
Did it work in reality?
Shipping proves something became real. It does not prove the Outcome occurred.
Look for Evidence where the claim lives: customer behavior, runtime behavior, production telemetry, business results, observed workflow changes, or direct experiential verification.
Do this on your project
Write down the claims you expect to make about the current Slice or Bet. For each one, ask:
What Evidence would actually justify saying this is true?
Then obtain it.
This part is yours
Where consequence requires human authorization, an agent cannot turn Evidence into permission by itself. Risk acceptance and accountability remain Authority decisions.
Look for
Keep these distinct.
- Output — what changed.
- Evidence — what we observed.
- Outcome — the change in reality we hoped to cause.
What you just learned
Done means shipped and verified, not merged.
Progress is reduction of meaningful uncertainty through Evidence. Conclusive Evidence that tells you to stop is progress.