Buying compute like real estate

White paper excerpt, about 1,500 words. A guide chapter for a B2B technology audience, built with callouts, a comparison table and a glossary: the shape commissioned for gated content.

Executive summary. Enterprise buyers now choose between three ways of securing AI compute: a colocation lease on powered shell, a managed-capacity contract with a provider who owns the hardware, and a reserved-cloud commitment priced per unit of consumption. They are usually presented as pricing options. They are better understood as three different allocations of construction risk, technology risk and counterparty risk. This section sets out what each structure puts on the buyer's side of the ledger, and the six figures a finance team should have in front of it before signing any of them.

Why the comparison is worth making

For twenty years, enterprise compute procurement was a procurement problem. Racks, storage and licences were bought on three-year cycles and depreciated on a schedule the finance team already understood.

AI capacity broke that pattern in three ways at once. The unit of scarcity moved from chips to megawatts, because a GPU order can be placed but an interconnection cannot. The contract term stretched, because the landlord financing a data hall needs a tenant commitment long enough to support the debt. TeraWulf, for example, describes its contracted revenue as sitting on leases of 10 to 20 years (TeraWulf Q3 2026 investor release). And the technology inside the contract now refreshes faster than the contract runs, which means the buyer is committing to a price for a capability that will be superseded inside the term.

Those three shifts are why the structure matters more than the rate card. The rate card tells you what a unit costs today. The structure tells you who pays when something goes wrong in year four.

Key takeaway. Capacity is now a capital commitment with an operating cost attached, not the other way around. Finance should own the structure and engineering should own the specification.

Structure one: the powered shell

In a powered-shell lease, the buyer takes space, power and cooling from a data-centre landlord and installs its own equipment. The landlord builds the building, secures the utility service, and hands over halls on a delivery schedule. The tenant funds the compute.

This is the structure most people misread. When a press release reports a multi-billion-dollar AI data-centre deal, the number is usually rent summed across the full term, not the cost of the building. The two are different orders of magnitude. At TeraWulf's Hawesville campus, the landlord estimated construction of the buildings and site infrastructure at $3.5 billion to $4.0 billion in its state energy filing, while the tenant, Anthropic, was to fund the compute infrastructure itself at a cost of approximately $10 billion.

What the buyer carries: technology risk in full, and delivery risk in phases. Rent usually begins on delivery of each hall rather than at financial close, and the credit support standing behind the tenant may only attach at the final hall of each lease (TeraWulf Form 8-K, Nov. 4, 2026).

What the buyer does not carry: construction cost overruns, provided the EPC contract is structured with a cap. Where the contractor's exposure ends, the owner's begins, and the buyer should know where that line sits because a squeeze there becomes a schedule slip.

Best fit: organisations that intend to run their own clusters, have the engineering bench to specify and operate them, and can absorb a two-quarter delay without losing the business case.

Structure two: managed capacity

Here the provider owns the hardware and sells the buyer a service level over it. The buyer's commitment is usually expressed as reserved capacity - a number of GPU-hours, a throughput floor, a maximum latency - at a contracted price, with the provider responsible for refresh.

What the buyer carries: counterparty concentration, and the risk that the service level is written in a unit that does not match how the workload actually consumes capacity. A commitment denominated in GPU-hours is not the same as one denominated in tokens served or jobs completed, and the difference becomes visible exactly when utilisation is uneven.

What the buyer does not carry: hardware obsolescence and the operational burden of the cluster. That is worth real money, and it is the reason managed capacity usually looks expensive per unit and cheap per unit of risk transferred.

The test to apply: ask what happens at the refresh boundary. If the provider is obliged to deliver the next generation at the same price, the buyer has bought protection. If the contract is silent, the buyer has bought today's hardware at a fixed price and will pay again to stay current.

Structure three: reserved cloud commitment

The buyer commits to a spend level over one to three years in exchange for a discount, and draws against it as needed. The commitment is financial rather than physical: no hall, no racks, no delivery schedule.

What the buyer carries: take-or-pay risk on the committed spend and exposure to the provider's own capacity constraints. A commitment is only worth the discount if the capacity is actually available when the workload arrives, and availability during a supply crunch is a commercial negotiation, not a technical one.

What the buyer does not carry: any of the capital risk of the build. This is the lightest structure on the balance sheet and the least useful for workloads with predictable, sustained, high-utilisation demand for a single hardware generation.

The test to apply: model the commitment against the bottom decile of your own demand forecast, not the middle. Commitments are priced for the average and paid for at the trough.

The three structures side by side

The table is a starting point, not a verdict. The mistake to avoid is choosing a structure because its rate card is lowest. A powered shell at a low rate with an uncapped overrun exposure and a ten-year exit price is a worse commitment than a managed service at a premium with a clean refresh obligation.

Six figures to have before you sign

1. Total obligation by year, undiscounted, for the full term including renewal options.
2. The exit price in each year, and the notice period attached to it.
3. Capacity by delivery date, hall by hall, with the service-credit trigger tied to the scheduled date rather than the actual one.
4. The pass-through list: power, utility capacity charges, taxes, maintenance, and anything else the provider can move to the buyer. Pass-throughs are where fixed-price contracts stop being fixed.
5. The utilisation assumption behind the business case, and the cost of the commitment at 60% of it.
6. The refresh obligation, whoever carries it, with the price mechanism named.

Key takeaway. A capacity contract is only as good as its exit. Price the exit before you price the capacity.

Glossary

Critical IT capacity. The electrical load available to the computing equipment itself, excluding cooling and losses. It is the number providers quote and the number that determines how much work a hall can do.

Commencement date. The date a lease obligation begins. In phased builds it can differ by hall, which means one contract can have several commencement dates and several risk start points.

EPC contract. Engineering, procurement and construction. A single contract under which one contractor delivers a facility to a specification, often on a guaranteed maximum price basis with a defined overrun-sharing mechanism.

Guaranteed maximum price (GMP). A contract form in which the contractor's price cannot exceed an agreed ceiling for a defined scope, with any overrun above the ceiling allocated according to the contract.

Take-or-pay. A commitment to pay for a quantity whether or not it is used.

Remaining performance obligations (RPO). The contracted revenue not yet recognised. It is the number providers use to show the size of their backlog, and it is the closest public proxy for how much capacity has already been sold forward.

Next section: the diligence request list - the eight documents that answer the six questions above, and what a good answer looks like.

Sources: Oracle Corp., Q1 fiscal 2027 results release, Sept. 10, 2026; TeraWulf Inc., Form 8-K, Nov. 4, 2026, and Q3 2026 investor release, Nov. 6, 2026; TeraWulf subsidiary energy plan filed with the Kentucky Energy and Environment Cabinet, Aug. and Sept. 2026; Fluor Corp., contract award release, Nov. 4, 2026. All figures are quoted as published; the framework and the comparison table are the author's own.