Skip to content

Scenario Dependency Diagram

Planning artifact — instantiates Cross-Impact Interaction Mapping

Maps which scenario assumptions require, exclude, or hinge on other assumptions, exposing incoherent futures and the enabling conditions a scenario secretly depends on.

Scenario planners assemble futures by bundling assumptions — "high automation, tight labor, cheap energy" — and too often bundle them as if each were free to vary independently. A Scenario Dependency Diagram operates one level up from raw drivers: its unit of analysis is the assumption, and its defining job is to draw the logical dependencies between assumptions inside and across scenarios. Does assuming cheap energy require assuming a policy that also makes tight labor implausible? Does a scenario's headline outcome silently depend on an enabling condition no one wrote down? The diagram makes these require/exclude/hinge relations explicit, so a scenario set can be checked for coherence before strategy is hung on it. It is less a picture of the world than a consistency check on the stories being told about the world.

Example

A city's transportation authority is planning around four mobility scenarios for 2040 — from "autonomous-transit dominant" to "private-car resurgent." Each scenario is a bundle of assumptions: AV regulation, curb-pricing policy, ride-hail economics, transit funding, and remote-work persistence. The dependency diagram lays the assumptions out and draws the logic between them. It immediately exposes a contradiction in the flagship scenario: "autonomous-transit dominant" assumes both permissive AV regulation and strong transit funding, yet the same scenario assumes a fiscal squeeze that, elsewhere in its own logic, is what forces the deregulation — the funding and the deregulation cannot both hold from the same cause. The scenario is internally incoherent.

The diagram also surfaces a hidden hinge: the "private-car resurgent" future only makes sense if remote work stays high enough to keep congestion tolerable — an enabling condition that was assumed silently. Once exposed, that condition becomes a monitored trigger and the scenario is rewritten to state it. The strategic implication is concrete: two scenarios are repaired, and the authority stops planning around a future that could never happen as described.

How it works

  • Take assumptions, not drivers, as nodes. The diagram works over scenario assumptions — the propositions each future asserts — rather than over the raw driver set.
  • Draw require / exclude / hinge links. For each pair, ask whether one assumption necessitates another, contradicts it, or merely depends on it under a condition, and draw the corresponding logical edge.
  • Test each scenario for coherence. Walk a scenario's assumption set along the links; a cycle of contradictions marks an incoherent future, and a dangling requirement marks an unstated enabling condition.
  • Expose silent enabling conditions. Conditional dependencies that no scenario named are lifted into the open as explicit preconditions the strategy must track or assume deliberately.

Tuning parameters

  • Assumption granularity — coarse bundles versus finely-split propositions. Fine splitting catches subtle contradictions but multiplies the links to check.
  • Link vocabulary — plain requires/excludes versus a richer set (necessitates, is-inconsistent-with, is-enabled-by, is-weakened-by). Richer links model reality better but demand more judgment per pair.
  • Coherence strictness — how hard a contradiction must be before a scenario is flagged incoherent. Strict settings prune more aggressively but may kill usefully-provocative futures.
  • Cross-scenario scope — checking dependencies within each scenario only, or across the whole set (mutually exclusive scenarios, shared hidden conditions). Wider scope catches more but is heavier to maintain.

When it helps, and when it misleads

Its strength is catching the incoherent and the under-specified before they mislead a strategy: a scenario built on assumptions that cannot co-exist is worse than no scenario, and this diagram is the consistency check[n1] that finds it. Exposing silent enabling conditions is its second gift — it converts a hidden assumption into a monitorable trigger.

Its failure mode is scenario overconstraint: push the coherence logic too hard and every interesting, discontinuous future gets pruned as "inconsistent," leaving a set of bland, over-determined scenarios that agree with today. The classic misuse is treating logical dependency as prediction — reading "assumption A requires assumption B" as "A will cause B in the world," when the diagram only claims the story needs both to hold. The guarding discipline is to distinguish logical necessity from empirical likelihood, allow deliberately low-probability but coherent scenarios to survive, and use the diagram to repair scenarios rather than to shrink the future to the comfortable.

How it implements the components

Scenario Dependency Diagram fills the scenario-coherence end of the archetype:

  • scenario_dependency_logic — its core: the require/exclude/hinge relations among assumptions that determine which scenarios are internally coherent.
  • conditional_dependency — it lifts silent enabling conditions into explicit preconditions, showing that a scenario holds only if some threshold or state obtains.
  • strategic_implication_revision — repaired scenarios and newly-exposed conditions feed back as revised planning assumptions and monitored triggers.

It reasons over scenario assumptions, not over raw driver interactions, so it does not record how one trend amplifies or suppresses another (reinforcement_effect, dampening_effect) — that driver-level view is Trend Interaction Map. It also names the conditions a scenario depends on but does not run the live monitoring that tracks whether those conditions are activating (monitoring_indicator_link); that ongoing watch is Trigger Dependency Watchlist.

Editorial Notes

Form Classification

Form family: Representation, Specification & Plan

Rationale: Scenario Dependency Diagram operates as a static representation, map, specification, schema, or prospective plan that externalizes information because it maps which scenario assumptions require, exclude, or hinge on other assumptions, exposing incoherent futures and the enabling conditions a scenario secretly depends on.

Independent corroboration: The frozen evidence defines Scenario Dependency Diagram as 'Maps which scenario assumptions require, exclude, or hinge on other assumptions, exposing incoherent futures and the enabling conditions a scenario secretly depends on', so its operative form is Representation, Specification & Plan.

Nearest alternative: Analysis, Modeling & Optimization — Scenario Dependency Diagram includes features of an analytical, modeling, inference, comparison, or optimization procedure that derives insight or a solution, but its defining operation is a static representation, map, specification, schema, or prospective plan that externalizes information.

Review outcome: Independent reviewer agreement; medium confidence.

Origin Attribution

Primary origin: Futurism & Strategic Foresight

Origin pattern: Cross-disciplinary synthesis

Present-day reach: Multi-domain

Rationale: Checking internal coherence and enabling assumptions among scenarios is strategic foresight.

Related originating lineages:

  • Computer Science & Software Engineering — Constraint graphs independently represent require and exclude relations.
  • Organizational & Management Science — Organizational design, management, and operational governance supplies a parallel or contributing lineage for the mechanism's defining operation: maps which scenario assumptions require, exclude, or hinge on other assumptions, exposing incoherent futures and the enabling conditions a scenario secretly depends on.
  • Systems Thinking & Cybernetics — Causal dependency mapping materially exposes hidden enabling conditions.

Review resolution: Both blind reviewers agree that futurism_foresight is the primary historical origin. Explicit reconciliation of alternate_origin_disagreement, origin_mode_disagreement starts from reviewer_a's mechanism-specific evidence: Checking internal coherence and enabling assumptions among scenarios is strategic foresight. Reviewer A proposed alternates=computer_science, systems_cybernetics, origin_mode=cross_disciplinary_synthesis, domain_reach=multi_domain, and encyclopedia_synthesis=true; reviewer B proposed alternates=organizational_management, origin_mode=single_lineage, domain_reach=multi_domain, and encyclopedia_synthesis=true. The final record retains every independently supported alternate from either review (computer_science, systems_cybernetics, organizational_management) without an arbitrary cap, selects origin_mode=cross_disciplinary_synthesis to represent the combined lineage evidence, and records domain_reach=multi_domain and encyclopedia_synthesis=true. Present-day transfer is recorded as reach and is not treated as proof of historical origin.

Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.

Review outcome: Reconciled after independent review; medium confidence.

Notes

[n1] A consistency matrix (as used in morphological analysis, pioneered by Fritz Zwicky) checks each pair of chosen parameter values for compatibility, discarding combinations that cannot co-exist. It is the classical technique for ensuring a constructed scenario is internally coherent rather than an arbitrary bundle of assumptions.