verification-planning

Start by framing the exact claim your change must make true, then derive evidence paths from the system's controllable inputs, observable effects, and state transitions. Choose the path that produces a trustworthy conclusion with proportionate cost before writing implementation code.

An evidence path is a project-specific route from a claim about system behavior to evidence that can establish, limit, or refute it. It is derived from the system's boundaries, invariants, artifacts, and ability to repeat or reverse a scenario rather than from a familiar testing technique.

Use verification planning for non-trivial work like features, refactors, or cross-system changes where the right evidence is not obvious. Small mechanical changes can follow ordinary project checks directly without a dedicated planning step.

A verification affordance is the smallest capability that makes relevant system state controllable, observable, repeatable, and diagnosable. Create one when the existing system leaves the decisive truth too indirect or ambiguous, and decide deliberately whether it is temporary or durable.

Set a verification budget: state the distinct claims, assign one owner per claim, and choose the minimum non-duplicative evidence covering claims and boundaries. Reuse evidence only while its relevant code, inputs, environment, and state remain valid.