Lived Experience Capture

batch: First Iteration/Batch 42

slug: phenomenology

slug: feedback

slug: observability

slug: boundary

components:
Experience Holder
Experience Scope
Elicitation Context
First-Person Account
Contextual Meaning Trace
Experience Pattern
Interpretation Check
Decision Translation
Subjective Evidence Limit
Protection and Consent Boundary
Experience-Holder Sampling Frame
Triangulation Plan
Participant Benefit Path

mechanisms:
Semi-Structured Interview
Diary Study
Journey Map
Ethnographic Observation
Experience Sampling
Narrative Account Collection
Participatory Research Session
Lived-Experience Panel
Contextual Inquiry
Co-Interpretation Workshop

essence_one_line: Capture first-person lived experience so systems are not designed, evaluated, or governed only from external metrics, expert categories, or institutional assumptions.

compression_statement: When a decision affects people whose subjective experience is invisible or misrepresented, Lived Experience Capture identifies whose experience matters, elicits first-person accounts, preserves contextual meaning, synthesizes experience patterns, translates those patterns into action, and states the limits of subjective evidence.

core_intuition: Systems can look successful from the outside while being confusing, burdensome, unsafe, humiliating, inaccessible, or meaningful in ways the official model cannot see. The archetype works by treating lived experience as evidence of how the system is actually encountered, not as noise to be averaged away.

canonical_formula: external_view_only + affected_experience_hidden -> first_person_accounts + contextual_meaning + experience_patterns + decision_translation + evidence_limits

structural_problem: A system, policy, product, process, or evaluation is being designed or judged through external indicators, expert abstractions, institutional categories, or aggregate metrics while the lived experience of affected people remains invisible, distorted, unsafe to express, or disconnected from decisions.

condition: External metrics show what happened but not how people experienced it.

example: A service meets response-time targets while users describe the process as frightening, opaque, stigmatizing, or impossible to navigate.

condition: Expert categories or institutional vocabulary do not match how people make sense of their own situation.

example: A program classifies cases by administrative type while participants describe barriers in terms of trust, dignity, timing, family obligations, or fear of consequences.

condition: A design or policy affects people who were not meaningfully heard during design, evaluation, or revision.

example: A school, clinic, platform, or workplace redesign uses staff assumptions about users rather than accounts from the people most affected.

condition: A problem is known through complaints, churn, avoidance, nonuse, attrition, or informal workarounds, but the experienced cause is unclear.

example: Customers abandon onboarding, employees bypass a workflow, or patients miss appointments, yet existing data does not reveal the lived constraint behind the behavior.

condition: The stakes include harm, exclusion, stigma, dignity, trust, access, or safety.

example: People may face retaliation, shame, re-identification, or institutional consequences if their experience is captured poorly.

condition: Decision-makers risk confusing observation from the outside with experience from the inside.

example: A manager observes that a tool is available, while workers experience it as unusable because of time pressure, surveillance risk, and conflicting incentives.

symptom: High measured compliance with low trust or high resentment

diagnostic_meaning: Actors may be conforming outwardly while experiencing coercion, confusion, or loss of dignity that metrics do not capture.

symptom: Persistent workarounds, avoidance, or nonuse despite formal availability

diagnostic_meaning: The official path may be accessible in theory but experienced as risky, burdensome, illegible, or misaligned with real constraints.

symptom: Expert explanations repeatedly miss what affected people say is central

diagnostic_meaning: The current representation may be over-reliant on external categories and under-reliant on situated meaning.

symptom: Satisfaction scores or surveys do not explain sharp differences across groups or contexts

diagnostic_meaning: Aggregate measurement is flattening variation, context, and subjective interpretation.

symptom: Stakeholders feel consulted but not heard

diagnostic_meaning: Input collection may be extractive or performative rather than anchored in interpretation, decision translation, and feedback.

symptom: Design changes solve visible tasks but leave felt burden unchanged

diagnostic_meaning: The intervention may be optimizing observable steps while missing anxiety, identity threat, stigma, cognitive load, or coordination burden.

root_tension: External observation is necessary for coordination, measurement, and accountability, but it can misrepresent the lived meaning of a system. First-person accounts reveal burden and significance, but they can also be partial, nonrepresentative, or unsafe to collect. The archetype must preserve subjective fidelity while connecting experience to accountable action and evidence limits.

case: The main work is identifying all affected parties, interests, influence, and engagement responsibilities.

case: The main work is fairly distributing credibility, testimony, interpretive resources, and authority in a knowledge process.

case: The main work is integrating social structures and technical infrastructure into a coherent operating system.

case: The main work is validating whether a solution functions in actual context of use, with behavior and constraints as the core evidence.

case: The work only administers a survey, interview, focus group, or empathy map without preserving first-person meaning or translating findings into decisions.

case: The activity is clinical therapy, personal reflection, or trauma processing rather than nonclinical design, evaluation, policy, or governance evidence.

structural_intervention: Create a disciplined evidence pathway from first-person experience to decision-relevant insight: identify whose experience matters, define the experience scope, establish safe elicitation conditions, gather accounts in the person's own terms, preserve contextual meaning, synthesize patterns without erasing variation, check interpretations, translate findings into action, and document subjective evidence limits.

name: Name the decision and the missing inside view

logic: Clarify what decision, design, policy, evaluation, or research question is currently over-reliant on external indicators or expert assumptions.

Identify experience holders

logic: Specify whose lived experience is relevant, including high-burden, excluded, edge-case, dissenting, abandoned, or underrepresented participants.

Define the experience scope

logic: Bound the situation being captured: touchpoint, journey, role, time period, life context, institutional process, harm, or consequence.

Design safe elicitation conditions

logic: Choose methods, settings, languages, consent practices, privacy protections, accessibility supports, and compensation appropriate to the stakes and power dynamics.

Capture first-person accounts

logic: Elicit accounts of perception, burden, meaning, emotion, workaround, trust, fear, dignity, access, timing, and interpretation before translating them into analyst categories.

Trace context and meaning

logic: Connect accounts to material constraints, social relations, institutional histories, incentives, identities, and environmental conditions that shape what the experience means.

name: Synthesize patterns and preserve variation

logic: Identify recurring experience patterns while retaining edge cases, minority experiences, and disagreements that reveal important risks or design failures.

Check interpretation

logic: Validate or contest synthesized findings with experience holders, trusted intermediaries, or transparent review so analyst projection is reduced.

Translate to decision changes

logic: State how the findings alter design requirements, policy criteria, evaluation measures, service processes, governance safeguards, or future research.

name: State evidence limits and follow-up needs

logic: Document what the accounts establish, what they suggest, what remains uncertain, and where additional measurement, causal testing, or representative sampling is needed.

rule: Use lived-experience capture when the inside view is decision-relevant.

rationale: The archetype is not needed for every decision. It matters when subjective burden, meaning, trust, fear, access, dignity, or hidden workaround could change what should be done.

rule: Do not substitute readily available voices for affected experience holders.

rationale: Convenient participants can reproduce institutional assumptions and miss excluded, abandoned, or high-burden experience.

rule: Preserve first-person language before coding it into analyst categories.

rationale: Premature coding can erase meaning, impose expert frames, or convert a lived contradiction into an apparently simple variable.

rule: Treat safety, consent, and privacy as design constraints, not afterthoughts.

rationale: Experience capture can create harm when disclosure exposes people to retaliation, stigma, emotional burden, or re-identification.

rule: Connect findings to a decision path before collecting accounts.

rationale: Capture without action can become extractive listening or empathy theater.

rule: Separate meaning evidence from prevalence or causal evidence.

rationale: First-person accounts can show what something is like and why it matters; additional methods may be needed to estimate frequency, causal effect, or population distribution.

rule: Preserve disagreement when disagreement is informative.

rationale: Averages can hide materially different experiences by role, identity, context, timing, or prior exposure.

rule: Close the loop with participants when feasible and safe.

rationale: Returning findings and action decisions improves accountability and reduces extractive knowledge production.

invariant: First-person fidelity

must_preserve: Accounts should retain how experience holders describe perception, meaning, burden, and interpretation before institutional translation.

invariant: Contextual grounding

must_preserve: Experience is tied to lived conditions, constraints, relationships, incentives, histories, and environments, not treated as isolated opinion.

invariant: Safe and consented capture

must_preserve: Participation, recording, storage, attribution, use, and escalation are governed by clear consent and appropriate protection.

invariant: Decision relevance

must_preserve: Findings connect to a real design, policy, evaluation, governance, or research decision rather than becoming an unused story archive.

invariant: Plurality and edge-case preservation

must_preserve: Synthesis should identify patterns without erasing minority, contested, or high-impact experiences that reveal hidden system failures.

invariant: Evidence-limit explicitness

must_preserve: The draft distinguishes what lived experience can establish from what requires additional measurement, sampling, or causal inference.

invariant: Non-extractive accountability

must_preserve: The process should avoid taking stories without benefit, feedback, protection, or a credible path to influence action.

outcome: More accurate design requirements

description: Designers see burdens, meanings, constraints, and workarounds that external task metrics miss.

outcome: Better policy and governance fit

description: Rules, services, and safeguards better reflect how affected people actually encounter institutions.

outcome: Improved evaluation validity

description: Success criteria incorporate experienced access, dignity, trust, usability, burden, and quality rather than only observable outputs.

outcome: Reduced hidden harm and exclusion

description: Experience holders surface friction, stigma, fear, or harm that may not appear in ordinary reporting channels.

outcome: Stronger interpretation and communication

description: First-person accounts give decision-makers language for what the problem means, not only what the problem measures.

outcome: Better follow-up research questions

description: Experience patterns reveal where additional measurement, causal testing, or representativeness checks are needed.

prose_essence:
Lived Experience Capture is the intervention pattern for bringing the inside view into decisions. It is used when a system has external measurements, expert descriptions, or institutional categories, but the people living through the situation experience it in ways those external views do not show. The archetype does not treat subjective experience as a decorative story. It treats it as a decision-relevant form of evidence that reveals burden, meaning, fear, dignity, trust, confusion, access barriers, workarounds, and hidden harm.

The core move is to ask: whose lived experience would change what we think this system is doing? Once that question is answered, the work becomes disciplined capture, contextual interpretation, pattern synthesis, decision translation, and evidence-limit management.

prose_when_to_use:
Use this archetype when a design, policy, evaluation, service, model, or organizational process is being judged from the outside while the inside view may materially change the decision. It is especially useful when people comply but resent the process, abandon a service that appears available, invent workarounds, distrust a system, avoid formal channels, or report burdens that the official metrics do not capture.

It also applies when an institution has heard opinions but not lived experience. A stakeholder may have interests, authority, or influence without having lived through the relevant condition. Conversely, someone may have little institutional power but possess indispensable knowledge of what the system is like from the inside.

prose_structural_problem:
The structural problem is an evidence asymmetry between external observation and first-person experience. A dashboard may show completion rate, but not dread. A policy file may show eligibility, but not the fear of applying. A workflow may show that a tool is available, but not that using it creates surveillance risk or hidden coordination work. An expert schema may classify a case correctly from the institution's perspective while misdescribing what the person is actually living through.

This asymmetry matters because decisions based only on the external view can optimize the wrong thing. A service can become faster but less dignified. A model can become more accurate but harder to contest. A classroom can improve average performance while leaving a subgroup feeling excluded or unsafe. Lived Experience Capture interrupts that failure by making the experienced reality inspectable before action is taken.

prose_intervention_logic:
The intervention begins by naming the decision that needs the inside view. Then it identifies the experience holders, including people who abandoned, avoided, resisted, or were excluded from the formal system. The team defines the experience scope, designs safe elicitation conditions, and gathers first-person accounts in language that preserves participants' own meanings.

Those accounts are then contextualized. The question is not only "what did someone say?" but "what conditions made that experience intelligible?" A fear, workaround, silence, preference, or complaint may be shaped by power, identity, history, material constraints, incentives, or prior institutional harm. After contextualizing, the team synthesizes experience patterns while preserving important variation and edge cases. It checks interpretations where feasible, translates findings into design or policy decisions, and states what the evidence can and cannot support.

prose_key_components:
### Experience Holder

An experience holder is the person or group whose first-person experience is necessary for understanding the system. This is not the same as a generic stakeholder. The experience holder has lived through the service, policy, condition, process, role, harm, or interaction being interpreted.

### Experience Scope

The experience scope defines which lived situation is being captured. It may be a journey, touchpoint, role, time period, institutional process, harm pattern, or recurring condition. Scope keeps the work actionable and prevents vague story collection.

### Elicitation Context

The elicitation context is the setting and method through which accounts are gathered. It includes language, access, privacy, consent, compensation, facilitation, and power dynamics. Bad elicitation conditions produce silence, self-protection, performance, or institutional scripts rather than lived experience.

### First-Person Account

The first-person account preserves what people report in their own terms: perception, meaning, burden, workaround, fear, trust, dignity, confusion, or emotional texture. The account is evidence of experience, not automatic proof of prevalence or causality.

### Contextual Meaning Trace

A contextual meaning trace links the account to the circumstances that make it meaningful. For example, a missed appointment may be experienced not as forgetfulness but as transportation uncertainty, fear of cost, inflexible work, or distrust built from prior encounters.

### Experience Pattern

An experience pattern is a recurring theme, tension, burden, workaround, or interpretation across accounts. Patterns allow action without flattening every account into a single average. Good synthesis preserves outliers when those outliers reveal high-impact failures.

### Interpretation Check

An interpretation check tests whether the synthesis fairly represents what experience holders meant. This can happen through member review, participatory analysis, trusted intermediaries, advisory panels, or transparent disagreement notes.

### Decision Translation

Decision translation connects findings to action. It states what changes in a requirement, metric, service flow, policy rule, communication, governance safeguard, or research agenda because of the captured experience.

### Subjective Evidence Limit

A subjective evidence limit states what the accounts establish and what they do not. Lived experience may reveal burden and meaning, but population prevalence, causal effect, diagnosis, or prediction may require additional evidence.

### Protection and Consent Boundary

The protection and consent boundary governs privacy, anonymity, data use, compensation, voluntary participation, escalation, and risk of disclosure. It is essential when accounts involve health, identity, harm, work vulnerability, legal risk, or stigma.

prose_common_mechanisms:
Semi-structured interviews implement the archetype by giving people enough structure to answer the decision question while leaving room for unexpected meanings and examples. A diary study implements it over time, capturing experience near the moment it occurs rather than relying only on retrospective memory. Journey maps implement it visually by connecting lived experience to a sequence of touchpoints, frictions, and emotional shifts.

Ethnographic observation and contextual inquiry implement the archetype by pairing situated observation with participant interpretation. Experience sampling captures variation across moments, contexts, and states. Narrative account collection preserves sequence and meaning. Participatory research sessions and co-interpretation workshops increase accountability by involving experience holders in synthesis. Lived-experience panels institutionalize repeated capture and interpretation across decisions.

These mechanisms are not the archetype. They are implementation routes. The archetype is the larger evidence pathway from first-person experience to contextual interpretation, decision translation, and evidence-limit discipline.

prose_failure_modes:
Extractive listening occurs when an institution collects stories without returning benefit, protection, or influence. Anecdote overgeneralization occurs when vivid accounts are treated as statistical proof. Forced category translation occurs when analysts code accounts into institutional labels before preserving participants' meanings. Tokenization occurs when a few available voices are made to stand for a whole group.

Other failure modes include empathy theater, unsafe disclosure, dominant voice capture, and action-path collapse. The most serious safety failures appear when participants describe harm, stigma, or vulnerability without consent, privacy, or support boundaries. The mitigation is to design the capture pathway with protection, decision translation, interpretation checks, and evidence limits from the beginning.

prose_neighbor_distinctions:
Lived Experience Capture is distinct from Stakeholder Mapping and Engagement. Stakeholder mapping asks who is affected, influential, responsible, or legitimate to engage; lived experience capture asks what the system is like from the inside for those who live through it.

It is distinct from Epistemic Inclusion Design. Epistemic Inclusion Design governs who is believed, represented, and given interpretive resources in a knowledge process. Lived Experience Capture supplies a disciplined way to collect and translate experience evidence, but it does not by itself solve all credibility or participation governance problems.

It is distinct from Bottom-Up Signal Integration because it does not merely move local signals upward. It preserves subjective meaning. It is distinct from Sociotechnical Integration because it does not redesign the whole social and technical system; it informs such redesign. It is distinct from Empathy Mapping because empathy maps are artifacts or mechanisms, not the full intervention logic.

prose_cross_domain_examples:
In healthcare, the archetype captures patient and caregiver experience of discharge, medication burden, dignity, and follow-up barriers. In product design, it captures why users abandon a flow despite technically correct functionality. In public policy, it captures how eligible people experience application processes as threatening, confusing, or impossible. In education, it captures how students experience learning conditions that are invisible in grades or attendance. In organizational change, it captures frontline experience of tools, incentives, workload, and hidden coordination.

In AI governance, it can capture how people experience automated decisions, contestability, opacity, and burden of proof. In each domain, the point is not to collect stories for illustration. The point is to change design, policy, evaluation, or governance based on a better account of experienced reality.

prose_non_examples: A stakeholder map is not Lived Experience Capture if it only lists affected parties. A survey dashboard is not this archetype if it only reports averages without first-person meaning. An empathy map is not this archetype if designers fill it with assumptions. A public comment session is not this archetype if the decision is already final. A therapy session is not this archetype because its purpose is clinical or personal support rather than nonclinical design, evaluation, or governance evidence.

prose_tradeoffs:
The main tradeoff is depth versus representativeness. Deep accounts preserve meaning but may not show distribution; broad capture can show coverage but may flatten experience. Another tradeoff is specificity versus privacy. Detailed accounts help decision-makers act, but they can expose participants to risk. A third tradeoff is fidelity versus translation. Participants' language should be preserved, yet decisions often require synthesis into requirements, rules, or measures.

There is also a speed versus trust tradeoff. Rapid capture may be useful for urgent design changes, while vulnerable or historically excluded groups may require relationship-building before people can speak safely. Finally, confidentiality can conflict with accountability: anonymous capture may protect people but make follow-up and verification harder.

prose_invariants_to_preserve:
The first invariant is first-person fidelity: the account should not be immediately overwritten by institutional categories. The second is contextual grounding: experience must be interpreted in relation to the conditions that shape it. The third is consent and safety: people should not have to expose themselves to institutional risk to be heard.

The fourth invariant is decision relevance. Lived experience capture should inform action, not merely generate emotional resonance. The fifth is plurality: synthesis should preserve minority, edge, and dissenting experiences when they matter. The sixth is evidence-limit explicitness: the work should distinguish meaning evidence from prevalence, causal, diagnostic, or predictive evidence.

prose_target_outcomes:
A successful use of the archetype produces better design requirements, more valid evaluation criteria, fairer policy interpretation, and more accurate understanding of hidden burden. It can reveal why people avoid a system, why formal access does not feel usable, why a process undermines dignity or trust, and why a technically correct solution fails in lived context.

The target outcome is not simply empathy. It is improved action under a richer account of reality. The institution should be able to say what it learned from experience holders, how that learning changed a decision, and what uncertainties remain.

prose_parameter_dimensions:
The first tuning dimension is scope. A project may capture a single touchpoint, a full service journey, a recurring role, a life transition, or a community-level experience. The second is depth versus breadth: a few deep accounts may reveal meaning, while broader sampling may reveal coverage and variation. The third is timing: capture can be retrospective, in-the-moment, longitudinal, or repeated after redesign.

Other dimensions include structure versus openness, individual narrative versus collective pattern, anonymity versus follow-up, expert-led versus participatory interpretation, and direct decision translation versus exploratory learning. Safety intensity also varies. Ordinary usability work may need standard consent and privacy; harm-related capture may require stronger protections, minimization, independent facilitation, and nonclinical referral boundaries.

prose_variants_and_near_names:
Recognized variants include User Experience Capture, Patient Experience Capture, Employee Experience Capture, Community Lived Experience Capture, and Harm Experience Capture. These variants differ by domain, safeguards, and translation path, but they share the same parent logic: identify experience holders, elicit first-person accounts, preserve context, synthesize patterns, translate findings, and state evidence limits.

Near names include phenomenological inquiry, voice of customer, user research, stakeholder interview, diary study, journey mapping, and empathy mapping. These should not automatically become archetypes. Most are mechanisms, domain labels, or broader practices. They belong under this archetype only when they are used to capture lived experience for decision-relevant interpretation.

User Experience Capture

short_definition: Captures first-person experience of using, adopting, avoiding, or working around a product, service, interface, or process.

distinctive_feature: The decisive evidence is the user's interpreted experience of a product or service in context, not only task success, satisfaction score, or observed behavior.

distinct_from_parent: The parent applies across policy, healthcare, organizations, research, and design. This variant is specifically product/service/user-context focused.

still_same_parent_because: The same logic applies: identify experience holders, elicit first-person accounts, synthesize patterns, translate findings, and state evidence limits.

use_when: A design team has behavioral or usage metrics but does not understand what the interaction feels like or means to users.

use_when: Usability problems, trust breakdowns, onboarding barriers, or workarounds are visible but not explained by external data.

Experience Scope

role: Defines product, service, or process touchpoints.

Decision Translation

role: Connects findings to design or roadmap decisions.

Contextual Inquiry

mechanism_type: method

role: Observes use while eliciting interpretation.

Journey Map

role: Visualizes experience across touchpoints.

domain: Product design

example: Capturing how first-time users experience onboarding confusion that analytics only show as drop-off.

domain: Public service

example: Capturing how applicants experience document requirements and waiting periods.

failure_modes: Reducing lived experience to preference polling rather than understanding meaning, constraint, burden, and workaround.

failure_modes: Only listening to active or easy-to-reach users while excluding people who abandoned the service.

Patient Experience Capture

short_definition: Captures first-person accounts of illness, care access, treatment burden, communication, dignity, and system navigation.

distinctive_feature: The capture must handle vulnerability, privacy, health uncertainty, caregiver roles, and the difference between clinical outcome and lived burden.

distinct_from_parent: The parent is cross-domain; this variant adds healthcare-specific safeguards and translation into care pathways, service design, or quality improvement.

still_same_parent_because: It still uses first-person accounts as evidence of experienced system effects and translates patterns into decisions with evidence limits.

use_when: Clinical or operational metrics miss what care feels like to patients, families, or caregivers.

use_when: Decision-makers need to understand burden, access friction, trust, communication, stigma, or quality of life from the patient perspective.

Protection and Consent Boundary

role: Protects sensitive health and identity information.

Subjective Evidence Limit

role: Separates patient-reported burden from diagnostic or causal claims that need clinical evidence.

Patient Story Collection

role: Collects care narratives and experience themes.

Lived-Experience Panel

role: Advises on care design and interpretation.

domain: Healthcare

example: Capturing patients' experience of post-discharge instructions to redesign follow-up support.

domain: Public health

example: Capturing vaccination-access barriers from people who do not appear in clinic-based data.

failure_modes: Using patient stories as inspirational anecdotes without changing care design or quality measures.

failure_modes: Overclaiming clinical causality from subjective accounts without triangulation.

Employee Experience Capture

short_definition: Captures workers' first-person experience of roles, processes, incentives, culture, workload, safety, and constraints.

distinctive_feature: Power asymmetry and retaliation risk shape what can be said; safe capture and interpretation checks are central.

distinct_from_parent: The parent is domain-general; this variant focuses on workplace roles, labor conditions, hierarchy, and organizational change.

still_same_parent_because: It still captures first-person accounts, synthesizes experience patterns, and translates them into decisions with evidence limits.

use_when: Leadership sees performance, retention, or engagement metrics but does not understand the lived operating conditions behind them.

use_when: A process redesign needs to account for hidden work, informal coordination, fear, overload, or moral injury.

Protection and Consent Boundary

role: Prevents retaliation or forced disclosure.

Contextual Meaning Trace

role: Connects accounts to incentives, workload, hierarchy, and norms.

Confidential Listening Session

mechanism_type: ritual

role: Elicits workplace experience under privacy protections.

Work Shadowing

role: Pairs observation with worker interpretation.

domain: Operations

example: Capturing frontline workers' experience of a scheduling tool that increases hidden coordination burden.

domain: Safety culture

example: Capturing why near-miss reporting feels risky despite formal no-blame policy.

failure_modes: Asking workers to disclose risk without protection or action path.

failure_modes: Treating experience capture as morale management rather than evidence for operational redesign.

Community Lived Experience Capture

short_definition: Captures community members' lived experience of a policy, institution, environment, service, risk, or exclusion pattern.

distinctive_feature: The capture must handle plural voices, representation risk, community trust, and non-extractive benefit paths.

distinct_from_parent: The parent can capture any lived experience. This variant emphasizes collective and community-level experience in governance or policy decisions.

still_same_parent_because: It remains centered on first-person and situated accounts translated into design, policy, or evaluation choices.

use_when: Policy or institutional design relies on aggregate indicators while affected community meaning, burden, distrust, or informal adaptation remains invisible.

use_when: The decision requires understanding experience across social location, place, language, access, and historical relation to an institution.

Experience-Holder Sampling Frame

role: Includes edge, excluded, and high-burden voices.

Participant Benefit Path

role: Prevents extractive consultation.

Community Listening Session

role: Collects situated accounts and priorities.

Participatory Research Session

role: Involves community members in interpretation.

domain: Urban planning

example: Capturing residents' experience of transit changes that official ridership data cannot explain.

domain: Environmental governance

example: Capturing lived burden of noise, odor, or risk that monitoring stations miss.

failure_modes: Tokenizing a few speakers as if they represent a whole community.

failure_modes: Collecting stories without returning findings, benefits, or decision influence.

Harm Experience Capture

short_definition: Captures first-person accounts of experienced harm, burden, stigma, exclusion, fear, or unsafe conditions with elevated safeguards.

distinctive_feature: Safety, consent, minimization, referral boundaries, and non-extractive handling are as important as the account itself.

distinct_from_parent: The parent includes ordinary design and evaluation uses. This variant applies when harm and vulnerability require stronger protections.

still_same_parent_because: The core logic still captures first-person experience and translates patterns into decisions, with stated evidence limits.

use_when: The system may be causing harm that is not visible in ordinary metrics or complaint channels.

use_when: Experience holders may face stigma, retaliation, re-identification, or emotional burden when describing what happened.

Protection and Consent Boundary

role: Defines safeguards before capture begins.

Subjective Evidence Limit

role: Avoids unsupported diagnosis, blame, or causal overclaim.

Trauma-Informed Interview Protocol

mechanism_type: protocol

role: Guides safe elicitation without forced disclosure.

Anonymous Harm Report Channel

mechanism_type: interface

role: Allows lower-risk reporting of sensitive experience.

domain: Workplace safety

example: Capturing how workers experience a reporting process as retaliatory despite formal protections.

domain: Platform governance

example: Capturing users' experience of harassment-reporting friction and fear of exposure.

failure_modes: Requiring people to relive harmful events for institutional learning without consent, support, or action path.

failure_modes: Publishing identifiable narratives or using accounts punitively without clear consent and governance.

near_names:
Phenomenological Inquiry
Stakeholder Interview
Diary Study
Journey Mapping
Empathy Mapping
Voice of Customer
User Research
Lived-Experience Panel


Load Balancing

type: archetype

related_primes: flow network coupling resource_management constraint queueing observability scalability resilience robustness scheduling trade_offs fairness

essence_one_line: Distribute incoming work across multiple viable receivers by capacity, health, or policy so no part is overloaded while usable capacity sits idle.

prose_failure_modes:
Common failure modes include:

- **Hot spot creation** — The balancing policy unintentionally concentrates load.
- **Stale capacity signal** — Assignments are based on outdated receiver state.
- **Unhealthy receiver selection** — Work continues flowing to failed or degraded receivers.
- **State affinity violation** — Work is routed to a receiver that lacks needed context or ownership.
- **Thrashing or route flapping** — Work shifts too rapidly between receivers.
- **Central balancer bottleneck** — The balancer itself becomes overloaded or critical.
- **Fairness collapse** — Some receivers, workers, regions, or users bear disproportionate load.
- **Hidden shared bottleneck** — Balanced receivers still depend on the same constrained backend.
- **Capacity fragmentation** — Small pools cannot help each other effectively.
- **Overload migration** — The hot spot moves rather than disappearing.
- **Sticky session pathology** — Affinity rules prevent useful redistribution.
- **Feedback lag** — The system reacts after overload has already accumulated.
- **Treating equal split as balance** — Equal distribution ignores real differences in capacity or suitability.

These failure modes should be treated as part of the archetype's design space.

prose_tradeoffs:
Load Balancing accepts routing and coordination costs in order to improve capacity use and resilience.

Typical tradeoffs include:

- **Routing complexity increases** because work must be assigned intelligently.
- **Coordination overhead rises** because receiver state must be tracked.
- **State affinity may constrain distribution** when work cannot safely move freely.
- **Receiver quality may vary** and balancing may send work to less capable nodes.
- **Monitoring burden increases** because load, health, and outcomes must be observed.
- **Fairness and efficiency may conflict** when the most efficient assignment creates unequal burden.
- **Overcorrection can occur** if the system shifts too much work away from a perceived hot spot.
- **The balancer can become a bottleneck or failure point** if not designed carefully.

The archetype is therefore not merely “spread things out.” It is a governed assignment strategy under capacity and reliability constraints.

prose_invariants_to_preserve:
Load Balancing should preserve explicit invariants:

- **Work is sent only to viable receivers** — Unhealthy or incapable receivers should not continue receiving ordinary work.
- **Assignment policy is defined** — The system should know why work goes where it goes.
- **Capacity or health signal is not ignored** — Balancing should respond to meaningful receiver conditions.
- **Stateful work preserves required affinity or consistency** — Redistribution should not break sessions, transactions, ownership, or context.
- **No receiver is overloaded while equivalent capacity remains idle** — Avoidable hot spots should be corrected.
- **Failed or unhealthy receivers are removed or downweighted** — The policy should not treat all receivers as equal when they are not.
- **The balancing layer does not silently drop work** — Assignment failure should be explicit.
- **Critical work preserves priority or safety requirements** — Distribution should not undermine priority policies.

If these invariants cannot be preserved, load balancing may create instability, inconsistency, or hidden failure.

Capacity-Aware Routing

short_definition: Route work or flow based on current or expected capacity across multiple receiving paths.

distinctive_feature: The distinctive feature is distribution based on capacity signals.

distinct_from_parent: Load balancing is general distribution; this variant explicitly uses capacity signals.

still_same_parent_because: It remains load balancing because the intervention distributes load across alternatives.

source_primes: flow resource_management observability network

use_when: Capacity differs or changes across receivers.

example_domains:
SRE
operations
workforce management
public services

failure_modes: Distribution hides structural undercapacity.


Load Leveling / Demand Smoothing

related_primes: flow queueing scheduling resource_management constraint variability intermittency periodicity threshold margin_of_safety trade_offs time_preference feedback observability scalability

essence_one_line: Redistribute demand or work over time to smooth destabilizing peaks and preserve stable utilization.

prose_failure_modes:
Common failure modes include:

- **Peak migration** — Demand shifts from one peak to another.
- **Hidden backlog** — Work is delayed but not visibly accounted for.
- **Starvation of shifted work** — Smoothed or deferred work never receives service.
- **Fairness collapse** — Less powerful users receive worse time slots or longer delays.
- **Demand suppression disguised as smoothing** — The policy reduces access rather than redistributing timing.
- **Over-smoothing** — The system delays too much and underuses available capacity.
- **Under-smoothing** — Peaks remain too high despite the policy.
- **Brittle schedule** — The timing policy cannot adapt to variation.
- **Misclassified urgency** — Urgent work is incorrectly shifted.
- **Queue buildup behind smoothed intake** — The apparent peak falls while internal backlog grows.
- **Incentive gaming** — Actors manipulate timing categories to get better slots.
- **Planning overhead exceeds benefit** — The smoothing system becomes too complex.
- **False average-capacity confidence** — Smooth averages hide unresolved local or temporal stress.

These failure modes should be treated as part of the archetype's design space.

prose_tradeoffs:
Load Leveling / Demand Smoothing accepts reduced immediacy in exchange for stable utilization.

Typical tradeoffs include:

- **Service or consumption is delayed** for some work or users.
- **Spontaneity declines** because demand must be scheduled or paced.
- **Planning overhead increases** because timing must be managed.
- **Some capacity may be underutilized** if smoothing overcorrects.
- **Fairness tensions arise** over who gets peak access and who is shifted.
- **Demand may migrate to new peaks** if many actors shift to the same alternative time.
- **Coordination burden rises** because calendars, incentives, or release rules must be maintained.
- **Stakeholders may experience inconvenience** when preferred timing is unavailable.
- **Real-time responsiveness may decline** if the system becomes too schedule-bound.

The archetype is therefore a temporal tradeoff: it exchanges immediacy and simplicity for stability and smoother capacity use.

prose_invariants_to_preserve:
Load Leveling / Demand Smoothing should preserve explicit invariants:

- **Urgent or nonshiftable work remains protected** — Smoothing should not delay what must happen now.
- **Shifted demand receives a defined service path** — Delayed work should not disappear.
- **Backlog does not grow unbounded** — Smoothing must not hide unmet demand.
- **True capacity shortfall is not hidden** — The policy should distinguish peak timing problems from total capacity insufficiency.
- **Timing policy is auditable** — The system should know who or what is shifted and why.
- **Fairness and access constraints are preserved** — Inconvenient timing should not always fall on the same group.
- **Peak reduction does not create worse peaks elsewhere** — The system should monitor secondary concentrations.
- **Service quality floor is preserved** — Smoothing should not degrade service below acceptable levels.

If these invariants cannot be preserved, the system may need capacity expansion, load shedding, rate limiting, or redesign rather than smoothing.

Peak Shaving

short_definition: Reduce or shift peak demand so capacity is not overwhelmed during high-load intervals.

distinctive_feature: The distinctive feature is reducing peak intensity over time.

distinct_from_parent: Load leveling/demand smoothing is broad; peak shaving specifically targets high-load peaks.

still_same_parent_because: It remains demand smoothing because the intervention redistributes demand temporally.

source_primes: flow queueing scheduling variability

use_when: Demand has peaks that exceed comfortable capacity.

use_when: Demand can be shifted, smoothed, delayed, or incentivized.

example_domains:
energy
operations
public services
education

failure_modes: Demand is suppressed rather than redistributed.


Load Shedding

related_primes: flow constraint threshold queueing resource_management trade_offs resilience fault_tolerance fail_safe coupling observability scheduling

essence_one_line: Deliberately drop, deny, or defer lower-priority load under overload so critical function stays within viable bounds.

prose_failure_modes:
Common failure modes include:

- **Arbitrary shedding** — Load is sacrificed without explicit priority or fairness policy.
- **Wrong load shed** — Critical work is dropped while less important work continues.
- **Priority inversion** — Lower-priority work consumes protected capacity.
- **Silent drop** — Work disappears without acknowledgment or safe handling.
- **Starvation** — Some class of work is repeatedly shed and never served.
- **Fairness collapse** — Sacrifice falls disproportionately on a group, region, user class, or component.
- **Hidden backlog** — Shed or deferred work accumulates elsewhere.
- **Oscillatory shedding** — The system repeatedly sheds and re-admits load near a threshold.
- **Reputational damage** — Stakeholders lose trust because denial appears arbitrary.
- **Shedding becomes normalized** — Temporary sacrifice becomes ordinary operating practice.
- **Gaming priority labels** — Actors misclassify their work to avoid being shed.
- **Collapse despite shedding** — The policy sheds too little, too late, or the wrong load.

These failure modes should be treated as part of the archetype's design space.

prose_tradeoffs:
Load Shedding accepts explicit loss or denial to prevent broader collapse.

Typical tradeoffs include:

- **Some work is denied, dropped, or lost** rather than completed.
- **Completeness declines** because the system no longer serves everything.
- **Fairness tensions increase** because some load classes are sacrificed before others.
- **User or stakeholder experience degrades** for affected parties.
- **Low-priority value may still be real value** and may be lost.
- **Policy complexity rises** because load classification and sacrifice rules must be maintained.
- **Reputation or trust may suffer** if shedding feels arbitrary or opaque.
- **Misclassification can be costly** when important load is incorrectly shed.

The archetype is therefore a survival-oriented intervention, not an optimization routine.

prose_invariants_to_preserve:
Load Shedding should preserve explicit invariants:

- **Critical load remains serviceable** — The protected function or class actually retains capacity.
- **Shed load is handled explicitly** — Removed work is dropped, rejected, expired, deferred, or retried according to policy.
- **Accepted work is not silently lost** — Work that the system claims to accept must be completed, cleanly rejected, or safely deferred.
- **Shedding policy is auditable** — Operators or stakeholders can understand what was shed and why.
- **Safety and integrity are not sacrificed** — Shedding should not corrupt state, hide acknowledged work, or endanger protected participants.
- **Queue growth remains bounded** — The system must not merely move overload into an invisible backlog.
- **Recovery remains possible** — The system can return to normal operation when overload subsides.
- **Priority rules do not create unacceptable harm** — Sacrifice must remain within ethical, legal, and operational constraints.

If these invariants cannot be preserved, load shedding may become arbitrary harm rather than controlled sacrifice.

Selective Rejection

short_definition: Reject or drop lower-priority inflow to preserve viability for remaining work or users.

distinctive_feature: The distinctive feature is intentional refusal/drop rather than slowdown or buffering.

distinct_from_parent: Load shedding is broader; this variant emphasizes rejection at the admission boundary.

still_same_parent_because: It remains load shedding because the system sacrifices some load to preserve viability.

source_primes: flow constraint priority resource_management

use_when: The system cannot serve all incoming load.

use_when: Some load can be rejected or deferred without violating core priorities.

example_domains:
SRE
utilities
public services
triage

failure_modes: Rejection hides capacity underinvestment.


Local-Chart Atlas Modeling

source: generated

batch: Batch 13

canonical_family: State Spaces & Symmetry

source_primes: manifold topology local_to_global_aggregation continuity phase_space representation navigation

related_primes: fixed_point neighborhood embedding metric vector_space projection constraint invariance scale state_and_state_transition boundary decomposition aggregation path_dependence

slug: manifold

slug: topology

slug: continuity

slug: representation

slug: navigation

slug: neighborhood

slug: embedding

slug: metric

slug: projection

slug: constraint

slug: invariance

slug: scale

slug: decomposition

slug: aggregation

components:
Manifold Hypothesis Scope
Local Chart Domain
Local Coordinate Vocabulary
Chart Boundary Condition
Overlap Region
Transition Map
Global Atlas Index
Global Invariant Set
Seam Consistency Check
Distortion Budget
Navigation Path Rule
Atlas Update Rule
Hole or Loop Marker
Chart Owner
Embedding Preservation Target
Boundary Case Library

mechanisms:
Chart Atlas Map
Overlap Transition Table
Round-Trip Consistency Test
Neighborhood Preservation Probe
Local Model Ensemble with Gating
Boundary Case Path Trace
Coordinate Translation Protocol
Geodesic or Path-Distance Audit
Atlas Stewardship Review
Manifold Learning Diagnostic

essence_one_line: Use overlapping local maps when one global map distorts the terrain: model locally, stitch through verified transition rules, and monitor global consistency.

compression_statement: Local-Chart Atlas Modeling applies when a problem space behaves simply within neighborhoods but becomes curved, folded, path-dependent, or topologically awkward at whole-system scale. Instead of forcing one universal coordinate frame, taxonomy, workflow, metric, or model, the archetype divides the space into meaningful local charts, defines where each chart is valid, verifies overlaps, creates transition maps between charts, preserves global invariants, and gives users or algorithms navigation rules for moving across the atlas without losing meaning.

core_intuition: A globe cannot be flattened into one map without distortion, but a set of overlapping maps can be useful if each map declares its local validity and the seams are governed. The same structure appears in data embeddings, user journeys, organizational operating models, medical pathways, and complex state spaces: local reasoning is often sound, but treating one local view as universal creates tears, folds, blind spots, and broken handoffs.

canonical_formula: Atlas = {local charts C_i with domains U_i} + {overlap tests U_i ∩ U_j} + {transition maps T_ij} + {global invariants G}; apply local reasoning inside U_i, switch via T_ij on overlaps, and reject actions that violate G or produce unresolved seam distortion.

structural_problem: A system is represented as if one flat, universal frame can describe all relevant cases, states, paths, segments, territories, or meanings. In reality, local neighborhoods are tractable while the global space is curved, folded, multi-regional, path-dependent, or connected in non-obvious ways. The single-frame representation then hides distortion: local models extrapolate outside their domain, handoffs lose variables, navigation crosses seams without translation, and global claims become artifacts of the chosen projection.

trigger_conditions: Local models, categories, maps, or workflows work well in some neighborhoods but fail when applied globally.

trigger_conditions: A single coordinate system, taxonomy, dashboard, policy, routing model, or user journey forces incompatible regions into one frame.

trigger_conditions: Transitions between segments, states, jurisdictions, contexts, levels, or regimes require translation rather than simple continuation.

trigger_conditions: Distances, similarities, rankings, or nearest-neighbor claims depend heavily on which local representation is used.

trigger_conditions: Path history matters: reaching the same apparent state through different routes changes what is valid next.

trigger_conditions: The system has holes, loops, seams, folds, boundary cases, or disconnected-looking regions that still interact.

trigger_conditions: A dimensionality-reduction, embedding, or visualization is used for navigation or decision-making and needs neighborhood and seam validation.

trigger_conditions: Stakeholders repeatedly argue from a locally valid map as though it were the whole terrain.

symptoms: Global dashboards look clean but local teams report that the categories do not fit their cases.

symptoms: A model performs well inside familiar regions and makes brittle or absurd recommendations near transition zones.

symptoms: Users, patients, tasks, or cases move between local workflows and lose state, context, ownership, or eligibility meaning.

symptoms: A projection, visualization, or summary map makes far-apart cases appear adjacent or nearby cases appear unrelated.

symptoms: Boundary cases accumulate manual exceptions because the representation has no explicit overlap region.

symptoms: Navigation instructions are locally clear but globally inconsistent, creating loops, dead ends, or invalid shortcuts.

symptoms: Different teams maintain separate local maps but lack transition rules for translating between them.

symptoms: Attempts to standardize everything into one model either erase needed local distinctions or create an unwieldy universal schema.

root_tension: The archetype manages the tension between local tractability and global coherence. One global frame is convenient but distorts; many local frames are accurate but fragment. The solution is not to choose one side, but to govern the seams between local views so local validity and global consistency can coexist.

anti_signatures: The main task is simply to map possible system states and trajectories; use phase_space_mapping unless local chart domains and transition maps are central.

anti_signatures: The main task is to preserve existing connectivity while changing a system; use topology_preserving_transformation when no atlas of local views is needed.

anti_signatures: The main task is reducing variables to reveal signal; use dimensionality_reduction_for_signal unless local-to-global chart validity is the intervention.

anti_signatures: The main risk is high-dimensional evidence sparsity or distance collapse; use high_dimensional_tractability_control unless the problem is global geometry/seam governance.

anti_signatures: The main task is a generic problem map of states, actions, and goals; use problem_space_mapping unless one map cannot cover the space without distortion.

anti_signatures: The main task is to smooth abrupt service, rule, or state transitions; use continuity_preservation when chart overlap and global topology are secondary.

anti_signatures: The space is genuinely homogeneous, flat, and well served by one validated schema, metric, workflow, or coordinate frame.

structural_intervention: Replace a forced universal representation with an atlas: define local chart domains, validate each chart internally, identify overlap regions, specify transition maps, preserve global invariants, and maintain navigation/update rules so local reasoning remains usable without pretending it is globally universal.

action_logic: State the manifold hypothesis: why the space is locally tractable but globally non-trivial, and what kinds of distortion a single frame creates.

action_logic: Identify local chart domains: neighborhoods, segments, contexts, regimes, territories, user states, model regions, or operating modes where one representation is valid.

action_logic: Define the coordinate vocabulary, variables, labels, metric, workflow semantics, or decision rules used inside each chart.

action_logic: Mark chart boundaries and overlap regions where more than one local representation should apply.

action_logic: Create transition maps that translate state, meaning, units, ownership, eligibility, coordinates, or decision context between overlapping charts.

action_logic: Validate seam consistency: round trips, boundary cases, preserved invariants, and local-to-global aggregation checks.

action_logic: Build an atlas index that tells users or algorithms which chart to use, when to switch, and what uncertainty or distortion applies.

action_logic: Test navigation paths across multiple charts for loops, invalid shortcuts, loss of state, discontinuities, and hidden holes.

action_logic: Monitor drift: revise charts, overlaps, and transitions when local domains shift or new regions appear.

decision_rules: Do not treat a local chart as global unless its domain of validity has been tested against out-of-region cases.

decision_rules: Prefer multiple local charts when a single global schema creates large distortion or exception burden.

decision_rules: Require explicit transition maps for every common handoff, segment crossing, regime change, or coordinate translation.

decision_rules: Treat overlap regions as first-class test cases rather than as noise, edge cases, or manual exceptions.

decision_rules: Preserve named global invariants even when local chart vocabularies differ.

decision_rules: If two charts cannot be reconciled on their overlap, expose the conflict instead of hiding it in a global average.

decision_rules: Do not use embedding or visualization proximity for decisions until neighborhood preservation and seam distortion have been validated.

decision_rules: Retire or split a chart when its local error, exception rate, or boundary ambiguity exceeds the agreed tolerance.

target_invariants: Each local chart states what region it covers and what assumptions make it valid.

target_invariants: Transitions between charts preserve the variables, meanings, obligations, or states required for downstream action.

target_invariants: Overlap tests reveal contradiction rather than suppressing it through averaging or ad hoc manual translation.

target_invariants: Global invariants remain visible across all local representations.

target_invariants: Navigation paths can be audited from origin chart to destination chart.

target_invariants: Projection, compression, or visualization does not silently create false adjacency or hide holes.

target_invariants: Chart maintenance has owners and update triggers.

expected_outcomes: Local teams, models, or users keep the accuracy of local representations without losing cross-region coherence.

expected_outcomes: Boundary cases and handoffs become designed overlap regions instead of recurring exceptions.

expected_outcomes: Global decisions rely on stitched, validated local knowledge rather than one distorted universal frame.

expected_outcomes: Navigation across complex spaces becomes more reliable because chart choice and chart switching are explicit.

expected_outcomes: Embedding, visualization, or segmentation tools are safer because neighborhood and seam claims are tested.

expected_outcomes: Organizations can standardize invariants while allowing local variation where one-size-fits-all representation fails.

Mathematical Chart-Atlas Modeling

short_definition: Use formal chart domains, transition functions, and compatibility conditions to reason on a manifold-like state space.

distinctive_feature: It uses formal chart, atlas, and transition-function vocabulary.

distinct_from_parent: The parent is cross-domain; this variant is closest to the mathematical origin of the manifold prime.

still_same_parent_because: It uses the same local-domain, overlap, transition, and global-invariant logic.

source_primes: manifold topology continuity

use_when: The object of work is explicitly mathematical or dynamical.

use_when: Local coordinate systems are valid but no single global coordinate system is adequate.

example: A nonlinear state manifold is analyzed through local linearizations with transition checks between neighborhoods.

Embedding Manifold Validation Atlas

short_definition: Validate whether an embedding or manifold-learning representation preserves local neighborhoods and usable transitions before decisions rely on it.

distinctive_feature: The atlas is implemented through embedding diagnostics and neighborhood preservation tests.

distinct_from_parent: The parent covers all local-chart atlases; this variant centers computational embeddings.

still_same_parent_because: It still requires local domains, overlap/seam tests, transition logic, and global invariant checks.

source_primes: manifold embedding dimensionality_reduction metric

use_when: A computational embedding is used for search, clustering, recommendation, anomaly detection, or navigation.

use_when: Local and path-based distances matter operationally.

example: An embedding is checked for false neighbors and seam artifacts before nearest-neighbor recommendations are trusted.

Organizational Journey Atlas

short_definition: Model local workflows, roles, and statuses as charts in a larger operating atlas with explicit handoff transitions.

distinctive_feature: The chart transitions are organizational handoffs and status translations.

distinct_from_parent: The parent is not limited to organizations; this variant centers operating model seams.

still_same_parent_because: It still uses chart domains, overlaps, transition maps, and invariants.

use_when: Different units or journey stages use locally valid rules.

use_when: Cases, people, or work items cross units and lose context at seams.

domain: healthcare

example: Emergency, specialty, rehabilitation, and chronic-care teams maintain local charts joined by handoff transition maps.

near_names:
Manifold-Aware Modeling
Local Chart Atlas Design
Patchwise Global Representation
Manifold Learning


name: Local-Disturbance / Global-Effect Tracing

batch: First Iteration/Batch 35

Local-to-Global Shock Tracing

notes: Useful when the initiating disturbance is a shock.

Disturbance Propagation Mapping

notes: Often names the mapping activity rather than the full archetype.

Small-Cause / Large-Effect Tracing

notes: Use cautiously because it can drift into metaphor without propagation evidence.

source_primes: turbulence nonlinearity scale

related_primes: amplification damping perturbation threshold diffusion instability coupling feedback

slug: turbulence

slug: nonlinearity

slug: amplification

slug: damping

slug: perturbation

slug: threshold

slug: diffusion

slug: instability

slug: coupling

slug: feedback

components:
Disturbance Source
Local Context State
Propagation Channel
Amplification Pathway
Damping Point
Scale Transition
Global Effect Signature
Intervention Point
Temporal Lag Profile
Cascade Boundary
Reorganization Indicator
Monitoring Trigger

mechanisms:
Systemic Risk Tracing
Supply-Chain Shock Analysis
Ecological Disturbance Mapping
Incident Blast-Radius Analysis
Financial Contagion Tracing
Rumor or Failure Propagation Map
Infrastructure Cascade Analysis
Disturbance Scenario Stress Test

essence_one_line: Trace how a localized disruption can propagate, amplify, dissipate, or reorganize system-wide behavior.

compression_statement: When a small local disturbance may produce large system effects, trace the source, propagation channels, amplification and damping mechanisms, scale transitions, lags, and intervention points so action can contain, damp, monitor, or deliberately channel the disturbance.

core_intuition: A local disturbance is not automatically local in consequence. Its future depends on the structure around it: how tightly it is coupled to other parts, which channels carry it, which feedbacks amplify it, where buffers absorb it, and where it crosses from a local event into a system-level pattern.

canonical_formula: disturbance source + local context + propagation channels + amplification/damping + scale transitions + global effect signature -> action-relevant disturbance trace

structural_problem: A localized disturbance appears small in its immediate context, but its propagation structure may let it cascade, amplify, dissipate slowly, or reorganize behavior at larger scales.

condition: A local failure, event, behavior, exposure, shortage, rumor, defect, or shock occurs inside a larger coupled system.

why_it_matters: The immediate size of the event may underestimate its larger-scale consequence.

condition: The system contains dependency chains, dense networks, shared resources, synchronization, or correlated vulnerabilities.

why_it_matters: These structures allow local variation to travel, combine, or amplify.

condition: Small disturbances sometimes produce outsized effects, but only under particular local or system conditions.

why_it_matters: Tracing helps distinguish harmless variation from dangerous perturbation.

condition: Stakeholders disagree over whether to treat an event as isolated, cascading, or system-threatening.

why_it_matters: The archetype provides a shared way to inspect propagation instead of relying on alarm or reassurance.

condition: Containment or response resources are limited.

why_it_matters: The trace helps identify where early damping or monitoring has the highest leverage.

symptom: Delayed blast radius

diagnostic_meaning: The full effect is not visible immediately because propagation requires time, intermediate relays, or scale transitions.

symptom: Unexpected cascade

diagnostic_meaning: A local event triggered effects in units that were not recognized as dependent or exposed.

symptom: Overreaction to isolated incidents

diagnostic_meaning: Teams may be treating every local disturbance as systemic because damping boundaries are not understood.

symptom: Underreaction to weak local signals

diagnostic_meaning: Early local variation may be dismissed before amplification pathways become visible.

symptom: Repeated containment failure

diagnostic_meaning: Controls are aimed at the source but the propagation channel or amplifier remains active.

symptom: Qualitative system shift after a small event

diagnostic_meaning: The disturbance may have crossed a threshold and reorganized the larger system rather than simply spreading.

root_tension: Local observability and global consequence are misaligned: the source is visible at one scale, but the effect depends on hidden channels, lags, buffers, and nonlinear transitions across scales.

case: The disturbance is fully isolated by design and cannot cross a meaningful boundary.

why_not_this: Ordinary incident handling or local repair is enough if no propagation channel exists.

case: The issue is a general system trend without a localized initiating disturbance.

why_not_this: Use whole-system diagnosis, trend analysis, or transition monitoring rather than local-disturbance tracing.

case: The intervention question is only how to spread a desired practice.

why_not_this: Diffusion acceleration or wavefront propagation management may be a better fit.

case: The task is only to list downstream consequences.

why_not_this: This archetype requires channels, amplification or damping, and scale transitions, not merely a consequence inventory.

case: The primary concern is steady-state resilience at multiple levels rather than propagation from a local disturbance.

why_not_this: Multi-scale resilience architecture or resilience capacity building is closer.

structural_intervention: Bound the local disturbance, trace how it could move through channels and scale transitions, identify where it is amplified or damped, and select monitoring or intervention points that prevent mistaken underreaction, overreaction, or late response.

logic: Define what happened locally, where it began, and what immediate state makes it worth tracing.

logic: Name the system-level outcome, metric, pattern, or reorganization that would count as a relevant larger effect.

logic: Identify the concrete dependencies, flows, networks, interfaces, contact patterns, incentives, or attention paths that can carry the disturbance.

logic: Ask where feedback, scarcity, thresholds, coupling, synchronization, or incentives increase the disturbance rather than merely transmit it.

logic: Name the buffers, slack, redundancies, boundary controls, absorptive capacities, or frictions that can reduce or stop propagation.

logic: Identify where the local event becomes a subsystem pattern, network effect, regional effect, organizational concern, or system-wide state, and how long that transition may take.

logic: Consider whether the disturbance grows, fades, loops back, or reorganizes the system under different plausible conditions.

logic: Select where to monitor, contain, damp, reroute, isolate, escalate, or adapt based on the trace rather than on the visibility of the source alone.

rule: Do not infer global effect from local magnitude alone.

reason: Small events can amplify, and large local events can dissipate; propagation structure matters more than initial size.

rule: Require at least one propagation channel for every claimed cascade.

reason: This prevents metaphorical butterfly-effect reasoning from replacing causal tracing.

rule: Model amplification and damping separately.

reason: A channel can carry a disturbance without increasing it; a damper can absorb it without eliminating the source.

rule: Treat scale transitions as possible transformations.

reason: What begins as a defect, rumor, exposure, failure, or shortage can become a different kind of system-level pattern.

rule: Stop tracing when additional pathways no longer change action.

reason: The output must guide monitoring, containment, damping, escalation, or adaptation, not become infinite consequence mapping.

rule: Check for false containment.

reason: A disturbance that appears contained may be delayed, hidden in an intermediate layer, or accumulating below a threshold.

meaning: The trace must begin from a specific local disturbance rather than a vague sense of risk.

meaning: Every local-to-global claim should preserve a continuous pathway through channels, relays, or transitions.

meaning: The analysis must show where the disturbance changes scale or changes form.

meaning: The draft should identify why the disturbance grows, fades, stabilizes, or reorganizes.

meaning: The trace should be wide enough to catch important propagation but bounded enough to support action.

meaning: The trace should identify monitoring, containment, damping, escalation, or adaptation points.

description: Teams can distinguish isolated incidents from disturbances with larger propagation risk.

description: Action can be placed where a disturbance is easiest to interrupt before it becomes system-level.

description: The same tracing logic helps avoid both exaggerating harmless local variation and dismissing dangerous weak signals.

description: Responders can act on source, channel, amplifier, damper, scale boundary, or system response layer instead of acting only where the problem is visible.

description: After-action reviews can compare predicted and actual propagation, improving future risk detection.

description: The trace reveals where buffers, redundancies, isolation, monitoring, or recovery paths are needed.

prose_essence:
Local-Disturbance / Global-Effect Tracing is used when a small, bounded disruption might matter far beyond its starting point. The central question is not simply “how bad is the local event?” but “what structure will carry, amplify, damp, delay, or transform this event as it crosses scales?”

The archetype is diagnostic and preparatory. It does not assume that every local disturbance becomes systemic. It creates a disciplined trace that can justify containment, damping, escalation, monitoring, redesign, or deliberate non-escalation.

prose_when_to_use:
Use this archetype when a localized shock, failure, exposure, shortage, defect, rumor, behavior, or ecological disturbance sits inside a larger coupled system. It is especially useful when the local event looks small but the system contains dependency chains, dense networks, shared resources, synchronized timing, feedback, thresholds, or weak buffers.

It is also useful when people disagree about the blast radius. One group may say the event is isolated; another may say it is an early sign of systemic failure. This archetype turns that disagreement into a traceable question: what channels exist, what amplifies the disturbance, what dampens it, where does it cross scale boundaries, and what intervention point follows from the answer?

prose_structural_problem:
The structural problem is a mismatch between local visibility and larger-scale consequence. The disturbance is visible at its origin, but its impact is determined by pathways and conditions that may sit elsewhere in the system.

A local disturbance becomes globally important only when some structure carries it beyond its origin. That structure may be a dependency, network exposure, material flow, shared information system, social attention channel, ecological corridor, financial relationship, governance rule, or timing constraint. Once it moves, the disturbance may grow through amplification, fade through damping, or change form at a scale transition.

The danger is two-sided. Underreaction ignores weak local signals until propagation is already underway. Overreaction treats every local disturbance as a system threat and exhausts attention, trust, and response capacity.

prose_intervention_logic:
The logic begins by bounding the disturbance source and defining the larger effect worth tracing. Then it follows concrete propagation channels outward from the local context. At each step, the trace asks whether the disturbance is merely moving, being amplified, being damped, delayed, or transformed.

A good trace distinguishes six things that are often blurred together: the source, the channel, the amplifier, the damper, the scale transition, and the intervention point. The resulting map should support a decision: monitor, contain, damp, isolate, reroute, escalate, adapt, or do nothing beyond local repair.

This archetype should stop when additional tracing no longer changes action. Its purpose is not to list every possible consequence; its purpose is to identify the propagation structure that matters for response.

prose_key_components:
### Disturbance Source

The disturbance source is the bounded local event or condition where the trace begins. It can be a failure, exposure, defect, rumor, shortage, conflict, local behavior, or ecological perturbation. The source is not automatically the root cause. It is the origin point for tracing how a local event might become larger than local.

### Local Context State

The local context state explains why the same disturbance may either fade or grow. A small shock in a buffered, loosely coupled context may dissipate. The same shock in an overloaded, synchronized, or tightly coupled context may propagate quickly. This component prevents the trace from treating the source as powerful by itself.

### Propagation Channel

A propagation channel is the path that carries the disturbance beyond its origin. It may be a supply route, network dependency, API call, contact pattern, shared staffing model, ecological corridor, financial exposure, or information channel. Without a channel, the trace becomes speculation.

### Amplification Pathway

An amplification pathway explains why the disturbance grows or becomes more consequential as it moves. Common amplifiers include feedback, scarcity, threshold effects, retry loops, central nodes, synchronized timing, attention dynamics, and correlated vulnerabilities. Amplification should not be confused with transmission; a channel carries the disturbance, while an amplifier increases its force or reach.

### Damping Point

A damping point is where propagation can be absorbed, slowed, isolated, or weakened. Damping may come from slack, redundancy, buffering, friction, diversity, quarantine, circuit breakers, governance controls, or response capacity. Damping points can justify proportional non-escalation as well as targeted intervention.

### Scale Transition

A scale transition is the moment where a local disturbance becomes a team-level, subsystem-level, network-level, regional, organizational, market-level, or ecosystem-level pattern. This is the archetype’s distinctive component. A disturbance may change form when it crosses scale: a defect becomes a shortage, a rumor becomes a trust problem, a local outage becomes platform degradation.

### Global Effect Signature

The global effect signature defines what larger effect is being traced. It may be system outage, market stress, population-level risk, ecosystem disruption, organizational trust loss, service degradation, or regional shortage. Naming it keeps the trace bounded and prevents infinite cascade hunting.

### Intervention Point

The intervention point is where the trace becomes useful. It may be at the source, channel, amplifier, damping point, scale boundary, or system response layer. The chosen point should follow from propagation logic rather than from where the disturbance is easiest to see.

prose_common_mechanisms:
### Systemic Risk Tracing

Systemic risk tracing implements the archetype by mapping how a local exposure, failure, or stress can become system-wide through coupling, concentration, feedback, or correlated vulnerability. It is a mechanism because it is a method; the archetype is the broader transferable logic of local-to-global disturbance tracing.

### Supply-Chain Shock Analysis

Supply-chain shock analysis traces how disruption at one supplier, route, plant, or inventory node can become a wider availability, price, schedule, or service problem. It implements the archetype when it names channels, buffers, delays, amplification points, and scale transitions rather than merely listing affected suppliers.

### Ecological Disturbance Mapping

Ecological disturbance mapping applies the archetype to nested environmental systems. A local fire, invasive species outbreak, pollution event, drought stress, or habitat disruption may propagate through connectivity, seasonal timing, species relationships, and thresholds.

### Incident Blast-Radius Analysis

Incident blast-radius analysis estimates which users, services, processes, teams, assets, or regions could be affected by a local incident. It is a mechanism, not the archetype itself. It becomes an implementation of this archetype only when it explains how the blast radius is produced through propagation paths and scale transitions.

### Financial Contagion Tracing

Financial contagion tracing is a domain mechanism for following liquidity, credit, confidence, or counterparty stress through financial relationships. It is structurally related to the archetype because local stress can become systemic through network exposure and feedback.

### Rumor or Failure Propagation Map

A rumor or failure propagation map represents how information, misinformation, operational errors, defects, or workarounds move through social or technical networks. The map is an artifact. The archetype is the reasoning pattern that decides what origin, channel, amplifier, damper, and scale transition matter.

### Infrastructure Cascade Analysis

Infrastructure cascade analysis traces how a local infrastructure fault can affect dependent systems such as power, water, transportation, communications, logistics, and service delivery. It is a strong implementation mechanism when dependency and fallback structures determine the global effect.

### Disturbance Scenario Stress Test

A disturbance scenario stress test uses plausible local shocks to explore propagation before the real disturbance occurs. It is especially useful when empirical evidence is limited or when systems need to test whether buffers and damping points work under stress.

prose_failure_modes:
A common failure mode is butterfly-effect storytelling. This happens when a small event is said to have enormous consequences without naming channels, amplifiers, or scale transitions.

Another failure mode is source fixation. Teams repair the local origin while leaving the propagation channel or amplifier untouched.

A third failure mode is linear-chain bias. The disturbance is traced as a simple sequence even though feedback, network effects, correlated vulnerability, or thresholds matter.

A fourth failure mode is false containment. Existing buffers appear to absorb the disturbance but fail under stress, hide delayed effects, or shift the disturbance to another layer.

A fifth failure mode is scale-transition blindness. The trace follows the disturbance within one level but misses the point where the effect becomes a different kind of system pattern.

A sixth failure mode is infinite cascade mapping. The analysis keeps adding possible consequences without deciding what would change action.

prose_neighbor_distinctions:
Cross-Scale Causal Mapping is broader. It maps causal movement across levels in both directions. Local-Disturbance / Global-Effect Tracing starts with a bounded local perturbation and asks whether it becomes a larger effect.

Wavefront Propagation Management is about managing a spreading front. This archetype diagnoses whether a local disturbance creates such a front, dissipates, or reorganizes the system.

Diffusion Containment is an intervention for limiting spread. This archetype may lead to containment, but it first traces source, channel, amplifier, damper, and scale transition.

Instability Dampening reduces unstable dynamics. This archetype may identify damping points, but it is not only a stabilization pattern.

Consequence Cascade Mapping can become generic downstream-effects analysis. This archetype is stricter: it requires local origin, propagation channel, amplification or damping, scale transition, and action relevance.

Turbulence Channeling deliberately redirects disorder into useful or bounded pathways. This archetype first determines whether a disturbance should be contained, damped, monitored, adapted to, or channeled.

prose_cross_domain_examples:
In software reliability, a local cache outage can trigger retry storms and dependent-service latency, producing platform-wide degradation.

In supply chains, a small supplier delay can propagate through low inventory, single-source dependency, and transport timing into regional product shortages.

In ecology, a localized pest outbreak can spread through habitat corridors and seasonal vulnerability into a regional ecosystem disruption.

In finance, local liquidity stress can move through counterparties and confidence feedback into broader funding stress.

In public health, a localized exposure event can propagate through contact networks, delayed reporting, and institutional settings into population-level response needs.

prose_non_examples:
A fully isolated local equipment failure is not this archetype when there is no dependency, shared workflow, exposure path, or scale transition.

A generic postmortem is not this archetype unless it traces propagation beyond the immediate cause.

A risk register that lists consequences without channels, amplifiers, dampers, or scale transitions is not this archetype.

A planned scale-up of a successful pilot is not this archetype; use scale-invariance testing or scale-bridging translation.

A deliberate campaign to spread a desired practice is usually diffusion acceleration or wavefront management, not local-disturbance tracing.

prose_tradeoffs:
Early sensitivity catches weak signals, but it can create false alarms. Deep tracing reveals delayed effects, but it can become speculative. Aggressive containment prevents harm, but it may suppress useful variation, experimentation, or warning signals. Centralized escalation mobilizes resources, but it can undermine local autonomy and create response fatigue.

The most important tradeoff is proportionality. The archetype should make response more accurate, not simply more intense.

prose_invariants_to_preserve:
Preserve localized origin clarity: the trace must begin with a specific disturbance, not a vague fear.

Preserve path continuity: every global-effect claim needs a plausible path through channels, relays, or transitions.

Preserve scale transition visibility: the trace must show where the disturbance changes scale or changes form.

Preserve amplification and damping explicitness: growth, dissipation, and reorganization must be explained, not assumed.

Preserve bounded scope: the trace should be broad enough to catch important propagation and narrow enough to support action.

Preserve intervention relevance: the final trace should identify where monitoring, containment, damping, escalation, adaptation, or redesign should occur.

prose_target_outcomes:
The main outcome is better blast-radius estimation. Teams can distinguish local incidents from events with systemic propagation potential.

A second outcome is earlier containment or damping. The trace identifies the channel or amplifier before the disturbance becomes a larger-scale pattern.

A third outcome is reduced false alarm and false reassurance. The same method can show when an event is dangerous and when it is likely to dissipate.

A fourth outcome is clearer cross-scale learning. After the event, teams can compare expected propagation with actual propagation and improve future monitoring.

A fifth outcome is stronger input for resilience design. The trace reveals which buffers, redundancies, isolation points, and recovery paths matter most.

prose_parameter_dimensions:
The first tuning dimension is the width of the disturbance boundary. Too narrow, and the trace misses local conditions that enable propagation. Too wide, and the source becomes vague.

The second dimension is propagation depth. Shallow traces miss delayed or second-order effects; deep traces can become speculative. The right depth is the point where additional pathways no longer change monitoring or intervention.

The third dimension is coupling resolution. The trace must represent dependencies clearly enough to identify channels, but not so finely that the main pathways disappear in detail.

The fourth dimension is amplification sensitivity. If too low, nonlinear growth is missed. If too high, ordinary local variation is treated as systemic threat.

The fifth dimension is damping confidence. Under-trusting buffers causes overreaction; over-trusting them causes false containment.

The sixth dimension is time-lag horizon. Many disturbances are delayed or pulsed. A short horizon misses slow cascades; a long horizon absorbs too many remote possibilities.

The seventh dimension is intervention threshold. This determines when tracing should lead to monitoring, containment, escalation, or redesign.

prose_variants_and_near_names:
Cascade Risk Tracing focuses on dependent failure chains. It is useful for infrastructure, software reliability, and supply chains.

Contagion Pathway Tracing focuses on networked exposure, contact, copying, counterparty relationships, or attention dynamics. It overlaps with diffusion and containment patterns but remains diagnostic here.

Disturbance Dissipation Tracing focuses on proving where and why a local disturbance fades before becoming systemic. It is useful when stakeholders need evidence that an event can remain local.

Threshold Reorganization Tracing focuses on cases where a small event shifts the operating pattern of a larger system. It may later deserve promotion if threshold-specific tracing becomes distinct enough.

Near names include Local-to-Global Shock Tracing, Disturbance Propagation Mapping, Small-Cause / Large-Effect Tracing, and Nonlinear Propagation Tracing. The last two require extra caution because they can drift into metaphor unless channels and scale transitions are explicit.

Cascade Risk Tracing

short_definition: A variant focused on whether a local failure or shock can trigger a chain of dependent failures across levels.

distinctive_feature: It emphasizes sequential or branching dependence among failures rather than general propagation through a field or network.

distinct_from_parent: The parent covers any local-to-global disturbance path; cascade risk tracing is narrower and failure-chain oriented.

still_same_parent_because: It still requires a localized disturbance, propagation channels, scale transitions, amplification or damping, and action-relevant tracing.

use_when: The system contains dependency chains where one local failure can unlock several downstream failures.

use_when: The practical question is how far and how fast a cascade can travel before it is damped or contained.

Disturbance Source

role: Defines the initiating local shock.

Propagation Channel

role: Shows dependent paths through which failure travels.

Cascade Boundary

role: Bounds the likely blast radius.

Infrastructure Cascade Analysis

role: Tests dependent infrastructure failure paths.

Incident Blast-Radius Analysis

role: Estimates the affected scope of an incident.

domain: infrastructure

example: A substation fault triggers dependent service disruptions across connected utilities.

domain: software reliability

example: A single service degradation propagates through dependent APIs into platform-wide latency.

failure_modes: Assuming every dependency fails sequentially without checking actual coupling strength.

failure_modes: Stopping at first-order impacts and missing second-order scale transitions.

Contagion Pathway Tracing

short_definition: A variant focused on spread through contact, exposure, attention, counterparty, or dependency networks.

distinctive_feature: The propagation channel is a networked exposure pattern rather than a linear chain or shared environmental field.

distinct_from_parent: The parent does not require network contagion; this variant does.

still_same_parent_because: The reasoning still begins with a local disturbance and traces cross-scale propagation to larger system effects.

source_primes: diffusion network coupling

use_when: The disturbance travels because nodes expose, copy, infect, imitate, or transmit to other nodes.

use_when: Network structure, centrality, clustering, or contact pattern materially changes the global effect.

Propagation Channel

role: Names the exposure network.

Amplification Pathway

role: Identifies hubs, feedback, or attention loops.

Damping Point

role: Locates isolation, friction, or buffering opportunities.

Financial Contagion Tracing

role: Applies networked exposure tracing to finance.

Rumor or Failure Propagation Map

role: Applies network propagation to information or reliability cases.

domain: public health

example: A localized exposure spreads through contact patterns into community-level risk.

domain: finance

example: Stress at one institution spreads through counterparty relationships.

failure_modes: Reducing all propagation to network spread and missing common-cause or threshold effects.

failure_modes: Treating high connectivity as always harmful when it may also carry warning or support.

Disturbance Dissipation Tracing

short_definition: A variant focused on proving where and why a local disturbance loses force before becoming system-wide.

distinctive_feature: The expected result is bounded dissipation, not escalation.

distinct_from_parent: The parent can trace amplification or dissipation; this variant emphasizes decay and containment evidence.

still_same_parent_because: It still maps disturbance source, channels, damping points, scale boundaries, and intervention implications.

source_primes: damping turbulence scale

use_when: Stakeholders disagree about whether a local incident is likely to remain local.

use_when: The task is to identify existing buffers, frictions, redundancies, or absorptive features that stop propagation.

Damping Point

role: Names where propagation loses force.

Cascade Boundary

role: Defines the limit of spread.

Temporal Lag Profile

role: Checks whether apparent dissipation is only delay.

Disturbance Scenario Stress Test

role: Tests whether proposed dampers stop propagation.

Incident Blast-Radius Analysis

role: Estimates bounded scope.

example_domains: risk_management ecology operations

domain: operations

example: A defect is contained within one production cell because inspection and quarantine points interrupt spread.

domain: ecology

example: A small habitat disturbance dissipates because surrounding buffers absorb it.

failure_modes: Mistaking slow propagation for dissipation.

failure_modes: Over-trusting nominal buffers that are already overloaded.

Threshold Reorganization Tracing

short_definition: A variant focused on how a local disturbance pushes a system across a threshold into a new operating pattern.

distinctive_feature: The global effect is a qualitative change in system behavior, not only a larger quantity of the original disturbance.

distinct_from_parent: The parent includes reorganization as one possible result; this variant treats threshold crossing as central.

still_same_parent_because: The trace still begins from a localized disturbance and follows propagation through scale transitions toward a larger effect.

source_primes: threshold tipping_points nonlinearity

use_when: A small event appears capable of changing the regime, norm, equilibrium, or dominant behavior of a larger system.

use_when: The main concern is reorganization rather than simple spread or cumulative damage.

Reorganization Indicator

role: Shows qualitative change rather than ordinary propagation.

Scale Transition

role: Marks the point where the local event changes system state.

Amplification Pathway

role: Explains how the local event reaches threshold relevance.

Disturbance Scenario Stress Test

role: Explores threshold-crossing scenarios.

Ecological Disturbance Mapping

role: Identifies regime-shift risk from local ecological shocks.

example_domains: ecology markets organizational_change

domain: organization

example: A local safety incident changes system-wide norms about reporting and oversight.

example: A local disturbance pushes a stressed ecosystem into a different stable state.

failure_modes: Seeing every large effect as a threshold shift.

failure_modes: Missing slow accumulation that prepared the threshold before the local trigger.

near_names:
Local-to-Global Shock Tracing
Small-Cause / Large-Effect Tracing
Disturbance Propagation Mapping
Nonlinear Propagation Tracing