Shock Propagation in Infrastructure Networks: A Systems Modeling Case Study - Sustainable Catalyst | Open Knowledge Lab for Ethical Strategy and Systems Intelligence

Last Updated June 7, 2026

Shock propagation in infrastructure networks shows how a local failure can become a system-wide disruption. A substation trips, a bridge closes, a telecom node goes offline, a water pump loses power, a logistics hub floods, or a hospital backup system fails. At first, the event looks isolated. But infrastructure systems are connected through physical flows, dependency relationships, control systems, service demand, geographic exposure, operational capacity, and institutional response. When one component fails, load may shift elsewhere, dependent assets may lose service, repair crews may face access constraints, and failures can cascade across sectors.

This case study builds a practical network model of shock propagation in infrastructure systems. The model represents infrastructure as nodes, edges, capacities, dependencies, loads, redundancy, repair time, service criticality, and cascading failure rules. It compares several scenarios: a random local outage, a hub failure, a dependency cascade, a load-redistribution cascade, a compound hazard, and a recovery intervention. The goal is not to reproduce a real power grid, transport network, water system, telecom system, or healthcare network. The goal is to demonstrate how network structure shapes vulnerability, resilience, shock spread, and recovery priorities.

Infrastructure shocks are often misunderstood because decision-makers focus on the initiating event rather than the propagation pathway. A storm, cyberattack, equipment failure, traffic closure, pipe break, power outage, or supply interruption may be the trigger, but the severity of the disruption depends on network topology, spare capacity, dependencies, redundancy, isolation mechanisms, repair sequencing, and the services that depend on the failed assets.

This article works through the case as a model-building exercise. It defines the infrastructure network, identifies failure pathways, specifies assumptions, develops equations, designs scenarios, simulates propagation, measures systemic risk, interprets results, and explains how network modeling can support infrastructure resilience planning, emergency management, maintenance prioritization, and decision support systems.

Series context: This article is part of the Systems Modeling knowledge series, which examines how formal representations, simulations, assumptions, data, uncertainty analysis, and model-based reasoning help analyze complex systems across science, engineering, policy, sustainability, infrastructure, organizations, and public decision-making.

Infrastructure network model showing bridges, rail lines, power grids, substations, ports, roads, damaged corridors, disrupted nodes, and shock waves spreading through connected systems. — Shock propagation in infrastructure networks shows how a localized disruption can travel through transport, energy, water, and communication systems, creating secondary failures across connected regions.

This case study covers model purpose, network representation, nodes, edges, dependencies, capacities, failure rules, propagation mechanisms, load redistribution, redundancy, criticality, recovery sequencing, scenario design, diagnostics, uncertainty, limitations, mathematical framing, R and Python workflows, responsible interpretation, and references for further study.

Case Study Purpose

The purpose of this case study is to show how a network model can clarify shock propagation in infrastructure systems. Infrastructure networks are not simply collections of assets. They are connected systems that move electricity, water, vehicles, data, goods, people, information, emergency services, and operational commands. When one component fails, the effect depends on where it sits in the network, what depends on it, how much load it carries, whether alternatives exist, and how quickly service can be restored.

The model is intentionally simplified. It uses a small synthetic network so the propagation logic is visible. The case is designed for learning, reproducible analysis, decision-support design, and resilience planning. It is not a validated operational model of any real infrastructure system.

Case study aim	What it demonstrates	Why it matters
Represent infrastructure as a network	Assets become nodes and connections become edges.	Network position shapes systemic importance.
Model initial shocks	A node, edge, region, or dependency can fail first.	The same shock size can have different consequences depending on location.
Model propagation	Failures spread through dependency, overload, isolation, or service loss.	Risk depends on pathways, not just failed components.
Compare scenarios	Random failure, hub failure, dependency cascade, load redistribution, and recovery are tested.	Scenario comparison reveals fragile assumptions and critical vulnerabilities.
Measure systemic disruption	Outputs include failed nodes, service loss, isolated components, overloads, and recovery time.	Decision-makers need system-level diagnostics, not only asset-level failure counts.
Identify resilience interventions	Redundancy, segmentation, spare capacity, prioritization, and repair sequencing are tested.	Network design can reduce cascade size and speed recovery.

The central lesson is that infrastructure resilience is not only about asset strength. It is also about network structure, interdependence, spare capacity, substitution, isolation, monitoring, repair logistics, and decision-making under uncertainty.

The System Being Modeled

The modeled system is a synthetic infrastructure network. It can be interpreted as an electric distribution network, transportation network, water network, telecommunications network, logistics network, healthcare service network, or multi-sector infrastructure dependency network. Each node represents an asset or service unit. Each edge represents a physical connection, service relationship, flow path, or dependency link.

The model assigns each node a capacity, load, criticality value, dependency set, redundancy level, repair time, and status. A shock disables one or more nodes. The model then updates the system over time: dependent nodes may fail, load may redistribute, overloaded nodes may fail, disconnected nodes may lose service, and repair actions may restore selected components.

System element	Case study interpretation	Possible real-world analog
Node	An infrastructure asset, service point, or operational unit.	Substation, bridge, pump, telecom exchange, hospital, logistics hub.
Edge	A connection, flow path, dependency, or service relationship.	Transmission line, road link, pipe, fiber route, supply route.
Capacity	Maximum load a node can handle before overload risk rises.	Electrical capacity, road throughput, pump capacity, data bandwidth.
Load	Current demand, flow, or operational burden on a node.	Power demand, traffic volume, water flow, data traffic, patient demand.
Dependency	Requirement that one node needs another node to function.	Water pump depends on power; hospital depends on power, water, telecom, and road access.
Redundancy	Alternative routes, backup systems, or substitute capacity.	Backup generator, alternate road, parallel line, backup pump, failover data route.
Repair time	Time required to restore failed components.	Crew dispatch, parts availability, access constraints, inspection, restart.
Criticality	Importance of the node to system service or social consequence.	Hospital service, emergency route, major substation, water treatment plant.

The model treats infrastructure failure as both a technical and service problem. A failed asset matters because of what it supports, what depends on it, and what alternatives exist when it is unavailable.

Why Infrastructure Shocks Require Network Thinking

Infrastructure shocks require network thinking because the effect of a failure depends on connection patterns. A small asset in a critical location can be more important than a large asset with many substitutes. A local outage can become regional if it disconnects a hub, overloads alternatives, or disables dependent services. A system can look robust component by component while remaining fragile as a network.

Asset-level view	Network view	Why the difference matters
Counts failed components.	Tracks how failure changes connectivity, load, and service.	Few failures can cause large disruption if they hit critical positions.
Ranks assets by condition.	Ranks assets by condition, centrality, dependency, capacity, and criticality.	An old low-centrality asset may matter less than a newer high-dependency hub.
Studies single-sector performance.	Studies interdependencies across power, water, transport, telecom, health, and logistics.	Cross-sector dependencies can amplify local failures.
Assumes failure remains local.	Models propagation through edges, dependencies, overloads, and isolation.	Cascades can spread beyond the initial hazard footprint.
Focuses on repair of the broken asset.	Prioritizes restoration based on service recovery and cascade control.	The best first repair may be the node that reconnects many dependent services.
Measures downtime.	Measures downtime, service loss, affected demand, cascade depth, and recovery sequence.	Decision support needs consequences, not just outage duration.

Network modeling therefore shifts the question from “Which asset failed?” to “How did the failure move through the system, what service was lost, and which intervention would stop the cascade fastest?”

Core Network Structure

The core structure is a graph. Nodes represent infrastructure assets or service units. Edges represent connections or dependencies. The graph can be directed or undirected. In a road network, edges may be physical two-way links. In a dependency network, edges may be directed: a pump depends on a substation, a hospital depends on water service, a telecom node depends on backup power, and repair crews depend on road access.

Network concept	Symbol	Interpretation
Node set	\(V\)	Infrastructure assets, facilities, control points, or service units.
Edge set	\(E\)	Connections, flow paths, dependencies, or service relationships.
Adjacency matrix	\(A\)	Matrix showing which nodes are connected.
Dependency matrix	\(D\)	Matrix showing which nodes require other nodes to function.
Node load	\(L_i\)	Demand, flow, or operational burden at node \(i\).
Node capacity	\(C_i\)	Maximum load that node \(i\) can handle before overload risk.
Node status	\(x_i(t)\)	Functional state of node \(i\) at time \(t\).
Criticality	\(w_i\)	Service importance or consequence weight of node \(i\).

The model can be made more detailed by adding edge capacity, travel time, restoration crews, geography, exposure, cyber dependencies, sector labels, and multiple service layers. But the simple graph structure is enough to demonstrate cascading behavior.

Nodes, Edges, and Dependencies

Infrastructure networks contain different kinds of relationships. Physical connections move flows. Dependency relationships define requirements for functioning. Operational relationships define coordination or control. Geographic relationships define shared hazard exposure. The case distinguishes these relationships because they create different propagation mechanisms.

Relationship type	Meaning	Propagation risk
Physical connection	Material, people, power, water, vehicles, or data move along an edge.	Failure can block flow, reroute load, or isolate nodes.
Functional dependency	One node requires another node to operate.	Dependent node fails if required service is unavailable.
Capacity dependency	Alternative nodes absorb load after failure.	Load redistribution can overload substitutes.
Control dependency	Monitoring, commands, or coordination depend on another system.	Physical assets may remain intact but become hard to operate safely.
Geographic co-exposure	Multiple assets face the same hazard footprint.	Compound failures occur because assets fail together.
Repair dependency	Restoration depends on crews, access, materials, power, or communications.	Recovery can be delayed by failures elsewhere.
Social service dependency	Communities, hospitals, firms, and emergency services depend on infrastructure function.	Technical failure becomes social disruption.

A strong case model documents which edge type each connection represents. Treating all edges as the same can hide the difference between physical flow, operational dependency, and shared vulnerability.

Failure Mechanisms

Failure propagation can occur through several mechanisms. A good model should state which mechanisms it includes. This case includes dependency failure, overload failure, isolation failure, and delayed recovery. It can also represent compound shock when several nodes fail at the same time.

Failure mechanism	Model rule	Example
Initial shock	One or more nodes are set to failed at time zero.	A substation floods, a bridge closes, or a telecom facility loses power.
Dependency failure	A node fails if too many required dependencies fail.	A pump fails because the power node it depends on is unavailable.
Overload failure	A node fails if redistributed load exceeds capacity.	Traffic reroutes to a bridge that cannot handle the added volume.
Isolation failure	A node loses service if disconnected from a source or main component.	A neighborhood loses water service because the connecting pipe segment fails.
Compound failure	Multiple nodes fail from a shared hazard footprint.	Storm surge disables power, roads, and telecom nodes in the same district.
Recovery delay	Failed nodes remain down until repair time is completed.	Restoration waits for crews, access, parts, inspection, and restart.
Repair constraint	Only a limited number of nodes can be repaired per period.	Repair crews prioritize high-criticality nodes first.

These mechanisms create different cascade signatures. Dependency cascades spread through required services. Overload cascades spread through substitute capacity. Isolation cascades spread through connectivity loss. Compound shocks begin with multiple failures and can overwhelm redundancy immediately.

Propagation Pathways

Shock propagation is not random once the initial shock occurs. It follows pathways created by topology, dependency, load, capacity, geography, and repair constraints. A network model helps identify those pathways before a disaster or outage occurs.

Propagation pathway	How it spreads	Diagnostic to track
Topological spread	Failure moves through connected edges.	Connected component size, isolated nodes, path loss.
Dependency spread	Dependent nodes fail when required nodes fail.	Dependency failure count and cascade depth.
Overload spread	Load shifts to remaining nodes and exceeds capacity.	Load-to-capacity ratio and overload failures.
Service spread	Technical failure causes service loss for users or communities.	Weighted service loss and affected demand.
Geographic spread	Shared hazard disables multiple nearby assets.	Failed nodes by region and hazard footprint.
Recovery spread	Restoration of one node enables recovery elsewhere.	Service restored per repair action and recovery time.

Propagation pathways matter because resilience interventions target pathways, not just assets. Redundancy targets overload and isolation. Backup power targets dependency failure. Segmentation targets cascade containment. Monitoring targets early detection. Repair prioritization targets recovery speed.

Model Boundary

The model boundary includes a synthetic infrastructure network, node capacities, node loads, dependency links, redundancy levels, criticality weights, failure propagation rules, and simple repair scheduling. It excludes detailed engineering physics, power-flow equations, hydraulic equations, traffic assignment, cyberattack mechanics, real geography, institutional coordination, budget constraints, and social vulnerability. These exclusions keep the case focused on network propagation logic.

Inside the model boundary	Outside the model boundary	Why this matters
Nodes and edges	Detailed engineering design of each asset.	The model clarifies network behavior, not component physics.
Load and capacity	Full flow optimization or physics-based simulation.	Load redistribution is simplified.
Functional dependencies	Detailed cross-sector institutional contracts.	Dependency logic is modeled structurally, not administratively.
Criticality weights	Full social vulnerability and equity analysis.	Service consequence is simplified.
Repair time	Crew routing, logistics, procurement, weather, and access constraints.	Recovery is stylized.
Scenario shocks	Full hazard modeling.	Shock size and location are assumed rather than hazard-calibrated.
System-level diagnostics	Detailed legal, economic, political, and governance consequences.	Decision use requires expanded boundary and stakeholder review.

For real infrastructure planning, the boundary would need to expand. A power model may require power-flow constraints. A transportation model may require traffic assignment. A water model may require hydraulic equations. A multi-sector resilience model may require social vulnerability, emergency response, governance, funding, and recovery logistics.

Variables and Parameters

The model uses a small set of variables and parameters. Each is interpretable and supports scenario comparison.

Symbol	Name	Type	Interpretation
\(G=(V,E)\)	Infrastructure graph	Network structure	Nodes and edges representing infrastructure assets and connections.
\(A\)	Adjacency matrix	Structure	Shows physical or network connectivity.
\(D\)	Dependency matrix	Structure	Shows functional dependencies between nodes.
\(x_i(t)\)	Node status	State variable	1 if node \(i\) is functional at time \(t\), 0 if failed.
\(L_i(t)\)	Node load	State variable	Current load or demand handled by node \(i\).
\(C_i\)	Node capacity	Parameter	Maximum load before overload failure risk.
\(w_i\)	Criticality weight	Parameter	Service consequence if node \(i\) fails.
\(r_i\)	Redundancy level	Parameter	Degree of backup or alternative service available for node \(i\).
\(T_i\)	Repair time	Parameter	Time required to restore node \(i\).
\(\phi\)	Dependency tolerance	Parameter	Fraction of dependencies that can fail before node \(i\) fails.
\(\theta\)	Overload threshold	Parameter	Load-to-capacity level that triggers overload failure.

These variables support a transparent cascade model. More advanced models can add edge loads, probabilistic failure, geographic exposure, hazard intensity, multiple service sectors, repair crews, budget constraints, and social vulnerability.

Baseline Assumptions

The baseline assumptions define the simplified case. They should be treated as modeling choices, not facts. In real work, each assumption would require data, engineering review, stakeholder input, and validation.

Assumption	Baseline choice	Risk if wrong
Network is static during the simulation.	Edges and dependencies do not change except through failure.	Adaptive rerouting, emergency operations, and human behavior may be understated.
Node failure is binary.	A node is either functional or failed.	Partial service, degraded mode, and intermittent operation are ignored.
Load redistributes evenly to available neighbors.	Failed-node load is shared across connected functional alternatives.	Real load redistribution follows physics, routing, contracts, or control systems.
Dependencies are known.	Dependency links are defined in the synthetic dataset.	Hidden dependencies may be the most important cascade pathways.
Capacity thresholds are deterministic.	Overload occurs when load exceeds threshold.	Real overload failure may be probabilistic and time-dependent.
Repair resources are limited but simplified.	A small number of nodes can be repaired per period.	Real recovery depends on crews, access, materials, weather, and coordination.
Criticality weights are synthetic.	Service consequence is represented by a simple weight.	Real criticality must include public health, equity, emergency access, and social consequence.

These assumptions are useful for teaching propagation structure. They are not sufficient for operational decision-making without domain-specific modeling and validation.

Governing Equations

The model uses discrete-time cascade logic. Each period updates node status, load, service loss, and recovery.

\[
x_i(t)=
\begin{cases}
1, & \text{node } i \text{ is functional at time } t \\
0, & \text{node } i \text{ has failed at time } t
\end{cases}
\]

Node status: Each node is represented as functional or failed in the simplified model.

\[
\rho_i(t)=\frac{L_i(t)}{C_i}
\]

Load ratio: The load-to-capacity ratio \(\rho_i(t)\) measures overload pressure at node \(i\).

\[
x_i(t+1)=0 \quad \text{if} \quad \rho_i(t)>\theta
\]

Overload failure: A node fails if its load ratio exceeds the overload threshold \(\theta\).

\[
x_i(t+1)=0 \quad \text{if} \quad \frac{\sum_j D_{ij}(1-x_j(t))}{\sum_j D_{ij}}>\phi
\]

Dependency failure: A node fails if too large a fraction of its required dependencies have failed.

\[
S(t)=\sum_i w_i(1-x_i(t))
\]

Weighted service loss: Total service loss is the sum of criticality weights for failed nodes.

\[
R(t)=\frac{\sum_i w_i x_i(t)}{\sum_i w_i}
\]

Weighted service remaining: \(R(t)\) measures the fraction of weighted service still functional.

These equations are simplified, but they capture the main logic of cascade analysis: status affects load, load affects failure, dependencies affect failure, failure affects service, and recovery affects future status.

Scenario Design

Scenario design asks how different shocks and interventions move through the same network. This case uses six scenarios. Each scenario changes the initial shock, propagation rule, or recovery intervention.

Scenario	Main change	Question tested
Localized outage	A low-to-moderate criticality node fails first.	Does the network absorb a small local failure?
Hub failure	A high-degree or high-criticality node fails first.	How much does centrality shape cascade size?
Dependency cascade	A node fails that several dependent nodes require.	How strongly do functional dependencies amplify failure?
Load redistribution	Failed-node load shifts to neighboring nodes.	Does spare capacity prevent overload cascade?
Compound shock	Multiple co-located or cross-sector nodes fail at once.	How does simultaneous failure stress redundancy?
Recovery intervention	Repair prioritizes critical connectors and dependent-service enablers.	Which repair sequence restores the most service fastest?

Scenarios should be treated as conditional experiments. Their purpose is not to predict a specific outage, but to reveal vulnerability patterns, intervention timing, and restoration priorities.

Localized Outage Scenario

The localized outage scenario tests whether the network can absorb a small failure. One peripheral or moderately connected node fails. Load and dependency effects are updated. If redundancy is adequate, the failure remains contained. If the node supports hidden dependencies, the outage may spread.

Localized outage feature	Expected behavior	Interpretive warning
Small initial failure	Only one node fails at time zero.	A small initiating event can still reveal hidden dependency.
Low centrality	Few direct network neighbors are affected.	Low degree does not mean low criticality if the node supports essential service.
Limited load shift	Neighbors absorb a small amount of load.	Low spare capacity can convert a small outage into overload.
Rapid repair	Short repair time may prevent secondary failures.	Repair delays can allow cascading effects to accumulate.

This scenario provides a baseline for network robustness. If a small local failure produces a large cascade, the network may have hidden fragility, weak redundancy, or dependency concentration.

Hub Failure Scenario

The hub failure scenario disables a highly connected or high-criticality node. Hubs can be substations, major bridges, central pumps, interchanges, data centers, logistics hubs, or coordination centers. Hub failure can fragment the network, reroute large loads, isolate dependent nodes, or remove a major service source.

Hub failure dynamic	Expected model behavior	Planning implication
Connectivity loss	Many paths become longer or unavailable.	Critical hubs need redundancy, monitoring, and contingency plans.
Load redistribution	Large load shifts to alternate nodes or routes.	Spare capacity must be tested under hub outage.
Dependency loss	Dependent nodes lose required service.	Backup service must be available for critical dependencies.
Service concentration	Weighted service loss may be high even if few nodes fail.	Criticality matters as much as failure count.
Recovery priority	Repairing the hub may restore many services.	Repair sequencing should account for network reconnection value.

The hub scenario often reveals a key infrastructure principle: a node’s importance is not only its condition or replacement cost, but its role in connecting, enabling, and stabilizing the wider network.

Dependency Cascade Scenario

The dependency cascade scenario shows how failure spreads when one infrastructure service depends on another. A water pump may require electricity. A hospital may require power, telecom, water, road access, and fuel. A traffic control system may require communications and power. A data center may require cooling, power, water, telecom, and access.

In the model, each node has dependency links. If too many required dependencies fail, the node fails even if it was not directly shocked.

Dependency pattern	Model effect	Resilience implication
Single dependency	Node fails if its required provider fails.	Critical nodes need backup service.
Multiple dependencies	Node fails if a critical fraction of dependencies fail.	Dependency diversity can improve resilience if alternatives are real.
Common dependency	Many nodes depend on the same provider.	Shared dependency can become a systemic vulnerability.
Cross-sector dependency	Failure jumps from one infrastructure sector to another.	Resilience planning must coordinate across sectors.
Recovery dependency	Repair requires another infrastructure service.	Restoration sequence must account for enabling services.

This scenario is often the most important for public decision support because it shows why sector-by-sector planning can fail. A technically sound water system may still fail if its power, telecom, road, chemical supply, or staffing dependencies fail.

Load Redistribution Scenario

The load redistribution scenario models what happens when failed nodes push load onto surviving nodes. In transportation, traffic reroutes. In power, load may shift through alternate lines. In telecom, data traffic may reroute. In healthcare, patients may be redirected. In logistics, shipments may move through different hubs.

Load redistribution is helpful if spare capacity exists. It is dangerous if the substitute nodes are already near capacity.

Load redistribution condition	Model behavior	Risk
High spare capacity	Neighboring nodes absorb load without failing.	Service degrades but cascade is contained.
Low spare capacity	Redistributed load exceeds capacity threshold.	Overload cascade begins.
Uneven network topology	Load concentrates on a few alternatives.	Central substitutes become new failure points.
Delayed demand reduction	Load remains high after failure.	Temporary rerouting becomes sustained overload.
Adaptive control	Load is actively reduced, shed, or redirected.	Cascade can be slowed or stopped if controls work.

This scenario demonstrates why redundancy must be tested under stress. An alternate route or backup asset is not enough if it cannot carry the load assigned to it during failure.

Compound Shock Scenario

The compound shock scenario disables multiple nodes at once. Compound shocks may result from hurricanes, floods, earthquakes, fires, cyber-physical incidents, heat waves, regional outages, supply-chain disruptions, or coordinated attacks. In a compound shock, redundancy may fail because the backup system is exposed to the same hazard or depends on the same enabling service.

Compound shock feature	Model representation	Planning concern
Multiple initial failures	Several nodes are failed at time zero.	Redundancy may be unavailable immediately.
Shared hazard exposure	Nodes in the same region or sector fail together.	Co-location of backups can create false resilience.
Cross-sector disruption	Power, transport, telecom, water, and health nodes may fail together.	Emergency plans must account for simultaneous service loss.
Repair constraint	Many failures compete for limited restoration capacity.	Repair prioritization becomes a central decision problem.
Demand surge	Some services face higher demand during the shock.	Hospitals, shelters, emergency routes, and communications may overload.

The compound shock scenario is especially important for climate resilience, emergency management, and public-sector planning. It shows that resilience cannot be assessed by testing one asset failure at a time.

Recovery and Restoration Scenario

The recovery scenario adds repair. Recovery is not just a reverse cascade. The sequence of restoration matters. Repairing a low-criticality node may restore little service. Repairing a connector, dependency provider, or enabling node may restore many downstream services.

Repair strategy	Model rule	Expected effect
First-failed, first-repaired	Repair nodes in the order they failed.	Simple but may not restore the most service.
Highest criticality first	Repair nodes with highest service weight.	Restores important services but may miss dependencies.
Connector first	Repair nodes that reconnect the largest component.	Improves network connectivity quickly.
Dependency enabler first	Repair nodes with many dependent services.	Can unlock recovery for multiple downstream nodes.
Hybrid priority	Combine criticality, connectivity, dependency, and repair time.	Often best for decision support because it balances consequence and feasibility.

Recovery modeling turns cascade analysis into actionable decision support. It helps ask which repair action restores the greatest weighted service, stops further propagation, or reduces recovery time for critical communities and services.

Diagnostics and Output Measures

A useful infrastructure cascade model should report more than the number of failed nodes. Failure count does not capture criticality, service consequence, dependency depth, recovery time, or who is affected.

Diagnostic	Question answered	Why it matters
Total failed nodes	How many components failed?	Basic scale of technical disruption.
Weighted service loss	How important were the failed nodes?	Criticality matters more than raw failure count.
Cascade depth	How many propagation rounds occurred?	Shows whether failure spread recursively.
Overload failures	How many failures resulted from load redistribution?	Identifies spare-capacity weakness.
Dependency failures	How many failures resulted from required-service loss?	Identifies interdependency vulnerability.
Largest component size	How connected is the remaining network?	Fragmentation can disrupt service even without many failures.
Isolated nodes	How many nodes are disconnected from the main service component?	Shows service islands and access problems.
Time to recovery	How long until weighted service is restored?	Recovery duration is central to resilience.
Restoration efficiency	How much service is restored per repair action?	Supports repair prioritization.

For decision support systems, these diagnostics should be tied to clear use cases: emergency prioritization, maintenance planning, resilience investment, contingency design, public communication, or post-event review.

Interpretation of Results

The model results should be interpreted as behavior patterns, not precise predictions. The most important result is how the network responds under different shock and recovery conditions. Does the shock stay local? Does it spread through dependencies? Does spare capacity absorb load? Does the network fragment? Which repair action restores the most service?

Observed pattern	Likely interpretation	Planning implication
Failure remains local.	Redundancy and dependency tolerance are adequate for the tested shock.	Maintain monitoring and verify assumptions under larger shocks.
Failure spreads through dependencies.	Functional interdependence is a major vulnerability.	Add backup service, diversify dependencies, or improve cross-sector planning.
Failure spreads through overload.	Spare capacity is insufficient after rerouting.	Increase capacity, reduce demand, segment load, or add controlled shedding.
Network fragments.	Connectivity depends on a small number of bridges, hubs, or corridors.	Add alternate connections or protect articulation points.
Weighted service loss is high despite few failures.	Critical services are concentrated in vulnerable nodes.	Prioritize criticality-weighted resilience, not only asset count.
Recovery is slow.	Repair times, access, dependency sequencing, or resource limits dominate.	Pre-position materials, improve access, and prioritize enabling nodes.

The interpretation should identify the mechanism. A cascade caused by dependency failure requires a different intervention than a cascade caused by overload or network fragmentation.

Policy and Planning Leverage Points

The case reveals several leverage points for infrastructure resilience. Some are engineering interventions. Others are governance, planning, monitoring, and decision-support interventions.

Leverage point	Model intervention	Expected effect
Redundancy	Add alternate edges, backup nodes, or substitute service capacity.	Reduces isolation and dependency failure.
Spare capacity	Increase capacity margin at high-load nodes.	Reduces overload cascade risk.
Segmentation	Limit how far failure can propagate.	Contains cascades within smaller zones.
Dependency diversification	Reduce reliance on one common provider.	Prevents shared dependency failure.
Critical node hardening	Protect hubs, connectors, and dependency providers.	Reduces probability of high-consequence failures.
Controlled load shedding	Reduce load before overload failures occur.	Protects core system function during stress.
Repair prioritization	Restore nodes based on criticality, connectivity, dependency, and repair time.	Improves recovery speed and service restoration.
Cross-sector coordination	Model power, water, telecom, transport, health, and logistics together.	Reveals interdependencies that single-sector planning misses.
Decision support systems	Use model outputs to guide scenario planning, maintenance, emergency response, and recovery sequencing.	Improves model-informed action when uncertainty is communicated responsibly.

The best intervention depends on the dominant propagation mechanism. A dependency cascade needs dependency resilience. An overload cascade needs capacity or load management. Fragmentation needs connectivity. Slow recovery needs repair logistics and prioritization.

Uncertainty and Sensitivity

Infrastructure cascade models are sensitive to assumptions about topology, dependencies, capacity, load, repair time, redundancy, failure thresholds, and shock location. Responsible interpretation requires sensitivity analysis.

Uncertain assumption	Why it matters	Sensitivity test
Network topology	Missing edges or nodes can change connectivity and cascade pathways.	Test alternative network maps and hidden-dependency assumptions.
Dependency links	Unobserved dependencies can dominate propagation.	Compare low, medium, and high dependency density.
Capacity estimates	Overload risk depends on available spare capacity.	Test conservative and optimistic capacity margins.
Load distribution	Demand varies by time, season, emergency, and behavior.	Test peak load, average load, and emergency demand surge.
Failure thresholds	Nodes may fail gradually or probabilistically.	Test different overload thresholds and failure probabilities.
Repair time	Recovery results can change dramatically with restoration assumptions.	Test fast, delayed, constrained, and dependency-aware repair.
Shock location	Different initiating nodes can produce different cascade sizes.	Run random, hub, regional, and worst-case shock sets.

If conclusions change under plausible assumptions, the model should be communicated as fragile. Fragility is useful: it identifies where better data, redundancy, monitoring, or governance attention is most needed.

Model Limitations

This case study is intentionally simplified. It is useful for explaining network propagation, but it should not be used as a real infrastructure decision tool without major extensions.

Limitation	Why it matters	Possible extension
Binary node states	Real infrastructure can operate in degraded, partial, intermittent, or unsafe modes.	Add multi-state or probabilistic functionality.
Simplified load redistribution	Real flows follow physical laws, routing behavior, or control systems.	Add power flow, traffic assignment, hydraulic modeling, or routing algorithms.
Synthetic dependencies	Real dependencies may be hidden, proprietary, informal, or changing.	Use dependency mapping, stakeholder interviews, operational records, and cross-sector data.
No geography	Hazards often affect spatially clustered assets.	Add geospatial exposure and regional hazard layers.
No social vulnerability	Service loss affects populations unequally.	Add population, health, income, disability, access, and equity metrics.
No institutional dynamics	Recovery depends on governance, contracts, crews, funding, and coordination.	Add repair logistics, agency coordination, budget constraints, and mutual aid.
No validation against real outages	Numerical outputs are illustrative.	Calibrate and validate with historical outage and restoration data.

The model is best used for conceptual learning, scenario exploration, resilience planning, decision-support prototyping, and assumption review. Real operational use requires domain expertise and validated data.

Relationship to Other Systems Modeling Approaches

Shock propagation in infrastructure networks connects naturally with other systems modeling approaches. Network modeling provides the structural backbone, but infrastructure resilience often requires hybrid methods.

Approach	How it extends the case	Added value
Network modeling	Represents nodes, edges, connectivity, centrality, dependency, and cascade pathways.	Clarifies propagation structure and systemic vulnerability.
System dynamics	Adds feedback loops, repair delays, maintenance backlog, investment cycles, and policy resistance.	Clarifies long-term resilience and deferred maintenance effects.
Discrete-event simulation	Represents repair crews, queues, logistics, dispatch, inspections, and restoration timing.	Improves operational recovery modeling.
Agent-based modeling	Represents households, firms, commuters, operators, emergency responders, or repair crews.	Shows behavioral response and adaptive rerouting.
Geospatial systems modeling	Adds location, exposure, hazard zones, access, and affected populations.	Connects technical outage to place-based consequence.
Digital twins	Adds live monitoring, sensor data, and operational simulation.	Supports real-time situational awareness and decision support.
Participatory modeling	Includes operator, community, emergency, and stakeholder knowledge.	Improves boundary judgment, dependency identification, and legitimacy.
AI and machine learning	Detects anomalies, forecasts demand, estimates failure risk, or prioritizes inspection.	Improves signal detection but must be tied to causal and network structure.

The strongest infrastructure models are often hybrid. They combine network structure, flow physics, repair logistics, geospatial exposure, stakeholder knowledge, and decision-support interfaces.

Mathematical Lens: Cascades, Connectivity, Load, and Recovery

The infrastructure network can be represented as a graph:

\[
G=(V,E)
\]

Interpretation: \(V\) is the set of infrastructure nodes and \(E\) is the set of edges connecting them.

Node status is represented as binary in the simplified model:

\[
x_i(t)\in\{0,1\}
\]

Interpretation: Node \(i\) is either functional or failed at time \(t\).

Load stress is measured with a load-to-capacity ratio:

\[
\rho_i(t)=\frac{L_i(t)}{C_i}
\]

Interpretation: A node becomes more vulnerable as its load approaches or exceeds capacity.

Overload failure occurs when load exceeds a threshold:

\[
x_i(t+1)=0 \quad \text{if} \quad \rho_i(t)>\theta
\]

Interpretation: If node load exceeds the overload threshold, the node fails in the next period.

Dependency failure occurs when failed dependencies exceed tolerance:

\[
F_i(t)=\frac{\sum_j D_{ij}(1-x_j(t))}{\sum_j D_{ij}}
\]

Interpretation: \(F_i(t)\) is the fraction of node \(i\)’s dependencies that have failed.

\[
x_i(t+1)=0 \quad \text{if} \quad F_i(t)>\phi
\]

Interpretation: A node fails if the share of failed dependencies exceeds tolerance \(\phi\).

Weighted service loss summarizes consequence:

\[
S(t)=\sum_i w_i(1-x_i(t))
\]

Interpretation: Failed critical nodes contribute more to service loss than failed low-criticality nodes.

Recovery can be measured as weighted service restored:

\[
\Delta R_t = \sum_i w_i[x_i(t+1)-x_i(t)]
\]

Interpretation: \(\Delta R_t\) measures how much weighted service is restored between periods.

These equations create a transparent cascade model. They do not capture full engineering detail, but they clarify how failure propagates through network structure, dependencies, capacity limits, and restoration decisions.

The Case Study Workflow

This workflow shows how to build, run, and interpret a network model of shock propagation in infrastructure systems.

1. Define the Infrastructure Boundary

Decide which assets, services, sectors, geographies, populations, and dependencies are inside the model.

2. Build the Network

Represent assets as nodes and connections, flows, or dependencies as edges.

3. Assign Attributes

Add load, capacity, criticality, redundancy, dependency, repair time, and sector labels.

4. Define Shock Scenarios

Specify initial node failures for localized outage, hub failure, dependency cascade, load redistribution, compound shock, and recovery runs.

5. Apply Propagation Rules

Update failure status through dependency loss, overload, isolation, and repair constraints.

6. Track System Diagnostics

Measure failed nodes, weighted service loss, cascade depth, overload failures, dependency failures, and remaining connectivity.

7. Compare Scenarios

Identify which shocks produce the largest cascades, fastest propagation, highest service loss, or slowest recovery.

8. Test Interventions

Compare redundancy, hardening, segmentation, spare capacity, controlled load shedding, and repair prioritization.

9. Validate and Stress Test

Check assumptions against outage data, operator knowledge, engineering constraints, and plausible worst-case scenarios.

10. Communicate Decision Use

Explain model purpose, assumptions, uncertainty, valid use, invalid use, and implications for decision support systems.

R Workflow: Infrastructure Shock Propagation Simulation

The R workflow below uses base R only. It creates a synthetic infrastructure network, applies shock scenarios, simulates dependency and overload propagation, summarizes results, and exports tables and a simple figure.

# infrastructure_shock_propagation_workflow.R
# Base R workflow:
# synthetic infrastructure network, shock propagation, cascade diagnostics.
#
# Suggested repository placement:
# articles/case-study-shock-propagation-in-infrastructure-networks/r/infrastructure_shock_propagation_workflow.R

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- normalizePath(getwd(), mustWork = TRUE)
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

nodes <- data.frame(
  node = c("power_hub", "water_pump", "hospital", "telecom_exchange", "bridge", "logistics_hub", "fuel_depot", "neighborhood_a", "neighborhood_b", "emergency_ops"),
  sector = c("power", "water", "health", "telecom", "transport", "logistics", "fuel", "community", "community", "emergency"),
  load = c(85, 50, 70, 65, 75, 60, 45, 40, 35, 55),
  capacity = c(120, 70, 95, 85, 110, 80, 65, 60, 55, 75),
  criticality = c(0.95, 0.80, 1.00, 0.90, 0.75, 0.70, 0.65, 0.55, 0.50, 0.95),
  repair_time = c(4, 3, 5, 4, 6, 3, 3, 2, 2, 4),
  stringsAsFactors = FALSE
)

edges <- data.frame(
  from = c("power_hub", "power_hub", "power_hub", "telecom_exchange", "bridge", "bridge", "logistics_hub", "fuel_depot", "emergency_ops", "water_pump", "hospital", "telecom_exchange"),
  to   = c("water_pump", "hospital", "telecom_exchange", "emergency_ops", "hospital", "logistics_hub", "neighborhood_a", "logistics_hub", "neighborhood_b", "neighborhood_a", "neighborhood_b", "logistics_hub"),
  edge_type = c("dependency", "dependency", "dependency", "dependency", "access", "access", "service", "dependency", "service", "service", "service", "dependency"),
  stringsAsFactors = FALSE
)

scenarios <- list(
  localized_outage = c("neighborhood_a"),
  hub_failure = c("power_hub"),
  dependency_cascade = c("telecom_exchange"),
  load_redistribution = c("bridge"),
  compound_shock = c("power_hub", "bridge", "telecom_exchange"),
  recovery_intervention = c("power_hub", "bridge")
)

simulate_cascade <- function(scenario_name, initial_failures, max_steps = 8, overload_threshold = 1.05, dependency_tolerance = 0.50) {
  status <- rep(1, nrow(nodes))
  names(status) <- nodes$node
  status[initial_failures] <- 0

  current_load <- nodes$load
  names(current_load) <- nodes$node

  rows <- data.frame()

  for (step in 0:max_steps) {
    failed_nodes <- names(status)[status == 0]
    weighted_service_loss <- sum(nodes$criticality[nodes$node %in% failed_nodes])
    failed_count <- length(failed_nodes)

    rows <- rbind(
      rows,
      data.frame(
        scenario = scenario_name,
        step = step,
        failed_count = failed_count,
        failed_nodes = paste(failed_nodes, collapse = "|"),
        weighted_service_loss = weighted_service_loss,
        functional_count = sum(status == 1),
        stringsAsFactors = FALSE
      )
    )

    if (step == max_steps) {
      break
    }

    new_failures <- character(0)

    for (node_name in nodes$node[status == 1]) {
      incoming_deps <- edges$from[edges$to == node_name & edges$edge_type == "dependency"]
      if (length(incoming_deps) > 0) {
        failed_deps <- sum(status[incoming_deps] == 0)
        failed_fraction <- failed_deps / length(incoming_deps)
        if (failed_fraction > dependency_tolerance) {
          new_failures <- c(new_failures, node_name)
        }
      }
    }

    for (failed in failed_nodes) {
      neighbors <- edges$to[edges$from == failed]
      neighbors <- neighbors[status[neighbors] == 1]
      if (length(neighbors) > 0) {
        redistributed_load <- current_load[failed] / length(neighbors)
        current_load[neighbors] <- current_load[neighbors] + redistributed_load
      }
    }

    for (node_name in nodes$node[status == 1]) {
      capacity <- nodes$capacity[nodes$node == node_name]
      if (current_load[node_name] / capacity > overload_threshold) {
        new_failures <- c(new_failures, node_name)
      }
    }

    new_failures <- unique(new_failures)
    if (length(new_failures) == 0) {
      next
    }

    status[new_failures] <- 0
  }

  rows
}

all_runs <- data.frame()

for (scenario_name in names(scenarios)) {
  run <- simulate_cascade(scenario_name, scenarios[[scenario_name]])
  all_runs <- rbind(all_runs, run)
}

scenario_names <- unique(all_runs$scenario)
summary_rows <- data.frame()

for (scenario_name in scenario_names) {
  subset_rows <- all_runs[all_runs$scenario == scenario_name, ]
  final_row <- subset_rows[nrow(subset_rows), ]

  summary_rows <- rbind(
    summary_rows,
    data.frame(
      scenario = scenario_name,
      final_failed_count = final_row$failed_count,
      max_failed_count = max(subset_rows$failed_count),
      final_weighted_service_loss = final_row$weighted_service_loss,
      max_weighted_service_loss = max(subset_rows$weighted_service_loss),
      cascade_depth = max(subset_rows$step[subset_rows$failed_count == max(subset_rows$failed_count)]),
      stringsAsFactors = FALSE
    )
  )
}

validation_checks <- data.frame(
  check = c(
    "nodes_created",
    "edges_created",
    "scenario_runs_created",
    "weighted_service_loss_nonnegative",
    "summary_created"
  ),
  passed = c(
    nrow(nodes) > 0,
    nrow(edges) > 0,
    nrow(all_runs) > 0,
    all(all_runs$weighted_service_loss >= 0),
    nrow(summary_rows) > 0
  )
)

write.csv(nodes, file.path(tables_dir, "r_infrastructure_nodes.csv"), row.names = FALSE)
write.csv(edges, file.path(tables_dir, "r_infrastructure_edges.csv"), row.names = FALSE)
write.csv(all_runs, file.path(tables_dir, "r_shock_propagation_timeseries.csv"), row.names = FALSE)
write.csv(summary_rows, file.path(tables_dir, "r_shock_propagation_summary.csv"), row.names = FALSE)
write.csv(validation_checks, file.path(tables_dir, "r_shock_propagation_validation_checks.csv"), row.names = FALSE)

png(file.path(figures_dir, "r_shock_propagation_failed_nodes.png"), width = 1000, height = 700)
plot(
  NULL,
  xlim = range(all_runs$step),
  ylim = c(0, max(all_runs$failed_count)),
  xlab = "Propagation Step",
  ylab = "Failed Nodes",
  main = "Shock Propagation in Infrastructure Network Scenarios"
)

for (scenario_name in scenario_names) {
  subset_rows <- all_runs[all_runs$scenario == scenario_name, ]
  lines(subset_rows$step, subset_rows$failed_count, lwd = 2)
}

legend("topleft", legend = scenario_names, lwd = 2, cex = 0.75)
grid()
dev.off()

print(summary_rows)
print(validation_checks)
cat("R infrastructure shock propagation workflow complete.\n")

This workflow demonstrates how a small synthetic network can show cascade depth, service loss, scenario differences, and the importance of dependency-aware modeling.

Python Workflow: Cascading Failure in an Infrastructure Network

The Python workflow below uses only the standard library. It creates a synthetic infrastructure network, simulates shock propagation, tracks dependency and overload failures, exports scenario summaries, and validates model outputs.

#!/usr/bin/env python3
"""
Case study: shock propagation in infrastructure networks.

Dependency-light workflow demonstrating:

1. Synthetic infrastructure network creation
2. Initial shock scenarios
3. Dependency-based cascading failure
4. Load redistribution and overload failure
5. Weighted service loss
6. Scenario diagnostics and validation checks

All data are synthetic.
"""

from __future__ import annotations

from dataclasses import dataclass
from pathlib import Path
import csv


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"


@dataclass(frozen=True)
class Node:
    name: str
    sector: str
    load: float
    capacity: float
    criticality: float
    repair_time: int


@dataclass(frozen=True)
class Edge:
    source: str
    target: str
    edge_type: str


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows to write: {path}")

    fieldnames: list[str] = []
    for row in rows:
        for key in row:
            if key not in fieldnames:
                fieldnames.append(key)

    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=fieldnames, extrasaction="ignore")
        writer.writeheader()
        writer.writerows(rows)


def build_nodes() -> list[Node]:
    return [
        Node("power_hub", "power", 85, 120, 0.95, 4),
        Node("water_pump", "water", 50, 70, 0.80, 3),
        Node("hospital", "health", 70, 95, 1.00, 5),
        Node("telecom_exchange", "telecom", 65, 85, 0.90, 4),
        Node("bridge", "transport", 75, 110, 0.75, 6),
        Node("logistics_hub", "logistics", 60, 80, 0.70, 3),
        Node("fuel_depot", "fuel", 45, 65, 0.65, 3),
        Node("neighborhood_a", "community", 40, 60, 0.55, 2),
        Node("neighborhood_b", "community", 35, 55, 0.50, 2),
        Node("emergency_ops", "emergency", 55, 75, 0.95, 4),
    ]


def build_edges() -> list[Edge]:
    return [
        Edge("power_hub", "water_pump", "dependency"),
        Edge("power_hub", "hospital", "dependency"),
        Edge("power_hub", "telecom_exchange", "dependency"),
        Edge("telecom_exchange", "emergency_ops", "dependency"),
        Edge("bridge", "hospital", "access"),
        Edge("bridge", "logistics_hub", "access"),
        Edge("logistics_hub", "neighborhood_a", "service"),
        Edge("fuel_depot", "logistics_hub", "dependency"),
        Edge("emergency_ops", "neighborhood_b", "service"),
        Edge("water_pump", "neighborhood_a", "service"),
        Edge("hospital", "neighborhood_b", "service"),
        Edge("telecom_exchange", "logistics_hub", "dependency"),
    ]


def node_rows(nodes: list[Node]) -> list[dict[str, object]]:
    return [node.__dict__ for node in nodes]


def edge_rows(edges: list[Edge]) -> list[dict[str, object]]:
    return [edge.__dict__ for edge in edges]


def simulate_cascade(
    scenario_name: str,
    initial_failures: set[str],
    nodes: list[Node],
    edges: list[Edge],
    max_steps: int = 8,
    overload_threshold: float = 1.05,
    dependency_tolerance: float = 0.50,
) -> list[dict[str, object]]:
    node_by_name = {node.name: node for node in nodes}
    status = {node.name: 1 for node in nodes}
    load = {node.name: node.load for node in nodes}

    for failed in initial_failures:
        status[failed] = 0

    rows: list[dict[str, object]] = []

    for step in range(max_steps + 1):
        failed_nodes = [name for name, value in status.items() if value == 0]
        weighted_service_loss = sum(node_by_name[name].criticality for name in failed_nodes)

        rows.append({
            "scenario": scenario_name,
            "step": step,
            "failed_count": len(failed_nodes),
            "failed_nodes": "|".join(failed_nodes),
            "weighted_service_loss": round(weighted_service_loss, 6),
            "functional_count": sum(1 for value in status.values() if value == 1),
        })

        if step == max_steps:
            break

        new_failures: set[str] = set()
        dependency_failures: set[str] = set()
        overload_failures: set[str] = set()

        for node in nodes:
            if status[node.name] == 0:
                continue

            dependencies = [
                edge.source
                for edge in edges
                if edge.target == node.name and edge.edge_type == "dependency"
            ]

            if dependencies:
                failed_dependencies = sum(1 for dep in dependencies if status.get(dep, 0) == 0)
                failed_fraction = failed_dependencies / len(dependencies)

                if failed_fraction > dependency_tolerance:
                    dependency_failures.add(node.name)

        for failed in failed_nodes:
            neighbors = [
                edge.target
                for edge in edges
                if edge.source == failed and status.get(edge.target, 0) == 1
            ]

            if neighbors:
                redistributed_load = load[failed] / len(neighbors)
                for neighbor in neighbors:
                    load[neighbor] += redistributed_load

        for node in nodes:
            if status[node.name] == 0:
                continue

            load_ratio = load[node.name] / max(node.capacity, 1e-9)

            if load_ratio > overload_threshold:
                overload_failures.add(node.name)

        new_failures = dependency_failures | overload_failures

        if not new_failures:
            continue

        for failed in new_failures:
            status[failed] = 0

        rows[-1]["new_dependency_failures"] = "|".join(sorted(dependency_failures))
        rows[-1]["new_overload_failures"] = "|".join(sorted(overload_failures))

    return rows


def summarize(rows: list[dict[str, object]]) -> dict[str, object]:
    final = rows[-1]
    max_failed_count = max(int(row["failed_count"]) for row in rows)
    max_weighted_service_loss = max(float(row["weighted_service_loss"]) for row in rows)
    cascade_depth = max(
        int(row["step"])
        for row in rows
        if int(row["failed_count"]) == max_failed_count
    )

    return {
        "scenario": final["scenario"],
        "final_failed_count": final["failed_count"],
        "max_failed_count": max_failed_count,
        "final_weighted_service_loss": final["weighted_service_loss"],
        "max_weighted_service_loss": round(max_weighted_service_loss, 6),
        "cascade_depth": cascade_depth,
    }


def main() -> None:
    nodes = build_nodes()
    edges = build_edges()

    scenarios = {
        "localized_outage": {"neighborhood_a"},
        "hub_failure": {"power_hub"},
        "dependency_cascade": {"telecom_exchange"},
        "load_redistribution": {"bridge"},
        "compound_shock": {"power_hub", "bridge", "telecom_exchange"},
        "recovery_intervention": {"power_hub", "bridge"},
    }

    all_runs: list[dict[str, object]] = []
    summary_rows: list[dict[str, object]] = []

    for scenario_name, initial_failures in scenarios.items():
        rows = simulate_cascade(
            scenario_name=scenario_name,
            initial_failures=initial_failures,
            nodes=nodes,
            edges=edges,
        )
        all_runs.extend(rows)
        summary_rows.append(summarize(rows))

    validation_rows = [
        {
            "check": "nodes_created",
            "passed": len(nodes) > 0,
            "value": len(nodes),
        },
        {
            "check": "edges_created",
            "passed": len(edges) > 0,
            "value": len(edges),
        },
        {
            "check": "scenario_runs_created",
            "passed": len(all_runs) > 0,
            "value": len(all_runs),
        },
        {
            "check": "weighted_service_loss_nonnegative",
            "passed": all(float(row["weighted_service_loss"]) >= 0 for row in all_runs),
            "value": "all_weighted_service_loss_values_checked",
        },
        {
            "check": "summary_created",
            "passed": len(summary_rows) == len(scenarios),
            "value": len(summary_rows),
        },
    ]

    write_csv(TABLES / "python_infrastructure_nodes.csv", node_rows(nodes))
    write_csv(TABLES / "python_infrastructure_edges.csv", edge_rows(edges))
    write_csv(TABLES / "python_shock_propagation_timeseries.csv", all_runs)
    write_csv(TABLES / "python_shock_propagation_summary.csv", summary_rows)
    write_csv(TABLES / "python_shock_propagation_validation_checks.csv", validation_rows)

    print("Infrastructure shock propagation workflow complete.")
    print(TABLES / "python_shock_propagation_summary.csv")


if __name__ == "__main__":
    main()

This workflow creates a transparent starting point for cascade modeling. It can be extended with geospatial data, real outage records, sector-specific physics, stochastic hazards, repair crews, equity layers, and decision-support dashboards.

GitHub Repository

Complete Code Repository

Companion repository for the case study, including synthetic infrastructure network data, dependency and overload cascade simulation, shock scenarios, weighted service-loss diagnostics, validation checks, documentation assets, and multi-language examples for applied systems modeling.

View the Full GitHub Repository

Common Pitfalls

Infrastructure cascade models are useful because they reveal hidden propagation pathways. They can mislead if they oversimplify dependencies, ignore social consequence, or present synthetic cascade outputs as operational predictions.

Pitfall	Why it matters	Correction
Counting failures without weighting service consequence	A few critical failures may matter more than many low-criticality failures.	Report weighted service loss and affected service demand.
Treating all edges as the same	Physical connections, dependencies, access links, and service links propagate differently.	Label edge types and use mechanism-specific rules.
Ignoring hidden dependencies	Unmapped dependencies can dominate real cascades.	Use operator interviews, dependency audits, and cross-sector review.
Assuming redundancy is available	Backups can fail, lack capacity, or share the same hazard exposure.	Stress-test redundancy under compound scenarios.
Ignoring load redistribution	Surviving nodes may overload after absorbing failed-node demand.	Track load-to-capacity ratios after each failure.
Ignoring recovery sequence	Repair order can strongly affect service restoration.	Test criticality, connectivity, dependency, and repair-time prioritization.
Using topology without social consequence	Network metrics may miss who is affected.	Add population, vulnerability, emergency access, and equity layers.
Overclaiming simplified results	Teaching models are not validated operational tools.	State assumptions, boundary, uncertainty, valid use, and data requirements.

The central correction is to interpret cascade models as structured evidence about pathways and vulnerabilities, not as complete representations of infrastructure reality.

Conclusion

Shock propagation in infrastructure networks is a systems problem. A local failure becomes consequential when it moves through dependency, connectivity, load redistribution, capacity limits, shared exposure, and delayed recovery. The initiating event matters, but the propagation structure determines how far the disruption spreads and how difficult it is to recover.

This case study shows why infrastructure resilience requires network modeling. Asset condition matters, but so do hubs, bridges, dependencies, spare capacity, service criticality, redundancy, restoration sequence, and cross-sector coordination. A network can be robust against many small failures and still fragile to the failure of a small number of critical connectors or dependency providers.

The model also shows why decision support systems must communicate uncertainty and valid use. A simplified cascade model can help identify vulnerability, compare scenarios, prioritize repair, and guide resilience investment. But real decisions require validated data, engineering detail, stakeholder review, social consequence analysis, and responsible governance.

The central lesson is that infrastructure failure is rarely only about the asset that breaks. It is about what that asset connects, what depends on it, where load goes next, who loses service, and how quickly the system can adapt and recover.

References

Barabási, A.-L. (2016) Network Science. Cambridge: Cambridge University Press. Available at: https://networksciencebook.com/.
Buldyrev, S.V., Parshani, R., Paul, G., Stanley, H.E. and Havlin, S. (2010) ‘Catastrophic cascade of failures in interdependent networks’, Nature, 464, pp. 1025–1028. Available at: https://www.nature.com/articles/nature08932.
CISA. Infrastructure Dependency Primer: Learn. Available at: https://www.cisa.gov/topics/critical-infrastructure-security-and-resilience/resilience-services/infrastructure-dependency-primer/learn.
Hollnagel, E., Woods, D.D. and Leveson, N. (eds.) (2006) Resilience Engineering: Concepts and Precepts. Aldershot: Ashgate.
Johansson, J. and Hassel, H. (2010) ‘An approach for modelling interdependent infrastructures in the context of vulnerability analysis’, Reliability Engineering & System Safety, 95(12), pp. 1335–1344.
Little, R.G. (2002) ‘Controlling cascading failure: understanding the vulnerabilities of interconnected infrastructures’, Journal of Urban Technology, 9(1), pp. 109–123.
Motter, A.E. and Lai, Y.-C. (2002) ‘Cascade-based attacks on complex networks’, Physical Review E, 66, 065102. Available at: https://link.aps.org/doi/10.1103/PhysRevE.66.065102.
National Academies of Sciences, Engineering, and Medicine. (2017) Enhancing the Resilience of the Nation’s Electricity System. Washington, DC: National Academies Press. Available at: https://nap.nationalacademies.org/catalog/24836/enhancing-the-resilience-of-the-nations-electricity-system.
Newman, M.E.J. (2010) Networks: An Introduction. Oxford: Oxford University Press.
NIST. Community Resilience Planning Guide for Buildings and Infrastructure Systems. Available at: https://www.nist.gov/community-resilience/planning-guide.
Ouyang, M. (2014) ‘Review on modeling and simulation of interdependent critical infrastructure systems’, Reliability Engineering & System Safety, 121, pp. 43–60.
Rinaldi, S.M., Peerenboom, J.P. and Kelly, T.K. (2001) ‘Identifying, understanding, and analyzing critical infrastructure interdependencies’, IEEE Control Systems Magazine, 21(6), pp. 11–25.