Skip to content

Termination Condition Design

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

Solution archetype #
1071
Problem family
Decision, Search & Optimization Failure
Problem subfamily
Stopping, Closure & Marginal Value

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.”

When This Archetype Applies

Partial catalog groundingSome structural conditions are represented by existing abstractions, but no sufficient condition set is fully represented.

A recursive, iterative, deliberative, search, review, escalation, approval, or refinement process lacks a clear stopping rule, causing work to continue indefinitely, regress to ever-earlier justifications, re-enter the same state repeatedly, or avoid final disposition.

What this problem means

The structural problem is nontermination. A process has a path that lets it continue by default: another recursion, another appeal, another review pass, another search expansion, another retry, another request for evidence, or another refinement. Because the end condition is implicit or contested, the process either continues until exhaustion or stops for reasons no one can inspect.

This is a well-foundedness problem in practical form. Without a base case, bounded space, progress measure, threshold, or finality rule, the system lacks a reliable bottom.

Show the applicability expression

Applicability expression6 distinct conditions

Self-continuing processandDisputed completion criteriaandDeclining marginal valueandUnbounded escalation pathandHigh-stakes stoppingandUnbounded exhaustive claim
Algebraic123456

groundedpartly groundedopen

6 conditions, all required.

6Required in every casenumbered 1–6

These hold no matter which pattern applies.

1

Self-continuing process · grounded

The process can call itself, retry, loop, escalate, reopen, revisit, or continue adding refinements.

2

Disputed completion criteria · grounded

Participants disagree about what counts as done, sufficient, exhausted, converged, or final.

3

Declining marginal value · open

The marginal value of more review, search, evidence, or refinement is falling but the process keeps consuming resources.

4

Unbounded escalation path · grounded

Escalation, exception handling, or appeal routes have no final level or reentry boundary.

5

High-stakes stopping · grounded

A process is safety-, rights-, cost-, or trust-sensitive enough that arbitrary stopping would be harmful.

6

Unbounded exhaustive claim · grounded

An exhaustive search or review claims completion but lacks a bounded universe or evidence of exhaustion.

5 of 6 conditions grounded · 1 open.

Read the methodologyDownload the trigger-logic data

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)

Also references 5 related abstractions

  • Boundedness: Values remain within limits.
  • Convergence: Movement toward stable state.
  • Infinite Regress: Endless chain of explanation.
  • Order: Defines ranking or sequencing relationships.
  • Threshold: Safe vs harmful levels.

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.

Editorial Notes

Problem Classification

Classification: Decision, Search & Optimization FailureStopping, Closure & Marginal Value

Problem kernel: recursive or iterative work lacks a well-founded stopping rule

Rationale: Earliest causal condition: A recursive, iterative, deliberative, search, review, escalation, approval, or refinement process lacks a clear stopping rule, causing work to continue indefinitely, regress to ever-earlier justifications, re-enter the same state repeatedly, or avoid final disposition.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A recursive, iterative, deliberative, search, review, escalation, approval, or refinement process lacks a clear stopping rule, causing work to continue indefinitely, regress to ever-earlier justifications, re-enter the same state repeatedly, or avoid final disposition. That is a stopping closure and marginal value problem because Inquiry, iteration, escalation, batching, or deliberation lacks a credible rule for whether the next increment remains worthwhile and when a sufficient choice becomes final.

Review outcome: Independent reviewer agreement; high confidence.