Common-Mode Failure Probe¶
Diagnostic probe — instantiates Layered Barrier Defense Architecture
Deliberately fails a shared dependency to see how many "independent" layers drop together — testing the independence the whole defense is betting on.
Layered defense multiplies safety only if the layers fail independently. Five barriers that all die when the same power feed, vendor, credential, or assumption goes down are not five barriers but one wearing five hats. Common-Mode Failure Probe goes hunting for exactly that hidden coupling: it picks a dependency several layers quietly share and pulls it — cuts the feed, revokes the credential, fails the vendor — then watches how many supposedly separate layers fall at once. Its defining move is adversarial and subtractive: rather than confirming each layer works in isolation, it attacks what they hold in common, because that shared root is where a multi-layer defense actually dies. It exists to turn the comfortable claim "we have defense in depth" into a tested statement about how correlated those depths really are.
Example¶
An airline's engineers are confident in a flight-critical system's triple redundancy — three independent channels, any one sufficient. A common-mode probe asks the uncomfortable question: what do all three actually share? Tracing it back, the team finds every channel draws from the same sensor bus and runs the same software build. In a bench test they inject a single malformed reading on that shared bus; all three "independent" channels reject it identically and trip together. No incident occurred — but the redundancy that looked three-to-one was, against that one input, one-to-one. The finding reroutes one channel to a diverse sensor source and diversifies its software, converting a paper redundancy into a real one. The probe's value was never a number; it was disproving an independence everyone had quietly assumed.[n1]
How it works¶
- Hunt the shared root, not the layer. The probe inventories what layers have in common — power, network, vendor, credential, clock, software build, staff, assumption — and treats each commonality as a candidate single point of failure.
- Pull one thing, watch many. It removes or corrupts a single shared dependency and observes how many layers degrade together; the count is the finding.
- Prefer the test to the argument. Where a design review would argue independence, the probe demonstrates dependence — it is believed only when a layer actually drops.
- Feed the fix, not a score. Each discovered coupling becomes a concrete remedy: diversify the dependency, add a genuinely different layer, or record the correlation honestly.
Tuning parameters¶
- Injection realism — from a paper "what if this fails" to actually severing the dependency in a live-like environment. Realism buys proof but risks real disruption.
- Breadth of shared roots probed — how many kinds of commonality (physical, logical, human, temporal) you hunt; a wider net catches more coupling but costs more to run.
- Blast-radius control — how tightly the induced failure is contained; loose control makes the probe itself a hazard, while too-tight control can mask the very cascade you meant to see.
- Tracing depth — how far up the dependency chain you follow shared roots; deeper tracing finds subtler coupling (a shared upstream vendor) at rising effort.
When it helps, and when it misleads¶
Its strength is that it attacks the single most flattering illusion in layered design — that independent-looking layers are independent — and does so by demonstration, which is far harder to argue away than a review comment.
Its failure mode is that you can only probe the couplings you think to look for; an unimagined shared dependency survives the probe and stays dangerous, so a clean result means "no coupling found," never "layers proven independent." The classic misuse is running it once, fixing the couplings it surfaced, and declaring independence verified — freezing a snapshot into a guarantee. The discipline that guards against this is to treat independence as disproven-until-tested and never fully provable, to keep widening the set of shared roots examined, and to re-probe whenever the system or its vendors change.
How it implements the components¶
Common-Mode Failure Probe fills the independence-testing slot — the adversarial check that the layers' separateness is real:
common_mode_dependency_map— its central output: the discovered map of dependencies shared across layers, the coupling no single-layer test can see.independence_assumption_register— it tests each "these layers fail independently" assumption and marks the ones that turn out false.red_team_probe— it is the archetype's adversarial probe, aimed specifically at shared dependencies rather than at the front door.
It surfaces correlated exposure but does not tally the leftover risk into a standing ledger — that is Compensating Control Register — nor prove the recovery layer (Backup Restore Drill). Note that Multi-Factor Access Challenge and Safety Interlock Chain also carry the independence assumption as a design premise; the probe is the one that actively puts it to the test.
Related¶
- Instantiates: Layered Barrier Defense Architecture — it validates the independence assumption the whole "in depth" idea rests on.
- Consumes: Layered Control Matrix — the catalogue of layers and pathways is where the probe looks for the dependencies they secretly share.
- Sibling mechanisms: Compensating Control Register · Tabletop Breach Walkthrough · Backup Restore Drill · Canary or Tripwire Asset · Intrusion or Anomaly Alerting · Layer Health Dashboard · Layered Control Matrix · Multi-Factor Access Challenge · Network Segmentation Policy · Physical Security Zoning · Safety Interlock Chain
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Deliberately fails a shared dependency to see how many 'independent' layers drop together — testing the independence the whole defense is betting on, making its operative form a bounded trial, probe, simulation, or adversarial exercise that generates evidence from performance.
Independent corroboration: The frozen evidence defines Common-Mode Failure Probe as 'Deliberately fails a shared dependency to see how many 'independent' layers drop together — testing the independence the whole defense is betting on', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Reliability testing made deliberate removal of a shared dependency a direct empirical probe of common-mode failure.
Related originating lineages:
- Computer Science & Software Engineering — Chaos engineering independently normalized controlled dependency failure in live distributed systems.
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 computer_science only where it materially formed the mechanism and keeps present-day application breadth separate from provenance.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The probe is a live attack on shared dependencies, which distinguishes it from a Tabletop Breach Walkthrough: the tabletop talks a breach through to find coordination and assumption seams, while the probe actually severs a dependency to find the technical coupling a discussion would rationalize away. They are complements — one finds the ambiguous escalation rule, the other finds the single power feed behind three "independent" systems.
[n1] A common-cause failure is a single event or shared root that defeats multiple redundant elements at once — the reason nominal redundancy can deliver far less protection than its component count suggests. Deliberately hunting shared causes is the standard corrective, since they are exactly what per-layer testing cannot see. ↩