Skip to content

Infrastructure-Load Simulation

Simulation model — instantiates Internal Capacity Deepening

Simulates how a proposed density increase loads the shared support systems — utilities, circulation, queues, supervision — and where the next bottleneck or cascade will appear.

Adding density to a position rarely fails at the position itself — it fails at the shared systems that serve it. Infrastructure-Load Simulation models what happens to utilities, circulation, cooling, supervision, transport, networks, and queues when you pack more into the existing envelope, and it predicts the two things a spreadsheet misses: the density at which a support system saturates, and where the binding constraint moves once you relieve the one you were worried about. Its defining contribution is treating capacity as a system, not a count — the new bottleneck is usually somewhere no one was looking, and under load, small saturations propagate into cascades.

Example

A stadium wants to add 4,000 seats by tightening row spacing rather than building a new deck. The seating math works; the simulation is run to check everything the seats depend on. It loads the concourse at the new headcount and finds egress time at a main exit climbing past the safety envelope during a simultaneous end-of-event surge, restroom queues spilling into circulation, and the transit platform outside — not the stadium at all — saturating first. Relieve the exit, and the model shows the constraint jumping to the transit platform; relieve that, and it lands on concession power draw. The simulation turns "add 4,000 seats" into a mapped chain of support-system ceilings, each of which must be cleared before the density is safe — and shows that one of them sits outside the operator's control entirely.

How it works

The simulation's distinctive move is propagation. It starts from a map of each support system and its real ceiling, drives the proposed density through them together, and watches load flow from one to the next — so relieving a bottleneck reveals the one behind it rather than declaring victory. It reports the utilization level at which each system saturates (the ceiling the density plan must respect) and, critically, models failure propagation: a queue that backs into a corridor, a cooling shortfall that trips a rack that sheds load onto its neighbours. The output is a chain of ceilings and cascade paths, not a single pass/fail.

Tuning parameters

  • System scope — which support systems are in the model. Too narrow and the simulation blesses a density that the un-modelled system (transit, supervision, wastewater) cannot survive.
  • Fidelity — steady-state averages versus dynamic, peak-and-surge simulation. Averages are cheap and hide exactly the surge failures that matter; dynamic models cost more but catch cascades.
  • Coupling assumptions — how strongly a failure in one system spreads to others. Weak coupling underplays cascade risk; strong coupling can make everything look fragile.
  • Ceiling margin — how much headroom below the saturation point counts as the usable ceiling, trading extracted capacity against safety under surge.

When it helps, and when it misleads

Its strength is refusing to let a plausible density plan hide its dependence on systems no one costed — it makes the support-side ceiling explicit and names the next constraint before it bites. It is what stops an intensification from succeeding on paper and failing in the corridor.

Its failure modes are the usual ones for a model, sharpened by coupling. It is only as honest as its support-capacity data and its scope — a system left out of the model is a cascade left out of the plan. Because relieving one constraint moves it elsewhere, a simulation stopped after the first fix gives false comfort.[1] And it is readily run backwards — tuned until it blesses a density target already chosen. The discipline is to model the systems together rather than one at a time, simulate surge rather than average, and keep re-running as each constraint is relieved and the next appears.

How it implements the components

This simulation fills the support-system slice of the archetype — the ceilings a density plan must clear:

  • infrastructure_and_support_capacity_map — the mapped inventory of support systems and their real capacities, the model's substrate.
  • constraint_migration_monitor — the prediction of where the binding constraint moves as each prior one is relieved.
  • utilization_ceiling — the density at which each support system saturates, i.e. the evidence-based limit the intensification must stay under.

It does not enforce reserve floors or redundancy requirements — that is the Slack-Erosion Test — and it does not price the two growth modes against each other, which is the Intensification–Expansion Lifecycle Model. It supplies ceilings those mechanisms consume.

References

[1] Goldratt's Theory of Constraints observes that a system's throughput is set by one binding constraint, and that relieving it simply relocates the constraint elsewhere — the exact behaviour this simulation is built to trace, and the reason it reports a chain of ceilings rather than a single fix. ↩