Two fiber connections. Two power feeds. Two backup systems.
The project dashboard shows redundancy. The procurement checklist is complete.
Then a single flooded service corridor interrupts both connections.
The equipment was duplicated. The vulnerability was shared.
For an owner or operator, that distinction determines whether a disruption becomes a manageable incident or a complete service outage.
It also explains why infrastructure resilience needs spatial intelligence.
The hidden assumption behind “we have a backup”
Redundancy is intended to preserve a function when a component fails.
A second pump can protect against the failure of the first. An alternative network route can preserve connectivity when the primary route is interrupted.
But independence depends on the event being considered.
Two pumps may provide protection against an individual motor failure while remaining exposed to flooding in their shared electrical room. Two communications providers may offer different contracts while routing their cables through the same bridge crossing.
The useful question is therefore:
Redundant against which failure?
Without that qualification, “we have a backup” can create more confidence than the evidence supports.
Digital infrastructure still has a physical address
Yandex’s October incident provides a timely reminder. The company reported that its Sasovo data center was seriously damaged during a drone attack on the night of 7–8 October. Its cloud incident record attributed disruption affecting ru-central1-b to the resulting fire. yandex.com
This does not establish that a particular redundancy design failed. It demonstrates the physical exposure beneath digital services.
Applications depend on servers. Servers depend on power, cooling and connectivity. Those systems occupy buildings, follow corridors and connect to infrastructure beyond the property boundary.
Cloud architecture already recognizes the importance of isolation. AWS describes Availability Zones as discrete facilities with separate power, networking and connectivity, and explains that common infrastructure such as cooling equipment is not shared across zones. AWS Whitepaper
The broader lesson applies equally to hospitals, airports, factories and utilities: resilience depends on how failure is contained.
A dependency graph needs geography
A conventional dependency model might show:
System A uses Power Feed A. System B uses Power Feed B.
That relationship is useful, but incomplete.
A spatial investigation may reveal that both feeds pass through the same underground chamber or depend on the same upstream substation.
The systems have different identifiers. They share an exposure.
This is where a failure domain becomes useful: a boundary within which one event can disrupt multiple components.
That boundary could be a room, building, cooling system, transport corridor or flood-affected area. It may also extend through shared software or operating procedures.
Geography cannot explain every common failure. It can expose physical relationships that equipment lists and logical diagrams often leave invisible.
What a resilience-focused digital twin should reveal
Consider an illustrative industrial campus with two operational buildings.
Each has its own backup generator. Both generators are maintained and regularly tested.
However, their fuel supply depends on one storage installation. Their replenishment route crosses an access road that becomes impassable during severe flooding.
An equipment dashboard could report both generators as healthy.
A dependency model could identify their shared fuel supply.
A spatially informed operational twin could connect fuel availability, road access, flood exposure, expected running time and the services requiring protection.
That creates a more useful decision:
Will critical operations remain available until fuel delivery can resume?
Answering it requires current records and engineering judgement. The twin provides the context for assessment; its visual appearance does not validate the conclusion.
Measure the function that survives
Installed capacity describes what infrastructure can support under specified operating conditions.
Resilience assessment asks what remains available after disruption.
For a hospital, the relevant measure might be critical-care services sustained during a power interruption. For a water utility, it could be minimum supply maintained after losing a pumping station.
For a data centre, electrical capacity alone cannot establish usable compute. Cooling, networking, workload placement and recovery arrangements also matter.
I would frame the resulting assessment as resilient functional capacity: the service that remains deliverable under a defined scenario.
This is a proposed decision lens, rather than a universal standard or a single resilience score.
Every assessment should state the event, duration, service threshold, assumptions and evidence. Otherwise, a precise-looking percentage may hide an uncertain model.
Three questions before approving another backup
1. What must continue?
Define the service and acceptable interruption before selecting the technical solution.
Emergency communications, routine reporting and historical analytics may require different recovery arrangements.
2. What can fail together?
Trace shared dependencies across power, cooling, communications, access, environmental exposure and control systems.
Include infrastructure outside the site. Different suppliers do not automatically establish independent physical routes.
3. What proves recovery will work?
Review commissioning records, maintenance evidence and controlled recovery exercises.
A spare system may exist without sufficient capacity, current configuration or a workable transfer procedure. AWS similarly places responsibility on customers to design resilient workloads and deploy them appropriately across locations; infrastructure isolation alone does not complete the application’s resilience strategy. Reliability Pillar
Make uncertainty visible
The hardest part may be discovering that nobody can confirm the backup route.
A supplier describes it as diverse. An old drawing suggests otherwise. Field verification is incomplete.
The digital twin should preserve that uncertainty.
Record the claim, supporting evidence, verification date, responsible owner and next action. Independence should remain unverified until sufficient evidence supports it.
Temporary changes matter too. Maintenance can move normally separate systems onto one supply. Construction can close an alternative access route.
Resilience is therefore a condition to maintain throughout operations.
The investment decision changes
Once shared exposure becomes visible, another equipment purchase may offer less protection than expected.
Separating cable routes, protecting a shared control room, improving access or testing recovery could address the actual weakness more effectively.
That is the commercial value of connecting GIS, BIM, asset records and operational evidence: helping teams identify where an intervention changes the service outcome.
Before approving the next backup, ask for evidence that the event disabling the primary system will leave the backup usable.
The answer should survive a review of the map, the dependencies and the recovery procedure.
