Why network binds

The binding constraint — the boundary this site runs into first — is network, with a gap of 100 % ◌ derived. The runner-up is capital at 85 % ◌ derived, a margin of 15 % ◌ derived.

A token only earns money once it reaches its buyer, and this site's connection to the outside world is narrower than what its machines can produce. Part of the output could never reach a customer, so the data links, not the computers, cap the revenue.

Network binds at 100 % ◌ derived. Routing serves 0 tokens ◌ derived and leaves 500 B tokens ◌ derived unmet each month. The site carries 250 Gbps scenario across 2 scenario independent paths; a token that cannot reach its buyer earns nothing.

In this market, demand is catching up with supply: utilisation pressure is building while the facility remains cash-generative. The constraint register files this state under the code R2 ◌ derived.

Constraints form a cascade: each solved constraint increases the load on the next boundary. If network 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 cycle

Counterfactual not runasset-lifecycle analysis refused: analysis.asset_lifecycle.no_supported_generation

Refusals recordedParts of this analysis refused their inputs rather than clamp them. Refusals recorded: 1, each named by the internal rule that fired (analysis.asset_lifecycle.no_supported_generation). A refusal is a finding; the affected sections are omitted, not approximated.

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

Adjust the assumptions in the constraints builder →