Skip to content

Termination Condition Design

Define explicit stop conditions so processes, searches, arguments, reviews, escalations, or recursive actions do not continue indefinitely.

The Diagnostic Story

Symptom: The review cycle keeps asking for one more check. The debugging session has no agreed boundary, so it expands to fill whatever time is available. An escalation bounces between levels without reaching final disposition. Work gets shipped because a deadline arrived or people got tired, not because any explicit done condition was met.

Pivot: Redesign the process so continuation is governed by explicit conditions: base cases for recursion, progress measures for iteration, completion criteria for review, exhaustion boundaries for search, and finality rules for escalation. Define what a stopped state looks like and what residual uncertainty gets recorded rather than resolved.

Resolution: Processes end on evidence rather than on exhaustion or deadline. Accountability for closure is clear because the stopping condition was defined before sunk-cost pressure or public commitment made revision feel costly. Residual uncertainty is documented rather than hidden, and reentry into the process is possible only under defined material conditions.

Reach for this when you hear…

[software QA] “We've been in final review for three weeks — if we don't define what done looks like we'll be here until someone just ships it out of frustration.”

[formal verification] “The proof kept requiring justification for the justification — you need a base case or the whole thing regresses to nothing.”

[regulatory appeals] “There's no final level in this appeals process — every denial can be appealed again and the case has been open for four years.”

Mechanisms / Implementations

  • Recursion Base Case: This is a rule_pattern implementation of the archetype.
  • Definition of Done: A single reusable, team-agreed standard for what 'done' means — the same bar every work item must clear — reviewed and re-tightened as the team learns.
  • Timebox: This is a limit_or_budget implementation of the archetype.
  • Iteration Limit: This is a limit_or_budget implementation of the archetype.
  • Convergence Threshold: This is a threshold_parameter implementation of the archetype.
  • Exhaustive Search Cutoff: This is a search_control implementation of the archetype.
  • Escalation Stop Protocol: This is a governance_protocol implementation of the archetype.
  • Finality Rule: This is a governance_rule implementation of the archetype.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (4)

  • Completeness: No gaps in structure.
  • Iteration: Repeats steps to refine outcomes.
  • Recursion: Breaks processes into self-similar steps.
  • Well Foundedness

Also references 5 related abstractions

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Base-Case Anchoring · subtype · likely subtype

Anchor recursive or progressive processes in clear base cases so later steps have a stable foundation and do not regress indefinitely.

Convergence-Based Termination · temporal variant · recognized

Stop iterative refinement when additional iterations produce changes below a declared tolerance or no longer improve the result enough to justify the cost.

Exhaustion-Based Termination · subtype · recognized

Stop when a declared bounded space of cases, options, sources, paths, or hypotheses has been completely inspected or ruled out.

Timeboxed Termination · implementation variant · recognized

End, pause, review, or replan work when a predefined time window expires.

Finality Condition Design · governance variant · candidate

Define when a dispute, review, appeal, or decision process becomes final enough for action, with narrow reopening conditions when needed.