In 2011, floodwater in central Thailand did not just damage factories. It interrupted hard-drive production in one of the world's most concentrated centers for that component, squeezed global electronics supply and sent prices sharply upward. This forced manufacturers far from the floodplain to confront a risk they had never scored as "weather exposure" at all.

Worldwide hard-drive shipments fell about 30% in the fourth quarter of that year, according to research firm IHS iSuppli. A regional monsoon became an international industrial shock, and most of the firms it hurt were nowhere near the water.

That is the problem with many risk registers: The spreadsheets, dashboards and risk matrices companies use to list threats, assign owners and score likelihood and impact. They score the trigger, not the route. Cybersecurity sits on one scale, supplier concentration on another, weather on a third, each line owned by a different function and escalated through a different chain.

It is tidy. It is also blind to the thing that actually idles a line because the damage is rarely in the first domain that a shock lands in. It's in the third, fourth and fifth domains the shock travels to while everyone is still staring at the first.

Consider how the Thailand cascade actually moved: Floodwater damaged production sites, disrupted transport, tightened component supply, exposed downstream concentration and slowed assembly far from the floodplain. Five hops, and only the first one looks like "weather" on anyone's register. By the time the shock reached a manufacturer's own line, it had crossed several domain boundaries and several functional owners—and no one's job was to watch the handoffs between them.

The instructive part is what happened next. Thailand's industrial estates are far better defended today than they were in 2011: higher levees, dredged canals, prepared pumps, improved flood forecasting. The wall got stronger. The concentration did not loosen—it tightened. By 2024, Thailand's Board of Investment reported that some 80 percent of the world's hard disks were made in the country, and the government approved a further $693 million expansion.

The situation is better at the wall and still dangerous at the handoff. That is the signature of a cascade: You can fix the box where the shock started and leave every downstream route exactly as exposed as before. Cascades do not expire when the floodwater recedes; they wait for the next trigger to travel the same unguarded path.

Here is a diagnostic worth running soon: Take your three most recent unplanned shutdowns. For each, write down where the trigger originated and where the cost actually landed. If those two columns name different functions, and they usually will, you've found a cascade your register is not built to see.

That is the problem cascade mapping is designed to examine. One version is the freely available CREF Atlas, which I built through the Yegii R&D Lab, drawing on work that began in systemic-risk research at Stanford. During that work, I discovered a failure mode every plant manager already recognizes: risk that refuses to stay in its box. The method follows a shock as it moves across technology, governance, markets, communities, the environment and health—the boundaries ordinary risk systems tend to keep separate.

Here are three ideas worth taking back to your own risk process, whether or not you ever open a tool.

Risk Crosses Domains; Your Org Chart Doesn't

The core claim is plain to state and hard to operationalize: A cascade is a sequence of effects in which each step hands force to the next, often crossing a domain boundary as it goes. The pattern is familiar once you see it. A ransomware attack on a pipeline becomes a fuel shortage, becomes a run on gas stations. A flood becomes a component shortage, becomes a production halt two continents away.

For an industrial operation, the lesson is uncomfortable because the boundaries the shock crosses are exactly the ones your org chart uses to assign ownership. A breach is IT's problem; a delayed shipment is procurement's; an idle line is operations'; the deferred labor issue it surfaces is HR's. Four owners, four scales, four escalation paths—and the cascade lives in the gaps between them.

In practice, the value is less about predicting the trigger and more about tracing the chain. You cannot forecast which supplier gets breached or which region floods. You can map, in advance, which of your dependencies sit one or two hops downstream of a domain you don't directly control, and decide now who owns that handoff.

An Absorber Can Become an Amplifier

The most counterintuitive part of the framework is also the most useful on a plant floor. The model decomposes any cascade into a small set of roles a factor can play—trigger, amplifier, absorber. The catch is that these roles are relative, not fixed; a factor that amplifies a shock in one cascade absorbs it in another, and the same factor can switch roles between the early and late stages of a single event.

Inventory is the cleanest manufacturing example. Buffer stock absorbs a short upstream disruption—it takes the shock and buys time. Push the same disruption past the buffer's depth and that inventory flips: now it's working capital frozen in a warehouse, an amplifier of a liquidity problem, the thing your CFO is staring at instead of the line. Same factor, opposite role, depending on where you sit in the chain.

This is why "build a resilient plant" tends to dissolve into platitude. You cannot pre-assign the absorber—it depends on the pathway. The practical move is to stop asking which of your assets is protective in general and start asking which is protective for this specific cascade, at this specific stage. That reframes a lot of standing assumptions about what your safety stock, your cross-trained crew, or your second supplier is actually doing for you.

Diagnostic: pick one absorber you're proud of—a buffer, a backup supplier, a flexible shift. Name the cascade in which it stops absorbing and starts amplifying. If you can't name that point, you don't yet understand the limit of your own protection.

Make the Reasoning Auditable, or Don't Trust the Conclusion

The third idea is methodological, but it matters on the shop floor. Too many risk tools ask you to trust a number. The better ones are built so you can check the work. Picture a supplier-risk dashboard that scores a vendor green because the vendor itself is financially sound and geographically safe—while missing that the vendor's own sole-source input sits in a flood plain two tiers up.

The score isn't wrong about what it measured; it's blind to the hop it never traced. An auditable model forces that hop into view.

That is the design principle behind a credible cascade map. In its current release-candidate form, the Atlas runs on an evidence base of several hundred risk factors, more than a thousand sourced propagation links and several hundred worked cases spanning historical events, current situations,and prospective scenarios. Every link carries provenance; every case is traceable to its sources. The 2011 Thailand floods case, for instance, isn't asserted as a story—it lays out the explicit pathway from flood to transport to supply to downstream assembly, with each hop sourced, so you can argue with the mechanism rather than the headline.

For practitioners, the takeaway transfers even if you never adopt a particular tool. The risk analysis you're shown should be inspectable. When a vendor scores your supply-chain exposure at a tidy number, ask what links produced it and whether each one is sourced.

An unauditable risk score is still a story. The problem is that stories usually break two handoffs downstream.

None of this requires software. The Monday-morning version is simple: Pick one recent disruption, draw the chain in five boxes from trigger to cost, mark the function that owned each box and circle the handoff nobody owned. That circle is the absorber you need to design—and it's almost never in the same domain as the trigger that set the whole thing moving.

/Do it with operations, procurement, IT, finance, and HR in the same room; otherwise, you will reproduce the same gaps your register already contains.

Cascade mapping has clear boundaries, and naming them matters as much as the claims. It does not predict triggers, and the tool is, by its own framing, a release candidate, not a finished product.

What it does is make propagation legible after the trigger is known—turning "we got unlucky" into "here is the pathway, here is where we had no absorber, here is who owns the next handoff."

For an operation that has been surprised by the same kind of indirect hit more than once, that reframing is the whole game.