Common-Mode Failure Analysis

batch: First Iteration/Batch 16/Wave 2

aliases:
common-mode failure review
common-cause failure analysis
common-cause failure review
correlated failure analysis
shared dependency failure analysis
false redundancy analysis
backup independence analysis
common-mode risk review

related_primes: robustness resilience fault_tolerance observability relation fmea uncertainty boundary risk_aversion

slug: redundancy

slug: robustness

slug: resilience

slug: observability

slug: relation

slug: fmea

components:
Protected Function Set
Redundancy Set
Independence Assumption
Shared Dependency Map
Common Failure Mode Map
Correlated Exposure Register
Diversity or Isolation Requirement
Mitigation Plan
Independence Validation Probe
Blast Radius Model
Common Environment Check
Common Design Lineage Check
Residual Common-Mode Risk Statement

mechanisms: Credential and Infrastructure Dependency Audit

essence_one_line: Identify shared dependencies that could cause supposedly independent backups or safeguards to fail together.

compression_statement: When redundancy appears protective but the redundant elements share hidden dependencies, environments, design assumptions, authorities, or operators, analyze common-mode failure so independence claims are tested and the redundancy can be diversified, isolated, hardened, or governed with explicit residual risk.

core_intuition: A backup is only a backup against failures it does not share. Common-Mode Failure Analysis makes the independence claim visible, searches for the same cause hiding behind multiple paths, and changes the system so one shock cannot quietly defeat all of the supposed protections at once.

canonical_formula: redundancy set + independence assumption + shared dependency map + common failure mode map + mitigation plan + validation probe -> redundancy that is credible against correlated failure

structural_problem: A system relies on multiple components, backups, suppliers, channels, teams, safeguards, or pathways as if they were independent, but they may share a cause that can make them fail at the same time.

condition: Redundancy is being used as a safety or continuity claim

description: The system treats backups, alternate paths, duplicate controls, reserves, or substitute providers as protection against failure.

condition: Independence is assumed rather than demonstrated

description: People know there are multiple elements, but they have not shown that those elements avoid the same upstream dependencies, design flaws, environmental exposures, credentials, operators, incentives, or authorities.

condition: A shared cause could defeat several paths at once

description: A single outage, event, policy change, defect, weather pattern, supplier failure, cognitive bias, funding shock, or governance failure could remove several supposedly separate safeguards.

condition: Consequences of correlated failure are high

description: If the backups fail together, the result is outage, unsafe operation, supply interruption, loss of public trust, regulatory breach, mission failure, or unrecoverable loss.

condition: Diversification, isolation, or explicit risk acceptance is possible

description: The system has enough design discretion to change dependencies, add separation, test backup independence, or document residual risk for review.

symptom: Many backups depend on one upstream resource

meaning: Multiple channels, tools, locations, or teams all require the same power source, identity system, supplier, network, platform, procedure, fuel, or authority.

symptom: Vendor or path diversity is mostly nominal

meaning: The system counts different labels or contracts as diversity even though the providers share infrastructure, sub-tier suppliers, data sources, region, ownership, or operational playbooks.

symptom: Failures surprise because protections disappear together

meaning: A disruption reveals that the backup was exposed to the same condition that disabled the primary path.

symptom: Resilience plans list resources but not dependency independence

meaning: Continuity plans contain reserves, alternates, and emergency procedures, but do not test whether they survive the same triggering event.

symptom: Identical design lineage creates repeated defects

meaning: Several redundant elements reproduce the same software bug, model assumption, procedure error, training weakness, or maintenance failure.

symptom: Risk reviews stop at component reliability

meaning: Each component may look reliable in isolation, but the review has not asked whether their failures are correlated.

root_tension: Redundancy reduces fragility only when the redundant elements are independent with respect to the failure being considered. Efficiency, standardization, shared platforms, common vendors, centralized authority, and common training all make systems easier to operate, but they can also turn many nominally separate protections into one hidden point of failure.

anti_signatures: The problem is simply that no backup exists; draft or use redundant_backup_provisioning instead.

anti_signatures: The main intervention is designing different ways to perform the same function; use diverse_functional_redundancy when analysis is secondary to building diverse pathways.

anti_signatures: The system is already failing and must continue operation under partial failure; use fault_tolerant_operation.

anti_signatures: The core issue is broad dependency visibility, not failure correlation among backups or safeguards; use dependency_exposure or relation-mapping neighbors.

anti_signatures: The artifact being produced is only a table, checklist, or one-time FMEA entry with no mitigation or validation logic; treat it as a mechanism rather than this archetype.

anti_signatures: The shared cause is already known and accepted, and no decision depends on whether redundancy is credible.

structural_intervention: Make independence assumptions explicit, map shared dependencies across redundant elements, identify common failure modes, rate correlated exposure, and change the system through diversity, isolation, hardening, sequencing, monitoring, or explicit residual-risk governance.

step: Name the protected function and redundancy set

logic: Identify what must continue and which components, channels, suppliers, teams, safeguards, or pathways are expected to protect that function.

step: State the independence assumption

logic: Write down what kinds of failures the redundant elements are assumed not to share, rather than leaving independence implicit.

step: Map shared dependencies and conditions

logic: Trace common infrastructure, locations, vendors, code bases, operators, credentials, environments, incentives, governance dependencies, data sources, and procedural lineages.

step: Construct common failure modes

logic: Ask which single cause, shared shock, design flaw, or coordinated pressure could disable several redundant elements at once.

step: Rate correlated exposure against protected functions

logic: Connect each common-mode scenario to the functions it would compromise, the severity of loss, the time window, the detectability, and the available workarounds.

step: Choose mitigation or explicit acceptance

logic: Diversify, isolate, harden, compartmentalize, add alternate authority, change vendor lineage, create procedural separation, or document residual risk when mitigation is not justified.

step: Validate independence under stress

logic: Probe whether the claimed backup remains available when the shared dependency fails, rather than testing only normal activation.

step: Refresh the analysis as dependencies change

logic: Common-mode risk drifts as vendors consolidate, procedures standardize, teams reorganize, infrastructure moves, data sources change, or emergency powers shift.

rule: Do not count a backup as independent until its shared failure causes are named.

rationale: The presence of a second element is not the same as independence against the relevant hazard.

rule: Analyze common-mode exposure at the function level, not only the component level.

rationale: Several different components can fail in different ways yet still remove the same protected function.

rule: Treat standardization as both an asset and a possible common cause.

rationale: Shared designs, procedures, vendors, and credentials reduce complexity but can replicate defects and concentrate exposure.

rule: Prefer diversity or isolation where a shared cause would defeat all safeguards.

rationale: A backup that shares the catastrophic cause with the primary path creates false confidence.

rule: Accept residual common-mode risk only explicitly.

rationale: Some shared exposure is unavoidable; the important requirement is that it be visible, justified, monitored, and assigned to an accountable owner.

rule: Retest after architectural, supplier, staffing, regulatory, or environmental change.

rationale: Independence can decay as organizations consolidate platforms, centralize authority, or shift dependencies.

invariant: Credible independence claim

description: Claims that a backup, safeguard, or alternate path is independent are backed by explicit dependency analysis and validation rather than by naming alone.

invariant: Protected function continuity under shared stress

description: At least one viable path remains for the protected function when a plausible common cause disables another path.

invariant: Visibility of shared dependencies

description: Shared infrastructure, operators, design lineage, suppliers, environments, data sources, and authorities are recorded in a form that can be reviewed and updated.

invariant: Traceable mitigation ownership

description: Each high-value common-mode exposure has an owner, mitigation, test, monitoring plan, or explicit residual-risk acceptance.

invariant: No false redundancy theater

description: The system does not present duplicate-looking elements as resilience when they share the same decisive failure cause.

outcome: Reduced surprise from correlated failure

description: The system is less likely to discover during crisis that all backups depended on the same hidden condition.

outcome: More credible redundancy investments

description: Resources spent on backups, alternate suppliers, independent controls, or safeguards provide real protection against specified failure classes.

outcome: Better prioritization of diversification and isolation

description: Teams can distinguish low-value duplicate capacity from high-value separation, heterogeneity, or compartmentalization.

outcome: Clearer residual risk governance

description: Unavoidable shared exposures are visible and governed rather than hidden inside broad claims of resilience.

outcome: Improved design of functional redundancy and fault tolerance

description: Neighboring reliability archetypes become more effective because their backup paths and continuation modes are checked for shared failure causes.

prose_essence:
Common-Mode Failure Analysis protects a system from **false independence**. It asks whether backups, alternate suppliers, safety controls, redundant channels, governance checks, or substitute teams can fail together because they share a hidden cause.

The archetype matters whenever resilience claims rest on the existence of more than one path. A second path is not automatically independent. It may share the same power source, credentials, supplier, code base, physical environment, operating staff, design assumption, funding authority, political constraint, or recovery procedure. The intervention is to expose those shared causes before a real disruption exposes them.

prose_when_to_use:
Use this archetype when a system says, in effect, “we have a backup,” “we have two suppliers,” “we have multiple channels,” “we have separate safeguards,” or “we have redundant controls,” and the consequences of simultaneous failure would matter.

It is especially relevant when independence has been assumed rather than tested. The trigger is not merely the presence of risk; it is the combination of redundancy, an independence claim, and a plausible shared cause that could defeat the redundancy. It is also useful after incidents where several protections disappeared together, because those incidents often reveal a common-mode structure that was invisible in normal operation.

prose_structural_problem:
The structural problem is that **nominal redundancy can hide a single point of failure**. A system may have many apparent backups, but those backups can be coupled through a shared dependency. That coupling can be technical, physical, institutional, economic, social, or cognitive.

For example, two data centers may be in different places but rely on the same identity provider. Two suppliers may have different names but source the same subcomponent. Two clinical workflows may appear separate but require the same record system login. Several institutional safeguards may be formally independent but rely on the same budget authority or information pipeline.

The deeper tension is between efficiency and independence. Standard platforms, common vendors, common training, centralized authority, and shared infrastructure make systems easier to manage. They also create the possibility that one cause will defeat many protections at once.

prose_intervention_logic:
The intervention begins by naming the protected function. The question is not just “what parts do we have?” but “what function must survive?” Once that function is clear, the redundancy set can be named: the components, channels, suppliers, controls, teams, sites, data sources, or pathways expected to preserve the function.

The next step is to state the independence assumption. What kinds of failures are these elements supposed not to share? Power loss, market shock, operator error, software defect, weather exposure, credential outage, funding cutoff, public panic, misinformation, political pressure, or supplier collapse can all be common causes.

Then the analysis maps shared dependencies and builds common failure modes. The output is not just a map; it is a decision. The system may need more diversity, stronger isolation, independent authority, different design lineage, separate recovery access, better monitoring, or explicit residual-risk acceptance. Finally, the independence claim should be probed under stress. A backup that has only been tested in normal conditions may not be a backup under the condition that matters.

prose_key_components:
### Protected Function Set

The protected function set identifies what must survive: a service, flow, safeguard, decision, care process, communication channel, or institutional obligation. Without this component, the review can become a generic inventory of parts rather than a test of whether the important function remains viable.

### Redundancy Set

The redundancy set names the elements that are being treated as substitutes or backups for one another. These might be servers, suppliers, teams, warehouses, clinics, approval routes, data sources, safety controls, or public communication channels. This component defines the scope of the independence claim.

### Independence Assumption

The independence assumption makes explicit the belief that the redundant elements will not fail for the same reason. It is the central claim under test. In many failures, the assumption was never written down, so no one noticed that the backup depended on the same condition as the primary path.

### Shared Dependency Map

The shared dependency map reveals upstream resources, environments, designs, credentials, vendors, authorities, staff, data, or procedures shared by supposedly separate paths. It is often the most important discovery tool because common-mode risks frequently sit outside the formal boundary of the component being reviewed.

### Common Failure Mode Map

The common failure mode map connects shared dependencies to plausible failure scenarios. A shared dependency is not automatically catastrophic; it becomes a common-mode concern when it can defeat multiple protections under a condition that matters.

### Correlated Exposure Register

The correlated exposure register records which redundant elements are exposed together, which functions would be lost, how severe the loss would be, who owns the mitigation, and what residual risk remains. It turns the analysis into accountable resilience work.

### Diversity or Isolation Requirement

The diversity or isolation requirement specifies what counts as enough separation. That may mean geographic separation, different vendor lineage, separate credentials, independent recovery authority, different skills, alternate media, compartmentalized infrastructure, or different design assumptions.

### Mitigation Plan

The mitigation plan defines how to reduce the common-mode exposure. Mitigation can include diversifying suppliers, isolating control planes, hardening a shared dependency, adding alternate authority, redesigning backup activation, or accepting residual risk explicitly when mitigation is not justified.

### Independence Validation Probe

The independence validation probe tests whether the claimed backup or safeguard remains available when a shared dependency fails. It is not enough to verify that the backup works in normal conditions; the probe must challenge the condition that could disable multiple paths at once.

prose_common_mechanisms:
### Common-Cause FMEA

Common-cause FMEA adapts failure mode analysis to ask which single causes could defeat multiple protections. It is a mechanism, not the archetype itself. It implements the archetype when it leads to independence testing, mitigation, and residual-risk decisions.

### Fault Tree with Common-Cause Branching

A fault tree can represent shared causal branches that lead to multiple failures. This is useful when teams need to see how a single upstream condition can pass through several apparently separate paths.

### Dependency Mapping Workshop

A dependency mapping workshop brings together people who see different parts of the system. Common-mode risks often cross team boundaries, so no single operator, supplier manager, engineer, or policy owner can see the whole exposure alone.

### Backup Independence Test

A backup independence test exercises a backup under a shared dependency outage. The point is not merely to turn the backup on. The point is to see whether it still works without the same network, credential, supplier, authority, facility, fuel, or staff that the primary path requires.

### Supply-Chain Dependency Review

A supply-chain dependency review traces alternate suppliers down to shared sub-tier suppliers, shipping routes, regional exposures, labor constraints, and regulatory chokepoints. It prevents “two suppliers” from becoming a misleading substitute for genuine independence.

### Diverse Vendor Review

A diverse vendor review checks whether vendor diversity is real across infrastructure, ownership, code lineage, support, credentials, and failure response. It is useful only when it tests shared exposure rather than merely counts vendor names.

### Correlated Risk Register

A correlated risk register records common-mode exposures, owners, mitigation status, test evidence, and residual-risk acceptance. It helps keep the analysis alive after the initial review.

### Tabletop Cascade Exercise

A tabletop cascade exercise simulates a shared failure cause and follows how redundant paths respond together. It can reveal timing, authority, communication, and human coordination dependencies that static maps miss.

### Credential and Infrastructure Dependency Audit

This audit checks whether emergency systems, backups, and alternate teams still depend on the same identity provider, cloud control plane, network, physical access system, or infrastructure service. It is especially important in digital and organizational systems.

prose_failure_modes:
The most common failure mode is **cosmetic redundancy**. The system has two of something, but both depend on the same hidden condition. This is mitigated by dependency mapping and independence validation.

Another failure mode is **checklist theater**. The review is completed, but no design, sourcing, procedure, test, or residual-risk decision changes. This is mitigated by tying findings to owners and actions.

A third failure mode is **hidden design lineage**. Redundant elements look separate but share code, model assumptions, procedures, training, or vendor templates. This is mitigated by design-lineage checks and independent validation where needed.

A fourth failure mode is **shared recovery dependency**. The backup exists, but activation or recovery requires the same network, credentials, staff, fuel, manual, spare part, or authority that failed. This is mitigated by testing recovery under loss of the shared dependency.

A fifth failure mode is **over-diversification**. The organization diversifies everything, creating unnecessary complexity and new errors. This is mitigated by prioritizing by consequence, likelihood, detectability, and mitigation cost.

prose_neighbor_distinctions:
Common-Mode Failure Analysis is distinct from **Redundant Backup Provisioning**. Provisioning adds backup capacity; common-mode analysis checks whether that capacity is genuinely independent against relevant failure causes.

It is distinct from **Diverse Functional Redundancy**. Diverse Functional Redundancy designs multiple ways to fulfill the same function; common-mode analysis determines whether existing or proposed ways share a failure cause and what diversity or isolation is needed.

It is distinct from **Fault-Tolerant Operation**. Fault tolerance keeps operating under partial failure; common-mode analysis reduces the chance that all continuation paths fail together.

It is distinct from **Dependency Exposure**. Dependency Exposure is a broader pattern for revealing hidden dependencies. Common-Mode Failure Analysis focuses specifically on dependencies that undermine redundancy, backup, or safeguard independence.

It is distinct from **FMEA**. FMEA is a method family and can be one mechanism used here. The archetype is the broader cross-domain intervention of challenging independence assumptions and mitigating correlated failure.

prose_cross_domain_examples:
In cloud operations, redundant regions may share one identity provider or deployment pipeline. Common-mode analysis asks whether emergency access, rollback, and recovery work when that shared service is unavailable.

In supply chains, two suppliers may share a sub-tier supplier, logistics route, region, or regulatory chokepoint. Common-mode analysis tests whether the alternate source is actually independent under the relevant shock.

In healthcare, backup workflows may depend on the same electronic records system or authorization path as the primary workflow. Common-mode analysis asks whether patient care can continue when that shared dependency fails.

In finance, hedges that look different in normal conditions may all depend on the same liquidity, counterparty network, or model assumption during crisis. Common-mode analysis looks for correlation under stress, not just surface diversity.

In public governance, multiple oversight bodies may be formally independent but share budget authority, appointment channels, or information sources. Common-mode analysis asks whether institutional safeguards can fail together.

prose_non_examples:
A single fragile component with no backup is not Common-Mode Failure Analysis. It calls first for backup provisioning or robustness improvement.

A backup that fails because it was never maintained is not necessarily common-mode failure. It becomes common-mode analysis if the same maintenance dependency can disable several backups together.

A standard FMEA table listing isolated component failures is not the archetype. It is a possible mechanism only when it includes shared causes, correlated exposure, mitigation, and validation.

A general supplier inventory is not the archetype unless it evaluates which shared dependencies can cause supposedly independent suppliers to fail together.

prose_tradeoffs:
The main tradeoff is independence versus efficiency. Shared platforms, common vendors, standard procedures, and centralized authority reduce cost and complexity, but they also concentrate failure exposure.

A second tradeoff is diversity versus maintainability. Different designs, vendors, credentials, and procedures can protect against common-mode failure, but they require more training, testing, integration, and governance.

A third tradeoff is analysis depth versus actionability. A shallow review can miss decisive shared causes; an excessively deep review can become paralyzing. The goal is useful exposure reduction, not exhaustive mapping for its own sake.

A fourth tradeoff is realism versus safety in testing. Stress tests should challenge independence assumptions, but they should not create unmanaged harm.

prose_invariants_to_preserve:
The first invariant is a credible independence claim. If a system claims that a backup or safeguard is independent, that claim should be backed by dependency analysis and stress validation.

The second invariant is protected function continuity under shared stress. At least one viable path should remain for the function that matters when a plausible common cause disables another path.

The third invariant is visibility of shared dependencies. Hidden dependencies should be made reviewable, especially when they connect several safeguards.

The fourth invariant is traceable mitigation ownership. High-consequence correlated exposures should not remain as anonymous warnings. Someone should own the mitigation, monitoring, test, or residual-risk acceptance.

The fifth invariant is avoidance of false redundancy theater. The system should not reassure people with duplicate-looking elements that will disappear together under the same condition.

prose_target_outcomes:
A successful common-mode analysis reduces surprise. Teams are less likely to discover during a crisis that all backups depended on the same unavailable condition.

It also improves the value of redundancy investments. Instead of spending resources on duplicate capacity that shares the decisive failure cause, the system can invest in separation, diversity, isolation, or hardening where it matters.

The archetype also improves adjacent resilience patterns. Redundant Backup Provisioning becomes more credible because the backups are tested for independence. Diverse Functional Redundancy becomes more targeted because the required diversity is tied to actual shared exposures. Fault-Tolerant Operation becomes safer because continuation paths are less likely to fail together.

prose_parameter_dimensions:
The first tuning dimension is **scope**. A common-mode review can focus on one protected function, one backup pair, one supplier category, one facility, one control family, or an entire operational ecosystem. Narrow scope is easier to act on; broad scope better reveals systemic coupling.

The second dimension is **dependency depth**. Looking only one layer upstream may miss sub-tier suppliers, hidden credentials, design lineage, or shared authority. Looking too deeply can make the analysis unmanageable. The right depth depends on consequence severity and practical decision value.

The third dimension is **independence standard**. Some systems only need partial independence; others require strong physical, procedural, vendor, or authority separation. The standard should be explicit enough that a backup can pass or fail it.

The fourth dimension is **test realism**. More realistic tests reveal more, but they also carry more operational risk. A good validation probe is bounded, reversible, and serious enough to challenge the independence assumption.

The fifth dimension is **residual risk tolerance**. Eliminating every shared cause is impossible. The archetype requires explicit acceptance of residual common-mode risk, not an illusion of perfect separation.

prose_variants_and_near_names:
**Common-Cause Failure Analysis** is a cause-centered variant. It asks which single cause could defeat multiple protections.

**Backup Independence Analysis** is a backup-centered variant. It asks whether a standby resource, alternate path, or recovery procedure remains available under the same stress that disables the primary path.

**Shared Dependency Review** is a mapping-heavy variant. It emphasizes upstream dependency visibility but should not stop at mapping; it must connect findings to common failure modes and mitigation.

**Correlated Risk Analysis** is a portfolio or risk-management variant. It asks whether several protective positions, hedges, safeguards, or resources are correlated under stress.

Near names include common-mode failure review, common-cause failure review, false redundancy analysis, shared dependency failure analysis, and backup independence testing.

Common-Cause Failure Analysis

short_definition: A causal form of common-mode review that asks which single cause could defeat multiple redundant paths or safeguards.

distinctive_feature: Centers the analysis on one shared cause and its effects across multiple protections.

distinct_from_parent: The parent includes dependency, lineage, environment, and correlation analysis; this variant emphasizes common causes as the organizing lens.

still_same_parent_because: It uses the same intervention logic of testing independence and mitigating correlated failure.

source_primes: redundancy coupling fmea

use_when: A single initiating event, defect, operator action, environmental condition, or governance failure could remove multiple protections.

use_when: Teams need a cause-centered analysis rather than a dependency inventory alone.

Common Failure Mode Map

role: Names the shared cause and paths it defeats.

notes: Required for cause-centered variants.

Correlated Exposure Register

role: Records the protected functions exposed to the common cause.

notes: Keeps causal findings actionable.

Common-Cause FMEA

mechanism_type: method

role: Structured method for cause-centered review.

Fault Tree with Common-Cause Branching

role: Visualizes shared causal branches.

example_domains:
safety engineering
cloud operations
public infrastructure

domain: Aviation or safety engineering

example: Two safeguards share one sensor design that can misread the same condition.

domain: Cloud operations

example: Several backup paths require one identity provider to authorize recovery.

failure_modes: Treating common-cause review as a table exercise without mitigation.

failure_modes: Stopping at obvious causes and missing shared governance or operator dependencies.

Backup Independence Analysis

short_definition: A backup-focused variant that tests whether alternate capacity, suppliers, records, channels, or roles remain available under the same stress that disables the primary path.

distinctive_feature: Focuses on the credibility of backup and alternate-path independence.

distinct_from_parent: The parent can evaluate any redundant safeguards; this variant specifically targets backup paths and standby resources.

still_same_parent_because: The core logic remains shared dependency mapping, correlated exposure identification, and independence validation.

use_when: The system already has backup resources and the question is whether they are truly independent.

use_when: Recovery plans assume alternates will be available but have not tested shared dependencies.

Redundancy Set

role: Defines primary and backup elements.

notes: Variant-specific emphasis on backup resources.

Independence Validation Probe

role: Tests backup behavior under shared stress.

notes: Often the most important component in this variant.

Backup Independence Test

role: Exercises backups under shared dependency outage.

Tabletop Cascade Exercise

mechanism_type: ritual

role: Surfaces timing and coordination dependencies in backup activation.

example_domains:
software reliability
hospital continuity
records management
emergency communications

domain: Data systems

example: Testing whether backups can be restored without the primary network or identity provider.

domain: Operations

example: Checking whether deputy roles can act when the normal approval authority is unavailable.

failure_modes: Forgetting that backups need separate access, authority, and maintenance paths.

Shared Dependency Review

short_definition: A dependency-centered review that looks for upstream resources, controls, or conditions shared by multiple protections.

distinctive_feature: Emphasizes shared dependency visibility rather than causal modeling or testing.

distinct_from_parent: The parent includes mitigation and validation; this variant is the mapping-heavy part of the intervention.

still_same_parent_because: It is not complete unless it connects shared dependencies to common failure modes and mitigation decisions.

source_primes: coupling observability relation

use_when: The same dependency may sit behind several supposedly separate paths.

use_when: The immediate need is visibility before deciding on diversification, isolation, or residual-risk acceptance.

Shared Dependency Map

role: Maps common upstream dependencies.

notes: Primary component for this variant.

Diversity or Isolation Requirement

role: Translates dependency findings into design requirements.

notes: Prevents mapping-only drift.

Dependency Mapping Workshop

mechanism_type: workshop

role: Elicits dependencies across teams.

name: Credential and Infrastructure Dependency Audit

mechanism_type: procedure

role: Finds common access and platform dependencies.

example_domains:
infrastructure
software operations
governance
supply chains

domain: Public services

example: Mapping whether emergency offices all rely on one communications provider.

failure_modes: Becoming a general dependency map without the redundancy/failure-correlation focus.

Correlated Risk Analysis

short_definition: A quantitative or portfolio-style variant that analyzes whether risks assumed to offset or diversify one another actually fail together under stress.

distinctive_feature: Uses correlation and shared stress scenarios as the main language.

distinct_from_parent: The parent is broader and need not be quantitative; this variant is useful where portfolio or correlated-risk vocabulary dominates.

still_same_parent_because: It still tests the independence of protective elements and mitigates shared failure exposure.

source_primes: uncertainty risk_aversion coupling

use_when: Multiple hedges, safeguards, or resources are expected to diversify risk.

use_when: The key concern is correlation under stress rather than ordinary failure rate.

Correlated Exposure Register

role: Records correlated risk exposures.

notes: Especially useful in portfolio-like applications.

Residual Common-Mode Risk Statement

role: Documents accepted correlation risk.

notes: Makes residual exposure explicit.

Correlated Risk Register

mechanism_type: document

role: Tracks correlated exposures and owners.

example_domains:
finance
supply chains
emergency planning
infrastructure portfolios

domain: Finance

example: Hedges that all depend on market liquidity during the same stress event.

failure_modes: Assuming historical low correlation will hold under extreme stress.

failure_modes: Focusing on numeric correlation while ignoring institutional and operational shared causes.

near_names:
common-mode failure review
common-cause failure review
common-cause failure analysis
false redundancy analysis
backup independence testing
shared dependency failure analysis


Commons Governance

type: archetype

source: generated

batch: First Iteration/Batch 14

related_primes: externality legitimacy accountability access_control constraint boundary feedback reciprocity incentive_compatibility equity

slug: externality

slug: legitimacy

slug: accountability

slug: constraint

slug: boundary

slug: feedback

slug: reciprocity

slug: equity

components:
Shared Resource Boundary
Access Rule
Use Quota or Use Limit
Monitoring Signal
Sanction Rule
Replenishment Rule
Legitimacy Basis
Dispute Resolution Path
Adaptation Cadence
Contribution Rule
Funding Pool
Exception Process
Transparency Record

mechanisms:
Quota System
Graduated Sanctions
Participatory Rulemaking
Resource Monitoring Dashboard
Replenishment Fund
Maintenance Rotation
Cap-and-Trade
Congestion Pricing
Commons Charter

essence_one_line: Govern shared resources so individually rational use, neglect, or pollution does not destroy collective viability.

compression_statement: When many actors can draw from, burden, or maintain a shared resource, commons governance creates legitimate access rules, use limits, monitoring, sanctions, replenishment duties, and adaptation processes that align local incentives with durable collective use.

core_intuition: A commons fails when each user sees the private benefit of one more use or one less contribution, while the damage is spread across everyone. Governance changes the local decision environment so the resource remains visible, bounded, maintained, and protected by rules people can understand and accept.

canonical_formula: shared_resource + distributed_access + private_gain / shared_cost -> governance_rules + monitoring + sanctions + replenishment + legitimacy -> sustainable_collective_use

structural_problem: A shared resource is vulnerable to overuse, depletion, congestion, pollution, or neglect because individual actors receive local benefits while costs, risks, maintenance burdens, or long-term damage are distributed across the group.

condition: Many actors can access or affect the same resource.

why_it_matters: Distributed access creates cumulative effects that no single actor fully controls.

condition: The resource has finite stock, finite throughput, finite attention, finite tolerance, or finite maintenance capacity.

why_it_matters: Unbounded use can degrade quality, availability, or renewal.

condition: Individual users do not automatically bear the full cost of their use or neglect.

why_it_matters: Private incentives diverge from collective viability.

condition: Pure exclusion, privatization, or central command would be illegitimate, impractical, or too costly.

why_it_matters: The solution must coordinate shared use rather than simply remove shared access.

symptom: The resource deteriorates while each actor can justify their own marginal use.

interpretation: Local rationality is overpowering collective sustainability.

symptom: Maintenance falls on a small group while many benefit.

interpretation: Contribution duties are under-specified or unenforced.

symptom: Rules exist informally but are applied inconsistently.

interpretation: Legitimacy, monitoring, or sanction design is weak.

symptom: Users race to consume before others do.

interpretation: Open access and scarcity have created a first-mover extraction incentive.

symptom: Conflicts recur around access, fairness, and exceptional cases.

interpretation: The commons lacks a trusted dispute and adaptation process.

root_tension: Each participant can gain from one more use, one less contribution, or one more burden shifted outward, while the cumulative loss is delayed, dispersed, or hard to attribute.

case: The resource is fully private and use does not affect others.

why_not: Ordinary ownership or contract design may be enough.

case: The problem is underproduction of a non-rival shared benefit rather than overuse or neglect of a shared resource.

why_not: Public_goods_provision is the closer archetype.

case: A central authority can directly allocate the resource without legitimacy, information, or enforcement problems.

why_not: Simple administrative allocation may be sufficient.

case: The apparent commons problem is actually a one-time dispute between two parties.

why_not: Conflict resolution or adjudication may be more precise.

structural_intervention: Create a legitimate governance arrangement that defines the shared resource, specifies access and use rules, observes resource condition and behavior, enforces proportional consequences, assigns replenishment duties, resolves disputes, and revises rules as conditions change.

action: Bound the commons.

purpose: Identify the resource, affected users, relevant outsiders, renewal constraints, and damage pathways.

action: Define rights and responsibilities.

purpose: Clarify who may access the resource, how much they may use, what they owe back, and who may change the rules.

action: Make use and condition visible.

purpose: Establish monitoring that shows both resource health and participant behavior.

action: Attach consequences to violations and neglect.

purpose: Use sanctions, incentives, or access changes that make overuse and under-maintenance costly enough to deter.

action: Provide replenishment and repair.

purpose: Create funding, labor, restoration, moderation, or maintenance routines that keep the resource viable.

action: Preserve legitimacy and adaptability.

purpose: Use participation, review, appeals, and periodic rule revision so governance remains trusted and fit for changing conditions.

rule: Use commons governance when the protected object is a shared resource, capacity, sink, or maintenance burden whose degradation is cumulative.

implication: Do not use it merely because several parties are involved.

rule: Choose the least coercive rule set that can reliably preserve the resource.

implication: Avoid heavy enforcement where visibility, norms, or contribution design would suffice.

rule: Sanctions should be proportional to harm, repetition, intent, and repairability.

implication: Punishment without legitimacy can damage the commons community.

rule: Replenishment duties must be paired with access benefits or governance voice.

implication: Users are more likely to contribute when obligations are understandable and reciprocal.

rule: Adapt rules when resource condition, demand, or membership changes enough to alter the original assumptions.

implication: A static governance design can become obsolete even if it was initially fair.

invariant: The resource remains viable across repeated use.

why: Short-term access must not destroy long-term availability.

invariant: Rules are legitimate enough that participants can accept enforcement.

why: Commons governance depends on compliance, cooperation, and dispute handling, not only force.

invariant: Use limits are connected to observable resource condition.

why: Arbitrary limits will be resisted and may fail to protect the actual resource.

invariant: Maintenance or replenishment duties are not indefinitely shifted to a small unprotected subgroup.

why: Hidden maintenance exploitation creates burnout and institutional decay.

invariant: The governance system can revise itself as conditions change.

why: Commons dynamics are often nonlinear and context-dependent.

outcome: Reduced overuse, depletion, congestion, pollution, or neglect.

observable_signal: Resource condition stabilizes or improves while legitimate use continues.

outcome: More predictable access and contribution expectations.

observable_signal: Participants understand what is allowed, owed, and appealable.

outcome: Lower conflict around shared-resource use.

observable_signal: Disputes move through defined processes rather than recurring informal power struggles.

outcome: More durable maintenance and stewardship.

observable_signal: Upkeep is funded, scheduled, staffed, or otherwise reliably supplied.

outcome: Better alignment between individual choices and collective viability.

observable_signal: Local actions increasingly reflect the true cost of resource use and neglect.

prose_essence:
Commons Governance is the intervention pattern for protecting a shared resource from the predictable gap between individual incentives and collective viability. It applies when many actors can draw from, burden, pollute, congest, or neglect the same resource, and each actor’s local choice looks reasonable while the accumulated result becomes depletion, decay, overload, or unfair maintenance burden.

The archetype does not mean “make a rule” or “ration a resource.” It means building a legitimate governance arrangement around the shared resource: who can use it, how much use is sustainable, how the condition of the resource is observed, what happens when rules are violated, who repairs or replenishes the resource, and how rules are revised when conditions change.

prose_when_to_use:
Use this archetype when a resource is shared enough that unilateral private decisions can damage it, but valuable enough that simple exclusion would be too blunt. It fits repeated-use settings: fisheries, water systems, roads, open-source projects, shared compute clusters, community gardens, public facilities, shared attention, shared data repositories, and other collective resources.

It is especially relevant when people say, “Everyone’s behavior makes sense individually, but the system is getting worse.” That sentence is often the practical signature of a commons problem.

prose_structural_problem:
The structural problem is distributed benefit with distributed cost. A user gets the benefit of one more fish caught, one more server job run, one more meeting scheduled, one more request filed, or one less maintenance task completed. The cost is spread across everyone as lower stock, slower access, worse quality, delayed repair, exhausted maintainers, degraded trust, or a damaged public environment.

This gap creates a race: use before others use, defer maintenance because others may do it, or push harm into a shared sink because the individual effect seems small. Left alone, the shared resource may cross thresholds where recovery is expensive or impossible.

prose_intervention_logic:
Commons Governance changes the decision environment around the shared resource. First, it defines what the commons is and who has legitimate claims around it. Then it sets access and use rules that reflect capacity or renewal constraints. It adds monitoring so resource condition and behavior are not hidden. It adds sanctions or consequences so evasion is not rational. It adds replenishment duties so the resource is repaired, maintained, or restored. Finally, it preserves legitimacy through participation, transparency, appeals, and rule revision.

The causal logic is: make the commons visible, make use bounded, make neglect accountable, make repair normal, and make the rule system legitimate enough to survive repeated conflict.

prose_key_components:
**Shared Resource Boundary** defines the resource, its affected users, and the harm or renewal pathways. Without this boundary, the governance system cannot know what it is protecting or when it is succeeding.

**Access Rule** specifies who may use, alter, draw from, or burden the resource. Good access rules protect the commons without turning stewardship into arbitrary exclusion.

**Use Quota or Use Limit** constrains extraction, load, pollution, or congestion. A quota is only one possible implementation; the broader component is a limit that connects use to resource capacity.

**Monitoring Signal** makes the resource’s condition and participant behavior visible. Monitoring can be technical, social, institutional, or audit-based, but it must be trusted enough to support rule changes and enforcement.

**Sanction Rule** defines consequences for violating rules, evading duties, or damaging the resource. Effective sanctions are usually graduated and proportional, because legitimacy matters in repeated communities.

**Replenishment Rule** ensures the commons is maintained, restored, repaired, funded, moderated, or renewed. This component is crucial for commons that fail by neglect rather than direct extraction.

**Legitimacy Basis** gives participants reasons to accept the rules. Legitimacy may come from consent, representation, expertise, custom, transparent evidence, public mandate, or demonstrated effectiveness.

**Dispute Resolution Path** handles edge cases, accusations, conflicts, and appeals. Without it, enforcement becomes personal, political, or arbitrary.

**Adaptation Cadence** revises the governance system as demand, resource condition, technology, or membership changes. A commons rule that cannot adapt can become both ineffective and unjust.

prose_common_mechanisms:
A **Quota System** implements bounded use by assigning allowable extraction, consumption, or load. It is a mechanism, not the archetype, because it does not by itself provide legitimacy, replenishment, appeals, or monitoring.

**Graduated Sanctions** implement proportional enforcement. They are common in ongoing communities because small violations, repeated abuse, and severe harm should not all receive the same response.

**Participatory Rulemaking** gives affected users a role in shaping rules. It helps when local knowledge and compliance are essential, though it still needs clear decision rights and safeguards against capture.

A **Resource Monitoring Dashboard** makes stock, throughput, congestion, backlog, degradation, or compliance visible. It supports governance but does not decide what should happen.

A **Replenishment Fund** pays for restoration, repair, moderation, inspection, or shared infrastructure. It is especially useful when the commons is maintained by a few people but benefits many.

A **Maintenance Rotation** assigns upkeep work across users or members. It fits smaller communities where labor contribution is feasible and shared responsibility reinforces reciprocity.

**Cap-and-Trade** can govern a shared sink by setting a total cap and allowing transfers within it. In this draft it is treated as a mechanism under Commons Governance or Externality Internalization, not as its own archetype.

**Congestion Pricing** can reduce peak demand on shared capacity. It must be used carefully because pricing can protect capacity while unfairly excluding people with less ability to pay.

A **Commons Charter** documents the resource boundary, rights, duties, monitoring, sanctions, and revision process. It helps turn implicit norms into a governable institution.

prose_failure_modes:
**Symbolic rules without enforcement** occur when rules exist but violations are not observed or addressed. The mitigation is to add trusted monitoring, graduated sanctions, and visible follow-through.

**Capture by powerful users** occurs when rulemaking protects incumbents or shifts costs to weaker participants. The mitigation is representation, transparency, appeals, conflict-of-interest controls, and equity review.

**Surveillance overreach** occurs when monitoring expands beyond the resource problem. The mitigation is proportional data collection, privacy safeguards, auditability, and deletion rules.

**Maintenance burnout** occurs when a small group silently sustains the shared resource. The mitigation is contribution rules, funding, rotation, paid stewardship, or scope reduction.

**Rigid quota failure** occurs when use limits ignore changing conditions. The mitigation is resource-condition triggers, periodic review, and exception processes.

**Illegitimate exclusion** occurs when governance protects the commons by excluding people without fair criteria. The mitigation is access review, appeals, and separation of resource-protection rules from status-based gatekeeping.

**Boundary leakage** occurs when users shift harm outside the governed boundary. The mitigation is boundary revision, coordination with neighboring institutions, or externality accounting.

prose_neighbor_distinctions:
**Public Goods Provision** solves underproduction of a shared benefit. Commons Governance solves overuse, congestion, pollution, or neglect of a shared resource. A public radio station may need provision; a fishery needs commons governance.

**Externality Internalization** changes the decision boundary so actors account for spillovers. Commons Governance may internalize spillovers, but it does so through ongoing shared-resource rules, monitoring, sanctions, and replenishment.

**Resource Rationing** allocates scarce access. Commons Governance may include rationing, but adds legitimacy, stewardship, dispute handling, monitoring, and adaptation.

**Constraint Envelope Adjustment** changes operating limits. Commons Governance builds an institution around a shared resource, not only a boundary condition.

**Priority-Based Admission** decides who gets access first. Commons Governance decides how access, use, maintenance, and enforcement preserve viability across repeated use.

**Price Signal Design** can be a mechanism inside Commons Governance, especially for congestion, but pricing alone is not enough when legitimacy, monitoring, and maintenance are central.

prose_cross_domain_examples:
In **fisheries**, catch limits, seasonal closures, monitoring, and local participation protect fish stocks from cumulative extraction.

In **groundwater**, pumping rights and aquifer monitoring prevent individually rational wells from collectively depleting the water table.

In **open-source software**, maintainer rules, contribution pathways, funding, moderation, and release authority protect the codebase and maintainer capacity.

In **shared cloud infrastructure**, quotas, priority classes, dashboards, and exception paths prevent one team’s workload from degrading access for others.

In a **community garden**, water rules, plot responsibilities, maintenance days, tool-care duties, and dispute resolution preserve shared land and equipment.

In **organizational attention**, meeting-load norms and escalation rules protect shared cognitive capacity from being consumed by individually reasonable requests.

prose_non_examples:
A private team deciding how to use its own equipment is not Commons Governance unless other actors have legitimate shared access claims.

A fundraising campaign for a shared benefit that does not degrade through use is better treated as Public Goods Provision.

A pollution tax without a shared-resource governance institution is usually Externality Internalization or Price Signal Design.

A one-time waiting list for scarce appointments is usually Priority-Based Admission or Resource Rationing, not Commons Governance.

prose_tradeoffs:
Commons Governance always trades access against preservation. Strong protection can reduce use; weak protection can destroy the basis for use.

It also trades monitoring against privacy and burden. Measurement is necessary, but surveillance can become a new harm. It trades local fit against central coherence: local rules may work well for one group but fail to coordinate broader spillovers. It trades flexibility against predictability: adaptive governance is responsive, but constant rule changes can confuse users and weaken trust.

prose_invariants_to_preserve:
The first invariant is resource viability: repeated use must not destroy the resource. The second is legitimate access: protection should not become arbitrary exclusion. The third is proportional accountability: users should face consequences for damage, but those consequences should be fair, evidence-based, and appealable.

The fourth invariant is replenishment: the commons must have a way to repair itself. The fifth is adaptability: as conditions change, rules must change before the resource fails or the governance system loses trust.

prose_target_outcomes:
A successful Commons Governance intervention stabilizes or improves resource condition while preserving legitimate use. It reduces races to overuse, makes access expectations predictable, and lowers recurring conflict around shared resources.

It also makes maintenance visible and distributed. Instead of a hidden few carrying the system, the governance arrangement clarifies who contributes, who decides, and how the resource remains viable over time.

prose_parameter_dimensions:
The main tuning dimension is **boundary breadth**: draw the commons too narrowly and harm leaks outside the system; draw it too broadly and governance becomes unmanageable.

**Access openness** determines who can use the resource. Too open, and the commons can return to depletion or congestion. Too closed, and governance becomes exclusion.

**Use-limit strictness** determines how tightly use is constrained. Strict limits may protect the resource but suppress valuable use; loose limits may preserve convenience while allowing decline.

**Monitoring intensity** must be strong enough to support trust and enforcement, but not so invasive or expensive that the governance system becomes harmful in its own right.

**Sanction severity** must deter evasion while preserving legitimacy. All-or-nothing punishment often fails in repeated communities.

**Replenishment burden** must be high enough to sustain the resource and low enough that contribution remains feasible.

**Local autonomy versus central coordination** determines who makes rules. Local systems often fit context better; central systems may coordinate broader spillovers and prevent local capture.

prose_variants_and_near_names:
**Common-Pool Resource Governance** is the classic variant: a resource is subtractable or congestible, and exclusion is costly. Fisheries, groundwater, grazing land, and shared compute capacity fit this variant.

**Congestion Commons Governance** focuses on shared capacity rather than permanent depletion. Roads, public facilities, wireless channels, and shared servers can fail by overload.

**Maintenance Commons Governance** focuses on under-maintenance. Open-source projects, shared workshops, knowledge bases, and community spaces often fail because many benefit but few repair.

**Pollution-Sink Governance** treats an absorptive capacity as the commons. Air quality, noise tolerance, safety margins, and organizational attention can all be overloaded by small individual burdens.

Near names include shared-resource governance, commons management, common-pool resource institutions, and community resource rules. Quotas, cap-and-trade, dashboards, dues, and maintenance rotations are mechanisms under the archetype, not separate top-level archetypes in this draft.

Common-Pool Resource Governance

short_definition: Governs a resource that is subtractable or congestible but costly to exclude from use.

distinctive_feature: The key problem is rival or subtractable use inside a shared access setting.

distinct_from_parent: This is the classic finite-resource case inside the broader commons governance archetype.

still_same_parent_because: It still relies on access rules, use limits, monitoring, sanctions, replenishment, legitimacy, and adaptation.

condition: Extraction, congestion, or degradation by one user reduces availability or quality for others.

condition: Pure privatization or pure open access would either exclude legitimate users or invite depletion.

Shared Resource Boundary

role: Defines the pool and user population.

Use Quota or Use Limit

role: Prevents extraction beyond renewal or capacity.

Monitoring Signal

role: Tracks resource stock and use behavior.

Quota System

role: Assigns bounded use rights.

Graduated Sanctions

role: Discourages repeated overuse.

example_domains:
fisheries
groundwater
grazing land
cloud infrastructure capacity

domain: fisheries

example: Catch limits paired with monitoring and penalties.

domain: infrastructure

example: Shared compute quotas and throttling for common clusters.

cause: Limits exist but use is not observed reliably.

mitigation: Add trusted measurement and audit paths.

Congestion Commons Governance

short_definition: Governs shared capacity where simultaneous use creates delay, crowding, or quality degradation.

distinctive_feature: The scarce object is usable capacity or throughput rather than stock that is consumed permanently.

distinct_from_parent: The parent covers depletion, pollution, neglect, and congestion; this variant emphasizes load-shaping over renewal.

still_same_parent_because: The intervention still governs shared access, limits, monitoring, and enforcement around a common resource.

source_primes: resource_management constraint feedback

condition: The resource is not depleted permanently, but peak demand reduces service for everyone.

condition: Local decisions about access timing or intensity impose congestion on other users.

Access Rule

role: Defines who may use capacity and under what conditions.

Monitoring Signal

role: Tracks load, delay, and crowding.

Congestion Pricing

role: Reduces peak pressure through a price signal.

Quota System

role: Caps use during constrained windows.

example_domains:
roads
wireless spectrum
shared servers
public facilities

domain: transportation

example: Peak-period road pricing tied to congestion indicators.

domain: computing

example: Cluster usage limits during high-demand periods.

cause: Congestion controls allocate access only by willingness or ability to pay.

mitigation: Add equity exemptions, alternatives, or non-price access windows.

Maintenance Commons Governance

short_definition: Governs shared assets that fail because everyone benefits from upkeep but no one reliably maintains them.

distinctive_feature: The intervention emphasizes replenishment, repair, moderation, and duty assignment.

distinct_from_parent: The parent also covers overuse; this variant is centered on neglect of shared benefit infrastructure.

still_same_parent_because: The same governance structure is used: define access, obligations, monitoring, sanctions, legitimacy, and adaptation.

condition: The main failure is under-maintenance rather than over-extraction.

condition: Beneficiaries depend on a shared artifact, codebase, facility, knowledge base, or infrastructure layer.

Replenishment Rule

role: Defines how upkeep is supplied.

Contribution Rule

role: Connects benefit to contribution.

Maintenance Rotation

role: Allocates upkeep work.

Replenishment Fund

role: Funds repair or stewardship.

example_domains:
open-source software
shared facilities
knowledge commons
neighborhood infrastructure

domain: open-source

example: Maintainer rules that require reviews, funding, and contribution pathways.

domain: facilities

example: Shared workshop maintenance duties tied to access privileges.

cause: Maintenance depends on a small group of contributors.

mitigation: Add contribution rules, funding, rotation, or scope reduction.

Pollution-Sink Governance

short_definition: Governs a shared sink or tolerance boundary that many actors can overload with harm.

distinctive_feature: The resource being protected is often an invisible capacity to absorb waste, risk, noise, or stress.

distinct_from_parent: The parent covers all commons; this variant emphasizes cumulative spillover and externality boundaries.

still_same_parent_because: It still governs a shared capacity through limits, monitoring, enforcement, and legitimacy.

condition: The shared resource is an absorptive capacity, safety margin, or environmental tolerance.

condition: Each actor benefits from imposing small harms whose cumulative effect damages everyone.

Shared Resource Boundary

role: Defines the sink or tolerance capacity.

Monitoring Signal

role: Measures cumulative load and damage.

Cap-and-Trade

role: Limits total load while allowing decentralized adjustment.

Quota System

role: Allocates allowable emissions, noise, risk, or load.

example_domains:
air quality
noise pollution
shared safety margins
organizational attention load

domain: environment

example: Emission limits that protect a shared air shed.

domain: organization

example: Meeting-load governance that protects shared attention capacity.

cause: Actors shift harm outside the measured sink or accounting boundary.

mitigation: Revise boundaries and monitoring to include displaced harms.

near_names:
Commons Management
Shared Resource Governance
Common-Pool Resource Institutions
Community Resource Rules
Resource Rationing
Tragedy-of-the-Commons Solution


Comparative Advantage Specialization

slug: modularity

slug: interoperability

components:
Opportunity Cost Comparison
Role Specialization Rule
Exchange Channel
Coordination Protocol
Dependency Review
Capability and Capacity Map
Reversibility Plan
Fairness and Power Review
Transaction Cost Check

mechanisms: Supplier or Partner Specialization Contract

essence_one_line: Assign work to actors or units based on lowest opportunity cost rather than absolute ability alone.

compression_statement: When tasks can be divided and outputs can be exchanged or recombined, specialize actors where their relative opportunity cost is lowest so the whole system gains more value than if everyone did the same work or if work followed absolute skill alone.

core_intuition: The best person to do a task is not always the person who is absolutely best at it. It is often the person who gives up the least valuable alternative by doing it, provided the specialized outputs can be coordinated and exchanged.

canonical_formula: For actors A and tasks T, assign actor a to task t when opportunity_cost(a, t) is lower relative to a's alternatives than competing assignments, then connect specialized outputs through exchange and coordination safeguards.

structural_problem: Work is allocated by habit, status, absolute skill, local ownership, politics, or equal rotation even though different actors face different opportunity costs across tasks. The result is avoidable loss of total output, duplicated effort, blocked exchange, or misused scarce capability.

trigger_conditions: Tasks, functions, or services can be divided without destroying their value.

trigger_conditions: Actors, teams, units, or partners differ in relative opportunity costs, constraints, learning curves, or context advantages.

trigger_conditions: Specialized outputs can be exchanged, handed off, integrated, or recombined.

trigger_conditions: Current assignment is based on who is best in absolute terms, who already owns the work, who is available first, or who has political claim.

trigger_conditions: The cost of coordination is lower than the expected gain from specialization.

symptoms: High-skill actors spend scarce time on tasks that others could do at lower relative cost.

symptoms: Multiple units duplicate the same work while neglected work waits elsewhere.

symptoms: A party that is good at everything becomes overloaded because absolute superiority is mistaken for comparative advantage.

symptoms: Role assignments feel fair or familiar but total output remains low.

symptoms: Potential exchange partners each hold capabilities that would be more valuable if specialized and traded.

symptoms: The system cannot explain why a given actor owns a task except by history, rank, or convenience.

root_tension: Local assignment habits optimize visible ability or ownership, while system-level value depends on relative opportunity cost, exchangeability, and the cost of coordinating specialized outputs.

anti_signatures: Tasks are indivisible or deeply coupled, so splitting them destroys more value than specialization creates.

anti_signatures: All actors have similar opportunity costs or the differences are too small to justify redesign.

anti_signatures: Exchange, trust, verification, or handoff costs exceed the specialization gain.

anti_signatures: The proposed specialization would trap actors in low-mobility roles or create coercive dependency.

anti_signatures: The objective is broad capability development, redundancy, or fairness-by-rotation rather than immediate output efficiency.

structural_intervention: Compare relative opportunity costs across actors and tasks, assign specialization where the relative cost advantage is strongest, create exchange or recombination channels, and monitor dependency, fairness, and changing conditions.

action_logic: Decompose the work into task, function, service, or capability units that can be specialized without losing essential integration.

action_logic: Map actors, capabilities, constraints, and opportunity costs across those units.

action_logic: Identify assignments where one actor gives up less valuable alternative work than others would give up.

action_logic: Create role, exchange, or service arrangements that let specialized outputs reach those who need them.

action_logic: Add coordination protocols so specialized work remains interoperable and accountable.

action_logic: Review dependency, power, fairness, resilience, and learning effects before locking in specialization.

action_logic: Revisit assignments when demand, technology, constraints, or actor capabilities change.

decision_rules: Prefer comparative advantage over absolute advantage when the goal is total joint output or mutual gain.

decision_rules: Do not specialize unless the exchange and coordination channel is reliable enough to capture the gain.

decision_rules: Retain redundancy when resilience, safety, learning, or bargaining power is more important than short-run efficiency.

decision_rules: Reassign work when the opportunity-cost ranking changes materially or when a dependency review shows fragility.

decision_rules: Treat fairness and consent as constraints, not as afterthoughts to be optimized away.

target_invariants: Assignments remain grounded in relative opportunity cost rather than prestige, habit, or absolute skill alone.

target_invariants: Specialized outputs remain exchangeable, interoperable, and useful to the rest of the system.

target_invariants: No actor is trapped in a role without renegotiation, learning opportunity, or exit path.

target_invariants: Dependency risks are visible and proportionate to the efficiency gains.

target_invariants: The system preserves enough slack, redundancy, or reversibility to adapt when conditions change.

expected_outcomes: Higher total output or service quality from the same resource base.

expected_outcomes: Better use of scarce expert time or scarce contextual capability.

expected_outcomes: Clearer roles and fewer duplicated efforts.

expected_outcomes: More mutually beneficial exchange among specialized actors or units.

expected_outcomes: Improved ability to explain why work is assigned where it is.

expected_outcomes: Reduced overload on actors who are absolutely good at many tasks but relatively costly for some of them.

prose_essence:
Comparative Advantage Specialization assigns work by **relative opportunity cost**, not by absolute talent, habit, or ownership. The archetype asks: who gives up the least valuable alternative by doing this task, and can the resulting specialized outputs be exchanged or recombined reliably?

The pattern is useful when multiple actors can perform multiple kinds of work but not all assignments create the same system-level value. Even if one actor is better at everything, that actor should not necessarily do everything. Their time may be more valuable in tasks where others would impose a much higher opportunity cost.

prose_when_to_use:
Use this archetype when work can be divided, actors differ in constraints or relative costs, and exchange or handoff channels can capture the gains from specialization. It fits team design, organizational redesign, supply-chain design, mutual-aid coordination, public-service allocation, classroom projects, and AI-human work allocation.

It is especially useful when high-capability actors are overloaded, many units duplicate the same work, or role assignments persist because of habit rather than a visible assignment logic.

prose_structural_problem:
The structural problem is misassignment under hidden opportunity cost. A system may assign tasks to whoever is absolutely strongest, whoever historically owned the work, whoever has status, or whoever happens to be available. Those assignments can look reasonable locally while wasting system capacity globally.

The danger is that absolute ability hides displacement cost. A senior expert may do a routine task well, but the cost is the expert work they did not do. A less expert actor may complete the routine task adequately while giving up much less valuable alternative work. Comparative advantage makes that hidden comparison explicit.

prose_intervention_logic:
The intervention decomposes work, compares relative opportunity costs, assigns specialization where relative advantage is strongest, and then builds the exchange or coordination machinery needed to make specialization useful.

The logic has five moves. First, identify divisible task units. Second, map actors, capabilities, constraints, and displaced alternatives. Third, assign work to the actor or unit with the lowest relative opportunity cost. Fourth, create exchange channels and coordination protocols so specialized outputs reach the rest of the system. Fifth, monitor dependency, fairness, resilience, and changing conditions.

prose_key_components:
### Opportunity Cost Comparison

This component compares what each actor gives up by doing one task instead of another. It prevents the absolute-advantage fallacy: assigning work to the best performer without asking what more valuable work that performer would otherwise do.

### Role Specialization Rule

The role specialization rule turns analysis into an assignment. It states who specializes in what, why the assignment follows relative opportunity cost, what handoffs are expected, and when the assignment should be revisited.

### Exchange Channel

Specialization only creates system value when specialized outputs can move to those who need them. The exchange channel may be an internal service agreement, workflow handoff, market, partnership, API, shared cadence, or informal swap arrangement.

### Coordination Protocol

Specialized work creates more interfaces. The coordination protocol defines timing, quality expectations, handoff formats, escalation paths, and responsibilities so specialization does not dissolve into integration failure.

### Dependency Review

Specialization can create brittle dependence. The dependency review checks single points of failure, switching costs, bargaining power, backup capacity, and whether efficiency gains justify the dependency being created.

### Capability and Capacity Map

This optional component records who can do what, under which constraints, at what quality and scale. It helps distinguish absolute skill from relative opportunity cost.

### Reversibility Plan

A reversibility plan defines how the system can undo or revise specialization if demand, capability, technology, or participant availability changes.

### Fairness and Power Review

Specialization can become exploitative if actors are trapped in roles or denied growth. This review checks consent, mobility, renegotiation, voice, and fair distribution of gains.

### Transaction Cost Check

The transaction cost check asks whether search, negotiation, handoff, verification, monitoring, or enforcement costs will erase the expected gains from specialization.

prose_common_mechanisms:
A **comparative task assignment matrix** is a template for comparing actors, tasks, opportunity costs, and constraints. It implements the diagnostic part of the archetype but is not the archetype itself.

A **role design workshop** is a facilitated process for redesigning work around relative advantage while surfacing status, morale, and learning concerns.

A **make–buy–partner review** helps decide whether a function should stay internal, be outsourced, or be handled through partnership. It is a mechanism for applying comparative advantage across organizational boundaries.

An **internal service agreement** turns inter-unit specialization into an operating arrangement with service levels, responsibilities, priorities, and escalation paths.

A **supplier or partner specialization contract** coordinates specialized exchange across organizations. It must be paired with dependency review so specialization does not become lock-in.

A **cross-functional work split** divides a project among disciplines according to relative cost and integration needs rather than default ownership.

A **trade or swap arrangement** allows actors to exchange tasks, services, shifts, or capabilities when each side has a different relative advantage.

prose_failure_modes:
The most common failure mode is the **absolute-advantage fallacy**, where the most capable actor gets the work even when their opportunity cost is highest.

Another failure mode is **over-specialization lock-in**, where roles become so narrow that actors and systems lose adaptability.

A third failure mode is **handoff loss**, where specialized outputs fail to integrate because coordination protocols are weak.

A fourth failure mode is **hidden transaction cost**, where negotiation, monitoring, and exchange costs exceed the gains from specialization.

A fifth failure mode is **exploitative specialization**, where comparative advantage language is used to justify trapping less powerful actors in low-status roles.

prose_neighbor_distinctions:
**Transaction Cost Reduction** lowers exchange friction. Comparative Advantage Specialization decides who should specialize in what. The two often work together, but they are not the same pattern.

**Opportunity Cost Surfacing** makes alternatives visible. Comparative Advantage Specialization uses those alternatives to assign work and create exchange.

**Resource Portfolio Balancing** spreads resources across exposures. Comparative Advantage Specialization concentrates work where relative cost is lowest, then manages the dependency that concentration creates.

**Responsibility Partitioning** clarifies ownership boundaries. Comparative Advantage Specialization chooses or revises those boundaries based on relative opportunity cost.

**Scale-Economy Consolidation** reduces per-unit cost by aggregating fixed costs. Comparative Advantage Specialization does not require scale effects; it requires different relative opportunity costs.

**Constrained Resource Allocation** is the broader family of allocating scarce resources under constraints. Comparative Advantage Specialization is specifically about role or task specialization by relative opportunity cost.

prose_cross_domain_examples:
In a software team, a senior engineer may be absolutely good at release administration, but their opportunity cost is high if architecture work waits. A release specialist may own the release process while the senior engineer focuses on architecture and reviews exceptions.

In a nonprofit partnership, one organization may specialize in grant compliance while another specializes in community outreach. The gain appears when they exchange those specialized capabilities through a reliable collaboration agreement.

In healthcare operations, clinicians may focus on clinical judgment while coordinators handle follow-up and scheduling. The specialization works only when escalation rules preserve safety.

In supply chains, a design-heavy firm may partner with a manufacturing specialist. The arrangement fits this archetype when the basis is relative opportunity cost plus dependency safeguards, not simply cheaper labor.

In AI-human work allocation, automated systems may handle repetitive drafting or summarization while humans retain ambiguous judgment, escalation, and accountability roles. The assignment should be revisited as automation capability and oversight cost change.

prose_non_examples:
Assigning all important work to the most talented person is not this archetype; it ignores opportunity cost.

Creating a shared service center solely to reduce duplicated fixed costs is scale-economy consolidation, not necessarily comparative advantage specialization.

Rotating everyone through every role for training is a learning and resilience strategy, not specialization by lowest opportunity cost.

Outsourcing to the cheapest provider without evaluating exchange reliability, dependency, and displaced alternatives is not a safe use of this archetype.

prose_tradeoffs:
The central tradeoff is efficiency versus resilience. Specialization can increase output while reducing fallback capacity. Another tradeoff is expert focus versus learning breadth: narrow specialization may improve performance while limiting development. A third tradeoff is role clarity versus coordination overhead: specialized work needs better interfaces.

The ethical tradeoff is mutual gain versus unequal capture. Specialization can help everyone, but only if exchange is fair and actors retain meaningful mobility and renegotiation power.

prose_invariants_to_preserve: The assignment criterion must remain relative opportunity cost, not status, habit, absolute skill, or narrow price. Specialized outputs must remain exchangeable and interoperable. Dependency risk must remain visible. Participants must not be trapped in roles without voice or exit. The system must preserve enough reversibility to respond when relative advantage changes.

prose_target_outcomes: The desired outcomes are higher total output, better use of scarce capability, less duplication, clearer roles, more mutually beneficial exchange, and fewer bottlenecks caused by assigning too much work to actors who are absolutely capable but relatively costly.

prose_parameter_dimensions:
Important tuning dimensions include task granularity, specialization depth, exchange-formality, review cadence, redundancy level, allowed dependency, bargaining safeguards, and learning-versus-output priority.

The archetype can be tuned for short-run efficiency by deepening specialization and lowering redundancy. It can be tuned for resilience by preserving backup capacity, cross-training, and reversibility. It can be tuned for fairness by adding voice, role rotation, gain-sharing, and renegotiation mechanisms.

prose_variants_and_near_names:
**Task-Level Specialization** applies the pattern inside a team or small group.

**Inter-Unit Specialization** applies it across departments, sites, agencies, or business units.

**Trade-Based Specialization** applies it across parties who specialize and exchange outputs.

**Dynamic Comparative-Advantage Rebalancing** revisits assignments as capabilities, technology, demand, and constraints change.

Near names include specialization by comparative advantage, lowest-opportunity-cost assignment, division-of-labor design, comparative task assignment, trade allocation, and outsourcing decision. Not all division of labor is this archetype: the assignment must be based on relative opportunity cost and supported by exchange or recombination.

Task-Level Specialization

variant_type: subtype

short_definition: Assigns individual tasks inside a team to the actors with the lowest relative opportunity cost for each task.

distinctive_feature: The unit of specialization is a task or role slice inside a local group.

distinct_from_parent: It is a small-scale team variant of the parent rather than a cross-organization or trade-system variant.

still_same_parent_because: It still uses the same causal logic: compare relative opportunity cost, specialize, exchange or recombine outputs, and monitor dependency.

use_when: A group performs multiple recurring tasks and members have different skill profiles, availability, or learning priorities.

use_when: Current work allocation follows habit, seniority, or absolute skill rather than relative opportunity cost.

use_when: The team can coordinate handoffs without overwhelming overhead.

Comparative Task Assignment Matrix

mechanism_type: template

example_domains:
teams
education
operations
volunteer coordination

domain: team operations

example: Assigning triage, documentation, and escalation to different team members based on relative cost rather than identical rotation.

domain: classroom collaboration

example: Dividing research, writing, design, and presentation tasks by relative opportunity cost while ensuring everyone can still learn.

failure_modes: Status lock-in, skill stagnation, overloaded specialists, handoff friction.

Inter-Unit Specialization

short_definition: Specializes functions across departments, sites, teams, or agencies that exchange services through internal coordination channels.

distinctive_feature: The specialization boundary is organizational rather than individual.

distinct_from_parent: It highlights governance, service-level agreements, and internal dependency risks that matter when whole units specialize.

still_same_parent_because: The allocation criterion remains comparative advantage rather than centralization for scale alone.

use_when: Multiple units duplicate work or compete for the same capabilities.

use_when: Some units can perform a function at lower relative opportunity cost than others.

use_when: Internal exchange or shared-service arrangements can preserve responsiveness.

example_domains:
organizations
public administration
health systems
shared services

domain: organization design

example: Letting one unit specialize in regulatory review while another specializes in field delivery, with explicit service agreements.

failure_modes: Internal monopoly, service bottlenecks, loss of local context, cost-shifting.

Trade-Based Specialization

short_definition: Uses specialization plus exchange between parties to create gains that neither party would reach in isolation.

distinctive_feature: The archetype is expressed through exchange between parties rather than internal task assignment.

distinct_from_parent: It emphasizes the exchange side of specialization and is therefore close to gains_from_trade_facilitation.

still_same_parent_because: The reason trade helps is that each side specializes where its opportunity cost is lower, then exchanges.

use_when: Parties have different relative opportunity costs across goods, services, or capabilities.

use_when: Exchange channels, trust, and terms can be created or already exist.

use_when: The parties can negotiate without coercive dependency or one-sided extraction.

Trade or Swap Arrangement

mechanism_type: protocol

name: Supplier or Partner Specialization Contract

example_domains:
supply chains
mutual aid
international trade
professional services

domain: mutual aid

example: One group handles logistics while another handles outreach because each gives up less by doing its specialized role.

domain: supply chain

example: A firm specializes in design while a partner specializes in production, with dependency safeguards.

failure_modes: Exploitation, lock-in, over-specialization, hidden transaction costs, unequal capture of gains.

short_definition: Periodically revisits specialization assignments as capabilities, demand, technology, or constraints change.

distinctive_feature: It treats specialization as a revisable state rather than a one-time design choice.

distinct_from_parent: The parent can be static; this variant makes review cadence and migration costs central.

still_same_parent_because: It still optimizes by relative opportunity cost and recombination of specialized outputs.

use_when: Relative opportunity costs change over time.

use_when: Specialization assignments have become stale or politically entrenched.

use_when: The cost of reassigning work is lower than the cost of maintaining misfit specialization.

example_domains:
career design
operations
AI-human work allocation
public services

domain: AI operations

example: Revisiting which tasks humans and automated tools should handle as model capability and oversight costs change.

failure_modes: Change fatigue, unstable ownership, hidden retraining costs, short-termism in reassignment.

near_names:
Specialization by Comparative Advantage
Lowest-Opportunity-Cost Assignment
Division-of-Labor Design
Comparative Task Assignment
Trade Allocation
Outsourcing Decision