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 48.3 % ◌ derived, a margin of 1.7 % ◌ 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.

This market is supply-constrained: demand is outrunning what can currently be built, unmet demand is present, and the binding constraint actively limits revenue. The constraint register files this state under the code R3 ◌ 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 132 kW ◌ derived design density no next chip generation is supportable — the nearest higher generation enters at 180 kW ◌ derived per rack. The refresh path holds the current generation and matches the sweat path over the analysis horizon; the facility supports 2 ◌ derived generation classes over 10 years ◌ derived.

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

Adjust the assumptions in the constraints builder →