Dependency Removal Counterfactual¶
Counterfactual diagnostic — instantiates Pivotal Participation Leverage Mapping
Removes one participant at a time — deletes, refuses, or makes it unavailable — and checks whether the outcome still happens, isolating true single points of failure from merely prominent contributors.
The archetype's core question is a but-for question: if this one unit vanished, would the outcome still occur? Dependency Removal Counterfactual is the deep, one-at-a-time version of that test. It takes a single participant, simulates its removal — deletion, refusal, or unavailability — while holding everything else fixed, and asks whether the precisely-defined outcome survives. If it does, the participant is prominent but replaceable; if it does not, the participant is a genuine dependency, a single point of failure. What distinguishes it from its siblings is depth over breadth: rather than summarizing power into a number or filling a whole grid at once, it interrogates one unit thoroughly — including whether a real fallback exists to catch the gap and whether the removal triggers second-order failures downstream.
Example¶
A consumer-electronics firm's dashboard lists three "key suppliers," ranked by annual spend. Marketing treats all three as strategic partners. Dependency Removal asks a sharper question of each: if you refuse to ship next quarter, does the product still leave the line? The two highest-spend suppliers turn out to have qualified alternate sources — remove them and production dips but the outcome survives; they are big, not pivotal. The third, a low-spend vendor of a custom RF module, has no drop-in substitute and a nine-month requalification path. Remove it and the outcome fails outright. That third vendor — invisible on a spend-ranked list — is the true single point of failure. The finding is produced not by size but by the removal test, and its verdict turns entirely on whether a fallback exists.
How it works¶
- Define the outcome precisely. State exactly what must happen for the collective outcome to count as achieved — the test is meaningless until "the outcome" is pinned down.
- Remove one unit. Simulate its deletion, refusal, delay, or defection while holding all other participants fixed.
- Check survival against fallbacks. Ask whether the outcome still occurs, explicitly crediting only substitutes that genuinely exist and would activate in time.
- Label and trace. Mark the unit pivotal or not, record why, and trace whether its removal knocks out anything else.
The single-unit, deep, causal framing is what sets it apart from the exhaustive matrix and the aggregate index.
Tuning parameters¶
- Removal semantics — full deletion, or softer forms (refusal, delay, partial availability, defection to the opposing side); harsher removals catch more dependencies but can overstate fragility.
- Ceteris-paribus scope — hold everything else frozen, or let the system adapt as others step up; the more adaptation you allow, the fewer units look pivotal.
- Fallback credit — whether to count substitutes that exist only on paper; optimistic crediting is the fastest way to hide a real single point of failure.
- Time horizon — survives this week vs. survives a year; a dependency with a slow substitute is safe long-term but pivotal in a crunch.
- Cascade depth — stop at the first-order outcome, or follow the knock-on failures the removal sets off.
When it helps, and when it misleads¶
Its strength is that it cuts straight past status and prominence to the causal question, surfacing the small, unglamorous unit whose absence breaks everything while demoting the large-but-replaceable one. It is the fast, sharp first screen for hidden dependencies.
Its blind spot is interaction: a strict one-at-a-time removal cannot see joint dependencies — two units each replaceable alone but jointly critical pass the atomic test and slip through. It also swings with the fallback assumption, and it is easy to run in self-interest ("remove my function and everything collapses") to manufacture indispensability. The disciplines are to state the fallback assumption out loud, test refusal and not just deletion, and escalate to a full pivotality matrix the moment interactions are suspected.[n1]
How it implements the components¶
pivotality_counterfactual_test— it is the atomic test: remove one unit, check whether the outcome survives.collective_outcome_definition— the test forces a crisp definition of the outcome that removal might break; the definition is a required first output.substitutability_and_fallback_map— each survive/fail verdict records, per unit, whether a fallback exists, producing the raw substitutability picture.
It does not aggregate these tests into a power score (that is Banzhaf Power Index) or tabulate them across all units and scenarios at once (that is Pivotality Counterfactual Matrix); and the redundancy it reveals a need for is actually built by the Redundancy or Substitute Build Plan.
Related¶
- Instantiates: Pivotal Participation Leverage Mapping — it supplies the per-unit "is this a genuine dependency?" verdict.
- Sibling mechanisms: Pivotality Counterfactual Matrix · Redundancy or Substitute Build Plan · Banzhaf Power Index · Minimal Winning Coalition Enumeration · Veto-Point Review · Swing-Vote Scenario Review
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: The mechanism deliberately simulates deleting, refusing, delaying, or defecting one participant while holding others fixed and observes whether the outcome survives, so it is an active dependency probe.
Nearest alternative: Analysis, Modeling & Optimization — Counterfactual modeling frames the case, but evidence about pivotality is generated through controlled unit-removal trials.
Review outcome: Adjudicated after independent review; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Convergent development
Present-day reach: Universal
Rationale: Law is primary because the mechanism's defining operation is the explicit but-for test: remove one factor while holding the rest fixed and ask whether the outcome would still occur. Reliability engineering independently converged on the same one-at-a-time necessity test through single-point-failure analysis and fallback assessment.
Related originating lineages:
- Engineering & Design — Reliability engineering independently developed single-point-failure analysis that asks whether loss of one element defeats the system outcome.
Review resolution: Law is primary because the mechanism's defining operation is the explicit but-for test: remove one factor while holding the rest fixed and ask whether the outcome would still occur. Reliability engineering independently converged on the same one-at-a-time necessity test through single-point-failure analysis and fallback assessment.
Attribution caveat: The generalized diagnostic deliberately joins legal counterfactual causation with engineering reliability analysis; neither lineage alone owns all of its fallback and cascade detail.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Researched adjudication after independent review; medium confidence.
Sources consulted:
Notes¶
Passing the single-removal test is necessary but not sufficient: a unit can survive its own knockout yet be half of a critical pair. Use this as the deep probe on one suspected dependency, then hand off to the Pivotality Counterfactual Matrix when joint effects are in play — the two are the same test at different scales.
[n1] The but-for test asks whether the outcome would still have occurred but for a given factor — the standard counterfactual test of necessity in law, mirrored in reliability engineering as the single point of failure. A unit that fails the but-for test is a genuine dependency, not merely a participant. ↩