Temporary Scaffold and Fade

batch: First Iteration/Batch 41

slug: scaffolding

components:
Task Barrier
Independent Capability Assessment
Scaffold Type
Support Requirement
Fading Schedule
Independence Check
Transfer Verification
Productive Struggle Signal
Responsibility Transfer Marker
Scaffold Removal Exception

mechanisms:
Prompt or Hint
Checklist or Job Aid
Template or Partial Solution
Worked Example Fading
Guided Walkthrough
Coaching Cue
Embedded Tooltip or Contextual Help
Faded Practice Drill

essence_one_line: Provide temporary supports that make near-independent performance possible, then deliberately fade those supports until capability transfers to unsupported action.

compression_statement: When a person or team cannot yet perform a target task alone, add a scaffold matched to the barrier, monitor capability, reduce support according to evidence, and verify independent transfer rather than letting support become permanent dependence.

core_intuition: Good scaffolding is not help forever. It is a bridge: strong enough to let the learner cross now, designed to disappear as the learner can carry the work internally or in normal operating conditions.

canonical_formula: barrier + temporary_support + fading_rule + independence_check + transfer_verification -> independent_capability

structural_problem: A learner, user, operator, or team needs support to perform a task, but no-support failure and permanent-support dependence are both undesirable.

trigger_conditions: The target task is valuable but currently beyond independent capability.

trigger_conditions: Failure without support would be costly, discouraging, unsafe, or too slow for learning.

trigger_conditions: The needed support can plausibly be reduced as capability develops.

trigger_conditions: The goal is independent performance or transferable capability, not merely completion of one supported task.

symptoms: People succeed during demonstrations but fail when asked to act independently.

symptoms: Checklists, prompts, templates, or coaching cues remain in place long after they were meant to teach.

symptoms: Support is removed suddenly, causing failure, anxiety, rework, or unsafe shortcuts.

symptoms: Learners memorize the aid rather than internalizing the underlying judgment or sequence.

symptoms: Managers or systems mistake scaffolded completion for real competence.

root_tension: The system must provide enough structure for successful practice now while preventing the structure from substituting for the capability it is meant to build.

anti_signatures: The support is a permanent accessibility accommodation, safety guardrail, legal requirement, or reliability control that should not fade.

anti_signatures: The task does not need independent performance; outsourced or automated completion is acceptable.

anti_signatures: The learner already performs independently and only needs reference documentation or optional convenience aids.

anti_signatures: The intervention mainly certifies achievement, diagnoses gaps, or aligns assessment evidence rather than building independence through support withdrawal.

structural_intervention: Match a temporary scaffold to a specific capability barrier, use it during guided performance, progressively remove or thin the scaffold, and test whether the capability survives without the support and across related contexts.

action_logic: Define the target capability and the task context in which unsupported performance matters.

action_logic: Assess what the performer can already do without support and identify the barrier preventing independent success.

action_logic: Choose the lightest scaffold that enables meaningful participation without doing the work for the performer.

action_logic: Make the fading rule explicit before the scaffold becomes normalized as part of the task.

action_logic: Observe performance signals, productive struggle, errors, and reliance on the scaffold.

action_logic: Reduce the scaffold gradually by removing cues, delaying help, withholding completed parts, increasing learner decisions, or shifting from push to pull support.

action_logic: Run an independence check under normal conditions and a transfer check in a nearby variation of the task.

action_logic: Revise the scaffold, restore a thinner support, or route to remediation when independence does not hold.

decision_rules: Add support only for a named barrier, not because support is easy to provide.

decision_rules: Use the minimum scaffold that permits productive action and preserves learner responsibility.

decision_rules: Fade when performance is stable enough that the scaffold is preventing rather than enabling growth.

decision_rules: Do not remove supports that function as safety controls, accessibility accommodations, or legitimate reference infrastructure.

decision_rules: Treat independent transfer, not supported completion, as the success criterion.

target_invariants: Support remains temporary unless there is an explicit reason it should be permanent.

target_invariants: The scaffold is tied to an observed barrier and a target capability.

target_invariants: Responsibility moves progressively from scaffold, coach, tool, or template to the performer.

target_invariants: Independence is verified without the scaffold, and transfer is checked beyond the original assisted task.

target_invariants: Fading is evidence-based rather than arbitrary, punitive, or purely time-based.

expected_outcomes: Higher success on tasks just beyond current capability without overwhelming the performer.

expected_outcomes: Reduced dependence on prompts, templates, walkthroughs, or coaching cues over time.

expected_outcomes: More durable skill transfer across related tasks and contexts.

expected_outcomes: Cleaner distinction between supported completion and genuine competence.

expected_outcomes: Improved confidence because challenge is paired with visible progress toward independence.

prose_essence:
Temporary Scaffold and Fade is the pattern of helping someone do a meaningful task before they can do it alone, while designing the help to disappear. The support is not the destination. It is a bridge from assisted participation to independent performance.

The archetype has three inseparable moves: provide support matched to a real barrier, deliberately reduce that support as capability grows, and verify that the person or team can perform without the scaffold in a related context. Without the fading and verification moves, the pattern collapses into ordinary help, documentation, automation, or accommodation.

prose_when_to_use:
Use this archetype when the target outcome is capability growth. It is especially useful when the task is worth attempting now, but unsupported performance would produce failure, unsafe practice, discouragement, or avoidable rework.

The best cases have an observable baseline, a named barrier, a support form that can be reduced, and a meaningful way to test independence. Examples include onboarding a new employee into real work, helping a user learn a complex software workflow, coaching a performer through progressively harder practice, or teaching a technical procedure in simulation before independent authorization.

Do not use this pattern to justify removing supports that should remain. Some aids are safety controls, accessibility accommodations, legal requirements, or high-reliability checklists. Those may be excellent design, but they are not temporary learning scaffolds.

prose_structural_problem:
The structural problem is a three-way tension between failure, help, and dependence. If no support is provided, the learner may fail before useful learning can occur. If support is too strong, the scaffold does the real work. If support stays too long, the system confuses scaffolded completion with actual competence.

This problem often appears as successful performance during training or guided walkthroughs followed by poor performance once prompts, templates, or coaching disappear. It also appears when organizations keep adding job aids and review layers but never ask whether responsibility has moved to the learner.

prose_intervention_logic:
The intervention begins by naming the target capability and identifying what the performer can do independently. Then it identifies the barrier that prevents success: missing knowledge, unclear sequence, excessive cognitive load, lack of confidence, unfamiliar cues, or inability to judge quality.

A scaffold is selected to match that barrier. A checklist may help with sequence, a template may help with structure, a worked example may reveal reasoning, a coach cue may direct attention, and contextual help may support point-of-use action. The support should be light enough that the performer still does meaningful work.

The crucial move is planned fading. The system removes completed parts, delays hints, reduces review frequency, shifts from push help to pull help, hides routine cues, or asks the learner to make more decisions. Finally, the learner performs without the scaffold and then handles a nearby variation so transfer is tested rather than assumed.

prose_key_components:
### Task Barrier

A task barrier explains why independent performance is not yet possible. It keeps the design from offering generic help. A barrier might be procedural, conceptual, attentional, emotional, contextual, or related to cognitive load.

### Independent Capability Assessment

The baseline assessment asks what the learner can already do without help. This prevents over-supporting someone who is ready for more responsibility and under-supporting someone who needs a stronger bridge.

### Scaffold Type

The scaffold type is the support form: prompt, checklist, template, worked example, guided walkthrough, coach cue, contextual help, or partial solution. The type should match the barrier, not merely reuse a favorite teaching method.

### Support Requirement

Support requirement tunes how much help is necessary. The goal is enough support for productive action, but not so much that the support performs the task.

### Fading Schedule

The fading schedule states how support will be reduced. This is the defining component. A scaffold without a fading rule is often just permanent help.

### Independence Check

The independence check tests unsupported performance. It asks whether the learner can act under normal conditions without the cue, template, walkthrough, or coach intervention.

### Transfer Verification

Transfer verification tests whether the capability works in a related but non-identical context. This protects against learners becoming good at the scaffolded exercise while failing in real use.

### Productive Struggle Signal

Productive struggle is an optional but useful signal. It shows whether the task is still developmentally useful: difficult enough to require effort, but not so difficult that practice becomes confusion or helplessness.

prose_common_mechanisms:
### Prompt or Hint

A prompt or hint cues the next step, relevant feature, or strategy. It implements the archetype only when the cue becomes less explicit, less frequent, or unavailable during independence checks.

### Checklist or Job Aid

A checklist externalizes sequence or criteria. It is a scaffold when it teaches reliable performance and then becomes shorter, optional, exception-only, or absent. A permanent safety checklist is not this archetype.

### Template or Partial Solution

A template lowers structural burden. It supports early production, then becomes less complete until the learner can generate the structure independently.

### Worked Example Fading

Worked example fading is a mechanism-family variant. The learner moves from complete examples to partially completed examples to independent solving. It is not the parent archetype by itself because it is one way to deliver scaffold fading.

### Guided Walkthrough

A guided walkthrough supports an early pass through an unfamiliar task. To instantiate this archetype, the walkthrough must hand off more decisions to the performer and eventually give way to unsupported execution.

### Coaching Cue

A coach cue can direct attention, invite reflection, or correct strategy. The cue should become less directive and less immediate so the learner develops self-correction.

### Embedded Tooltip or Contextual Help

Embedded help appears at the point of need. It becomes a just-in-time scaffold only when the system reduces visibility, detail, or frequency after competence signals appear.

### Faded Practice Drill

A faded practice drill repeats practice while removing layers of support. It is useful when capability needs several cycles of supported performance, thinner support, variation, and unsupported trials.

prose_failure_modes:
Permanent scaffold lock-in occurs when no one owns removal. The mitigation is to assign a fading owner and independence criterion before the scaffold becomes normal infrastructure.

Premature scaffold removal occurs when support is withdrawn because time has passed rather than because capability has grown. The mitigation is evidence-based fading and reversible retuning.

Mismatched scaffolding occurs when the aid solves the wrong problem, such as giving a checklist when the true barrier is conceptual misunderstanding. The mitigation is barrier diagnosis.

Hidden dependency occurs when supported completion is mistaken for competence. The mitigation is unsupported performance checks and transfer tests.

Equity-blind fading occurs when designers remove accommodations or safety supports under the banner of independence. The mitigation is to distinguish learning scaffolds from permanent supports that should remain.

prose_neighbor_distinctions:
Temporary Scaffold and Fade is close to Transfer Scaffolding, but the center of gravity differs. Transfer Scaffolding focuses on movement across contexts; this archetype focuses on removing support as independent capability grows.

It is close to Worked Example Fading, but worked examples are a mechanism-family variant. The parent pattern includes many other support forms.

It is close to Cognitive Workflow Sequencing, but sequencing organizes steps while scaffold fading transfers responsibility for those steps.

It is close to Progressive Disclosure, but disclosure controls information reveal. Scaffold fading controls support withdrawal based on capability.

It is close to Cognitive Load Reduction, but load reduction can be permanent simplification. Here, load reduction is temporary and capability-building.

It is close to Formative Feedback Loop and Mastery-Gate Progression because both may provide evidence for fading. Yet feedback loops diagnose and adjust, while mastery gates control progression. Scaffold fading is about support withdrawal and independence.

prose_cross_domain_examples:
In onboarding, a new support agent may begin with scripts, templates, and live review. Those supports become shorter and less frequent until the agent handles novel cases independently.

In software adoption, an analytics platform may guide a first report with a walkthrough, later hide routine hints, and eventually ask the user to create a different report without guided steps.

In professional writing, a novice analyst may start with a full memo template, then use a lighter outline, and finally produce a memo from scratch with review only after completion.

In safety training, a trainee may rehearse a procedure with prompts in simulation, then with fewer cues, and finally under supervised realistic conditions before independent authorization.

prose_non_examples:
A permanent aircraft checklist is not this archetype because it is a reliability control intended to remain.

A final exam is not this archetype because it evaluates endpoint achievement rather than providing temporary support.

A lesson plan is not this archetype because it organizes instruction; it may contain scaffolds, but it is not itself the scaffold-fade-transfer pattern.

A fully automated tool that completes the task indefinitely is not this archetype because it removes the need for human capability rather than building it.

prose_tradeoffs:
The central tradeoff is support versus dependence. Support enables action, but persistent support can prevent capability from forming. Another tradeoff is safety versus authenticity: scaffolds reduce risk, but overly artificial practice may not transfer. A third tradeoff is efficiency versus learning. Templates and walkthroughs speed early output, but fast supported output can hide weak independent performance.

The practical answer is not to minimize support. It is to make support conditional, visible, and temporary, while preserving permanent supports that serve safety, access, or reliability.

prose_invariants_to_preserve: The support must be tied to a target capability and a named barrier. It must leave meaningful responsibility with the learner. It must be temporary unless there is a clear reason to keep it. Fading should be based on evidence rather than arbitrary time or managerial impatience. Finally, success should be measured through unsupported performance and transfer, not merely through completion while the scaffold is present.

prose_target_outcomes:
The desired outcome is independent capability. More specifically, the pattern should produce successful unsupported performance, lower reliance on prompts or templates, better transfer to related situations, and cleaner evidence about what the learner can actually do.

A secondary outcome is confidence. When challenge is paired with well-designed support and visible fading, learners can experience progress without being trapped in either helplessness or permanent dependence.

prose_parameter_dimensions:
The first tuning dimension is scaffold strength. Strong scaffolds give explicit steps, examples, or review; weak scaffolds give small cues or optional reference. Strong support is appropriate early or in high-risk practice, but it should not persist without evidence.

The second dimension is fading rate. Fading can be quick when the task is simple and performance stabilizes rapidly. It should be slower when the task is complex, safety-critical, emotionally loaded, or highly variable.

The third dimension is support timing. Support may appear before the task, during the task, after an attempt, or at the moment of need. Point-of-use support is powerful, but it can become invisible dependency unless it is deliberately reduced.

The fourth dimension is transfer distance. A near transfer check uses a small variation of the original task. A far transfer check tests capability in a significantly different context. The farther the intended transfer, the more carefully the scaffold must fade into varied practice.

The fifth dimension is reversibility. A good fading plan allows support to be restored temporarily when independence fails, but restoration should usually be thinner and more targeted than the original scaffold.

prose_variants_and_near_names:
Proximal Challenge Calibration is captured as a merge-review variant. It emphasizes choosing a task just beyond current independent capability, then providing enough support to make the challenge developmental. It remains under this parent for now because the support, fading, and independence logic are the same.

Just-in-Time Scaffold is a candidate temporal variant. It provides point-of-need support, such as embedded help or a job aid, and fades it once competence appears. It should remain only a variant unless timing becomes more structurally distinct than support withdrawal.

Scaffold and Fade, Fading Support, Guided Support Withdrawal, and Scaffolding are aliases or near names when they refer to temporary support plus planned fading. Prompt, checklist, worksheet, coaching session, and worked example are mechanisms or artifacts, not full archetypes by themselves.

Proximal Challenge Calibration

variant_type: subtype

short_definition: Selects a target task just beyond current independent capability and supplies temporary support so challenge becomes developmental rather than overwhelming.

distinctive_feature: The emphasis is challenge calibration before scaffold selection: the intervention first locates the learner-task gap, then chooses support.

distinct_from_parent: The parent can begin from any barrier that requires temporary support and planned fading; this variant begins from difficulty matching around the proximal zone.

still_same_parent_because: It still works by adding removable support, watching performance, fading assistance, and verifying independent capability.

use_when: The main design question is whether the task is too easy, too hard, or appropriately just beyond independent capability.

use_when: The performer needs supported stretch practice rather than either unsupervised struggle or fully solved demonstrations.

use_when: A coach, teacher, manager, interface, or tool can adjust challenge and support as capability changes.

Independent Capability Assessment

role: Defines the unsupported baseline.

Productive Struggle Signal

role: Shows whether challenge remains developmental.

Fading Schedule

role: Transfers responsibility as competence grows.

Graduated Assignment

mechanism_type: procedure

Stretch Goal with Support

mechanism_type: method

domain: training

example: A novice analyst receives harder cases only after earlier cases can be solved with thinner prompts.

domain: onboarding

example: A new employee is assigned real tasks with gradually reduced review checkpoints.

domain: coaching

example: An athlete practices a technique variant that is just beyond current form, with cues reduced as form stabilizes.

concise_examples: A help system increases task complexity only after the user completes the simpler workflow with fewer hints.

concise_examples: A writing coach removes outline prompts once the learner can structure the argument independently.

failure_mode: Challenge inflation

cause: The target moves faster than capability grows.

mitigation: Use productive-struggle signals and independence checks before increasing difficulty.

failure_mode: Support lock-in

cause: The performer succeeds only because support remains high.

mitigation: Pair each challenge increase with an explicit fading rule.

Just-in-Time Scaffold

short_definition: Provides temporary help at the point of need and fades it once the performer can act without the contextual cue.

distinctive_feature: The timing of support is the main distinction: help appears at the moment of use rather than during a separate preparation phase.

distinct_from_parent: The parent does not require point-of-need timing; it can use pre-task, in-task, or post-task support as long as fading and transfer are preserved.

still_same_parent_because: It remains a scaffold only when the contextual aid is temporary and responsibility moves to the performer rather than staying permanently embedded.

use_when: Front-loaded instruction is forgotten or disconnected from the task.

use_when: The performer needs concise support exactly when the task creates relevance.

use_when: The support can later be hidden, delayed, shortened, or made optional.

Task Trigger

role: Detects the point of need.

Scaffold Type

role: Defines the contextual support.

Fading Schedule

role: Reduces the aid over time.

Embedded Tooltip or Contextual Help

mechanism_type: interface

Job Aid

mechanism_type: artifact

domain: software adoption

example: A product shows contextual hints for a workflow and suppresses them after repeated successful use.

domain: field operations

example: A mobile checklist appears during an unfamiliar inspection and is later replaced by exception-only reminders.

concise_examples: A novice support agent receives live response prompts during early cases, then only gets escalation cues.

concise_examples: A machine interface displays setup steps until the operator has completed enough independent runs.

failure_mode: Permanent tooltip dependence

cause: Contextual help never fades.

mitigation: Hide, shorten, or make help pull-based after competence signals appear.

near_names:
Scaffold and Fade
Fading Support
Guided Support Withdrawal
Scaffolding
Just-in-Time Instruction


Tension–Resolution Cycle Design

type: archetype

source: generated

batch: Batch 03

canonical_family: Constraint Release & Resolution

aliases:
Tension–Release Design
Tension–Release Cycle Design
Anticipation–Resolution Cycle
Build–Hold–Resolve Design
Earned Resolution Sequencing
Bounded Suspense and Release

slug: contrast

slug: sequencing

slug: stability

slug: threshold

slug: periodicity

slug: rhythm

slug: cadence

slug: dissonance

slug: emphasis

slug: feedback

slug: homeostasis

slug: attention

slug: closure

slug: liminality

slug: resonance

components:
Baseline Expectation Model
Intended Resolution Value
Tension Generator
Tension Build Curve
Bounded Deviation Envelope
Anticipation Accrual Signal
Sustain Window
Release Readiness Gate
Release Timing Rule
Resolution Move
Payoff Linkage Test
Closure Quality Criterion
Frustration and Harm Limit
Post-Resolution Stabilization
Reset and Recovery Path
Audience or Agent Segmentation
Accessibility and Modality Adaptation
Rehearsal or Sandbox
Cycle Portfolio and Spacing Plan

mechanisms:
Harmonic Suspension and Resolution
Unresolved-Question Hold
Progressive Reveal Sequence
Productive-Struggle Pause and Reveal
Cadence Break and Restoration
Staged Commitment Release
Countdown and Completion Cue
Tension-Curve Storyboard
Tension-Curve Rehearsal
Adaptive Release-Timing Protocol
Real-Time Dropout or Distress Monitor
Post-Resolution Debrief

essence_one_line: Deliberately build, bound, sustain, and resolve a temporary instability so the resolution’s value is earned by the preceding tension without turning anticipation into harm.

compression_statement: When value depends on contrast between a stable expectation and a later resolution, define the baseline and intended payoff, introduce a bounded deviation, monitor whether anticipation or productive readiness is actually accruing, hold only within a safe sustain window, release through a move prepared by the buildup, test closure and payoff linkage, and reset the system before another cycle.

core_intuition: Resolution is not valuable merely because it arrives later. It gains force when the prior unresolved state made a meaningful prediction, need, contrast, or readiness salient. The design task is therefore a coupled cycle: build enough tension to make the resolution matter, but preserve timing, trust, reversibility, and safety so the cycle does not become arbitrary delay or unmanaged stress.

canonical_formula: resolution_value ≈ meaningful_deviation × anticipation_accrual × payoff_linkage × closure_quality, bounded by consent, harm, duration, and recoverability

structural_problem: A system needs a later state, explanation, commitment, or completion to carry more value than immediate delivery would produce, but the value can arise only if a preceding unresolved state is deliberately constructed and resolved at the right moment. Without governance, the buildup is too weak, too short, too long, arbitrary, manipulative, or harmful.

trigger_conditions: The desired resolution depends on contrast with a stable baseline, expectation, incomplete state, or competing tendency.

trigger_conditions: Participants or system state can tolerate a bounded unresolved interval and can exit or recover if it fails.

trigger_conditions: Observable evidence can distinguish useful anticipation or readiness from confusion, distress, or disengagement.

trigger_conditions: The eventual resolution can be prepared by the buildup rather than appended as an unrelated surprise.

trigger_conditions: Timing materially changes the value of the outcome.

trigger_conditions: A post-resolution state can be stabilized and the cycle can be reset.

symptoms: Resolutions feel flat because they arrive before a meaningful expectation or contrast forms.

symptoms: Suspense or difficulty persists after engagement has become frustration, anxiety, or abandonment.

symptoms: A reveal or completion feels arbitrary because the preceding sequence did not prepare it.

symptoms: Different participant groups reach readiness at different times, but one fixed release schedule is used.

symptoms: The release is dramatic but leaves interpretation, learning, or operational state unresolved.

symptoms: Repeated cycles create chronic activation because no recovery or baseline restoration occurs.

root_tension: The intervention must preserve enough unresolved deviation to generate anticipation and contrast while preserving consent, comprehension, safety, trust, and a reachable path to closure.

anti_signatures: Accumulated pressure is inherited, dangerous, and should be relieved as soon as safely possible rather than deliberately built.

anti_signatures: The outcome is valuable independently of any preceding unresolved state.

anti_signatures: The system cannot provide a credible resolution or safe abort path.

anti_signatures: Ambiguity concerns safety-critical instructions, legal rights, medical consent, or other facts that should not be strategically withheld.

anti_signatures: Participants cannot perceive the buildup or the release in their available modality.

anti_signatures: The design relies on deception, coercion, humiliation, or unbounded anxiety rather than bounded expectation and prepared closure.

structural_intervention: Design one coupled temporal cycle that establishes a baseline, introduces a bounded unresolved deviation, measures useful buildup and harm, releases at a readiness gate through a structurally prepared resolution, validates payoff and closure, and restores a stable recoverable state.

action_logic: Name the audience or acting system, the baseline expectation, and the value the eventual resolution should create.

action_logic: Specify exactly how the unresolved state will differ from baseline and why that deviation should generate useful anticipation, attention, or readiness.

action_logic: Bound magnitude, duration, reversibility, affected population, information withholding, and permissible stress.

action_logic: Instrument evidence of anticipation, prediction, engagement, productive struggle, confusion, distress, and dropout.

action_logic: Define early-release, continue, soften, and abort rules before live exposure.

action_logic: Sustain only while value indicators rise or remain useful and harm indicators stay below limits.

action_logic: Execute a resolution move that follows from and answers the prepared structure.

action_logic: Test whether participants can connect the resolution to the buildup and whether closure is sufficient for the intended purpose.

action_logic: Stabilize, explain, consolidate, or recover the post-resolution state.

action_logic: Record timing and outcome evidence so later cycles can be recalibrated rather than repeated by intuition alone.

decision_rules: Use this archetype only when the payoff would be materially weaker without the prior build.

decision_rules: Release early when harm, confusion, abandonment, or loss of trust crosses its limit even if the planned payoff has not matured.

decision_rules: Extend the sustain window only when anticipation or readiness remains observable and the resolution remains credible.

decision_rules: Abort rather than improvise a false payoff when the prepared resolution is no longer available.

decision_rules: Segment timing or provide parallel paths when readiness and vulnerability differ materially across participants.

decision_rules: Do not manufacture high-stakes uncertainty that participants reasonably believe has already been resolved or disclosed.

decision_rules: Allow incomplete closure only when the retained residue is deliberate, bounded, and legible as continuation rather than failure.

target_invariants: The unresolved state remains bounded, reversible, and attributable to an explicit design purpose.

target_invariants: Participants retain an accessible exit, clarification, or recovery path where exposure is not fully voluntary.

target_invariants: The resolution is causally or semantically prepared by the buildup.

target_invariants: No safety-critical fact, consent condition, or material right is obscured merely to intensify tension.

target_invariants: The sustain window ends before distress or system instability becomes self-amplifying.

target_invariants: The post-resolution state is usable, interpretable, and stable enough for the next action.

target_invariants: Repeated cycles include sufficient recovery to preserve contrast and prevent chronic activation.

expected_outcomes: Greater salience, insight, emotional force, or learning at resolution.

expected_outcomes: Fewer arbitrary reveals, flat completions, and mistimed releases.

expected_outcomes: Better timing adaptation across audiences and contexts.

expected_outcomes: Reduced frustration, abandonment, and harmful overextension.

expected_outcomes: Clearer linkage between sequence design and outcome value.

expected_outcomes: Improved closure, consolidation, and readiness for subsequent cycles.

prose_tradeoffs: More intensity and duration can deepen anticipation, but narrow the safety margin. Adaptive timing improves fit, but reduces synchronization and reproducibility. Strong closure improves comprehension, but may reduce ambiguity that an artistic form intentionally preserves. Segmentation protects heterogeneous participants, but can fragment a shared experience. Frequent cycles maintain engagement, but can exhaust attention and normalize manipulation.

Harmonic Suspension–Resolution Variant

short_definition: Prepare, hold, and resolve tonal or rhythmic instability so the resolution gains force from the preceding suspension.

distinctive_feature: The tension and resolution are encoded in musical expectation and temporal relation.

distinct_from_parent: This variant specializes the general cycle to tonal, harmonic, melodic, or rhythmic grammar.

still_same_parent_because: It still requires a baseline, bounded deviation, sustain window, release gate, prepared resolution, and closure assessment.

source_primes: tension_and_release dissonance rhythm

use_when: A stable tonal or rhythmic expectation is legible.

use_when: The instability can be bounded and resolved perceptibly.

use_when: The expressive value depends on timing rather than novelty alone.

example: A suspension is held across a chord change and resolves after the phrase has made its instability salient.

failure_modes: resolution before tension is perceptible

Narrative Suspense–Payoff Variant

short_definition: Create and sustain a consequential uncertainty, then resolve it through information or action prepared by the preceding sequence.

distinctive_feature: Closure is evaluated for causal and thematic preparation, not surprise alone.

distinct_from_parent: This variant emphasizes information, prediction, stakes, and narrative closure.

still_same_parent_because: The core intervention remains deliberate deviation from expectation, bounded sustain, timed resolution, and payoff-linkage validation.

source_primes: tension_and_release sequencing closure

use_when: The withheld answer remains relevant across the sequence.

use_when: The payoff can be traced to planted evidence or established stakes.

example_domains: storytelling journalism presentation_design investigation

example: A diagnostic anomaly is introduced, evidence is ordered to sustain competing explanations, and the causal finding resolves the question.

failure_modes: closure that contradicts planted evidence

Productive-Struggle Revelation Variant

short_definition: Let a learner experience a bounded unresolved problem long enough to activate prior knowledge and notice structure before revealing support or explanation.

distinctive_feature: The buildup is cognitive disequilibrium whose resolution consolidates a transferable model.

distinct_from_parent: This variant requires readiness and cognitive-load safeguards specific to learning.

still_same_parent_because: It uses the same bounded build, monitored sustain, readiness gate, resolution, and integration cycle.

use_when: The learner has enough prerequisite knowledge to make progress.

use_when: Struggle produces diagnostic information or schema activation.

use_when: Support can be released before overload or disengagement.

example_domains: education training coaching debugging_instruction

domain: education

example: Students compare failed solution attempts before a facilitator reveals the invariant that organizes the problem.

failure_modes:
prerequisite mismatch
unproductive confusion
hint released too soon
support released after disengagement

Staged Interaction Completion Variant

short_definition: Use a bounded visible sequence of incomplete states so final confirmation or completion gains clarity and salience from the preceding progression.

distinctive_feature: Anticipation is created through interaction state and completion feedback rather than narrative or aesthetics.

distinct_from_parent: This variant emphasizes progress visibility, waiting tolerance, confirmation, and recoverable interaction state.

still_same_parent_because: It retains a baseline, controlled incomplete interval, release cue, completion move, closure test, and recovery path.

source_primes: tension_and_release cadence feedback

use_when: The wait or staged action is real and can be made legible.

use_when: Users benefit from knowing progress and the completion boundary.

use_when: The sequence can be aborted or recovered safely.

example: A multi-stage import shows bounded progress and resolves with a definitive validation summary rather than an unexplained spinner stop.

failure_modes: no recovery after interrupted resolution

near_names:
Tension–Release Cycle Design
Tension–Release Design
Anticipation–Resolution Cycle
Build–Hold–Resolve Design
Earned Resolution Sequencing


Termination Condition Design

batch: First Iteration/Batch 07

source_primes: well_foundedness recursion iteration completeness

related_primes: infinite_regress boundedness threshold convergence order

slug: recursion

slug: iteration

slug: completeness

slug: boundedness

slug: convergence

slug: order

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

compression_statement: When a process can continue without resolution, define base cases, completion criteria, stopping thresholds, exhaustion rules, escalation limits, or finality conditions so the system can end responsibly rather than drifting into infinite regress, endless review, runaway search, or perpetual deferral.

core_intuition: Open-ended processes often feel safer because they postpone hard closure. But without a designed stopping condition, continuation can consume resources, defer accountability, create ambiguity, and make completion impossible. Termination Condition Design makes “enough,” “done,” “exhausted,” “converged,” or “final” explicit enough to govern.

canonical_formula: identify nonterminating process → define well-founded progress measure or bounded search/review space → declare stop/base/completion/exhaustion/convergence condition → assign termination disposition → preserve narrow reentry when new evidence or risk justifies reopening

structural_problem: 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.

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

why_it_matters: Recursive and iterative structure creates the possibility of nontermination unless there is a base case or progress measure.

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

why_it_matters: Ambiguous completion criteria let each actor continue or reopen the process according to their own standard.

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

why_it_matters: This is where a stop threshold, timebox, or sufficiency standard can prevent waste without denying residual uncertainty.

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

why_it_matters: A system can avoid decision by continually transferring the unresolved case to another layer.

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

why_it_matters: The stop condition must be explicit and reviewable rather than a hidden convenience decision.

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

why_it_matters: Termination by exhaustion only works when the space to be exhausted is declared.

symptom: Endless review cycles, repeated revisions, or recurring “one more check” requests.

diagnostic_hint: Ask what evidence would allow the review to stop and whether that standard is written down.

symptom: Recursive logic that keeps requiring a prior case, deeper justification, or further prerequisite.

diagnostic_hint: Look for the missing base case or initial condition.

symptom: Search, debugging, investigation, or research efforts expand without a boundary.

diagnostic_hint: Ask what search space is being exhausted and what would count as no relevant options remaining.

symptom: Disputes, appeals, support tickets, or exceptions bounce between levels without final disposition.

diagnostic_hint: Check whether there is a highest escalation level, final authority, or reopening rule.

symptom: Teams ship prematurely because “done” is implicit and negotiated informally.

diagnostic_hint: Compare actual exit decisions against explicit completion criteria or acceptance evidence.

symptom: A process stops only when people are tired, deadlines arrive, or budgets are exhausted.

diagnostic_hint: Distinguish externally forced stoppage from designed termination with accountable disposition.

root_tension: The system needs enough continuation to avoid premature closure, but enough closure to avoid infinite regress, endless refinement, resource exhaustion, and deferred accountability. Termination Condition Design balances sufficiency against incompleteness.

case: The process already has a clear stop rule, but actors ignore it or lack incentives to follow it.

why_not_this: The closer intervention may be enforcement, accountability, incentive alignment, or governance authority rather than designing termination conditions.

case: The main issue is choosing the order of prerequisite steps before progress can begin.

why_not_this: Dependency Ordering is closer when sequencing prerequisites is central.

case: The process needs a review or approval gate, not a stopping rule for indefinite continuation.

why_not_this: Stage-Gate Progression is closer when the issue is controlled advancement through gates.

case: The problem is that outputs escape a valid domain during operation.

why_not_this: Closure-Preserving Operation or Invariant Guarding is closer when validity preservation is central.

case: The system needs to reintroduce something after removal or pause.

why_not_this: Controlled Reentry is closer when the intervention governs return after exit rather than the stop condition itself.

case: The best response is open-ended exploration by design, with no meaningful need for closure yet.

why_not_this: Prematurely imposing termination can suppress discovery when uncertainty is high and stakes do not require a disposition.

structural_intervention: Redesign the process so continuation is governed by explicit base cases, progress measures, completion criteria, thresholds, exhaustion boundaries, budgets, finality rules, and post-stop dispositions, with narrowly defined reentry when new information or risk justifies reopening.

action: Name the process, loop, search, escalation, review, or recursion that needs a stopping design.

rationale: Termination must attach to a specific process rather than a general wish to end things.

action: Map how the process can continue indefinitely: retry, recursive call, appeal, escalation, review round, added evidence, or expanded search.

rationale: The stop condition should target the actual route by which continuation becomes unbounded.

action: Choose a well-founded progress measure, bounded search space, finite escalation ladder, iteration budget, or convergence standard.

rationale: This converts endless continuation into movement toward an end state.

action: Write the stop, base, completion, exhaustion, convergence, or finality condition in observable terms.

rationale: Actors need to know when the condition has been met without renegotiating closure each time.

action: Define what happens after termination: accept, reject, ship, archive, escalate, return, mark inconclusive, defer, or open a separate process.

rationale: Stopping must produce a governed state, not abandonment.

action: Specify narrow reopening or reentry criteria for new evidence, safety risk, rights violations, drift, or material changed conditions.

rationale: Closure should be firm enough to work but not so brittle that it hides new risk.

action: Track premature stops, endless continuations, reopened cases, and termination disputes to tune the stop condition.

rationale: Stop conditions need adjustment when they routinely over-close or under-close.

rule: Use a base case when the process is recursive or repeatedly refers to prior/deeper cases.

reason: A base case supplies a bottom that does not require another round of the same process.

rule: Use completion criteria when a task or review needs a standard of enoughness.

reason: Completion criteria prevent both vague perfectionism and under-specified exit.

rule: Use exhaustion boundaries when termination depends on checking all relevant options, cases, or evidence sources.

reason: Exhaustion is only meaningful relative to a declared bounded universe.

rule: Use thresholds or convergence standards when the process approaches a stable result by iteration.

reason: The system can stop when additional refinement falls below the value or accuracy requirement.

rule: Use time, budget, or iteration limits when continuation costs can exceed the value of more process.

reason: A resource bound prevents endless work, but must be paired with a disposition for unresolved remainder.

rule: Use finality and escalation limits when procedural reopening blocks action or accountability.

reason: Governance systems need a final level or rule that distinguishes closure from abandonment.

rule: Do not use a stop condition as a way to silence important evidence, affected parties, or safety signals.

reason: Termination can create harm when it forecloses legitimate review.

invariant: Termination conditions remain explicit and reviewable.

why_it_matters: Hidden stop rules become arbitrary power or accidental neglect.

invariant: Continuation makes measurable progress or has a bounded reason to continue.

why_it_matters: This preserves well-foundedness and prevents endless loops.

invariant: Stopping produces an accountable disposition.

why_it_matters: Closure without disposition merely moves ambiguity elsewhere.

invariant: Residual uncertainty is recorded when stopping before certainty.

why_it_matters: Responsible termination distinguishes sufficient closure from complete knowledge.

invariant: Reentry is possible only under defined material conditions.

why_it_matters: This protects both adaptability and the value of closure.

outcome: Fewer endless loops, review cycles, recursive failures, and indefinite escalations.

evidence: Processes reach disposition under the designed stop condition instead of continuing by default.

outcome: Clearer accountability for when and why a process ended.

evidence: Stop decisions can be traced to explicit conditions and authorities.

outcome: Reduced resource waste from low-value continuation.

evidence: Time, attention, computational cycles, review rounds, or escalation levels are bounded.

outcome: Lower risk of premature closure.

evidence: Completion criteria and reentry conditions make stopping standards visible enough to challenge.

outcome: More stable recursive, iterative, and governance processes.

evidence: Base cases, progress measures, finality rules, and exhaustion boundaries prevent regress and drift.

prose_essence:
Termination Condition Design is the pattern of making endings explicit. It applies when a process can keep looping, searching, reviewing, escalating, refining, or justifying itself without a natural endpoint. The archetype asks: what would count as enough, done, exhausted, converged, final, or safely handed off?

The core move is not merely to stop. It is to define a responsible condition for stopping, pair that condition with an accountable disposition, and preserve a narrow path for reopening when new evidence or risk makes closure unsafe.

prose_when_to_use:
Use this archetype when a process has recursive, iterative, review, search, escalation, appeal, or refinement structure and participants cannot reliably tell when continuation should end. It is especially useful when continuation consumes scarce resources, delays accountability, creates endless review cycles, or allows hard decisions to be deferred indefinitely.

It also applies when premature stopping is a known risk. A good termination condition protects against both extremes: endless continuation and arbitrary closure.

prose_structural_problem:
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.

prose_intervention_logic:
The intervention begins by naming the process that can fail to terminate. Then it maps how continuation happens: recursion, retry, review, appeal, escalation, expansion, or refinement. The designer then selects the right termination basis: base case, completion criteria, convergence threshold, exhaustion boundary, time or iteration budget, escalation limit, or finality rule.

A strong design also defines what happens after termination. Stopping may mean accept, reject, ship, archive, hand off, escalate, declare inconclusive, defer, or open a separate process. Finally, the design specifies when reentry is legitimate so that closure does not become brittle denial.

prose_key_components:
- **Termination Frame** (`termination_frame`): Defines what kind of process is being stopped, completed, exhausted, converged, escalated, or declared final. The same stop signal means different things in a search, review, recursion, escalation, negotiation, experiment, or workflow. The frame prevents a generic ending from being misapplied.
- **Stop Rule** (`stop_rule`): Specifies the condition under which the process must stop, pause, return, escalate, or hand off. In the reconciliation controls, stop_rule is a component candidate. In this archetype it is central but still not the whole archetype: it must be attached to a frame, evidence standard, and disposition path.
- **Base Case** (`base_case`): Provides a non-recursive or minimal case where recursive, escalatory, or progressive logic can stop safely. A base case prevents infinite regress by grounding recursive action in a case that does not require more of the same process. Base-Case Anchoring is preserved as a variant and possible second-wave candidate.
- **Completion Criteria** (`completion_criteria`): Defines the evidence or state that counts as done, sufficiently resolved, acceptable, or ready to exit. Completion criteria are not perfection criteria. They define enoughness for the present purpose, stakes, and risk tolerance.
- **Progress Measure** (`progress_measure`): Tracks whether each iteration, search step, review round, or recursive call is moving toward termination. For well-founded designs, progress may decrease a measure, exhaust a finite set, narrow uncertainty, consume a budget, or approach a convergence threshold.
- **Exhaustion Boundary** (`exhaustion_boundary`): Defines the finite space of options, evidence, cases, search nodes, review rounds, or escalation levels that can be exhausted. An exhaustion boundary is especially important when termination depends on showing that there is nothing relevant left to inspect or try.
- **Termination Disposition** (`termination_disposition`): Specifies what happens after stopping: accept, reject, ship, archive, escalate, return, retry later, declare inconclusive, or open a new process. Stopping without a disposition often creates hidden continuation elsewhere. The disposition makes closure operational.
- **Exception and Reentry Path** (`exception_and_reentry_path`): Allows the process to reopen, escalate, or resume when new evidence, safety risk, appeal, drift, or changed conditions invalidate the stop condition. This component distinguishes responsible closure from brittle finality. It should be narrow enough not to erase the value of termination.
- **Iteration Budget** (`iteration_budget`): Limits the number of cycles, review rounds, retries, experiments, or search expansions before a stop or escalation rule applies. A budget may be temporal, financial, computational, attentional, social, or political.
- **Convergence Standard** (`convergence_standard`): Defines how stable, close, or consistent a result must be before iterative refinement can end. The standard should be explicit about tolerance, uncertainty, and what is sacrificed by stopping before exactness.
- **Escalation Limit** (`escalation_limit`): Sets a boundary on how far a process may climb through review, dispute, approval, or exception channels before a final disposition is required. Escalation limits prevent a system from converting hard decisions into indefinite routing.
- **Stopping Authority** (`stopping_authority`): Names who or what is allowed to declare the termination condition satisfied and accountable for the disposition. The authority may be a role, rule engine, committee, reviewer, protocol, court, incident commander, or automated guard.
- **Residual Uncertainty Record** (`residual_uncertainty_record`): Documents what remains unknown, unresolved, or imperfect at termination so closure is not mistaken for certainty. This record is most important where termination happens because of sufficiency, diminishing returns, or bounded resources rather than complete proof.

prose_common_mechanisms:
- **Recursion Base Case** (`recursion_base_case`): This is a rule_pattern implementation of the archetype. Defines a smallest or simplest case that returns directly rather than making another recursive call. Implements the archetype in algorithms, proofs, curricula, recursive workflows, and escalation trees. It is a mechanism because it is one concrete way to supply a stop rule.
- **Definition of Done** (`definition_of_done`): This is a checklist_or_acceptance_standard implementation of the archetype. Specifies the acceptance conditions that allow a task, sprint, project stage, or deliverable to be considered complete. Operationalizes completion criteria in project and product work. It should include evidence standards, not only a label that something is finished.
- **Timebox** (`timebox`): This is a limit_or_budget implementation of the archetype. Constrains work to a fixed time window and requires stop, review, handoff, or replanning when the window ends. The reconciliation controls classify timebox/timeboxing as a mechanism. It implements termination by bounding duration, but it is not the archetype itself.
- **Iteration Limit** (`iteration_limit`): This is a limit_or_budget implementation of the archetype. Stops or escalates a process after a defined number of retries, cycles, review rounds, or recursive expansions. Useful when every extra cycle has cost or risk, such as retry storms, failed negotiations, repeated review comments, or search loops.
- **Convergence Threshold** (`convergence_threshold`): This is a threshold_parameter implementation of the archetype. Stops iterative refinement when changes become smaller than a defined tolerance or when successive outputs are stable enough. A parameterized mechanism for numerical methods, model tuning, deliberation, estimation, training, and consensus processes.
- **Exhaustive Search Cutoff** (`exhaustive_search_cutoff`): This is a search_control implementation of the archetype. Declares search complete when all bounded alternatives, cases, nodes, sources, or hypotheses have been examined or ruled out. Implements termination when the process is defined over a finite search space or a bounded coverage universe.
- **Escalation Stop Protocol** (`escalation_stop_protocol`): This is a governance_protocol implementation of the archetype. Defines the highest escalation level, maximum review rounds, final decision authority, and post-escalation disposition. Useful for disputes, support tickets, incident command, exception handling, legal review, and governance processes.
- **Finality Rule** (`finality_rule`): This is a governance_rule implementation of the archetype. Declares when a decision, judgment, review, or appeal process is final unless a defined reopening condition occurs. Implements termination where recurring challenge or reconsideration would otherwise prevent action, settlement, or institutional stability.

These mechanisms should not be confused with the archetype. A timebox, base case, threshold, or definition of done is a way to implement termination logic. The archetype is the broader design pattern that links the mechanism to process scope, evidence, authority, disposition, and reentry.

prose_failure_modes: Common failure modes include premature termination, vague stop criteria, false exhaustion, endless reentry, brittle finality, metric gaming, and displacement of unresolved work into side channels. The usual mitigations are better evidence standards, explicit stopping authority, coverage checks for exhaustion claims, residual uncertainty records, and narrow but real reentry paths.

prose_neighbor_distinctions:
Termination Condition Design is distinct from **Stage-Gate Progression**, which controls advancement through stages. It is distinct from **Dependency Ordering**, which arranges prerequisites before action. It is distinct from **Completeness Audit**, which finds missing cases or gaps. It is distinct from **Controlled Reentry**, which governs return after exit or pause. It is distinct from **Closure-Preserving Operation**, which keeps outputs inside a valid domain.

The closest boundary questions are with Base-Case Anchoring, finality/decision closure, and timeboxing. In this draft, base cases and timeboxes remain variants or mechanisms unless the intervention is broader than stopping a process.

prose_cross_domain_examples:
- **recursive computation**: A recursive parser defines base cases for empty input, atomic tokens, and maximum nesting depth before recursing into subexpressions. The base cases and depth guard prevent infinite recursion and provide defined return states.
- **project delivery**: A team defines a “definition of done” that includes acceptance tests, documentation, owner signoff, and known-risk recording before a feature can leave development. The work can stop because completion evidence and disposition are explicit.
- **incident response**: An incident command process defines when active response ends, when monitoring continues, and when a new incident must be opened if symptoms recur. The stop condition separates closure, monitoring, and reentry.
- **legal or administrative appeals**: An appeals process has defined levels, deadlines, final authority, and reopening criteria for new material evidence. Finality prevents endless appeal while preserving a narrow path for legitimate reopening.
- **optimization and modeling**: A model fitting loop stops when validation improvement stays below a tolerance for several rounds or when a compute budget is reached. A convergence threshold and budget supply observable termination conditions.
- **research triage**: A literature search defines databases, date range, inclusion criteria, and saturation threshold before declaring the search complete. The exhaustion boundary and sufficiency rule prevent both false completion and endless searching.

prose_non_examples:
- **A meeting ends because the room reservation expired, with no decision, owner, or follow-up path.** This is externally forced stoppage, not designed termination.
- **A supervisor says “we are done discussing this” without predefined criteria or appeal path.** This may be authority exercise, but not a transferable termination condition design.
- **A dashboard turns green because a single metric crossed a threshold, while known exceptions remain unhandled.** A threshold alone is not enough when disposition and residual uncertainty are missing.
- **A workflow moves from intake to review to approval in fixed sequence.** That is staged progression unless the key intervention is the stopping logic for a loop or review.

prose_tradeoffs: This archetype trades open-endedness for closure. The benefit is that action, learning, shipment, adjudication, or handoff can occur. The cost is that some uncertainty remains. It also trades flexibility for shared standards: explicit stop rules reduce negotiation but can be too rigid in novel situations. In governance settings, finality supports stability but can feel unjust if appeal or reopening conditions are poorly designed.

prose_invariants_to_preserve: The termination condition should remain explicit, reviewable, and tied to a defined process. Continuation should either make measurable progress or remain bounded by a declared reason. Stopping should always produce a disposition, not hidden abandonment. Residual uncertainty should be recorded when closure happens before certainty. Reentry should be possible only under defined material conditions.

prose_target_outcomes: The desired outcomes are fewer endless loops, clearer closure, reduced waste, better accountability, and safer handling of residual uncertainty. A successful design lets a system stop without pretending that stopping equals omniscience. It also helps teams distinguish useful continuation from continuation that only delays responsibility.

prose_parameter_dimensions:
Important tuning dimensions include how strict the stop threshold is, how much residual uncertainty is acceptable, how expensive continuation is, who has authority to declare termination, how many iterations or escalation levels are allowed, how broad the search or review boundary is, and how easy it is to reopen a terminated process.

High-stakes contexts usually need stricter evidence, clearer appeal paths, and stronger residual-risk records. Low-stakes or high-speed contexts may rely more on timeboxes, iteration limits, or lightweight completion criteria.

prose_variants_and_near_names:
- **Base-Case Anchoring** (`base_case_anchoring`): Anchor recursive or progressive processes in clear base cases so later steps have a stable foundation and do not regress indefinitely. It remains under this parent when the named form mainly supplies a stop condition rather than a separate intervention logic.
- **Convergence-Based Termination** (`convergence_based_termination`): Stop iterative refinement when additional iterations produce changes below a declared tolerance or no longer improve the result enough to justify the cost. It remains under this parent when the named form mainly supplies a stop condition rather than a separate intervention logic.
- **Exhaustion-Based Termination** (`exhaustion_based_termination`): Stop when a declared bounded space of cases, options, sources, paths, or hypotheses has been completely inspected or ruled out. It remains under this parent when the named form mainly supplies a stop condition rather than a separate intervention logic.
- **Timeboxed Termination** (`timeboxed_termination`): End, pause, review, or replan work when a predefined time window expires. It remains under this parent when the named form mainly supplies a stop condition rather than a separate intervention logic.
- **Finality Condition Design** (`finality_condition_design`): Define when a dispute, review, appeal, or decision process becomes final enough for action, with narrow reopening conditions when needed. It remains under this parent when the named form mainly supplies a stop condition rather than a separate intervention logic.

Near names include stopping criterion, stop rule design, completion criteria design, termination rule design, definition of done, timeboxing, escalation stop rule, and finality rule. These should point to this archetype or its variants unless a future review promotes a more specific form.

Base-Case Anchoring

distinctive_feature: It emphasizes the grounding case more than the act of stopping.

distinct_from_parent: Termination Condition Design covers all forms of stopping, exhaustion, convergence, finality, and controlled handoff; Base-Case Anchoring specifically supplies the bottom of a recursive or progressive structure.

still_same_parent_because: The base case functions as the condition that prevents infinite regress or endless descent.

use_when: A process calls back to earlier cases, prerequisites, assumptions, justifications, or training stages.

use_when: Failure comes from having no minimal accepted case or no stable starting point.

use_when: The process needs a foundation before recursive extension can be safe.

example_domains:
algorithm design
proofs and formal reasoning
education and scaffolding
organizational onboarding

Convergence-Based Termination

distinctive_feature: The stop condition is based on stability or diminishing change rather than a fixed count or complete exhaustion.

distinct_from_parent: The parent includes timeboxes, base cases, exhaustion, and finality; this variant specifically uses a convergence criterion.

still_same_parent_because: The convergence threshold is still a termination condition attached to an iterative process.

source_primes: convergence threshold iteration

use_when: A process repeatedly updates an estimate, model, design, consensus, or approximation.

use_when: Perfect exactness is unavailable, unnecessary, or too costly.

use_when: The system can measure difference, stability, error, or marginal improvement across iterations.

example_domains:
numerical computation
machine learning
forecasting
consensus processes
design iteration

Exhaustion-Based Termination

distinctive_feature: Termination is justified by coverage of a bounded search or review space.

distinct_from_parent: The parent covers any designed stop condition; this variant requires a declared universe and evidence of exhaustion.

still_same_parent_because: Exhaustion is one way to satisfy a stop rule.

source_primes: completeness boundedness

use_when: A process depends on checking alternatives, cases, evidence sources, or search nodes.

use_when: The relevant space can be bounded enough to define what exhaustion means.

use_when: The key risk is either stopping before all relevant areas are checked or searching forever.

example_domains:
search and rescue
legal discovery
debugging
literature review
quality inspection

Timeboxed Termination

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

distinctive_feature: The boundary is temporal rather than based on proof, convergence, or exhaustion.

distinct_from_parent: The parent is the abstract stop-condition intervention; timeboxing is a concrete limit mechanism that may or may not be sufficient by itself.

still_same_parent_because: The timebox is one implementation of designed termination.

source_primes: boundedness iteration

use_when: Continuation is likely to consume more time than the additional value warrants.

use_when: A group needs a forcing function to leave discussion, exploration, or refinement and make a disposition.

use_when: Residual uncertainty can be documented or routed after the time window ends.

Timebox

slug: timebox

example_domains:
agile delivery
meetings and facilitation
incident response
research triage

Finality Condition Design

distinctive_feature: The stop condition governs institutional or procedural finality rather than technical iteration.

distinct_from_parent: The parent includes technical and operational stop rules; this variant applies termination logic to governance and adjudication.

still_same_parent_because: Finality is a social or procedural form of termination condition.

use_when: Repeated reconsideration blocks action, settlement, accountability, or implementation.

use_when: There must be a highest appeal level, final authority, or closure event.

use_when: The system needs a way to distinguish legitimate reopening from endless relitigation.

example_domains:
law and adjudication
governance
policy exceptions
design approval
organizational conflict

near_names:
Stopping Criterion
Stop Rule Design
Completion Criteria Design
Definition of Done
Base-Case Anchor
Timeboxing
Finality Rule
Escalation Stop Rule