Perturbation Testing

type: archetype

source: generated

batch: First Iteration/Batch 17

related_primes: chaos resilience observability feedback uncertainty variability randomization hypothesis_testing reproducibility_replicability margin_of_safety boundedness threshold

slug: perturbation

slug: robustness

slug: chaos

slug: resilience

slug: observability

slug: feedback

slug: uncertainty

slug: variability

slug: randomization

slug: boundedness

slug: threshold

essence_one_line: Introduce small controlled disturbances to learn system sensitivity, robustness, and hidden dependencies.

compression_statement: When a system's response to disturbance is uncertain, apply bounded perturbations to reveal sensitivity, fragility, and adaptation paths before larger disruptions occur.

core_intuition: A system can look stable because it has not been asked the right question yet. Perturbation testing asks a deliberately small, bounded question: what changes when one condition is nudged, stressed, removed, delayed, varied, or challenged? The answer reveals where the system is robust, where it is fragile, what it depends on, and which assumptions deserve redesign.

canonical_formula: bounded disturbance + baseline reference + observation window + sensitivity inference + recovery path + learning loop -> earlier knowledge of fragility and dependency with limited risk

structural_problem: The system appears stable, but its sensitivity to small changes, boundary conditions, failures, assumptions, or local disturbances is unknown.

trigger_conditions: The system, model, process, prototype, or population performs acceptably under ordinary conditions, but its response to variation is uncertain.

trigger_conditions: A small disturbance could plausibly reveal a hidden dependency, nonlinear threshold, brittleness, recovery gap, or false assumption.

trigger_conditions: Waiting for an uncontrolled disturbance would be more expensive, harmful, confusing, or politically costly than running a bounded diagnostic disturbance now.

trigger_conditions: The test can be scoped, observed, stopped, and reversed or repaired if it produces an unexpectedly strong response.

trigger_conditions: The learning target is clear enough to connect a perturbation to a response observation and design update.

trigger_conditions: Stakeholders can distinguish controlled learning from sabotage, manipulation, or reckless disruption.

symptoms: Teams say the system is robust, but evidence comes only from ordinary operating conditions.

symptoms: Plans assume continuity of a supplier, tool, role, data source, habit, channel, or model parameter without knowing what happens if it shifts.

symptoms: A past incident revealed a hidden dependency that had never been tested deliberately.

symptoms: Models or policies produce confident conclusions despite unclear sensitivity to key assumptions.

symptoms: Recovery procedures exist on paper but have not been exercised under even mild disturbance.

symptoms: Small changes sometimes produce surprisingly large effects, but the sensitivity pattern is anecdotal rather than measured.

symptoms: People avoid testing because they fear disruption, leaving the system to be tested only by real crises.

root_tension: The system needs evidence about how it behaves under disturbance, but the act of disturbing it can itself create risk, harm, mistrust, noise, or invalid inference if the test is too large, unobserved, poorly authorized, or disconnected from learning.

anti_signatures: The disturbance cannot be bounded, observed, stopped, or recovered from; crisis response or risk avoidance may be more appropriate.

anti_signatures: The goal is to create resilience capacity or safety margin directly rather than to learn sensitivity; robustness_margin_design or resilience_capacity_building may fit better.

anti_signatures: The test is a broad failure-oriented chaos campaign; chaos_exposure_testing may be the cleaner parent.

anti_signatures: The work only varies assumptions analytically without disturbing a real, simulated, scenario, or decision condition; sensitivity_analysis_protocol may fit better.

anti_signatures: The goal is to compare two full solution options for adoption rather than to probe response to a disturbance; scoped_experimentation may fit better.

anti_signatures: The disturbance is performed without consent, authorization, safeguards, or an ethical basis when people or critical services may be affected.

anti_signatures: The likely result cannot change any assumption, design, control, or decision; the test would be theater rather than learning.

structural_intervention: Select a bounded perturbation, define safe bounds, observe the response, infer sensitivity or dependency, and update design, controls, assumptions, or follow-up tests.

action_logic: Name the uncertainty: sensitivity, robustness, hidden dependency, threshold proximity, recovery behavior, or assumption fragility.

action_logic: Choose the smallest perturbation likely to produce interpretable evidence about that uncertainty.

action_logic: Define safe bounds for magnitude, duration, scope, population, blast radius, reversibility, and stop criteria.

action_logic: Establish a baseline reference or comparison condition before introducing the disturbance.

action_logic: Specify the observation window and response measures, including delayed, indirect, and spillover effects.

action_logic: Introduce the perturbation under authorization and monitoring rather than as an unmanaged surprise.

action_logic: Compare observed response against expected response, noting amplitude, delay, propagation, compensation, thresholds, and recovery quality.

action_logic: Translate the result into a sensitivity estimate, dependency map, updated assumption, revised control, or redesign requirement.

action_logic: Rollback, repair, or support affected parts of the system if the response exceeds acceptable bounds.

action_logic: Queue follow-up probes only after learning from the current perturbation, rather than escalating blindly.

decision_rules: Use the smallest disturbance that can answer the learning question; increase intensity only when prior bounds and observations justify it.

decision_rules: Do not perturb live or human-facing systems unless authorization, notice, ethics, recovery, and harm controls match the stakes.

decision_rules: Prefer simulated, staged, canary, or tabletop perturbations when full-system exposure would be unsafe or uninterpretable.

decision_rules: Separate the perturbation from the response: measure what the system did, not merely what testers intended.

decision_rules: Stop or reduce the perturbation when sentinel metrics indicate unacceptable spread, harm, confusion, instability, or loss of trust.

decision_rules: Treat a surprising nonresponse as a finding too; robustness, insensitivity, masking, or failed instrumentation may all be possible explanations.

decision_rules: Convert findings into system changes before repeating the same kind of test.

target_invariants: The disturbance remains bounded, authorized, and recoverable.

target_invariants: The observation plan is strong enough to make the result interpretable.

target_invariants: Learning value is proportional to risk imposed on people, operations, assets, or trust.

target_invariants: Critical functions and rights are protected unless explicitly and ethically included in a safe test design.

target_invariants: The test preserves enough realism to reveal useful response behavior without becoming uncontrolled disruption.

target_invariants: Findings are connected to concrete updates in design, controls, assumptions, training, or future tests.

expected_outcomes: Earlier discovery of hidden dependencies, brittle assumptions, and fragile recovery paths.

expected_outcomes: Better estimates of sensitivity, tolerance, threshold proximity, and response delay.

expected_outcomes: Improved robustness design, monitoring, fallback planning, and incident preparation.

expected_outcomes: Reduced surprise when real disturbances occur.

expected_outcomes: More credible models and plans because important assumptions have been probed.

expected_outcomes: More disciplined learning culture around uncertainty, rather than avoidance or theatrical testing.

prose_essence:
Perturbation Testing is the pattern of learning from a deliberately small disturbance. The disturbance can be physical, operational, behavioral, analytical, or simulated, but it must be bounded and connected to observation. The core question is not “Can we disrupt the system?” but “What does a controlled disturbance reveal about sensitivity, hidden dependency, threshold behavior, recovery, and robustness?”

This archetype is useful because many systems look stable under normal conditions. A process may work only because an informal person quietly compensates. A model may look decisive only because one assumption has never been varied. A service may seem robust only because a dependency has never been slowed. Perturbation testing makes those hidden conditions visible before uncontrolled events expose them at higher cost.

prose_when_to_use:
Use this archetype when a system, plan, model, prototype, workflow, or behavior pattern appears to function, but its response to variation is unknown. It is especially apt when a small probe can reveal whether the system is fragile, insensitive, overcoupled, near a threshold, or dependent on an unrecognized support.

It should be used only when the perturbation can be scoped, observed, stopped, and learned from. If the disturbance cannot be bounded or reversed, the safer choice is usually analysis, simulation, staged rehearsal, or risk avoidance rather than live perturbation. If the main goal is a broad failure-oriented chaos exercise, the neighboring archetype `chaos_exposure_testing` may be a better fit.

prose_structural_problem:
The structural problem is apparent stability under untested variation. The system has not been asked how it responds when a condition shifts, a dependency degrades, a key assumption changes, a behavioral prompt moves, a load increases, or a failure occurs. Because the response is unknown, planners may overestimate robustness, underestimate coupling, or miss thresholds.

This creates a dangerous knowledge gap: the organization may believe it understands the system because it has seen normal operation, when the relevant evidence would only appear under disturbance. Perturbation testing converts that latent uncertainty into observable response.

prose_intervention_logic:
The intervention begins by naming the uncertainty. The designer then chooses the smallest disturbance likely to create useful evidence. That disturbance is constrained by safe bounds: magnitude, duration, scope, affected population, reversibility, monitoring, and stop authority. A baseline or comparison reference is established before the test.

During the test, the important object is the system response, not the perturbation itself. The response may include amplification, delay, compensation, failure, recovery, nonresponse, or spillover. Afterward, the result is translated into a sensitivity estimate, dependency map, revised assumption, control update, or follow-up probe. Without that learning loop, the pattern collapses into test theater.

prose_key_components:
- **Perturbation Plan** (`perturbation_plan`): Specifies what will be changed, why it is being changed, what response is expected, and what uncertainty is being tested. It keeps the disturbance diagnostic rather than random.
- **Safe Bound** (`safe_bound`): Defines the test limits: magnitude, duration, scope, blast radius, reversibility, and stop criteria. This is the main safeguard against drifting into uncontrolled disruption.
- **Baseline Reference** (`baseline_reference`): Provides a comparison point so the response can be interpreted rather than merely noticed.
- **Observation Window** (`observation_window`): Defines when and where response will be monitored, including delayed and spillover effects.
- **Response Observation** (`response_observation`): Captures what the system actually did under perturbation: amplification, compensation, saturation, degradation, recovery, or no visible change.
- **Sensitivity Estimate** (`sensitivity_estimate`): Converts observed response into an interpretation about fragility, robustness, hidden dependency, or threshold proximity.
- **Rollback or Recovery Path** (`rollback_or_recovery_path`): Provides a way to stop the disturbance, restore the prior condition, and repair harm if the response exceeds safe bounds.
- **Learning Loop** (`learning_loop`): Turns findings into updated assumptions, controls, designs, runbooks, policies, or follow-up tests.

Optional components include an **Authorization Boundary** for approval and accountability, a **Sentinel Metric** for early warning, and a **Follow-up Probe Queue** for sequencing subsequent tests without escalating prematurely.

prose_common_mechanisms:
- **Stress Test** (`stress_test`): Implements the archetype by increasing load, pressure, demand, or adverse conditions within a defined range. It is useful for capacity and boundary questions, but it is only one mechanism.
- **Failure Injection** (`failure_injection`): Implements the archetype by disabling, degrading, delaying, or removing a component to reveal dependencies and recovery behavior.
- **Sensitivity Sweep** (`sensitivity_sweep`): Implements the archetype by varying a parameter across a bounded range to learn which inputs materially change response.
- **Scenario Perturbation** (`scenario_perturbation`): Implements the archetype by changing a condition in a model, tabletop exercise, or scenario and observing how plans or conclusions shift.
- **A/B Nudge Test** (`ab_nudge_test`): Implements the archetype when a small behavioral or interface variation is used to learn response sensitivity, not merely to optimize conversion.
- **Prototype Stress Probe** (`prototype_stress_probe`): Implements the archetype by applying a bounded adverse condition to a prototype before full deployment.
- **Red-Team Probe** (`red_team_probe`): Implements the archetype by using a bounded adversarial challenge to expose weaknesses or blind spots.
- **Canary Perturbation** (`canary_perturbation`): Implements the archetype by limiting the disturbance to a small monitored slice before wider exposure.

These mechanisms should not be confused with the archetype itself. The archetype is the full structure of bounded disturbance, observation, inference, recovery, and learning.

prose_failure_modes:
Common failure modes include unbounded disturbance, uninterpretable results, test theater, hidden harm to participants, overgeneralization, instrumentation blindness, and accidental escalation into chaos exposure. These arise when teams perturb before defining safe bounds, baseline references, observation windows, or learning responsibilities.

The most serious misuse is treating the archetype as permission to break things or manipulate people. Perturbation testing must be governed by proportionality, authorization, recovery, and respect for affected stakeholders.

prose_neighbor_distinctions:
Perturbation Testing is distinct from **Chaos Exposure Testing** because it can be small, diagnostic, and parameter-specific rather than broad, chaotic, or failure-oriented. It is distinct from **Robustness Margin Design** because it discovers where margins may be needed rather than adding the margin itself. It is distinct from **Sensitivity Analysis Protocol** because it introduces or simulates a changed condition and observes response, whereas sensitivity analysis may be purely analytical.

It is also distinct from **Scoped Experimentation**, which may test an intervention or product variant for effectiveness. Perturbation testing specifically asks how a system responds to disturbance, variation, failure, or boundary change. It is distinct from **Instability Dampening**, which is a response pattern used after amplification or oscillation has been discovered.

prose_cross_domain_examples:
In software operations, a team may inject a small delay into a canary environment to see whether retry logic overloads queues. In supply-chain planning, a tabletop perturbation may delay one supplier to reveal substitution gaps. In education, a small change in feedback timing can show whether learners are sensitive to cadence. In policy modeling, changing one compliance assumption can reveal whether a recommendation is robust or fragile.

In organizational coordination, temporarily rerouting one handoff may reveal whether a meeting is redundant, essential, or masking informal work. In product design, a small reminder-timing variation can expose behavioral sensitivity before a full rollout. In engineering, a prototype stress probe can reveal tolerance limits before production scale increases the cost of failure.

prose_non_examples:
Randomly breaking a live service without rollback is not perturbation testing. It lacks safe bounds and responsible learning design. A purely theoretical brainstorming session about possible failures is not perturbation testing unless a condition is changed and a response is observed. A full disaster drill may be resilience training or chaos exposure if the main purpose is broad disruption practice rather than bounded diagnostic sensitivity learning.

A/B testing is not automatically perturbation testing. It becomes part of this archetype only when the variation functions as a bounded probe into system or behavioral response and when findings update assumptions or design responsibly.

prose_tradeoffs:
The central tradeoff is realism versus safety. Highly realistic perturbations reveal more but impose more risk. Simulated or tabletop perturbations are safer but may miss real behavior. Another tradeoff is surprise versus trust: surprise can reveal natural response, but unannounced tests can damage legitimacy or create ethical problems.

There is also a tradeoff between diagnostic focus and systemic spillover. Narrow tests are easier to interpret but may miss broad interactions. Broad tests reveal more connections but can become too noisy, risky, or close to chaos exposure.

prose_invariants_to_preserve:
The disturbance must remain bounded, authorized, observable, and recoverable. The test should protect critical functions, rights, privacy, safety, and trust unless those stakes have been explicitly and ethically included in the design. The observation plan must be good enough to interpret the response, and the learning loop must connect findings to real updates.

The most important invariant is proportionality: the learning value should justify the risk imposed. Perturbation testing is not a license to create unnecessary disturbance. It is a disciplined way to reduce larger future surprise.

prose_target_outcomes:
A successful perturbation test reveals hidden dependencies, brittle assumptions, threshold behavior, weak recovery paths, or areas of genuine robustness. It improves confidence by replacing untested belief with observed response. It can also generate better monitoring, fallback design, runbooks, policy assumptions, training priorities, or next-test sequences.

The best outcome is not dramatic failure. Often the best outcome is a precise, bounded discovery: one dependency is too fragile, one assumption matters more than expected, one fallback works, one alert arrives too late, or one behavioral prompt changes response more than predicted.

prose_parameter_dimensions:
Important tuning dimensions include perturbation size, duration, scope, realism, reversibility, notice level, observation depth, and escalation policy. A small perturbation is safer but may produce ambiguous evidence. A realistic perturbation is more informative but may impose more operational, ethical, or trust risk.

Other parameters include whether the test is live, staged, simulated, or tabletop; whether the affected population is randomized, selected, or protected; whether the response measure is quantitative, qualitative, or mixed; and whether the test probes ordinary operating range, boundary conditions, or failure conditions.

prose_variants_and_near_names:
Recognized variants include **Sensitivity Probe**, **Failure Injection Probe**, **Boundary Condition Probe**, **Behavioral Nudge Test**, and **Adversarial Probe**. These variants differ mainly in what kind of disturbance is introduced and what type of response is being learned.

Near names include controlled perturbation, diagnostic disturbance, robustness testing, sensitivity testing, stress testing, failure injection, red-team probing, and A/B testing. Some of these are mechanisms rather than archetypes. `chaos_engineering` should be treated carefully: it may be a failure-injection mechanism, but broader `chaos_exposure_testing` remains a merge-sensitive neighbor.

Sensitivity Probe

variant_type: subtype

short_definition: A small disturbance designed mainly to estimate how strongly one variable or condition affects system response.

distinctive_feature: The perturbation is chosen for diagnostic resolution around a variable, not for broad disruption exposure.

distinct_from_parent: The parent includes any bounded disturbance used for learning; this variant focuses specifically on response magnitude and sensitivity.

still_same_parent_because: It still uses the parent structure: bounded disturbance, observation, inference, and update.

use_when: The main uncertainty is which inputs matter most.

use_when: The system can tolerate controlled variation in one or more variables.

use_when: The desired output is a sensitivity ranking, response curve clue, or revised assumption.

example_domains:
model validation
operations
policy analysis
education

domain: service operations

example: Slightly increase simulated traffic to learn which queue saturates first.

domain: policy analysis

example: Vary one assumed compliance rate to see whether a recommendation changes.

failure_modes: Confusing a noisy response for true sensitivity.

failure_modes: Testing only easy variables while ignoring high-risk dependencies.

Failure Injection Probe

short_definition: A bounded test that intentionally disables or degrades a specific part to learn dependency and recovery behavior.

distinctive_feature: The perturbation is a named failure or degradation rather than a generic parameter shift.

distinct_from_parent: The parent can use many kinds of disturbances; this variant concentrates on intentionally introduced faults.

still_same_parent_because: The fault is used as a diagnostic probe inside safe bounds, not as an open-ended chaos exposure campaign.

source_primes: perturbation robustness resilience

use_when: The system depends on components, services, actors, suppliers, or assumptions that might fail.

use_when: The likely failure can be safely simulated, isolated, or reversed.

use_when: The goal is to learn recovery behavior before an uncontrolled failure occurs.

example_domains:
software reliability
supply chains
emergency preparedness

domain: software reliability

example: Temporarily block a noncritical dependency in staging to observe retry and fallback behavior.

domain: supply chain planning

example: Simulate one vendor delay to reveal where substitution paths are missing.

failure_modes: Letting the injected fault escape its blast radius.

failure_modes: Testing a failure without a recovery path.

Boundary Condition Probe

short_definition: A bounded disturbance applied near an edge condition to learn whether the system changes regime, saturates, or fails.

distinctive_feature: The probe is placed near a boundary rather than in ordinary operating conditions.

distinct_from_parent: The parent includes central-range probes; this variant specifically tests edges and thresholds.

still_same_parent_because: It remains a controlled disturbance with observation and learning as the central logic.

source_primes: perturbation threshold boundedness

use_when: Performance near limits, thresholds, or edge cases is uncertain.

use_when: The edge can be approached safely in increments.

use_when: The team needs evidence about when ordinary assumptions stop holding.

example_domains:
engineering
medicine operations
education
public services

domain: operations

example: Test a scheduling process with a slightly higher absence rate to see when it breaks.

domain: education

example: Try a shorter feedback interval with one class section to learn whether support demand spikes.

failure_modes: Crossing the boundary rather than probing it.

failure_modes: Missing delayed effects because the observation window is too short.

Behavioral Nudge Test

short_definition: A small change in framing, default, timing, salience, or prompt used to estimate behavioral response.

distinctive_feature: The disturbance is cognitive, communicative, or interface-level rather than physical or operational.

distinct_from_parent: The parent is cross-domain; this variant uses behavioral micro-changes as the perturbation family.

still_same_parent_because: It still relies on bounded disturbance, observation, sensitivity inference, and design update.

use_when: The uncertainty concerns how people respond to a small choice-architecture change.

use_when: The test can be run with consent, fairness, privacy, and reversibility safeguards appropriate to the context.

use_when: The desired result is learning about behavior, not covert manipulation.

example_domains:
digital product design
public services
education
health communication

domain: digital product design

example: Change reminder timing for a small randomized group to see whether completion improves.

example: Test a different feedback prompt to see whether learners revise more accurately.

failure_modes: Treating behavioral sensitivity as permission for manipulation.

failure_modes: Ignoring distributional or fairness effects across groups.

Adversarial Probe

short_definition: A bounded challenge by a red team, reviewer, or adversarial scenario to expose weaknesses in assumptions, defenses, or processes.

distinctive_feature: The perturbation is generated from an adversarial stance rather than from a neutral parameter change.

distinct_from_parent: The parent can be non-adversarial; this variant deliberately uses challenge, opposition, or attack simulation.

still_same_parent_because: The challenge remains bounded and diagnostic rather than a full security or adversarial-governance archetype.

source_primes: perturbation robustness uncertainty

use_when: The system may fail under strategic, adversarial, or skeptical pressure.

use_when: The challenge can be authorized and scoped.

use_when: The output should be actionable vulnerabilities or revised assumptions.

example_domains:
security
policy planning
research review
organizational decision-making

domain: research review

example: Ask a reviewer to perturb key assumptions and note where the conclusion changes.

domain: security

example: Run a scoped red-team probe against a staging workflow.

failure_modes: Adversarial testing turns into blame, theater, or unauthorized attack.

failure_modes: Findings are not translated into design changes.

near_names:
Controlled Perturbation
Perturbation Probe
Robustness Testing
Sensitivity Testing
Stress Testing
Failure Injection
Red-Team Probe
A/B Testing
Chaos Engineering


Perturbative Error Correction

batch: Second Iteration/Batch 03

aliases:
Corrective Perturbation
Micro-Correction Loop
Drift Trimming
Incremental Error Correction
Bounded Course Correction
Maintenance Trim
Local Corrective Adjustment
No-Reset Correction Loop

source_primes: maintenance perturbation feedback

slug: maintenance

slug: homeostasis

slug: controllability

slug: iteration

slug: adaptation

slug: damping

slug: stationarity

slug: calibration

components:
Reference State or Operating Band
Drift and Error Signal
Perturbation Budget
Local Correction Vector
Blast-Radius Boundary
Post-Perturbation Observation Loop
Cumulative Correction Ledger
Escalation or Reset Threshold
Correction Simulator
Canary or Shadow Channel
Rollback Checkpoint
Human Override Gate

mechanisms:
Proportional Trim Adjustment
Bounded Rebalancing Trade
Incremental Hotfix or Patch
Feature Flag or Canary Toggle
Clinical Titration Adjustment
Spacecraft Attitude Trim Pulse
Model Parameter Recalibration Nudge
Workflow Queue Rebalancing
Delta Reconciliation Patch
Corrective Feedback Nudge

essence_one_line: Correct accumulated drift by applying small, bounded perturbations that steer a system back toward its operating band without shutting it down or rebuilding it.

compression_statement: Perturbative Error Correction treats maintenance as a continuous no-reset problem. A system has a reference state or tolerated operating band; drift or error begins to accumulate; a small corrective perturbation is selected, bounded, applied, observed, and logged; and escalation occurs when small corrections no longer restore function or when their cumulative side effects become structural.

core_intuition: Many systems fail not because they suddenly break, but because small deviations accumulate faster than ordinary operation notices or corrects them. A large reset may be unnecessary, expensive, risky, or disruptive. A small correction can restore trajectory while preserving continuity—but only if the correction is targeted, bounded, observed, reversible enough, and stopped before it becomes a string of hidden patches.

canonical_formula: Given reference band R, observed state x_t, deviation e_t = distance(x_t, R), and allowable perturbation budget B, choose a local correction δu such that |δu| ≤ B, expected e_{t+1} < e_t, invariants remain satisfied, side effects are observable, and escalation is triggered if e_t persists, grows, or correction debt exceeds threshold.

structural_problem: A functioning system is drifting away from its intended state through small errors, wear, imbalance, stale parameters, or environmental change. The deviation is not yet severe enough to justify full reset, but ignoring it allows accumulated error to become structural failure.

condition: A system has a known reference state, target allocation, setpoint, service band, or acceptable operating envelope.

diagnostic_use: The correction can be judged against a defined maintenance target rather than subjective preference.

condition: Deviation is measurable or at least observably inferable before catastrophic failure.

diagnostic_use: A drift/error signal can trigger corrective perturbation early enough to matter.

condition: Small interventions can alter the trajectory without requiring shutdown, replacement, or global redesign.

diagnostic_use: The system has enough controllability for a bounded correction to be meaningful.

condition: The cost or risk of full reset is high relative to the present deviation.

diagnostic_use: A no-reset maintenance pattern has practical value.

condition: Repeated minor deviations are likely to accumulate if left untreated.

diagnostic_use: The problem is maintenance under drift, not a one-time isolated error.

condition: The effects of a corrective perturbation can be observed within a useful time horizon.

diagnostic_use: Observation prevents blind tinkering and repeated ineffective adjustments.

symptom: Outputs remain acceptable but are slowly moving toward a tolerance boundary.

interpretation: The system is in early drift and may benefit from a small corrective perturbation.

symptom: Operators repeatedly compensate informally for the same small error.

interpretation: Unlogged micro-corrections are already happening and need to be bounded, measured, and governed.

symptom: A reset would restore function but would also interrupt service, erase context, or impose avoidable cost.

interpretation: No-reset correction may preserve continuity while addressing the immediate deviation.

symptom: Small patches, trades, pulses, or adjustments have previously restored performance, but their cumulative effects are unclear.

interpretation: A correction ledger and escalation threshold are needed.

symptom: A system oscillates between neglect and overreaction.

interpretation: Perturbative correction can create a middle path between doing nothing and resetting everything.

root_tension: The same smallness that makes a correction safe and cheap also makes it easy to trivialize, repeat blindly, or use to postpone necessary structural repair. The archetype balances continuity-preserving correction against the risk of patch accumulation, hidden debt, and delayed redesign.

case: The system has crossed a known safety threshold or failure boundary.

reason: Use safe_mode_operation, emergency response, fail-safe shutdown, or structural repair rather than another perturbative correction.

case: There is no observable reference state, target band, or drift signal.

reason: A small adjustment would be arbitrary tinkering rather than error correction.

case: The proposed correction is irreversible, broad, or poorly bounded.

reason: It is not perturbative in the relevant sense and should be treated as redesign or major intervention.

case: The real problem is to discover system sensitivity rather than correct an existing drift.

reason: Use perturbation_testing or chaos_exposure_testing instead.

case: The task is scheduled upkeep with no detected error or drift.

reason: Use preventive_maintenance_cadence rather than perturbative error correction.

case: The mismatch is a data-state disagreement requiring record reconciliation, not ongoing operational drift.

reason: Use reconciliation_after_drift unless the reconciliation is one mechanism inside the broader correction loop.

structural_intervention: Create a bounded correction loop: specify the reference state, detect drift or accumulated error, choose a small targeted perturbation, constrain its magnitude and propagation, apply it without full reset, observe the resulting state, log cumulative correction debt, and escalate when small corrections stop being safe, effective, or honest.

step: Define the reference state and tolerance band.

logic: Establish what counts as maintained function and which deviations are meaningful enough to correct.

step: Measure or infer the drift/error vector.

logic: Identify magnitude, direction, trend, uncertainty, and suspected causal channel before acting.

step: Select the smallest targeted correction likely to reduce error.

logic: Prefer local leverage over broad disturbance; the correction should be small because it is sufficient, not because the problem is ignored.

step: Set a perturbation budget and blast-radius boundary.

logic: Constrain size, frequency, reversibility, affected population, and side-effect exposure.

step: Apply the correction while preserving operation.

logic: Keep the system inside acceptable service, safety, continuity, or mission constraints.

step: Observe the post-correction response.

logic: Compare actual response with expected response and watch for side effects, oscillation, and hidden coupling.

step: Record cumulative corrections and debt.

logic: Make repeated micro-corrections visible so they do not become ungoverned redesign.

step: Escalate when thresholds are crossed.

logic: Move to repair, redesign, rollback, safe mode, or reset when small corrections are no longer appropriate.

rule: Use perturbative correction only when the target state is clear enough to define success.

reason: Otherwise the intervention cannot distinguish restored function from cosmetic change.

rule: Keep each correction below a predefined magnitude, frequency, and blast-radius limit.

reason: This preserves the perturbative character of the intervention.

rule: Require observation before repeating or compounding a correction.

reason: Blind repetition can cause overcorrection, oscillation, or hidden damage.

rule: Treat cumulative small corrections as evidence of possible structural mismatch.

reason: Maintenance should not become an excuse to defer redesign indefinitely.

rule: Escalate immediately when safety, legality, ethics, or irreversible harm thresholds are implicated.

reason: The no-reset advantage never overrides high-stakes safety constraints.

invariant: Continuous acceptable function

preservation_logic: The correction should not interrupt the core service or mission it is meant to preserve.

invariant: Boundedness of intervention

preservation_logic: Magnitude, propagation, and frequency stay inside the perturbation budget.

invariant: Observability of effect

preservation_logic: The system response is measured or reviewed after each correction.

invariant: Reversibility or compensability

preservation_logic: The correction can be rolled back, compensated, or contained if it misfires.

invariant: Escalation honesty

preservation_logic: Repeated micro-corrections do not hide a need for structural repair or reset.

outcome: Reduced drift and accumulated error

observable_indicator: Deviation from the reference state decreases without broad disruption.

outcome: Longer useful operating continuity

observable_indicator: The system remains functional while minor deviations are corrected early.

outcome: Lower reset and rework burden

observable_indicator: Fewer avoidable full resets, rebuilds, liquidations, or emergency interventions occur.

outcome: Improved maintenance knowledge

observable_indicator: Correction logs reveal recurring drift causes, effective small interventions, and escalation thresholds.

outcome: Safer transition from micro-correction to redesign

observable_indicator: Escalation happens when correction debt or failure signals justify larger intervention.

Control-Trim Error Correction

short_definition: Use bounded control inputs to trim a physical, technical, or operational system back toward its target state.

distinctive_feature: The correction is explicitly vector-like: it has magnitude, direction, actuator, and expected state effect.

distinct_from_parent: The parent covers any bounded corrective perturbation. This variant is the control-systems form with a measurable state and actuator authority.

still_same_parent_because: It retains the same no-reset maintenance logic: small correction, bounded effect, observation, and escalation threshold.

use_when: A measurable state error exists relative to a setpoint or operating band.

use_when: The system can receive small control inputs without mode change or shutdown.

use_when: The effect of a trim can be observed quickly enough to prevent cumulative overcorrection.

example_domains:
spacecraft control
industrial process control
robotics
service operations

domain: spacecraft control

example: Small thruster pulses reduce attitude error while the vehicle remains in mission mode.

example: A team makes a small staffing adjustment to correct queue imbalance before backlog becomes systemic.

failure_modes:
overcorrection oscillation
actuator saturation
unobserved coupled-side-effect

name: Portfolio or Resource Rebalancing Correction

short_definition: Restore a target allocation or resource balance through small reallocations rather than wholesale liquidation or reorganization.

distinctive_feature: The perturbation is a bounded reallocation rather than a physical trim, software patch, or clinical adjustment.

distinct_from_parent: It focuses on distributional drift across resources, capacities, or holdings.

still_same_parent_because: It still uses bounded correction to preserve a functioning system instead of resetting the portfolio or organization.

source_primes: maintenance perturbation

use_when: The system has a target allocation or balance criterion.

use_when: Drift accumulates through market movement, demand shift, usage, or uneven consumption.

use_when: Small reallocations can restore acceptable balance without disrupting core function.

example_domains:
investment portfolios
cloud capacity allocation
staffing and workload management

domain: finance

example: Small trades restore a portfolio to its target allocation after market drift.

example: A manager shifts a small set of cases from one queue to another to restore service balance.

failure_modes:
transaction-cost creep
rebalancing too often
masking a changed strategy need

Clinical or Recovery Micro-Adjustment

short_definition: Make small care, dose, mobility, workload, or support adjustments in response to recovery-state deviations.

distinctive_feature: The perturbation acts inside a living or human-centered recovery window where overcorrection has safety consequences.

distinct_from_parent: It adds biological, psychological, and care-governance constraints to the general correction pattern.

still_same_parent_because: It preserves the same bounded, observed, reversible correction logic.

use_when: The patient, learner, athlete, or worker is already in a recovery or adaptation trajectory.

use_when: A large reset or discontinuity would be harmful or unnecessary.

use_when: Safety monitoring can detect adverse response quickly.

example_domains:
hospital recovery
physical rehabilitation
mental health support
training load management

domain: hospital care

example: A clinician adjusts fluid, medication, or activity level slightly based on recovery indicators.

domain: training

example: A coach reduces load for a short period to correct fatigue drift without abandoning the plan.

failure_modes:
proxy metric overreliance
hidden adverse effects
normal variation treated as pathology

name: Software Hotfix and Configuration Correction

short_definition: Apply a narrow software, configuration, or rule change to correct a defect or drift without a major release or system reset.

distinctive_feature: The correction is delivered as a patchable, reversible technical artifact.

distinct_from_parent: It is the software/configuration form of the broader maintenance pattern.

still_same_parent_because: The governing logic remains bounded correction, not full rewrite or redeployment.

use_when: The fault is localized and can be bounded.

use_when: The system must remain available or disruption must be minimized.

use_when: Rollback, canary, logging, and monitoring are available.

example_domains:
software operations
cybersecurity response
platform governance

domain: software

example: A narrow configuration patch reduces error rate while broader release work continues.

domain: platform operations

example: A feature flag limits an unstable behavior for affected users before full remediation.

failure_modes: temporary patch becoming permanent architecture

Model-Drift Recalibration Nudge

short_definition: Apply small calibration, threshold, prior, or normalization updates to a model whose outputs are drifting.

distinctive_feature: The perturbation targets model calibration rather than the underlying operational process.

distinct_from_parent: It requires additional concern for evaluation data, distribution shift, fairness, and stationarity.

still_same_parent_because: It remains a small, bounded correction to preserve service under drift.

use_when: The model remains mostly valid but calibration has degraded.

use_when: A bounded adjustment can be tested against holdout, shadow, or monitoring data.

use_when: The adjustment does not conceal a deeper stationarity break requiring retraining or model replacement.

example_domains:
machine learning operations
forecasting
risk scoring

domain: forecasting

example: A calibration constant is adjusted after a known sensor bias appears.

domain: risk scoring

example: A threshold is slightly retuned after monitoring shows systematic false positives.

failure_modes:
masking distribution shift
fairness regression
overfitting to recent noise

near_names:
Micro-Correction
Drift Trimming
Incremental Course Correction
Local Error Correction
Maintenance Trim


Phase-Space Mapping

batch: First Iteration/Batch 29

slug: representation

slug: constraint

slug: topology

slug: nonlinearity

slug: optimization

slug: perturbation

slug: scale

components:
State Variable
State-Space Scope
Reachable State Set
State Transition Relation
Trajectory Map
Constraint Boundary
Attractor Region
Intervention Zone
Forbidden State Region
State Observation Proxy
Trajectory Uncertainty Band
Map Update Rule

mechanisms:
State-Space Model
Phase Space Plot
Trajectory Mapping Diagram
Reachability Analysis
Attractor Basin Analysis
Risk Landscape Map
Scenario State Map
Control-State Diagram
Behavioral State Space

essence_one_line: Map possible system states and trajectories so reachable, forbidden, stable, and risky regions become visible.

compression_statement: When a system can occupy many states, map its state space to understand trajectories, constraints, attractors, and intervention points.

core_intuition: People often reason from the current state directly to a desired endpoint, as if the system can jump there. Phase-space mapping changes the frame from isolated states to a landscape: where the system can be, how it can move, what regions are unreachable or unsafe, where it tends to settle, and where interventions can change the path. The map does not solve the system by itself; it makes possible motion intelligible enough for better control, planning, diagnosis, and risk avoidance.

canonical_formula: state_landscape = variables × reachable_states × transitions × constraints × attractors; choose actions by path feasibility, risk region, and intervention leverage rather than endpoint preference alone

structural_problem: Actors reason only about the current state or desired endpoint without understanding the wider set of possible states and paths.

trigger_conditions: A system can occupy multiple states, modes, configurations, levels, health conditions, project conditions, or behavioral patterns.

trigger_conditions: Movement between states is constrained by capacity, timing, law, physics, resources, path dependence, thresholds, or social dynamics.

trigger_conditions: A desired endpoint is known, but the available path, intermediate states, or transition risks are unclear.

trigger_conditions: Some states are stable, sticky, dangerous, forbidden, or hard to escape, and those regions affect intervention choice.

trigger_conditions: Decision makers need to compare paths, not merely compare end states or current metrics.

trigger_conditions: The system repeatedly returns to an unwanted condition, suggesting hidden attractors or missing variables.

symptoms: Plans jump from current state to target state without explaining feasible intermediate transitions.

symptoms: Teams debate what to do next because they lack a shared picture of where the system could go.

symptoms: A solution works only in one state of the system and fails when the system moves into another state.

symptoms: Warnings are missed because the current metric looks acceptable while the trajectory points toward a dangerous region.

symptoms: Interventions are applied at points where they cannot meaningfully alter the path.

symptoms: A project, patient, market, organization, or technical system repeatedly falls back into a familiar failure pattern.

root_tension: Decision makers need to act in a system whose future depends on state, path, constraints, and dynamics, but they usually see only a snapshot, a target, or a small set of named states. The intervention must expand visibility without turning the map into an unbounded, overfit, or falsely precise model.

anti_signatures: The issue is only to name a small set of mutually exclusive statuses and allowed transitions; Explicit State Modeling may be sufficient.

anti_signatures: The decision is a one-step, low-risk choice with no meaningful path dependence or state dynamics.

anti_signatures: The central task is to choose a representation rather than to map a state landscape; use Representation Fit Selection first.

anti_signatures: The central task is pruning a search space of options rather than understanding trajectories through system states.

anti_signatures: The system is too poorly observed to locate even the current state; Observability Instrumentation or State Estimation may be needed first.

anti_signatures: The main intervention is to steer an already mapped system through a control surface; use Control Surface Creation or a steering archetype instead.

structural_intervention: Define state variables, map reachable states, mark constraints and attractors, and identify trajectories and intervention zones.

action_logic: Set the state-space scope: name the system, time horizon, actors, variables, and decision that the map must support.

action_logic: Choose state variables that preserve the dynamics relevant to action while avoiding unnecessary dimensions that make the map unusable.

action_logic: Represent the current state and plausible state regions, including desirable, risky, stable, forbidden, unknown, and transitional regions.

action_logic: Map transition relations: how movement occurs, what triggers it, what controls it, which transitions are reversible, and which require intermediate states.

action_logic: Identify reachable states from current conditions under real constraints, resources, timing, and control limits.

action_logic: Mark constraint boundaries, thresholds, cliffs, bottlenecks, attractor regions, and risk gradients that shape path choice.

action_logic: Trace likely, desired, unsafe, and recovery trajectories through the landscape rather than treating endpoints as directly selectable.

action_logic: Locate intervention zones where an action, control, signal, resource, or design change can redirect trajectory or prevent entry into a forbidden region.

action_logic: Update the map as observations, outcomes, constraints, or system dynamics change.

decision_rules: Use this archetype when state, path, and reachability materially affect what action is possible or safe.

decision_rules: Prefer the smallest state-variable set that preserves the dynamics needed for the decision.

decision_rules: Treat an endpoint as actionable only after a plausible trajectory and transition sequence are identified.

decision_rules: Do not rely on a map that lacks current-state observability or a way to update against evidence.

decision_rules: Escalate when mapped trajectories approach forbidden, irreversible, high-risk, or hard-to-escape regions.

decision_rules: Keep descriptive mapping separate from downstream steering: mapping reveals the landscape; controls change motion through it.

target_invariants: State variables must remain decision-relevant rather than merely available to measure.

target_invariants: Reachable, unreachable, unknown, and forbidden states must not be conflated.

target_invariants: Transition paths must preserve ordering, feasibility, reversibility, and timing constraints.

target_invariants: Constraint boundaries and risk regions must remain explicit when they affect safety, legitimacy, or feasibility.

target_invariants: Attractor or stable regions must be treated as hypotheses subject to validation, not as decorative labels.

target_invariants: The map must support action without pretending to fully predict all future behavior.

expected_outcomes: More realistic path planning from current state to target state.

expected_outcomes: Earlier detection of dangerous, unstable, forbidden, or hard-to-recover regions.

expected_outcomes: Better selection of intervention points because leverage is located in the state landscape.

expected_outcomes: Clearer distinction between desired states, reachable states, and merely imagined states.

expected_outcomes: Improved shared understanding of system dynamics across teams or disciplines.

expected_outcomes: Reduced surprise when systems revert to stable failure modes or cross thresholds.

prose_essence:
Phase-Space Mapping turns a system from a snapshot or target-state story into a landscape of possible conditions and paths. The map asks: what state is the system in now, what states could it enter, what paths connect those states, what boundaries or attractors shape movement, and where can intervention change the trajectory?

The point is not to draw a sophisticated chart. The point is to prevent action from being based on endpoint wishes. A desired state is not useful unless it is reachable from current conditions through feasible transitions. A safe-looking current state may still be dangerous if its trajectory points toward a cliff. A repeated failure may make sense once the map reveals that the system is being pulled back into a sticky attractor region.

prose_when_to_use:
Use Phase-Space Mapping when state, path, and transition matter. It is especially useful when a system can move through several possible conditions; when some states are risky, forbidden, stable, or hard to escape; when decision makers need to know whether a target is reachable; or when interventions keep failing because they are applied at the wrong point in the landscape.

Do not use it simply because a diagram would look elegant. If the problem only needs a finite status list, use explicit state modeling. If the main challenge is choosing the right representational form, use representation fit selection. If the central issue is pruning an option set, use search-space pruning or solution-space bounding.

prose_structural_problem:
The structural problem is that actors reason about a current state and desired endpoint without understanding the wider state landscape. They may assume the system can jump from here to there, or they may choose an intervention that works only in one region of the landscape. They may also miss dangerous trajectories because the current state still looks acceptable.

This problem appears in technical systems, projects, clinical pathways, cybersecurity, organizational change, markets, and public policy. In each case, the system is not just “good” or “bad.” It occupies a position in a structured space, and movement through that space is shaped by constraints, thresholds, timing, resources, feedback, and path dependence.

prose_intervention_logic:
The intervention begins by choosing state variables. These variables define the coordinates of the map, so they should be chosen for decision relevance rather than measurement convenience alone. Next, the current state and plausible state regions are placed in the map. Then transition relations are described: what moves the system from one state to another, which transitions are reversible, which paths require intermediate states, and which paths are blocked.

After that, the map marks reachable states, constraint boundaries, risky or forbidden regions, attractor regions, and intervention zones. The resulting map helps decision makers compare paths rather than merely compare endpoints. The map should be revised when evidence changes, because a stale state-space map can become more dangerous than no map at all.

prose_key_components:
### State Variable

State variables determine what becomes visible in the map. Poorly chosen variables make the landscape look simple while hiding the dynamics that matter for action. Its role in the archetype is: Defines one dimension or coordinate used to describe the system state.

### State-Space Scope

Without scope, the map can balloon into an unbounded universe of possible conditions or shrink so much that important transitions disappear. Its role in the archetype is: Sets the boundary around which system, actors, timescale, and variables are included in the mapped landscape.

### Reachable State Set

Reachability prevents the map from treating every imaginable state as actionable. It separates possible futures from fantasies, impossibilities, and states requiring unavailable transitions. Its role in the archetype is: Identifies states the system can plausibly enter from current conditions under known actions, constraints, and time horizons.

### State Transition Relation

A phase-space map is not just a static catalog of states. Its value comes from understanding movement, path dependence, transition likelihood, and blocked or irreversible transitions. Its role in the archetype is: Describes how movement between states can occur and what events, controls, thresholds, or forces drive those movements.

### Trajectory Map

Trajectory mapping helps actors reason about paths rather than endpoints. It reveals that some attractive endpoints are inaccessible from current conditions without intermediate moves. Its role in the archetype is: Shows possible paths through the state landscape over time, including likely, desired, risky, and forbidden paths.

### Constraint Boundary

Constraint boundaries may come from physics, law, budgets, capacity, social rules, biological limits, or design requirements. They are not merely labels; they change what paths are viable. Its role in the archetype is: Marks limits that separate feasible, forbidden, unsafe, unstable, or institutionally unavailable regions of the state space.

### Attractor Region

Attractor regions explain why some states are sticky and why small interventions may fade while others shift the system into a new basin of behavior. Its role in the archetype is: Identifies regions or patterns toward which the system tends to settle, return, or converge under normal dynamics.

### Intervention Zone

Intervention zones connect the map to action. A map that names states but does not reveal leverage points remains descriptive rather than decision-supportive. Its role in the archetype is: Highlights locations in the mapped landscape where action can change path, avoid risk, cross a boundary, or steer toward a preferred region.

prose_common_mechanisms:
### State-Space Model

State-Space Model is a method that implements part of Phase-Space Mapping. Represents system condition as state variables and transitions, often supporting simulation, estimation, or control. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Phase Space Plot

Phase Space Plot is an artifact that implements part of Phase-Space Mapping. Visualizes selected state variables so regions, paths, cycles, and qualitative dynamics can be inspected. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Trajectory Mapping Diagram

Trajectory Mapping Diagram is a artifact that implements part of Phase-Space Mapping. Depicts plausible paths from current state toward desired, risky, stable, or forbidden regions. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Reachability Analysis

Reachability Analysis is a method that implements part of Phase-Space Mapping. Tests which states can be reached from current conditions under available controls and constraints. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Attractor Basin Analysis

Attractor Basin Analysis is a method that implements part of Phase-Space Mapping. Identifies regions that tend to pull system trajectories toward stable patterns, loops, equilibria, or recurrent behavior. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Risk Landscape Map

Risk Landscape Map is an artifact that implements part of Phase-Space Mapping. Overlays risk intensity across states so safe, fragile, hazardous, and catastrophic regions become visible. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Scenario State Map

Scenario State Map is a method that implements part of Phase-Space Mapping. Maps how different assumptions or futures change reachable states, transition paths, and intervention opportunities. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Control-State Diagram

Control-State Diagram is an artifact that implements part of Phase-Space Mapping. Connects states to permitted controls, triggers, gates, and action policies. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

### Behavioral State Space

Behavioral State Space is a method that implements part of Phase-Space Mapping. Maps behavioral, cognitive, social, or organizational states and transitions when the system is not purely technical. It should not be confused with the archetype itself, because the archetype is the transferable logic of mapping states, reachability, trajectories, boundaries, and intervention zones.

prose_failure_modes:
One common failure mode is variable omission. The map looks coherent, but the omitted variable is what actually controls transition. Another is false reachability: a target is drawn on the map but no feasible path connects it to current conditions. A third is visualization theater, where a polished chart substitutes for transition logic, update rules, and action implications.

Other failure modes include map overfitting, static map illusion, forbidden-region blindness, and attractor mislabeling. The safest mitigation is to treat the map as a living decision-support artifact: explicit assumptions, evidence checks, update rules, and review after surprising transitions.

prose_neighbor_distinctions:
Phase-Space Mapping is distinct from Explicit State Modeling because it emphasizes the landscape of reachable states and trajectories, not merely the existence of named states and transitions. It is distinct from Regime Map Navigation because regime navigation adapts action by named operating regimes and transition boundaries, while phase-space mapping builds the broader state landscape.

It is distinct from Control Surface Creation because it identifies where intervention might matter but does not itself create controls. It is distinct from Attractor Basin Steering because steering changes conditions to move a system toward a desired stable region; mapping identifies the regions and paths. It is distinct from Discrete–Continuous Model Selection because that archetype chooses modeling granularity, while Phase-Space Mapping can use either discrete or continuous representations.

prose_cross_domain_examples:
In clinical care, a team maps stable, deteriorating, critical, and recovering patient states, then defines escalation zones before deterioration becomes irreversible. In project management, a team maps delivery states such as on-track, dependency-blocked, overloaded, scope-unstable, recovering, and failing. In cybersecurity, system exposure, privilege, detection, and containment states are mapped to understand attack and recovery paths.

In organizational change, leaders map adoption, workaround, resistance, temporary compliance, and stable-practice states to explain relapse. In supply-chain planning, inventory, supplier, transportation, and demand states are mapped under disruption scenarios. In public policy, rollout states are mapped across staffing, eligibility, compliance, funding, and continuity so implementation does not assume an impossible jump from legislation to service delivery.

prose_non_examples:
A simple table of statuses is not Phase-Space Mapping unless it includes reachability, transitions, constraints, and intervention implications. A two-by-two quadrant chart is not enough unless it represents meaningful state variables and paths. A mathematical phase-space diagram copied from a technical context is not the archetype unless it supports transferable intervention reasoning.

A fixed target-state vision is not this archetype because it does not show paths. A risk ranking is not this archetype unless risk is mapped across states and trajectories. A simulation is not this archetype if its outputs are never interpreted as a state landscape with intervention zones.

prose_tradeoffs:
The main tradeoff is richness versus usability. A richer map may preserve more dynamics, but it can also overwhelm users. Another tradeoff is fidelity versus abstraction: simplifying the landscape makes it usable, but too much simplification hides thresholds and rare states. There is also a tradeoff between technical precision and shared understanding. A mathematically precise map may not help a cross-functional team unless it can be interpreted and used.

Safety creates another tradeoff. Conservative forbidden regions can prevent harm, but overly broad forbidden regions can block beneficial transitions. Conversely, permissive maps can unlock opportunity while increasing exposure to irreversible or hard-to-recover states.

prose_invariants_to_preserve:
The first invariant is decision relevance: every state variable should matter for action, diagnosis, risk, or control. The second invariant is reachability discipline: desired, imaginable, reachable, unreachable, unknown, and forbidden states must not be conflated. The third invariant is trajectory integrity: the map should preserve ordering, timing, reversibility, and path constraints.

The map should also preserve uncertainty and updateability. It should be clear where boundaries are validated, where they are assumptions, and where observation is weak. In safety-sensitive contexts, forbidden regions and escalation zones must remain visible even when stakeholders prefer a cleaner story.

prose_target_outcomes:
A good phase-space map improves path planning, intervention timing, shared situational understanding, and risk avoidance. It helps teams identify states that are dangerous before they become irreversible. It reveals why some interventions fail because the system is in the wrong region or because the intervention does not change transition dynamics.

The target outcome is not perfect prediction. It is better reasoning about possible motion. The archetype succeeds when decision makers can say which paths are feasible, which states must be avoided, where the system tends to settle, and where action can redirect the trajectory.

prose_parameter_dimensions:
Important tuning dimensions include the number of state variables, the scope of the system boundary, the time horizon, the resolution of state regions, whether the map is discrete, continuous, or hybrid, the confidence assigned to transition relations, and the threshold for marking a state as risky, forbidden, stable, or reachable.

A map with too few variables may hide the dynamic that actually governs movement. A map with too many variables may become impossible to interpret. A short time horizon may be useful for immediate control but blind to slow drift. A long horizon may reveal structural risk but become speculative. The right tuning depends on the decision the map is meant to support.

prose_variants_and_near_names:
Reachable Set Mapping focuses on states that can be reached from the current condition under real constraints. Risk Landscape Mapping overlays consequence, fragility, or danger across the state landscape. Attractor Region Mapping identifies stable, sticky, or recurring regions. Scenario State Mapping compares how different future assumptions change reachable paths and intervention zones.

Near names include state-space mapping, state landscape mapping, trajectory mapping, risk landscape, behavioral state space, clinical state trajectory, state-space model, and phase-space plot. The last two should usually be treated as mechanisms, not standalone archetypes.

Reachable Set Mapping

short_definition: Maps which states are reachable from current conditions under known constraints, controls, and time horizons.

distinctive_feature: The variant emphasizes reachability and feasibility of movement rather than describing the entire landscape equally.

distinct_from_parent: The parent maps possible states and trajectories broadly; reachable set mapping focuses on the subset accessible from a starting condition.

still_same_parent_because: It still uses state variables, transition relations, and constraint boundaries to reason about the state landscape.

source_primes: phase_space constraint controllability

use_when: Decision makers are considering endpoints without knowing whether those endpoints can actually be reached from the current state.

use_when: Controls, resources, legal limits, timing, or physical dynamics restrict the paths available.

use_when: The main decision is whether to pursue a path, redesign constraints, or choose a different target state.

example: A delivery team maps which schedule states remain reachable after a critical dependency slips.

example: A policy team maps which implementation states can be reached before statutory deadlines.

failure_modes: Treating a reachable state as desirable without considering whether its path crosses unsafe or illegitimate regions.

failure_modes: Defining reachability too narrowly and excluding creative paths that could become available by changing constraints.

Risk Landscape Mapping

short_definition: Overlays risk intensity, fragility, or consequence severity across a mapped state space.

distinctive_feature: The variant highlights risk gradients and dangerous regions rather than only reachability or structure.

distinct_from_parent: The parent can map neutral states and paths; this variant colors the landscape by consequence, fragility, and safety margin.

still_same_parent_because: It remains a state-landscape intervention: risk is interpreted relative to locations and paths in the mapped space.

use_when: The system can enter states with materially different danger, fragility, or recovery costs.

use_when: Actors need to know which paths avoid hazardous regions, cliffs, traps, or irreversible losses.

use_when: A simple risk list hides how risk changes by state and trajectory.

domain: cybersecurity

example: A security team maps system states where privilege, exposure, and monitoring gaps combine into high-risk regions.

example: Care teams map patient states that precede rapid deterioration and define escalation zones.

failure_modes: Heat-map aesthetics create false precision when risk is poorly measured.

failure_modes: Risk intensity is mapped without transition likelihood, causing teams to focus on scary but unreachable states.

Attractor Region Mapping

short_definition: Identifies stable, sticky, recurring, or convergent regions in a state landscape.

distinctive_feature: The variant focuses on basins, stability, recurrence, and stickiness rather than all possible paths.

distinct_from_parent: The parent maps the whole landscape; this variant specifically names regions that pull or hold trajectories.

still_same_parent_because: Attractor regions are interpreted through state variables, transitions, boundaries, and trajectories.

source_primes: phase_space convergence equilibrium

use_when: The system repeatedly returns to some states or patterns despite interventions.

use_when: Small changes sometimes disappear while other changes push the system into a new stable pattern.

use_when: A team needs to understand why a behavior, failure mode, equilibrium, or operating pattern persists.

example: A team maps how work keeps returning to an informal workaround even after a new process is announced.

example: A coach maps recurring relapse states and the conditions that pull behavior back toward them.

failure_modes: Assuming every stable-looking region is a true attractor rather than a temporary artifact of missing variables.

failure_modes: Jumping from attractor identification to steering without validating available control surfaces.

Scenario State Mapping

short_definition: Maps how possible future scenarios alter state landscapes, reachable paths, and intervention zones.

distinctive_feature: The variant treats the state map as conditional on scenario assumptions.

distinct_from_parent: The parent can map one operating landscape; this variant compares several landscapes across plausible futures.

still_same_parent_because: Each scenario is still analyzed by state variables, reachable states, trajectories, constraints, and intervention points.

use_when: Future conditions are uncertain enough that one state landscape would mislead decisions.

use_when: Different scenarios change which states are reachable, safe, stable, or forbidden.

use_when: Plans need robust path choices rather than a single predicted trajectory.

example: A planner maps inventory and supplier states under normal, disrupted, and recovery scenarios.

example: A city maps flood-response states under several rainfall and infrastructure-failure scenarios.

failure_modes: Creating scenario maps that are vivid but not connected to current-state transitions.

failure_modes: Multiplying scenarios until the map becomes too complex to guide action.

near_names:
State-Space Mapping
Phase Space Plot
State-Space Model
Trajectory Mapping
Risk Landscape
Behavioral State Space
Clinical State Trajectory


Phase-Specific Intervention

batch: First Iteration/Batch 20/Wave 2

aliases:
Phase-Matched Response
Stage-Specific Policy
State-Specific Response
Regime-Specific Action
Lifecycle-Stage Intervention
Stage-Appropriate Intervention
Contextual Phase Policy
Phase-Based Treatment
Stage-Guided Response

related_primes: state_and_state_transition threshold observability boundary contextual_mode_switching adaptation feedback

slug: stratification

slug: observability

slug: boundary

slug: feedback

components:
Phase Classifier
Phase Condition Model
Action by Phase
Phase Contraindication Map
Transition Boundary Indicator
Phase Handoff Rule
Adaptation Rule
Phase Feedback Monitor
Exception Review Path
Phase Transition Memory
Phase Playbook
Mixed-Phase Segmentation
Equity and Access Check
Phase Exit Criteria

mechanisms:
Lifecycle-Stage Policy
Disease-Stage Treatment Protocol
Incident Phase Playbook
Product Lifecycle Strategy
Market Regime Strategy
Ecological Phase Management
Education Scaffolding by Stage
Maturity Model Guidance
Escalation/De-escalation Matrix
Stage-Specific Communication Plan

essence_one_line: Use different interventions in different phases because each regime responds differently.

compression_statement: When a system's response changes by phase, tailor interventions to the current phase rather than applying one uniform policy.

core_intuition: The same action can help, fail, or harm depending on the phase of the system. Phase-Specific Intervention first identifies the current phase, then chooses actions, constraints, supports, communication, and monitoring that fit that phase while watching for transition into the next one.

canonical_formula: phase_classifier + phase_condition_model + action_by_phase + contraindication_map + transition_indicator + handoff_rule + feedback_monitor → phase-matched intervention with lower wrong-phase harm

structural_problem: An intervention effective in one phase is ineffective or harmful in another phase, but the system is being treated as if one uniform action applies across all phases.

trigger_conditions: The system has distinguishable phases, stages, regimes, maturity levels, lifecycle periods, disease stages, crisis phases, or developmental states.

trigger_conditions: The causal conditions, risks, constraints, sensitivities, available levers, or stakeholder needs change materially by phase.

trigger_conditions: There is enough observability to classify the current phase or at least reason about phase uncertainty.

trigger_conditions: A uniform intervention would over-treat, under-treat, mistime, destabilize, confuse, or delegitimize the response.

trigger_conditions: Actors must decide what to do now, not only how to represent the phase diagram or state model.

trigger_conditions: The system may be approaching a phase boundary where action rules need to change.

trigger_conditions: The intervention needs to preserve continuity across phase transitions while changing enough to fit the new phase.

symptoms: A policy that helped during launch becomes wasteful, controlling, or risky during maturity.

symptoms: Early crisis actions continue after stabilization, preventing recovery and learning.

symptoms: A mature system receives novice scaffolding, while an immature system is asked to use advanced practices it cannot yet support.

symptoms: Treatment, coaching, regulation, investment, or communication arrives too early or too late because phase is not diagnosed.

symptoms: People argue over the correct response because they are implicitly assuming different current phases.

symptoms: A single playbook is stretched across detection, containment, stabilization, recovery, and prevention despite different objectives.

symptoms: Phase transition signals are ignored, so the intervention remains locked to an obsolete state.

symptoms: Subgroups in different phases receive a uniform aggregate response that fits none of them well.

root_tension: The system needs consistent rules and coordination, but its behavior, vulnerabilities, and useful levers change by phase; over-standardization causes wrong-phase action, while over-fragmentation causes confusion, unfairness, and loss of continuity.

anti_signatures: The main task is to map regimes and transition boundaries, not to choose phase-matched actions; Regime Map Navigation or Transition Boundary Monitoring may be a better fit.

anti_signatures: The main task is deciding whether preconditions are sufficient to cross a threshold; Transition Readiness Assessment is a better fit.

anti_signatures: The main task is deliberately moving the whole system from one regime to another; Controlled Phase Transition is a better fit.

anti_signatures: The main task is finding a safe dose or operating range; Therapeutic Window Management may be a better fit.

anti_signatures: The categories are stable population strata rather than phases that change over time or system state; Stratified Treatment may be a better neighbor.

anti_signatures: There is no meaningful difference in response by phase; phase labels would add bureaucracy without improving decisions.

anti_signatures: The phase model is too unreliable, stigmatizing, or politically loaded to guide action without safeguards and review.

anti_signatures: The candidate is only a phase diagram, stage table, checklist, or maturity label with no intervention selection logic.

structural_intervention: Classify current phase, select phase-specific action, and adjust when transition indicators change.

action_logic: Define the phases that matter for intervention, not just for description: each phase must imply different useful actions, constraints, risks, or contraindications.

action_logic: Build a phase condition model that explains why the system responds differently in each phase.

action_logic: Classify the current phase using observable criteria, expert judgment, measurements, history, or agreed indicators, while recording uncertainty.

action_logic: Map each phase to appropriate actions, support levels, communication norms, safeguards, and actions to avoid.

action_logic: Include contraindications for interventions that are useful in some phases but harmful, premature, or illegitimate in others.

action_logic: Monitor transition indicators that show when the system is moving toward another phase and the intervention set should change.

action_logic: Define handoff and exit rules so responsibility, authority, resources, and communications shift cleanly across phases.

action_logic: Use feedback to update phase classification, tune action intensity, detect adverse effects, and revise the phase model after experience.

action_logic: Provide an exception path for ambiguous, mixed-phase, or contested cases instead of forcing every case into a rigid stage label.

decision_rules: If an action has different effects across phases, never evaluate it without first specifying the phase in which it will be applied.

decision_rules: If phase evidence is ambiguous, prefer reversible, information-gathering, or low-regret interventions until phase confidence improves.

decision_rules: If a phase label changes what people are allowed to receive, require transparent criteria, appeal or review, and monitoring for unfair exclusion.

decision_rules: If the system is near a phase boundary, prepare the next-phase handoff before fully switching actions.

decision_rules: If subgroups occupy different phases, segment the intervention rather than imposing an aggregate phase response, unless segmentation would create more harm than mismatch.

decision_rules: If a phase-specific action continues after its phase has passed, trigger de-escalation, exit review, or conversion into a new phase-appropriate response.

decision_rules: If phase categories become identity labels or status rankings, reconnect them to observable conditions and action consequences.

decision_rules: If the phase model cannot explain why actions differ, treat it as a descriptive taxonomy rather than an intervention guide.

target_invariants: Interventions remain matched to current phase conditions rather than to historical habit, generic best practice, or political convenience.

target_invariants: Phase categories are actionable, observable enough, and tied to causal differences in system response.

target_invariants: Each phase includes not only what to do, but what to avoid and when to hand off.

target_invariants: Transition between phases is monitored and does not leave actors trapped in obsolete response modes.

target_invariants: Phase labels do not become stigmatizing, permanent, opaque, or unfair gatekeeping devices.

target_invariants: Exception handling preserves judgment in mixed, ambiguous, or contested cases.

target_invariants: Feedback revises both the action map and the phase model when results contradict assumptions.

expected_outcomes: Fewer harmful or ineffective wrong-phase interventions.

expected_outcomes: Clearer alignment between current system conditions and selected actions.

expected_outcomes: Smoother handoffs across lifecycle, crisis, clinical, organizational, or ecological phases.

expected_outcomes: Better timing of escalation, de-escalation, support, constraint, investment, or communication.

expected_outcomes: Reduced over-treatment of stable phases and under-treatment of vulnerable phases.

expected_outcomes: More accountable use of stage labels because each label has explicit criteria, actions, and review paths.

expected_outcomes: Improved learning across repeated phase transitions because feedback updates the model.

prose_essence:
Phase-Specific Intervention is the pattern of changing the intervention because the system is in a different phase. It starts from the premise that a system may look like one object while behaving like several different systems over time: launch is not maturity, acute crisis is not recovery, early learning is not expert performance, and ecological establishment is not succession. The archetype asks: *what phase are we in, why does that phase respond differently, what action fits this phase, and when must the response change?*

The core move is not merely to draw a phase diagram. The core move is to bind phase diagnosis to action selection, contraindications, handoffs, and feedback.

prose_when_to_use:
Use this archetype when a uniform response is creating wrong-time or wrong-phase harm. It is especially relevant when phases have different objectives, sensitivities, available levers, stakeholder needs, or transition risks. It works best when the system can classify its current phase with enough confidence, monitor when that classification changes, and explain why different phases deserve different interventions.

It is useful in clinical staging, incident response, product lifecycle management, organizational maturity, ecological restoration, public-policy rollout, education, and behavior-change support. In each case, the same generic action may be helpful in one phase and damaging in another.

prose_structural_problem:
The structural problem is phase mismatch. Actors apply one rule across a system whose behavior changes by phase. The result may be premature escalation, delayed support, stale emergency mode, advanced practices imposed before prerequisites exist, or late-stage maintenance applied during early experimentation.

The deeper tension is that systems need coordination and consistency, but phase-sensitive systems also need differentiated action. Too much uniformity produces wrong-phase interventions; too much differentiation produces complexity, unfairness, and fragmentation.

prose_intervention_logic:
The intervention begins by defining phases only where phase differences change action. It then builds a causal phase condition model, classifies the current phase, maps actions and contraindications by phase, monitors transition indicators, and updates the response when the system enters a new phase.

A strong implementation also defines handoff rules. When a crisis moves from containment to recovery, or a product moves from growth to maturity, authority, communication, resources, and success criteria often need to change. Feedback then revises both the phase classification and the action map.

prose_key_components:
- **Phase Classifier:** Determines which phase, stage, regime, or operating state the system is currently in before action is selected.
- **Phase Condition Model:** Explains why the system responds differently by phase, so phase labels are causally meaningful rather than cosmetic.
- **Action by Phase:** Maps each recognized phase to appropriate actions, supports, constraints, and communication rules.
- **Phase Contraindication Map:** Identifies actions that are useful in one phase but harmful, premature, or illegitimate in another.
- **Transition Boundary Indicator:** Tracks signs that the system is crossing into another phase and the action set should change.
- **Phase Handoff Rule:** Defines how authority, responsibility, resources, or procedures move between phase-specific responses.
- **Adaptation Rule:** Handles uncertainty, mixed phases, and contested phase diagnosis without forcing rigid categorization.
- **Phase Feedback Monitor:** Tests whether the current phase-specific intervention is working and whether the phase classification remains valid.
- **Exception Review Path:** Allows review or override when a case does not fit the normal phase model.
- **Phase Transition Memory:** Captures what worked across phases so future phase rules can improve.

prose_common_mechanisms:
Mechanisms implement the archetype; they are not the archetype itself. A clinical staging protocol, crisis playbook, lifecycle policy, or maturity model becomes an implementation of Phase-Specific Intervention only when it connects phase diagnosis to different actions, contraindications, handoffs, monitoring, and revision.

Common mechanism families include lifecycle-stage policies, disease-stage treatment protocols, incident phase playbooks, product lifecycle strategies, market regime strategies, ecological phase management, education scaffolding by stage, maturity model guidance, escalation/de-escalation matrices, and stage-specific communication plans.

prose_failure_modes: Common failure modes include wrong-phase classification, stage-label bureaucracy, premature escalation or de-escalation, stale playbooks, over-fragmentation, aggregate phase mismatch, and gatekeeping by phase label. These failures are mitigated by clear criteria, contraindication maps, feedback monitors, transition indicators, exception review, and equity checks.

prose_neighbor_distinctions: This archetype is distinct from **Regime Map Navigation**, which builds and navigates the map of operating regimes. Phase-Specific Intervention uses a phase diagnosis to choose the right action. It is distinct from **Transition Readiness Assessment**, which decides whether conditions are sufficient to cross a threshold. It is distinct from **Controlled Phase Transition**, which deliberately moves the system between phases. It is distinct from **Therapeutic Window Management**, which manages safe ranges of intensity, and from **Stratified Treatment**, which usually differentiates response by stable subgroup characteristics rather than changing phase.

prose_cross_domain_examples: In clinical care, treatment changes across acute, stabilization, rehabilitation, and maintenance phases. In incident response, detection, containment, recovery, and learning require different actions. In product management, launch, growth, maturity, and sunset require different investment and communication. In ecological restoration, intervention changes across colonization, establishment, succession, and disturbance recovery. In education, support changes as learners move from novice dependence to independent performance.

prose_non_examples: A phase diagram that does not alter decisions is not this archetype. A readiness checklist that only says proceed or delay is not this archetype unless it also maps actions by current phase. A universal safety rule that must apply identically in every phase is not this archetype. A maturity label used mainly for ranking, stigma, or exclusion is misuse, not Phase-Specific Intervention.

prose_tradeoffs: The main tradeoff is fit versus simplicity. Phase-specific rules improve intervention fit but increase operational complexity. Precision can become brittleness when classification is uncertain. Segmentation can improve fairness when groups are truly in different phases, but it can also produce opaque or inequitable treatment if criteria are poor.

prose_invariants_to_preserve: The intervention should preserve actionable phase definitions, transparent criteria, reviewability, phase-appropriate support, continuity across handoffs, feedback-driven revision, and protection against unfair gatekeeping. Phase labels should remain tools for better intervention, not status labels or permanent identities.

prose_target_outcomes: The target outcomes are fewer wrong-phase interventions, better timing of support or constraint, clearer handoffs, reduced over-treatment and under-treatment, more accountable stage-based decisions, and improved learning across repeated phase transitions.

prose_parameter_dimensions: Important tuning dimensions include phase granularity, classification confidence, phase transition thresholds, response intensity by phase, degree of local adaptation, handoff timing, exception authority, review cadence, and tolerance for mixed-phase segmentation. Too few phases create mismatch; too many phases create bureaucracy and coordination failure.

prose_variants_and_near_names: Recognized variants include lifecycle phase intervention, crisis phase response, capability maturity intervention, and mixed-phase targeting. Near names include phase-matched response, state-specific response, stage-specific policy, regime-specific action, and stage-of-change matching. These names should not multiply into separate archetypes unless they introduce stable components, failure modes, and neighbor distinctions that the parent cannot cover.

Lifecycle Phase Intervention

short_definition: Tailor interventions to predictable lifecycle phases such as launch, growth, maturity, decline, renewal, or sunset.

distinctive_feature: The phase sequence is usually directional and recurring across similar systems.

distinct_from_parent: This variant emphasizes lifecycle timing, while the parent includes any phase-dependent response, including crisis, clinical, ecological, and market phases.

still_same_parent_because: The intervention logic remains phase diagnosis plus phase-matched action selection.

use_when: The system progresses through recognizable lifecycle phases.

use_when: The appropriate support, constraint, investment, or communication changes as the lifecycle phase changes.

use_when: The main risk is applying early-stage or late-stage actions at the wrong time.

example_domains:
product management
organizational development
education
public programs

domain: product management

example: A mature product receives reliability and migration investment rather than startup-style feature expansion.

domain: public programs

example: A pilot program receives learning-oriented evaluation, while a scaled program receives accountability and operations controls.

failure_modes: Treating lifecycle stages as inevitable and ignoring actual phase evidence.

Crisis Phase Response

short_definition: Use different interventions in detection, escalation, containment, stabilization, recovery, and learning phases of a crisis.

distinctive_feature: Response objectives change quickly and wrong-phase action can prolong or amplify the crisis.

distinct_from_parent: This variant focuses on crisis time structure and operational handoff rather than all phase-dependent systems.

still_same_parent_because: It still uses phase diagnosis, phase-matched action, transition indicators, and feedback.

use_when: The system is moving through a crisis or incident with changing objectives.

use_when: Actions appropriate in active containment would be harmful in recovery or learning phases.

use_when: Authority, communication, or resource allocation must shift as the crisis phase changes.

example_domains:
incident response
public health
organizational crisis
cybersecurity

example: Containment limits spread, while recovery restores service and post-incident learning revises controls.

domain: public health

example: An outbreak response shifts from detection to containment to vaccination or reopening guidance as phase evidence changes.

failure_modes: Staying in emergency mode after the stabilization phase has begun.

Capability Maturity Intervention

short_definition: Recommend different practices according to capability maturity rather than prescribing advanced practices to immature systems.

distinctive_feature: The phase reflects capability readiness, not just calendar time or external system state.

distinct_from_parent: It is a readiness- and maturity-oriented variant of phase-specific intervention.

still_same_parent_because: The core decision remains selecting action by diagnosed stage or phase.

source_primes: stratification adaptation

use_when: Organizations, learners, teams, or infrastructures have different capability stages.

use_when: Advanced interventions fail when prerequisites are absent.

use_when: A development path should sequence practices without treating every case as identical.

example_domains:
organizational change
security programs
learning design
operations maturity

example: A basic program receives asset inventory and patch discipline before advanced zero-trust automation.

example: Novices receive structured prompts before being asked to perform open-ended expert tasks.

failure_modes: Using maturity labels as status hierarchy rather than actionable capability diagnosis.

Mixed-Phase Targeting

short_definition: Apply different phase-specific interventions to subgroups or regions that occupy different phases simultaneously.

distinctive_feature: The system is not in one phase; the intervention must be segmented by current phase.

distinct_from_parent: The parent may assume a single current phase; this variant explicitly manages simultaneous phase heterogeneity.

still_same_parent_because: It still selects actions by phase, but does so across segments.

source_primes: stratification observability

use_when: The aggregate system hides phase differences among subgroups, regions, cohorts, assets, or cases.

use_when: A uniform policy would over-treat one subgroup and under-treat another.

use_when: Segmentation can be done without unacceptable complexity or inequity.

example_domains:
public health
market operations
education
ecological restoration

example: Different regions receive containment, mitigation, or recovery guidance according to local outbreak phase.

example: Learners in the same class receive stage-matched supports rather than one uniform assignment.

failure_modes: Segmenting so finely that coordination, fairness, or communication collapses.

near_names:
State-Specific Response
Stage-Specific Policy
Regime-Specific Action
Phase-Matched Response
Stage-of-Change Matching