Cascade Dependency Graph¶
Structural model — instantiates Cascade Pathway Management
Maps the standing web of transfer links and branch points so a change's possible propagation paths — including jumps across domains — can be read off before anything moves.
A Cascade Dependency Graph is a structural model of the system's connective tissue: every element as a node, every "if this changes, that is affected" relation as a directed edge. Its defining property is that it is descriptive and standing — derived from the actual wiring of the system (calls, exposures, physical connections, data flows) rather than imagined in a room — and it enumerates the links exhaustively so any hypothetical change can be traced forward across the web to see everything it could reach. It answers a static question, "what is connected to what, and which way does effect flow," and leaves the dynamic questions of when and how hard to others. It is a map, not a rehearsal and not a decision.
Example¶
An engineering team runs a payments platform built from forty microservices. Nobody holds the whole picture of what depends on what, so every outage is a surprise: a small service goes down and, hours later, checkout mysteriously fails three hops away. The team builds a dependency graph by instrumenting real traffic — every service call, queue, and shared database becomes an observed edge in the graph, direction included (the checkout service calls the fraud service, not the reverse).
With the graph assembled, they can read propagation off it directly. Take down the currency-conversion service on paper and trace forward: it feeds pricing, which feeds checkout, which feeds the receipts service and the analytics pipeline. The graph also marks where an edge crosses a boundary the team doesn't own — the currency service calls an external exchange-rate vendor, a link that leaves their domain entirely and would carry a failure in from outside their control. None of this predicts when a cascade will fire or how bad it gets; it establishes, before any incident, the complete set of paths a disturbance at any node could travel.
How it works¶
- Enumerate nodes and directed edges. Every element becomes a node; every dependency becomes a directed edge pointing the way effect flows. Direction is the whole point — an undirected diagram cannot tell propagation from mere association.
- Derive edges from evidence, not memory. Edges come from observed calls, traced data flows, physical wiring diagrams, or contractual exposures, so the graph reflects the system as built rather than as remembered.
- Trace reachability on demand. Given any starting node, a forward traversal returns every node the change could eventually reach — the reachable set that bounds the worst-case blast radius.[n1]
- Flag boundary-crossing edges. Edges that leave the mapped domain (third-party vendors, other teams, other jurisdictions) are marked specially, because they carry propagation in and out of the zone anyone can control.
Tuning parameters¶
- Granularity — how fine the nodes are (whole services vs. individual endpoints; substations vs. individual lines). Finer graphs reveal precise paths but explode in size and staleness risk; coarser graphs stay legible but hide within-node propagation.
- Edge evidence bar — how much proof an edge needs before it is drawn. A low bar captures informal and rare links (fewer hidden bypasses) at the cost of clutter; a high bar keeps the graph clean but risks missing the sleeper link that actually transmits a cascade.
- Refresh cadence — how often the graph is re-derived from live evidence. Frequent refresh fights staleness but costs instrumentation effort; infrequent refresh invites the archetype's stale-map failure.
- Boundary scope — how far past your own domain the graph extends. Wider scope surfaces external contagion paths but pulls in nodes you cannot observe well.
When it helps, and when it misleads¶
Its strength is making an invisible web legible before anything goes wrong: it turns "we think these are connected" into an enumerated, directional model you can query, and it is the substrate every other cascade control needs — you cannot place a breaker, a gate, or a monitor without first knowing where the links are.
Its failure mode is the map that lies by omission. A dependency graph is only as complete as its edges, and the links most likely to transmit a real cascade are exactly the informal, undocumented ones an evidence-based build can miss — the archetype's hidden bypass pathway. A graph also goes stale silently: the system rewires while the picture does not, and confidence in an out-of-date map is worse than no map. The classic misuse is treating the graph as guaranteed-complete and reasoning as if unmapped links cannot exist. The guarding discipline is to re-derive from live evidence on a cadence, to hunt deliberately for undocumented edges, and to treat the reachable set as a lower bound on blast radius, never a ceiling.
How it implements the components¶
propagation_pathway_map— it is the pathway map: nodes, directed edges, and branch points showing how change can move from any element to the next.transfer_link_inventory— its edge set is the exhaustive inventory of transfer links, each recorded with its direction and evidence.cross_domain_boundary_map— it marks the edges that cross out of the owned domain, recording where propagation can enter from or escape to systems no one here controls.
It is a static description only. It does not choose which links to sever — that prescriptive step is its nearest twin, Dependency Cut-Set Review, which consumes this graph and owns the cascade_breakpoint_set. Nor does it host human foresight about consequences: eliciting what a trigger might set off, and standing up a residual_cascade_review_loop, belongs to Consequence Cascade Workshop. The graph maps the wiring; the review decides where to cut it, and the workshop imagines what travels along it.
Related¶
- Instantiates: Cascade Pathway Management — the graph is the archetype's foundational legibility artifact; nearly every other control reads off it.
- Sibling mechanisms: Dependency Cut-Set Review · Consequence Cascade Workshop · Cascade Circuit Breaker · Rate-Limit or Quarantine Gate · Leading-Link Indicator Dashboard · Propagation Simulation or Fault Injection · Domino Tabletop Exercise · Beneficial Cascade Seeding Plan
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Maps the standing web of transfer links and branch points so a change's possible propagation paths — including jumps across domains — can be read off before anything moves, making its operative form a non-executable information artifact that externalizes static or prospective structure.
Independent corroboration: The frozen evidence defines Cascade Dependency Graph as 'Maps the standing web of transfer links and branch points so a change's possible propagation paths — including jumps across domains — can be read off before anything moves', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Convergent development
Present-day reach: Multi-domain
Rationale: Software and systems architecture established directed dependency graphs for reachability and blast-radius analysis.
Related originating lineages:
- Systems Thinking & Cybernetics — Systems mapping contributes cross-domain transfer links and standing structural interpretation.
Review resolution: Computer science is primary because the source constructs a directed graph from actual service calls and data flows, then computes downstream reachability and blast radius. Systems analysis is a genuine formative lineage, but operations research is not necessary to explain this recognizable software-dependency method.
Review outcome: Researched adjudication after independent review; high confidence.
Sources consulted:
Notes¶
[n1] Blast radius — the site-reliability term for the full set of things a single failure can affect. A dependency graph's forward-reachability traversal is the standard way to compute it, and shrinking the blast radius (by cutting or gating edges) is a common motivation for building the graph in the first place. ↩