Skip to content

Termination Condition

Prime #
1230
Origin domain
Computer Science & Software Engineering
Subdomain
algorithms and control flow → Computer Science & Software Engineering

Core Idea

A termination condition is the explicit, checkable predicate that decides whether an iterative or recursive process stops or continues. It lives at the same structural level as the process itself: every loop, every recursive descent, every regress, every search, every negotiation, every optimization run, every clinical trial is an unfolding-over-steps that requires a separate, named rule for halting — and the entire character of the process is determined by which condition is chosen and whether it is guaranteed to be met.

The structural commitment is sharp. A process plus a termination condition is a bounded computation, with a guaranteed final state, worst-case resource use, and a definable output. A process without one is a non-halting process, with no guaranteed final state, unbounded resource use, and at best a stream rather than a result. The work of designing the condition — what predicate, evaluated when, on what state — is structurally separate from the work of designing the iteration. Designs that conflate the two reliably produce one of the canonical pathologies: infinite loops, infinite regress, premature stopping, deadlock on failure to terminate, runaway optimization, escalation of commitment past the point of return. A second feature gives the prime its bite: the termination condition depends on what the process is meant to deliver. A search terminates when the goal is found (success), or when the search space is exhausted (failure), or when a budget is depleted (resource bound) — three structurally different conditions with three structurally different post-termination guarantees. Choosing the wrong family of condition silently corrupts what the process means even when the iteration is correctly coded. The pattern is a bare predicate-on-an-iterative-process, with no imported context.

How would you explain it like I'm…

When To Stop

When you play hide-and-seek, you need a rule for when the counting stops — like 'count to ten, then go look.' Without a stopping rule, you'd just keep counting forever and never go find anyone. Every game that repeats needs a clear 'okay, stop now' rule.

The Stopping Rule

A Termination Condition is the clear rule that tells a repeating process when to stop. Think of any loop — stirring until the batter is smooth, searching until you find your shoe, counting down until zero. The rule for stopping is a *separate* thing from the doing itself, and you have to pick it on purpose. If you forget it or pick a bad one, you get problems: going forever and never stopping, or stopping too early before you're actually done. The rule also depends on *what you want*: you might stop because you found what you were looking for, or because you ran out of places to look, or because you ran out of time — and those are three different kinds of stopping.

The Halt Predicate

A Termination Condition is the explicit, checkable rule that decides whether a repeating or recursive process keeps going or stops. It sits at the same level as the process itself: every loop, search, negotiation, or optimization run is something that unfolds step by step and *needs* a separate, named rule for halting — and the whole character of the process depends on which rule you pick and whether it's guaranteed to be met. A process *with* a good condition is a bounded computation: it has a guaranteed final state, a worst-case cost, and a definable output. A process *without* one never reliably halts: no guaranteed end, unbounded resource use, at best a stream rather than a result. Designing the stopping rule is a separate job from designing the steps, and conflating them produces classic failures — infinite loops, infinite regress, stopping too soon, runaway optimization. Crucially, the right rule depends on what the process is meant to deliver: stop on *success* (goal found), on *failure* (search space exhausted), or on a *budget* (time or money depleted) — three different conditions with three different guarantees afterward.

 

A Termination Condition is the explicit, checkable predicate that decides whether an iterative or recursive process stops or continues. It lives at the same structural level as the process itself: every loop, recursive descent, regress, search, negotiation, optimization run, or clinical trial is an unfolding-over-steps that *requires* a separate, named rule for halting, and the entire character of the process is determined by which condition is chosen and whether it is guaranteed to be met. The structural commitment is sharp: a process *plus* a termination condition is a bounded computation, with a guaranteed final state, worst-case resource use, and a definable output; a process *without* one is non-halting, with no guaranteed final state, unbounded resource use, and at best a stream rather than a result. Designing the condition — what predicate, evaluated when, on what state — is structurally separate from designing the iteration, and designs that conflate the two reliably produce the canonical pathologies: infinite loops, infinite regress, premature stopping, deadlock on failure to terminate, runaway optimization, escalation of commitment past the point of return. A second feature gives the prime its bite: the condition *depends on what the process is meant to deliver*. A search terminates when the goal is found (success), when the space is exhausted (failure), or when a budget is depleted (resource bound) — three structurally different conditions with three structurally different post-termination guarantees. Choosing the wrong family of condition silently corrupts what the process means even when the iteration is correctly coded. The pattern is a bare predicate-on-an-iterative-process, with no imported context.

Structural Signature

the iterative or recursive process unfolding over steps — the process state the predicate reads — the halting predicate itself — the evaluation point at which it is checked — the well-foundedness argument guaranteeing the predicate is reached — the post-halt state and what it is certified to mean

A process has a termination condition when each of the following holds:

  • An unfolding process. A loop, recursion, search, negotiation, optimization, or trial that proceeds step by step and could in principle continue indefinitely.
  • A readable state. The process carries a state on which a predicate can be evaluated at each step.
  • A halting predicate. An explicit, checkable rule that decides continuation versus stopping; it lives at the same structural level as the process and is structurally separate from the step logic.
  • An evaluation point. A specified moment in the step cycle at which the predicate is tested.
  • A well-foundedness argument. A separate argument — monotone progress over a bounded or well-ordered state — that the predicate will actually be reached, distinguishing a bounded computation from a non-halting one.
  • A post-halt certification. The predicate's family (success: goal reached; failure: impossibility detected; resource: budget depleted; no-progress: convergence/stagnation; external: deadline/signal) determines what the final state is guaranteed to mean.

The components compose the boundary of a process: choosing the predicate family and its well-foundedness argument is structurally distinct from designing the iteration, and that choice partly determines what the process delivers — the wrong family silently corrupts the result even when the iteration is correctly coded.

What It Is Not

  • Not iteration. iteration is the unfolding process — the repeated step itself. A termination condition is the separate predicate that decides when the iteration stops; the two live at the same level but are designed independently, and conflating them is the canonical source of infinite loops.
  • Not well-foundedness. well_foundedness_well_ordering is the argument that a process must reach a halting state (monotone progress over a bounded or well-ordered state). The termination condition is the predicate that is checked; well-foundedness guarantees the predicate is reachable, but they are different objects — a condition can exist without any well-foundedness argument behind it.
  • Not an optimal stopping rule. optimal_stopping_rule chooses when to stop to maximize an expected payoff under uncertainty. A termination condition merely defines a halting predicate; it need carry no optimality claim, and most (loop exit, base case) make none.
  • Not a constraint. constraint restricts the feasible states of a system throughout its operation. A termination condition is a predicate on the process's progress, evaluated to decide continuation; it bounds time, not the solution space.
  • Not convergence. convergence is the dynamical fact that a sequence approaches a limit. A termination condition may test for convergence (a no-progress predicate), but convergence is a property of the trajectory while the condition is a checkable rule — and a no-progress halt can fire far from any true limit.
  • Common misclassification. Assuming a loop stops because "it has to" without naming the predicate — implicit termination. The dual error is premature termination: a stopping rule chosen to make the answer come out right (p-hacking, mid-game concession). A sound design fixes the predicate in advance and supplies a guaranteed backstop.

Broad Use

Termination conditions, read as halting predicates on iterative processes, recur across substrates that unfold over steps. In computer science and algorithms they are loop exit conditions, recursion base cases, convergence criteria of iterative solvers, protocol timeouts, and episode stopping rules — the discipline is built on noticing that halting is structurally separate from progress. In mathematics and logic, foundationalism holds that epistemic regresses terminate at self-justifying basic beliefs, coherentism replaces termination with a cyclic structure, and infinitism refuses termination, so the structural choice of condition is the philosophical position. In statistics, sequential analysis defines acceptance and rejection thresholds at each interim look, group-sequential designs use spending functions as stopping rules, and adaptive trials add futility bounds. In optimization and control, convergence criteria for nonlinear solvers, early stopping in training, and branch-and-bound termination on the bound gap all instantiate the pattern. In engineering, tolerance bands, inspection stop rules, and mission-abort criteria do the same. In negotiation, deadlines and walk-away points are termination cues, and finite-horizon games terminate by clock. In project management, "definition of done," kill-criteria, and the sprint timebox are termination rules. And in biology, apoptosis terminates cell life on checkpoint failure, telomeres terminate replication, and satiety signals terminate feeding. In every case the same structural object appears: a predicate on the process's state, evaluated at each step, that decides continuation versus halting, and whose choice partly determines what the post-halt state means.

Clarity

Naming the termination condition separates what the process does each step from what makes it stop, two questions that have systematically different answers and call for different design work. It exposes the common error of implicit termination: assuming a loop will stop because "it has to" without naming the predicate that guarantees it — the source of most production infinite loops, most philosophical regress problems, and most optimization runaways. It also exposes the dual error of premature termination: a stopping rule chosen to make the result come out the right way, as in early stopping in clinical trials, optional-stopping p-hacking, or ending negotiations when you are winning. The vocabulary further clarifies why "the same algorithm with different stopping rules" can produce structurally different objects: gradient descent with a fixed iteration count is a different estimator from gradient descent with a convergence tolerance, which is different again from gradient descent with early stopping on validation loss. Naming the condition explicitly makes the estimator's identity legible. The clarifying force is to surface the halting rule as a first-class object with its own correctness obligations, rather than leaving it as an unexamined appendage of the iteration.

Manages Complexity

The prime compresses a large class of design questions about repeated processes to a small structured choice: which family of termination condition, evaluated when, guaranteed to be reached or not, and meaning what at the post-termination state? The same checklist applies to a training loop, a clinical trial, a foundationalist epistemology, a sales negotiation, and a control system, with each substrate filling in substrate-specific values for the same structural slots. The structural taxonomy of termination conditions is itself compact and cross-domain: success conditions (goal reached), failure conditions (impossibility detected), resource conditions (budget depleted), no-progress conditions (convergence or stagnation), and external conditions (deadline or signal). Most production stopping policies are combinations of two or three, and the choice of combination shapes the character of the process. The complexity managed is the apparent diversity of "when to stop" decisions across fields: rather than a separate craft of stopping for algorithms, trials, negotiations, and proofs, there is one taxonomy of five condition families and one checklist of four design questions, so an analysis built in one domain transfers wholesale, and a novel process can be audited for which branches it includes and which it dangerously omits.

Abstract Reasoning

Termination condition supports several portable inferences. Halting requires a separate argument: proving that an iterative process terminates is structurally distinct from proving that it does the right thing while iterating, and conflating the two is a recurring engineering bug. Monotone-progress plus bounded-state implies termination: if each step monotonically changes a state variable that lives in a bounded set, termination is forced, which is the underlying form of nearly every classical termination proof — loop variants, well-founded recursion, decreasing measure functions. No-progress conditions are dangerous near optima: a stopping rule based on "the objective stopped improving" can halt arbitrarily close to or far from the optimum depending on the landscape, with the cross-domain symptom of solvers converging to wrong answers and early-stopped models acquiring avoidable bias. Optional stopping inflates false positives: a rule allowed to look at the data and choose when to stop violates fixed-design statistical guarantees, the same structural fact appearing in p-hacking, mid-game concession in negotiation, and early stopping for non-inferiority. And regress termination is a commitment: a foundationalist stop at self-justifying beliefs, a coherentist refusal to terminate, and an infinitist acceptance of unending regress are positions with different epistemic costs, with analogous choices in legal-authority hierarchies, type-system universe hierarchies, and the question of what counts as a stopping point for "why?"

Knowledge Transfer

Because a termination condition is a bare predicate on an iterative process, a stopping-rule technique built in one substrate transfers to another by re-identifying the process, the predicate, and the post-halt guarantee, and the prime's reach is the reach of that re-identification. The branch-and-bound termination vocabulary — gap closure, bound improvement — maps directly to group-sequential trial design with its efficacy and futility bounds, with parallel mathematical structure and parallel optional-stopping pathologies, so an algorithm designer's stopping intuition becomes a trial statistician's. The sequential-analysis warning about optional stopping transfers directly to validation-loss early stopping in deep nets, with the same cure — pre-registered stopping rules and hold-out discipline — so a statistical guarantee about looks at the data becomes a machine-learning guarantee about epochs. The well-founded-recursion argument that every recursive descent must bottom out at base cases is structurally the foundationalist argument about epistemic regress — same well-foundedness, same axiomatic bottoming-out, same alternative responses of cycles or infinite-regress acceptance — so reading philosophy with computer-science vocabulary clarifies the structural choices. Apoptosis and immune-resolution programs are precisely engineered termination conditions whose design principles — checkpoints, resolution-promoting signals, end-of-program cleanup — transfer to graceful-shutdown design in software. And the negotiation walk-away point is the participant's stopping condition, whose existence rules out infinite bargaining and whose mis-estimation explains many failures to reach agreement on time, transferring directly to finite-horizon game theory. In every transfer the practitioner runs the same procedure — name the iterative process, choose the family of termination condition (success, failure, resource, no-progress, external) and usually combine several, fix the evaluation point, supply the well-foundedness argument that the process reaches a halting state, and state what the post-termination state is certified to mean — and the transfer is structural rather than metaphorical because none of these steps names the substrate: a Newton-Raphson root-finder wiring convergence, success, and budget branches together and a philosophy seminar arguing whether to stop at foundations, impossibility, or the session's end are making the same compound choice, distinguished only by what is iterating and what its halting is certified to mean.

Examples

Formal/abstract

Newton-Raphson root-finding makes every role of the prime explicit and shows why the choice of condition family silently determines what the answer means. The unfolding process is the iteration \(x_{n+1} = x_n - f(x_n)/f'(x_n)\), which under good conditions doubles the number of correct digits each step. The readable state is the pair \((x_n, f(x_n))\) together with the step size \(|x_{n+1}-x_n|\). The interesting design fact is that a production solver almost never uses one halting predicate; it composes three from different families, and the post-halt certification depends on which one fired. A success condition — \(|f(x_n)| < \epsilon\) — certifies "a root was found to tolerance \(\epsilon\)." A no-progress condition — \(|x_{n+1}-x_n| < \delta\) — certifies only "the iterate stopped moving," which near a flat derivative can fire arbitrarily far from any root, the prime's "no-progress conditions are dangerous near optima" warning made concrete. A resource condition — \(n > N_{\max}\) — certifies nothing about correctness at all; it merely caps cost and is the well-foundedness backstop that converts a possibly-non-halting process into a bounded computation. The prime's diagnosis is sharp: a solver that returns a confidently wrong answer is usually one where the no-progress branch fired but was reported as success — the certification was attached to the wrong family. The well-foundedness argument is equally explicit: only the iteration-cap branch is guaranteed to be reached, since the function-value branch can fail forever on a function with no root in range, so a correct design must include the resource family precisely to guarantee termination. The intervention the prime names is to wire the branches with distinct return codes — converged, stalled, exhausted — so the caller learns which condition stopped the process and therefore what the result is certified to mean.

Mapped back: Newton-Raphson is the prime's compound-condition structure in pure form — success, no-progress, and resource predicates on one iteration, each with a different post-halt certification — and its classic failure (returning a stalled iterate as a root) is exactly the prime's warning that the wrong condition family silently corrupts the result.

Applied/industry

Two unrelated applied domains — interim monitoring of a clinical trial and the kill-criteria of an agile product sprint — run the same compound-halting structure. A group-sequential clinical trial is an iterative process whose steps are interim looks at accumulating data. Its halting predicate is not one rule but several from the prime's families wired together: an efficacy boundary (a success condition — stop early if the treatment is clearly working), a futility boundary (a failure condition — stop if it clearly cannot work), and the maximum sample size (a resource condition — the well-foundedness guarantee that the trial ends). The prime's "optional stopping inflates false positives" inference is the entire reason the boundaries are computed from a pre-registered spending function rather than chosen on the fly: a stopping rule allowed to look and decide when to stop violates the fixed-design false-positive guarantee, so the post-halt certification ("the effect is real at level \(\alpha\)") is only valid if the predicate was fixed in advance. A sprint's kill-criteria map cleanly onto the same diagram: the iterative process is the repeated sprint cycle, the definition of done is a success condition, an explicit kill-criterion (no user traction after N sprints) is a failure condition, and the timebox plus budget is the resource condition guaranteeing the effort cannot run forever. The prime's premature-termination warning applies with equal force: a team that quietly drops the kill-criterion and keeps iterating because momentum feels good is committing the escalation-of-commitment pathology, the project-management form of an implicit non-terminating loop. The intervention in both is the prime's: name each halting predicate, fix it in advance, supply the resource backstop that guarantees termination, and state for each branch what the stop certifies.

Mapped back: A group-sequential trial and a sprint kill-criteria set both compose success, failure, and resource conditions on an iterative process with a pre-committed evaluation rule, and both fail through the prime's optional-stopping and escalation pathologies, so the discipline — fix the predicate in advance, guarantee a resource backstop — transfers from biostatistics to product management unchanged.

Structural Tensions

T1 — Halting versus Correctness (scopal). Proving that a process stops is structurally separate from proving it does the right thing while running, and the two demand different arguments. The failure mode is conflating them — assuming a loop that terminates also produces a valid result, or that correct step logic guarantees termination. Diagnostic: ask whether the well-foundedness argument (the process reaches a halting state) and the correctness argument (the halt state is what you want) are stated separately. If a design has only one, it has silently assumed the other; a process can terminate reliably on a wrong answer, or compute correctly yet never stop.

T2 — Success versus Resource Condition (measurement). The post-halt state means something different depending on which condition family fired — a success predicate certifies the goal was reached, a resource cap certifies only that the budget ran out. The failure mode is attaching the success certification to a resource or no-progress halt, reporting "converged" when the iteration cap fired or the iterate merely stopped moving. Diagnostic: wire each halting branch to a distinct return code and check what each is provably entitled to claim. If the caller cannot tell which condition stopped the process, it cannot know what the result means, and a stalled or exhausted run will masquerade as a solved one.

T3 — Premature versus Implicit Termination (sign/direction). Two opposite errors flank a good stopping rule: stopping too early (a rule chosen to make the answer come out right — p-hacking, mid-game concession) and never stopping (no explicit predicate, the loop "has to" end). The failure mode is on whichever side the design neglected — premature halting biases the result, missing termination runs forever. Diagnostic: ask whether the stopping rule was fixed before the process ran and whether a guaranteed backstop exists. If the predicate can be chosen by looking at the data, premature stopping is live; if no resource condition exists, non-termination is live; a sound design closes both.

T4 — No-Progress Halting versus the True Optimum (scalar). A "stop when the objective stops improving" rule can fire arbitrarily near to or far from the optimum depending on the landscape — flat regions, plateaus, and saddle points fool it. The failure mode is a solver or trainer that halts on stagnation and reports a stalled iterate as a solution, acquiring avoidable bias. Diagnostic: ask whether no-progress can occur away from the goal in this landscape. If the objective can flatten without being optimal — a near-zero gradient far from any root, a loss plateau before true convergence — a no-progress condition alone is unsafe and must be paired with a success check or a restart from a perturbed state.

T5 — Fixed-Design Guarantee versus Optional Stopping (temporal). A statistical or contractual guarantee computed for a fixed horizon is violated when the stopping moment is chosen adaptively from the unfolding data. The failure mode is preserving the appearance of rigor — a p-value, a confidence level — while the looking-and-deciding-when-to-stop inflates false positives the fixed design assumed away. Diagnostic: ask whether the evaluation points and boundaries were pre-registered. If the process is allowed to peek at intermediate state and halt opportunistically, the fixed-design certification is void; the fix is a pre-specified spending function or alpha-correction that prices the repeated looks.

T6 — Single versus Compound Conditions (coupling). Real processes rarely halt on one predicate; they compose success, failure, and resource conditions whose interactions determine behavior, and the conditions can mask or race each other. The failure mode is designing one clean halting rule and discovering an un-handled branch — no failure case for the unreachable goal, no resource backstop behind a success test that can fail forever. Diagnostic: enumerate the condition families present and ask which guarantees termination. If only the success branch exists and it can fail indefinitely (a search for an absent target), the compound is incomplete; every halting design needs at least one branch — typically resource — that is provably always reachable.

Structural–Framed Character

Termination condition sits at the structural end of the structural–framed spectrum. Although it originates in computer-science control flow, the pattern it names — an explicit, checkable predicate that decides whether an iterative or recursive process stops or continues — is a bare predicate-on-a-process, and on every diagnostic it reads structural, matching the frontmatter's all-zero criteria and aggregate of 0.0.

Walking the five diagnostics with this prime's substrates: vocabulary travels freely. The same halting-predicate structure is told in loop exits and base cases in algorithms, in foundationalist regress-stopping in epistemology, in efficacy and futility boundaries in sequential analysis, in convergence criteria in optimization, in walk-away points in negotiation, in definition-of-done in project management, and in apoptosis and satiety in biology — each substrate names the predicate and its post-halt meaning in its own words, importing no "control-flow" lexicon. Evaluative weight is absent: a halting predicate carries no approval; stopping is neither good nor bad until you specify what the process delivers, which is why premature and implicit termination are symmetric failure modes rather than a moral asymmetry. Institutional origin is formal — the structure is fully stated as a predicate read on a process's state with a well-foundedness argument, with no appeal to human institutions. It is not human-practice-bound: it runs indifferently in a Newton-Raphson solver, in telomere-limited replication that no human mediates, and in apoptosis checkpoints, as well as in deliberately designed negotiations. And invoking it recognizes a pattern already present rather than importing a frame — to point at a termination condition is to identify a real predicate one can test by asking whether a given state continues or halts, not to overlay an interpretation. Every diagnostic points the same way, and the prime is structural without qualification.

Substrate Independence

Termination Condition is about as substrate-independent as a prime can be — composite 5 / 5 on the substrate-independence scale. Its signature — a halting predicate evaluated against the state of an ongoing process that decides when to stop — is a pure relational object with no commitment to any medium, so it is recognized rather than translated when it surfaces in a new field. Its domain breadth is maximal: the identical stopping-predicate structure governs loops and recursion in computer-science algorithms, the foundational halting question in mathematics and logic, optional-stopping rules in sequential statistical analysis, convergence criteria in optimization, shutdown and tolerance limits in engineering, walk-away points in negotiation, and exit criteria in project management. Its structural abstraction is complete because the pattern is nothing but a predicate over process state plus a commitment to stop when it holds — it carries zero domain-specific content. And the transfer is concretely documented: the same convergence-and-halting formalism moves intact between numerical optimization, iterative algorithms, and sequential statistics. Maximal breadth, a fully relational signature, and documented cross-domain transfer all converge on a canonical 5.

  • Composite substrate independence — 5 / 5
  • Domain breadth — 5 / 5
  • Structural abstraction — 5 / 5
  • Transfer evidence — 5 / 5

Relationships to Other Primes

One-hop neighborhood: parents above, mutual partners to the right, children below.Termination Conditioncomposition: IterationIterationdecompose: Well-Foundedness (Well-Ordering)Well-Foundedness(Well-Ordering)

Parents (1) — more general patterns this builds on

  • Termination Condition presupposes Iteration

    A halting predicate on an iterative/recursive process; it presupposes the iteration it halts (the two live at the same level but are designed separately).

Children (1) — more specific cases that build on this

  • Well-Foundedness (Well-Ordering) decompose Termination Condition

    The well-foundedness argument that guarantees the predicate is reached (the resource-branch backstop).

Path to root: Termination Condition → Iteration

Neighborhood in Abstraction Space

Termination Condition sits in a moderately populated region (44th percentile for distinctiveness): it has near-neighbors but no dense thicket of synonyms.

Family — Staged Processes & Drift (32 primes)

Nearest neighbors

Computed from structural-signature embeddings · 2026-06-14

Not to Be Confused With

The termination condition is most often confused with iteration, its nearest neighbor, because the two are inseparable parts of the same process. The distinction is a division of labor. Iteration is the unfolding — the repeated step that advances the process's state, the loop body, the recursive call, the negotiation round. The termination condition is the separate predicate that reads the state and decides continuation versus halting. They live at the same structural level and are designed together, but they answer different questions and demand different correctness arguments: iteration answers "what does each step do?" while termination answers "what makes it stop, and what does stopping certify?" The whole bite of the prime comes from insisting these are distinct — most production infinite loops, most philosophical regress problems, and most optimization runaways are failures of the termination design hiding behind a correct iteration design. A practitioner who treats the loop and its exit as one object will prove that each step makes progress and falsely conclude the process halts, missing that termination requires its own well-foundedness argument over and above correct step logic.

A subtler and more important confusion is with well_foundedness_well_ordering, because the two are so tightly coupled in any sound halting design that they can look like one notion. The difference is between a predicate and an argument. The termination condition is the checkable rule actually evaluated at each step — "stop when the residual is below tolerance," "stop at the base case," "stop when the budget is spent." Well-foundedness is the guarantee that the predicate will be reached: an argument that some measure decreases monotonically over a bounded or well-ordered set, so the process cannot run forever. The two are separable in both directions. A process can carry a termination predicate with no well-foundedness argument behind it — a "stop when the goal is found" rule for a goal that may not exist, which can loop forever — and well-foundedness can be established for a process whose halting predicate is left implicit. Keeping them apart is exactly the T1 (halting-versus-correctness) and T6 (compound-conditions) discipline: a complete design names the predicate and supplies the well-foundedness argument, typically by including a resource branch that is provably always reachable. Conflating them produces the dangerous illusion that writing an exit test guarantees the exit is reached.

A third genuine confusion is with optimal_stopping_rule, which shares the surface phrase "when to stop." Optimal stopping is a decision-theoretic object: given a sequence of opportunities under uncertainty, it chooses the stopping moment that maximizes expected payoff (the secretary problem, exercise of an American option, when to stop sampling). A termination condition is far weaker and more general: it merely defines a checkable halting predicate, with no claim that the stopping moment is optimal in any payoff sense. Most termination conditions carry no optimality at all — a loop's exit on array-end, a recursion's base case, a timeout — they simply bound the process. The relationship is that an optimal stopping rule, once derived, can serve as a termination condition (a no-progress or success predicate tuned to a payoff), but the prime is the broad category and optimal stopping is one specialized, optimized instance. The practical consequence: confusing them imports an expectation of optimality where none exists, leading an analyst to over-trust a crude timeout as if it were a payoff-maximizing decision, or to over-engineer a simple loop exit into a decision-theoretic computation it never needed.

These distinctions matter because each separates the predicate from something adjacent: iteration is the process the predicate halts, well-foundedness is the argument that the predicate is reachable, and optimal stopping is a payoff-maximizing special case of the predicate. A design that conflates termination with iteration proves progress and assumes halting; one that conflates it with well-foundedness writes an exit test and assumes it fires; one that conflates it with optimal stopping imports optimality claims it has not earned. Holding the termination condition as the specific, first-class halting predicate — with its family (success, failure, resource, no-progress, external), its evaluation point, its well-foundedness backstop, and its post-halt certification — keeps the analyst asking the four questions the prime exists to surface: which predicate, checked when, guaranteed to be reached, meaning what.

Solution Archetypes

No catalogued solution archetypes reference this prime yet.