Define a Stopping Condition Before You Start Checking

Verification without a stopping condition can become an endless search for certainty.

Define what evidence would count as sufficient before beginning the verification loop. Without a stopping condition, every successful check creates the possibility of another check: "Perhaps I should inspect one more file." "Perhaps I should rerun the test." "Perhaps another source would increase confidence." "Perhaps there is an edge case I have not considered." This can continue indefinitely because absolute certainty is rarely available. A useful verification plan identifies: 1. what could realistically fail, 2. which checks would reveal those failures, 3. what result counts as acceptable, 4. what uncertainty can reasonably remain, 5. and when work should be delivered. This turns verification from open-ended anxiety into a bounded engineering activity. **Note — this is the missing half of the leash rule.** The generators-on-a-leash rule bounds a *run* by wall clock: no generator or batch launches without a cap. Nothing bounded a *verification loop*, which is why checking could expand quietly while a run stayed inside its timeout. Same discipline, different object: the run gets a deadline, the checking gets a stopping condition, and both are set before the work starts, never discovered from the failure afterwards.

An AI coding agent changes one mobile navigation component. A poor instruction says: "Verify thoroughly that everything still works." The agent may interpret "thoroughly" without limit. A stronger instruction says: "Render the affected view at the required breakpoints, test the changed navigation actions, confirm no console errors related to the component, and stop if all checks pass." Now the agent knows what completion means.

More from the same record, pulled by shared topic — not written new for this page.

Verification without a stopping condition can become an endless search for certainty.