Progress-Guarded Livelock Disruption

batch: Batch 09

aliases:
livelock cycle disruption
livelock escape design
active stalemate interruption
futile response cycle breaking
non-progress cycle disruption
progress-guarded retry escape

source_primes: livelock concurrency race_condition feedback coupling state_and_state_transition coordination oscillation

slug: livelock

slug: concurrency

slug: feedback

slug: coupling

slug: coordination

slug: oscillation

slug: deadlock

slug: synchronization

slug: observability

slug: randomization

slug: scheduling

slug: flow

slug: queueing

slug: starvation

components:
Activity–Progress Separation
Joint-State Progress Invariant
Coupled Actor Response Map
Non-Progress Cycle Detector
Liveness Observability Signal
Symmetry-Breaking Rule
Desynchronization/Backoff Policy
Quiescence or Hold Window
External Progress Resolver
Fairness and Starvation Guard
Recovery Checkpoint and Reentry Rule
Retry Budget
Cycle Signature Registry
Stakeholder Priority Contract
Safe Race Boundary

mechanisms:
Liveness Watchdog
Progress Counter Heartbeat
Joint-State Cycle Trace
Exponential Backoff with Jitter
Randomized Retry Desynchronization
Leader Election or Token Passing
Bounded Priority Rotation
Circuit Breaker and Cooldown
Quiescence Barrier
External Arbitration/Escalation
Contention Trace Replay
State-Machine Cycle Detection

core_intuition: A livelock looks busy. That is why it survives. The solution is not simply more effort or faster reaction; it is a rule that asks whether the joint system moved closer to completion and, when it did not, deliberately changes the pattern of responsiveness that is keeping everyone stuck.

canonical_formula: Livelock disruption = actors A + joint state J + activity signal U + progress metric P + cycle detector C + rule perturbation R + completion check V, where U remains high while P stays flat; success requires R to change the reachable joint states so V can pass.

structural_problem: Coupled actors, processes, teams, controllers, or policies remain active and responsive, but their moves mutually cancel, reset, defer, or compensate for one another. The system consumes attention, time, resources, retries, or coordination bandwidth without reaching closure because every local adaptive response preserves the global stuck cycle.

trigger_conditions: Activity, retries, messages, negotiations, or state changes continue while the completion metric remains flat.

trigger_conditions: Each actor’s move is locally reasonable but triggers a compensating move by another actor.

trigger_conditions: The system repeatedly visits the same joint states, negotiation positions, lock-free retries, or operational configurations.

trigger_conditions: Attempts to be polite, nonblocking, adaptive, or responsive make the cycle more stable instead of resolving it.

trigger_conditions: Deadlock checks show that actors are not simply blocked; they are moving, yielding, or retrying.

trigger_conditions: Adding capacity or speed increases churn without increasing completions.

trigger_conditions: Progress depends on breaking symmetry, choosing a winner/turn, or temporarily reducing responsiveness.

symptoms: High CPU, message traffic, meeting time, ticket updates, or negotiation activity with no completed units.

symptoms: Repeated “after you / no, after you” handoffs, mutual backoffs, or mirrored concessions.

symptoms: Logs show alternating retries, aborts, yields, rollbacks, or route changes that return to the same state.

symptoms: Stakeholders describe the system as busy, polite, reactive, or agile but unable to finish.

symptoms: Actors avoid blocking one another yet still starve the shared objective.

symptoms: Timeouts fire repeatedly but only restart the same cycle.

symptoms: Fairness rules prevent any actor from taking a decisive completing move.

root_tension: Local responsiveness protects actors from blocking or conflict, but global progress may require one actor, rule, or state to stop reciprocating long enough for a real transition to complete.

anti_signatures: If actors are inactive because each waits while holding resources, use deadlock_prevention or deadlock_resolution.

anti_signatures: If uncontrolled relative timing corrupts shared state but the system can complete, use concurrency_control and order-sensitive safeguards.

anti_signatures: If the main issue is too much active work diluting capacity, use work_in_progress_limiting.

anti_signatures: If one blocked front item delays a queue, use head_of_line_blocking_relief.

anti_signatures: If the cycle is a normal oscillatory control problem without coupled strategic responsiveness, use oscillation_damping or gain_control.

anti_signatures: If the issue is merely slow completion rather than repeated return to a no-progress joint state, use scheduling, resource_management, or flow improvement patterns.

anti_signatures: If a single actor is unresponsive rather than mutually responsive, diagnose failure, timeout, escalation, or availability instead.

structural_intervention: Introduce an explicit progress guard for the coupled system, detect recurring non-progress cycles, and alter the response rule by desynchronizing, adding asymmetry, imposing a temporary hold, assigning priority, or escalating to a resolver until the joint state crosses a completion threshold.

action_logic: Define the shared progress objective and distinguish it from activity, responsiveness, politeness, utilization, or local motion.

action_logic: Map the actors, resources, states, triggers, and reciprocal moves that keep the cycle alive.

action_logic: Instrument liveness: record repeated state signatures, retry counts, handoff loops, repeated concessions, or unchanged completion metrics.

action_logic: Set a non-progress threshold that marks livelock rather than ordinary iteration or useful negotiation.

action_logic: Choose a disruption mode: desynchronize, randomize, add cooldown, hold one actor still, appoint a temporary leader, rotate priority, or escalate.

action_logic: Apply the least disruptive rule change that lets at least one completing transition occur.

action_logic: Verify progress against the independent progress metric, not against renewed activity.

action_logic: Record the livelock signature and add prevention or early-warning rules so the same active cycle is not recreated.

action_logic: Retire the exceptional disruption once a stable non-livelocked operating rule is in place.

decision_rules: Treat rising activity with flat completions as a possible livelock signal, not as evidence of commitment.

decision_rules: Do not reward or optimize local responsiveness until it is checked against system-level progress.

decision_rules: When actors mirror each other, introduce asymmetry before adding more retries.

decision_rules: When simultaneous correction creates the cycle, add jitter, cooldown, or turn-taking.

decision_rules: When fairness prevents completion, use bounded priority or rotation rather than unbounded equal yielding.

decision_rules: Escalate to an external resolver when local actors cannot safely choose the asymmetry themselves.

decision_rules: Preserve safety and data integrity while disrupting the cycle; livelock escape must not become race-condition acceptance.

decision_rules: After escape, distinguish permanent rule changes from one-time recovery actions.

target_invariants: The progress metric remains independent of raw activity or utilization.

target_invariants: Safety, integrity, and authorization constraints remain valid during cycle disruption.

target_invariants: At least one actor can complete a real transition rather than continuously yielding.

target_invariants: Fairness or priority changes are bounded, visible, and reviewable.

target_invariants: The system does not replace livelock with deadlock, starvation, unsafe races, or unbounded escalation.

target_invariants: Cycle signatures remain observable enough for future detection and diagnosis.

expected_outcomes: Repeated non-progress cycles are detected earlier.

expected_outcomes: Actors stop mistaking activity for advancement.

expected_outcomes: Retries, negotiations, controllers, or workflows desynchronize enough for completion.

expected_outcomes: The joint system exits the active stuck region and reaches a validated next state.

expected_outcomes: Future coordination rules include explicit progress, liveness, fairness, and escape conditions.

expected_outcomes: Operational load, frustration, churn, and resource waste decline without suppressing necessary responsiveness.

prose_essence:
Detect active non-progress cycles and break them by adding progress tests, desynchronization, asymmetry, cooldown, or external resolution.

Progress-Guarded Livelock Disruption applies when actors keep responding to one another, retrying, yielding, backing off, renegotiating, or correcting, yet the joint state returns to the same non-productive region. The intervention distinguishes activity from progress, maps the reciprocal triggers that keep the cycle alive, adds a liveness/progress guard, then changes the coordination rule through jitter, priority, token passing, quiescence, cooldown, or escalation so at least one actor can complete a real state transition.

Retry-Collision Livelock Escape

short_definition: A livelock variant where actors repeatedly retry after conflicts but their retry timing makes them collide again.

distinctive_feature: The escape move is primarily desynchronization of retries rather than adjudication or resource release.

distinct_from_parent: This variant focuses on retry systems and collision timing, while the parent also covers negotiation, robotics, workflow, and control cycles.

still_same_parent_because: It still requires progress detection, cycle recognition, desynchronization, and validation of real completion.

source_primes: livelock concurrency race_condition

use_when: Conflicts are detected and handled, but retries recreate the same conflict.

use_when: Actors are not blocked; they keep aborting, yielding, or retrying.

use_when: Randomized or staggered timing can safely alter the outcome.

example: Two clients repeatedly abort and retry at identical intervals until jitter is added.

failure_modes: Blind backoff hides persistent failure rather than escaping the livelock.

Symmetry-Breaking Livelock Escape

short_definition: A livelock variant where identical rules or mirrored moves keep actors canceling each other until a bounded asymmetry is introduced.

distinctive_feature: The decisive move is to break symmetry rather than add capacity or slow all actors equally.

distinct_from_parent: The parent includes several escape modes; this variant highlights role, token, and priority assignment.

still_same_parent_because: The same progress guard, cycle detector, fairness guard, and reentry rule remain required.

source_primes: livelock coordination synchronization

use_when: Actors make equivalent or mirrored choices.

use_when: A leader, token, priority, or role asymmetry can safely allow progress.

domain: robotics

example: Two robots yield to each other until one receives a temporary right-of-way token.

failure_modes: The temporary priority becomes permanent domination or starvation.

name: Human Coordination Livelock Interruption

short_definition: A social or organizational livelock where responsive meetings, revisions, escalations, or deference loops prevent closure.

distinctive_feature: The cycle is sustained by social responsiveness, deference, governance ambiguity, or constant re-planning rather than software retries.

distinct_from_parent: The parent is cross-domain; this variant emphasizes legitimacy, decision rights, and group process.

still_same_parent_because: It still distinguishes activity from progress, maps reciprocal triggers, interrupts the cycle, and verifies closure.

source_primes: livelock coordination feedback

use_when: Teams continuously adapt to one another but no commitment stabilizes.

use_when: People avoid conflict, imposition, or premature closure so thoroughly that progress stops.

use_when: Decision rights, freeze windows, or facilitation can interrupt the loop.

example: Two teams keep revising requirements in response to each other until a freeze window and decision owner are established.

failure_modes: The facilitator treats symptoms as lack of effort and schedules more meetings, increasing livelock activity.

Controller-Hunting Livelock Relief

short_definition: A control or automation variant where mutually responsive adjustments keep a system searching or hunting without settling into a useful state.

distinctive_feature: The livelock sits near feedback oscillation, but progress/settling is blocked by reciprocal adaptive rules.

distinct_from_parent: The parent handles any livelock; this variant highlights control-system and automation dynamics.

still_same_parent_because: The same progress guard and active-cycle disruption logic apply.

source_primes: livelock feedback oscillation damping

use_when: Controllers, agents, or policies adjust to one another continuously.

use_when: The system stays active but does not settle or complete.

use_when: Hysteresis, damping, hold windows, or role priority can break the active search loop.

example: An interface and user keep adapting to each other until a confirmation hold stops the loop.

failure_modes: Ordinary damping is applied without checking whether coupled agent rules are preserving non-progress.

near_names:
Livelock Breaking
Livelock Resolution
Active Stalemate Interruption
Futile Response Cycle Breaking
Progress Guard


Progressive Disclosure

type: archetype

source: generated

batch: First Iteration/Batch 38

source_primes: chunking cognitive_load layering

slug: chunking

slug: layering

slug: hierarchy

slug: compression

slug: representation

slug: scaffolding

components:
Information Layer
Reveal Trigger
Task Stage
User Expertise Level
Drilldown Path
Orientation Cue
Critical Detail Exception
Full Access Escape Hatch
Default Summary
Readiness Signal
Depth Label
Return Path
Progressive Validation Prompt
Expanded View Preference

mechanisms:
Expandable Section
Staged Onboarding
Layered Documentation
Drill-Down Dashboard
Progressive Training Module
Just-in-Time Help
Tiered Decision Support
Wizard or Stepper Workflow
Advanced Settings Panel
Summary-Detail View

essence_one_line: Reveal information in layers so users receive what they need when they are ready for it.

compression_statement: When presenting all information at once overloads users, disclose information progressively according to task stage, expertise, risk, or decision need while preserving access to deeper detail.

core_intuition: Useful information is not equally useful at every moment. Progressive Disclosure separates immediate action guidance from optional, advanced, contextual, or exception detail, then gives users reliable paths to reveal more when the situation calls for it.

canonical_formula: current_need + information_layers + reveal_trigger + orientation_cue + drilldown_path -> lower_overload + timely_detail + preserved_depth

structural_problem: People face more detail than they can use at the current moment. The relevant facts may exist, but they arrive too early, too densely, or without a path from overview to detail, causing overload, error, hesitation, abandonment, or superficial compliance.

condition: All detail is shown at once

signal: Users must scan long pages, complex dashboards, dense forms, exhaustive menus, or full procedures before knowing what matters now.

condition: User readiness varies

signal: Novices need guidance and examples, while experts need direct controls, reference detail, or shortcuts; one flat presentation underserves both.

condition: Information relevance changes by task stage

signal: A detail that is useful during setup, diagnosis, execution, review, or escalation becomes distracting when shown outside that stage.

condition: Advanced or rare information is necessary but not always relevant

signal: Safety notes, configuration options, exceptions, legal detail, or advanced settings must remain available without dominating the ordinary path.

condition: Users abandon or misuse the system before reaching the right detail

signal: Important information is buried in volume rather than absent; users leave, guess, over-click, or ask for help because the path to detail is unclear.

condition: A summary is needed but cannot safely replace the full explanation

signal: Decision-makers need a first-pass view while analysts, auditors, practitioners, or learners still need access to underlying evidence, assumptions, and exceptions.

symptom: Users skim past important content

interpretation: The presentation asks users to filter too much detail before they know which detail matters.

symptom: Novices freeze while experts complain about clutter

interpretation: The same flat layer is being used for different readiness levels instead of staging guidance and depth.

symptom: Advanced settings or exceptions create errors for ordinary users

interpretation: The design exposes low-frequency or high-complexity options before the user has a reason to engage them.

symptom: People remember the headline but cannot locate the supporting detail

interpretation: The overview exists, but the drilldown path and orientation cues are weak.

symptom: Critical warnings are hidden with ordinary optional detail

interpretation: The disclosure policy treats all deeper information alike instead of distinguishing optional depth from mandatory risk cues.

symptom: Documentation, training, or dashboards become either too shallow or too exhaustive

interpretation: The design lacks a stable relationship between first-layer guidance and later layers of explanation, evidence, or action.

root_tension: Progressive Disclosure balances two opposing needs: reduce immediate cognitive load, and preserve enough depth for learning, exception handling, accountability, and expert use. If it hides too much, it becomes paternalistic or unsafe; if it reveals too much, it stops being progressive.

case: The main issue is that information is irrelevant and should be removed entirely

why_not: Task-relevant compression or simplification may be primary when the solution is deletion, filtering, or condensation rather than staged access.

case: The main issue is grouping information into meaningful units

why_not: Chunked Information Design is primary when the key intervention is defining chunks and labels, while Progressive Disclosure is primary when timing, layer depth, or reveal conditions govern access.

case: The problem is a system architecture with layers hiding implementation detail

why_not: Layered Abstraction is the better archetype when the layers are structural interfaces between system levels, not staged information access for a user.

case: The goal is to increase prototype or model fidelity over iterations

why_not: Progressive Fidelity Increase is a development or modeling pattern; Progressive Disclosure is about when and how users receive information detail.

case: The detail is safety-critical at the first moment of action

why_not: Safety-critical warnings should not be deferred merely to reduce apparent clutter; the disclosure policy must make mandatory risk information visible at the point of need.

structural_intervention: Define the user’s current task, readiness, and risk context; divide information into meaningful layers; assign each layer to a reveal trigger; preserve orientation between layers; and test whether users can act from the first layer while still finding deeper detail when needed.

step: Clarify the use moment

logic: Name the user, task stage, decision need, risk level, time pressure, and prior knowledge that determine what information is immediately useful.

step: Inventory information by depth and urgency

logic: Separate immediate guidance, contextual explanation, optional examples, advanced settings, evidence, assumptions, exceptions, and audit detail.

step: Design the first layer

logic: Create a surface layer that supports safe orientation and next action without requiring users to process the full information space.

step: Assign deeper layers

logic: Place supporting explanation, examples, advanced controls, edge cases, and evidence into deeper layers that remain reachable and clearly labeled.

step: Specify reveal triggers

logic: Decide whether deeper information appears by user request, task progression, risk signal, expertise level, validation need, or system state.

step: Add orientation cues and return paths

logic: Show users where they are, what was hidden, why a detail is being shown, and how to return to the overview or full reference.

step: Protect mandatory detail

logic: Identify warnings, constraints, legal requirements, or irreversible-action cues that must be surfaced at the point of need rather than buried in optional layers.

step: Test reveal behavior

logic: Observe whether users can complete realistic tasks, locate deeper detail, recover from wrong assumptions, and avoid both overload and hidden-information errors.

step: Revise layer boundaries and triggers

logic: Move information between layers when evidence shows overload, confusion, under-disclosure, over-disclosure, or poor retrieval.

rule: Reveal what is needed now, not everything known

application: The first layer should support orientation and immediate action while avoiding premature exposure to low-frequency or advanced detail.

rule: Never hide what changes the safe action

application: Warnings, contraindications, irreversible consequences, and material constraints must appear before the user can make the affected decision.

rule: Make deeper access explicit

application: Users should know that more detail exists and how to reach it; hidden depth without signposting becomes omission.

rule: Use triggers that match the user’s reasoning path

application: Reveal by stage, expertise, risk, uncertainty, or user request, not by arbitrary page length or aesthetic neatness.

rule: Preserve expert efficiency without abandoning novices

application: Experts should have shortcuts or expanded views; novices should have guided layers, examples, and gradual exposure.

rule: Treat layers as hypotheses

application: Layer assignments and triggers should be revised through task testing, support data, error reports, and retrieval evidence.

invariant: The first layer is usable and safe

reason: Users should be able to orient and take the next reasonable action without being forced through unnecessary depth.

invariant: Deeper detail remains accessible

reason: Progressive Disclosure is not deletion; the design must preserve paths to explanation, evidence, advanced control, and exceptions.

invariant: Reveal triggers are legible

reason: Users need to understand why information appears, disappears, or becomes relevant; otherwise staging feels arbitrary.

invariant: Critical warnings are not buried

reason: Safety, compliance, and irreversible-decision information must be visible at the relevant moment even if it disrupts the clean first layer.

invariant: Orientation is preserved across layers

reason: Users should know what layer they are in, how it relates to the overview, and how to return or move deeper.

invariant: Layering matches actual use rather than designer convenience

reason: A beautiful hierarchy that does not match task flow, expertise, or decision need will produce hidden-information errors.

outcome: Lower immediate cognitive load

evidence_signal: Users encounter fewer irrelevant or premature details at the first moment of use.

outcome: Higher task completion and lower abandonment

evidence_signal: Users can proceed through the ordinary path with less scanning, guessing, or help-seeking.

outcome: Better expert and novice fit

evidence_signal: Novices can follow guided layers while experts can reach advanced detail or shortcuts without being slowed by beginner explanations.

outcome: Improved retrieval of deeper detail

evidence_signal: Users can locate supporting explanations, exceptions, and evidence when realistic situations require them.

outcome: Reduced error from premature complexity

evidence_signal: Advanced options, edge cases, or unusual settings create fewer mistakes because they appear under appropriate triggers.

outcome: Preserved accountability and depth

evidence_signal: Auditors, reviewers, or advanced users can still inspect assumptions, evidence, and full guidance behind the summary layer.

prose_essence:
Progressive Disclosure reveals information in layers so people receive what they can use now while preserving a path to what they may need later. It is not simply hiding content, shortening a page, or using an accordion widget. The archetype works when layer boundaries, reveal triggers, orientation cues, and deeper access paths are deliberately designed around task stage, expertise, risk, and decision need.

The basic pattern is: start with the smallest safe layer that supports orientation and next action; reveal additional explanation, options, evidence, or exceptions when a meaningful condition makes that detail relevant; and make sure users can find the full depth when they need it.

Task-Stage Disclosure

short_definition: Reveals information according to where the user is in a workflow, learning path, service journey, or decision sequence.

distinctive_feature: The reveal trigger is the user’s current stage in an ordered task or journey.

distinct_from_parent: The parent covers several trigger types; this variant is specifically stage-based.

still_same_parent_because: It still divides information into layers and reveals deeper or different detail when the use context changes.

source_primes: chunking layering cognitive_load

condition: Different stages require different information

application: Show setup information during setup, execution guidance during action, and review or escalation detail only when those stages are reached.

condition: Premature detail causes errors or abandonment

application: Keep later-stage exceptions, controls, or explanations out of the first layer while signposting where they will appear.

role: Defines the stage that controls relevance.

role: Stores stage-specific guidance, examples, or exceptions.

role: Moves the user to the next information layer when the task stage changes.

example_domains:
software onboarding
operations
service design

domain: Software onboarding

example: A setup wizard reveals API key instructions only after the account, environment, and permissions steps are complete.

domain: Operations

example: A field checklist reveals verification and reporting steps after the repair step is marked complete.

failure_mode: rigid stage gating

cause: The workflow assumes every user follows the same order.

mitigation: Add skip paths, backtracking, expert shortcuts, and alternate-stage access when safe.

Expertise-Adaptive Disclosure

short_definition: Adjusts the amount and kind of information shown according to a user’s skill, role, confidence, or demonstrated readiness.

distinctive_feature: The reveal policy varies by expertise or readiness rather than only by task stage.

distinct_from_parent: The parent is general staged access; this variant focuses on audience differentiation and readiness fit.

still_same_parent_because: It still uses layers, triggers, drilldown, and critical-detail exceptions to manage information access.

condition: Novices and experts share the same system or material

application: Provide guided explanations, examples, or constraints for novices while preserving shortcuts, full controls, and reference depth for experts.

condition: Readiness can be observed or selected

application: Use explicit role selection, progress, proficiency checks, or user preference to choose the initial disclosure depth.

role: Controls which layer is default.

role: Indicates when deeper complexity can be introduced.

role: Lets experienced users choose a fuller default view when appropriate.

example_domains:
education
enterprise software
professional training

domain: Education

example: A learning platform gives beginners hints and worked examples, then reveals proof detail and open-ended problems after mastery signals.

domain: Enterprise software

example: A tool defaults to guided mode for new analysts and compact expert mode for certified users.

failure_mode: misclassified expertise

cause: The system guesses a user’s readiness incorrectly.

mitigation: Allow manual override, explain mode differences, and monitor errors by mode.

Risk or Exception Disclosure

short_definition: Keeps ordinary guidance simple while surfacing warnings, constraints, exceptions, or escalation detail when risk conditions become relevant.

distinctive_feature: The reveal trigger is a risk, exception, threshold, or contraindication rather than ordinary user curiosity or stage progression.

distinct_from_parent: The parent can hide optional detail; this variant emphasizes when hiding becomes unsafe and must be overridden.

still_same_parent_because: It still stages information by relevance while preserving deeper exception detail and explicit reveal conditions.

condition: Most use cases are routine but exceptions matter

application: Keep rare exceptions out of the routine path until a cue, selection, threshold, or condition makes them relevant.

condition: Some information is mandatory at the point of risk

application: Override ordinary hidden layers and surface critical constraints before the affected action is taken.

role: Defines detail that must bypass ordinary staging.

role: Indicates that a warning or exception layer should appear.

role: Directs users to deeper guidance or human review when the exception exceeds routine handling.

example_domains:
clinical decision support
compliance workflows
industrial operations

domain: Compliance workflow

example: A reporting tool hides rare filing exceptions until a transaction type, jurisdiction, or threshold makes them mandatory.

domain: Industrial operations

example: A maintenance interface shows ordinary steps first but surfaces lockout or escalation warnings when hazard conditions are selected.

failure_mode: unsafe concealment

cause: The system treats warnings as optional depth.

mitigation: Classify mandatory risk detail separately and test for point-of-action visibility.

Drill-Down Disclosure

short_definition: Starts from an overview or aggregate layer and lets users navigate downward into progressively more specific detail.

distinctive_feature: The user actively traverses a summary-to-detail path, often through nested levels.

distinct_from_parent: The parent includes many reveal styles; this variant centers on exploratory movement from overview to detail.

still_same_parent_because: It remains staged information access, with visible paths from first-layer summary to deeper detail.

source_primes: hierarchy layering search_and_retrieval

condition: Users need both overview and detail

application: Show summaries, aggregates, or categories first, then allow inspection of the underlying cases, metrics, examples, or assumptions.

condition: Navigation depth is user-driven

application: Let the user choose which branch to inspect rather than forcing a fixed stage sequence.

role: Defines the route from summary to detail.

role: Shows the current level and parent context.

role: Lets users move back to overview or comparison.

example_domains:
analytics
knowledge bases
case management

domain: Analytics

example: An executive dashboard opens from total risk score to category, region, account, and incident-level data.

domain: Knowledge base

example: A troubleshooting page begins with symptom groups and lets users open diagnostic branches and detailed repair instructions.

failure_mode: lost in depth

cause: Users drill down but lose the parent context or cannot return to comparison.

mitigation: Use breadcrumbs, stable labels, preserved filters, and clear return paths.

near_names:
Staged Disclosure
Layered Disclosure
Gradual Disclosure
Expandable Sections
Just-in-Time Help
Drill-Down Dashboard


Progressive Fidelity Increase

batch: First Iteration/Batch 28

aliases:
Fidelity Ladder
Fidelity Ramp
Staged Fidelity
Incremental Fidelity
Progressive Model Refinement

alias_records:
Fidelity Ladder
Fidelity Ramp
Staged Fidelity
Incremental Fidelity
Progressive Model Refinement

Progressive Refinement from Core Model

role: Motivates adding detail in structured layers around a validated lower-fidelity base.

Approximation

slug: approximation

role: Frames early fidelity levels as intentionally partial approximations rather than final truth.

Iteration

slug: iteration

role: Supports repeated improvement while requiring that each cycle changes fidelity in a controlled way.

Uncertainty

slug: uncertainty

role: Fidelity increases are justified when unresolved uncertainty must be reduced for learning or decision quality.

Complexity

slug: complexity

role: Each added layer increases complexity and therefore needs a budget, gate, or stop rule.

Design Prototyping

role: A common implementation domain where artifacts move from low to high fidelity.

Correspondence Principle

role: Higher-fidelity layers should remain compatible with the valid conclusions of lower-fidelity representations where their domains overlap.

Scaffolding

role: Supports staging complexity so people or systems can handle it progressively.

Feedback

slug: feedback

role: Validation results and user or system feedback drive escalation, revision, rollback, or stopping.

Parsimony

slug: parsimony

role: Prevents fidelity from increasing beyond what evidence, risk, or decision need justifies.

Diminishing Returns

role: Helps define when additional fidelity no longer changes the decision enough to justify its cost.

components:
Fidelity Scale
Core Reference
Uncertainty Register
Refinement Layer
Validation Checkpoint
Escalation Criterion
Detail Addition Rule
Fidelity Cost Budget
Stop or Defer Rule
Rollback or Simplification Rule
Fidelity Dimension Map
Comparability Baseline
Critical Edge Case Set
Handoff Artifact
Stakeholder Readiness Signal

mechanisms:
Low-to-High Fidelity Prototyping
Simulation Refinement Ladder
Staged Research Model
Progressive Policy Pilot
Design Mockup to Production Path
Coarse-to-Detailed Planning
Learning Scaffold Sequence
Engineering Review Gate
Model Calibration Increment
Digital Twin Maturation

essence_one_line: Increase model, prototype, or process fidelity in controlled layers as uncertainty resolves.

compression_statement: When full-fidelity design is costly or premature, increase fidelity progressively so each layer of detail is justified by evidence, need, or risk.

core_intuition: A low-fidelity representation is often the right starting point because it is cheap, interpretable, and fast to test. It becomes dangerous when treated as sufficient after the decision has outgrown it, or when teams jump to high fidelity before knowing what detail matters. Progressive Fidelity Increase solves this by making fidelity a staged variable: add only the next useful layer, validate it, and stop or roll back when further realism does not improve the decision.

canonical_formula: purpose + current_fidelity + named_uncertainty + validation_gate -> justified_next_fidelity_layer, with stop_or_rollback when marginal value falls below cost

structural_problem: A team either stays too crude for too long or jumps to high fidelity before the uncertainty justifies the cost.

trigger_conditions: Full-fidelity analysis, design, or implementation would be expensive, slow, cognitively overwhelming, or premature.

trigger_conditions: A low-fidelity model or prototype is useful for early learning but cannot answer later questions about feasibility, realism, edge cases, or operational readiness.

trigger_conditions: Teams are debating fidelity as a preference rather than tying it to uncertainty, decision stakes, or validation evidence.

trigger_conditions: Each added detail has cost, but staying at low fidelity risks false confidence, oversimplification, or poor transfer to real conditions.

trigger_conditions: The project needs a path from concept to operational readiness without treating every intermediate artifact as final.

symptoms: Stakeholders request high-fidelity artifacts before the core assumption has been tested.

symptoms: A prototype or model looks convincing but has not tested the fidelity dimension that matters most.

symptoms: The team keeps adding detail because it can, not because the decision requires it.

symptoms: Early simplified results no longer match the complexity of the question being asked.

symptoms: Later teams distrust earlier work because assumptions, omitted details, and escalation criteria were not documented.

symptoms: High-fidelity work reveals basic errors that could have been found with a cheaper lower-fidelity stage.

root_tension: The intervention must balance learning speed and tractability against realism and decision reliability. Too little fidelity produces misleading simplicity; too much fidelity too early wastes resources, hides the signal, and can create false confidence.

anti_signatures: The correct fidelity level is already known and cheap to implement.

anti_signatures: The problem requires immediate high-fidelity assurance because simplified testing would be unsafe or legally unacceptable.

anti_signatures: The main task is merely to repeat an improvement cycle without changing fidelity dimensions.

anti_signatures: The team is choosing among options rather than increasing the detail of one representation; Coarse-to-Fine Search or progressive narrowing may fit better.

anti_signatures: The central issue is validating an already-added layer rather than planning the fidelity ramp; Layered Model Validation may be the better archetype.

structural_intervention: Define fidelity levels, validation checkpoints, escalation criteria, and what detail is added at each layer.

action_logic: Name the decision, learning goal, or implementation risk that the current representation must support.

action_logic: Define the fidelity scale and separate fidelity dimensions so the team knows what “higher fidelity” actually means.

action_logic: Start from a core reference or lowest useful fidelity that preserves the main structure while remaining cheap to test.

action_logic: Record uncertainties and assumptions that the current fidelity cannot resolve.

action_logic: Choose a bounded refinement layer that targets the highest-value uncertainty or risk.

action_logic: Run a validation checkpoint to determine whether the new layer improved learning, accuracy, usability, safety, or decision quality.

action_logic: Escalate, revise, stop, defer, or roll back based on explicit criteria rather than habit or aesthetics.

action_logic: Preserve comparability and documentation so learning accumulates across fidelity levels.

decision_rules: Increase fidelity only when the current level cannot answer a decision-relevant question or manage a material risk.

decision_rules: Raise the fidelity dimension that is most connected to the uncertainty, not necessarily the dimension that is easiest to polish.

decision_rules: Treat high fidelity as a cost-bearing intervention, not as an automatic mark of quality.

decision_rules: Do not add a refinement layer unless it can be validated, compared, or used by the next decision point.

decision_rules: Stop or defer when added fidelity no longer changes conclusions, materially reduces risk, or improves stakeholder action enough to justify the burden.

decision_rules: Roll back or simplify when added fidelity introduces noise, fragility, overfitting, maintenance burden, or false confidence.

target_invariants: The core purpose remains visible across fidelity levels.

target_invariants: Each fidelity increase has an explicit reason tied to uncertainty, risk, evidence, or decision value.

target_invariants: Lower-fidelity findings are not silently invalidated unless the new layer shows why they fail.

target_invariants: Assumptions, omitted details, and scope boundaries are documented at each level.

target_invariants: Users can distinguish fidelity dimensions such as visual polish, behavioral realism, operational readiness, and quantitative precision.

target_invariants: The escalation path remains reversible or at least reviewable.

expected_outcomes: Better learning per unit of cost because early stages answer cheap questions before expensive fidelity is built.

expected_outcomes: Reduced premature complexity and reduced risk of staying with oversimplified artifacts too long.

expected_outcomes: Clearer handoffs between research, design, engineering, policy, implementation, and operations.

expected_outcomes: More credible high-fidelity work because it is grounded in validated lower-fidelity layers.

expected_outcomes: Improved decision timing: enough fidelity for the decision at hand without waiting for unnecessary completeness.

prose_essence:
Progressive Fidelity Increase is the pattern of moving from a simple, low-cost representation toward richer realism only when the next layer is justified. It treats fidelity as a controlled variable rather than as a default goal. A low-fidelity model, prototype, plan, or explanation is valuable because it is fast and legible; a higher-fidelity version is valuable when it answers questions the simpler version cannot answer.

The archetype matters because both extremes are common. Teams either remain with rough artifacts after the question has become too consequential, or they jump immediately to high-fidelity work before knowing which details matter. This archetype creates a disciplined middle path: choose the right next layer of detail, validate it, and stop or roll back when it does not pay for itself.

prose_when_to_use:
Use this archetype when full realism would be costly or premature, but the simplified representation will eventually become misleading if it is not refined. It is especially useful in prototyping, modeling, simulation, policy pilots, research programs, planning, education, software, and engineering.

Typical use cases include a product team deciding when to move beyond wireframes, a simulation team deciding when to add spatial or stochastic detail, a city deciding when a pilot is ready for operational complexity, or an instructor deciding when learners are ready for more realistic cases. The common structure is not the domain; it is the staged raising of fidelity through gates.

prose_structural_problem:
The structural problem is a mismatch between the fidelity of the representation and the maturity of the decision. Low fidelity is cheap and clarifying, but can hide important constraints. High fidelity can be more realistic, but it can also be expensive, fragile, difficult to interpret, and falsely persuasive.

The project fails when the team treats fidelity as a vibe: more detail feels more serious, less detail feels more agile, and no one can say what question the next fidelity level is supposed to answer. Progressive Fidelity Increase converts that vague preference into a sequence of fidelity levels, validation checkpoints, escalation criteria, and stop rules.

prose_intervention_logic:
The intervention begins by naming the purpose and the current fidelity level. Next, the team identifies the uncertainty, risk, or decision question that the current level cannot answer. It then selects a bounded refinement layer that raises the relevant fidelity dimension, tests whether that layer improves learning or decision quality, and decides whether to escalate, revise, stop, or roll back.

This is not ordinary iteration. Iteration can repeat the same kind of artifact many times. Progressive Fidelity Increase changes the level or dimension of realism: from conceptual to interactive, from aggregate to detailed, from synthetic to field data, from isolated component to integrated operation, from idealized teaching case to messy real case.

prose_key_components:
- **Fidelity Scale** (`fidelity_scale`): Defines the ordered levels of realism, detail, integration, precision, or operational completeness that the solution can move through. The fidelity scale prevents vague calls to “make it more realistic.” It names what higher fidelity means in this context: richer data, finer resolution, live integration, production constraints, stakeholder-facing polish, regulatory realism, or other concrete dimensions.
- **Core Reference** (`core_reference`): Anchors the fidelity ramp to a baseline model, prototype, process, plan, or explanation whose purpose and limits are already understood. Progressive fidelity should not be a random sequence of increasingly elaborate artifacts. A core reference states what the low-fidelity starting point is meant to preserve as more detail is introduced.
- **Uncertainty Register** (`uncertainty_register`): Records the uncertainties, unknowns, risks, assumptions, or decision questions that justify adding fidelity. The register makes fidelity increases evidence-seeking rather than aesthetic. Each added layer should answer a named uncertainty, reduce a specific risk, or support a decision that cannot be handled at the current fidelity level.
- **Refinement Layer** (`refinement_layer`): Bundles a coherent set of details, constraints, data, interactions, or operational features to be added at one stage. A refinement layer is not every imaginable improvement. It is a bounded increment of fidelity that can be tested as a unit and compared against its cost and complexity burden.
- **Validation Checkpoint** (`validation_checkpoint`): Tests whether the current fidelity level is accurate, useful, safe, or decision-relevant enough to justify continuation or escalation. Checkpoints keep the archetype from becoming a ritualized march toward maximum fidelity. They ask whether the added detail improved prediction, learning, usability, risk control, or decision quality.
- **Escalation Criterion** (`escalation_criterion`): Specifies the evidence, threshold, risk level, stakeholder need, or decision dependency that permits movement to a higher fidelity level. Escalation criteria distinguish progressive fidelity increase from ordinary iteration. Higher fidelity is added because a named condition has been met, not because the team has available time or prefers richer artifacts.
- **Detail Addition Rule** (`detail_addition_rule`): Determines which details enter the next layer and which remain suppressed, deferred, simulated, approximated, or ignored. The rule protects the intervention from uncontrolled realism creep. It links each proposed detail to uncertainty reduction, risk exposure, operational feasibility, stakeholder comprehension, or decision impact.
- **Fidelity Cost Budget** (`fidelity_cost_budget`): Limits the time, cognitive load, implementation effort, data burden, maintenance cost, and validation cost introduced by higher fidelity. Higher fidelity often feels more legitimate, but it is not free. A budget requires each refinement layer to earn its added burden and keeps the artifact usable, maintainable, and auditable.
- **Stop or Defer Rule** (`stop_or_defer_rule`): Defines when the current fidelity is sufficient and further detail should be delayed, cancelled, or moved to a separate investigation. The stop rule is essential because fidelity can always increase in principle. The rule may be based on marginal decision value, diminishing uncertainty reduction, budget exhaustion, safety review, or a stable validation result.
- **Rollback or Simplification Rule** (`rollback_or_simplification_rule`): Removes or downgrades a refinement layer when it adds cost, noise, fragility, or false confidence without improving the target outcome. Progressive fidelity increase should be reversible. A layer that fails validation can be revised, split, postponed, or removed so that the model or prototype does not accumulate unjustified complexity.

prose_common_mechanisms:
Mechanisms implement the archetype in particular domains. They should not be confused with the archetype itself. A high-fidelity prototype, a simulation ladder, or a policy pilot is only an instance of Progressive Fidelity Increase when it includes explicit fidelity levels, checkpoints, escalation criteria, and stop or rollback logic.

- **Low-to-High Fidelity Prototyping** (`low_to_high_fidelity_prototyping`): method. Moves from sketches, mockups, or simple prototypes toward functional and production-like prototypes as questions become sharper. This is the most familiar mechanism, but it is not the whole archetype. The archetype also applies to models, plans, simulations, governance processes, and staged evidence generation.
- **Simulation Refinement Ladder** (`simulation_refinement_ladder`): method. Adds simulation detail in layers, such as finer resolution, stochastic effects, heterogeneity, spatial structure, feedback, or operational constraints. A simulation ladder should preserve comparability across levels so that analysts can tell whether added realism changes conclusions or merely consumes compute and attention.
- **Staged Research Model** (`staged_research_model`): process. Advances from exploratory evidence to stronger methods, richer instruments, larger samples, or closer-to-field conditions as uncertainty narrows. This mechanism supports scientific, UX, policy, and market research. It should not be mistaken for generic research iteration; fidelity dimensions and escalation criteria must be explicit.
- **Progressive Policy Pilot** (`progressive_policy_pilot`): governance_process. Begins with small or simplified pilots and adds population coverage, administrative complexity, legal constraints, or operational realism in stages. This mechanism is useful when a policy cannot safely or credibly jump from concept to full-scale rollout. It requires guardrails so pilot evidence is not overgeneralized.
- **Design Mockup to Production Path** (`design_mockup_to_production_path`): workflow. Moves a design from conceptual, visual, interactive, technical, integrated, and production-ready states through explicit gates. The mechanism prevents teams from polishing before learning or building production systems before the interaction and value assumptions are tested.
- **Coarse-to-Detailed Planning** (`coarse_to_detailed_planning`): planning_method. Starts with rough plans, estimates, or schedules and adds task detail, dependencies, resource constraints, and contingencies as commitment approaches. This mechanism overlaps with Coarse-to-Fine Search when the main issue is exploration of options. It is a fidelity mechanism when the chosen plan representation becomes progressively more operational.
- **Learning Scaffold Sequence** (`learning_scaffold_sequence`): instructional_method. Introduces simplified representations first and adds disciplinary complexity as learners gain competence and misconceptions are exposed. The mechanism implements the archetype in education and training. It must preserve eventual correspondence with the richer domain rather than freezing learners in oversimplified models.
- **Engineering Review Gate** (`engineering_review_gate`): governance_mechanism. Requires technical review before a prototype, model, or design moves to a more integrated or operationally realistic level. Review gates can be helpful but can also become bureaucracy. They instantiate the archetype only when they govern fidelity escalation, validation, and cost.
- **Model Calibration Increment** (`model_calibration_increment`): analytical_method. Adds calibration detail only when model error or decision sensitivity justifies the additional parameter, dataset, or fitting effort. This mechanism helps prevent overfitting by tying calibration richness to validation and decision impact.
- **Digital Twin Maturation** (`digital_twin_maturation`): technical_workflow. Evolves a simple system representation toward live, integrated, sensor-fed, or operationally synchronized fidelity in stages. This is a domain-laden mechanism, not the parent archetype. It belongs here only when the maturation path is governed by explicit fidelity levels and validation checkpoints.

prose_failure_modes:
- **Cosmetic fidelity creep**: caused by The team increases visible polish or procedural detail because it impresses stakeholders, not because it resolves a named uncertainty. Mitigation: Separate fidelity dimensions and require each detail to connect to an uncertainty register or decision criterion.
- **Stuck at low fidelity**: caused by Early artifacts remain cheap and comfortable even after the decision requires more realism. Mitigation: Use escalation criteria tied to risk, decision stakes, and validation gaps.
- **Premature high fidelity**: caused by The team builds production-like detail before validating the core value, behavior, or feasibility assumption. Mitigation: Require a core reference and a validation checkpoint before costly fidelity increases.
- **Fidelity dimension mismatch**: caused by The team raises the wrong kind of fidelity, such as visual polish when behavioral realism is the real uncertainty. Mitigation: Use a fidelity dimension map and choose the dimension that matches the open question.
- **Unvalidated layer accumulation**: caused by Refinement layers are added but not tested, leaving the artifact more complex without being more trustworthy. Mitigation: Make validation checkpoints mandatory and include rollback or simplification rules.
- **False confidence from realism**: caused by High-fidelity detail causes users to assume the model or prototype is accurate, safe, or complete. Mitigation: Document assumptions, scope limits, validation evidence, and unresolved uncertainties at each fidelity level.
- **Incomparable stages**: caused by Each fidelity level uses different scenarios, measures, or purposes, so learning does not accumulate. Mitigation: Maintain a comparability baseline and record what changed between levels.
- **Operational surprise**: caused by Operational, legal, safety, or equity fidelity is deferred too long. Mitigation: Identify critical edge cases and high-stakes constraints that require earlier fidelity escalation.

prose_neighbor_distinctions:
- **Iterative Refinement Loop** (`iterative_refinement_loop`): Iteration repeats improvement cycles; Progressive Fidelity Increase specifically changes fidelity levels in controlled layers and asks whether added detail is justified.
- **Staged Commitment** (`staged_commitment`): Staged Commitment governs when resources or obligations are locked in; Progressive Fidelity Increase governs how representation or implementation fidelity rises. They often combine but are not the same.
- **Versioned Experimentation** (`versioned_experimentation`): Versioned experimentation compares or tests versions; Progressive Fidelity Increase defines a path from lower to higher fidelity and may not require multiple competing versions.
- **Design Prototyping** (`design_prototyping`): Design prototyping is a domain and mechanism family. Progressive Fidelity Increase can use prototypes but also applies to models, simulations, plans, research, policy, and training.
- **Core Model First** (`core_model_first`): Core Model First emphasizes starting from a stable conceptual core. Progressive Fidelity Increase emphasizes how later fidelity layers are added and gated after the core exists.
- **Layered Model Validation** (`layered_model_validation`): Layered Model Validation is the quality-control counterpart that checks whether each added layer improves the model. Progressive Fidelity Increase is the escalation strategy that structures which layers to add and when.
- **Bounded Approximation** (`bounded_approximation`): Bounded Approximation states where a simplified representation is acceptable. Progressive Fidelity Increase defines a sequence for raising fidelity when the approximation is no longer enough.
- **Minimum Sufficient Solution** (`minimum_sufficient_solution`): Minimum Sufficient Solution seeks the least solution that works. Progressive Fidelity Increase may pass through minimum sufficient levels but remains focused on staged fidelity escalation.
- **Coarse-to-Fine Search** (`coarse_to_fine_search`): Coarse-to-Fine Search explores a large option space by refining promising regions. Progressive Fidelity Increase raises the realism or detail of a model, prototype, process, or plan, even when the option is already chosen.
- **Progressive Disclosure** (`progressive_disclosure`): Progressive Disclosure reveals information to users in layers. Progressive Fidelity Increase changes the fidelity of the artifact, model, process, or test itself.

prose_cross_domain_examples:
- **Software product design**: A team begins with wireframes, then clickable prototypes, then instrumented beta releases, and only then a production implementation once each layer has answered its learning question.
- **Engineering simulation**: A bridge design is first tested with simplified load calculations, then medium-resolution simulations, then detailed analysis of joints, fatigue, and construction constraints.
- **Public policy**: A new transit fare policy is tested in a limited pilot, then with operational integrations, then across more rider segments as equity and administrative risks become clearer.
- **Medical device development**: A device concept moves from bench model to simulated-use testing to controlled clinical evaluation to real-world usability studies through staged evidence gates.
- **Education**: Learners begin with a clean model of a concept and progressively add exceptions, noisy data, and realistic cases once comprehension is stable.
- **Strategic planning**: A strategy begins as a high-level scenario map and gradually gains financial detail, operational dependencies, risk contingencies, and execution plans as commitment approaches.

Extended example: A city wants to redesign emergency shelter allocation. A full operational redesign would require legal review, data integration, staff training, public communication, and equity analysis, but the city does not yet know whether its core allocation logic is better than the current process. It starts with a low-fidelity analytical model using simplified demand categories and shelter capacities. The first checkpoint asks whether the logic improves basic matching under representative scenarios. Once that passes, the next refinement layer adds geographic travel constraints and high-priority vulnerability categories. A later layer adds real intake data, staff workflows, and privacy constraints. The escalation criterion for each layer is a named question: does travel time change allocation? do vulnerable groups experience different wait times? can staff execute the workflow without creating bottlenecks? The city stops short of full automation until validation shows that the higher-fidelity model improves outcomes without introducing unacceptable equity or operational risk. This is Progressive Fidelity Increase because fidelity rises in evidence-driven layers rather than moving immediately from concept to full system.

prose_non_examples:
- **A team makes a prototype look finished to attract funding before testing whether users need it.** Visual polish is not tied to validation or uncertainty reduction.
- **A planner updates a schedule every week without changing detail level or validating assumptions.** This is iteration or project management, not progressive fidelity increase.
- **A simulation adds every available variable in one step.** There is no staged fidelity scale, checkpoint, or cost budget.
- **A policy pilot expands despite evidence that the simplified version failed.** Escalation violates the validation checkpoint and is therefore not this archetype.

prose_tradeoffs:
- Lower early cost and faster learning in exchange for explicit management of when simplifications become inadequate.
- More disciplined escalation in exchange for added planning overhead and documentation burden.
- Reduced premature high-fidelity work in exchange for the risk that some realism-sensitive issues appear later.
- Better comparability across stages in exchange for constraints on how freely each layer can change.
- More reversible refinement in exchange for slower movement when stakeholders demand immediate polish or certainty.

prose_invariants_to_preserve:
Preserve the purpose of the representation, the validated lessons from lower-fidelity stages, the explicit assumptions and omissions at each level, and the ability to compare results across stages. Also preserve the distinction between fidelity and truth: a richer representation is not automatically more accurate or safer.

The core invariant is justification. Every fidelity increase should have a reason that can be stated before the work begins and evaluated after the checkpoint.

prose_target_outcomes:
The target outcomes are faster learning, better timing of complexity, lower premature investment, better handoffs, and more trustworthy high-fidelity artifacts. The archetype should help teams learn early with cheap representations while avoiding the trap of using cheap representations for decisions that require realism.

When it works, high-fidelity work arrives neither too early nor too late. It arrives when the next decision needs it and when the prior layer has earned it.

prose_parameter_dimensions:
Important tuning dimensions include the number of fidelity levels, the size of each refinement layer, the cost budget for added detail, the strictness of validation checkpoints, the strength of evidence needed for escalation, the reversibility of each layer, the risk threshold that forces earlier realism, and the fidelity dimension being raised.

A central tuning problem is choosing which kind of fidelity to increase. Visual fidelity, behavioral fidelity, data fidelity, operational fidelity, integration fidelity, legal fidelity, and social fidelity are different. Raising the wrong one can make the artifact look mature while leaving the real uncertainty untouched.

prose_variants_and_near_names:
- **Prototype Fidelity Ramp** (`prototype_fidelity_ramp`): A variant that moves prototypes from sketches or mockups toward functional, integrated, and production-like forms through explicit learning gates. Distinctive feature: The artifact is a prototype and fidelity dimensions include look, feel, behavior, integration, manufacturability, or production readiness.
- **Simulation Refinement Ladder** (`simulation_refinement_ladder`): A variant that increases simulation resolution, realism, heterogeneity, or coupling as model uncertainty and decision stakes justify the cost. Distinctive feature: Fidelity is expressed through simulation structure: resolution, parameters, interactions, stochasticity, data coupling, and operational constraints.
- **Policy Pilot Fidelity Ramp** (`policy_pilot_fidelity_ramp`): A governance variant that adds coverage, administrative realism, legal complexity, and delivery burden to policy pilots in controlled stages. Distinctive feature: Fidelity increases include institutional and population realism, not only technical detail.
- **Learning Scaffold Fidelity** (`learning_scaffold_fidelity`): A learning variant that begins with simplified representations and adds conceptual, procedural, or contextual complexity as learners become ready. Distinctive feature: Fidelity increases are tied to learner readiness and conceptual correspondence with the richer domain.
- **Operational Readiness Fidelity Ramp** (`operational_readiness_fidelity_ramp`): A variant that adds operational constraints, integrations, reliability requirements, staffing, monitoring, and maintenance burden in stages. Distinctive feature: Higher fidelity means closer correspondence to real operations rather than only richer representation.

Near names include fidelity ladder, fidelity ramp, staged fidelity, incremental fidelity, progressive model refinement, high-fidelity prototype, low-fidelity prototype, and simulation fidelity level. The first four point to the parent archetype when they include validation and escalation logic. High- and low-fidelity prototypes and simulation fidelity levels are mechanisms or stages, not standalone archetypes.

Prototype Fidelity Ramp

distinct_from_parent: The parent applies to any model, process, plan, or representation; this variant centers prototype artifacts and design workflow gates.

still_same_parent_because: The core logic remains controlled addition of fidelity layers based on uncertainty, evidence, and escalation criteria.

use_when: The team needs to test assumptions before investing in production-ready design.

use_when: Stakeholders confuse visual polish with behavioral or operational validity.

use_when: Different fidelity dimensions must be raised in a deliberate order.

Fidelity Scale

role: Names prototype fidelity levels.

Validation Checkpoint

role: Tests each prototype level before escalation.

Escalation Criterion

role: Determines when to invest in higher fidelity.

Low-to-High Fidelity Prototyping

mechanism_type: method

Design Mockup to Production Path

mechanism_type: workflow

example_domains:
product design
service design
software interface design
industrial design

domain: Product design

example: A team moves from paper sketches to clickable prototypes to instrumented beta builds only after each level answers its intended question.

domain: Service design

example: A service concept is role-played, then piloted with staff, then integrated into real operations in stages.

failure_modes: Polishing a prototype increases perceived credibility before its core assumption has been validated.

Simulation Refinement Ladder

distinct_from_parent: The parent is cross-domain; this variant names simulation-specific escalation and validation concerns.

still_same_parent_because: Each simulation layer is still added through the same progressive fidelity logic.

use_when: A full simulation is computationally, cognitively, or evidentially premature.

use_when: A simplified simulation is useful but may hide critical interactions at higher fidelity.

use_when: Decision-makers need to know whether added realism changes conclusions.

Comparability Baseline

role: Keeps scenarios comparable across simulation levels.

Validation Checkpoint

role: Tests whether added simulation fidelity changes conclusions.

Fidelity Cost Budget

role: Controls compute, data, and interpretation burden.

example_domains:
engineering simulation
climate modeling
traffic modeling
operations research

domain: Traffic modeling

example: A planner begins with aggregate flows, then adds lane detail and driver heterogeneity only where the simpler model cannot answer the policy question.

domain: Engineering

example: A design team starts with a simplified structural model before moving to high-resolution finite element analysis.

failure_modes: Added simulation realism can create false confidence if data quality and validation do not keep up.

Policy Pilot Fidelity Ramp

distinctive_feature: Fidelity increases include institutional and population realism, not only technical detail.

distinct_from_parent: This variant emphasizes governance, equity, rollout risk, and administrative capacity.

still_same_parent_because: It still adds fidelity only when the pilot has produced evidence that justifies the next layer.

use_when: A full policy rollout would be risky or expensive before implementation assumptions are tested.

use_when: Pilot settings differ from the target scale and need staged translation.

use_when: Stakeholder, equity, or safety concerns require monitoring as fidelity increases.

Critical Edge Case Set

role: Identifies harms or populations that simplified pilots may miss.

Escalation Criterion

role: Defines when to widen or deepen the pilot.

Handoff Artifact

role: Transfers evidence into implementation planning.

example_domains:
public policy
public health
education reform
municipal services

domain: Public health

example: A vaccination reminder program starts in one clinic, then adds multilingual outreach, data integration, and regional operations as evidence accumulates.

domain: Education reform

example: A curriculum change moves from classroom trial to school pilot to district rollout with staged administrative fidelity.

failure_modes: Pilot success can be overgeneralized if higher-fidelity institutional conditions are not tested.

Learning Scaffold Fidelity

distinctive_feature: Fidelity increases are tied to learner readiness and conceptual correspondence with the richer domain.

distinct_from_parent: The parent is not necessarily pedagogical; this variant treats comprehension and transfer of learning as fidelity constraints.

still_same_parent_because: It still increases detail in controlled layers and validates readiness before escalation.

use_when: Learners need an accessible model before confronting the full complexity of a domain.

use_when: An early simplification is useful but must be retired or qualified later.

use_when: Instruction needs to sequence complexity without fossilizing misconceptions.

Stakeholder Readiness Signal

role: Signals when learners are ready for more complexity.

Detail Addition Rule

role: Adds complexity without breaking prior understanding.

Validation Checkpoint

role: Checks comprehension and transfer.

example_domains:
education
professional training
technical documentation
onboarding

example: Students first learn an idealized physics model, then progressively add friction, nonlinear effects, and real measurement error.

domain: Professional training

example: A trainee practices with simplified cases before moving to messy real cases with exceptions and ambiguity.

failure_modes: The simplified model becomes a misconception if later fidelity layers are never introduced.

Operational Readiness Fidelity Ramp

distinctive_feature: Higher fidelity means closer correspondence to real operations rather than only richer representation.

distinct_from_parent: The parent can be analytic or representational; this variant is about operational readiness and deployment realism.

still_same_parent_because: Operational detail is still added through defined layers, checkpoints, and stop rules.

use_when: A design works in concept but has not yet been proven under operational conditions.

use_when: Integration, reliability, support, or compliance fidelity would be costly to build too early.

use_when: The team needs to expose operational constraints without overwhelming early learning.

Fidelity Dimension Map

role: Separates operational fidelity from visual or analytic fidelity.

Handoff Artifact

role: Transfers validated assumptions to operations.

Rollback or Simplification Rule

role: Removes operational detail that fails validation.

example_domains:
software operations
infrastructure
manufacturing
service delivery

domain: Software operations

example: A service moves from local prototype to staging environment to production-like load testing to monitored deployment.

domain: Manufacturing

example: A concept model progresses through bench prototype, pilot line, controlled production run, and full production readiness.

failure_modes: Operational fidelity can arrive too late, revealing constraints after strategic or design commitments are already locked in.

near_names:
Fidelity Ladder
Fidelity Ramp
Staged Fidelity
Incremental Fidelity
Progressive Model Refinement
High-Fidelity Prototype
Low-Fidelity Prototype
Simulation Fidelity Level