Common-Mode Dependency Audit¶
Audit — instantiates Dependency Concentration Control
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."
A redundancy count is only as real as the independence behind it. Common-Mode Dependency Audit takes the dependencies a system treats as interchangeable alternatives and traces each one upstream, hunting for the shared root that would take several of them down together — a common cloud region, a single fourth-tier subcontractor, one certificate authority, a reused credential, or a common trigger such as a sanctions regime that hits an entire country at once. Its defining move is tracing provenance rather than counting names: it assumes two providers are correlated until a shared-root search comes back empty, not the other way around. The output is a profile of the hidden correlations inside a plural-looking dependency set — the gap between listed redundancy and effective redundancy.
Example¶
A payments company believes its one-time-passcode delivery is well defended: it contracts with three separate SMS providers and fails over between them automatically. A Common-Mode Dependency Audit walks each of the three back through its delivery chain and finds that all three resell capacity from the same upstream messaging aggregator in one region. On paper there are three vendors; in the wire there is one. The audit also checks a second axis — authentication — and finds two of the three route through a shared telecom identity gateway.
The deliverable is a short profile: "Three named OTP providers, one effective provider; a single aggregator outage silences all passcodes; independence evidence = contractual only, not technical." That sentence reframes the roadmap from "we already have failover" to "our failover targets a sibling of the thing that just failed." It is an instance of a common-cause failure, where redundant components share a single defeating root.[n1]
How it works¶
- Trace each alternative to ground. For every nominal substitute, follow the chain up through ownership, infrastructure, region, credential, and regulatory trigger until you reach an independent origin or hit a shared one.
- Mark the convergences. Wherever two or more "alternatives" meet at a common node, record the node, how many dependents it silently carries, and the failure it would propagate.
- Grade the independence evidence. Distinguish asserted independence (a vendor's word) from demonstrated independence (contracts, network paths, or a technical probe), because the audit's whole value is refusing to take redundancy on faith.
Its distinguishing trait is that it can flag a correlation nobody had ever named — a shared foundry, a common DNS root — precisely because it works upstream from the alternatives rather than reasoning from the vendor list.
Tuning parameters¶
- Trace depth — how many upstream tiers you follow before stopping. Deeper tracing catches buried shared roots (the tier-4 foundry) but costs investigation time and often runs into vendors who cannot see their own upstreams.
- Dimension set — which axes you check for convergence: ownership, physical region, infrastructure, credential/identity, regulatory jurisdiction. Adding axes finds more common modes but dilutes effort across each.
- Evidence standard — self-attestation, contract inspection, or live technical probe. A stricter standard turns "believed independent" into "shown independent," at rising cost and vendor friction.
- Refresh trigger — re-run on schedule, or on any provider change, subcontractor swap, or migration. Common modes appear between audits when a vendor quietly re-hosts.
When it helps, and when it misleads¶
Its strength is converting nominal redundancy into effective redundancy: it catches the correlated failure that a headcount of providers is structurally blind to, and it does so before an outage proves the point. It is the input that tells the rest of the archetype whether "we have alternatives" is true.
Its central failure mode is that an audit is only as deep as its trace — a shared dependency one tier below where you stopped looking survives the audit and still takes everything down, so a clean result can manufacture false confidence. Providers also misrepresent their own upstreams, sometimes because they genuinely don't know them. The classic misuse is the shallow self-attestation pass run to certify an independence the organization has already assumed — an audit staged to bless the vendor list rather than to test it. The discipline that guards against this is to demand demonstrated (not asserted) evidence for any independence the system actually relies on, and to re-run the trace whenever a provider's supply chain moves.
How it implements the components¶
Common-Mode Dependency Audit fills the detection side of the archetype — it finds hidden correlation, it does not size or fix it:
common_mode_dependency_profile— its primary output: the map of shared upstream roots and the dependents each one silently carries.independence_evidence_check— it grades every claimed independence as asserted or demonstrated, refusing to count redundancy the evidence can't support.
It does not quantify how concentrated the exposure is (that's Effective Independent Provider Count and Top-K Exposure Share), set a ceiling on it (Concentration Cap Policy), or remediate it (Multi-Sourcing Rule); the audit only reveals the correlation those mechanisms then measure and act on.
Related¶
- Instantiates: Dependency Concentration Control — the audit supplies the common-mode profile the rest of the appraisal treats as ground truth.
- Sibling mechanisms: Effective Independent Provider Count · Dependency Concentration Stress Test · Dependency Concentration Heatmap · Concentration Cap Policy · Multi-Sourcing Rule · Substitution Drill · Weighted Dependency Graph
Editorial Notes¶
Form Classification¶
Form family: Assessment, Review & Assurance
Rationale: 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.", making its operative form a bounded evaluation of existing evidence or work that produces a finding or disposition.
Independent corroboration: The frozen evidence defines Common-Mode Dependency Audit as '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.'', so its operative form is Assessment, Review & Assurance.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Nuclear-safety and reliability engineering cohered common-mode analysis that traces redundant channels to shared defeating roots.
Related originating lineages:
- Logistics & Supply Chain Management — Multi-tier supplier mapping applies the same method to correlated vendors, regions, and upstream sources.
Review resolution: Both reviewers agree on engineering_design as primary. Reading the source mechanism confirms that its defining operation belongs to that lineage; the final record retains logistics_supply_chain only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The profile is a snapshot with a short shelf life: a provider can re-host, change a subcontractor, or migrate regions without telling anyone, silently creating a common mode between two audits. Treat a clean audit as valid until the next supply-chain change, not indefinitely — it pairs naturally with a drift monitor that flags when a re-audit is due.
[n1] A common-cause failure is the simultaneous failure of components that were counted as redundant because they share a single defeating root (a power feed, a cooling loop, a software version). The concept comes from reliability and nuclear-safety engineering, where defending against it is the reason redundancy is required to be diverse, not merely duplicated — exactly the distinction this audit enforces. ↩