Why timeline binds

The binding constraint — the boundary this site runs into first — is timeline, with a gap of 50 % ◌ derived. The runner-up is hardware at 37.2 % ◌ derived, a margin of 12.8 % ◌ derived.

Everything this site needs can be had — just not yet. Grid connection, permits, construction and deliveries stack into one long schedule, and no revenue flows until the last step clears. Waiting itself is the cost: every month of schedule is a month of financing paid with nothing earned.

Timeline binds at 50 % ◌ derived. The deployment schedule runs 24 months ◌ derived, with the utility queue at 24 months ◌ derived inside it. Revenue starts when the last gate clears; every month of schedule is a month of carry.

In this market, supply and demand are in balance: the facility can serve its demand at target utilisation across the planning horizon. The constraint register files this state under the code R1 ◌ derived.

Constraints form a cascade: each solved constraint increases the load on the next boundary. If timeline were cured — more of it bought, built or approved — the demand it now holds back would flow through to the next limit in this site's ranking, and hardware would become the binding constraint. Curing a constraint moves the boundary; it does not remove it.

Sweat the current fleetRefresh each cycleRefresh blocked

Counterfactual, sweat versus refresh: at 60 kW ◌ derived design density no next chip generation is supportable — the nearest higher generation enters at 120 kW ◌ derived per rack. The refresh path holds the current generation and matches the sweat path over the analysis horizon; the facility supports 1 ◌ derived generation classes over 5 years ◌ derived.

Whether that is acceptable is a judgment this model does not make.

Adjust the assumptions in the constraints builder →