name: Multiple Causation and Explanatory Pluralism

batch: Second Iteration/Batch 03

aliases:
Multicausal Explanation
Causal Pluralism
Explanatory Pluralism
Multifactor Explanation
Anti-Monocausal Explanation
Plural Causal Explanation

related_primes: perspective scale uncertainty confounding counterfactual_reasoning historicism historical_empathy presentism revisionism great_man_theory

slug: causality

slug: complexity

slug: perspective

slug: confounding

slug: historicism

slug: presentism

slug: revisionism

components:
Explanatory Target Boundary
Causal Family Inventory
Scale Partition
Causal Role Typology
Interaction Map
Evidential Weighting
Contingency Register
Plural Synthesis Statement
Stakeholder Perspective Set
Counterfactual Probe Set
Causal Weight Scale

mechanisms:
Multicausal Factor Matrix
Cause-Role Worksheet
Causal Loop or Influence Diagram
Process-Tracing Evidence Table
Counterfactual Sensitivity Probe
Cross-Disciplinary Causal Review

essence_one_line: Explain a complex outcome by coordinating multiple causal families and scales instead of reducing it to one master cause.

compression_statement: Multiple Causation and Explanatory Pluralism is the intervention of replacing monocausal determinism with a disciplined causal plurality: candidate causes are separated by type and scale, assigned causal roles and evidence weights, checked for interactions, and synthesized into an explanation that preserves necessity, contingency, uncertainty, and relative importance.

core_intuition: Complex outcomes often happen because several conditions jointly make them possible, likely, or durable. A single-cause story may be memorable, but it hides enabling conditions, background structures, precipitating events, actor choices, and feedback loops. The pattern works by giving plurality a structure: not every factor is equal, but more than one factor may be genuinely explanatory.

canonical_formula: outcome ≈ weighted_interaction(structural_forces, institutional_rules, material_conditions, actor_choices, cultural_frames, timing, contingency, feedback) with uncertainty and evidence explicitly marked

structural_problem: A complex event, change, or outcome is being compressed into a single deterministic cause, obscuring the interaction of forces at different scales and making the explanation brittle, partisan, or misleading.

condition: Several plausible causal families can explain part of the outcome.

diagnostic_use: Signals that a one-cause account is likely under-specified.

condition: Participants disagree because each side highlights a different real factor.

diagnostic_use: Suggests the conflict may require causal integration rather than simple refutation.

condition: The dominant account makes an outcome appear inevitable, natural, or caused by one actor or force alone.

diagnostic_use: Signals historical_determinism or grand-narrative compression risk.

condition: Evidence appears at multiple scales, such as individual choices, institutions, markets, technologies, norms, and chance events.

diagnostic_use: Requires a scale-aware explanatory structure.

symptom: Explanations repeatedly use phrases such as “because of X” while ignoring enabling background conditions.

interpretation: The account may be monocausal or deterministic.

symptom: Different disciplines or stakeholders offer mutually exclusive but individually plausible explanations.

interpretation: The problem may require plural causal integration.

symptom: Counterexamples show that the named cause is not sufficient on its own.

interpretation: The cause may need to be reclassified as enabling, amplifying, precipitating, or contributory.

symptom: The same cause appears in some cases without producing the same outcome.

interpretation: Missing interaction conditions or contextual moderators are likely.

root_tension: Explanatory compression is necessary for understanding, but excessive compression turns causal analysis into a deterministic story. The archetype balances interpretive clarity against the need to preserve multiple causal roles, scales, and uncertainties.

case: A single cause has been isolated by strong experimental or mechanical evidence and no broader explanatory task is being performed.

reason: Plural causal synthesis may add noise rather than insight.

case: The immediate task is emergency triage with a known actionable fault.

reason: Rapid containment may matter more than full explanatory synthesis.

case: The task is only to verify source provenance or data quality.

reason: Use source_provenance_triangulation or data-integrity mechanisms first.

case: All listed factors are merely labels for the same underlying cause.

reason: The apparent plurality collapses into synonymy or re-description.

structural_intervention: Build a structured multicausal explanation by identifying distinct causal families, separating scale levels, classifying each factor’s causal role, mapping interactions, weighting evidence, and preserving uncertainty and counterfactual contingency in the final synthesis.

step: Define the explanatory target.

logic: Specify the outcome, time boundary, contrast class, and level of explanation so the causal account is not trying to explain everything at once.

step: Inventory candidate causal families.

logic: Collect plausible material, institutional, economic, cultural, technological, psychological, environmental, and contingent factors without prematurely ranking them.

step: Partition by scale and causal role.

logic: Separate background conditions, enabling constraints, precipitating events, amplifiers, inhibitors, actor decisions, feedback loops, and maintenance conditions.

step: Map interactions and dependencies.

logic: Show which causes combine, substitute, gate, intensify, or weaken one another rather than treating all factors as independent checklist items.

step: Assign evidence weight and confidence.

logic: Distinguish strongly supported causes from plausible hypotheses, interpretive inferences, and open uncertainties.

step: Preserve contingency and counterfactual sensitivity.

logic: Ask what would plausibly change if one factor were removed, delayed, intensified, or replaced.

step: Synthesize without collapsing.

logic: Write or model the explanation so it communicates relative importance while retaining the plural causal structure.

rule: Do not add a factor merely to appear balanced.

application: Every included cause should have evidence, a plausible mechanism, or a clearly marked hypothesis status.

rule: Do not force equal weight across causes.

application: Pluralism allows unequal importance; some causes may be decisive while others are enabling or amplifying.

rule: Keep scale labels explicit.

application: Micro-level decisions, meso-level institutions, and macro-level structures should not be conflated.

rule: Treat inevitability claims as hypotheses, not conclusions.

application: A deterministic account must be tested against contingency, counterfactuals, and omitted conditions.

rule: Separate causal roles from moral blame.

application: A background condition may help explain an outcome without excusing responsible actors.

invariant: Causal specificity

preserve_by: Name what each factor does: enables, triggers, amplifies, constrains, diverts, stabilizes, or maintains.

invariant: Temporal order

preserve_by: Keep sequence and duration visible so later effects are not mistaken for earlier causes.

invariant: Scale integrity

preserve_by: Do not treat actor motives, institutional rules, and structural forces as interchangeable explanations.

invariant: Evidence transparency

preserve_by: Record confidence levels and evidential basis for each causal claim.

invariant: Explanatory contrast

preserve_by: State what alternative outcome or comparison case is being explained against.

outcome: Reduced monocausal determinism

indicator: The explanation no longer depends on one master cause to carry the entire account.

outcome: Stronger direct coverage for historical_determinism

indicator: Structural forces are represented without making outcomes seem fully inevitable.

outcome: More robust causal judgment

indicator: Stakeholders can see which causes are necessary, contributory, uncertain, or interactive.

outcome: Better intervention choice

indicator: Action can target leverage points across levels instead of over-investing in the most salient cause.

outcome: Improved explanatory humility

indicator: The final account records uncertainties and plausible alternatives without abandoning explanation.

prose_tradeoffs: The main tradeoff is accuracy versus communicability. A plural explanation can be more accurate but harder to teach, decide from, or communicate. Another tradeoff is humility versus decisiveness. The archetype preserves uncertainty, but many domains still require action. A third tradeoff is structural explanation versus accountability: background forces can explain why harmful action became likely, but they should not erase responsibility for decisions.

Historical Multicausal Explanation

short_definition: A historical application that explains events through interacting structural forces, actors, institutions, and contingencies.

distinctive_feature: Explicit pressure against deterministic history and single-factor period narratives.

distinct_from_parent: It is domain-specific to historical explanation and period-sensitive evidence.

still_same_parent_because: It uses the same plural causal inventory, role classification, interaction mapping, and synthesis discipline.

use_when: A historical outcome is being reduced to a single ideology, technology, leader, class force, or inevitability claim.

use_when: The explanation must preserve both structural constraints and contingent turning points.

example_domains:
history education
historiography
institutional memory

domain: history

example: Explaining industrialization by combining resource endowment, institutions, finance, labor discipline, technology, and imperial trade.

failure_modes: Replacing one deterministic story with an unweighted list of factors.

name: Organizational Change Multicausal Diagnosis

short_definition: An organizational use that explains change outcomes through market, leadership, cultural, process, incentive, and legacy-system factors.

distinctive_feature: Combines structural and social causes inside organizations while preserving accountability.

distinct_from_parent: It emphasizes organizational roles, incentives, legacy systems, and governance constraints.

still_same_parent_because: The causal integration logic remains the same across domains.

source_primes: causality complexity

use_when: A transformation success or failure is being blamed on one team, leader, tool, or market condition.

use_when: Several departments hold partial explanations that need integration.

example_domains:
enterprise transformation
postmortem review
strategy diagnosis

domain: organization

example: Explaining failed software adoption through procurement incentives, training gaps, workflow mismatch, and executive signaling.

failure_modes: Using complexity to avoid naming accountable decisions.

name: Public Health Multifactorial Causal Modeling

short_definition: A public-health use that integrates environmental, behavioral, genetic, socioeconomic, policy, and care-access causes without collapsing disease outcomes into one factor.

distinctive_feature: Strong need to separate causal contribution, confounding, and intervention leverage.

distinct_from_parent: It uses epidemiological evidence and policy constraints more heavily than general causal synthesis.

still_same_parent_because: It remains a plural causal account across families and scales.

source_primes: causality confounding complexity

use_when: Disease distribution differs across groups, regions, or time periods for more than one plausible reason.

use_when: Policy choices require multiple intervention points.

example_domains:
epidemiology
health equity
prevention policy

domain: public health

example: Explaining asthma prevalence by combining housing quality, pollution exposure, access to care, genetics, stress, and policy enforcement.

failure_modes: Treating correlation-heavy factor lists as proven causal models.

Determinism–Contingency Balance Variant

short_definition: A narrower use that balances structural forces with contingent events and choices that could have changed the outcome.

distinctive_feature: Focuses on inevitability versus contingency rather than all forms of causal plurality.

distinct_from_parent: It foregrounds counterfactual turning points and determinism pressure more than general factor integration.

still_same_parent_because: It is implemented by the same causal role, evidence weighting, and contingency-register components.

use_when: A historical or strategic account makes an outcome seem inevitable.

use_when: There are credible turning points or near-miss alternatives.

example_domains:
historiography
scenario planning
strategy review

domain: historical explanation

example: Showing how deep fiscal stress made revolt likely while specific leadership choices and food-price shocks shaped timing and form.

failure_modes: Overcorrecting into “anything could have happened” contingency rhetoric.

near_names:
Causal Pluralism
Multicausal Explanation
Explanatory Pluralism
Determinism / Contingency Balance


Multiple-Testing Discipline

type: archetype

source: generated

batch: First Iteration/Batch 30

slug: uncertainty

slug: probability

slug: threshold

components:
Claim Family
Multiplicity Inventory
Error-Risk Profile
Multiplicity Adjustment Rule
Exploratory–Confirmatory Boundary
Discovery Record
Confirmation Requirement
Claim Hierarchy
Holdout Evidence
Independent Replication Path
Result Status Label

mechanisms:
Bonferroni-Like Correction
False Discovery Rate Control
Preregistration
Holdout Validation
Claim Registry
Replication Study
Confirmatory Follow-Up
Alpha-Spending Plan
Metric Hierarchy
Multiverse Analysis Report

essence_one_line: Control false discoveries when many comparisons, claims, or tests are being tried.

compression_statement: When many comparisons are searched, separate the family of attempted claims from any single attractive result, adjust the evidentiary standard or discovery procedure, record exploratory search, and require confirmation before treating selected findings as reliable.

core_intuition: A surprising result is less surprising when it is the best-looking result among many tries. Multiple-Testing Discipline changes the unit of interpretation from “this one result” to “the set of opportunities for a false alarm,” then makes the confirmation burden match that broader search space.

canonical_formula: many attempted claims + ordinary single-claim interpretation -> inflated false positives; claim family + adjusted threshold/procedure + exploration log + confirmation -> credible discovery

structural_problem: A system runs, inspects, or informally considers many tests, comparisons, metrics, groups, models, or stories, but reports the most appealing result as though it came from one pre-specified test. The more opportunities there are for a chance pattern, the easier it becomes to mistake noise for evidence.

condition: Many hypotheses, outcomes, subgroups, time windows, thresholds, features, treatments, or metrics are being tested or inspected.

condition: A result was selected after looking across several alternatives rather than being specified before the evidence was seen.

condition: The same dataset, dashboard, experiment, audit stream, or corpus is reused for many discovery attempts.

condition: Teams have incentives to publish, ship, escalate, or celebrate whichever comparison looks significant or favorable.

condition: Different analysts or stakeholders can keep slicing, filtering, modeling, or reframing until a preferred pattern appears.

condition: A finding will trigger expensive action, reputation change, policy change, clinical choice, enforcement, or strategic commitment.

condition: Exploratory search is valuable, but the organization needs a clear boundary between generating leads and confirming claims.

symptom: Isolated significant result after broad search

description: A single attractive finding is highlighted without stating how many other comparisons, segments, outcomes, or model variants were examined.

symptom: Metric shopping or subgroup fishing

description: A claim depends on choosing the favorable metric, window, cohort, geography, subgroup, transformation, or exclusion rule after seeing results.

symptom: Discovery treated as confirmation

description: Patterns found during open-ended exploration are reported with the confidence appropriate only for pre-specified confirmatory tests.

symptom: Untracked failed comparisons

description: Only the successful or surprising analyses are recorded, while the null, failed, or inconvenient attempts disappear from the evidence trail.

symptom: Replication decay

description: Promising discoveries repeatedly weaken, vanish, or reverse when tested in fresh data, later cohorts, or independent teams.

symptom: Alert or anomaly overload

description: Many detection rules create a flood of impressive-looking anomalies whose base-rate-adjusted credibility is low.

symptom: Threshold inflation by repetition

description: A threshold that is reasonable for one test becomes too permissive when hundreds or thousands of opportunities to cross it are created.

root_tension: Open-ended search is useful because discovery often requires looking broadly, but broad search creates many chances for accidental patterns. The archetype preserves exploration while preventing the most interesting accident from being mislabeled as already-confirmed knowledge.

condition: Only one pre-specified claim, outcome, population, and analysis path is evaluated; Hypothesis Testing Frame may be sufficient.

condition: The issue is whether the effect is large enough to matter; Effect Size Reporting is the closer candidate and is currently held for merge review.

condition: The issue is whether the study is sensitive enough to detect a meaningful effect; Power-Aware Design is the closer candidate and is currently held for merge review.

condition: The main need is to recreate the workflow or result rather than control false discoveries across many claims; use Reproducibility Protocol.

condition: The main problem is a biased sample or inclusion pathway; Representative Sampling Design or the held Selection Bias Correction candidate is closer.

condition: The goal is brainstorming, ideation, or exploratory screening with no claim of confirmed truth or decision consequence.

condition: All tested comparisons are explicitly framed as low-stakes leads and are not used for confirmation, ranking, punishment, or irreversible action.

structural_intervention: Define the family of related tests or claims, track the search process, choose a multiplicity-aware decision rule, separate exploratory from confirmatory evidence, and require fresh confirmation or disciplined interpretation before acting on selected findings.

Define the claim family

logic: State which comparisons, outcomes, segments, models, time windows, thresholds, or decisions belong to the same family of discovery opportunities.

Inventory attempted looks

logic: Record not only the final selected finding but also the number and kind of tests, filters, analyses, model choices, or dashboard views used to find it.

Set the error-risk policy

logic: Decide whether the context needs strict false-positive prevention, controlled discovery rate, explicit exploratory labeling, or staged confirmation.

Apply a multiplicity-aware rule

logic: Use an adjustment, holdout, registry, alpha-spending plan, confirmation stage, or reporting convention that makes the evidence standard reflect the search space.

Label claim status

logic: Mark results as exploratory, adjusted-discovery, confirmed, replicated, or rejected rather than allowing all attractive patterns to occupy the same status.

Confirm before costly action

logic: Use fresh data, a held-out sample, independent replication, targeted follow-up, or prospective testing before high-stakes action based on a selected discovery.

Preserve the discovery record

logic: Keep enough history of tested alternatives, null results, and analytic choices that later reviewers can understand the true evidentiary burden.

rule: Family first, result second

guidance: Interpret a striking result in light of the family of comparisons that made it possible.

rule: Exploration does not equal confirmation

guidance: Treat broad search as lead generation unless the result survives a pre-specified, adjusted, held-out, or replicated confirmation process.

rule: Tighten standards as the search expands

guidance: The larger or more flexible the search space, the stronger the threshold, correction, or confirmation burden should become.

rule: Match discipline to error costs

guidance: Use stricter familywise control when any false claim is costly; use discovery-rate approaches when screening many leads is valuable and some false positives are acceptable.

rule: Do not hide failed looks

guidance: Unreported attempts are part of the evidence context because they determine how surprising the reported result actually is.

rule: Do not substitute correction for judgment

guidance: Adjusted thresholds and discovery-rate procedures do not fix poor measurement, weak theory, confounding, selection bias, or trivial effect magnitude.

invariant: The family of attempted claims remains visible when interpreting any selected finding.

invariant: Exploratory and confirmatory evidence are not collapsed into the same status.

invariant: False-positive risk is bounded, corrected, or explicitly acknowledged in proportion to the search space.

invariant: Null, failed, or non-selected tests remain part of the discovery record.

invariant: High-stakes action requires confirmation stronger than the initial search result.

invariant: Mechanisms such as p-values, corrections, preregistration, and holdouts remain implementation tools, not the archetype itself.

outcome: Reduced false discoveries in many-claim environments.

outcome: Clearer distinction between leads worth exploring and findings ready for action.

outcome: More credible reported discoveries because the search space is acknowledged.

outcome: Less p-hacking, metric shopping, subgroup fishing, and after-the-fact storytelling.

outcome: Better reproducibility because selected results are confirmed or labeled with appropriate uncertainty.

outcome: Improved decision trust when stakeholders can see both the successful claim and the opportunity set that produced it.

prose_essence:
Multiple-Testing Discipline is the intervention pattern for situations where many comparisons, claims, metrics, screens, or analytic choices are tried and the most attractive result is at risk of being interpreted as though it came from a single planned test. The archetype does not prohibit exploration. It makes exploration honest: the selected result must be understood against the larger search space that made it possible.

The core move is to change the unit of credibility. Instead of asking only, "Does this one result look unlikely by chance?" the pattern asks, "How many chances did the system have to find something that looked unlikely, and what confirmation burden follows from that?" That shift turns a potentially misleading discovery ritual into a disciplined evidence process.

prose_when_to_use:
Use this archetype when the same evidence base can generate many candidate findings: many outcomes in a study, many metrics in an experiment, many subgroups in a report, many model variants in a benchmark, many anomaly screens in an audit, or many investigative leads in a case file. It is especially important when selected findings will guide decisions, reputations, resource allocation, safety action, publication, enforcement, or product launch.

The archetype is not needed for every open-ended exploration. It becomes necessary when exploratory results are about to be presented as confirmed claims or used for consequential action. In low-stakes exploration, the right move may be simple labeling: "this is a lead." In high-stakes contexts, the right move may require formal correction, holdout validation, independent replication, a registry of attempted claims, or a staged confirmation process.

prose_structural_problem:
When many tests are tried, chance has many opportunities to produce an impressive-looking pattern. If the failed, null, or unreported comparisons disappear from view, the remaining selected result looks more surprising than it really is. This is the structural source of p-hacking, metric shopping, subgroup fishing, data dredging, repeated interim looks, and overfitting to validation evidence.

The problem is not simply that people use a p-value, a threshold, or a dashboard. The problem is that the evidentiary context of the selected result is incomplete. A single result is being interpreted without the family of attempts that generated it. Multiple-Testing Discipline restores that missing context.

prose_intervention_logic:
The intervention begins by defining the **claim family**: the related tests, outcomes, metrics, models, filters, time windows, and segments that created opportunities for a selected discovery. It then records the **multiplicity inventory**, including failed or unselected attempts. Next, it chooses an error-risk policy: strict false-positive avoidance, discovery-rate control, exploratory labeling, or staged confirmation. Finally, it applies a rule or process that matches the search space, and it withholds decision-ready status until the finding has survived the appropriate confirmation burden.

A disciplined process can still be creative. Exploration generates leads; confirmation changes their status. The archetype succeeds when a stakeholder can see both the promising result and the path by which it was found, then judge whether the result is exploratory, adjusted, confirmed, replicated, or ready for action.

prose_key_components:
- **Claim Family (`claim_family`)**: Defines which comparisons belong together for interpretation. A single product experiment might include one primary metric, several secondary metrics, dozens of segments, and multiple time windows; the claim family makes those opportunities visible.
- **Multiplicity Inventory (`multiplicity_inventory`)**: Records the number and kind of attempted looks. This includes tested metrics, model variants, filters, thresholds, subgroups, interim checks, and abandoned analyses.
- **Error-Risk Profile (`error_risk_profile`)**: States what kind of mistake matters most. A safety screen, scientific discovery program, and product experiment may need different balances between false positives and missed discoveries.
- **Multiplicity Adjustment Rule (`multiplicity_adjustment_rule`)**: Implements the chosen discipline. It might be a formal correction, a false-discovery-rate procedure, a holdout rule, an alpha-spending plan, or a staged confirmation requirement.
- **Exploratory–Confirmatory Boundary (`exploratory_confirmatory_boundary`)**: Prevents patterns found during search from being treated as planned tests. It preserves exploratory value while protecting confirmatory credibility.
- **Discovery Record (`discovery_record`)**: Keeps failed, null, alternative, and selected analyses visible. Without it, selective memory recreates the same false-discovery risk.
- **Confirmation Requirement (`confirmation_requirement`)**: Defines what must happen before a selected result can guide high-stakes action. Confirmation may require a new experiment, held-out data, independent replication, a second site, or a stricter review gate.

prose_common_mechanisms:
Mechanisms implement the archetype; they are not the archetype itself.

- **Bonferroni-Like Correction (`bonferroni_like_correction`)**: A strict threshold-adjustment mechanism for contexts where even one false positive across the family is costly.
- **False Discovery Rate Control (`false_discovery_rate_control`)**: A screening mechanism that permits many discoveries while controlling the expected share that are false.
- **Preregistration (`preregistration`)**: A procedural commitment mechanism that records planned claims and analyses before results are observed.
- **Holdout Validation (`holdout_validation`)**: An evidence-partitioning mechanism that reserves fresh data or cases for confirmation after discovery.
- **Claim Registry (`claim_registry`)**: A governance mechanism that tracks attempted claims, statuses, owners, and follow-up requirements.
- **Replication Study (`replication_study`)**: An independent-confirmation mechanism that tests whether a selected finding persists in new evidence.
- **Confirmatory Follow-Up (`confirmatory_follow_up`)**: A staged-validation mechanism that turns a promising lead into a targeted confirmatory test.
- **Alpha-Spending Plan (`alpha_spending_plan`)**: A sequential-testing mechanism for repeated interim looks.
- **Metric Hierarchy (`metric_hierarchy`)**: A priority mechanism that prevents teams from promoting a secondary metric after the primary result disappoints.
- **Multiverse Analysis Report (`multiverse_analysis_report`)**: A transparency mechanism that shows whether a result depends on one favorable analytic path.

prose_failure_modes:
A common failure is **undefined claim family**, where only the reported tests are corrected and hidden analytic flexibility is ignored. Another is **correction theater**, where a formal adjustment is applied while metric shopping, data leakage, confounding, or selective reporting continues. **Overcorrection paralysis** happens when strict rules suppress useful discovery even when false leads could be cheaply followed up. **Exploratory label laundering** occurs when a claim is labeled exploratory in methods text but presented as confirmed in decisions or headlines. **Confirmation contamination** happens when holdout or replication evidence is influenced by the original search.

The most subtle failure is treating a result that survived multiplicity discipline as automatically important. A disciplined discovery can still be tiny, biased, confounded, practically irrelevant, or ethically unsafe to act on.

prose_neighbor_distinctions:
**Hypothesis Testing Frame** structures a single claim against a default with evidence thresholds and error costs. Multiple-Testing Discipline adds the many-claim layer: what counts as evidence changes when many opportunities for a false alarm exist.

**Reproducibility Protocol** makes work rerunnable and auditable. A reproducible workflow can still overclaim a cherry-picked result if the discovery process had many unacknowledged attempts.

**Uncertainty Explicitness** communicates uncertainty. Multiple-Testing Discipline changes the discovery and confirmation process so reported uncertainty is not falsely narrow because of hidden search.

**Confounder Control** addresses third-variable distortion. Multiple-Testing Discipline addresses false discoveries created by repeated or flexible search.

**Power-Aware Design** and **Effect Size Reporting** remain merge-review neighbors in this batch. They address false negatives and practical magnitude, while this archetype addresses inflated false positives across many claims.

prose_cross_domain_examples: In genomics, thousands of candidate genes may be screened; the archetype uses discovery-rate control and replication before treating candidates as credible. In product analytics, a feature may be examined across many metrics and segments; the archetype keeps primary metrics separate from exploratory subgroup leads. In machine learning, many hyperparameters may be tried; the archetype protects a locked test set for final confirmation. In public policy evaluation, many regions, outcomes, and demographic subgroups may be inspected; the archetype reports the family and labels subgroup findings appropriately. In safety monitoring, many anomaly screens may create false alarms; the archetype tracks alert families and requires corroboration before escalation.

prose_non_examples: A single pre-specified pass/fail test is better handled by Hypothesis Testing Frame. A brainstorming session that produces speculative ideas without evidence claims does not require this archetype. A causal comparison distorted by a third variable calls for Confounder Control. A report that lacks uncertainty intervals calls for uncertainty representation. A statistically significant but practically tiny result calls for effect magnitude and decision-relevance checks, not primarily multiplicity discipline.

prose_tradeoffs:
Multiple-Testing Discipline trades some speed and sensitivity for credibility. Stricter correction can miss real signals. Broad exploration can generate useful leads but weak confirmation. Simple rules are easy to explain but may be too conservative or poorly matched to correlated tests. Claim registries improve memory but add administrative burden. Confirmation delays action, but premature action can be far more costly when the discovery is false.

The best version of the archetype is not always the strictest. It is the version that fits the error-risk profile and clearly labels what status each finding deserves.

prose_invariants_to_preserve: The claim family must remain visible when interpreting a selected result. Exploration and confirmation must not be merged into a single status. Failed or unreported attempts must not disappear from the evidence context. The evidentiary burden should increase as the search space expands. High-stakes action should require stronger confirmation than initial discovery. Mechanisms should remain mechanisms: a p-value, Bonferroni correction, preregistration form, or holdout dataset is not the archetype by itself.

prose_target_outcomes: The archetype aims to reduce false discoveries, reduce p-hacking and metric shopping, improve trust in selected findings, preserve the value of exploratory search, and make reported claims more reproducible. A successful implementation does not eliminate uncertainty; it makes the credibility of discoveries better calibrated to how they were found.

prose_parameter_dimensions:
Important tuning dimensions include the size of the claim family, the dependence among tests, the cost of false positives, the cost of false negatives, the strength of prior theory, the number of exploratory degrees of freedom, the availability of held-out evidence, the stakes of action, and the acceptable delay before confirmation.

A strict familywise approach is appropriate when any false claim is dangerous. A false-discovery-rate approach is often better when screening many candidates and expecting later follow-up. A governance-heavy approach is useful when the main risk is organizational cherry-picking rather than a single statistical formula. A staged exploration-confirmation approach is useful when broad search is necessary but action must wait.

prose_variants_and_near_names:
Recognized variants include **Familywise Error Control**, **False Discovery Rate Discipline**, **Exploratory–Confirmatory Partition**, and **Claim Registry Governance**. Near names include multiplicity control, multiple comparisons correction, false discovery control, data-dredging guardrail, p-hacking guardrail, look-elsewhere effect control, and trials-factor correction.

Bonferroni correction, FDR correction, preregistration, holdout validation, and claim registries should generally remain mechanisms or variants. **Exploratory–Confirmatory Split** is preserved as a promotion candidate for second-wave review after first-wave saturation.

Familywise Error Control Variant

short_definition: A stricter variant that tries to avoid even one false positive across a defined family of claims.

distinctive_feature: The protected quantity is the chance of at least one false positive anywhere in the family.

distinct_from_parent: The parent includes several ways to discipline many-claim discovery; this variant emphasizes strict family-level false-positive prevention.

still_same_parent_because: It still implements the core pattern of interpreting selected findings through the full claim family.

use_when: Any false claim in the family could cause serious harm, liability, wasted resources, or irreversible action.

use_when: The number of tests is moderate enough that strict control is still usable.

use_when: The environment values high specificity over broad exploratory discovery.

role: Defines the family whose collective false-positive risk is controlled.

role: Sets stricter thresholds for each member of the family.

role: Justifies the strictness of control.

role: Implements strict threshold adjustment.

role: Uses hierarchical logic to control family-level error.

domain: Clinical safety

example: A trial adjusts across several serious adverse-event endpoints before declaring a safety signal.

domain: Quality acceptance

example: A plant controls false acceptance risk across many required inspection checks.

failure_modes: Overly strict thresholds can hide real signals when exploratory discovery is the primary goal.

failure_modes: A badly defined family can create false confidence even under formal correction.

False Discovery Rate Variant

short_definition: A screening-oriented variant that permits many discoveries while controlling the expected share that are false.

distinctive_feature: It focuses on the credibility of the selected set rather than the absolute avoidance of any false positive.

distinct_from_parent: The parent is broader; this variant accepts a calibrated false-discovery burden to preserve useful discovery.

still_same_parent_because: It still disciplines many-claim search by aligning interpretation with the search space.

use_when: Large numbers of candidate signals are screened and some false leads are tolerable.

use_when: The goal is to prioritize follow-up candidates, not to make final irreversible claims from the first screen.

use_when: Discovery value is high enough that overly strict familywise control would be counterproductive.

role: Defines the screened candidate set.

role: Specifies the tolerated false-discovery share.

role: Ensures selected candidates get follow-up before costly action.

role: Controls expected false-discovery proportion.

role: Prioritizes selected leads for confirmation.

domain: Genomics

example: A screen selects candidate genes under an FDR rule and sends them to replication experiments.

domain: Security monitoring

example: An alert system tolerates some false leads but tracks expected false-discovery rate before escalation.

failure_modes: Treating screened candidates as confirmed truths rather than prioritized leads.

failure_modes: Setting an acceptable false-discovery rate without considering downstream action costs.

short_definition: A staged variant that explicitly labels idea-generation evidence separately from confirmation evidence.

distinctive_feature: The central move is status separation across stages rather than only threshold correction.

distinct_from_parent: The parent controls many-claim false-discovery risk; this variant may become broader as a staged epistemic-status pattern for discovery work generally.

still_same_parent_because: In this batch, the variant mainly functions as a way to prevent many exploratory claims from masquerading as confirmed results.

use_when: Broad exploration is necessary but later claims must be credible.

use_when: Discovery and confirmation can be separated by time, dataset, team, site, or protocol.

use_when: Stakeholders frequently overstate exploratory patterns.

role: Labels and separates discovery from confirmation.

role: Creates evidence not used during exploration.

role: Communicates current claim status.

slug: preregistration

role: Locks confirmatory criteria.

role: Provides fresh confirmation evidence.

role: Tests persistence beyond the original exploration.

domain: Product analytics

example: Exploratory segment findings are labeled as leads and require a new experiment before launch claims.

domain: Machine learning

example: A model is tuned on validation data and confirmed only on a locked test set.

failure_modes: The boundary is declared but not enforced.

failure_modes: The confirmatory stage is quietly influenced by exploratory knowledge.

Claim Registry Variant

short_definition: A governance variant that controls multiplicity by making attempted claims, status, and follow-up obligations visible across a portfolio.

distinctive_feature: It uses traceability and governance rather than primarily statistical correction.

distinct_from_parent: The parent includes statistical and procedural strategies; this variant centers on portfolio-level claim memory and accountability.

still_same_parent_because: The goal remains disciplining many attempted claims before action.

use_when: Many teams, analysts, experiments, dashboards, alerts, or investigations generate claims over time.

use_when: The main risk is not a single formula but organizational forgetting, selective reporting, or repeated re-analysis.

use_when: Reviewers need to see what has been tried, what failed, and what remains exploratory.

role: Records attempted and selected claims.

role: Marks evidence maturity.

role: Defines next steps before action.

role: Maintains the portfolio memory.

role: Prevents action without status review.

domain: Analytics governance

example: A company keeps a registry of tested metrics and segment claims so teams cannot revive failed results without evidence.

domain: Regulatory review

example: A review board tracks exploratory safety signals and requires pre-specified confirmation before enforcement.

failure_modes: The registry becomes bureaucratic bookkeeping with no effect on decisions.

failure_modes: Teams avoid registering tests to preserve cherry-picking flexibility.

near_names:
Multiplicity Control
Multiple Comparisons Correction
False Discovery Control
Data-Dredging Guardrail
p-Hacking Guardrail
Look-Elsewhere Effect Control
Trials Factor Correction


Multi-Scale Resilience Architecture

batch: First Iteration/Batch 35

Multi-Level Resilience Architecture

notes: Level language for the same pattern when levels are explicitly tied to scale boundaries and recovery responsibilities.

Cross-Scale Resilience Design

notes: Plain-language near name; keep canonical slug focused on architecture rather than a generic design activity.

Nested Resilience Architecture

notes: Useful when local, subsystem, and whole-system layers are nested rather than merely adjacent.

Resilience Layering

notes: Shorthand only; not enough by itself unless it includes functions, buffers, escalation, recovery, and risk-shift monitoring.

source_primes: resilience scale redundancy

slug: resilience

slug: scale

slug: redundancy

slug: adaptation

slug: coupling

slug: boundary

slug: hierarchy

slug: homeostasis

slug: feedback

slug: constraint

components:
Critical Function by Scale
Scale Boundary Map
Local Buffer
Subsystem Redundancy
System Recovery Path
Cross-Scale Escalation Path
Risk-Shift Monitor
Recovery Authority Allocation
Reserve Capacity Pool
Mutual Aid Linkage
Adaptive Reconfiguration Option
Service-Level Floor
Failure Mode by Scale

mechanisms: Community / Regional / National Resilience Layers

essence_one_line: Design resilience at multiple scales so local failures are absorbed without sacrificing subsystem or whole-system continuity.

compression_statement: When shocks can occur at different levels, build a resilience architecture across local, subsystem, and whole-system scales so absorption, adaptation, escalation, and recovery reinforce rather than undermine each other.

core_intuition: A system can look resilient at one scale while becoming fragile at another. Local buffers can protect units but starve the network; central optimization can preserve aggregate performance while removing local slack. Multi-Scale Resilience Architecture works by asking what must keep functioning at each scale, what each scale should absorb, when stress should move upward or downward, and how to prevent resilience gains in one layer from becoming hidden fragility elsewhere.

canonical_formula: critical functions by scale + boundary buffers + subsystem redundancy + recovery paths + risk-shift monitoring -> resilience that holds across nested levels

structural_problem: A system is resilient at one scale but fragile at another, or a resilience intervention at one level shifts risk, cost, delay, overload, or dependency to another level.

condition: Shocks occur at several scales.

why_it_matters: Local incidents, subsystem congestion, and whole-system disruptions require different response times, authorities, and capacities.

condition: Local units have coping capacity but cannot restore system-wide continuity alone.

why_it_matters: Local resilience can delay collapse but may not coordinate recovery or allocate scarce shared resources.

condition: Central continuity plans exist but ignore local context or local slack.

why_it_matters: High-scale resilience can accidentally strip the very adaptive capacity that makes local units viable.

condition: Redundancy, reserves, or recovery plans are concentrated at only one level.

why_it_matters: One-layer resilience often creates bottlenecks or hidden single points of failure.

condition: Interventions reduce visible disruption in one layer while worsening stress elsewhere.

why_it_matters: This is a sign of risk shifting rather than true resilience improvement.

symptom: Repeated local failures are individually absorbed but aggregate into chronic system degradation.

interpretation: Local buffers are functioning, but the architecture lacks subsystem or whole-system recovery.

symptom: Central recovery succeeds statistically while particular communities, teams, sites, or species lose essential function.

interpretation: Whole-system metrics are hiding local fragility.

symptom: A local fix makes downstream, upstream, regional, or institutional risk worse.

interpretation: Resilience has been purchased by risk export.

symptom: Recovery handoffs are improvised during every incident.

interpretation: Escalation and recovery paths are not architected across levels.

symptom: Redundancy exists but is poorly located, correlated, or inaccessible during stress.

interpretation: Redundancy was added as capacity rather than placed as part of a multi-scale architecture.

root_tension: Resilience needs both local autonomy and system-wide coordination. Too much local self-protection can fragment the system; too much central control can erase local slack, context, and adaptation.

case: The problem is simply insufficient total capacity at one known level.

why_not_this: Capacity reservation or robustness margin design may be enough when cross-scale interaction is not central.

case: The main task is mapping causes across scales before choosing any design.

why_not_this: Use Cross-Scale Causal Mapping first; this archetype designs resilience after relevant scales and functions are known.

case: The main task is choosing which scale to intervene at, not designing a resilience stack across levels.

why_not_this: Use Cross-Scale Intervention Matching when action selection is the core issue.

case: A single backup, reserve, failover, or stockpile solves the problem without cross-scale risk.

why_not_this: That is a mechanism or component, not the full architecture.

structural_intervention: Define critical functions at each scale, place buffers and redundancies at appropriate scale boundaries, create escalation and recovery paths, allocate authority by scale, and monitor whether resilience at one level is shifting risk to another.

Name the scales that matter.

logic: Identify local units, intermediate subsystems, and whole-system governance or environment. Avoid vague multi-level language by defining actual boundaries and dependencies.

Define critical functions by scale.

logic: Specify what must continue, degrade gracefully, or recover quickly at each scale. A local minimum may differ from a regional or whole-system minimum.

name: Map shock directions and scale transitions.

logic: Ask which shocks originate locally, which arrive from higher levels, which cascade upward, and which constraints push downward.

name: Allocate buffers and redundancies across levels.

logic: Put absorption capacity where it reduces propagation without hiding deterioration or creating hoarding, correlated failure, or central bottlenecks.

Define escalation and recovery paths.

logic: Clarify when stress moves from local coping to subsystem coordination to whole-system recovery, and how recovery returns responsibility back down after stabilization.

name: Assign authority and information rights.

logic: Give local actors enough autonomy for fast contextual response while reserving higher-scale authority for shared-resource allocation, prioritization, and coordination.

Monitor cross-scale risk shifting.

logic: Track whether one layer’s apparent resilience is degrading another layer’s slack, function, equity, or recovery capacity.

rule: Preserve function where failure is experienced, not only where metrics are aggregated.

rationale: Whole-system continuity is not enough if local essential functions are repeatedly sacrificed.

rule: Place fast-response capacity near fast disturbances and coordination capacity near shared dependencies.

rationale: Response speed and coordination scope are different design needs.

rule: Use redundancy when failure paths are diverse; use buffers when variation is expected; use reconfiguration when the disturbance changes the structure of demand or supply.

rationale: Different resilience components solve different stress patterns.

rule: Escalate before local coping becomes destructive.

rationale: Exhausted local units may preserve appearances while creating hidden damage.

rule: Treat risk export as a failure of the architecture, not as proof of success at the protected level.

rationale: The archetype aims for cross-scale resilience, not local metric improvement.

invariant: Critical function continuity across scales

description: Essential functions remain available in minimum viable form locally, at subsystem level, and at whole-system level.

invariant: No hidden risk export

description: A resilience gain at one scale should not create unobserved fragility, overload, or dependency at another scale.

invariant: Escalation legibility

description: Actors know when stress should stay local, move laterally, escalate upward, or receive downward support.

invariant: Recovery path integrity

description: The system can move from disruption to degraded function to restored function without losing responsibility or coordination.

invariant: Local adaptive capacity

description: Higher-scale resilience does not strip local actors of the slack and judgment needed for contextual response.

outcome: Local shocks are absorbed before they become systemic failures.

evidence_signal: Common disturbances stop at the designed boundary or are handled through planned lateral support.

outcome: System-wide recovery does not erase essential local functions.

evidence_signal: Recovery metrics include local service floors and not only aggregate restoration.

outcome: Redundancy and buffers are placed where they interrupt actual cross-scale failure paths.

evidence_signal: Stress tests show fewer bottlenecks, single points of failure, and correlated backup failures.

outcome: Escalation and recovery become predictable rather than improvised.

evidence_signal: Incidents follow known triggers, handoffs, and return-to-normal criteria.

outcome: Risk shifting becomes visible and correctable.

evidence_signal: Post-incident review shows whether costs, overload, or fragility moved to another scale.

prose_essence:
Multi-Scale Resilience Architecture designs resilience as a relationship among levels, not as a pile of isolated backups. It asks what must keep functioning locally, what must be coordinated at subsystem level, what must be protected for whole-system continuity, and how those layers support one another under stress.

The core idea is that a system can be resilient in one place and fragile in another. A local unit can protect itself by hoarding scarce resources while weakening the network. A central plan can preserve aggregate continuity while exhausting the local actors who make continuity possible. This archetype treats resilience as an architecture of cross-scale absorption, escalation, adaptation, and recovery.

prose_when_to_use:
Use this archetype when shocks can occur at several scales or move between them. It is especially useful when a local disturbance can become a system-wide failure, when central recovery plans ignore local conditions, when resilience capacity exists but is concentrated at the wrong level, or when one layer’s resilience seems to create another layer’s fragility.

It is also useful when the system has recurring handoff problems during disruption. Local teams, regional coordinators, central authorities, and external partners may each have some role, but the boundaries between them are improvised. Multi-Scale Resilience Architecture turns that improvisation into a designed structure.

prose_structural_problem:
The structural problem is cross-scale fragility hidden behind single-scale resilience. A system may protect local units without preserving whole-system continuity. Or it may preserve aggregate metrics by exhausting local units, suppliers, communities, ecosystems, or teams.

This often appears when resilience is equated with more capacity at one level: more local reserves, a bigger central stockpile, another backup system, or a stronger central command. Those may help, but they do not automatically answer where shocks originate, where they cross boundaries, who should absorb them first, when support should escalate, and how recovery returns the system to a viable operating state.

prose_intervention_logic:
The intervention begins by naming the relevant scales: local units, intermediate subsystems, and whole-system governance or environment. It then defines critical functions by scale. What must a local unit preserve? What must the subsystem coordinate? What must the whole system guarantee?

Next, the design maps shock directions and scale transitions. Some shocks originate locally and propagate upward. Some are system-wide constraints that press downward. Some create subsystem bottlenecks. The architecture places buffers, redundancy, authority, and recovery pathways where these transitions actually occur.

The final step is monitoring risk shifting. A resilience strategy should not count as successful merely because one layer’s metrics improve. The design must ask what happened to the burden, cost, delay, overload, and fragility at other scales.

prose_key_components:
### Critical Function by Scale

A critical function by scale defines what must continue at each level. Local continuity might mean basic service access; subsystem continuity might mean routing, mutual support, or pooled capacity; whole-system continuity might mean strategic allocation and recovery sequencing. Without this component, resilience remains vague.

### Scale Boundary Map

A scale boundary map shows where local units, subsystems, and whole-system actors meet. This is where shocks often cross levels and where responsibility can become unclear. The map helps decide where buffers, escalation triggers, and recovery authority belong.

### Local Buffer

A local buffer absorbs common variation near the point of disturbance. It may be stock, slack time, reserve staff, local autonomy, a local failover path, or a simple emergency procedure. Its job is not to solve all disruption; it keeps ordinary stress from immediately cascading upward.

### Subsystem Redundancy

Subsystem redundancy provides a middle layer of backup or substitution. It prevents the design from depending only on isolated local self-sufficiency or on slow central rescue. Regional surge capacity, supplier diversity, shared support teams, or alternative routing can all function here.

### System Recovery Path

A system recovery path specifies how priority functions are restored after local and subsystem defenses are exceeded. It includes sequencing, decision rights, dependencies, degraded service targets, and return-to-normal criteria.

### Cross-Scale Escalation Path

A cross-scale escalation path defines when stress should move from local handling to lateral aid, subsystem coordination, or whole-system intervention. Good escalation prevents local coping from becoming destructive heroics.

### Risk-Shift Monitor

A risk-shift monitor checks whether resilience at one scale is being purchased by fragility at another. It watches for depleted local slack, overloaded suppliers, hidden recovery debt, inequitable triage, or central policies that make local adaptation harder.

### Recovery Authority Allocation

Recovery authority allocation assigns decision rights by scale. Some decisions need local context; others need regional coordination or central authority. The architecture should not centralize everything under stress or abandon local units to cope alone.

prose_common_mechanisms:
### Nested Resilience Planning

Nested resilience planning links plans across levels. Local, intermediate, and whole-system actors each know what they absorb, what they escalate, what support they can request, and how they participate in recovery. The mechanism implements the archetype, but the archetype is broader than any one plan.

### Community / Regional / National Resilience Layers

Civic resilience often uses community, regional, and national layers. Communities preserve immediate function; regions coordinate surge and mutual aid; national systems provide strategic resources and authority. This is an implementation family for public systems.

### Multi-Level Redundancy Design

Multi-level redundancy design places backup capacity at more than one scale. The important point is not simply having duplicates. The backups must fail differently, be reachable during stress, and match the failure paths they are meant to interrupt.

### Local Recovery Plus Central Support

Local recovery plus central support allows local actors to act quickly while central actors provide resources, legitimacy, or coordination. It prevents both extremes: local abandonment and central takeover.

### Ecological Resilience Design

In ecological settings, the mechanism may include habitat patches, corridors, refugia, disturbance regimes, and landscape-scale restoration. These mechanisms preserve function across organism, patch, watershed, and regional scales.

### Distributed Infrastructure Resilience

Infrastructure and cloud systems often implement this archetype through local isolation, regional failover, global traffic control, and incident command. These are mechanisms when tied to cross-scale function, escalation, and recovery design.

### Organizational Resilience Tiers

Organizations can implement the archetype through team, department, enterprise, and ecosystem resilience responsibilities. A tier chart alone is not enough; each tier needs authority, resources, escalation criteria, and recovery obligations.

### Cross-Scale Buffering Playbook

A cross-scale buffering playbook specifies where buffers sit, when they are released, how depletion is monitored, and how support moves upward or downward. It is best treated as a variant or mechanism inside the broader architecture.

prose_failure_modes:
One failure mode is risk export. The system protects one layer by shifting cost, overload, or fragility to another. This is mitigated through risk-shift monitoring and cross-scale post-incident review.

Another failure mode is a missing middle layer. Local units and central authorities exist, but subsystem redundancy, mutual aid, or regional coordination is weak. The result is a jump from local stress to central crisis.

A third failure mode is central recovery that overrides local essential functions. Aggregate metrics look good while specific communities, teams, suppliers, or ecosystems lose viability.

A fourth failure mode is buffer masking. Local buffers hide chronic system stress until they are depleted. Depletion, repeated local coping, and recovery debt should be treated as system signals.

A fifth failure mode is correlated redundancy. Backup paths exist but share a supplier, geography, platform, policy, or incentive. Stress tests should validate that redundancy is genuinely diverse.

A sixth failure mode is resilience theater. Plans, dashboards, and diagrams exist, but they do not change capacity, authority, escalation, or recovery behavior.

prose_neighbor_distinctions:
**Resilience Capacity Building** builds the general ability to absorb, adapt, and recover. Multi-Scale Resilience Architecture specifies where those capacities belong and how they interact across scales.

**Robustness Margin Design** creates margin against variation. Multi-Scale Resilience Architecture designs buffers, redundancy, escalation, authority, recovery, and monitoring across levels.

**Diverse Functional Redundancy** provides multiple ways to perform a function. In this archetype, redundancy is one component inside a broader cross-scale design.

**Capacity Reservation** protects capacity for future or priority use. This archetype decides which reserves belong at which scale and how using them affects other scales.

**Cross-Scale Buffering** is a subtype focused on placing buffers at scale boundaries. It should remain inside this parent unless later evidence shows enough distinct structure for promotion.

**Cross-Scale Causal Mapping** diagnoses causal movement across levels. Multi-Scale Resilience Architecture uses such diagnosis to design resilience structure.

**Local-Disturbance / Global-Effect Tracing** traces propagation from small disruptions to large effects. This archetype designs the architecture that absorbs, escalates, or recovers from those disruptions.

**Cross-Scale Intervention Matching** chooses the best scale of action. This archetype often requires coordinated action at multiple scales rather than one selected level.

prose_cross_domain_examples:
In public health, local clinics, hospital networks, regional agencies, and national supply systems each preserve different parts of care continuity. The architecture coordinates local buffers, regional surge, national stockpiles, and risk-shift monitoring.

In cloud infrastructure, service cells absorb local faults, regions provide failover, global controls route traffic, and incident command coordinates recovery. The architecture is not any single backup; it is the interaction among layers.

In ecology, local habitat patches, corridors, refugia, watersheds, and regional restoration plans work together to preserve ecological function. Buffers and recovery paths must be placed at ecological boundaries that matter.

In supply chains, local safety stock, supplier diversity, regional logistics alternatives, and enterprise allocation rules are designed together. The architecture also checks whether upstream suppliers become fragile because downstream actors look resilient.

In organizations, teams maintain fallback routines, departments maintain backup roles, the enterprise sets continuity priorities, and leadership monitors burnout or hidden recovery debt.

prose_non_examples:
A local stockpile is not the archetype by itself. It is a buffer mechanism unless it is tied to scale boundaries, escalation, recovery, and risk-shift monitoring.

A central continuity plan is not the archetype if it treats all local units identically and ignores scale-specific functions.

A backup supplier is not the archetype unless supplier diversity is integrated with subsystem redundancy, enterprise recovery, and upstream risk monitoring.

A multi-level dashboard is not the archetype. It can support the archetype only when signals trigger authority, capacity movement, and recovery actions.

A causal map of shock propagation is not the archetype. It helps diagnose where the architecture should act, but it does not itself provide buffers, redundancy, or recovery pathways.

prose_tradeoffs:
The first tradeoff is local autonomy versus central coordination. The design needs local speed and context, but it also needs shared-resource allocation and system-wide priorities.

The second tradeoff is redundancy versus efficiency. Spare capacity can preserve function, but it can also be expensive or illusory if all backups share the same failure mode.

The third tradeoff is standardization versus scale-specific fit. Shared rules make coordination easier, but identical rules across scales may ignore different functions and constraints.

The fourth tradeoff is rapid escalation versus local overload tolerance. Escalating too quickly may overwhelm higher layers; escalating too late may turn local resilience into burnout or hidden damage.

prose_invariants_to_preserve:
The first invariant is critical function continuity across scales. The system should know what minimum viable function means locally, at subsystem level, and at whole-system level.

The second invariant is no hidden risk export. A design that protects one layer by silently burdening another has not achieved cross-scale resilience.

The third invariant is escalation legibility. Actors should know when to handle stress locally, when to seek lateral support, when to escalate upward, and when to return authority downward after recovery.

The fourth invariant is recovery path integrity. The architecture should move from disruption to degraded operation to restoration without losing responsibility or coordination.

The fifth invariant is local adaptive capacity. Higher-scale coordination should not strip away the local judgment and slack that make contextual response possible.

prose_target_outcomes:
A successful architecture absorbs ordinary local shocks before they become systemic failures. It also prevents system-wide recovery from sacrificing essential local functions.

It places redundancy and buffers where they interrupt actual cross-scale failure paths. It makes escalation and recovery predictable rather than improvised. It also makes risk shifting visible enough to correct.

The end state is not a system that never fails. It is a system whose failures are bounded, whose recovery is coordinated, whose local units are not abandoned, and whose whole-system continuity does not depend on hidden local exhaustion.

prose_parameter_dimensions:
**Scale granularity** determines how many layers the architecture distinguishes. Too few layers hide important failure paths; too many layers make governance slow and confusing.

**Buffer placement** determines whether absorption happens locally, at a boundary, in a subsystem pool, or centrally. Placement should match shock speed, coupling, and recovery authority.

**Redundancy diversity** determines whether backup paths fail differently. Redundancy that shares geography, suppliers, data dependencies, governance rules, or incentives may be correlated and therefore brittle.

**Escalation threshold** determines when stress moves to another scale. If thresholds are too low, the system overwhelms higher layers and weakens local learning. If thresholds are too high, local actors are forced into destructive coping.

**Authority distribution** determines who can act during disruption. Local authority improves speed and context; central authority improves coordination and allocation. The architecture tunes both.

**Degraded service floor** determines the minimum function each scale must preserve during stress. This protects local essentials from disappearing inside aggregate recovery metrics.

**Risk-shift sensitivity** determines how quickly the system detects exported fragility. High sensitivity improves ethics and long-term resilience but can create measurement burden.

prose_variants_and_near_names:
The main recognized variant is **Cross-Scale Buffering**. It places buffers at scale boundaries so local variation does not become systemic failure and system pressure does not crush local units. It remains a variant because buffer placement alone does not define critical functions, recovery paths, authority, redundancy, or risk-shift monitoring.

A second variant is **Local Recovery with Central Support**. It is useful when local actors have context and speed but need higher-scale resources or authority. Its failure modes are local abandonment and central command capture.

A third candidate variant is **Cross-Scale Risk-Shift Monitoring**. It focuses on detecting whether resilience at one scale creates hidden fragility elsewhere. It is currently best treated as a monitoring variant or component rather than a separate archetype.

Near names include multi-level resilience architecture, cross-scale resilience design, nested resilience architecture, local/global resilience architecture, and resilience layering. These names should point to the parent when the intervention includes explicit cross-scale functions, buffers, escalation, recovery, and risk-shift monitoring.

Cross-Scale Buffering

variant_type: subtype

short_definition: Place buffers at scale boundaries so local variation does not become systemic failure and system-wide pressure does not crush local units.

distinctive_feature: It focuses specifically on buffer placement at scale boundaries.

distinct_from_parent: The parent archetype coordinates functions, buffers, redundancies, recovery paths, authority, and monitoring across scales; this variant narrows the intervention to absorption capacity at one or more scale boundaries.

still_same_parent_because: Buffer placement alone does not provide the whole architecture; it needs critical functions, escalation, recovery sequencing, and risk-shift monitoring to become resilient rather than merely padded.

source_primes: resilience scale

use_when: A shock crosses from one scale to another because the boundary has too little absorption capacity.

use_when: Local resilience is being overwhelmed by global pressure or global continuity is being threatened by local overload.

use_when: The immediate design question is where to place slack, reserve, isolation, or surge capacity rather than how to redesign the whole resilience architecture.

Scale Boundary Map

role: Identifies where the buffer should sit.

Local Buffer

role: Absorbs common local variation before escalation.

Risk-Shift Monitor

role: Checks whether the buffer relocates fragility rather than reducing it.

Regional Surge Capacity

role: Provides intermediate-scale absorption capacity.

Ecological Buffer Zone

role: Absorbs disturbances at habitat, watershed, or landscape boundaries.

Financial Capital Buffer by Level

role: Separates local, institutional, and systemic absorption capacity.

example: Local clinics keep routine surge stock while regional pools cover outbreaks that exceed local buffers.

example: Cells absorb tenant-level failures before traffic is moved to a regional failover pool.

domain: ecology

example: Riparian buffer zones reduce local runoff pressure before it propagates into watershed-level degradation.

failure_modes: Buffers become hoarded at one scale and unavailable where the shock actually propagates.

failure_modes: Large buffers delay detection of structural fragility.

failure_modes: The buffer is treated as the whole resilience strategy.

Local Recovery with Central Support

short_definition: Allow local units to recover quickly while higher-scale actors supply resources, coordination, or authority that local units cannot provide alone.

distinctive_feature: It emphasizes the balance between local autonomy and higher-scale support during recovery.

distinct_from_parent: The parent includes all cross-scale resilience layers; this variant focuses on recovery authority, handoff, and support flow between local and central levels.

still_same_parent_because: It still depends on the parent architecture to define functions, buffers, redundancies, escalation triggers, and risk-shift monitoring.

source_primes: resilience scale hierarchy

use_when: Local actors have the best context but not enough resources or mandate to recover alone.

use_when: Central actors have resources but would respond too slowly or too bluntly if they fully took over.

use_when: The design must preserve local agency while ensuring whole-system continuity.

Cross-Scale Escalation Path

role: Moves support requests across levels.

Recovery Authority Allocation

role: Clarifies who decides what during recovery.

System Recovery Path

role: Sequences whole-system restoration.

Tiered Incident Command

role: Coordinates local and central response.

Mutual Aid Compact

mechanism_type: agreement

role: Adds lateral support before central takeover.

example: Municipal response manages the incident locally while regional and national agencies supply specialized assets.

failure_modes: Central support becomes command capture.

failure_modes: Local autonomy becomes uncoordinated improvisation.

Cross-Scale Risk-Shift Monitoring

short_definition: Track whether resilience gains at one scale create hidden fragility, cost, delay, overload, or dependency at another scale.

distinctive_feature: It makes risk transfer across scales the primary thing being monitored.

distinct_from_parent: The parent includes monitoring as one guardrail; this variant elevates risk-shift detection into the focal activity.

still_same_parent_because: Risk-shift monitoring does not by itself define the resilience architecture or prescribe where buffers, redundancy, and recovery paths belong.

source_primes: resilience scale feedback

use_when: Local performance improves while downstream, upstream, or higher-scale stress rises.

use_when: A central resilience policy reduces visible incidents but removes local slack or adaptive capacity.

use_when: Stakeholders disagree about whether a resilience strategy reduces risk or exports it.

Risk-Shift Monitor

role: Detects hidden transfer of vulnerability.

Critical Function by Scale

role: Shows which function may be protected or weakened at each scale.

Cross-Scale Resilience Dashboard

role: Displays local, subsystem, and whole-system resilience indicators together.

Post-Incident Risk-Shift Review

role: Examines whether response decisions moved risk to another scale.

example: A firm checks whether supplier-level safety stock reduces factory stoppages while increasing upstream financial fragility.

failure_modes: Monitoring becomes a dashboard without authority to alter the architecture.

failure_modes: Risk-shift metrics are chosen at one scale and miss harms borne elsewhere.

near_names:
Multi-Level Resilience Architecture
Cross-Scale Resilience Design
Nested Resilience Architecture
Resilience Layering
Local / Global Resilience Architecture