Interleaved Discrimination Practice

canonical_family: Learning Sequence & Discriminative Practice Design

source_primes: interleaving contrast transfer_of_learning diversity scheduling cognitive_load

slug: interleaving

slug: contrast

slug: diversity

slug: scheduling

slug: multiplexing

slug: decomposition

slug: feedback

slug: metacognition

slug: classification

slug: comparison

slug: juxtaposition

slug: attention

slug: order

components:
Discrimination Target Set
Contrast Dimension Map
Interleaving Schedule
Retrieval or Performance Prompt
Comparison Feedback Loop
Load and Scaffold Boundary
Blocked-to-Interleaved Transition Rule
Delayed Retention and Transfer Probe
Adaptive Item Difficulty Balance
Near-Miss Case Bank
Domain Cue Suppression Rule
Metacognitive Confusion Log

mechanisms:
Mixed Problem Set
Shuffled Practice Deck
Near-Miss Case Rotation
Interleaved Repertoire Practice
Adaptive Interleaving Scheduler
Mixed Diagnostic Quiz
Contrastive Example Sequence
Alternating Context Drill

essence_one_line: Mix related practice targets in a deliberate sequence so the learner must choose, recall, classify, or perform under discrimination pressure, improving durable retention and transfer beyond blocked fluency.

compression_statement: When learners can succeed while a topic, method, category, or performance context is pre-announced, but fail when targets are mixed, decompose the target space into confusable classes, identify the contrast dimensions, alternate targets through a bounded interleaving schedule, require active attempts before feedback, and evaluate delayed retention and transfer rather than immediate ease alone.

core_intuition: Blocked practice can feel efficient because the learner knows what kind of problem, piece, category, or move is coming next. That ease may be a cue from the block rather than genuine discrimination. Interleaving removes the advance label. By moving among related targets, the learner has to ask: what is this, which rule applies, what makes it different from the last one, and can I retrieve it after a context shift? The added difficulty is useful only when it points attention toward real distinctions rather than merely increasing chaos.

canonical_formula: target_set + contrast_dimensions + active_attempt + bounded_mixed_sequence + feedback_on_confusions + delayed_retention_probe -> interleaved_discrimination_practice

structural_problem: Practice is organized in homogeneous blocks that make performance look strong while hiding weak discrimination, brittle retrieval, and poor transfer. Learners or performers improve within a local run because the surrounding context tells them what kind of action is expected. When items are later mixed, delayed, or embedded in realistic conditions, they choose the wrong method, confuse near categories, fail to retrieve, or cannot adapt the skill outside the block.

trigger_conditions: Learners perform well when one topic or procedure is announced but struggle when similar targets are mixed.

trigger_conditions: The real environment requires selecting the right category, method, diagnosis, movement, interpretation, or response without a label.

trigger_conditions: Multiple targets are similar enough that blocked practice lets shallow cues or repetition effects substitute for discrimination.

trigger_conditions: Retention after a delay matters more than immediate speed at the end of a single practice block.

trigger_conditions: A training system, teacher, coach, or tutor has enough item variety to sequence related targets deliberately.

trigger_conditions: A curriculum or practice routine overuses topic blocks, chapters, songs, drills, or job types that do not resemble later use conditions.

trigger_conditions: Computerized practice, flashcard, simulation, or scheduling systems need to mix items while controlling load, coverage, and feedback.

symptoms: High immediate accuracy within a block but poor mixed review or cumulative assessment performance.

symptoms: Learners ask which formula, method, diagnosis, or rule to use before attempting the item.

symptoms: Errors cluster around near-miss categories or look-alike examples.

symptoms: Practice feels fluent, but delayed recall, transfer, or performance under context shifts is weak.

symptoms: The learner can repeat a passage, routine, or procedure after warmup but cannot enter it cleanly from another task.

symptoms: Feedback reports correctness but does not explain which contrast dimension was missed.

symptoms: A mixed session becomes overwhelming because too many categories are interleaved before foundational fluency exists.

symptoms: A scheduler randomizes items without guaranteeing target coverage or preserving useful contrast.

root_tension: Practice must balance fluency-building with discrimination-building. Blocking reduces cognitive load and supports initial acquisition, but it also supplies hidden contextual cues. Interleaving increases difficulty and may slow immediate performance, but it forces target selection and comparison. The archetype manages the tension between short-term ease and long-term flexible retrieval.

anti_signatures: The targets are unrelated, and mixing them would only create attention fragmentation without meaningful discrimination.

anti_signatures: Learners have not yet acquired minimal recognition or execution ability for each target; use scaffolding or blocked introduction first.

anti_signatures: The primary problem is forgetting over time rather than confusion among targets; use retrieval_spaced_reinforcement unless interleaving is also central.

anti_signatures: The primary problem is realistic context fidelity; use authentic_practice_environment.

anti_signatures: The primary problem is transferring a known structure across contexts; use transfer_scaffolding.

anti_signatures: The primary problem is operations/resource scheduling rather than learning or discrimination; use adaptive_scheduling, work_in_progress_limiting, or a scheduling archetype.

anti_signatures: The system is sharing one channel among many streams without a practice/learning objective; route to multiplexing or a technical concurrency pattern.

structural_intervention: Replace or supplement long homogeneous practice blocks with bounded, contrast-aware mixed sequences in which learners actively choose, recall, classify, diagnose, solve, or perform among related targets, then use feedback and delayed probes to tune the sequence.

action_logic: Identify targets that must be distinguished in later use, not just topics that happen to belong to the same course or domain.

action_logic: Decompose each target into its discriminating cues, prerequisite fluency, common confusions, and typical surface distractions.

action_logic: Introduce or preserve enough blocked/scaffolded practice for novices to form an initial representation.

action_logic: Create an interleaving schedule that alternates related targets while controlling coverage, difficulty, spacing, and cognitive load.

action_logic: Require active retrieval, classification, selection, production, diagnosis, or performance before giving answers or examples.

action_logic: After each attempt, connect feedback to the relevant contrast dimension and record confusion pairs.

action_logic: Adjust the mixture when overload, boredom, shallow cue use, or systematic confusion appears.

action_logic: Evaluate success with delayed, mixed, and transfer-oriented probes rather than immediate blocked-session performance alone.

decision_rules: Interleave targets when the learner has enough baseline fluency to benefit from contrast but still confuses nearby categories.

decision_rules: Increase mixture when blocked performance is high but mixed or delayed performance remains weak.

decision_rules: Decrease mixture, add scaffolds, or temporarily re-block when error rates show overload rather than productive discrimination.

decision_rules: Prefer near-miss alternation when the main goal is category boundary learning; prefer broader variety when the main goal is transfer across surface forms.

decision_rules: Do not count a random sequence as successful unless target coverage, contrast dimensions, and delayed outcomes are visible.

decision_rules: Treat lower immediate practice scores as acceptable only if delayed retention, category choice, or transfer improves.

target_invariants: The mixed sequence must preserve deliberate target coverage, not merely randomness.

target_invariants: Each item must require the intended discrimination or retrieval act before feedback leaks the category.

target_invariants: Feedback must identify why one target differs from nearby alternatives.

target_invariants: Cognitive load must remain high enough to force choice but low enough for learning.

target_invariants: Assessment must include delayed or mixed probes because immediate blocked fluency is not the main outcome.

target_invariants: The design must not confuse interleaving with multitasking, context switching for its own sake, or generic scheduling.

expected_outcomes: Better discrimination among similar categories, methods, cases, signals, or performance tasks.

expected_outcomes: More durable retention than purely blocked practice when delayed review or use matters.

expected_outcomes: Improved transfer to mixed, realistic, or unannounced contexts.

expected_outcomes: Reduced dependence on superficial topic labels, chapter boundaries, or practice-order cues.

expected_outcomes: Better diagnosis of which targets are confused, enabling targeted re-teaching or reblocking.

expected_outcomes: More robust performance when moving among tasks, pieces, situations, or problem types.

prose_tradeoffs: Interleaving may slow immediate performance. That can be a feature when the struggle is productive, but a failure when it reflects overload. It may also frustrate learners who are accustomed to blocked fluency. Designers should explain why mixed practice feels harder and should support learners with feedback and staged transitions.

Mixed Problem Practice

short_definition: Interleaves problem types so learners must decide which procedure, formula, rule, or representation applies before solving.

distinctive_feature: The main discrimination is procedural or categorical choice before execution.

distinct_from_parent: It specializes the parent for problem-solving assignments and diagnostic quizzes.

still_same_parent_because: It retains the same mixed-sequence logic: confusable targets are alternated to strengthen category selection and durable recall.

source_primes: interleaving classification contrast

use_when: Learners can execute procedures in isolation but choose the wrong one in mixed settings.

use_when: Assessments or real use do not announce the target category in advance.

domain: mathematics

example: An assignment mixes integration methods so students must decide whether substitution, parts, or partial fractions fits each item.

failure_modes: Learners remember item positions rather than discriminating features

Interleaved Retrieval Review

short_definition: Combines active recall over time with mixed target sets so each review item also requires discrimination among nearby categories.

distinctive_feature: It joins interval timing with mixed discrimination pressure.

distinct_from_parent: It adds spacing and retrieval timing as a central control dimension; the parent can operate inside one session or across a sequence without adaptive forgetting intervals.

still_same_parent_because: The interleaving contribution is still the mixed ordering of confusable targets.

use_when: The practice design must fight forgetting and category confusion at the same time.

use_when: A spaced review system already exists but items are over-blocked or predictable.

domain: medical training

example: A spaced quiz alternates similar diagnoses so clinicians retrieve signs and distinguish look-alike conditions.

failure_modes: Duplicate with retrieval_spaced_reinforcement if the only novelty is interval timing

failure_modes: Overly aggressive scheduling that hides systematic confusion pairs

Interleaved Repertoire Practice

short_definition: Rotates pieces, movements, techniques, or performance contexts so performers learn retrieval, transition, and discrimination rather than only short-term blocked fluency.

distinctive_feature: The mixed units are performance tasks rather than declarative problem categories.

distinct_from_parent: It specializes the parent for music, sport, craft, and embodied skills.

still_same_parent_because: It still improves durable performance by alternating targets and making transitions informative.

use_when: A performer can execute a passage after warmup but cannot retrieve or adapt it later.

use_when: The target skill must survive transitions among pieces, keys, movements, or contexts.

domain: music

example: A practice session rotates short segments from three pieces instead of perfecting one passage before touching the next.

failure_modes: Excessive switching prevents deep repair

failure_modes: Hard passages are avoided because the rotation feels productive

Adaptive Interleaving Scheduler Variant

short_definition: Uses performance data to choose the next mixed item so confusion pairs, target coverage, spacing, and load are continually adjusted.

distinctive_feature: The interleaving schedule is generated or updated by a feedback-driven algorithm.

distinct_from_parent: It is an implementation-heavy variant of the parent rather than a different structural archetype.

still_same_parent_because: The goal remains discriminative mixed practice, not scheduling optimization for its own sake.

source_primes: interleaving scheduling feedback

use_when: The practice system has enough item metadata and feedback data to adapt sequence choices.

use_when: Static mixing under-serves some targets or overexposes others.

domain: edtech

example: A tutor alternates geometry proof types based on which theorem pairs a student has recently confused.

failure_modes: Algorithm optimizes immediate correctness instead of delayed discrimination

failure_modes: Opaque scheduling undermines learner trust

near_names:
Interleaved Practice
Mixed Practice
Mixed-Topic Practice
Interleaved Scheduling
Shuffled Practice Sequence
Contrastive Practice Rotation
Varied Problem Sequence


Intermediate-State Throughput Control

type: archetype

source: generated

batch: Batch 14

aliases:
transient intermediate control
intermediate residence-time control
formation-consumption balancing
intermediate state governance
work-in-process state control
transient-state intervention design
intermediate occupancy control

source_primes: reaction_intermediate transformation flow clearance_rate turnover queueing observability feedback constraint threshold resource_management

slug: transformation

slug: flow

slug: turnover

slug: queueing

slug: observability

slug: constraint

slug: threshold

slug: pipeline

slug: bottleneck

slug: composition

slug: buffering

slug: boundedness

components:
Transformation Path Map
Intermediate State Definition
Formation Rate Model
Consumption Rate Model
Intermediate Occupancy Metric
Residence-Time Window
Intermediate Quality Decay Model
Intervention Surface Map
Throughput Balance Rule
Side-Reaction or Leakage Guard
Observability Probe
Conversion Priority Rule
Stale Intermediate Disposition Path
Intermediate State Owner
Holding Condition Specification
Branching Exit Selectivity Model
Batch Size and Release Policy
Rework Loop Boundary
Intermediate Hazard Register

mechanisms:
WIP Limit by Intermediate State
Residence-Time Dashboard
Intermediate State Tagging
Conversion Capacity Boost
Formation Throttle
Priority by Age or Risk
Quench or Stabilization Step
Holding Condition Control
Side-Path Suppression
Stale Item Sweep
Stage Handoff Check
Batch Size Tuning

essence_one_line: Treat a named transient state as a controllable intervention surface: regulate how fast it forms, how long it persists, how its quality changes, and how reliably it converts into the desired next state.

compression_statement: Multi-step transformations often fail between endpoints. A transient intermediate may be absent in the raw input and final output yet determine yield, safety, throughput, and rework. This archetype names the intermediate, instruments its occupancy and residence time, balances formation against consumption, protects its quality, suppresses side paths, and uses the intermediate as a direct control surface rather than waiting for final-output failure.

core_intuition: If the middle state is invisible, everyone argues about inputs and outputs while the real process is won or lost in between. By making the intermediate state named, measured, and governable, designers gain a lever that is earlier than endpoint failure and more specific than generic pipeline optimization.

canonical_formula: desired_flow ≈ min(formation_rate(intermediate), consumption_rate(intermediate), quality_preserving_residence_window); intervene when intermediate_occupancy, age, quality, or side_path_rate crosses control bands.

structural_problem: A multi-step transformation is governed only by endpoint inputs and outputs while an absent-at-endpoints transient state silently controls throughput, yield, quality, risk, or path selection.

trigger_conditions: The transformation passes through a recognizable intermediate state, stock, queue, compound, case status, work-in-process state, staging table, or readiness condition.

trigger_conditions: The intermediate is neither the initial input nor the final desired output, so it is easy to under-instrument or treat as incidental.

trigger_conditions: Formation and consumption rates can diverge, causing accumulation, starvation, quality decay, side reactions, or idle downstream capacity.

trigger_conditions: The intermediate has a finite useful residence window before it spoils, ages, becomes stale, loses context, creates risk, or changes path.

trigger_conditions: Final output problems appear late, while intermediate state signals would reveal the failure earlier.

trigger_conditions: Operators have levers that can change formation, conversion, holding conditions, routing, clearance, or priority at the intermediate state.

symptoms: Final output is delayed, low-yield, unsafe, or inconsistent even though raw input seems adequate.

symptoms: Work-in-process, partially transformed material, draft decisions, staging records, or prequalified cases accumulate in a middle state.

symptoms: Downstream stages alternate between starvation and overload because intermediate formation is irregular or poorly matched to conversion capacity.

symptoms: Aging, spoilage, stale context, rework, or side-path loss increases with time spent in the intermediate state.

symptoms: Teams blame upstream input quality or downstream capacity while the uncontrolled intermediate is the actual intervention point.

symptoms: Process metrics count stage completion but not intermediate occupancy, age distribution, quality, or exit path.

symptoms: Small changes to holding conditions, dwell time, routing, or conversion priority have outsized effects on final yield.

root_tension: The intermediate is temporary, so it is tempting to ignore; but because every successful transformation must pass through it, the temporary state can become the most durable control surface. The intervention must preserve flow while preventing the intermediate from accumulating, decaying, leaking, or being prematurely consumed.

anti_signatures: The process is effectively one-step and has no named transient state worth governing.

anti_signatures: The relevant middle step is a passive buffer with no distinct formation, quality, residence-time, or conversion dynamics; use Buffering.

anti_signatures: The main problem is simply stage ordering or handoff accountability; use Pipeline Staging or Dependency Ordering.

anti_signatures: The main decision is whether formal criteria permit progression; use Stage-Gate Progression.

anti_signatures: The issue is only identifying a slow resource after the bottleneck is already known; use Bottleneck Identification and Relief.

anti_signatures: The intermediate is harmful at any level and should never exist; use hazard elimination or containment rather than intermediate-state throughput control.

structural_intervention: Insert a control layer around the transient intermediate state: define it, measure it, set safe occupancy and residence-time bands, tune formation and consumption rates, protect quality, and suppress side paths or leakage.

action_logic: Map the transformation path and identify the named intermediate state or states that all successful outputs must traverse.

action_logic: Define the intermediate precisely enough to distinguish it from raw input, final output, ordinary queues, and neighboring stages.

action_logic: Instrument formation rate, consumption rate, occupancy, age distribution, quality, side-path exits, and rework loops.

action_logic: Set control bands for safe occupancy, residence time, quality, and conversion reliability.

action_logic: Tune upstream formation so the intermediate is produced at a rate downstream conversion can consume without quality loss.

action_logic: Tune downstream consumption or clearance so intermediates do not accumulate beyond useful residence windows.

action_logic: Add holding, preservation, containment, routing, or prioritization mechanisms when the intermediate must wait.

action_logic: Use intermediate-state evidence to decide whether to slow input, speed conversion, split paths, clear stale stock, redesign the stage, or change endpoint promises.

action_logic: Review incidents where final output failed and ask which intermediate signal would have revealed the problem earlier.

decision_rules: If intermediate occupancy rises while final output does not, inspect consumption capacity, side-path loss, and quality decay before increasing input.

decision_rules: If downstream stages starve while upstream is active, inspect formation failure, premature clearance, or misclassified intermediate states.

decision_rules: If age distribution widens, add residence-time limits, expiry rules, priority by age, or batch-size changes.

decision_rules: If quality decays in the intermediate, shorten dwell time, improve holding conditions, or change the sequence so conversion happens sooner.

decision_rules: If multiple exits are possible, monitor selectivity and suppress side paths before final yield collapses.

decision_rules: If the intermediate is hazardous or fragile, privilege containment and rapid conversion over throughput maximization.

decision_rules: If intervention at the intermediate repeatedly compensates for bad upstream design, redesign the earlier stage rather than permanently over-controlling the middle.

target_invariants: The intermediate state remains identifiable and observable enough to control.

target_invariants: Formation and consumption rates remain balanced within acceptable bands.

target_invariants: Residence time stays inside the useful window for quality, safety, and context.

target_invariants: The intermediate does not become an invisible backlog, side-reaction sink, or stale inventory.

target_invariants: Endpoint optimization does not destroy intermediate stability or quality.

target_invariants: Interventions at the intermediate preserve the final transformation purpose rather than optimizing the middle for its own sake.

expected_outcomes: Earlier detection of yield loss, throughput mismatch, spoilage, rework, or side-path failure.

expected_outcomes: More stable throughput through multi-step transformations.

expected_outcomes: Lower accumulation of stale or unsafe intermediate stock.

expected_outcomes: Clearer accountability for middle-state quality and conversion reliability.

expected_outcomes: Better tuning of upstream formation, downstream consumption, and holding conditions.

expected_outcomes: More precise interventions than generic bottleneck relief or endpoint inspection.

prose_tradeoffs: Intermediate control improves visibility and leverage, but it can create overhead. Tight rules protect quality but may reduce flexibility. Formation throttles prevent accumulation but may lower throughput. Holding controls preserve useful state but add cost. Branching controls improve selectivity but can reduce experimentation. The review question is whether the intermediate dynamics are important enough to justify the added control layer.

Transient Bottleneck Control

variant_type: subtype

short_definition: Treat an accumulating intermediate state as the bottleneck that determines whole-transformation throughput.

distinctive_feature: The constraint is located in the transient state, not only in a fixed stage or resource.

distinct_from_parent: Narrower case where the intermediate is specifically the throughput bottleneck.

still_same_parent_because: It uses the same formation, occupancy, residence-time, and conversion controls.

source_primes: reaction_intermediate constraint queueing flow

use_when: A named intermediate accumulates before the final output is scarce or delayed.

use_when: The limiting factor is formation/consumption imbalance rather than the endpoint itself.

use_when: Relieving the intermediate bottleneck changes final yield, safety, or speed.

concise_examples: A half-finished batch aging before final cure

concise_examples: A staged ETL table growing faster than downstream validation

concise_examples: A clinical pre-discharge state binding hospital flow

Labile Intermediate Safety Control

short_definition: Control a fragile, reactive, unsafe, or rapidly degrading intermediate before it causes side effects or irreversible loss.

distinctive_feature: Intermediate preservation and safety are as important as throughput.

distinct_from_parent: The parent also covers benign intermediates where the main issue is throughput or yield.

still_same_parent_because: It still manages the transient state as the intervention surface.

use_when: The intermediate is useful only within a narrow time, concentration, quality, or containment band.

use_when: Accumulation creates hazards, spoilage, toxicity, security risk, or trust loss.

use_when: The intervention must tune dwell time, concentration, containment, or rapid conversion.

concise_examples: Reactive chemical intermediate quenching

Intermediate Inventory Governance

short_definition: Govern the stock of partly transformed items whose age, quantity, and mix determine final throughput and quality.

distinctive_feature: The transient state is managed as a governed inventory rather than merely a queue.

distinct_from_parent: Narrower operational form focused on stock, aging, and mix control.

still_same_parent_because: The controlled object remains the transient intermediate state.

use_when: Intermediate work-in-process has material cost, aging, obsolescence, or quality risk.

use_when: The final output depends on keeping intermediate stock within a useful band.

use_when: Operators can alter release, batch size, holding conditions, or conversion priority.

concise_examples:
Semi-finished goods aging rule
Moderation review queue by state
ETL staging table TTL

Branching Intermediate Steering

short_definition: Steer an intermediate toward the desired downstream path when multiple exits or side paths are possible.

distinctive_feature: The central problem is not just rate balance but path selection from the transient state.

distinct_from_parent: The parent includes single-path intermediate control as well as branching cases.

still_same_parent_because: The intermediate remains the named intervention surface.

use_when: The same intermediate can proceed to multiple final states.

use_when: Side reactions, rework loops, leakage, or misclassification can divert yield.

use_when: Control levers can bias exit probabilities or route the intermediate.

concise_examples:
Selective reaction path control
Lead qualification routing
Ambiguous case reclassification

near_names:
Transient Intermediate Control
Intermediate Residence-Time Control
Formation–Consumption Balancing
Intermediate State Governance
Work-in-Process State Control
Labile Intermediate Control


Intermittent Burst Absorption

batch: First Iteration/Batch 21

Burst Absorption

notes: Shorter label, but less explicit about irregular intermittency and post-burst recovery.

Intermittent Surge Handling

notes: Names a common operational phrasing for the same pattern.

Burst Tolerance

notes: Names the capacity property produced by the archetype rather than the intervention design.

Surge Absorption

notes: Useful where “surge” is standard vocabulary, especially operations, health care, and infrastructure.

related_primes: resource_management system_slack queueing fault_tolerance observability threshold boundedness variability adaptation flow scalability

slug: intermittency

slug: resilience

slug: variability

slug: adaptation

slug: scalability

components:
Burst Pattern Profile
Burst Detector
Burst Threshold
Temporary Holding Capacity
Surge Capacity
Priority Policy
Normal Operation Boundary
Recovery Interval
Degradation or Shedding Gate
Overflow Path
Reserve Replenishment Rule
Burst-Mode Authority
Post-Burst Learning Loop
Backlog Visibility

mechanisms:
Surge Queue
Burst Buffer
Elastic Capacity Scaling
On-Call Response Rotation
Incident Surge Team
Backup Staffing Pool
Triage Protocol
Rate Limit with Burst Allowance
Overflow Channel
Peak Response Reserve
Flash Crowd Playbook
Post-Burst After-Action Review

essence_one_line: Prepare for irregular bursts by providing temporary absorption capacity and post-burst recovery.

compression_statement: When a mostly stable system experiences irregular spikes in demand, failures, signals, attention, or disturbance, define burst detection, temporary absorption, priority rules, overflow or surge capacity, and recovery so short-lived peaks do not destabilize normal operation.

core_intuition: A system sized only for average conditions can be efficient most of the time and fragile during sudden spikes. Intermittent Burst Absorption creates a temporary mode between ordinary operation and full failure: it catches the spike, protects what matters, uses reserves or queues deliberately, and then restores capacity before the next burst.

canonical_formula: stable baseline + irregular burst above steady-state capacity -> burst detector + threshold + holding/surge capacity + priority policy + recovery interval -> preserved normal function with bounded backlog and restored readiness

structural_problem: A system is generally stable under ordinary load but periodically receives irregular bursts that exceed steady-state capacity, creating overload, lost signals, failed service, unsafe improvisation, hidden backlog, or cascading disruption.

condition: Bursts are intermittent rather than continuous.

description: The spike appears episodically, sometimes unpredictably, and is separated by quieter intervals where permanent high capacity would be wasteful.

condition: The burst exceeds ordinary steady-state handling.

description: Baseline capacity works for normal flow but fails during sudden arrival, error, demand, attention, or disturbance spikes.

condition: The burst is short enough or bounded enough to absorb.

description: Temporary holding, surge capacity, or overflow can bridge the spike if the system responds quickly and recovers afterward.

condition: Normal operation must continue during the burst.

description: The system cannot simply abandon baseline service, safety, or core function while reacting to the spike.

condition: Some prioritization is unavoidable.

description: When burst volume exceeds immediate capacity, the system must decide what receives attention first, what waits, what routes elsewhere, and what may be shed.

condition: Post-burst debt matters.

description: Deferred work, exhausted reserves, fatigued staff, drained budget, overheated infrastructure, or unresolved cases must be restored before the next burst.

symptom: Sudden queues or backlogs

example: Tickets, calls, patients, packets, requests, orders, alerts, or messages accumulate faster than ordinary channels can process them.

symptom: Normal service collapses during spikes

example: A team, website, clinic, logistics system, or help desk functions well most days but degrades sharply during occasional surges.

symptom: Urgent items get buried in burst noise

example: Critical cases, severe failures, high-risk patients, or important signals are mixed with low-priority arrivals because no triage policy is active.

symptom: Emergency improvisation becomes the default burst response

example: People repeatedly invent ad hoc workarounds, overtime, escalations, or manual routing whenever a burst appears.

symptom: Capacity appears both excessive and insufficient

example: Permanent staffing or infrastructure seems wasteful during quiet intervals yet inadequate during short, irregular peaks.

symptom: Hidden recovery debt accumulates

example: After the spike passes, backlog, fatigue, system load, depleted reserves, or unresolved exceptions remain invisible until the next burst.

symptom: Downstream subsystems receive shock waves

example: A burst in one channel spills into fulfillment, support, risk, communications, finance, safety, or leadership attention.

root_tension: The system wants efficient steady-state operation, but intermittent bursts require temporary excess capacity, looser coupling, triage, and recovery that would be inefficient or unnecessary if maintained permanently. The design problem is to create enough burst-mode capacity without converting the whole system into permanent emergency mode.

case: The high load is sustained rather than intermittent.

why_not: Permanent capacity expansion, demand reduction, load shedding, rate limiting, or redesign of steady-state throughput is more appropriate.

case: The peaks are predictable recurring cycles.

why_not: Cycle Staggering, Cadence Design, or Load Leveling may fit better when timing can be planned and offset in advance.

case: The issue is merely a timing mismatch between producer and consumer.

why_not: Generic Buffering may apply, but Intermittent Burst Absorption needs a burst detector, burst-mode rule, prioritization, and recovery design.

case: The system must reject excess load rather than absorb it.

why_not: Load Shedding or Rate Limiting is the primary pattern when safe acceptance is impossible.

case: The burst is diagnostic rather than capacity-threatening.

why_not: Intermittent Failure Capture or Intermittent Sampling may be better when the goal is to observe elusive episodes rather than absorb overload.

case: The spike is a one-time exceptional event with no reusable response design.

why_not: A one-off emergency response may be needed, but the archetype concerns reusable burst-mode capability.

structural_intervention: Identify burst patterns and thresholds, create a temporary absorption mode using holding capacity, surge capacity, overflow, or bounded throttling, govern priorities during overload, preserve the normal operating boundary, and restore readiness after the burst.

step: Characterize the intermittent burst

logic: Clarify what spikes, how quickly it arrives, how long it lasts, what triggers it, what baseline capacity exists, and which invariants are threatened.

step: Define burst-mode thresholds

logic: Set observable conditions that switch the system from ordinary handling to burst absorption before overload becomes irreversible.

step: Create temporary holding or absorption capacity

logic: Provide buffers, queues, reserves, staging areas, overflow paths, extra staff, elastic infrastructure, or attention capacity that can absorb excess for a bounded interval.

step: Activate surge capacity when holding alone is insufficient

logic: Bring temporary resources online quickly enough to process, route, communicate, or stabilize the burst while avoiding uncontrolled permanent expansion.

step: Apply a priority policy

logic: Decide what is served first, what waits, what escalates, what routes elsewhere, and what may be safely degraded or shed.

step: Protect the normal operation boundary

logic: Prevent burst response from consuming the whole system or undermining core service, safety, evidence integrity, fairness, or minimum quality.

step: Monitor backlog, reserves, and secondary effects

logic: Track what is accumulating, where the burst is spilling over, and whether absorption is merely hiding damage downstream.

step: Recover and replenish after the burst

logic: Clear backlog, rest staff, refill reserves, scale down temporary capacity, resolve deferred cases, and return to ordinary operating rules.

step: Update the burst design from experience

logic: Use post-burst review to retune thresholds, sizing, escalation paths, priority policies, and recovery intervals.

rule: Absorb only within a bounded safety envelope.

description: If the burst exceeds safe holding or surge capacity, shift to explicit degradation, rate limiting, or shedding rather than pretending full service is possible.

rule: Preserve critical invariants before preserving arrival order.

description: During burst load, urgency, severity, reversibility, safety, fairness, or dependency may matter more than first-come-first-served handling.

rule: Separate temporary burst capacity from permanent baseline capacity.

description: Use surge reserves when spikes are intermittent; redesign steady-state capacity when high load becomes sustained.

rule: Treat recovery as part of the intervention, not cleanup.

description: A burst is not absorbed until backlog, reserves, fatigue, system health, and deferred obligations are restored.

rule: Make hidden backlog visible.

description: Temporary holding capacity can create an illusion of stability unless the system tracks what is waiting, aging, or deteriorating.

rule: Escalate before the buffer becomes the failure point.

description: Holding capacity buys time; it should trigger additional processing, overflow, or prioritization before it saturates.

invariant: Core service or safety remains available

description: The burst response should protect the minimum viable function that must not collapse under spike load.

invariant: Critical cases remain visible

description: High-urgency or high-risk items should not disappear inside backlog or low-priority queues.

invariant: Absorption capacity remains bounded

description: Queues, buffers, reserves, and surge teams must have explicit limits and escalation paths.

invariant: Priority remains legitimate

description: Triage and deferral rules should be explainable, fair, and auditable enough for the domain.

invariant: Recovery restores readiness

description: The system should be able to absorb the next burst rather than surviving one burst by exhausting hidden reserves.

invariant: Burst response does not normalize emergency mode

description: Temporary rules should demobilize when the burst ends unless evidence shows the baseline system must change.

outcome: Reduced overload during irregular spikes

description: The system remains functional when burst volume briefly exceeds ordinary capacity.

outcome: Lower loss of important signals or cases

description: Detection and triage keep high-priority items from being buried in burst noise.

outcome: More predictable burst-mode behavior

description: Predefined queues, reserves, escalation paths, and priority rules reduce improvisation.

outcome: Bounded backlog and faster recovery

description: Waiting work becomes visible and is cleared through recovery rules rather than left to accumulate.

outcome: Less need for permanent overcapacity

description: Temporary absorption handles intermittent peaks without staffing or provisioning for peak load at all times.

outcome: Better learning from burst episodes

description: Post-burst review improves thresholds, reserve sizing, and recovery planning.

prose_essence:
Intermittent Burst Absorption prepares a mostly stable system for short, irregular spikes that exceed ordinary capacity. The intervention is not simply “add a buffer” or “keep extra resources.” It is a complete burst-mode design: detect the spike, switch modes at a threshold, hold or route excess load, activate temporary capacity, prioritize scarce attention or processing, protect core function, and recover readiness after the burst.

This archetype is useful when the average load is misleading. A help desk may be calm until a product outage creates thousands of tickets. A cloud service may run well until a public announcement creates flash traffic. A hospital may function normally until several emergency cases arrive at once. In all of these cases, designing only for ordinary flow leaves the system brittle during bursts, while permanently staffing for worst-case peaks may be wasteful.

The core idea is to create a bounded temporary mode between ordinary operation and failure. The burst is absorbed long enough for the system to process, route, prioritize, or degrade safely, and the system then restores the capacity it consumed.

prose_when_to_use:
Use this archetype when a system is stable under normal conditions but periodically receives irregular spikes in demand, failures, signals, attention, cases, traffic, or workload. The spike should be large enough to threaten ordinary operation, but bounded enough that temporary holding capacity, surge capacity, overflow, or priority rules can reduce harm.

The strongest signal is a repeated pattern of “fine most of the time, overwhelmed suddenly.” The burden may appear as queues, dropped requests, severe cases buried in noise, infrastructure overload, exhausted staff, depleted reserves, or downstream spillover. It especially fits cases where permanent high capacity would be inefficient, yet having no spike plan creates recurring crisis.

Do not use this as the primary archetype for sustained undercapacity, predictable recurring peaks, or purely diagnostic intermittent failures. Sustained undercapacity requires baseline redesign. Predictable peaks may call for Cycle Staggering or Load Leveling. Diagnostic episodes may call for Intermittent Failure Capture.

prose_structural_problem:
The structural problem is a mismatch between steady-state efficiency and burst-state resilience. A system sized for ordinary flow can be efficient during quiet periods, but the same lean design becomes fragile when arrivals accelerate or disturbances spike. Because the bursts are intermittent, the organization or infrastructure may resist permanent overcapacity; because the bursts are consequential, ordinary capacity is not enough.

The problem often has four layers. First, the burst is not recognized early enough. Second, excess load has nowhere safe to wait or route. Third, priority decisions are made implicitly by arrival order, noise, influence, or whoever shouts loudest. Fourth, the visible spike passes but leaves recovery debt: backlog, fatigue, depleted reserves, unresolved exceptions, or degraded infrastructure.

Intermittent Burst Absorption addresses all four layers. It turns burst handling from improvisation into a reusable structural response.

prose_intervention_logic:
The intervention starts by profiling the burst: what spikes, how quickly it arrives, how long it lasts, what ordinary capacity exists, and what core invariants are threatened. A burst threshold then defines when the system should switch from normal mode into burst mode.

Once burst mode activates, the system needs an absorption surface. That surface might be a queue, buffer, staging area, overflow path, reserve, autoscaled infrastructure, backup staffing pool, incident team, or communication playbook. The surface buys time, but it cannot be unmanaged. A priority policy determines what is served first, what waits, what escalates, what routes elsewhere, and what may be degraded or shed if absorption limits are exceeded.

The response must also protect the normal operation boundary. If the burst consumes the entire system, absorption has failed. Finally, recovery is part of the design: clear backlog, replenish reserves, rest people, scale down temporary capacity, document learning, and return to ordinary rules when safe.

prose_key_components:
### Burst Pattern Profile

**Role:** Characterizes the burst as intermittent rather than steady, including its probable triggers, arrival shape, duration, intensity, recurrence clues, and uncertainty.

This profile keeps the archetype from becoming generic capacity planning. The intervention applies when the system is mostly stable but periodically receives short, irregular spikes that exceed ordinary operating capacity.
### Burst Detector

**Role:** Recognizes when incoming demand, failures, signals, attention, traffic, or workload has crossed from ordinary variation into burst behavior.

The detector may be automated, procedural, or human judgment based. Without timely detection, the system continues operating as if conditions were normal until the burst has already caused overload.
### Burst Threshold

**Role:** Defines the observable boundary at which ordinary steady-state handling should give way to burst-mode absorption.

The threshold prevents both underreaction and overreaction. It can be based on queue length, arrival rate, error rate, occupancy, sentiment volume, case severity, or resource utilization.
### Temporary Holding Capacity

**Role:** Provides a short-term place, channel, queue, buffer, reserve, staging area, or holding pattern where excess load can wait without immediately destabilizing normal operation.

This component is not merely a generic buffer. It must be sized and governed for intermittent spikes, including limits, priorities, aging, and release back into normal processing.
### Surge Capacity

**Role:** Adds temporary processing, staffing, compute, funding, attention, space, or response capability during the burst window.

The Batch 021 extraction controls identify surge_capacity as a component to update. Here it appears as a structural part of the archetype, not as a full archetype by itself.
### Priority Policy

**Role:** Determines which incoming items, people, requests, failures, or signals are served first, deferred, routed elsewhere, throttled, or dropped when burst volume exceeds absorption capacity.

Intermittent bursts force ordering decisions. A priority policy preserves critical outcomes and fairness rather than allowing arrival order, noise, or political pressure to decide implicitly.
### Normal Operation Boundary

**Role:** Protects the stable baseline function that must continue while the burst is being absorbed.

Burst absorption succeeds only if the temporary mode prevents the spike from consuming the whole system. The boundary clarifies what cannot be sacrificed, such as safety, core service, custody of evidence, or minimum quality.
### Recovery Interval

**Role:** Defines how backlog is cleared, reserves are replenished, staff recover, systems cool down, and normal operating rules resume after the burst.

Post-burst recovery distinguishes absorption from mere survival. Without recovery, each burst leaves hidden debt that lowers the system’s capacity for the next spike.
### Degradation or Shedding Gate

**Role:** Specifies when the system should intentionally reduce quality, defer lower-priority work, reject noncritical load, or shed demand rather than pretend all burst volume can be absorbed.

This gate prevents catastrophic overload when a burst exceeds the safe absorption envelope. It should be explicit because ad hoc shedding often harms the least powerful participants first.

### Overflow Path

**Role:** Routes excess work, people, data, traffic, or attention to an alternate channel when the primary channel is saturated.

Overflow paths can include backup sites, alternate teams, mirrored queues, external partners, emergency funds, or alternate communication channels.

### Reserve Replenishment Rule

**Role:** Restores consumed buffer stock, staffing reserve, compute headroom, emotional bandwidth, or financial capacity after the burst passes.

A burst reserve that is not replenished becomes a one-time cushion rather than a reusable absorption design.

### Burst-Mode Authority

**Role:** Authorizes temporary changes in staffing, routing, limits, spending, messaging, escalation, or operating rules during a burst.

Irregular spikes unfold faster than ordinary governance cycles. Someone or some protocol must be allowed to switch modes within guardrails.

### Post-Burst Learning Loop

**Role:** Captures what triggered the burst, how well absorption worked, which limits were reached, and what should change before the next spike.

This component converts burst experience into better thresholds, sizing, priority rules, and recovery design.

### Backlog Visibility

**Role:** Makes accumulated waiting work, unresolved cases, deferred tasks, or delayed requests visible during and after the burst.

Backlog can hide inside queues, teams, clinics, warehouses, inboxes, or emotional labor. Visibility prevents the system from declaring success while deferred work quietly compounds.

prose_common_mechanisms:
### Surge Queue

**Mechanism type:** workflow. **Role:** Temporarily holds burst arrivals in an ordered queue with triage, aging, escalation, and release rules so the primary process does not collapse under immediate load.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Burst Buffer

**Mechanism type:** artifact. **Role:** Provides a temporary storage, staging, cache, waiting room, holding account, spare inventory, or memory area for excess load during an intermittent spike.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Elastic Capacity Scaling

**Mechanism type:** software_or_tool. **Role:** Automatically or procedurally adds compute, bandwidth, staffing, space, or processing capacity when burst indicators cross a threshold.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### On-Call Response Rotation

**Mechanism type:** role_or_team. **Role:** Maintains people who can be activated during irregular incidents or demand spikes without making permanent full staffing necessary.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Incident Surge Team

**Mechanism type:** role_or_team. **Role:** Temporarily forms a cross-functional team to handle a burst of failures, cases, requests, public attention, or operational exceptions.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Backup Staffing Pool

**Mechanism type:** role_or_team. **Role:** Provides trained extra personnel who can enter service for short burst windows and then return to reserve or ordinary roles.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Triage Protocol

**Mechanism type:** protocol. **Role:** Sorts burst arrivals by urgency, severity, reversibility, fairness, or dependency so scarce absorption capacity goes where it preserves the most important invariants.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Rate Limit with Burst Allowance

**Mechanism type:** protocol. **Role:** Allows short bursts up to a bounded envelope while capping sustained inflow that would exhaust buffers or prevent recovery.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Overflow Channel

**Mechanism type:** workflow. **Role:** Redirects excess load to an alternate team, facility, queue, communication channel, provider, route, or partner when the primary channel saturates.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Peak Response Reserve

**Mechanism type:** other. **Role:** Holds money, inventory, compute headroom, equipment, beds, vehicles, or attention in reserve for short-lived spikes rather than continuous use.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Flash Crowd Playbook

**Mechanism type:** document. **Role:** Predefines steps for sudden surges in traffic, attention, demand, media activity, or public behavior so response begins before improvisation becomes chaotic.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.
### Post-Burst After-Action Review

**Mechanism type:** method. **Role:** Reviews burst triggers, thresholds, backlog, losses, fairness effects, and recovery debt after the spike passes.

This is an implementation of the archetype, not the archetype itself. It becomes part of Intermittent Burst Absorption only when it participates in burst detection, temporary absorption, prioritization, protected normal operation, or post-burst recovery.

prose_failure_modes:
### Buffer Becomes the Graveyard

Temporary holding capacity accumulates work that nobody owns, clears, or monitors. The system looks stable from the outside while delayed cases age and deteriorate. Mitigate this with backlog age metrics, ownership, clearance targets, and escalation rules.

### Late Burst Detection

The system recognizes the burst only after overload has already cascaded. Mitigate this with leading indicators such as arrival acceleration, queue growth, error rate, reserve depletion, or staff saturation.

### False Burst Activation

The system enters burst mode during normal variation, wasting reserves and fatiguing responders. Mitigate this with graduated thresholds, hysteresis, cooldowns, and after-action review of false positives.

### Surge Capacity Is Theoretical

The design assumes backup people, rooms, infrastructure, or funds exist, but they are not trained, authorized, stocked, or ready. Mitigate this through precommitment, drills, automation tests, and clear activation authority.

### Priority Capture

Powerful, noisy, or visible actors get served first while more urgent but quieter cases wait. Mitigate this with explicit triage criteria, transparency, and audit trails.

### Permanent Burst Mode

The system never returns to a healthy baseline. Mitigate this by tracking activation frequency and treating sustained burst conditions as evidence for redesign of baseline capacity or demand.

### Recovery Debt Accumulates

The spike passes, but backlog, fatigue, depleted reserves, and deferred maintenance remain. Mitigate this by making recovery interval and reserve replenishment part of the formal intervention.

prose_neighbor_distinctions:
**Buffering** is broader. It absorbs variation or timing mismatch generally. Intermittent Burst Absorption specifically targets irregular spikes and includes detection, thresholding, temporary burst mode, prioritization, and recovery.

**Capacity Reservation** protects resources for future or priority use. This archetype may use reserved capacity, but its full logic includes when to activate it, how to prioritize it, and how to replenish it.

**Load Shedding** rejects, drops, or degrades load to protect the system. Intermittent Burst Absorption tries to absorb within a bounded envelope and uses shedding only when the envelope is exceeded.

**Rate Limiting** caps inflow. Burst absorption may allow bounded spikes and apply rate limits only when buffers or recovery capacity are threatened.

**Load Leveling or Demand Smoothing** works best when demand can be shaped over time. Intermittent Burst Absorption fits irregular spikes that cannot always be planned away.

**Cycle Staggering** offsets predictable recurring peaks. This archetype handles irregular spikes whose timing, magnitude, or source may not be schedulable.

**Intermittent Failure Capture** is about diagnosing elusive episodes. Intermittent Burst Absorption is about protecting capacity and normal operation during episodic overload.

prose_cross_domain_examples:
In software infrastructure, a service uses queues, autoscaling, and bounded rate limits during flash traffic. In healthcare, a hospital activates triage, overflow rooms, and backup staff after a sudden arrival spike. In customer support, tickets after an outage enter a surge queue while severe cases escalate. In logistics, unexpected return volume is staged in temporary space and processed with extra capacity. In public communications, a flash-crowd playbook routes sudden media and resident inquiries. In finance, liquidity reserves and priority rules absorb short stress bursts and are replenished afterward.

These examples differ in implementation, but the structure is the same: irregular spike, burst threshold, temporary absorption, priority, protected baseline, and recovery.

prose_non_examples: A weekly review reminder is not this archetype because no irregular burst is being absorbed. Permanent staffing for permanently high volume is baseline capacity design, not burst absorption. A cache for normal repeated reads is not this archetype unless it is explicitly designed to absorb irregular spikes and recover. A hard rate limit that simply rejects everything above a cap is Rate Limiting or Load Shedding. A recurring seasonal peak planned months ahead is better handled by Load Leveling, Capacity Reservation, or Cycle Staggering. A diagnostic logger for rare software crashes is Intermittent Failure Capture, not burst absorption.

prose_tradeoffs:
The main tradeoff is efficiency versus readiness. Surge reserves, extra queues, overflow paths, trained backups, and playbooks cost something even when idle. The value is that they prevent short spikes from causing disproportionate damage.

Another tradeoff is absorption versus visibility. A buffer can make the front door look calm while waiting work accumulates invisibly. That is why backlog visibility is not optional in high-stakes settings.

Priority creates a fairness tradeoff. First-come-first-served may seem neutral, but during bursts it can bury urgent cases. Triage can preserve safety, but it must be legitimate and auditable.

Finally, temporary surge capacity can become permanent emergency mode. If bursts happen too often, the system may need baseline redesign rather than more heroic absorption.

prose_invariants_to_preserve:
The first invariant is core service continuity: the function that matters most should not collapse merely because the system is temporarily busy. The second is visibility of critical cases: severe, urgent, or irreversible items must not disappear inside burst noise. The third is bounded absorption: queues, buffers, and reserves need limits, ownership, and escalation paths.

A fourth invariant is legitimate priority. During bursts, not everyone can be served immediately, so the priority policy must be explainable and appropriate to the domain. The fifth invariant is readiness after recovery. A system that survives one burst by exhausting reserves and people has not truly absorbed the burst unless it restores capacity for the next one.

prose_target_outcomes:
Successful Intermittent Burst Absorption reduces overload during irregular spikes without requiring permanent peak capacity. It lowers dropped requests, lost signals, panic improvisation, critical-case burial, and cascade into downstream systems. It also makes burst behavior more predictable: people know when burst mode starts, what mechanisms activate, how priorities work, and how recovery will be handled.

A strong implementation leaves visible evidence after each burst: queue age, severity mix, reserve use, activation delay, recovery time, fairness effects, and changes needed before the next spike.

prose_parameter_dimensions:
### Burst Threshold

The burst threshold determines when ordinary operation should switch to burst mode. If the threshold is too low, the system overreacts to normal variation. If it is too high, the burst may cause irreversible overload before response begins. Useful threshold signals include arrival rate, acceleration, queue growth, error rate, occupancy, severity mix, reserve depletion, or staff saturation.

### Absorption Capacity Size

The holding capacity or reserve must be large enough to bridge plausible spikes but not so large that it hides chronic undercapacity. Size it against burst duration, arrival intensity, acceptable waiting time, safety constraints, and recovery capacity.

### Surge Activation Delay

Temporary capacity is only useful if it arrives before the burst causes unacceptable harm. Activation delay includes detection time, decision time, technical startup, staffing availability, communication lag, and routing delay.

### Priority Granularity

A crude priority rule may be easy to run but unfair or unsafe. A fine-grained rule may be more accurate but too slow during bursts. The right level depends on stakes, observability, and available triage skill.

### Recovery Interval

The recovery interval defines how quickly the system must clear deferred work, replenish reserves, and restore people or infrastructure. If recovery takes longer than the typical interval between bursts, the system is accumulating fragility.

### Shedding Boundary

Not every spike can be absorbed safely. The shedding boundary defines when lower-priority load must be delayed, degraded, rejected, capped, rerouted, or publicly communicated as unavailable.

prose_variants_and_near_names:
**Surge Queue Absorption** uses explicit queue governance to hold and order excess arrivals. It is useful when arrivals can wait briefly, but urgency still varies.

**Elastic Surge Absorption** temporarily expands capacity through autoscaling, backup staffing, reserve equipment, overflow beds, or similar mechanisms. It fits when permanent peak capacity would be wasteful.

**Incident Surge Mobilization** temporarily activates a team, authority structure, or response role set. It is common when bursts involve cross-functional work, communication, or operational decisions.

**Overflow Absorption** routes excess load to an alternate path when the primary channel saturates. It is useful only if the overflow path is credible and monitored.

Near names include burst absorption, intermittent surge handling, burst tolerance, surge absorption, flash-crowd handling, burst buffer, and surge queue. The last two should normally remain mechanisms or variant labels, not standalone archetypes.

Surge Queue Absorption

short_definition: Absorbs irregular bursts by placing excess arrivals into an explicitly governed queue until normal processing can catch up.

distinctive_feature: The holding structure is an ordered queue with explicit release and priority logic.

distinct_from_parent: The parent can use reserves, elastic capacity, overflow, or triage without queueing; this variant makes queue governance the central absorption method.

still_same_parent_because: The queue exists to absorb intermittent bursts and recover normal operation rather than to optimize ordinary waiting work in general.

source_primes: intermittency queueing resilience

condition: Burst arrivals can wait briefly without irreversible harm.

notes: The queue should preserve safety, fairness, and information quality while delaying service.

condition: Arrival order alone would be unfair or inefficient.

notes: A queue with triage, aging, and escalation can prevent high-urgency cases from being buried.

condition: The primary service path must remain stable.

notes: The surge queue decouples immediate arrivals from constrained processing capacity.

Temporary Holding Capacity

role: Holds excess arrivals safely during the burst.

notes: Usually implemented as a queue, waiting room, ticket backlog, staging lane, or digital buffer.

Priority Policy

role: Orders the queue by urgency, fairness, dependency, or aging.

notes: Prevents arrival order from silently deciding outcomes under burst load.

Backlog Visibility

role: Shows the size, composition, and age of waiting work.

notes: Needed to prevent hidden accumulation after the burst.

Surge Queue

mechanism_type: workflow

role: Holds and orders arrivals during the spike.

Triage Protocol

mechanism_type: protocol

role: Sorts queued work by urgency and preservation of invariants.

domain: Customer support

example: A surge queue holds post-outage tickets while severe cases are escalated first.

domain: Healthcare

example: A triage queue handles a sudden arrival burst while protecting critical care capacity.

failure_mode: Invisible backlog debt

cause: The queue absorbs arrivals but clearing plans are missing.

mitigation: Track age, severity, and clearance rate after the burst.

failure_mode: Priority capture

cause: Loud or powerful requesters jump the queue.

mitigation: Use transparent triage and escalation rules.

Elastic Surge Absorption

short_definition: Absorbs bursts by temporarily expanding capacity and then scaling back after recovery.

distinctive_feature: The key move is temporary expansion of processing capability rather than only holding or shedding load.

distinct_from_parent: The parent includes several absorption methods; this variant emphasizes activation and deactivation of temporary capacity.

still_same_parent_because: The capacity expansion is triggered by intermittent bursts and paired with post-burst recovery.

source_primes: intermittency resilience scalability

condition: Capacity can be added faster than the burst causes unacceptable degradation.

notes: The system needs reliable activation thresholds and prearranged resources.

condition: Permanent capacity would be wasteful.

notes: Elastic expansion fits low baseline demand plus occasional spikes.

condition: Recovery requires returning capacity to a sustainable baseline.

notes: Unbounded scaling can become financially or operationally unsafe.

Surge Capacity

role: Adds temporary processing capability.

notes: Can be compute, staff, beds, equipment, funds, or attention.

Burst Threshold

role: Triggers capacity expansion.

notes: Should separate real spikes from ordinary variability.

Recovery Interval

role: Returns the system to baseline after the burst.

notes: Prevents elastic capacity from becoming permanent unmanaged expansion.

Elastic Capacity Scaling

role: Adds resources when burst indicators rise.

Backup Staffing Pool

role: Activates trained people for short spike windows.

Peak Response Reserve

mechanism_type: other

role: Uses reserved resources only during burst conditions.

domain: Cloud infrastructure

example: Autoscaling adds instances during a traffic spike and later scales down.

domain: Public health

example: An emergency clinic activates overflow staff during a sudden case surge.

failure_mode: Runaway expansion

cause: The burst threshold triggers too easily or lacks budget/safety bounds.

mitigation: Use ceilings, cooldowns, and manual override for extreme cases.

failure_mode: Late activation

cause: The expansion takes longer than the burst onset.

mitigation: Pre-warm reserves or combine with temporary holding capacity.

Incident Surge Mobilization

short_definition: Absorbs bursts by temporarily mobilizing a special response structure, authority, or team for the duration of the spike.

distinctive_feature: The absorption method is temporary organizational mobilization rather than only technical capacity or a holding queue.

distinct_from_parent: The parent describes burst handling generally; this variant concentrates on temporary authority, roles, and coordination routines.

still_same_parent_because: The response structure exists to absorb intermittent overload and then demobilize during recovery.

condition: The burst is exceptional enough to require temporary coordination authority.

notes: Ordinary roles cannot handle the volume, complexity, or urgency alone.

condition: The burst involves cross-functional dependencies.

notes: A temporary team can coordinate operations, communication, escalation, and recovery.

condition: Permanent incident staffing would be inefficient.

notes: The structure activates only when burst-mode criteria are met.

Burst-Mode Authority

role: Authorizes temporary operating changes.

notes: Essential when normal governance is too slow during a burst.

Priority Policy

role: Guides triage and escalation under scarce response capacity.

notes: Prevents improvisational priority drift.

Post-Burst Learning Loop

role: Captures lessons after demobilization.

notes: Improves the next surge response.

Incident Surge Team

role: Temporarily handles cross-functional burst workload.

On-Call Response Rotation

role: Maintains people who can be activated quickly.

Post-Burst After-Action Review

mechanism_type: method

role: Reviews trigger, response, recovery, and residual debt.

domain: Software operations

example: An incident team forms during a burst of alerts and user reports after an outage.

domain: Public services

example: A storm response team mobilizes for a temporary surge in emergency calls and road closures.

failure_mode: Permanent emergency mode

cause: The surge team never demobilizes and normal operation remains disrupted.

mitigation: Define demobilization criteria and recovery handoff.

failure_mode: Authority confusion

cause: Temporary response authority conflicts with normal owners.

mitigation: Specify activation scope and decision rights before bursts occur.

Overflow Absorption

short_definition: Absorbs bursts by routing excess load to an alternate path or reserve channel when the primary channel saturates.

distinctive_feature: The central move is alternate routing rather than expanding the primary path or simply queueing.

distinct_from_parent: The parent can absorb within the primary system; this variant explicitly creates a secondary path for excess.

still_same_parent_because: The overflow channel is activated by intermittent bursts and paired with recovery to normal routing.

source_primes: intermittency flow resilience

condition: The primary channel saturates before the whole system is actually out of options.

notes: There is another place excess load can go if routing is predesigned.

condition: Holding load in place would create local collapse.

notes: Overflow prevents the primary subsystem from becoming the single point of overload.

condition: Alternate channels can preserve minimum quality or safety.

notes: The overflow path must be credible, not a dumping ground.

Overflow Path

role: Routes excess load to an alternate channel.

notes: May be physical, digital, organizational, financial, or communicative.

Burst Threshold

role: Determines when overflow begins.

notes: Prevents premature rerouting or late activation.

Normal Operation Boundary

role: Protects the primary path from collapse.

notes: Clarifies what must stay functional during overflow.

Overflow Channel

role: Routes excess to an alternate team, facility, queue, or provider.

Flash Crowd Playbook

mechanism_type: document

role: Predefines alternate routing and messaging during sudden attention or traffic surges.

example: Overflow clinics handle a short-lived patient surge while emergency rooms preserve critical capacity.

domain: Cloud systems

example: Traffic is routed to fallback regions during a flash crowd.

failure_mode: Overflow path collapse

cause: The alternate channel is underprepared or receives too much low-priority load.

mitigation: Size, test, and prioritize overflow paths before bursts.

near_names:
Burst Absorption
Intermittent Surge Handling
Burst Tolerance
Burst Buffer
Surge Queue
Flash Crowd Handling
Peak Response Reserve
Backup Staffing Pool
On-Call Response


Intermittent Failure Capture

batch: First Iteration/Batch 21/Wave 2

Episodic Failure Capture

notes: Near-name emphasizing failure episodes rather than intermittent timing.

Rare Event Capture

notes: Useful when intermittent episodes are rare enough that ordinary inspection almost never sees them.

Intermittent Bug Capture

notes: Software-domain name for the same pattern when elusive bugs disappear before inspection.

Triggered Diagnostic Capture

notes: Highlights trigger-based activation of richer evidence capture.

Flight-Recorder Failure Capture

notes: Variant that uses a rolling log or black-box record to preserve evidence.

source_primes: intermittency observability

related_primes: sampling_representativeness state_and_state_transition causality feedback uncertainty accountability resilience fault_tolerance threshold signaling irreversibility

slug: causality

slug: feedback

slug: uncertainty

slug: accountability

slug: signaling

slug: irreversibility

components:
Trigger Condition
Capture Window
State Snapshot
Contextual Trace
Event Log
Evidence Preservation Rule
Recurrence Analysis
Follow-up Diagnostic Path
Capture Budget
Privacy and Safety Filter
Episode Identifier
Reproduction Gate

mechanisms:
Flight Recorder
Trigger-Based Debug Trace
Incident Snapshot
Symptom Diary
Rare Event Monitor
Automatic Diagnostic Capture
Post-Episode Evidence Review
Black Box Log

essence_one_line: Capture evidence during irregular failure episodes so elusive problems can be diagnosed after the episode disappears.

compression_statement: When failures occur intermittently and vanish before ordinary inspection, define episode triggers, capture windows, state snapshots, contextual traces, evidence preservation rules, recurrence analysis, and follow-up diagnostic paths so rare or transient failures become analyzable rather than anecdotal.

core_intuition: The hardest intermittent failures are not merely rare; they are self-erasing. By the time an expert arrives, the system may have recovered, reset, cleaned logs, normalized the symptom, or lost the witness context. Intermittent Failure Capture turns the moment of failure into a preserved evidence packet before that evidence evaporates.

canonical_formula: intermittent_episode + trigger_condition + capture_window + state_snapshot + contextual_trace + evidence_preservation + follow_up_analysis -> diagnosable_failure_record

structural_problem: A failure, symptom, anomaly, or breakdown appears irregularly and cannot be reliably reproduced or inspected during ordinary investigation, so the system repeatedly returns to normal before enough evidence is captured to explain what happened.

description: The problematic state appears in episodes, bursts, or rare windows rather than remaining continuously observable.

description: By the time a person, diagnostic tool, review meeting, or repair process engages, the system has recovered, reset, or changed state.

description: The cause depends on surrounding conditions such as timing, sequence, load, environment, configuration, human action, dependency state, or prior transitions.

description: Logs rotate, symptoms fade, witnesses forget, state is overwritten, or recovery actions erase the evidence needed for diagnosis.

description: The system can preserve some diagnostic evidence without creating unsafe surveillance, excessive overhead, privacy violation, or operational instability.

description: The failure is reported or observed, but testing under normal conditions does not recreate it.

description: The problem disappears when a technician, manager, clinician, investigator, or observer is present.

description: People describe recurring episodes, but the reports lack enough state, timing, and context to support diagnosis.

description: Available records show only the aftermath or recovery, not the preconditions and transitions that generated the episode.

description: The system repeatedly treats episodes as isolated incidents because evidence is too thin to reveal common causes.

root_tension: Diagnosis requires evidence from the failure state, but the failure state is temporary, irregular, and often erased by recovery, cleanup, human memory limits, or normal system operation.

why_not_this_archetype: If the failure remains observable, ordinary diagnosis, repair, or incident response may be sufficient; intermittent capture is unnecessary.

why_not_this_archetype: If the main problem is estimating prevalence or representing a population, Statistical Sampling or Intermittent Sampling is the better parent.

why_not_this_archetype: If the central problem is surviving bursts rather than diagnosing failures, Intermittent Burst Absorption is the better archetype.

why_not_this_archetype: Some evidence should not be captured without consent, minimization, safety boundaries, or legal authority; the archetype must not override those constraints.

why_not_this_archetype: If a controlled reproduction path is available and safe, perturbation testing or ordinary debugging may be more direct.

structural_intervention: Instrument the system, process, or human reporting workflow so that when an intermittent episode occurs, the relevant state, context, sequence, and traces are captured inside a protected window and routed into a diagnostic follow-up path before evidence disappears.

logic: Define what counts as the failure episode and which symptoms, thresholds, anomalies, or reports should trigger capture.

logic: Identify which state variables, contextual conditions, logs, traces, and human observations are most likely to distinguish the episode from normal operation.

logic: Set a capture window that preserves lead-up, occurrence, and recovery evidence rather than only the moment of visible failure.

logic: Implement evidence capture through automation, forms, rolling buffers, diaries, sensors, incident snapshots, or observer protocols suited to the domain.

logic: Freeze, tag, or protect the captured evidence so ordinary cleanup, rotation, repair, or social pressure does not erase it before review.

logic: Analyze captured episodes individually and comparatively to identify recurrent conditions, causal sequences, or safe reproduction paths.

logic: Convert diagnosis into corrective action, instrumentation refinement, prevention, escalation, or a decision to retire the capture setup.

description: Evidence should be preserved while the episode is occurring or immediately after it, not only during later review.

description: Save the state and surrounding conditions that could explain the failure, not merely a record that the failure happened.

description: Make captured evidence durable enough to survive log rotation, resets, recovery routines, memory decay, and handoff gaps.

description: Capture only what is diagnostically relevant, proportionate, and governed by privacy, safety, and resource limits.

description: Every capture setup needs a review owner, analysis path, and rule for revising triggers or retiring the mechanism.

description: The intervention must make transient evidence available after the episode has ended.

description: Captured state, context, timing, and observations must remain associated as one episode record.

description: Capture must not destabilize the system, expose sensitive data unnecessarily, or create unacceptable overhead.

description: Evidence collection must lead to analysis, decision, or learning rather than indefinite accumulation.

description: Triggers, windows, storage, and access rules should be explicit enough to evaluate and improve.

description: Intermittent failures become analyzable because evidence exists after the episode disappears.

description: Investigators can compare preserved state and context instead of relying solely on memory or speculation.

description: Captured evidence shortens the path from episode report to repair, prevention, or escalation.

description: Multiple episodes reveal conditions or sequences that are invisible in isolated reports.

description: The system avoids excessive continuous monitoring or unsafe reproduction attempts by capturing evidence opportunistically.

prose_essence:
Intermittent Failure Capture is the pattern of making elusive failures diagnosable by preserving evidence while the failure is happening. The target problem is not simply that a system fails. The target problem is that the system fails irregularly, then returns to normal before the relevant state, context, sequence, or witness detail can be inspected.

The archetype works by turning a temporary episode into a durable episode record. A trigger condition opens a capture window; snapshots, traces, logs, and contextual details are preserved; the evidence is protected from ordinary cleanup; and a follow-up diagnostic path turns the record into repair, prevention, or better instrumentation.

prose_when_to_use:
Use this archetype when failures or symptoms are real but hard to reproduce, when ordinary inspection arrives after the episode has disappeared, and when diagnosis depends on transient state or context. It is especially useful when continuous full monitoring is too costly, too intrusive, or too noisy, but targeted capture during episodes is feasible.

Good fits include intermittent production bugs, episodic health symptoms, rare equipment defects, safety near misses, field events, and organizational process breakdowns that look normal during scheduled reviews. The pattern is weaker when the failure is continuously visible, when safe reproduction is easy, or when useful capture would violate privacy, consent, safety, or proportionality constraints.

prose_structural_problem:
The structural problem is an evidence timing mismatch. Diagnosis needs information from the failure state, but the failure state is intermittent and self-erasing. Logs rotate, systems reset, symptoms fade, witnesses forget, cleanup routines remove evidence, and people reinterpret episodes after the fact.

This creates recurring root-cause ambiguity. Each episode is treated as isolated or anecdotal because the common sequence across episodes is unavailable. The system may accumulate reports without accumulating diagnosis.

prose_intervention_logic:
The intervention is to design a capture loop around the episode itself. First, define what counts as the failure and what signal should trigger capture. Next, decide what state, context, sequence, and observations would make the episode explainable. Then create a capture window that preserves evidence before, during, and after the visible symptom.

Once evidence is captured, it must be protected. If normal recovery overwrites logs, if records are detached from their episode, or if no one owns review, the pattern fails. The final step is recurrence analysis: compare captured episodes and turn the findings into corrective action, safer reproduction, prevention, or better capture rules.

prose_key_components:
**Trigger Condition** defines the observable sign, threshold, anomaly, or report that starts evidence capture. It must be specific enough to avoid constant noise and sensitive enough to catch episodes before important state is lost.

**Capture Window** defines how much evidence before, during, and after the episode should be retained. The window matters because causes often appear before the visible failure and recovery evidence may explain how the system returned to normal.

**State Snapshot** preserves the internal state at or near the failure moment: configuration, queue state, variable values, resource levels, user/session state, environmental readings, or other domain-specific details.

**Contextual Trace** captures surrounding conditions such as timing, workload, dependency state, user action, medication timing, staffing, weather, or recent changes. The context explains why the episode occurred in this instance.

**Event Log** provides the chronological sequence of signals, actions, transitions, and observations. It lets investigators reconstruct the episode rather than relying on memory.

**Evidence Preservation Rule** prevents captured evidence from being overwritten, normalized away, discarded, or altered before analysis. It is the difference between a useful episode record and a temporary diagnostic artifact.

**Recurrence Analysis** compares episodes to find common preconditions, sequences, triggers, or hidden causes. A single capture may make the problem visible; several captures often make it diagnosable.

**Follow-up Diagnostic Path** assigns review, escalation, reproduction boundaries, and corrective action. Without this path, capture becomes data hoarding rather than diagnosis.

prose_common_mechanisms:
Mechanisms implement the archetype; they are not the archetype itself. A **Flight Recorder** or **Black Box Log** maintains recent state so evidence survives the episode. A **Trigger-Based Debug Trace** or **Automatic Diagnostic Capture** turns on richer evidence collection when a symptom or threshold fires. An **Incident Snapshot** packages state, context, and logs into one preserved record. A **Symptom Diary** lets a person capture episodic human experience when sensors are unavailable. A **Rare Event Monitor** stays ready for low-frequency episodes, and a **Post-Episode Evidence Review** turns captured material into analysis while context is still fresh.

The mechanism choice depends on episode frequency, diagnostic need, privacy risk, cost, and whether evidence is best captured by automation, resilient recording, human reporting, or review workflow.

prose_failure_modes:
A common failure mode is a trigger that fires too late or too narrowly, missing the relevant state. Another is thin capture: the system records that the episode occurred but omits the context needed to explain it. Capture can also overwhelm review capacity when triggers are too broad or evidence packets are too large.

Other failure modes include privacy violations, instrumentation that changes the behavior being diagnosed, evidence stored without analysis, and overinterpretation of a small number of captured episodes. These can be mitigated through capture budgets, minimization, trigger review, access control, and explicit diagnostic ownership.

prose_neighbor_distinctions:
**Intermittent Sampling** detects intermittent states by choosing observation windows or triggers. **Intermittent Failure Capture** preserves richer state and context during actual failure episodes so diagnosis remains possible afterward.

**Observability Instrumentation** broadly exposes system state. Intermittent Failure Capture is narrower: it is episodic, evidence-preserving, and diagnosis-centered.

**Perturbation Testing** tries to induce or reproduce behavior under controlled change. Intermittent Failure Capture waits for naturally occurring episodes and captures evidence when they happen.

**Intermittent Burst Absorption** protects operations from irregular spikes. Intermittent Failure Capture diagnoses elusive failures; it may not absorb or mitigate the episode at all.

**Recurrence Pattern Detection** can analyze captured records, but it is usually a component or follow-on analysis rather than the capture archetype itself.

prose_cross_domain_examples:
In software operations, a rare production bug can trigger expanded traces and state snapshots because ordinary logs are too thin after recovery. In healthcare, a symptom diary can preserve timing, context, and recovery details for episodes absent during appointments. In manufacturing, a defect detector can freeze sensor state, material batch metadata, operator actions, and environmental readings when an intermittent flaw appears.

In safety engineering, black-box logs preserve pre-incident state for post-event investigation. In organizational reliability, teams can record workload, handoff state, decision context, and dependency signals whenever an episodic escalation failure occurs.

prose_non_examples: A daily dashboard of aggregate error rates is not this archetype unless it preserves episode-level failure evidence. A generic bug report saying “it happened again” is not enough because it lacks state and context. Random spot checks for compliance are usually Intermittent Sampling. A burst queue that holds demand during a spike is Intermittent Burst Absorption, not failure capture.

prose_tradeoffs:
Intermittent Failure Capture trades simplicity for diagnostic power. It can add instrumentation overhead, storage cost, workflow burden, and governance complexity. It can also create ethical concerns when captured evidence includes sensitive human behavior, personal data, or security details.

The archetype also trades immediacy for accuracy. Capturing and preserving evidence may slow cleanup or require additional review. In safety-critical contexts, evidence collection must never delay emergency response.

prose_invariants_to_preserve:
The first invariant is that episode evidence must survive beyond the episode. The second is that state, context, timing, and observations must remain linked as one record. The third is that ordinary operation, recovery, and human safety must not be compromised by the capture setup.

A fourth invariant is that capture must remain tied to diagnosis. The intervention is not justified by accumulation alone; it should support review, learning, repair, prevention, or a decision to retire the capture mechanism.

prose_target_outcomes:
The desired outcome is diagnosable failure episodes. Instead of vague reports that a problem “happened again,” the system produces preserved evidence: what state it was in, what conditions surrounded it, what sequence led into it, and what changed afterward.

Successful use reduces root-cause ambiguity, shortens the path to corrective action, reveals recurrence patterns, and reduces dependence on unsafe reproduction attempts or excessive continuous monitoring.

prose_parameter_dimensions:
Important tuning dimensions include trigger sensitivity, trigger specificity, pre-event buffer length, post-event capture duration, snapshot depth, contextual breadth, storage retention, access control, review urgency, false-positive tolerance, and capture overhead.

The central tuning problem is balancing diagnostic power against cost and intrusion. More evidence can reveal causes, but broad capture can create privacy risk, analysis burden, performance impact, and false certainty. The best design captures enough to distinguish the episode from normal operation while minimizing unnecessary exposure.

prose_variants_and_near_names:
Recognized variants include Trigger-Based Diagnostic Capture, Episodic Symptom Capture, Flight-Recorder Failure Capture, and Rare Event Evidence Capture. Near names include Episodic Failure Capture, Rare Event Capture, Intermittent Bug Capture, Triggered Diagnostic Capture, Incident Snapshot, Symptom Diary, and Flight-Recorder Logging.

Simple event loggers, debug traces, incident snapshots, flight recorders, and diaries should collapse into mechanisms unless they include the full trigger, capture-window, preservation, recurrence-analysis, and follow-up logic.

Trigger-Based Diagnostic Capture

Trigger Condition

role: Starts capture when an episode is suspected.

notes: Usually the decisive component in this variant.

Capture Window

role: Bounds pre-event, event, and post-event evidence.

notes: Often extended around the trigger to avoid missing lead-up conditions.

State Snapshot

role: Preserves system state at the triggered moment.

notes: Frequently automated.

Trigger-Based Debug Trace

role: Enables detailed trace collection only when the trigger fires.

Automatic Diagnostic Capture

role: Saves diagnostic evidence at trigger time.

Episodic Symptom Capture

Contextual Trace

role: Captures surrounding circumstances of the episode.

notes: May include human activity, setting, timing, and recent changes.

Event Log

role: Creates a chronological account.

notes: Often a diary, form, or structured report.

Follow-up Diagnostic Path

role: Turns the record into diagnosis or care.

notes: Prevents symptom capture from becoming unmanaged notes.

Symptom Diary

role: Records symptoms and context at the time of occurrence.

Post-Episode Evidence Review

role: Reviews the episode before details fade.

Flight-Recorder Failure Capture

Capture Window

role: Defines how much recent history is retained.

notes: Often implemented as a rolling buffer.

Evidence Preservation Rule

role: Freezes evidence when an episode is detected.

notes: Prevents the rolling buffer from overwriting the relevant window.

Episode Identifier

role: Links records from the same event.

notes: Useful when the record spans multiple subsystems.

Flight Recorder

role: Retains recent state and logs for later diagnosis.

Black Box Log

role: Preserves traces through failure conditions.

Rare Event Evidence Capture

Trigger Condition

role: Recognizes the rare episode.

notes: May be conservative to avoid false positives.

Capture Budget

role: Controls long-running readiness cost.

notes: Important when waiting months or years for the event.

Recurrence Analysis

role: Compares rare captures over time.

notes: May require sparse-evidence reasoning.

Rare Event Monitor

role: Keeps capture readiness for low-frequency events.

Automatic Diagnostic Capture

role: Saves evidence without needing a human present.

near_names:
Episodic Failure Capture
Intermittent Bug Capture
Rare Event Capture
Debug Trace on Trigger
Incident Snapshot
Symptom Diary
Flight-Recorder Logging