Common-Cause Dependency Audit¶

Audit — instantiates Conjunctive Path Assurance

Challenges the independence the redundancy math assumes by hunting the shared upstream driver that would fail several "separate" barriers in the same instant.

Every assurance argument for a conjunctive hazard rests on a quiet premise: that the barriers guarding a route fail independently, so the chance of all of them conducting at once is the product of several tiny numbers. Common-Cause Dependency Audit attacks that premise directly. It is a structured review that takes each set of supposedly-independent safeguards on a path and asks what single upstream factor — one power feed, a shared calibration constant, one vendor's firmware, the same maintenance crew, a single design assumption — could disable several of them at the same moment. Where the other mechanisms map or test the route, this one interrogates the independence the route's safety math silently assumes, because one common cause collapses a product of small probabilities into a single one.

Example¶

A payments platform runs across three cloud availability zones "for independence." The audit ignores the routing diagram and walks the shared-driver list instead. All three zones pull deploy configuration from one control plane — a single bad config push could take them offline in the same minute. Two of the three sit behind one physical power substation. All three resolve through a single DNS provider. Each finding is tagged as a common driver, scored by how many "independent" barriers it collapses, and handed a separation remedy: stagger the config rollout with a bake-time gate between zones, add a second DNS provider, verify the power feeds are genuinely separate. The headline was three-way redundancy; against a configuration fault the audit shows it was closer to ≈1.5-way.

How it works¶

It does not build the causal graph or exercise combinations. It starts from the set of barriers the assurance argument treats as separate and traces each one backwards to what it depends on — power, data, tooling, people, environment, calendar, design assumptions — looking for any node that turns up under more than one barrier. Every shared node is a candidate common cause. Each is classified by coupling type (shared resource, shared trigger, shared design flaw, shared human, shared environment) and, where the math needs it, assigned a dependence factor. Standard taxonomies drive the hunt so the search is systematic rather than a matter of who remembers what.

Tuning parameters¶

Coupling-taxonomy breadth — how many categories of shared driver you scan (only power and signal, or also human, procedural, calibration, cyber, environmental, calendar). Broader catches subtler couplings but costs review time.
Dependence quantification — whether a finding is a qualitative flag or a numeric coupling factor. Numbers feed the reliability calculation but invite false precision over a coupling nobody has measured.
Barrier-set scope — which redundancies you audit: only the formally credited safety barriers, or every independence claimed anywhere in the design. Wider scope, more findings, more effort.
Evidence depth — taking each independence claim on trust versus verifying it physically (tracing the actual cable, reading the actual config). Verification is the expensive part and where the real surprises hide.

When it helps, and when it misleads¶

Its strength is that it catches the one failure the redundancy arithmetic is blind to: adding a fourth "independent" barrier buys nothing if all four share a driver. Its failure mode is that couplings hide in shared infrastructure nobody drew on the diagram, and a fresh common cause can be created after the audit — a later consolidation onto a single vendor quietly re-couples barriers that were once separate. The classic misuse is running it backwards: asserting independence to protect a headline reliability figure rather than testing it. The discipline that guards against this is to verify independence physically, treat any unverified independence claim as a dependence until proven otherwise, and re-audit on every consolidation.^[1]

How it implements the components¶

common_driver_and_independence_check — its core loop: enumerate shared upstream drivers and put each claimed independence to the test.
probabilistic_dependence_profile — it converts a qualitative coupling into a dependence factor that corrects the naive product-of-probabilities.
diversity_and_separation_plan — its output is the diversification and separation that restores genuine independence.

It maps no routes and builds no graph: the state_conditional_causal_graph and its minimal_activating_conjunction_set belong to Attack Graph Analysis and Fault Tree with AND-Gate Logic, and the path_break_or_interlock_requirement — the physical guard — belongs to Independent Interlock or Guard.

Instantiates: Conjunctive Path Assurance — it defends the independence assumption the whole assurance argument stands on.
Sibling mechanisms: Fault Tree with AND-Gate Logic · Minimal Cut-Set Enumeration · Independent Interlock or Guard · Scenario or Monte Carlo Joint-State Sampling · Runtime Gate Co-Activation Monitor

Notes¶

An independence finding has a shelf life. The audit certifies independence as of a given architecture; the next consolidation, shared-service migration, or vendor merger can silently re-introduce a common driver. Treat independence as a property to be maintained and re-checked on change, not a fact established once.

References¶

[1] Common-cause failure is the standard reliability-engineering name for multiple redundant elements failing from a single shared cause; the beta-factor model is the usual way to fold a fraction of otherwise-independent failures back in as common-cause. Both are why a bare product-of-probabilities overstates the reliability of redundant barriers. ↩