Cascade Blindness: Designing Wargames That Stress-Test Interdependent Systems

Most wargames treat systems the way org charts treat organizations — as clean boxes with labeled arrows. Power grid here. Supply chain there. Financial markets somewhere off to the right. The problem is that catastrophic failures almost never stay inside the box. They jump.

Photo by Matias Luge on Pexels.

The 2003 Northeast blackout started with a software bug in Ohio and left 55 million people without power across eight U.S. states and Canada within two hours. No single-system model predicted it. No wargame run by a regional utility that year was designed to ask what happens when the alarm system goes dark at the same moment line engineers are distracted by a separate outage. That's cascade blindness — and it's endemic to exercises that optimize each system node without modeling the edges between them.

So how do you actually design your way out of it?

Start with the dependency map, not the threat list

Most exercise designers begin by asking: what are the plausible threats? Flip it. Begin by mapping every dependency your system-of-systems has on adjacent systems — power, data, personnel, logistics, communications — and ask which of those dependencies is invisible to the people operating the primary system. Those invisible links are where cascade events incubate.

For a tabletop exercise, this means building what I call a cross-domain dependency matrix before you write a single inject. Rows are your primary systems. Columns are external dependencies. Each cell gets a simple rating: known/managed, known/unmanaged, or unknown. The unknown cells are your design targets. Every major inject in the exercise should threaten at least one unknown cell.

Here's a simplified flow for structuring this:

graph TD
    A[Map Primary Systems] --> B{Identify Cross-Domain Dependencies}
    B --> C[Known / Managed]
    B --> D[Known / Unmanaged]
    B --> E[Unknown]
    E --> F[Design Injects Targeting Unknown Links]
    D --> F
    F --> G[Run Exercise — Observe Propagation]
    G --> H[Update Dependency Map]

Notice that the loop closes back. One exercise run is rarely enough. Each run teaches you something about edges the matrix missed.

The timing problem nobody talks about

Cascade events are exquisitely sensitive to timing. The 2010 Flash Crash — where the Dow shed nearly 1,000 points in minutes before partially recovering — wasn't caused by a single bad actor or algorithm. It was caused by a specific sequence of events at a specific market liquidity moment. Shuffle the order and you probably get a footnote, not a crisis.

Most wargames compress time. That's fine for strategic-level exercises, but it's lethal for cascade modeling. When you compress time, you inadvertently give players the gift of sequential clarity — they see inject A, respond, then see inject B. Real cascades don't wait for your response cycle. They stack.

The design fix is simultaneous inject delivery: multiple injects released at the same time across different functional cells, with no coordination signal between them. Players discover the linkage themselves — or they don't, which is itself a data point. FEMA's Hurricane Pam exercise in 2004 actually did something close to this, layering infrastructure, medical, and evacuation injects concurrently across agencies. The gaps that surfaced directly influenced (though clearly not sufficiently) pre-Katrina planning conversations.

Give one player the cascade role

Here's a specific mechanic worth borrowing or adapting: designate a single player — not the red team, not the umpire — as the cascade adjudicator. Their only job is to watch for second and third-order effects that the standard adjudication rules won't catch, and surface them as unscripted injects. They hold a deck of blank cards. When they observe that Player A's decision has just stressed a dependency that Player B's team manages, they write a new inject and hand it to the umpire within five minutes.

This role works best when filled by someone with genuine cross-domain experience: a civil engineer who has also worked logistics, or a financial risk analyst with infrastructure exposure. Domain hybrids see edges that specialists miss. Specification matters here — don't just assign whoever is available.

What you're actually measuring

The output of a cascade-focused exercise isn't a list of threats defeated or survived. It's a revised dependency map — annotated with the propagation paths your players did and didn't anticipate. Which links were invisible to the team until they broke? Which responses inadvertently stressed a third system nobody was watching?

Run that comparison honestly, and you've built something most models can't: a record of your own blind spots, in a controlled environment, before the cascade finds them for you.