Common-Driver Decomposition¶
Method — instantiates Vulnerability Hotspot Mapping and Hardening
Tests whether the vulnerabilities stacked on a hotspot are genuinely independent or all traceable to one shared cause — so hardening targets the driver, not the symptoms.
Once a hotspot is found, the map shows that several vulnerabilities pile up on one unit but not why. Common-Driver Decomposition answers the why-question that decides how to harden: are the co-located weaknesses independent — so the compounding is real and every layer needs its own fix — or are they all downstream of one shared cause, so the "five problems" are really one? Its defining move is separating apparent stacking from a concealed common cause, because the two demand opposite responses. When one driver dominates, the method flags it as a hidden single point of concentration: strengthen that, and the whole cluster relaxes at once. This is not detection (the cluster is already found) and not validation (whether it is statistically real) — it is attribution.
Example¶
A service team watches a dashboard hotspot: five nominally independent subsystems — checkout, search, notifications, the mobile API, and the recommendation feed — all degrade during the same peak hours. The instinct is five hardening projects. Decomposition instead asks whether the five failures move together and share an upstream. Tracing dependencies and correlating the incident timeline, the team finds all five read from one shared configuration service that saturates under load. The pile-up was one driver wearing five costumes. Hardening that config service — caching, a read replica, a load ceiling — quiets all five symptoms, where five separate efforts would have spent five budgets and left the real chokepoint untouched. Had the decomposition instead shown the five failures were genuinely uncorrelated, the correct conclusion would have been the reverse: a real compound hotspot needing layered, independent fixes.
How it works¶
The method turns a co-location map into an attribution:
- List the stacked vulnerabilities on the hotspot as separate candidate contributors.
- Test for dependence. Look for shared inputs, correlated failure timing, and common upstream components — not just that they co-occur, but that they move together.
- Attribute the variance. Partition the hotspot's risk between a dominant shared driver and genuinely independent contributions.
- Route the hardening. A dominant driver is marked as the concealed single point to strengthen; genuine independence means the compounding is real and calls for defense in depth across layers.
Tuning parameters¶
- Dependence test strength — correlation vs. mechanistic tracing. Correlation is cheap but confounded; tracing the actual pathway is costlier and more convincing.
- Driver granularity — how deep to trace before stopping. Stop too shallow and you name a symptom as the cause; chase too deep and every driver dissolves into "the environment."
- Independence prior — whether you start assuming the vulnerabilities are independent or shared. This sets the balance between inventing a false common driver and missing a real one.
- Evidence source — incident history, architecture/dependency graph, or expert judgment, and how much each is weighted.
When it helps, and when it misleads¶
Its strength is preventing the expensive category error of hardening many symptoms when one cause drives them all — and, conversely, of applying a single fix to a hotspot whose layers are genuinely independent. It is the step that distinguishes a concealed single point from real compounding, which a co-location map alone cannot tell apart.
Its failure modes are the classic hazards of causal attribution. Correlation is not common cause: things can move together because of a lurking third factor, and a decomposition run on correlations alone can crown a spurious driver.[n1] There is a pull toward monocausal bias — collapsing a genuinely multi-cause hotspot onto one tidy root and then under-hardening the other layers — and the method is easily run backwards to blame a convenient cause someone already wanted to fix. The discipline is to require a plausible mechanism, not just a correlation, and to keep the independent-compounding hypothesis alive until the shared driver is actually demonstrated.
How it implements the components¶
Common-Driver Decomposition realizes the attribution components of the archetype — the ones that explain a cluster rather than find, map, or harden it:
independence_and_shared_driver_check— this is the check: does the co-located risk share a driver, or is it independently stacked?single_point_or_concentration_marker— a dominant shared driver is flagged as the hidden single point of concentration to target.
It does NOT locate or map the cluster (Layered Risk Heatmap, Spatial or Network Cluster Detection) or confirm it is statistically real (Multiple-Testing Holdout Check); it does NOT harden the driver it names — that falls to Single-Point-of-Failure Elimination and Exposure Pathway Breakpointing.
Related¶
- Instantiates: Vulnerability Hotspot Mapping and Hardening — supplies the attribution that tells hardening whether to fix one cause or many layers.
- Consumes: the cluster located by Layered Risk Heatmap or Spatial or Network Cluster Detection.
- Sibling mechanisms: Multiple-Testing Holdout Check · Single-Point-of-Failure Elimination · Spatial or Network Cluster Detection · Exposure Pathway Breakpointing
Editorial Notes¶
Form Classification¶
Form family: Analysis, Modeling & Optimization
Rationale: Tests whether the vulnerabilities stacked on a hotspot are genuinely independent or all traceable to one shared cause — so hardening targets the driver, not the symptoms, making its operative form a computation, comparison, model, or analytic representation used to infer, estimate, or choose.
Independent corroboration: The frozen evidence defines Common-Driver Decomposition as 'Tests whether the vulnerabilities stacked on a hotspot are genuinely independent or all traceable to one shared cause — so hardening targets the driver, not the symptoms', so its operative form is Analysis, Modeling & Optimization.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Engineering & Design
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Multi-domain
Rationale: Reliability engineering established explicit dependency analysis that traces apparently redundant or separate failures to common support systems, environments, maintenance processes, controls, or other shared causes before assigning independent risk reduction.
Related originating lineages:
- Statistics & Experimental Design — Causal and variance-decomposition methods help distinguish shared latent drivers from independent contributors and quantify the common share.
Review resolution: NRC reliability guidance explains that dependent failures defeat redundancy, traces functional dependencies to shared support systems and subtle interactions such as common maintenance, controls, and environments, and models them in fault and event trees. NRC's common-cause database guidance separately defines shared-cause events and a process for screening, classifying, and understanding them. This directly supports engineering design as the complete lineage, with statistics retained for formal attribution.
Attribution caveat: Statistical decomposition supplies attribution mathematics, but engineering reliability is primary because the mechanism is a dependency investigation that identifies and routes hardening against concrete common causes.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
- U.S. NRC: Common-Cause and Dependent Failures
- U.S. NRC: Availability of Common-Cause Failure Database
Notes¶
Decomposition should precede resource targeting, because its result changes the shape of the plan: a shared-driver verdict argues for one deep fix, an independence verdict for many shallow ones. Skipping it doesn't just lose information — it silently biases the whole hardening budget toward whichever framing was assumed.
[n1] In reliability engineering a common-cause failure is one shared condition that defeats several nominally redundant elements at once — the failure mode this method exists to surface. Correctly used, it is the reason co-located failures must be tested for a shared driver before they are treated as independent. ↩