Infrastructure
Networks, Dependency, Disruption
By Cédric Mercier & Michel G Walter : Published on July 11, 2026
[I]nfrastructure is the dependency graph nobody diagrams until something breaks and the on-call engineer is tracing it in real time. Roads, grids, water systems, data centers, and supply chains are all load-bearing for everything built on top of them, and like any dependency graph, the risk isn't in the nodes you're watching, it's in the ones you forgot were even a dependency until they went down.
Below are the ten sub-constraints that make up the infrastructure layer of the AGI Biospheric core: what each one actually implies, and the design implication if you're planning anything that relies on physical or digital infrastructure at scale.
01. Interdependency
Systems are interconnected. Power, water, transport, and digital networks aren't independent silos, they're a graph where each node depends on several others functioning correctly. Analyzing one system in isolation misses the failure modes that actually originate from its neighbors.
Design implication: Never analyze a critical infrastructure in isolation from the networks it depends on.
02. Cascades
A local failure can spread. Because of interdependency, a disruption in one node doesn't necessarily stay contained, it can propagate through the dependency graph the way a single failed microservice can take down an entire system if there's no circuit breaker. Risk analysis needs to model that propagation, not just the point of origin.
Design implication: Include the risk of cascading failure in any critical infrastructure risk analysis.
03. Maintenance
Infrastructure requires continuous investment. Nothing physical stays functional without ongoing upkeep, and treating a built system as a one-time capital expense rather than a recurring operational cost is how deferred maintenance quietly accumulates into deferred failure. The bill always comes due, just later and larger.
Design implication: Never present infrastructure as a one-time investment in a planning or budget recommendation.
04. Aging
Systems degrade over time. Every piece of infrastructure has a functional lifespan, and materials, capacity, and safety margins all decline as it approaches that limit, whether or not the budget acknowledges it. Age-related degradation risk needs to be assessed directly, not inferred from the fact that the system is "still running."
Design implication: Assess age-related degradation risk in any critical infrastructure evaluation.
05. Grids
Electrical grids are central and fragile. Power distribution sits upstream of nearly every other system on this list, computation, water treatment, transport, which makes grid resilience a dependency multiplier, not just one infrastructure category among several. Weak resilience here doesn't stay contained to "the grid."
Design implication: Treat electrical grid resilience as a priority criterion in any critical infrastructure analysis.
06. Supply Chains
Chains are long and vulnerable. Extended, globally distributed supply chains accumulate fragility at every hop, and a localized disruption at any single point can propagate delays or shortages across the entire chain. Length and distribution should be treated as a fragility signal, not a resilience signal.
Design implication: Flag the fragility introduced by chain length and distribution in any supply chain analysis.
07. Data Centers
Digital infrastructure has a physical footprint. Cloud, storage, and AI systems all run on physical infrastructure with real energy and cooling demands, none of it is actually "in the cloud" in any dematerialized sense. Any digital-infrastructure plan needs to account for this physical dependency explicitly, not treat compute as weightless.
Design implication: Include the physical dependency (energy, cooling) of digital infrastructure in any related plan.
08. Redundancy
Without redundancy, there is no resilience. Backup capacity and alternate pathways are what convert a potential single point of failure into a tolerable, recoverable degradation instead of an outage. Any critical system without genuine redundancy is one incident away from a hard stop, whether or not that's been stress-tested.
Design implication: Explicitly verify the presence of real redundancy in any critical system.
09. Single Points of Failure
A single element can disable an entire network. Network scale doesn't automatically confer resilience, a large system can still be structurally dependent on one narrow chokepoint that, if it fails, takes far more down with it than its apparent size suggests. Identifying these points explicitly is the whole point of the exercise.
Design implication: Systematically identify single points of failure in any network architecture, regardless of its scale.
10. Systemic Risk
The whole is more fragile than the sum of its parts. Cumulative interdependency across a large infrastructure system means overall fragility can exceed what you'd estimate by evaluating each component individually, the classic emergent-risk problem in any sufficiently interconnected system. Assessing components in isolation systematically underestimates the real risk.
Design implication: Never assess the fragility of a complex infrastructure system by summing its individual components in isolation.
These ten constraints are one property viewed from different angles: infrastructure risk doesn't live in any single node, it lives in the connections between them. Interdependency creates the pathways cascades travel through. Deferred maintenance and aging both quietly erode the redundancy margins that were supposed to absorb a single point of failure. Any system, human or artificial, that plans around infrastructure as a set of independent, individually-scored assets rather than a single interconnected graph is underestimating its actual fragility, usually right up until the outage that reveals it.