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.

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

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

• Common-Mode Dependency Audit
• Concentration Cap Policy
• Dependency Concentration Heatmap
• Dependency Concentration Stress Test
• Effective Independent Provider Count
• Multi-Sourcing Rule
• Portability Checklist
• Provider Load Split Table
• Residual Concentration Risk Register
• Substitution Drill
• Top-K Exposure Share
• Weighted Dependency Graph

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.