Why timeline binds

The binding constraint — the boundary this site runs into first — is timeline, with a gap of 75 % ◌ derived. The runner-up is capital at 72.9 % ◌ derived, a margin of 2.1 % ◌ 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 75 % ◌ derived. The deployment schedule runs 36 months ◌ derived, with the utility queue at 36 months ◌ derived inside it. Revenue starts when the last gate clears; every month of schedule is a month of carry.

This market is severely supply-constrained: even at maximum utilisation supply cannot meet demand, and several constraints sit near their bounds. The constraint register files this state under the code R4 ◌ 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 capital 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 80 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 →