Dependency Concentration Control

Prevent dependency fragility by measuring where reliance is concentrated and capping, diversifying, or isolating overweight dependency providers before their failure can dominate the system.

Version

v1 · 2026-08-24 · History

Solution archetype #

324

Problem family

Fragility, Failure & Continuity Risk

Problem subfamily

Dependency Concentration & Common-Mode Loss

Essence

Prevent dependency fragility by measuring where reliance is concentrated and capping, diversifying, or isolating overweight dependency providers before their failure can dominate the system.

Dependency Concentration Control is for situations where the dependency map is not enough. A system may list many dependencies, providers, suppliers, platforms, teams, routes, regions, or channels, yet most effective reliance can still be carried by one provider or by a correlated cluster. The archetype converts dependency visibility into concentration governance: it assigns weights, measures concentration, tests independence, sets limits, and rebalances exposure before a dominant dependency becomes the hidden failure path.

Compression statement

Dependency Concentration Control applies when a system has multiple apparent dependencies but most effective reliance, switching difficulty, recovery time, criticality, or control leverage is concentrated in a small number of providers, channels, platforms, regions, teams, standards, or support paths. The intervention converts a dependency map into a weighted exposure portfolio, measures concentration and common-mode correlation, sets concentration limits, verifies independence among substitutes, and rebalances demand, contracts, capacity, interfaces, or contingency paths so no small dependency subset can dominate system viability.

Canonical formula: dependency_fragility = concentration_index(weighted_dependency_exposure × criticality × switching_time × common_mode_correlation) - independent_substitution_capacity - concentration_controls

When This Archetype Applies

Complete catalog groundingAt least one sufficient condition set is fully represented by existing primes or domain-specific abstractions.

Diagnostic problem

A dependent system's apparently plural provider set is fragile because effective weight is concentrated on a few providers, shared upstream modes, or nominal substitutes that cannot carry the required load.

What this problem means

A system depends on external or internal providers, channels, teams, platforms, resources, regions, standards, or support paths. The dependency set appears plural, but effective reliance is unevenly distributed: one provider carries most demand, a small cluster shares a common upstream bottleneck, or nominal alternatives are correlated through the same infrastructure. Because the concentration is a structural property of the dependency distribution, internal defenses cannot fully compensate for an overweight provider or common-mode cluster.

Applicability expression4 distinct conditions

Multiple dependency optionsandany oneConcentrated dependency loadorShared upstream dependenciesorNominal substitutes lack capacity

Algebraic1∧(A∨B∨C)

groundedpartly groundedopen

Equivalent to the 3 condition sets it replaces, with 2 duplicate condition cards removed.

1Required in every casenumbered 1–1

These hold no matter which pattern applies.

1

Multiple dependency options · grounded

The system relies on multiple providers, channels, platforms, regions, teams, resources, or support paths. more

primeDependency Distribution Concentration— How a system's dependency weight is distributed across providers — concentrated or spread — is a structural property that bounds its fragility independent of its own defenses.

and also

3At least one of theselettered A–C

Any single one of these completes the pattern.

A

Concentrated dependency load · grounded

A small subset of providers carries most demand, authority, information, legitimacy, capacity, or recovery leverage. more

domainSupplier Concentration Risk— Exposure that arises when a buyer's dependency for a critical input rests on so few suppliers that one node's disruption propagates downstream faster than alternatives can be qualified — a shape property of the dependency distribution, not of any supplier's performance.

How this was matched — 3 shared + 6 branches

A small provider subset carries most of one listed dependency weight.

All of

• roleProviders form the population being compared.
• quantifierThe focal provider subset is small relative to the provider population.
• comparisonThe small subset carries most of the selected dependency weight.

…and any one of

• domainDemand is the concentrated dependency weight.
• domainAuthority is the concentrated dependency weight.
• domainInformation is the concentrated dependency weight.
• domainLegitimacy is the concentrated dependency weight.
• domainCapacity is the concentrated dependency weight.
• domainRecovery leverage is the concentrated dependency weight.

or — any one satisfies this slot

B

Shared upstream dependencies · grounded

Nominally separate providers share upstream infrastructure, ownership, geography, standards, labor, funding, credentials, or failure modes. more

domainDeposit Concentration Risk— Judge a bank's funding fragility by the correlation-adjusted effective depositor count rather than the headline number — coupled depositors collapse toward one bet, voiding the law-of-large-numbers smoothing a large base seems to guarantee.

AND both parts required

context guardthe correlation-generating cause is a shared geographic exposure

suppliesThe providers share an upstream dependency or failure locus. · Geography is shared.

How this was matched — 3 shared + 8 branches

Nominally separate providers share at least one listed upstream dependency or failure mode.

All of

• quantifierMore than one provider is present.
• comparisonThe providers are nominally separate.
• relationThe providers share an upstream dependency or failure locus.

…and any one of 8 alternative branches

Too many branches to lay out readably. The full expression is in the trigger-logic download.

or — any one satisfies this slot

C

Nominal substitutes lack capacity · open

Nominal substitution paths cannot absorb the load, quality requirement, or timing need of the concentrated provider. more

Other requirements and context (3)

Why these sit outside the expression

Supporting context — it may accompany or help interpret the situation, but it is not a load-bearing condition in a sufficient diagnostic set.

• Supporting contextDependency lists exist, but their relative weights, criticality, switching difficulty, or recovery times are not measured together. more

• Supporting contextDecision makers treat the count of alternatives as equivalent to actual independent distribution.

• Supporting contextThe system’s own defenses assume that provider failure is local rather than distribution-dominating. more

Coverage

3 of 4 conditions grounded · 1 open.

None of the 1 open conditions sit in the shared core — each falls inside one alternative branch, so grounding any one of them closes only that branch.

Read the methodology · Download the trigger-logic data

Why this is distinct

The draft is intentionally narrower than generic dependency visibility and broader than supplier diversification. dependency_exposure asks, “What do we depend on?” This archetype asks, “How much of the system’s viability is weighted onto each dependency provider or cluster, and what must change if that distribution is too concentrated?” It also differs from risk-pooling correlation analysis because it governs reliance on providers and support paths, not only whether pooled risks diversify statistically.

Key components

Component	Description
Weighted Dependency Inventory ↗	A list of providers is not a concentration model. Each dependency needs weights for demand share, mission criticality, control leverage, data or authority custody, recovery importance, and switching time. The weights reveal low-volume dependencies that are still structurally dominant because they are hard to replace or central to recovery.
Concentration Measure ↗	The archetype needs a simple and repeatable way to describe concentration: maximum share, top-k share, effective independent provider count, or another domain-appropriate concentration index. The point is not mathematical elegance; the point is to create a signal that can trigger governance action.
Common-Mode Dependency Profile ↗	Alternatives only reduce concentration when they are genuinely independent. Two suppliers, services, or agencies may share the same upstream manufacturer, cloud region, payment rail, credential system, labor pool, or regulatory exposure. The common-mode profile prevents false diversification claims.
Substitution Feasibility Map ↗	A substitute must be able to absorb load, preserve quality, and switch within the required time. A backup that exists only on paper does not materially reduce dependency concentration.
Concentration Limit Band ↗	A concentration band defines when exposure is normal, when it needs review, when it requires rebalancing, and when it needs explicit residual-risk acceptance. Bands are especially useful when measurement is uncertain and switching takes time.

Common mechanisms

Useful mechanisms include dependency concentration heatmaps, weighted dependency graphs, top-k exposure-share metrics, effective independent provider counts, common-mode audits, concentration-cap policies, multi-sourcing rules, provider load-split tables, substitution drills, portability checklists, concentration stress tests, and residual concentration risk registers.

These mechanisms should not be mistaken for the archetype. The archetype is the complete control loop: weight dependencies, measure concentration, test independence, set limits, rebalance exposure, and monitor drift.

Parameter dimensions

Important parameters include exposure weight, provider criticality, time to substitute, maximum acceptable top-one and top-k share, effective independent provider count, common-mode correlation, load absorption capacity, switching cost, quality loss during substitution, concentration-review cadence, and residual-risk acceptance duration.

Invariants to preserve

The system should preserve usable independence rather than nominal provider count. It should ensure critical dependencies do not exceed concentration limits accidentally. It should distinguish efficiency-driven concentration from risk-accepted concentration. It should maintain tested substitution paths and make concentration drift visible before incidents reveal it.

Tradeoffs

Reducing concentration can increase cost, integration effort, quality variation, contract complexity, and coordination overhead. A good design does not maximize provider count. It finds a distribution that lowers dominant-dependency fragility without creating a more complex and fragile provider portfolio.

Failure modes

The most common failure is false diversification: counting multiple names as independent when they share upstream failure modes. Another is paper substitution, where alternate providers exist contractually but cannot carry realistic load. Over-diversification is also a failure: adding so many providers that monitoring and coordination costs outweigh resilience gains.

Neighbor distinctions

• Dependency Exposure reveals and classifies dependencies; this archetype governs their weighted distribution.
• Correlation Structure Analysis for Pooling Effectiveness checks diversification in pooled risks; this archetype controls provider and dependency reliance.
• Diverse Functional Redundancy creates alternative ways to perform a function; this archetype tests whether alternatives actually reduce weighted concentration.
• Redundant Backup Provisioning adds backup capacity; this archetype manages portfolio concentration and common-mode independence.
• Sustainable Load Envelope Governance limits total load against carrying capacity; this archetype limits dependency-weight concentration across providers or paths.

Examples

A software platform may discover that its regions, monitoring, and recovery tooling all rely on one identity service. A manufacturer may discover that several named suppliers all depend on one upstream fabricator. A public program may discover that all eligibility verification flows through one vendor. In each case, the failure is not simply a missing backup; it is an overweight dependency distribution.

Non-examples

A dependency inventory without weights is not this archetype. A backup supplier contract without load tests is not this archetype. A risk pool correlation analysis is adjacent but different. A deliberately concentrated low-criticality dependency may be acceptable when residual risk is recorded and switching remains easy.

Common Mechanisms

12 documented mechanisms across 8 implementation forms.

The grouping reflects forms represented among the mechanisms currently documented for this archetype; an absent form is not necessarily an impossible implementation.

Analysis, Modeling & Optimization · 1 mechanism

• Effective Independent Provider Count — Collapses a weighted, correlation-adjusted dependency portfolio into a single honest number — how many genuinely independent providers you effectively have, which is usually far fewer than you can name.

Assessment, Review & Assurance · 2 mechanisms

• Common-Mode Dependency Audit — Traces whether a system's nominally independent alternatives actually converge on the same upstream provider, region, credential, owner, or trigger — turning "we have three suppliers" into "we have one shared failure point wearing three names."
• Portability Checklist — A standing list of the concrete things — data, contracts, interfaces, credentials, skills, runbooks — that must be movable before an alternative provider counts as real rather than nominal.

Experiment, Test & Rehearsal · 2 mechanisms

• Dependency Concentration Stress Test — Simulates the sudden loss, withdrawal, or price shock of the dominant provider or cluster and traces the blast radius — checking whether the substitutes and reserves that look adequate on paper actually absorb it.
• Substitution Drill — A rehearsed, live cutover from an overweight provider to its alternatives under realistic load and timing, proving a diversification that looks good on paper actually holds when exercised.

Interface, Display & Cue · 1 mechanism

• Dependency Concentration Heatmap — Lays weighted dependency exposure onto a coloured grid — provider against function, geography, platform, and criticality band — so the overweight cells announce themselves at a glance.

Monitoring, Sensing & Alerting · 1 mechanism

• Top-K Exposure Share — Reduces the whole dependency distribution to one governable number — the share of critical exposure carried by the largest one, three, or five providers — and watches it drift over time.

Record, Log & Register · 1 mechanism

• Residual Concentration Risk Register — The signed record of every concentration the organization has knowingly chosen to keep — who owns it, why it is tolerated, what compensates for it, and when it must be re-justified.

Representation, Specification & Plan · 2 mechanisms

• Provider Load Split Table — The concrete allocation sheet that names what share of demand each provider is meant to carry, turning a diversification target into intended percentages and tiers.
• Weighted Dependency Graph — Represents every dependency as a weighted, directed edge so that overweight providers and shared upstreams stop hiding behind a long, flat list of names.

Rule, Policy & Commitment · 2 mechanisms

• Concentration Cap Policy — Sets explicit ceilings on how much of a critical function any single provider or common-mode cluster may carry, and defines the sign-off required to run above them.
• Multi-Sourcing Rule — Requires a dependency class to keep two or more genuinely qualified, switchable providers once its concentration risk crosses a threshold — a floor on independence, not a ceiling on share.

Related Abstractions

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (1)

• Dependency Distribution Concentration: How a system's dependency weight is distributed across providers — concentrated or spread — is a structural property that bounds its fragility independent of its own defenses.

Also references 22 related abstractions

• Boundedness: Values remain within limits.
• Carrying Capacity: The sustainable load envelope of a system: the maximum demand it can carry indefinitely before sustained operation begins consuming its own substrate and lowering future capacity.
• Correlated Capacity Demand: When demands on a shared finite resource are tail-correlated rather than independent, capacity sized for independent peaks fails at the rare joint exceedance.
• Coupling: Interdependence among subsystems.
• Defense In Depth: Stacking multiple independent protective layers between threat and asset so that only a correlated breach across all layers produces total loss.
• Dependency: Directed relation in which one element relies on another being present, prior, compatible, or supplied, with a specifiable failure mode if the condition is unmet.
• Diversification: Spreading exposures across positions whose failure modes are uncorrelated reduces total-outcome variance; correlation, not count, drives the benefit.
• Failure Mode and Effects Analysis (FMEA): Identify failure modes.
• Fault Tolerance: Continue operating under failure.
• Margin of Safety: Buffer capacity.

▸ Show 12 more

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Single-Provider Concentration Variant · risk or failure variant · recognized

A variant where one provider, platform, team, route, or standard carries enough dependency weight to dominate system failure risk.

• Distinct from parent: The parent covers any concentrated distribution; this variant covers the one-provider extreme.
• Use when: One provider carries most critical load or switching leverage; Failure of that provider would disable multiple functions at once.
• Typical domains: software reliability, supply chain, public policy
• Common mechanisms: top k exposure share, substitution drill, concentration cap policy

Common-Mode Provider Cluster Variant · risk or failure variant · recognized

A variant where apparent alternatives share upstream failure modes, making the effective dependency concentration higher than provider count suggests.

• Distinct from parent: The parent covers weighted concentration generally; this variant emphasizes common-mode correlation among alternatives.
• Use when: Providers share geography, infrastructure, ownership, standards, credentials, labor pools, or control planes; A common shock would affect several dependencies at once.
• Typical domains: cloud computing, supply chain, finance risk
• Common mechanisms: common mode dependency audit, effective independent provider count

Platform Dependency Concentration Variant · domain variant · recognized

A variant where a digital, institutional, or market platform becomes the dominant dependency channel for many functions.

• Distinct from parent: The parent can apply to any provider; this variant emphasizes platform control and switching friction.
• Use when: Many workflows route through one platform, standard, market channel, or identity/control layer; The platform can change access, rules, pricing, or availability faster than the dependent system can adapt.
• Typical domains: software reliability, platform governance, media distribution
• Common mechanisms: portability checklist, dependency concentration stress test

Near names: Dependency Portfolio Concentration, Provider Concentration Risk, Supplier Concentration Risk Control, Third-Party Concentration Governance.

Editorial Notes

Problem Classification

Classification: Fragility, Failure & Continuity Risk → Dependency Concentration & Common-Mode Loss

Problem kernel: plural providers conceal concentrated effective reliance

Rationale: One provider or shared upstream cause carries most critical demand, so nominal alternatives do not protect continuity.

Independent corroboration: The earliest necessary condition in the frozen evidence is: A system depends on external or internal providers, channels, teams, platforms, resources, regions, standards, or support paths. That is a dependency concentration and common mode loss problem because Nominally plural providers, paths, backups, or pooled exposures share enough concentration or correlation that one cause can remove them together.

Review outcome: Independent reviewer agreement; high confidence.