verification-disciplinelisted

# Verification Discipline > Status: v0.1 baseline draft — derived from the case catalog and axis definitions; awaiting trace evidence from Fable 5.1 case runs. ## When to apply - You are about to say "done", "fixed", "implemented", or "this should work" in any form. - You wrote or changed code but have not yet executed the changed path. - The requirement is stated in terms of runtime behavior: performance, concurrency, crash recovery, rendering, protocol compliance, or a user-visible flow. - A bug fix exists but the original failure has not been re-triggered against the fixed code. - Tests pass, but the requirement lives above the unit level (e.g., "the page loads fast", "no duplicate charge under load"). - You feel confident from reading the code alone. That feeling is the trigger, not the evidence. ## Core loop 1. **State the completion claim as an observable.** Before verifying anything, write down what "done" means as something the world can show you: "GET /orders returns 200 with the new field", "loss decreases for 500 steps", "the shell survives `kill -9` of a child process". If you cannot phrase the claim as an observation, the requirement is not yet understood — go pin it down first. 2. **Identify the layer the requirement lives at, and verify at that layer.** - User-visible behavior → drive the UI or hit the API end-to-end. - Throughput / latency → benchmark under representative load, not a single request. - Durability / crash safety → a