There’s a reason I’m starting with this, as it’s just as relevant in data centers; as there’s a huge amount of them running the same system which underpins the functioning of an entire portfolio. We call it BMS (Building Management System) and EPMS (Electrical Power Monitoring System) – think of it as the central brain that controls all of the electrical power and mechanical cooling systems in data centers. The company behind the dominant version of that idea is Tridium, and the product is called Niagara. It’s been sold for twenty years as the solution that solved vendor lock-in in building controls, and nearly every operator uses it. It’s the data-center-adjacent example which is a prime target for a scorched earth attack.

Take that out, and the whole system collapses.

Open And Shut

Before Niagara, buying a building management system meant marrying a vendor. Honeywell, Siemens, Johnson Controls; whoever you picked, every device and every future upgrade had to come from them, because their system couldn’t talk to anyone else’s. Want to switch suppliers later? You couldn’t, not without ripping the whole installation out. That’s the problem Niagara solved; it sits above the hardware and normalizes everything, BACnet, Modbus, LonWorks, whatever protocol a given chiller or VFD happens to speak, into one internal format it can read consistently. A facilities team could suddenly mix vendors freely and still run one singular and unified dashboard which covers all of their different equipment..

Its popularity and rate of adoption is a case in point of the industry’s continued desire for (and subsequent reliance on) it. It’s vast deployment has created a huge systemic risk though; funnily enough, their solution didn’t remove the vendor lock-in, it just moved it up a layer, from the hardware manufacturers onto themselves.

What this is to suggest, is that you’re no longer married to one hardware vendor, but you are now married to Tridium. Ironically, Tridium was bought by one of the hardware manufacturers (Honeywell) in 2005. I’ve always thought the marketing of it as a bit of smoke-and-mirrors -it’s marketed as being an “open model”, but if you sign up, you’re actually running their licensed, closed codebase that’s just very good at behaving like an open one. Ask a facilities engineer what “open protocol” means in Niagara and they’ll talk you through BACnet compliance. Ask what happens if Tridium ships a bad update to the framework itself, and the conversation usually stalls, because it’s doesn’t seem to be a topic that’s been particularly well interrogated.

It should be. Niagara isn’t just a niche product, it’s the default supervisory layer across a huge share of commercial buildings, data centers, hospitals and manufacturing plants worldwide.I understand the engineering mindset behind it, but in reality it’s a pure definition of exposure – and comes back to our scorched earth argument from the beginning.

If someone wanted to take down the world, just take down Tridium or Niagara.There’s no data in specific on it, but it’s rumoured that nearly every hyperscaler uses it – which is effectively nearly the whole market share. And that’s not even considering the other infrastructure that also deploy it widely.

Falcon Down, Then What

We’ve already run this experiment once, just not in buildings. In July 2024, a bad update pushed automatically to CrowdStrike Falcon, a security tool sitting on millions of Windows machines, that brought a huge slice of global IT to a standstill within hours. Airlines grounded flights. Hospitals cancelled procedures. Delta later sued CrowdStrike, whose defence was essentially that Delta’s own infrastructure was too brittle to recover fast, which is itself an admission of that brittleness absolutely exists in deployments at scale like this. Analysts have called this a digital monoculture problem ever since: when enough of the world standardises on the same software, a single flaw doesn’t stay contained, it cascades.

Now translate that into physical infrastructure. The same event inside a BMS framework running mechanical and electrical control across thousadns of buildings doesn’t lock just anyone out of a dashboard- it potentially throws chillers, transfer switches and generators into an undefined state, all at once. We got a small, contained taste of the physical version in May 2026, when a cooling fault in a single AWS data center hall triggered automatic thermal shutdowns and took the better part of a day to fully recover, with knock-on effects hitting trading platforms and betting apps mid-event. That was one hall, and one mechanical fault; and ironically, nothing to do with the control software itself. Multiply that by a bad Niagara update, or a cyberattack on it and you could be looking at a physical, global outage with cooling and power as the failure mode, instead of just a login screen.

I’m not saying this is imminent, and I have no knowledge whatsoever on the security standards of Niagara – it’d be fairly safe to assume that it’s taken very seriously and monitored very closely. But I am saying the industry seem to have spent two decades optimising for interoperability, and comparatively little time asking what happens when the interoperability layer itself becomes the single point of failure.

Building Your Own Backbone

So if we continue with AWS…what’s the alternative for an operator with their scale and AWS’s incentives? Basically, build your own. Not necessarily because Niagara is badly engineered, but because creating something proprietary drops your risk exposure to a fraction of your competitors if done correctly.

This isn’t hypothetical for Amazon specifically. Every article briefly discussing AWS data center controls describes a similar architecture: a BMS controlling mechanical systems, an EPMS monitoring electrical ones, both talking to field devices over a mix of open and proprietary protocols, all fed back into two centralized operations centers in Virginia watching every AWS facility on earth 24/7. They’re already a company that treats control infrastructure the way it treats servers and networking: build it yourself rather than buy it off the shelf, because at this scale the economics and the risk profile both favour ownership.

But for the others, what would it take? Four things, roughly:

• A protocol abstraction layer that talks natively to BACnet, Modbus, proprietary chiller comms and whatever a given generator manufacturer decided to invent, without depending on a third party’s driver library.

• In-house controls engineering talent - annd talented enough to build and patch that layer itself. Arguably, that’s the expensive, scarce part, not the licensing.

• Full ownership of the patch pipeline, so a firmware or framework change only gets pushed out once your own team has tested it against your own fleet and system sandboxes.

• And finally -a commitment to carrying that cost indefinitely. The entire appeal of a shared framework like Niagara is that someone else is continually absorbing the maintenance burden; but if you give that up and you’re absorbing it forever.

I’ll caveat that none of that is going to be cheap to make. But cheap was never really the question; the question is whether concentrating control of a multi-billion DC portfolio to one external vendor is a risk worth trading for their licence fee (no public figures exist for the cost of Niagara licences – I’d assume millions, but could be more or less than that in practice).

Different Dialects, Same Room

We should be a little careful though, as the “just build it yourself” argument disintegrates if you don’t think it through properly. Building a proprietary control layer doesn’t automatically make you safer. If you build one homogeneous system to replace Niagara, you’ve built a smaller monoculture with your own name on the licence. And especially if it’s not comparable to Niagara…if it’s a weaker product, it could be more susceptible to cyberattacks.

The alternative is deliberate heterogeneity: different manufacturers, different protocol dialects, different underlying system architectures kept properly distinct across the fleet, so a vulnerability or bad patch hitting one hall doesn’t have a clean path to every other hall on earth. Whether you build proprietary or stay on Niagara isn’t really the question worth arguing over; how much diversity survives underneath the surface is. An attacker or a bad update that compromises one control path shouldn’t result in them getting the keys to the whole portfolio.

The hard part is what that demands of the software sitting above it. It has to be completely indifferent to what it’s talking to underneath, normalising a dozen manufacturers’ quirks and comms standards into one identical operator experience, so whoever’s watching the dashboard in Herndon sees the same clean interface regardless of which vendor’s equipment is in the installation. That’s a harder problem than the one Niagara solves, because Niagara optimises for convenience; this version has to optimise for containment, preserving diversity at the control layer while erasing it entirely at the interface layer. Get that right and you keep the resilience of a fragmented fleet without asking your operations team to learn five different systems. But if you fail at that, you’ve just added complexity without adding safety, which is probably worse than doing nothing at all.

It can be done though; CANbus has been used on a lot of industrial and agricultural machinery for many years. Each machinery manfufacturer produces their own products and solutions, but the CANbus interface means they can all communicate flawlessly between each other. Sure, it had its teething problems, but no doubt there’s some parallels to the modbus used in DC installations.

It’s not necessarily straightforward, but it can be done – we also standardised USB and Ethernet cables and connectors to work between manufacturers, so there’s no reason the same rationale can’t be applied to the electrical and mechanical systems. It just takes some cooperation between manufacturers and the industry working towards a common goal.

The Robot In The Room

There is a final argument that the risk that seems to be here may be very shortlived; as soon, the BMS and EPMS may just be rolled into a singular SCADA system.

Robotics is moving into data center operations fast: with testing and deployment of autonomous inspection robots doing thermal patrols, automated guided vehicles moving server racks, early deployment of robotic arms for hardware installation and cable management. The market forecasts for the continued rollout aren’t modest. If physical maintenance increasingly gets handled by robots rather than people, those robots need something to coordinate against: a control brain that’s fast, consistent and predictable across the whole estate. That points in exactly the opposite direction from everything I’ve argued. It points toward tighter integration, not more diversity. So is a diversified, deliberately fragmented control layer a properly resilient design, or a transitional idea autonomy is about to make obsolete? I don’t think that’s settled yet.

A few facts remain for now:

• Niagara’s dominance is a real concentration risk, not a hypothetical one; the CrowdStrike outage is the proof of concept, just aimed at the wrong industry so far.

• Building proprietary doesn’t solve anything on its own, it only helps if the replacement is deliberately heterogeneous rather than a second monoculture thats rebranded.

• The uniform-interface problem is the actual engineering challenge: diversity underneath, with an identical front-end user experience on top.

• Robotics could make this whole debate moot within a decade, and maybe much sooner than that

TH

Share

Find me on Linkedin

This is because National Grid can’t energise the Margam connection in time; a new 275kV gas-insulated substation, a second 275kV substation inside the steelworks, supergrid transformers and two kilometres of underground cable, all for one furnace.

That’s going to be a lot of power. Meanwhile, in tandem, there’s 50GW or so of data centre demand now sat in the UK connection queue, stuck in the same bottleneck.

Both are enormous loads, and are actually more similar than different. Both need electricity, and lots of it. But more importantly, both demands swing violently – the energy demand to get the furnace up to temperature requires monolithic amounts of energy. But once it’s up to temperature, that demand tails off. Same with AI loads – training loads are those which get the headlines about colossal energy consumption. Inference loads are still not insignificant, but are considerably less.

And yet still, both are asking for their buckets of power to be served by an ancient network built for a few kettles and some street lighting.

The difference is that steelmaking has a century of experience behind it, and the other is currently improvising.

So this is my argument for today; AI training loads are electric arc furnaces. Not loosely, nor metaphorically; in the specific electrical sense that matters to a grid planner. Thousands of GPUs run the same training iteration in lockstep, so compute-heavy and communication-heavy phases alternate across the whole cluster at once, and the site’s draw slams up and down by tens of megawatts in under a second.

That’s basically the same definition of a furnace. But steelmakers have already grappled with this issue. And they’ve written the maths down, put it in an international standard, and made the fix a condition of connection.

This isn’t the first time I’ve used a parallel universe to give a bit of data centre insight, so I may as well stay on-brand. Probably going to be full of flaws and plenty of holes in the argument – but nothing better seems to be getting suggested, so let’s run the steel protocol forwards and see what number falls out. I’ll carry one example the whole way through the rest of it: a generic 100MW AI-training hall.

Bore-in, bore-out

A modern arc furnace is 100 to 150MVA of transformer feeding three graphite electrodes into a bucket of cold scrap. During the bore-in phase, as the electrodes cut down through the pile, the arc strikes, collapses, re-strikes and wanders. The load goes from something close to a short circuit to something close to an open circuit, and back, continuously. The characteristic frequency content of that thrashing sits at roughly 4 to 14Hz.

That band is not a coincidence in the history of this problem. The human eye’s sensitivity to modulated light peaks at around 8.8Hz, and at that frequency you can perceive brightness modulation of well under half a percent. So when steelworks scaled up in the early twentieth century, the complaint that landed wasn’t from a systems engineer, btu from people whose lights were pulsing in their homes. Funnily enough, the entire discipline is still called “flicker” because of it.

The steel industry built a that tied to the strength of the connection, and published it. IEC 61000-3-7 gives the working relationship for a furnace’s flicker emission at the point of common coupling:

Pst is short-term flicker severity, where 1.0 is roughly the threshold of irritation for a typical observer. S_load is the furnace rating. S_sc is the short-circuit power available at the point of common coupling, which is the honest measure of how stiff your connection is. Kst is an empirical fudge factor that generally summarises how badly a given furnace actually thrashes; the standard puts it between 48 and 85 depending on the nature, weight and density of the scrap you’re melting, with 58 to 70 recommended for estimating (and 85 used for stainless).

Rearrange it against a planning level of Pst = 0.9 and you get the connection rule that has governed steel siting for decades:

Sorry if you’re lost already (I had to read it about 10 times aswell, and I’m still barely grasping it…) so just fixate on this bit:

Your connection point needs somewhere between fifty and a hundred times more short-circuit power than your furnace has rating.

As I understand it, this is the whole reason Port Talbot it getting its own 275kV substation instead of just a feeder off the local network.

Stiff competition

I’m sure every steelworks electrical engineer in the industry knows their short-circuit ratio. Strangely though, I have never once seen a data centre planning document mention it. We talk about MW, we talk about PUE, we’ve started talking about WUE (I’ve got my own thoughts on that here), and we discuss critical load as though a megawatt were a megawatt (I’ve explained more nuance of this definition in turning crypto mines into data centres here).

This is basically suggesting that most planners treat the the strength of the network behind the meter as someone else’s problem that won’t affect them.

As I’m completely playing with this concept, if we invert the steel rules - it becomes a headroom allowance instead of a limit. If a fluctuating load can sit at up to about 1.5% of the short-circuit power at its connection point before it becomes a nuisance (which is what Pst = 0.9 with Kst = 60 works out to), then a site’s free allowance is:

ΔP_allow = ε × S_sc, with ε ≈ 1.5%

[Note, that transposition is mine rather than the standard’s – my maths could be crap, so double check it…]

My understanding is that Kst is usuakky calibrated on furnaces whose swing is roughly their own rating, so using it as though S_load were the swing amplitude is fair for a furnace; but probably needs checking for anything else. But that’s more of a design heuristic, not a compliance calculation.

It still gives you something the data centre industry doesn’t currently have: a defensible answer to “how much am I allowed to wobble”, set by the physics of the connection rather than by whatever the utility feels like writing into the agreement that week.

We come back to the same argument, and the same ‘flicker’ phenomenon – doesn’t matter what the agreement says; if people’s lights start flickering, then you’ve got to do something about it. And by that point, all of your investment has been made into something which now may need to be restricted or curtailed.

Reactive measures

The voltage disturbance a fluctuating load creates is approximately (ΔP·R + ΔQ·X)/V². On a high-voltage network, reactance dominates resistance by a wide margin, so the term that does the damage is ΔQ; the reactive swing. And an arc furnace’s disturbance is overwhelmingly reactive, because what’s changing is the impedance of the arc itself.

Which is why the steel industry’s solution is so cheap. A static VAr compensator, or a modern STATCOM, injects and absorbs reactive power in opposition to the furnace. The first commercial one went in back in 1964, using a saturated reactor to stop lamps flickering; thyristor control arrived in the 1970s and the technology has been routine ever since. Crucially, a STATCOM isn’t storing energy in any meaningful quantity. As I understand it, it’s basically shuffling phase. The DC capacitor inside it is small because reactive power doesn’t have to come from anywhere; you can conjure VArs out of switching.

So this is the data centre parallel challenge, and where my metaphor’s holes start to appear -because you cannot ‘conjure’ watts.

A data centre’s power supplies are power-factor corrected to around 0.99. When a training cluster drops out of its compute phase, what disappears is real power. There is no compensator that can fix that, because those joules have to come from somewhere physical.

So we’ve got to be careful about what we steal from steel (I’ve been waiting all article to use that one…):

Steel gives us the metric, the standard, the siting rule and the commercial model; but sadly, withholds the entire thing that made it all affordable.

There’s a second, and probably more impending problem. Arc furnaces thrash at 4 to 14Hz. AI training, according to the NVIDIA, Microsoft and OpenAI power stabilisation paper, has its FFT energy concentrated between 0.2 and 3Hz. That’s below the eye’s sensitivity peak, so the lights effectively barely move (hence you won’t see the ‘flicker’). It is also, precisely, the electromechanical band: below 1Hz you’re in the natural modes of long transmission lines, and 1 to 2.5Hz is where closely coupled generating plant oscillates against itself. The paper’s authors are blunt about the risk of exciting turbine-generator shaft torsional modes and sub-synchronous resonance, and cite a 2019 Florida event in which a single unstable combined-cycle unit set the system ringing with a driving magnitude of around 200MW.

A gigawatt of synchronised training load is five times that amount, and all happening at a frequency the eye can’t see and the shaft can feel.

So in simple terms: if there was a problem with steelmaking, you saw it or heard it. With AI equipment, you can’t. So by the time a problem is realized, it’s probably too late and your equipment and infrastructure has destroyed itself.

Joules in the crown

But back to the useful stuff we could use. To ensure our AI stuff doesn’t destroy itself, we can do the thing that steelmakers also do – factor in a buffer.

The buffering requirement has to be denominated in energy, and the derivation is simpler than it looks.

Model the iteration ripple as a sinusoid of peak-to-peak amplitude, ΔP at frequency, f. Integrate over the half cycle in which the load sits above its mean and you get ΔP/2πf, which is the energy the buffer has to hold. Subtract the amplitude the grid will accept for free, divide by round-trip efficiency, and you have it: (I’m fully aware that derivation wasn’t simple, I had to dig out my A-Level maths textbook to remind myself how to integrate).

Normalise by site load and the result is more elegant than I expected. With α as the swing depth as a fraction of load, and SCR as the short-circuit ratio:

The buffering requirement per MW of training load has units of seconds – the good thing about that, is that it makes it directly comparable to the ride-through figure every UPS in a data centre building is already specified against. So that means it’s a number that a facilities engineer, an electrical engineer and a utility repr4esentative can all argue about in the same room.

If we go back to our example, and run our 100MW hall through it:

Swing depth α = 0.30 (NVIDIA’s own smoothing work quotes a 30% reduction in peak grid demand, so that’s a fair centre of the range).

Connection at short-circuit ratio 8, a realistic weak-ish 132kV position. ε = 1.5%.

Frequency 1Hz, the middle of the published band.

Round-trip efficiency 0.9.

Plugging in some more numbers revealed something I didn’t expect to work: NVIDIA’s GB300 NVL72 power shelves carry 65 joules of electrolytic capacitance per GPU, 72 GPUs to a rack, in a rack drawing about 132kW. That’s 35kJ per MW. My steel-derived rule says 32.

I’ll caveat about how much weight that figure should carry in my argument. I took f from the middle of a published band and α from NVIDIA’s own headline figure, so the check isn’t independent, and the sensitivity is quite brutal: at the 0.2Hz end the requirement is five times larger, at 3Hz it’s a third. A capacitor bank sized like NVIDIA’s is right for the fast end of the spectrum and short for the slow end.

Note also what the ε·SCR term does. Take the same example hall to a connection with a short-circuit ratio of 20 and the allowance swallows the entire swing; the storage requirement goes to zero. Grid stiffness and stored energy are substitutes.

So in simpler terms: you can buy your buffer in copper, or you can buy it in joules.

Ramp and circumstance

The capacitors solve the ripple. But they do nothing whatsoever about the other problem, which is what happens when something starts, stops, checkpoints or loses a node, and 100MW appears or vanishes as a step.

Usually, most utilities companies don’t regulate that with a spectrum. They regulate it with a ramp rate, in MW per minute, written into the connection agreement. If your load steps by ΔP and the network will only follow you at R, the deficit decays linearly and the energy you have to cover is:

At a permitted 10MW/min, a 100MW step needs 9.3MWh. That’s 93kWh per MW, against 32 kilojoules per MW for the ripple. Ten thousand times.

Both numbers seem a bit intimidating, but are still completely buildable. 9.3MWh is a handful of Megapacks and an unremarkable line in a £500m large compute or hyperscale project.

But they are different machines, on different balance sheets, with different failure modes, and treating them as one procurement is how you end up with the situation Bloomberg reported earlier this month: batteries installed for stabilisation duty being replaced within weeks because they’re being cycled at a rate nothing in their warranty anticipated. A battery asked to chase a 1Hz ripple will destroy itself. But a capacitor asked to cover a two-minute ramp is9n’t even in the right order of magnitude.

What the steel industry actually knew, and what it can teach us

The transferable insight isn’t the implementation of the STATCOM, but probably more about the paperwork and the discussions about what it’ll actually do under load (before it’s built).

When a furnace applies to connect, it declares its Kst, its rating and the short-circuit power at its proposed connection point, and the network operator checks the arithmetic against a published planning level and says yes or no. The applicant pays for its own compensation. Everyone knows the number before tany capital is committed.

A data centre connection application often only declares megawatts, and that’s the whole disclosure. Given that the load in question can move a third of that figure in under a second, in a frequency band that talks directly to turbine shafts, this initially suggests to be an odd place to have stopped asking questions.

If I were redesigning the application form I’d want two more fields on it: swing depth as a fraction of contracted load, and the frequency band that swing occupies. Everything above falls out of those two, and neither is hard to measure; the operators already hold the telemetry, which is how the NVIDIA and Microsoft paper got written in the first place.

I’ll accept the limits of all this, as I’m sure I[‘ve butchered the theory with a lot of oversimplification. My ε transposition wants testing against real emission data before anyone puts it in a contract or quotes it verbatim. Swing depth and frequency vary enormously with model architecture, parallelism strategy and cluster size, and they’ll keep moving as training methods change; inference behaves nothing like this. A formula that assumes a clean sinusoid is also being very generous about a signal that is, in practice, a mess.

Behind the theory is a more stark reality, and one which may need to be thought about more if the country decides to re-industrialise. If we take Port Talbot’s furnace and our hypothetical AI training hall down the road - they’ll eventually approach the utility operator asking ffor the same favour. One of them will arrive with its homework done, its compensation costed and a hundred years of standards behind the number. The other will arrive with a megawatt figure and a smile.

And in that situation, I know which one I’d connect first.

TH

Share

Find me on Linkedin

There’s the counter-argument too; a lot of operators are generally aggressively pursing on-site generation as an alternative. But, there’ll also come a point where possibly not all of that energy will be utilized on the data center site – in which case, it may be better generated and redistributed back throughout the grid. So there’s still an argument that we still need to get power from the data centers to the rest of the community, even if they’re generating it themselves.

We could try a deliver a new scheme to cover the entirety of the country with new cabling – engage with landowners, dig some trenches, and lay some new cables. However, we’re not very good at that delivery of large scale infrastructure projects cough HS2 cough.

That’s the modern summation of our ‘track’ record, and it’s something we utterly failed at. So multi-stakeholder engagement isn’t going to be the way around getting something delivered in a timely manner. But rail infrastructure does provide a line of thought worth considering.

Whilst everyone stares at the connection queue, wondering how long it’ll take to get power from the station to the site, we’re ignoring a linear asset that already runs to every major city and most of the towns in between; that’s fenced, secured, surveyed and owned by a single organisation; and that was purpose-built for moving heavy materials long distances. The railway. Half the hard work of any linear build is assembling the route, and the Victorians finished that job for us over a century ago. My argument here is simple: the rail corridor should become the default route for the fibre and power cabling this country desperately needs, and the railway itself should be the machine that delivers it.

The route of the problem

The engineering of burying a cable is well understood; the hard part is the route. A new overhead line or buried circuit crossing open country negotiates with every landowner, tenant farmer, and occupier along its length. Each one gets consultation rounds, access agreements, compensation negotiations, and mitigation works. I’ve represented clients with National Grid lines passing over their land, and I’ve seen how slow that process works from the other side; consultation and scheme delivery run on timescales that would embarrass a medieval cathedral builder, and that’s with a statutory undertaker holding compulsory purchase powers. Multiply one slow negotiation by several hundred ownerships per route and you understand why new transmission schemes take a decade before a spade touches soil.

Now run the same exercise along a railway. One landowner, end to end. Network Rail holds roughly 52,000 hectares, and, from my own experience of dealing with them, its in-house property and surveying teams are set up for exactly this kind of transaction; they deal with wayleaves, easements and boundary matters as business-as-usual, and they’re straightforward to work with. One counterparty means one negotiation, one access regime, one fixed price per metre; no severance claims, no crop loss schedules, no ransom strips. The corridor is already fenced and secure, so the only people near your cable are contractors who are already safety-trained to be there.

The permanent way to do it

None of this is a novel fantasy; it’s arguably the oldest trick in telecoms. The Victorian telegraph ran beside the tracks because the railway was the only assembled corridor in existence. Sprint is literally an acronym: Southern Pacific Railroad Internal Network Telecommunications. The railroad laid around 15,000 miles of fibre along its own right-of-way in the late 1980s, using its own construction train to do it. And in the US today, the SOO Green HVDC Link is a 350-mile, 2,100MW buried transmission line routed 90% inside a single railroad’s corridor, structured that way specifically to avoid negotiating easements with hundreds of landowners. The trench is about a metre wide. That’s a gigawatt-scale power line in a slot narrower than a garden path.

Britain has started down this road for the fibre half. Project Reach, signed in June 2025, sees Neos Networks deploying 1,000km of high-count fibre along the East Coast Main Line, Chiltern, and parts of the West Coast and Great Western routes, explicitly to connect business hubs, data centres and subsea landing stations, with ambitions beyond 5,000km. Network Rail Telecom already operates close to 20,000km of fibre; apparently the third largest network in the country. So the question isn’t whether the corridor works for cabling. It demonstrably does. The question is why we’re only using it for the easy half.

Power is the unfinished business, and I’ll be honest about the limits before anyone else points them out. A rail wayleave solves routing; it does not solve grid capacity. If your scheme needs a transmission connection, you’re still in the queue, and no amount of Victorian earthworks changes that. Where the corridor earns its keep is everything the queue doesn’t cover: private-wire links running from generation sites directly to data centre campuses, distribution-level connections, and the interconnection of smaller meshed sites of exactly the kind I argued for in previous articles. SOO Green proves the engineering; so that just leaves the commercial logic to be implemented.

Night mail, new tricks

The railway also has a second distinct advantage – it’s got it’s own integrated construction system. Any other linear project has to build its own logistics: haul roads, laydown areas, with hundreds of aggregate lorries driving through villages (that after a week, absolutely hate you and everything you’re building). But in this case, the railway is the logistics. Cable drums, ducting and backfill aggregates arrive by engineering train; spoil leaves the same way. Sprint’s construction train proved this model forty years ago; nothing about it has dated.

1. The workflow already exists. Network Rail runs continuous repair and upgrade works every week of the year; possessions, isolations, and night working are standard operating procedure, not an exotic request. From what I’ve seen of how they work, plugging a trenching programme into that machinery is a feasible extension of business-as-usual, not a new discipline.

2. The clock runs at night. Lineside works can run during engineering hours and overnight possessions, 24/7 where the programme demands it, without touching the timetable. Try getting a wayleave that lets you work through the night across any other private land. Properties are typically build away from most of the railway network, so much of the other stakeholder gripes are already addressed by design and location.

3. A trencher eats linear metres. A specialist rail-mounted or lineside trencher working an unobstructed corridor should achieve a daily metreage that open-country schemes, with their access constraints and reinstatement obligations, can’t even begin to touch. Add that to the additional capacity of engineering trains over lorries, and thousands of meters of cabling could be laid every night. This could be a scheme that could be delivered in record time compared to other recent British attempts.

I should probably temper the estate-agent gloss, because I’ll accept that the railway corridor is less generous than the map can sometime suggest. The boundary can be narrow and fragmented, depending on the railway section itself; cuttings, embankments and structures can eat into the width, and those can be congested with existing signalling and telecoms troughing. Scanning and detection of existing infrastructure that’s installed will nbeed to be on point.

That level of asset protection is a real regime with real costs, too: roughly 20 weeks of notice, and the applicant pays for everything including the safety staff watching you work. One landlord, yes; but a demanding one with a railway to run. Rather than pretending that friction away, it just needs to be systemized – there’ll be a few teething problems for the first part of the scheme; but thereafter, it should be just be a procedural rinse and repeat. 20 weeks isn’t necessarily fast; but still significantly faster than a currently quoted 2033 connection date via other means.

Ghost stations, live wires

There’s another final piece of potential in this scheme - the Beeching era left the network littered with closed stations, redundant goods yards and disused sidings; parcels of railway land sitting next to a live corridor, many with hardstanding, road access and a community that stopped noticing them decades ago. These are natural homes for the nodes a cable network needs: connection compounds, battery storage, and substations serving both the railway and whatever the corridor now feeds. The government has already gestured at this, announcing plans in April 2026 to squeeze 10GW of renewable capacity from public land, railway land included, and commentators have pointed out that fragmented lineside plots suit battery storage far better than they suit anything else.

Another caveat before anyone gets too carried away: I’m aware that a node site doesn’t conjure the kit that goes on it. I’m aware that even if we roll out a whole new set of cabling in record time, Power transformers are running lead times of 128 weeks and up, and switchgear is effectively sold out through 2028, so repurposed goods yards join the same procurement queue as everyone else. But land with grid adjacency, road access and a single public landlord is precisely the land that queue-jumps every other part of the development process; the transformer arrives no faster, but everything that usually waits for the transformer is already done. Think of this as an efficient way to build out the infrastructure in parallel; we can’t connect the transformer until the cabling is laid anyway – so it makes sense to put the cabling in whilst we’re waiting for the transformers to be bui;lt.

Two hundred years ago we built the railway to move coal to where the work was. We’ve still got the same issue, and the same macro-requirement, but work is different now: it’s compute, running on electrons and photons rather than steam. But fundamentally the corridor is the same corridor; and it’s sitting there, fenced, and connected to everywhere that matters – and it makes far more sense to me to utilize that rather than we queuing politely for permission to dig up fresh ground with far more blockers in the way.

I also accept the hard version of this argument; bulk transmission by rail corridor, needs National Grid, Ofgem and Network Rail in a room agreeing things which historically regulators are slow to agree. The soft version needs a wayleave, a trencher, and a fixed price per metre. But we’ve already done it with fibre optics, so now it’s just a case of replicating it with power.

TH

Share

Find me on Linkedin

Months later, in March 2026, Dawsongroup bought the world’s first JCB hydrogen generator and put it straight to work as standby power for a data centre customer.

That’s a strange dichotomy - a data centre killed Britain’s flagship hydrogen project, and another became hydrogen’s first paying generator customer.

If you build, operate or finance data centres, both sides of that story are equally as relevant. Every operator is sitting in a grid connection queue that now exceeds 100 GW against a national peak demand of about 45 GW; and nearly every operator runs a diesel standby fleet it’s under pressure to decarbonize.

Hydrogen gets pitched at both problems constantly, but never quite makes it onto the asset register.

The Teesside winter tells an interesting tale here: Hydrogen’s fate was never going to be decided by its own price tag; it’s decided by the price of the thing it replaces.

Judged against that test, the technology is in better shape than its critics claim, but equally is in far worse shape than its strategy documents assume.

Standby Me

The JCB G60RS H is the world’s first production hydrogen genset, and its first buyer was Dawsongroup, who dropped it into a rental fleet alongside 155 diesel units and deployed it on standby duty at a data centre. The design pairs the engine with a battery pack so it only fires at peak or to recharge; effectively a mild hybrid drivetrain (similar to what’s in a lot of modern hybrid vehicles), but ran in reverse. Behind it sits a serious engineering programme: £100m ($130m), a team of around 150 engineers, and in May 2025 the first full EU type approval ever granted to a hydrogen engine in non-road machinery.

What impresses me more than the machine is that the Bamford family has assembled the entire supply chain around it, privately, whilst all attempts of the UK state version never got out of the starting blocks:

• Production. Hygen’s Bradford electrolyser plant (in construction) and Ryze Power’s distribution fleet, both under Jo Bamford’s HydraB group.

• Refuelling. HYKIT, a JCB/HYCAP/HydraB joint venture, whose mobile unit carries 75kg and turns a machine around in fifteen minutes.

• Demand. JCB’s own hydrogen machines, in series production since June, with National Highways contracting 2,500 tonnes for the Lower Thames Crossing to displace twelve million litres of diesel.

• Finance. JCB Finance leasing the kit with a service contract, so no customer carries the residual risk of a novel asset.

That’s a complete miniature hydrogen economy, built by one family, without waiting for an allocation round.

The scale ceiling is rising, too. INNIO, the Austrian engine maker behind the Jenbacher gas engines that already power a 60 MW off-grid plant for a Dublin hyperscale data centre, ran a 3 MW engine on 100% hydrogen in April 2026, tested against the fast, violent load swings that AI training clusters produce. Technical staff from Microsoft, Google and Data4 witnessed it. The people who buy data centre power physically watched a hydrogen engine pass their own test.

So at this point, we can initially conclude Hydrogen’s unpopularity isn’t a technology problem, and the engineers have done some phenomenal work.

The Allocation of Blame

So there’s no professional blame from me; but I will blame policy.

The UK’s first Hydrogen Allocation Round committed £90m ($117m) of capital and over £2bn ($2.6bn) of revenue support to eleven production projects totalling 125 MW. One is operating: GeoPura’s HyMarnham in Nottinghamshire, on the site of a former coal plant, running since January. The second round shortlisted 765 MW in April 2025; fifteen months later the Invite to Offer stage still hadn’t opened, and when asked in the Commons this July whether it would open before year end, the minister answered that the department was “working hard” to start it “as soon as possible”. The refresh of the national Hydrogen Strategy, due autumn 2025, remains unpublished. The Hydrogen to Power business model, the mechanism that would let hydrogen generation actually earn revenue, was promised as operational by 2026; I can’t find any evidence that it exists (there again, I’m just a bloke using Google – but I still haven’t found it after a lot of searching).

Investors have drawn their own conclusions. SSE took a £21.8m ($28m) write-down and paused its hydrogen production projects, citing “material policy delays”. ScottishPower paused two schemes despite having already signed HAR1 funding agreements; they walked away from subsidy they’d won. Hydrogen’s share of global energy venture capital has fallen from 13% to 4% in two years.

Sitting Tenants

The difference is the incumbent. Run hydrogen against the three duty cycles a data centre or construction programme actually buys, and the pattern explains both halves of Teesside.

• Grid-connected prime power: hydrogen loses heavily. The incumbent is industrial electricity at roughly £150–250/MWh ($195–325). Hydrogen through a fuel cell, at the £9.50/kg strike price HAR1 contracted, at current rate is estimated to cost £360–570/MWh ($470–740) in fuel alone. No learning curve fixes this; hydrogen made from electricity can’t undercut the electricity it came from once you’ve lost two thirds of the energy in the round trip. [Caveat: A hydrogen engineer may quote higher on HHV (Higher Heating Value) with generous fuel cell assumptions, but the underlying principle is still the same].

• Fixed standby at a single site: hydrogen loses on capital, not fuel. A standby set runs perhaps fifty hours a year, so expensive fuel barely registers, and anyone waving a £/kg figure at a backup fleet is making a category error. The problem relocates to capital expenditure: on a 100 MW site, illustratively, £276m of fuel cells against £42m of diesels ($359m vs $55m), with no notable fuel saving to claw it back. This is also where Hydrotreated Vegetable Oil already won; a drop-in renewable diesel, 90% of the carbon benefit, same tanks, same engines.

• Off-grid and temporary power: hydrogen wins now. The incumbent is a hired-in diesel set at £400–800/MWh ($520–1,040) all-in, the most expensive electricity routinely bought in Britain. Hydrogen clears that bar today, and the capital objection dissolves because the asset usually lives in a rental fleet, amortised across many sites. This is precisely the Dawsongroup model, and why the first commercial hydrogen genset in the world went to a plant hire company, rather than a utilities provider.

This distills into one pattern, arrived at through three verdicts:

• Hydrogen’s viable territory is wherever the incumbent is most expensive, and the incumbent is the most expensive in the small, mobile, off-grid applications.

• A national strategy built around gigawatt production plants was optimised for the exact end of the market where hydrogen loses.

• My previous article on turbine generation made a related point about buying supply chain position rather than queueing; and it’s a similar point here - the position worth buying is the duty cycle, not the plant.

  ---

Teesside Story

The causation of the failure at H2Teesside was a little more layered and nuanced. Realistically, they had already lost its anchor customer as soon as Sabic closed the Wilton petrochemical cracking plant. Meanwhile, bp had also scrapped its neighbouring green hydrogen scheme months earlier as part of a wider retreat to oil and gas. From a surveying and consultant’s perspective, my read is that the dispute over the land just forced a decision that bp was already minded to make.

But if we dissect it, there were two stated national priorities: AI infrastructure and hydrogen production. They competed for the same 115 acres of the scarcest asset in modern infrastructure: energised, consented, connected land (my previous article covers why that’s currently the real currency).

Dig into the paperwork, and you’ll see that bp argued the two could have coexisted under HSE rules (had the data centre been kept below two storeys); it says its offers to meet were ignored; the council granted permission; and then bp withdrew before ministers ever had to choose. There was no mechanism to arbitrate, no way to price what was being displaced, and so the decision was made by default. A 1.2 GW project producing a tenth of a national target died without anyone in government ever ruling on it.

The incumbent test applies to land too. On that site, the sitting tenant with the better economics was the data centre. In comparison, the competitor hydrogen plant wasn’t even close to matching it.

Scale Model

The limits, stated plainly: off-grid and standby duty is a real market, but it isn’t the hydrogen economy the strategy assumed. A construction programme burns tonnes; while a hyperscale campus can burn tonnes an hour. When Ofgem awarded 7.6 GW of long-duration storage contracts this year, not one went to hydrogen. To add insult to injury, the niche could yet be eaten from below by Hydrotreated Vegetable Oil and batteries.

But Britain is provably good at the part that works. We hold Europe’s first hydrogen engine type approval. We built the first commercial hydrogen genset and sold it into the first data centre. GeoPura built the one production project that runs, and has now agreed a £275m ($358m) sale to a Canadian buyer (a common way how these stories tend to go..!).

The engineers have done their job, but it’s now down to policy to fund the duty cycle that pays, rather than the tonnage that impresses. And it should try and do it before the rest of the working half gets bought by someone with a bit more foresight.

TH

Share

Find me on Linkedin

Film production sorted this out a century ago, without a project-management textbook anywhere in the building.

A film schedule doesn’t start with the story. It starts with the stripboard: one strip per scene, the whole lot shuffled out of script order before a frame is shot. Underneath that sits the sheet worth stealing, the day-out-of-days. Think of it as a film schedule equivalent of a gantt chart – the cast members down the side, shooting days across the top, and a code in each cell:

• SW when an actor starts;

• W when they work;

• WF when they finish; and

• The code the entire discipline hangs on: H, for hold.

Contracted, paid, and doing nothing. Once an actor starts, the production pays them every day until they finish, trailer days included, so the assistant director’s job is to try and minimize the the ‘H’ days out of the expensive rows. The schedule bends around whatever is scarce, immovable and dear: usually an expensive lead actor, booked for twelve days; or a scarce location for a week; or even could be due to only having daylight for a few hours. The script order is irrelevant.

A popular culture example: Peter Jackson shot Rivendell for all three Lord of the Rings films in one block, because Rivendell was the constraint.

As demand pressures increase on components and materials for data centre build-outs, the construction schedules are quickly mimicking this exact shape; but most are planned as though they don’t.

Casting call

In our context, the ‘lead actor’ on a data centre programme is most commonly the energisation date at the time of writing this article. It behaves like a star booked for a twelve-day window: contracted years in advance, on terms you mostly didn’t set, and if you’re not ready when it arrives, your slot in the supply order queue disappears. In the UK our equivalent of the casting market is brutal; operators who filed connection applications back in 2021 are reportedly being handed energisation dates of 2030 and beyond, with something like 50GW of data centre demand sat in the queue; whilst demand-side connections still run first come, first served. And yet open most programme plans and that date appears as one milestone among hundreds; that’s the equivalent of the star’s name being printed in the same font style as the catering order.

It’s nto a perfectly transferrable practice though, as a production signs its constraints before day one;in our example, the twelve days are in the contract and they stay twelve. In the case of large construiction projects such as data centres though, they migrate. Since 2023, the industry’s binding constraint has wandered from the connection queue to transformers, with lead times reportedly stretching towards five years at the worst, to medium-voltage switchgear that’s effectively sold out through 2028; and now, on many programmes, to commissioning labour. Casting the constraint is a question you now must re-ask at every gate, not a decision you laminate as being absolute and immovable. So I suppose the discipline technically transfers; but the permanence doesn’t seem to.

Waiting for the light

Watch a crew at golden hour and you’ll see the theory of constraints performed live. Forty people stand completely idle so that one camera can catch twenty minutes of usable light; that’s technically the right call - because the light is the constraint, but the crew is not. Goldratt formalised this decades later as ‘the drum’: the constraint sets the beat, everything else subordinates to it – so the theory suggests that an hour lost at the bottleneck is an hour lost for the whole system.

The strain arrives in the same breath, though, because a 1st Assistant Director commands everyone on the call sheet, but in relative terms even as a programme manager, you only command a fraction of yours. The Distribution Network Operator’s calendar, the switchgear vendor’s order book, the local authority planning approvals; all of it sits outside your gift. A data centre programme runs for years across developer, utility, contractors, vendors and tenant, and subordination stops dead at your organisational boundary. But everything you do own: the fit-out sequence, procurement, the commissioning booking etc, all paces to the constraint’s beat; everything you don’t own gets a buffer placed in front of it rather than an instruction issued to it. Pharma tech-transfer teams will recognise the shape instantly: the regulator’s calendar is a drum you play to without ever holding the sticks.

Continuity errors

Reordering is where borrowing too much of the methodology could be dangerous though. So we must recognize it’s limitations. On a film, continuity is simply a supervisor with a notebook, which is why shooting the ending in week one costs almost nothing. On a site, continuity is an inspection regime with statutory teeth. Commissioning runs Level 1 to Level 5 in order; you can’t run integrated systems testing on gear that isn’t energised; and safety files don’t shuffle or have any bypass mechaniusm. A serious chunk of the sequence is physics and law, and no clever board rearranges it.

But equally, a flat Gantt hides how much of the remainder is only habit. Switchgear can be committed before design freeze; manufacturers are in effect selling delivery slots now rather than products, and the slot is arguably the real asset. The shell can rise whilst the queue ticks down. Skids and modules can be prefabricated in whatever order suits the factory, which is rarely the order they’re installed; the same instinct I argued for in manufacturing generally. The test to apply to every dependency line on the chart.

Hold everything

So here’s the instrument, with the borrowed parts and the claimed parts kept separate. The theory underneath, constraints, critical chain, drum-buffer-rope, is decades old and already has a construction literature behind it. The novel take is the film sheet itself ported across – so itt should be judged more as a method, not a proof.

We’ll dub it the “programme day-out-of-days”:

1. Cast the constraints. List only the resources that idle the whole programme when they sit still. The effective ‘audition’ question for each: if this waits a day, does the end date move a day? For a 40MW UK build that’s the energisation window, the HV switchgear delivery and the commissioning team. If we’ve really attempting to mimic this method, that should be three to five rows. If you’ve got twelve, you’ve just copied the organisation chart.

2. Draw the sheet. Constraints down the side, months across the top, a film code in each cell: S when the constraint becomes available, W when it’s loaded with real work, H when it’s available and idle, X when two workstreams contend for it at once, B where you’ve deliberately buffered it, F when it’s released. One page. The H and X cells aare effectively displaying the entire finding.

3. Price the hold. A day of lost data centre revenue benchmarks at roughly $10,000 per megawatt (call it £8,000), so a 40MW site with an energised connection and no finished halls is holding at around £320,000 a day. Against that, the cost of keeping the constraint fed, early procurement carrying costs, stored gear, a commissioning team booked ahead and occasionally underused, might run £4,000 a day. That’s an exchange rate of 80:1, and it means you should cheerfully waste the cheap resources to protect the expensive one. A landlord would call an energised shell with no fit-out a void period; so this sheet should indicate a void before it happens.

4. Buffer the drum, not the tasks. Strip the padding scattered through individual task estimates and pool it in front of the constraint rows. This is pure critical chain (and I claim none of it!). The limits come with it: buffer-sizing methods are openly disputed, and in construction some padding is priced risk rather than actual waste. A float ahead of utility witness testing is insurance against a seven-figure re-mobilisation; keep that. Pool the padding that’s only padding for the sake of it.

   

Run the illustrative numbers on our 40MW build and the case makes itself. Flat-Gantt version: fit-out paced by its own internal logic, halls finish three months after the March 2028 energisation slot, and the window holds for roughly ninety days; call it £29 million of H cells that appear on no invoice. Programme day-out-of-days version: switchgear slot bought fourteen months early at perhaps £400,000 in carrying cost, commissioning team retained ahead of need for £350,000, and the window opens loaded. Under £1 million of deliberate, visible waste to avoid £29 million of the invisible kind. There is a caveat that needs to be recognised: that £320,000 a day is an “opportunity number”, mainly resting on demand assumptions. That means that if the demand isn’t there when you energise, theoretically the H cells were cheaper than the hurry. The sheet doesn’t automatically remove that judgement; it’s left for someone to make it in the open.

The martini shot

Film crews call the last set-up of the day the martini shot, because the next glass is at the bar. The industry earned its scheduling discipline the hard way, through a hundred years of paying stars to sit in trailers; meanwhile construction and engineering own the theory shelf, Goldratt and all, and still plan £2 billion programmes as flat lists of equal bars.

The uncomfortable direction of travel is that this gap gets more expensive from here. AI is compressing the flexible parts of every programme I write about, the design hours, the documentation, the engineering rework, whilst doing absolutely nothing for transformer lead times, connection queues or commissioning labour. The immovable constraints are quickly becoming the basis of the whole schedule. So open your programme plan and read it like a call sheet: Find the star; and count the H days. If you can’t see any, they’re not absent; they’re just unpriced, and somebody is likely paying for them anyway.

TH

Share

Find me on Linkedin

These are not companies with different levels of ambition; they’re companies with different businesses, and their shopping lists for land barely overlap. Yet the industry still appraises and markets sites as if there’s a single customer out there called “a hyperscaler”, with a single set of requirements, who’ll pay a single fair price.

Last August I published a valuation methodology to try and bring some rigour to this: the Data Center Valuation Suitability Index. Score a site’s power, fiber, water, size and grid proximity, weight each attribute, produce a number out of ten, tie it to local land value. I stand by the mechanics and the intent of doing so. But as every engineer does, I’ve been tweaking it a bit. Version 1 gave the weights as fixed percentages, and the last year of build-out has been one long demonstration that what I defined as constants were actually much closer to variables. So this is the correction, and the upgrade.

Five buyers, five lists

Watch what each operator actually bought this year, and you can reverse-engineer the list they were shopping from.

Meta is the purest case, because it has no customers buying any share of it’s physical infrastructure. Nobody buys cloud services from Meta; the compute serves its own ads and its own models. If a training run drops for an hour, Meta loses an hour, and no bank’s SLA is breached. That’s why it can live in a tent, and it’s why its flagship Hyperion campus sits in rural Louisiana with ten self-funded gas plants behind it - around 7.5 gigawatts of generation, nearly $11 billion of it, a more than 30% addition to the entire Louisiana grid. Meta doesn’t need a ‘good’ site...or certainly not one with all of the faculties that one of the other hyperscalers need. They can manage with just an enormous empty one, as long as there’s plenty of power on tap.

Google is playing a different game, because its campuses aren’t really individual assets. Its private network lets it pool compute across sites and shift workloads between them, so it buys additions to their portfolio, not just a postcode. Its “power-first” model pairs new campuses with dedicated generation, including a Texas campus with a gigawatt of its own supply and a 933-megawatt gas plant that won’t touch the grid at all [according to the Cleanview report on Crusoe permitting]. And because Google also sells latency-sensitive services to the public, it needs the urban and metro sites that some hyperscalers would never need to bother with.

Oracle seems to barely buy any sites at all. Its flagship AI campus at Abilene is a fifteen-year lease on somebody else’s real estate - 1.2 gigawatts running, hundreds of thousands of GPUs, and as far as I understand it, Oracle doesn’t own the ground under any of it. Its weight vector puts almost everything on speed-to-energize and almost nothing on freehold. At the opposite extreme, it’ll install a full cloud region inside a customer’s own building. Oracle has quietly decoupled the operational component from the real estate -- although I was only writing last week how that comes with it’s own risk.

AWS and Microsoft carry the old obligations. They serve banks, governments and hospitals, so redundancy and physical security is contractual, not optional; a tent would be worthless to them at any price. AWS’s answer was to buy certainty, siting a campus beside an existing nuclear plant. Microsoft’s answer, revealingly, was to stop buying: it walked away from a couple of hundred megawatts of leases and froze around 1.5 gigawatts of its own builds while it worked out what its demand actually looks like. When one buyer is erecting tents in a hurry and another is cancelling leases, it’ss a clear indicator that they’re not valuing the same site the same way.

Underneath all of this sits the split I keep coming back to: training siting is more of a power problem, inference siting is more of a location problem. The market now talks about inference in latency tiers, and a site’s assessment has started to refine from a spectral subjective assessment into a discrete basis of categorisation. But depending on their end use case, the side a buyer is hungry for can drastically change what they’ll pay.

DCVSI 2.0: the subscript

My version 2 is an iterative improvement to factor this in; mathematically it’s only a small change, but I’ll run through it with some illustrative figures. Version 1 said a site’s suitability was:

where Aᵢ are the normalized attribute scores (power, fiber, cooling water, water pressure, size, grid proximity) and wᵢ the fixed weights. Version 2 adds a subscript:

The attributes don’t change; and the weights belong to the buyer, b. Every operator carries its own weight vector, set by its business model, and the vectors are wildly different. Meta’s loads up on power capacity, site size and utility willingness, with latency weighted near zero. A cloud provider’s puts real weight on redundancy potential and metro proximity, because its revenue is contractual uptime. Oracle’s prices time itself; a site that energizes in eighteen months beats a better site that takes four years. Version 2 also needs two attributes that 2026 made impossible to ignore:

• latency proximity to population, owing to the exponential demand growth of the technology; and

• generation headroom, meaning the realistic scope to add dedicated power behind or beside the meter. Critical, bearing in mind the lead times transformers and other electrical infrastructure equipment lead times are at.

The building you end up with is just the weight vector made physical; a tent is a weight vector with nothing on redundancy, but a campus beside a nuclear plant is a weight vector with everything on it. In theory, you could nearly effectively read the buyer’s P&L off the architecture alone.

The max, not the mean

The part I got wrong by omission in my first version was the mispricing from assuming a generic buyer with universal needs.

A generic site score is effectively an average across imagined buyers. But a site doesn’t sell to the average buyer; it sells to its best-fit buyer. Its clearing price is set by the maximum:

That gap between the max and the mean is the mispricing. And that gap is largest for exactly the sites generic scoring punishes hardest; a remote, no-redundancy, power-rich site scores terribly on average - four buyers wouldn’t touch it - and it’s precisely Meta-shaped. I made a version of this argument about converted crypto-mines a few weeks ago; the mines worth converting are a filter across a portfolio, not a score per site.

And this is the general case - one man’s dealbreaker is another man’s discount, and the sites everyone agrees are mediocre are the only ones that can really be defined as being valued correctly.

Declare your buyer

For valuers, the uncomfortable conclusion is that a site no longer has a value; it has a value surface, one number per plausible buyer, and the honest appraisal quotes the shape of it. For developers, “hyperscale-ready” is now a meaningless phrase, because there’s no generic hyperscaler to be ready for. You either spend heavily on optionality, or you pick your buyer early and build their weight vector into the ground around it. As owners of bare land attempt to market it’s viability for data center use, a strange site that every broker has scored a four out of ten could indeed be scored an eight by another party.

TH

Share

Find me on Linkedin

Moratoriums or restrictions on new data centers are under discussion in more than twenty US states; more than $130 billion of projects were delayed or abandoned in the first quarter of 2026 alone; and by one analysis roughly two-thirds of planned American sites sit in areas that experienced drought in the past year. It would appear that water is at the centre of nearly every fight, from Arizona to Aragón.

There’s also a second narrative that seems to keep cropping up, and it’s a battle pertaining to the water demand of a hyperscale facility. One side says data centres drink millions of litres; the other says dry cooling exists and the problem is solved. Both are technically right, but both are just shouting in response to each other, and neither has really costed it. But there is a trade-off, and it’s brutally mechanical: dry cooling saves litres of water; but only by spending kilowatt-hours of electricity to do so. Water and energy are two currencies, and the row over which one a data centre should burn is a currency dispute where no one has bothered to publish the exchange rate.

So let’s publish it. But first we need to untangle what “water cooling” actually means, because half of the shouting match arguably rests on a conflation.

Getting the plumbing straight

The industry is moving to liquid cooling at the chip, and for AI workloads the move is seems to be compulsory rather than fashionable. Air cooling runs out of physics somewhere between 20 and 50kW per rack; direct-to-chip cold plates carry racks to 80–120kW, and immersion beyond 100–250kW. With the industry now debating megawatt racks, the chips will be liquid-cooled, full stop.

The reason is unglamorous: a litre of water can carry on the order of 350 times more heat than a litre of air at the same flow rate. I’ll be critical of the industry’s own press releases here: you’ll increasingly read that this shift is powered by exotic thermodynamics, supercritical CO2 loops and two-phase dielectric fluids that boil off the chip. Those technologies are real, and two-phase change does buy you an order of magnitude again in heat flux; but nearly everything actually deployed at significant scale today is single-phase water or water-glycol in a sealed loop. The liquid revolution is nineteenth-century thermophysics arriving in the server hall, not a materials-science breakthrough; the supercritical and two-phase kit remains mostly vendor demos and patents rather than fleets. There is future scope, but for now – it appears to be fairly hypothetical.

For the noisy bunch who shout loudest about the amount of water required to cool these racks, they often omit one hugely critical fact: that chip-level liquid loop is closed. The same water goes round and round, topped up or replaced periodically, consuming next to nothing of fresh water supply. Liquid cooling at the chip is not what drinks the river. All the water politics live at one specific boundary: the point where the site’s accumulated heat is finally rejected to the outside world. Evaporate water there (cooling towers, at 2 to 4 litres per kWh of IT load, most of it leaving as vapour) and you’re cheap on electricity but heavy on water. Refuse to evaporate (dry coolers, sealed loops and fan walls) and site water use falls to roughly zero, but you surrender something like 0.15 to 0.25 of PUE, because pushing heat into dry air is thermodynamically harder work.

So the honest framing of every one of these planning fights: the chips will be liquid-cooled either way; the argument, for now, is only really about the last metre, where the heat leaves.

Doing the exchange maths

Economists have already solved this class of problem with the shadow price: the true value of a resource that its market price fails to carry.

Start with the exchange rate between the two currencies. The extra electricity per cubic metre of water saved by rejecting heat dry rather than wet is:

Established engineering quantities, my illustrative figures.

• Illustrative numbers: a PUE penalty of 0.2 against an evaporative WUE of 2 L/kWh gives X = 100. One hundred kilowatt-hours of extra electricity for every cubic metre of water saved.

• Take our example campus, 100MW of IT load in a hot, dry market: evaporative rejection drinks about 1.75 million cubic metres a year; going dry hands that back at a cost of roughly 175 GWh a year of additional electricity.

The break-even water price follows immediately: dry cooling wins on money when the water saved is worth more than the electricity spent.

At 10 cents per kWh, W* is about $10 per cubic metre; at British industrial rates nearer 25p, it’s £25.

Now compare with what water actually costs:

• Google’s much-criticised Mesa, Arizona deal priced water at $6.08 per thousand gallons, roughly $2.16 per cubic metre;

• UK non-domestic supply typically lands between £1 and £2.

Water is trading at a fifth to a twentieth of the price at which a rational operator would stop evaporating it. The operators evaporate because the price tells them to; but the campaigners are furious because the price is wrong. A moratorium is a price correction that is being expressed as a ban.

The grid puts its thumb on the scale

The electricity side of the equation carries a distortion of its own, and in 2026 it’s often the bigger one. P_elec in that break-even should really be the shadow price of power, not the tariff, and in grid-constrained markets the two are nowhere near each other.

If your campus is capped by its grid connection, and most are, then every megawatt spent on fans is a potential megawatt of compute you can’t sell. The opportunity cost of the dry-cooling penalty isn’t 10 cents a kWh; it’s the margin on the compute those kilowatt-hours would otherwise have earned, which can run to an order of magnitude more. Price power that way and W* doesn’t sit at $10 per cubic metre; it climbs towards $100.

In a power-starved hub, the maths screams evaporate, which is precisely what operators do, and why the thirstiest sites keep appearing in the sunniest, driest, most power-constrained places. The two bottlenecks compound each other.

The weighting isn’t universal, though. In markets where power is abundant and water genuinely scarce, the shadow prices flip, and dry cooling becomes obviously right. And there’s a third option worth taking seriously: generating the penalty yourself. Cooling load peaks on hot afternoons, which is exactly when solar produces; the fan penalty is one of the rare industrial loads whose profile matches photovoltaics almost perfectly. Our campus’s 175 GWh a year is roughly a 90MW solar farm in the Arizona sun, several hundred acres [with a yield assumption of ~2,000 kWh/kWp]. ¬I’m not being naïve that this is real land and real capex, but it converts dry cooling from a raid on a constrained grid into a self-funded, water-free heat rejection system. Where land is cheap and sun is reliable, solar-backed dry cooling deserves a place in the comparison rather than a footnote.

The sound barrier

There’s a second constraint on dry cooling that the spreadsheets ignore, but the neighbours won’t: noise. Rejecting 100MW of heat into air with no help from evaporation takes an enormous amount of airflow, which means fan walls, which means a noisy sustained hum that carries. Facilities routinely measure 60 to 80 dB at the property line, against typical night-time planning limits of 45 to 55 dB at the nearest home, and the WHO flags sustained night noise above 55 dB as a health risk [EESI / local ordinance ranges].

Sound from a compact source decays at roughly 6 dB per doubling of distance, which gives us a feasibility gate (established acoustics, first-order, ignoring the low-frequency component that makes data centre noise notoriously hard to regulate):

Feed in an aggregate sound power of, say, 110 dB(A) for a full dry-cooling fan estate and a 45 dB night limit, and d_min comes out around half a kilometre. Inside that radius, full dry cooling is not an engineering option regardless of what the exchange rate says; you derate it, screen it, or go hybrid. Which means air-based heat rejection has a ceiling on its applications: it is a rural and edge-of-town technology, and the denser the neighbourhood, the more the maths is forced back towards water, whose rejection plant is far quieter per megawatt. Urban compute is wet almost by definition; the equations that follow only apply where the noise gate is passed.

Water from a stone

The water side of the ledger has its own overlooked lever: where the water comes from. The fights almost always stem from concern about strain on mains supply, but a data centre with the right hydrogeology can sink boreholes into the aquifer beneath it. At scale, this is cheap; groundwater from 100 to 150 metres down arrives at a constant 10 to 12°C, which is itself a cooling asset, and the treatment plant required for cooling-grade water is little more tham a rounding error against a multi-billion build. So the tariff isn’t the real water price either; and the planners should be comparing against the cheapest licensed source:

Two caveats though:.

1. A borehole bypasses the mains price, not the scarcity: Mesa’s grievance is precisely groundwater depletion, so in a stressed aquifer the shadow price applies underground just as hard, and the abstraction licence, not the drilling cost, is the true constraint.

2. This makes hydrogeology a siting criterion: proximity and depth to a healthy, recharging aquifer belongs in the site-selection matrix alongside power and fibre, because it can swing W_eff by an order of magnitude.

And wherever heat is rejected by evaporation, the netting from before still applies: the extra grid electricity that dry cooling demands is itself made with water at the power station (the grid’s energy-water intensity, EWIF), so savings must always be quoted net:

On a thermal-heavy grid, a fifth of the water “saved” by dry cooling re-evaporates in a cooling tower the planning committee will never see. Dry cooling in the wrong grid relocates consumption upstream rather than eliminating it; sometimes relocation is exactly the point, out of a stressed basin and into a wetter one, but it should be claimed as such.

Pricing the river

Put it together and you get a planner’s rule that fits on an index card:

1. Separate the loops. The chip-level liquid loop is closed and consumes next to nothing; strike it from the argument. Every question below applies only to heat rejection.

2. Run the noise gate. If the nearest home is inside d_min, dry cooling is capped or out, whatever the prices say.

3. Compute X and W for the site, using the shadow price of power: tariff if the grid is slack, opportunity cost of displaced compute if it’s constrained, solar LCOE if you’re prepared to build your own fans’ power supply.

4. Compute W_eff from the cheapest licensed water source, borehole included, scarcity-adjusted; and net any dry-cooling saving against the grid’s EWIF.

5. Compare. If the scarcity-adjusted water value exceeds W,* dry (or solar-backed dry) cooling should be a condition of consent. If it doesn’t, evaporative rejection is the right engineering answer and the community’s quarrel is with the water pricing, not the data centre.

What I like about this rule is that it takes the heat out of both arguments. It tells operators that “we comply with the tariff” is an accounting statement, not an engineering defence, in any basin where the tariff is fiction. And it tells campaigners that forcing dry cooling onto a wet, cheap-power, noise-constrained site burns energy, carbon and sleep to save water that wasn’t scarce. The formula doesn’t have a side – and I suppose that’s rather the point of formulas.

Where the water gets muddy

Some pushback on this may be reasonable. WUE and PUE penalties are ranges, not constants; climate moves both, and hybrid systems that evaporate only on the hottest hours can scramble the neat binary, usually in a good way. Shadow prices are estimated, not observed, and handing a number that political to whoever performs the estimate is its own fight. Withdrawal and consumption aren’t the same thing, and I’ve used consumption throughout; a campaigner armed with withdrawal figures will produce numbers five times scarier for the same power station. The noise model is first-order and data centre noise is notoriously low-frequency, which carries further and regulates worse than the formula suggests. And the closed-loop caveat has its own caveat: loops leak, get flushed and get replaced, so “near zero” consumption is near zero, not zero.

But none of that rescues the status quo, in which the loudest infrastructure argument of 2026 is being conducted between one side quoting litres and another quoting kilowatt-hours, with no exchange rate on the table. Engineering disputes get solved when someone prices the trade. This one prices at a hundred kilowatt-hours per cubic metre before the shadow prices move it; everything after that is negotiation.

TH

Share

Find me on Linkedin

Michael Burry, of Big Short fame, has accused the hyperscalers of flattering their earnings by stretching the accounting life of their GPUs; Microsoft depreciates over six years, Meta over five and a half, while Nvidia ships a new architecture roughly every year and the founder of Groq argues the real economic life of an AI accelerator is closer to one or two. Burry puts the understated depreciation at $176 billion between 2026 and 2028.

Both sides are arguing about one component, on one balance sheet. My problem is with everything wrapped around it.

A data centre is a single facility running on several clocks at once. The silicon ages in about three years; the mechanical and electrical fit-out in ten to fifteen; the shell and the land underneath it on a timescale where, in the current market, they may not be ageing at all. And critically, those layers usually sit on different balance sheets. Most data centres are leased: a freeholder owns the shell, a tenant operator owns the kit inside it and holds a leasehold that runs down to zero on a fixed date. Any calculation that treats the facility as one asset with one owner, including the version of this argument I first sketched out, gets the answer wrong before it starts.

So rather than join the fight over whether a GPU lives three years or six, I want to ask two questions the whole discussion seems to be overlooking:

1. What is the blended lifespan of each party’s stake in the building?

2. And what happens when the fast clock and the lease clock strike midnight in the same year?

Whose building is it anyway?

We need to start with the split, because it changes the context of everything.

To the freeholder, the age of the servers is close to irrelevant. They own a powered shell with a grid connection, planning consent and a covenant from the tenant; as far as they’re concerned, the tenant’s kit could be bleeding-edge Blackwell, or frankly, a rack of abacuses. It’s better than irrelevant, in fact: while the operator’s equipment has been decaying, the capital value of the site has in most markets will have likely been appreciating, driven by power scarcity, interconnection queues and the sheer difficulty of consenting new sites. By virtue of those facts the freeholder’s isotope isn’t decaying, it’s actually enriching.

To the tenant operator, the picture is the exact opposite, and far worse than the depreciation debate suggests. The operator’s stake is a stack of three assets, every one of them wasting: the servers on roughly a three-year economic life; the mechanical and electrical fit-out they installed on ten to fifteen; and the leasehold interest itself, which amortises down to precisely zero on the day the term expires, however lovingly the building has been maintained by them.

The whole industry regularly argues about the first item on that list; but in reality, it’s the third that really bites.

A borrowed idea from the physics department

I’m a sucker for stealing the homework of more successful parallel universes, and the physicists did this particular piece of homework a century ago.

A mixture of radioactive isotopes doesn’t have a single expiry date; each component decays on its own curve. So if you want to know how alive the mixture is, you don’t average the labels on the tin, you sum the decay curves and read the total.

This is the correct mental model here too, albeit with one amendment: you must run it separately for each balance sheet. The remaining value of a party’s stake at time, t is:

Where v is the share of that party’s capital in each layer and T is the layer’s half-life. Their half-life is the point where half their stake, by value, has expired:

Established maths (borrowed openly); applying it per-balance-sheet to a data centre lease is my own synthesis, so treat the numbers that follow as illustrative.

If we take a tenant operator on a fifteen-year lease of a 100MW campus. Say their invested capital splits 65% servers and networking (three-year life), 25% fit-out (twelve years), 10% leasehold interest (amortising to zero at year fifteen).

Plot these curves and the operator’s half-life lands around 4.4 years. Half of everything they’ve put into that building, gone before the first rent review. The freeholder, over the same period, may well be sitting on an asset worth more than they paid for it. It’s the same building but with two half-lives (and one of them suggestively negative – or actually enriching).

The scissors in the lease

The widely considered server-depreciation argument often mistakes the lease itself as a passive backdrop. But it’s really not at all; infact, it’s specific terms drive the calculation.

A leasehold interest is worth, roughly, the gap between the rent that’s being paid and the rent the market would charge today, capitalised over the years left until the maturity, or term date:

Two forces pull on that number in opposite directions, which is why I think of it as a pair of scissors. The annuity factor shrinks as expiry approaches; fewer years left, less to capitalise. But if market rents are growing, the rent gap widens every year the operator sits on their current rental rate.

In a market where prime capacity is scarce and rents are climbing, a leasehold can be appreciate through the middle of its term before the shortening tail drags it to zero. So the wider that gap grows, the more brutal the reset at renewal date. At 5% annual rental growth, the market rent in year fifteen is more than double the passing rent. Your appreciating leasehold is a countdown to a doubled rent bill.

The lease terms decide how sharp the scissors are, and they deserve more attention in these calculations than the servers do. Upward-only rent reviews, still standard in UK commercial leases, mean the gap only ever closes one way. Indexed reviews with caps and collars soften the path but not the terminal reset. Break clauses shift the effective maturity. Dilapidations and reinstatement obligations add a lump of end-of-term cost that scales with how much equipment the tenant bolted to the fabric of the building. And a lease contracted out of the 1954 Act gives the operator no security of tenure at all: renewal at open market rent, if the freeholder fancies renewing with you.

When both clocks strike midnight

This is where it turns from an accounting curiosity into a cashflow problem: does the equipment’s decay line up with the leasehold’s? On many standard structures, catastrophically, it would appear to be a ‘yes’.

A fifteen-year lease with a three-year server cycle puts refreshes at years three, six, nine, twelve and fifteen. Year fifteen is also lease expiry. So in a single year, our example tenant operator faces: a renewal negotiation at a market rent that could be double what they’ve been paying, with the negotiating leverage of somebody whose entire operation is bolted to the floor of the landlord’s building; a full server fleet purchase; likely the tail end of the fit-out’s life too; plus dilapidations on the way through. Every layer of that stack demanding capital simultaneously, in what may also be the year lenders are least keen to extend, because the collateral (that leasehold) has just amortised to zero. It’s the duration mismatch that would make a 2008 mortgage banker blush, and it’s baked into the standard lease template.

Corporate treasurers solved this decades ago and named it: laddering. You never let your debt maturities land in the same year, precisely so no single refinancing wall can kill you. The same logic should govern data centre leases, and it gives us a design rule. Stagger the maturities so the lease event lands mid-way through a refresh cycle:

On a three-year refresh, that means preferring a sixteen-to-seventeen-year term over the tidy fifteen, or negotiating breaks and reviews at years that sit between refreshes, or deliberately offsetting the refresh programme itself. The point is the same in every version: significant capital events, spread as evenly as possible across the operational lifetime of the building, so the operator walks into every renewal with a young fleet and a strong covenant rather than an expiring everything.

Whose half-life is it anyway?

Which brings me back to valuation, and a better way to do it than my own first attempt. It would suggest that there is actually no such thing as the half-life of a data centre.

• There is the freeholder’s curve (shell, land, grid connection, often appreciating), and;

• The operator’s curve (kit, fit-out and a wasting leasehold, half-gone in under five years).

The two must be computed separately because the parties can, and increasingly do, sit on opposite sides of the table at renewal. Any single blended number for the facility smuggles in an owner-occupier assumption, and outside the hyperscalers’ own campuses, that animal is rare.

Read the Burry row through that lens and it shrinks. A six-year depreciation schedule against a three-year chip is an error of 2x on one layer of the tenant’s/operator’s costs. A fifteen-year lease that concentrates a rent doubling, a fleet purchase and a dilapidations bill into the same trading year is a structural error across the whole stack of costs.

Where the isotope leaks

As with most of my more novel takes, I appreciate it’s not quite as simplistic as originally suggested; silicon doesn’t decay on a smooth curve; cascading kit from training to inference flattens the early years, and if you stretch the server life to four or five, our operator’s half-life moves out towards six. Those are all fine and sound arguments; but every lease structure above is still mismatched. The leasehold formula also ignores renewal goodwill, sunk connectivity and the practical reality that moving 100MW of live load is so painful that operators will nearly always likely renew on bad terms rather than migrate, which is of course exactly the leverage the maths is pricing. And the model measures replacement value, not earning power; an old chip that still books revenue is dead on my curve and alive on the P&L. There is nothing to suggest that just because an AI-based chip is obsolete for the latest models, it can’t be repurposed as part of a simpler compute unit either – in which case the depreciation isn’t a straight line on that asset either.

However, I still think the core of it holds. The building’s paperwork keeps the freeholder’s time, amd the value inside it keeps the operator’s. Until leases are structured around both clocks, with maturities laddered the way any competent treasurer would ladder debt, the industry will keep concentrating its capital demands into coincidence years and calling the resulting distress a surprise – but in all honesty, it never was - it was actually on the calendar from the day the lease was signed.

TH

Share

Find me on Linkedin

I’ve been part of plenty of design reviews where the decision was made long before the meeting started. It could be material selection, a build-or-buy decision, or an architecture choice. In these scenarios, a faithful scoring matrix is used to help make the decision; criteria down the side, weights in a column, a total at the bottom.

The matrix is an illusion though, as it still relies on judgement to allocate weighting to it. The decision came first, and the matrix came second – produced to make the decision look like it had been arrived at, rather than announced.

The scoring matrix is doing its real job, which is giving the decision a paper trail. But everyone who’ll live with the consequences of the decision knows exactly what happened. The option that won was the one somebody wanted to win, and the weights got nudged until the arithmetic agreed.

This approach isn’t actually always a bad thing either; in the context that the decision is passed by someone of authority or expertise, the matrix scoring and the outcome are one of the same – as it’s all based in the context of a learned approach. It does, however, fall on it’s face ion the context when the approach is adopted by junior or lesser-experienced team members. The matrix isn’t always faithful in practice as it is on paper – especially in context of project decisions where the decision is for something of a individualistic, vernacular or specific nature.

Anyone who’s read anything of my work will know I’m a sucker for stealing the homework of more successful parallel universes. So to try and address this problem, the workflow shouldn’t really aim to be borne from decision science, or from systems engineering.

My novel take is to steal the process from a chess engine – the program that plays chess on computers. For clarity, chess programming isn’t my area at all, and I’m happy to be corrected on the finer details; but it’s been interesting learning about it. And I’ve found it ludicrously ironic that engineers have spent fifty years teaching machines to make multi-factor trade-off decisions transparently and consistently, and we’ve barely borrowed a thing from the very thing we systemized for them to do in the first place.

The weighting game

To be clear, I’m not about to tell you to use a variant of a weighted decision matrix. You probably already know about them; Stuart Pugh formalised the tool in the 1980s, it’s been a fixture of systems engineering ever since, and the decision-science research is on its side: when you’ve got several conflicting criteria and a few people who care about different ones, the structured scoring is the best approach really – and it stops everybody from different departments arguing until the loudest voice in the meeting wins. There’s even been contexts where I’ve even argued for this kind of approach myself – for instance, there’s huge merit in applying an algorithmic approach to data centre site valuation with a weighted index.

The weighted-matrix tool isn’t the problem, but it’s the two ways it reliably gets abused:

1. Retrospective weighting As mentioned in our introductory example. Set your weights after you’ve seen how the options score and then tune them (consciously or not), until your preferred answer comes out on top. The matrix stops being a decision tool and becomes a justification tool.

2. False precision. A more nuanced factor that where an answer buries the mathematics underpinning it. For instance, visually a total of 4.10 in one category compared to 3.95 in another looks like a decisive win. However, if you shift one weight by five points, then the ranking flips. It enables a judgement call to be disguised a measurement. And when it’s presented in figures, the methodology isn’t typically scrutinized.

Both criticisms are fair and common – and a chess engine solves both.

Board-level decisions

Strip a chess engine down and it’s running your scoring matrix, except it’s been forced to do it properly. A position comes in, and the engine scores it as a weighted sum of factors:

• Material first (queen worth nine, rook five, bishop and knight three, pawn one);

• Then king safety, pawn structure and mobility, which is simply how many squares your pieces command. Dozens of weighted terms, summed into one number measured in centipawns, hundredths of a pawn.

That number is the evaluation function, and for decades the entire craft of engine building was tuning those weights against each other. Not adding more factors. Getting the relative weights right.

There’s a misconception with this though, and it should be clarified that the evaluation function doesn’t choose the move. A completely separate system, the search, generates and explores the candidate moves, millions of positions a second. Evaluation just scores whatever static position the search hands it. They’re two separate jobs, deliberately kept apart; the thing proposing options has no say in how they’re scored, and the thing scoring has no idea who proposed them.

To translate that into our context, the person advocating an option is usually also the person scoring it, and quite often the person who set the weights too. An engine would never allow that.

Generate the options as a group, with nobody scoring. Then set and lock the weights before anyone sees how the options land against them. Once the weights are fixed in ignorance of the answer, retrospective weighting becomes impossible, because there’s nothing left to refine or amend. I suppose the approach could feel bureaucratic for about ten minutes, but I’d suspect that eventually it’ll just feel honest.

Playing the long game

The second concept worth stealing is the distinction an engine draws between tactical and positional value, because it’s the one a scoring matrix almost certainly collapses. Immediate material gain is tactical; it pays off now. Pawn structure and king safety are positional; they might pay off in forty moves, or never pay off at all. The engine holds both on the board at once and scores them side by side. A simple scoring matrix would flatten everything onto one number and one unspoken time horizon; and typically, that horizon is nearly always the near term, because the near-term factors are the ones everyone in the room can feel more tangibly.

An illustrative example: Material choice for a component.

If we take a structural material choice for a long, exposed service life: carbon steel against a corrosion-resistant alloy. If we split the factors the way an engine would:

If we sum each column flat, the carbon steel wins comfortably - because three of the six factors reward it. They’re also the ‘loudest’ three factors, that most people are going to care about in the immediate short term. But the three criteria it effectively ‘loses’ on are as valid, but just only become apparent long after the project that chose it has been concluded.

An engine model wouldn’t let you ignore the three losing factors (Corrosion, Maintenance, Downtime) just because the payoff sits in the future after; positional health is scored as real value now, even when nobody can say exactly when it will carry any relevancy or take effect. [Caveat: Treat the numbers as rough, by the way. The point of the split isn’t the totals, it’s seeing that you’re trading two different kinds of value on two different clocks and pretending they’re one.]

Knowing when to resign

The technique isn’t hugely transferrable though, and there are a few flaws. Chess engines have a famous flaw called the horizon effect. Because the search can only look so far ahead, a bad outcome that’s certain but delayable can be pushed just past the point where the engine stops looking, and the engine will play something actively worse to postpone it, because the lesser damage sits inside the visible horizon and the real disaster sits beyond it. Searching deeper doesn’t fix it; as there’s always a new horizon. In our context, it’s rqually as common and applicable - consider how often an engineering decision does the same thing on purpose. Deferring a maintenance liability into a phase the business case never models. Optimising hard for the milestone that can be seen, and shoving the cost just past the edge of the analysis. Your decision has a horizon too; but the difference is the engine’s flaw is accidental, and ours is usually a choice.

There’s a couple of others too; chess hands its engine a single currency: every factor converts to centipawns, because centipawns map cleanly to the one thing that matters, the probability of winning. But often, nearly all engineering decisions has no centipawn equivalent. Pounds, kilograms, risk, downtime and reputational exposure don’t share a unit, and the moment you force them into one combined score you’ve copmmited the same crime – smuggling in judgement in, but calling it a measurement. So in reality, this could be a useful discipline; but could also result in a terrible verdict. It should also be considered that the engine gets to tune its weights against millions of self-play games with a known result. There could be manu scenarios where you don’t get to replay the same decisions, as every project is unique. You’d only find out whether the allocated weights were right in about thirty years when the project has been successful or a persistent nightmare.

This is exactly why the transparent, hand-tuned engine is the right model for us, and the modern black boxes aren’t. Stockfish’s NNUE network and AlphaZero’s self-taught evaluation are stronger models than anything a human ever hand-tuned, but you similarly can’t ask either why it likes a position and get an answer you could put in front of a review board, let alone a regulator. Being able to explain why the weights are what they are is part of the decision, not paperwork after it. The legible model beats the accurate one, because a decision nobody can interrogate is less of a decision, and arguably just more of a guess with good PR.

So the lesson here would suggest to take the architecture and the humility:

• Keep the people generating options away from the people scoring them.

• Fix your weights before you know the answer.

• Score the factors that pay off over the asset’s whole life as real value on their own clock, not as an afterthought to the ones that pay off this quarter.

• And know where your own horizon sits, the line past which the model goes blind and a human has to take over.

The best engine ever built still gets the position wrong when the decisive move sits one square beyond where it can see – so there’s still a place for us after all. On a macro-level in the context of the current news climate where we’re apparently all soon meant to be obsolete in the wake of the new AI, this finding is rather promising.

TH

Share

Find me on Linkedin

But there’s now a data center boom, but the bottlenecks are widely documented at this point (in particular, the infrastructure). However, there’s plenty of crypto-mining sites with large electrical supplies already there; in purpose built facilities, full of compute capacity, cooling systems installed, and connectivity established.

So could the crypto-miners flip their sites over to AI and ride the next wave? In theory, yes – but the maths doesn’t necessarily suggest it’d be the smoothest transition.

Firstly, there’s got to be an asymmetric economic benefit to converting mining sites. So if we start with the premise everyone leads automatically leads with - that bitcoin is “running out.” For clarity, it isn’t - not for a very long time anyway. Around 95% of all bitcoin has already been mined, but the last coins don’t arrive until roughly 2140 because the issuance halves every four years and the tail stretches over a century. This is partly the reason nobody is rushing to pivot their facilities - because they’ve actually not run out of coins to ‘dig up’.

But the bottom seems to have dropped out of the economics. The April 2024 halving cut the block reward in half overnight, and the network’s hashrate carried on climbing regardless, so the revenue per unit of effort fell off a cliff. By early 2026 hashprice had hit a five-year low and something like a fifth of the older rigs were running at a loss. This is more the forcing function; not the scarcity of coins, but a business whose margins strangles itself based on a timer.

Miners didn’t realise the value they were building at the time, as the volatile growth of crypto made any investment more than worth it, even for the short term. But the long term benefits are now being realized.

Power suffocation, chip shortages, and rapidly inflating build costs makes existing facilities with one or multiples of those factors a very attractive solution for those looking to build a new data center.

The coin was never the point

I’ve argued before in previous articles that the grid connection is the real bottleneck on everything in this industry. A new gigawatt of grid interconnection in the US can take something close to fifty months to secure, and the queue of projects waiting for a connection now runs to thousands of gigawatts, most of which will never get built.

Bitcoin miners were really ahead of their time. For a decade, miners went to the places nobody else wanted, stood up next to stranded gas or cheap hydro or a corner of the Texas grid withg loads of surplus power capacity. They did it early, before anyone was fighting over megawatts, and the bitcoin paid the bills while they held the seat. As it seems to have panned out now, the coin seems to just be a way that has made it economic to sit on a scarce grid connection and keep it warm. A placeholder tenant, paying just enough rent to justify holding the lease.

AI build-out projects have now shown up, and needing power more urgently than anything has needed power in a generation. But they’ve found the entire front of the interconnection queue was already occupied by people mining internet money. So they’ve had to start paying for their place at the front of the queue - over seventy billion dollars of AI hosting deals reportedly got signed across 2025 and into 2026: Core Scientific with CoreWeave, IREN with Microsoft, Hut 8, TeraWulf, Cipher, Galaxy’s Helios site in West Texas. In a strange twist, the placeholder tenant is being evicted by one that pays roughly ten times the rent.

So far, so neat; but it’s not quite as straightforward as that. Once a data center operator has bought out the mining facility, the interesting problems start.

A megawatt is not a megawatt

A bitcoin mine and an AI datacentre are not the same building with different machines inside. They’re barely the same category of thing - the number on the front gate is a bit misleading, at best.

When someone says “500-megawatt mine,” they mean 500 megawatts going almost entirely into ASICs, which are gloriously undemanding tenants. They need to care about redundancy; if a miner PC drops offline for an hour, you just lose an house of hashing. They run hot and “dumb” - a mine runs at a power efficiency close to the theoretical floor, because almost every watt goes straight into the chips. The Uptime Institute has put it about as bluntly as an engineering body ever does: most crypto mines have no redundancy in power or cooling, no UPS, no batteries, no generators, no fuel.

An AI datacentre is the opposite animal. The GPUs need serious cooling, increasingly direct liquid cooling piped to every chip; the cooling and the electrical distribution eat a real slice of the incoming power before a single GPU does any work. Then they need redundancy, because a bank you’re serving, or an inference workload a customer is paying for by the millisecond, cannot just wink out because a transformer needed maintenance. So let me put a number on the gap, because that’s the honest way to argue it.

Call it the conversion yield: the fraction of a mine’s nameplate power you can actually sell as AI compute once you’ve built the rest of the real datacentre around it.

As an illustrative example, take our 500-megawatt mine in West Texas:

• First, knock off what the cooling and the electrical build now consume. Where mining put maybe 95% of the draw into the chips, a liquid-cooled AI hall spends a meaningfully bigger share keeping those chips alive, so call it a fifth of the connection gone before you start. That’s 500 down to roughly 400.

• Then hold back capacity for redundancy, because “concurrently maintainable” means you can take any feeder or cooling unit offline without dropping the floor, and that reserve isn’t free. For easy maths, lets assume that to be about a quarter, or 25%.

• Now you’re at about 300, and the honest figure the industry keeps quoting is harsher still: a 500-megawatt mine converting to something like 20 to 25 megawatts of usable critical load.

Round it off and the rule of thumb is uncomfortable. Your 500-megawatt mine is a 250-megawatt datacentre, give or take. The numbers above are illustrative and every site’s different, but the shape holds: you lose roughly half the headline number to the difference between “powering chips” and “running a datacentre.”

So there needs to be an attempt to mine the gap between the two figures – because that’s where the real cost and the real opportunity both sit.

Keep, rip, or skip

If half the power survives conversion, the obvious next question is what else does. In reality, sadly not much. It’s worth being precise about it, because the answer tells you exactly what you’re buying.

For data centre applications, the machines are worthless. A bitcoin ASIC is fixed-function silicon wired to do one calculation, and it can’t run AI any more than a calculator can edit video. Every rig comes out and goes to scrap or the second-hand market. The cooling mostly doesn’t transfer either. The immersion tanks some miners are proud of solve a different problem to the direct-to-chip liquid cooling a modern GPU rack wants, different fluid, different plumbing, different everything. And the low-voltage electrical distribution a mine is built around usually needs tearing out and rebuilding for the density AI racks now run at, where a single rack can pull more power than an entire aisle of miners.

So what are you actually keeping?

Basically all of the asset parts which don’t depreciate - the land, the permits, the substation, the transformers, and above all the interconnection agreement. The things that took probabl;y about 5 years and a place in a decade-old queue to obtain. Everything inside the fence gets ripped out and rebuilt. You’re not really buying a datacentre per se, you’re more buying the right to build one, already energised, on a timeline which most other competitors can’t match in the current market. It’s an underutilized move which seems to be overlooked at the present time, and I’ve explained it in other articles previously. The scarce, slow, unglamorous asset is the grid connection, and whoever holds one holds the only thing money genuinely can’t seem to hurry at the present moment.

The middle of nowhere problem

There’s one more haircut, and it’s the one that kills a chunk of the estate. Miners went where the power was cheap, which usually meant the middle of nowhere. Bitcoin was happy out there, because a mine needs almost no bandwidth and doesn’t care about distance. A block header is eighty bytes. You could technically mine over satellite.

AI cares enormously though; training clusters need fat fibre to move data. And inference (the bit that actually serves users), needs to sit close enough to them that latency stays low, because a few milliseconds of delay breaks a real-time service. A mine parked next to a remote gas flare, three hundred miles from the nearest fibre backbone and any real population, is a wonderful place to make bitcoin, but an awkward place to run AI. Some of these sites can convert beautifully, but there’s many which are stranded in exactly the way that made them good mines in the first place - and no amount of capital is going to fix their postcode.

That’s why the conversion yield isn’t just a per-site number, it should be thought of as more of a filter across the whole portfolio. The mines worth converting are the ones that happen to sit near fibre, near water, near demand, with a utility willing to grow the connection.

Laughing stock

The most interesting part about this is how it’s turned out to be the antidote to the doom story about bitcoin’s poorly-marketed energy use. Without meaning to, an industry that everyone spent a decade mocking as a waste of electricity has gone and assembled a distributed fleet of energised, grid-connected sites, scattered across exactly the kind of second-tier locations that a sane infrastructure build would want. Tens of gigawatts of it, already in the queue’s good graces, right at the moment AI discovered it had nowhere to plug in.

I’ll admit that this is not ever going to be the hyperscale megaproject model; the single enormous campus that takes half a decade and a national grid upgrade to stand up. It’s the messy, meshed, many-sites-in-many-places model I keep arguing is the better bet in countries that’s bad at building big things. The miners didn’t plan to build the physical layer for distributed AI; they were just chasing cheap power with a coin to fund it - but strip out the ASICs, do the honest calculation on what each site can really deliver, and you could be left with a ready-made map of where the next wave of compute can actually go.

So it could be about to turn out that the coin was never the point, but actually the connections were.

TH

Share

Find me on Linkedin

There are two complaints you commonly hear in the supply chain of spares in many industries, but rarely are both uttered in the same breath. The first is that there’s too much stock. Warehouses full of parts bought years ago to hedge against a forecast that never came true – and it’s probably now slowly depreciating, and some of it even ages out before it’s ever fitted. The second is that there’s never the right stock. In aviation, that commonly means that an aircraft sits grounded waiting for one part that isn’t available in any close proximity…and subsequently, burning tens of thousands of pounds an hour while it waits.

They’re actually the same problem wearing two coats. Both come from the same habit: forecasting slow, intermittent demand off long-run historical averages, then covering the uncertainty with a big static buffer and hoping it’s sitting in the right place. You end up holding too much of the wrong thing and too little of the right thing, but ironically paying for both at once. I recently wrote about the warehousing half of this in [Just in Case], where the redundancy cushion has quietly become one of the biggest tenants in the industrial property market. This is the other half.

I’ve long been a fan of stealing the successes of other industries to help solve issues in another, and this can be one of those examples; there’s an industry that solved the responsiveness problem so thoroughly it became notorious for it, and it’s one aerospace would never normally look at:

Fast fashion.

The likes of Zara and Shein are an environmental embarrassment; but strip the disposability away and what’s left is a genuinely brilliant machine for matching supply to demand you can’t predict; and that’s a model worth borrowing.

This article is about how their model actually works.; which bits of it survive contact with a certified aircraft part and which absolutely don’t, and a small piece of maths that puts a number on the prize.

What the rag trade worked out

Most people picture fast fashion as cheap clothes made fast. The interesting part is how the supply chain decides what to make.

Start with demand sensing. Instead of forecasting a whole season from last year’s sales and committing months ahead, Zara reads what’s selling right now, store by store, day by day, and feeds that straight back to production. Shein takes it further, watching search trends, social signals and in-app behaviour to spot a rising shape or colour before it’s really arrived. The principle is simple: forecast from signals of what’s about to happen, not averages of what already did.

Then there’s postponement, which is the practice of staying deliberately undecided. You build generic, half-finished stock and commit to its final form as late as you possibly can, once you know what’s actually wanted. Zara holds undyed fabric and colours it late, so there’s less guessing.

Add small in-season batches. Zara launches a style in runs sometimes under a thousand, watches the sell-through, then reorders only the winners, restocking stores twice a week. Shein tests with as few as a hundred units and scales only what moves. And they position stock close to where it’ll actually be bought. They pay a bit more per unit and accept it, because the saving comes from almost never being badly wrong about what’s needed, or where.

So in the broadest possible principles aircraft supply chain should aim to mimic:

• Sense fast

• Commit late

• Position close

From that 30,000 ft view, none of that logic is really specific to clothes.

Some of it doesn’t fly

I’m just a bloke thinking about stuff, and I’m not closely wedded to the intricacies of this industry – so I’m sure a maintenance planner would spot a lazy analogy instantly, and they’d be right to. The broad theory translates, but there’s reasons if works flawlessly in fashion context, but there may be a few creases to iron out before being adopted by aviation.

Fashion demand is high-volume and forgiving. A missed t-shirt sale costs a markdown. Miss a spare and you might ground an aircraft or, far worse, you’re into safety-critical territory where the cost isn’t a markdown at all. Spares demand is also a different statistical animal: low-volume and lumpy, long stretches of nothing punctuated by the odd spike. Realiostically, that can’t be smoothed with the methods a fashion retailer uses. Also, none of it escapes regulation, traceability and certification, which fashion simply doesn’t carry in the same way that parts for aircraft does; but, software, barcoding and inventory management could develop alongside this to make this more or a practical reality./.

[FIGURE 3 here: mapping table, “What packs, and what gets left at the gate”]

As I see it, the principles seem to split into three piles:

1. Demand sensing ports over relatively cleanly: swap store sell-through for part removals, condition data and how hard the fleet’s being flown.

2. Distributed positioning ports across quite well too, with solid maths behind pooling stock rather than scattering it. Paying more per part to dodge a grounded jet is a trade aerospace already understands.

3. Admittedly, the Postponement only half-travels across: you can hold a common module and finalise its configuration late, but only where the part and its certification allow it. Small test batches mostly don’t, because certification costs and supplier minimums fight you. And the disposability doesn’t travel at all, which is rather the point.

There’s an irony staring at us as far as I can see it - the maintenance world already adopts fast fashion’s worst feature. Industry estimates put the share of spares that expire unused at something like a fifth to a third of them. So it’s a waste bill that’s already being paid, although the responsiveness it’s supposed to buy isn’t being collected.

The buffer you can throw away

A number can be attributed to assist in this, and it’s built on textbook inventory maths, not anything I’ve invented. The safety stock you hold to hit a service target is roughly the service factor, multiplied by how variable demand is, multiplied by the square root of the lead time. In plain terms, your buffer grows with two things: how wrong your forecast tends to be, and how long you wait for resupply.

Responsiveness attacks both, separately. Sense demand better and you shrink the forecast error. Resupply faster and you shrink the lead time. Because the two multiply together, the gains compound.

If we take a basic aircraft part – something like a valve - say it turns over about two a month, lumpily, with a demand spread of three units. Lead time from the manufacturer is six months, and you want to cover ninety-five times out of a hundred. The textbook buffer for that works out at roughly twelve units, sitting on top of the dozen already in the pipeline. Two dozen units of a part that moves twice a month. That’s the dead-capital story in one part number. The below graph should help to illustrate that.

To improve responsiveness, we should consider feeding in condition-monitoring data so the forecast error roughly halves, and the buffer falls to about six. Separately, pre-position stock or stand-up regional repair (so resupply drops from six months to six weeks), and simultaneously the buffer falls to about six again, this time with far less in the pipeline too. Do both and you’re near three units, for the same ninety-five percent cover. Mathetmatically, this leads to suggest to about quarter of the buffer, with the same identical protection.

I will expressly state that this is a very linear model, and as such, can’t ever really be deemed as immediately and universally accurate in realistic context. With demand which is typically very lumpy for aircraft parts, the tidy bell-curve formula is only a rough guide; and a proper model would model the lumps directly. For genuinely intermittent parts you’d reach for something like Croston’s method, which forecasts the size of demand and the gap between demands separately, so all those zero months don’t drag the estimate to mush. The exact figures shift when you do it properly. The shape of the result doesn’t: compress forecast error and lead time, and the buffer collapses while the service level holds.

Sorting the wardrobe

The catch is that not every part can move along that curve, so you have to sort them first.

Two questions do the sorting:

• How lumpy is the demand; and

• Can the part be made responsive at all, meaning can you sense its demand early, resupply it quickly, and is it free of certification locks.

Cross those and you get four homes:

1. Steady demand you can sense gets responsive replenishment, the fast-fashion zone: thin buffer, sense and react.

2. Lumpy but responsive gets the same reflex with a slightly deeper cushion for the spikes.

3. Predictable but hard to move runs happily on a classic reorder point.

4. And the lumpy, hard-to-move, often safety-critical parts get a deep buffer or, better, a shared pool.

That last pile is where positioning earns its keep. Pool the same slow mover across several operators instead of everyone holding their own, and the arithmetic of pooling means the combined buffer shrinks roughly with the square root of how many holdings you’ve merged. Four separate stashes pooled into one need about half the total safety stock for the same cover. For the parts that can’t be made responsive, that’s the lever that’s left.

Keep it honest

Nearly sounds too good to be true, doesn’t it? So let me be clear about the line you can’t cross, and probably is the large part why this model hasn’t been fast-tracked into the supply chain before.

You cannot fast-fashion a safety-critical certified part (for regulatory reasons predominantly, but there’s practical merit to the approach aswell, of course). Postponement stops where certification of a configuration begins.

Traceability is non-negotiable, sole-source lead times are real and often immovable, and “sense and react” is never a licence to thin the buffer on the part whose failure is catastrophic.

So the lesson, or the thing to borrow is the responsiveness philosophy, applied carefully, on the parts that can take it - sensing earlier, committing later, and aiming to position smarter.

Position stock closer; sense demand sooner; commit later where the part lets you; and pool the rest in the open.

TH

Find me on Linkedin

Share

Factories and warehouses are filling up with robots very quickly; but the improvements to the systems meant to keep them out of each other’s way are not matching that growth rate. It usually ends up as a mixture of fixed-path vehicles that follow tape or floor markers, free-roaming robots that build their own maps and reroute as they go, or collaborative arms (often, ironically, working an arm’s length) amongst humans. They all share the same concrete; and even legacy models are regarded as good news for general safety and efficient. However, the traffic management around them mostly isn’t.

What passes for traffic control on most floors today is primitive:

• A robotic vehicle follows a fixed route.

• It reserves a zone and makes everyone else wait until it’s done with it, or;

• Tt stops dead the instant a sensor sees something in its path.

Each of those rules is sensible on its own, and each is safe. But ratchet up the fleet density, and you end up with robotic vehicles attempting to work on top of each other. The outcome of that are production floors that deadlock, that freeze on a single obstruction, and whose throughput falls once you add enough robots. Past a certain density you get less work out of more machines, which is the opposite thesis of why anyone bought them.

The awkward part is that this is already a solved problem, just not by manufacturing engineers and warehousing consultants.

Air traffic control has spent the best part of a century moving traffic that’s faster, higher-stakes, and in places denser than anything on a warehouse floor, and it almost never loses an aircraft. It does that with a layered approach most robot floors have never thought to borrow, including the ones that like to describe themselves in air-traffic terms.

First come, first freeze

To illustrate my point, we need to take the mechanism apart. The floor gets carved into a graph of zones, and before a robot enters a zone it reserves it (akin to booking a meeting room), so everyone else waits until it’s free. It’s safe, it’s easy to reason about, but it throttles throughput the moment density climbs.

To keep this concrete I’ll use one example throughout, the kind of pinch point every floor has: a crossing where a pick aisle, a charging bay and a packing line all feed into a single intersection. Call it ‘Junction 12’. When one robot stops there, say for a person stepping across, the robot behind it reaches its own stopping distance and halts, the one behind that is already holding the next zone, and the approach backs up. Two robots that each want a zone the other is holding deadlock outright, the warehouse version of a circular wait, and neither moves until something external breaks the tie.

The deeper issue is that throughput doesn’t rise smoothly with fleet size. It rises, peaks, and then falls off once it reaches a point of critical density. Add robots past that sweet spot and they spend more time waiting on each other than working.

In the worst case the floor tips into a congested state where almost nothing moves. It’s a property of dense agents sharing space under simple local rules, and it’s been measured repeatedly. A well-known result that a robot navigating a crowd will freeze in place once the crowd gets dense enough.It still freezes even with perfect sensing, because the fix was never better perception; the fix is modelling the fact that the other agents will cooperate. But stop-on-detection has no concept of cooperation. It just has one rule, and it applies it to everything.

I‘ll address the obvious counter-argument early, because there’s probably some engineers that have already started yelling it at their screen – I’m aware that plenty of the industry already calls the fleet manager an “air traffic controller”. Omron markets it in exactly those words. Ocado describes the brain coordinating its grid as an air-traffic control system talking to a thousand bots ten times a second. Amazon pitches its newest layer as an intelligent traffic system.

My argument is that the industry appears to have copied the wrong half of air traffic control; but to clarify which half, that is, we should probably quickly run through how the tower systems actually work.

What the tower actually does

Most people would consider air traffic control as collision avoidance, as we see in films - a controller watching blips on a screen, and telling two of them to turn before they touch. It’s true that’s part of it, but it’s nowhere near the most important part.

The overarching concept in air traffic control towers is that of separation minima; which is the formal term for the minimum gap that must sit between two aircraft. The thing worth stealing as a transferable concept, is that it’s never one number. Aircraft are kept apart vertically, usually a thousand feet between cruising levels. They’re kept apart along their track (roughly three nautical miles near a busy airport and five miles further out); critically, the size of the gap changes with how well the controller actually knows where everyone is. When a controller has live radar, the in-trail gaps can be kept quite tight. But when they don’t, working a stretch of ocean purely off position reports and timing estimates, and that gap blows out to ten minutes or tens of miles. It is the same aircraft, in the same sky, but with a a far bigger buffer - purely because the position is inferred rather than seen. That distinction between procedural separation (you’re estimating where the traffic is) and surveillance separation (you can see it) is the single most useful idea in this whole article, so remember it, as we’ll be building on it later.

On top of separation sits flow management. The tower doesn’t just resolve conflicts where they happen. It meters traffic upstream so the conflict never forms, holding aircraft on the ground or slowing them hundreds of miles out so they arrive at the busy sector already spaced. The doctrine is explicit that delay should be absorbed early and far away, not by stacking aircraft over the airport hoping it clears.

Finally, there’s conflict resolution, which is proactive by design. A controller’s hardest job is spotting a converging pair minutes before it’s a problem and changing one aircraft’s heading, height or speed while there’s still room to do it gently. Automated tools back this up, flagging a looming loss of separation a couple of minutes out and a possible one up to twenty minutes ahead. This whole posturing is intended to make the system preventative and not reactionary.

And underneath all of it sits the last line. Every airliner carries an onboard collision-avoidance system (usually called TCAS) that works independently of the ground entirely. If two aircraft get dangerously close, their boxes talk directly to each other, agree who climbs and who descends, and order the crews to do it. Pilots are required to obey that instruction even when it contradicts the controller.

There’s some sobering examples of why that system and such rules exist, and the importance of it. Over Überlingen in 2002, two aircraft received those automated instructions, but one crew followed the controller’s contrary order instead. 71 people tragically died. So now the rule now is absolute. The automated last resort wins, because it keeps working when the layer above it is wrong.

That stack of independent layers has a name: defence in depth, or the Swiss cheese model, from James Reason back in 1990. Picture each safety layer as a slice of cheese with holes in it. Any one layer can fail, but an accident only gets through when the holes in every slice happen to line up at once. The genius isn’t any single barrier. It’s that no single failure reaches all the way through.

The half they copied, and the half they didn’t

So why that’s important: When the robotics world borrowed from aviation, it only took the optimizer, but left the institution.

The optimiser is the clever bit: a central brain with a god’s-eye view, computing efficient, deconflicted routes for the whole fleet. That part has been copied brilliantly. Amazon’s and Ocado’s systems are genuinely impressive pieces of coordination.

The institution is everything else. It’s the layered separation that flexes with how well you know where things are; the upstream metering; the proactive conflict resolution; the independent last resort that survives the central brain being wrong. And it’s talso the defence-in-depth philosophy tying them together.

This is the half which seems to have been omitted, and the gap is apparent in the standards. The dominant interface standard that lets different robot brands talk to one fleet manager, VDA 5050, explicitly puts traffic management, routing, congestion and deadlock resolution out of scope and leaves them to each vendor. There’s a standard pipe for commanding the robots and no standard at all for the hard part. Aviation would never accept that, as safety is the priority over efficiency - the hard part is the whole point, and should take precedence over everything else.

A floor that borrows the right half

So what does a floor look like if it borrows the institution instead of just the brain? We can revert back to Junction 12 examp[le to illustrate the point.

We can start by killing the single rule, and exchange one fixed number for a term which represents the space a robot needs, defined by cumulative sum of it’s component attributes which contribute to how it defines that space requirement.

That’s the sensing and localisation error, plus the distance covered while the robot decides what to do, plus its braking distance, plus how unsure it is about where the other party is, plus a designed safety margin.

The safety standards for mobile robots already compute something like this; but the piece that does the real work is , and it’s exactly the procedural-versus-surveillance idea from aviation. Two robots that both broadcast their position and intent can run a tight, “surveillance-grade” gap. A robot facing something that doesn’t communicate has to fall back to a wide, “procedural-grade” gap, because it’s guessing. One floor, two traffic classes, two separation regimes, and not one rule applied to everyone.

The part which shows why the single rule is so expensive and, neatly, where this whole analogy breaks is apparent though: On a floor, the space a robot sterilises around itself is an area, and area grows with the square of the radius. Pack robots that each need a clear radius S into a floor and the handling capacity scales roughly as:

Run one rule and you’re forced to set S to the worst case everywhere, the wide human-grade gap, even for two robots that could safely run close. Layer it, and robot-to-robot encounters drop to the tight gap. The ratio between the two regimes is the thing to remember:

In this theory, the penalty is squared. If the human-grade gap is three times the cooperative one, a single rule isn’t costing you a third of your throughput. It’s costing you roughly nine times the robot density at equal safety. (I’d probably treat that as a first-order packing argument rather than a control-theory proof, but the shape of it appears to hold true.)

The rest of the logic follows the tower systems:

• Meter robots upstream of Junction 12 so the crossing never saturates, the way aircraft are held before a busy sector, instead of letting four arrive at once and fight.

• Resolve conflicts by prediction, rerouting one robot down a parallel aisle before the crossing locks, rather than first-come-first-freeze.

• Build it in independent layers, so when the central brain hiccups or a robot drops off the network, planned separation still holds and the onboard stop still fires. The lesson of Überlingen, ported to a warehouse, is that the local safety stop has to keep working when the fleet manager is wrong. One dropped connection should never be able to reach through every layer at once.

Where the sky stops helping

I should caveat by stating that this can’t simplistically be lifted wholesale (I’d be lying if I pretended otherwise).

A factory floor is not airspace, and the differences are not just cosmetic. Aircraft are sparse in three dimensions and separate vertically; but your robots are more likely packed into two and can’t. That’s not a footnote, it’s the squared penalty above, the reason a margin that costs aviation a little costs most manufacturing operations a lot. Aircraft are cooperative, equipped, tracked and predictable. Controllers almost never deal with uncooperative traffic. Your floor likely has humans walking through it on their own schedule, equipped with nothing, and that’s where the deepest break is in this theory. The tower has room to breathe, the go-around, the holding stack, and the option to delay a problem in spare airspace. A packed aisle in a manufacturing facility usually has none of that slack. In essence, there’s nowhere to send the problem.

The parts of aviation that transfer are the parts that don’t depend on cooperation: layered separation, and defence in depth. The part that doesn’t transfer is the comfortable assumption that everyone in the system is equipped and behaving. So you need to design the human in as the worst case, not the exception. They’ll always get the widest envelope, permanently. They’re never assumed to communicate, signal or move predictably, because they won’t. And the densest, fastest, tightest-separation robot traffic gets physically kept out of the spaces where people roam, because the one thing a century of air traffic control can’t teach you is how to separate from something that doesn’t know the rules exist and never agreed to follow them.

So we can borrow the philosophy, the layering, the metering, the independent last resort, and the refusal to let one failure cascade.

But we can’t just borrow the numbers, as the most dangerous thing on your floor is the one agent the tower almost never has to deal with: a human, on foot, who has no idea they just froze Junction 12.

TH

Share

Find me on Linkedin

You may find these of interest:

We’ve all been in a presentation where someone ludicrously intelligent manages to lose the room’s attention in under a minute. It’s very common amongst academics and professional thinkers.

We all see it as soon as the slide pops up onto the screen – and usually, it’s a chart or a diagram with far too much information on it. Usually, by any technical metrics, it’s probably perfect; every component is there; every interface; every link; every redundant path; every label, all depicted with the same care and attention.

But the room stays silent - not because anyone was impressed, but because noone could find the thing they were referencing or talking about. If we’re lucky, someone else in the room may eventually pluck up the courage to question it and seek a bit more clarity from the presenter; four minutes later, a single piece of data is extracted out of the explosion of information on the slide, and everyone carries on. It’s a perfect example how something can be ‘complete’ or ‘finished’, yet also useless in achieving it’s purpose.

The remarkable thing about this common scenario – often seen in management meetings where the technical staff are attempting to explain findings to C-suite - the failure is rarely a lack of skill. It was actually the opposite - too much of the wrong kind of skill.

We’ve actually had a solution on this type of communication, and it was figured out a long time ago – not by engineers, but by mapmakers.

The man who deleted geography

In 1931, a 29-year-old engineering draughtsman called Harry Beck sat down in his spare time and redrew the London Underground map. London Transport had a perfectly accurate map at the time. It showed the lines where they actually ran, over a real street geography, true to distance and position. It was also a tangled mess, especially in the centre where the stations bunch up, and passengers found it confusing.

Beck threw the geography away. He straightened every line into verticals, horizontals and 45-degree diagonals. He blew up the cramped central zone so you could read it, and he squashed the sprawling suburbs so they’d fit. He kept exactly one piece of real-world geography as an anchor, the River Thames, and threw out the rest. His own explanation was blunt: “If you’re going underground, why do you need to bother about geography? Connections are the thing.”

London Transport initially rejected it for being too radical, but then reluctantly trialled 500 copies in 1933. They printed 850,000 in the first two months. It’s now one of the most recognised pieces of information design on the planet, and it works precisely because of everything Beck refused to draw.

Every map is picking a fight

There’s something which engineers and other technical folk innately tend to resist: a map is never reality. It’s just an argument about what matters, but disguised as a neutral picture.

There’s a useful pair of words for this:

• A topographic map is true to the ground: real positions, real distances, real scale.

• A topological map is true to the connections: what joins to what, in what order, regardless of where things physically sit.

Beck’s diagram is topologically honest and topographically a lie, and that’s the whole point. He sacrificed where things are to make crystal clear how they connect, because connection is the only thing a passenger underground actually needs.

Strangely enough, nearly every map does a version of this deal – even the ones we think of being very ‘accurate’. The Mercator projection you you’ll have seen since school, takes a round Earth and flattens it so that compass bearings come out as straight lines, which is exactly what a 16th-century sailor needed to plot a course. But the price it pays is area; in some iterations, Greenland can end up looking the size of Africa, when about fourteen Greenlands would fit inside it. But it’s the bargain the map struck to do its one job. Mark Monmonier wrote a whole book called How to Lie with Maps, and the lie isn’t the scandal - the lie is actually the craft.

Engineers usually do the opposite of this on instinct. We treat distortion as failure and completeness as virtue, so we cram everything in and call it accuracy. What we actually produce is the tangled 1931 map. All technically there and complete, but still totally unreadable.

The grown-up word for lying

Cartographers (the professional description for people who draw maps) have a formal name for drawing things wrong on purpose. They call it generalisation, and it’s a real discipline with named techniques, not a vague instinct to tidy up. Five of them map almost directly onto what you do at a whiteboard.

None of this is new to the people who think about charts. Jacques Bertin laid out the visual variables you’ve got to play with back in 1967, position, size, shape, colour, value, orientation, texture; Edward Tufte gave us the data-ink ratio. What the mapmakers added was a proper vocabulary for deliberate deformation. Tufte’s technique mostly wants you to remove clutter. Cartographers will happily bend the truth of where something is, and they’ve got techniques and standards for doing it honestly.

Same system, two maps

So by way of an example: here’s the same plant control architecture drawn twice. Sensors, edge gateways, network, controllers, analytics, operators.

This first version is the one that I talk about in the introduction - the one that appears on the slideshow and loses the room’s attention. You can see every sensor drawn individually, every redundant link, protocol tags, IP addresses, switch model numbers, all lines equal, sprawling across the page in a layout that vaguely follows where the kit physically sits. Complete. Dead.

The second version applies the five moves. The sensors are classified into typified blocks. The flow runs cleanly left to right similar to Beck’s straight lines. The critical path and the one real bottleneck are exaggerated so your eye lands on them first. The IP addresses and switch models are selected straight off the page. The only way to improve this would be a note the corner saying what this drawing is for and what it deliberately leaves out.

In both examples, it’s the same system - but you can only really think clearly with one of them.

Declare your projection

That note that I should have put in the corner is not insignificant, and it’s actually the difference between a useful lie and a dangerous one.

Every serious map states its scale, its projection and its date. That declaration is what makes the distortion honest, because it tells you the rules for reading it and, by implication, what not to use it for. Nobody walks into the River Thames because the Tube map drew the embankment wrong, because nobody thinks the Tube map is to scale. But where the Tube map does mislead people is the bit it doesn’t declare; for instance, Leicester Square to Covent Garden looks like a journey. In reality, it’s one stop on the Piccadilly line, and about 250 metres on foot. People ride it every day because the map’s silence about distance lets them. The distortion that makes the network legible but obfuscates from the fact that the walk is arguably faster than going through the barriers, down the escalators, waiting for the train, and then back up following your less-than-a-minute journey.

That’s the crux of this - a good, simplified diagram tells you it’s simplified, but a bad one pretends to be complete. The solution is almost insultingly simple: write on the drawing what kind of map it is and what you took out. Modern iterations of Tube maps now put a little note next to Leicester Square informing that it’s just a 10 minute walk to Covent Graden.

Where the distortion kills

There’s a bit of nuance that need to apply to this argument though. Distortion is a skill when the job is to help someone understand, and what you cut isn’t needed for the decision they’ll make. It becomes negligence when the job is to help someone act, build it, operate it, certify it, respond to a fault, and you cut something they needed to act safely. A nautical chart and a road atlas of the same coast are both heavily distorted, and neither is more accurate in the abstract. Attemptiong to navigate the rocks with the road atlas and you’ll find you’re on them.

So the two worlds need to be kept apart:

• The released fabrication drawing, the P&ID of record, the FMEA, the certified schematic, those are your survey maps. They live under ASME, ISA and IEC standards, under revision control and sign-off, exactly because people build and certify from them and a dropped tolerance there can kill. You do not generalise those.

• Everything in this article belongs to the other layer, the diagrams you draw to explain: the review slide, the architecture overview, the onboarding sketch, the briefing for the stakeholder who needs the shape of the system and not the means to fabricate it.

Get that distinction wrong in one specific way and there is a scenario where it could be lethal, but I do think that’s quite a rare occurrence, and most humans are aware of the distinction. The sin isn’t simplifying; it’s letting a drawing made to explain get mistaken for the record people act on, with no note on it to say which one it is. A good map always tells you what kind of map it is, and thhe bad ones let you assume they’re the whole truth.

Harry Beck knew his map was a lie, and that’s why it’s one of the most useful drawings ever made. His skill worth borrowing isn’t necessarily drawing less accurately; it’s knowing exactly which map you’re making, and adjusting it for your purpose – but just ensure you never let anyone confuse it for the other type.

TH

Share

Find Me on Linkedin

You may find these of interest:

By those standards, SpaceX’s/Elon’s offering under xAI looks like a minnow swimming with whales. Microsoft, Amazon, Google and Meta are currently each pouring tens of billions into capacity. xAI is the newcomer with the edgy chatbot that appears on X for a bit of context testing (or Twitter, for millennials and older – we all still call it Twitter, don’t worry). Grok is seen as a novelty - a side project which is easy to file under “small AI lab” and move on.

I think that’s a huge mistake though. I completely understand why it appears like this at the moment, but if anything about SpaceX’s record IPO has taught us, there’s as much belief into Elon’s capability as there ever has been.

The reason xAI gets underestimated is that it isn’t really chasing the same prize as everyone else. It’s not optimising Grok for mass-market consumer release the way OpenAI is with ChatGPT. Similarly, they’re not positioning for enterprise like Anthropic are doing with Claude. Their market destination is ‘embodied’ AI, such as the the brain for Tesla’s Optimus robot – and frankly, it’s a market that simply isn’t here yet (or not at any significant scale yet).

The attention stays elsewhere, on the companies shipping products you can poke at today. Meanwhile the infrastructure underneath xAI is being built by a man who treats “impossible on that timeline” as a personal challenge. Forget the newly advertised ‘trillionaire’ net worth for a second too, because ironically the valuation is a distraction. Roughly as much money has been collectively or cumulatively shovelled into data centre construction by his rivals anyway – so his advantage isn’t monetary.

What Elon has that the others don’t is a set of ludicrously unfair advantages no other operator has any real experience wielding.

Power to the people who build their own

Start with the one constraint that decides everything in this industry: electricity. I’ve written before that the grid is the actual bottleneck, not the tech, not the money,, nor the planning. It’s that all of the other operators are stuck in the same queue. Connection waits stretch for years, and when developers need turbines they’re lining up behind each other for GE Vernova or Kawasaki, usually hiring the same handful of consultants to tell them what they already know.

Elon doesn’t queue. When the grid couldn’t feed his Memphis Colossus site fast enough, xAI wheeled in a fleet of methane gas turbines, somewhere around thirty-five of them, and simply ran the thing anyway while the permits caught up. He’s run factories off generators before. He’s built the Raptor engine. Rocket science is the family business, so the idea that building a steam turbine to make his own electricity would faze him is laughable. Where everyone else sees a power problem that needs outside help, he sees an engineering task he’s already solved in a harder domain.

This is the bit that should genuinely worry the incumbents. To be fair, Amazon has comparable muscle here, on paper at least. It has the capital, the logistics and some similar engineering knowledge through Blue Origin. What it doesn’t have is quite the same level of risk appetite, or the speed at refining manufacturing efficiencies. The same tools, but completely different temperament.

Bigger, and half-empty on purpose

The second unfair advantage is Elon’s affinity for scale. Look at the Tesla Gigafactory as an example; hyperscale isn’t a stretch goal for Elon, it actually seems to be his default setting. Doing it bigger than anyone else isn’t a challenge he has to rise to, it’s probably the way he always intended to do it in the first place when he ideated it. Colossus has already grown from a standing start to hundreds of thousands of GPUs, with a million openly being talked about as the target – it wouldn’t surprise me if Elon asks that timeline to be moved up to urgently either.

It’s going to take a bit more insider knowledge, but patternising Elon’s behaviour would suggest there’s likely another avenue which will double his capacity over his competitors for the same cost per square foot.

If you’ve not read ‘The Book of Elon’ by Eric Jorgenson, I’d recommend it (he’s also being doing podcast as part of the promotion for it too, so I’d recommend checking some of those out aswsell). A key finding in that is how Elon is willing to push efficiency and design to it’s limits, and he hates too much redundancy built into things – he sees it wasteful, inefficient and unnecessary if something if well designed and durable in the first place.

Most operators of data centers build everything and run it at half capacity – keeping the other half as a redundancy backup.

But I’d bet good money that xAI’s data centres will likely eventually (or may even currently) run with barely any redundancy. Everyone else builds in duplicate, two of everything, because their reputation lives or dies on uptime guarantees to enterprise customers. xAI mostly answers to itself. If a node drops mid-training, it’s just an annoyance, not a breached SLA. Strip out the spare capacity everyone else is contractually forced to carry, and for every square metre of building you’ve effectively got double the usable compute. I can’t prove the redundancy figures from the outside, so treat that as my inference rather than reported fact, but it’s exactly the kind of efficiency he chases everywhere else - cutting the part that isn’t earning its keep.

The warm-up act

All of that is impressive, and if he hyperscales with a power generation solution with minimum redundancy, he’ll already by running at factorial levels of efficiency that other operators could achieve. But potentially, it’s just the warm-up act.

The headline act is space. SpaceX has now merged with xAI and filed with the regulator for permission to launch a constellation that could eventually run to a million compute satellites, with the first AI satellite design already shown off publicly. The pitch is simple enough: in orbit the sun never sets, so the power is free and constant, and you’re not fighting any community over land, water or grid capacity. The engineering is brutal, cooling in a vacuum is a genuine nightmare, and plenty of serious people think parity with ground-based sites is a decade away rather than two or three years. I’m not claiming the timeline is right – Elon’s timelines have been awry more than once – sometimes for better, but more often not.

SpaceX already runs the world’s busiest rocket launch cadence; bolting a bit of data center deployment into that (in a modularized, proven and repeatable format), and the best thing all of the other data center operators could do is sell up and buy SpaceX shares. Once Elon cracks orbital deployment, every operator still pouring concrete on the ground is competing in a different and slower league. Attempting to fix data centers relationships with the grid if the slow route. Elon will potentially leave the grid behind entirely, and nothing on earth will be able to compete.

This isn’t actually theoretical at all, as he’s already done it with Starlink. The glacial pace that hard cabling telecommunications infrastructure upgrades can’t even begin to compete with the speed that Starlink can be rolled out.

The only one who could answer

If anyone is positioned to meet this, it’s Amazon, but at this stage it would seem that it’s not even close. AWS is also the operator with the most to lose, because its whole empire is terrestrial cloud. So Blue Origin filing its own orbital data centre plan, Project Sunrise, should be a no-brainer, and it is happening, but their trouble is the scale and the timing. Blue Origin filed weeks after SpaceX, for fewer than 52,000 satellites against a potential million. That’s a reaction, not a leading strategy.

Amazon has done this before. It speed-ran cloud computing while everyone else dithered and owned the category for fifteen years off the back of moving first. I think it needs to find that same nerve again (and bloody fast), because the window doesn’t stay open once xAI nails infrastructure deployment in orbit. SpaceX’s advantage would compound in the same way that all of Elon’s engineering does – standardized, repeated and iterated. The same playbook that took SpaceX from blowing up rockets to landing them on barges, and Tesla from niche curiosity to the one of the most valuable carmaker on the planet – all from complete blank slates also.

That’s why this is a one-shot. Whoever’s still building data centres the traditional way when that flywheel spins up doesn’t get a second chance to catch the front-runner. They just get lapped.

I’ll caveat all of this the way I caveat every piece oon AI infrastructure rollout - none of this is a problem if the market stays competitive and honest. A ferociously capable operator dragging the whole industry forward is a good thing, right up until it’s the only operator left and gets to set the price of every junction on the network. The healthiest outcome is xAI, Amazon and a handful of others genuinely racing each other into orbit. The worst is everyone waking up to the predator only after it’s already eaten.

In his defence, Elon has always been welcoming of competition, and genuinely seems to push his agenda in pursuit of creating a better humanity. He’s fine being one of a few operators in any space. But this is no longer at just the direction of Elon; there’s now a lot of shareholders to answer to – and they are not going to be as welcoming of anything which appears to compromise their investment.

So by all means keep watching Microsoft, Google, Meta, Oracle and Amazon. But don’t forget to watch xAI – or there’s a chance you may end up watching the wrong predator.

TH

Share

Find me on Linkedin

You may find these of interest:

Then 2020 happened, and the gospel flipped. A blocked canal, a chip drought, half-empty supermarket shelves, and suddenly the company holding three months of stock looked clever rather than careless. “Just-in-case” became the new orthodoxy almost overnight.

Most of the commentary on that shift has generally framed the cost only really as a financial one. Working capital tied up in inventory. Carrying costs that the Institute for Supply Management puts at somewhere between 20% and 30% of inventory value every single year.

In theory, that’s all true, and all worth worrying about. But the premise skips the more interesting bill, that nobody’s really itemising. Every extra week of just-in-case has to physically exist somewhere; it needs a roof, a floor, dock doors and a postcode.

The redundancy cushion has quietly become one of the largest new tenants in the industrial property market; but unlike the money tied up in stock, the space it occupies doesn’t politely unwind once the crisis passes.

Lean has become a lot less lean

The numbers behind this shift are not subtle. By 2023, days inventory outstanding across S&P 1500 companies had climbed to roughly 71.6 days, a five-year high. Manufacturers, in particular, have held those swollen inventory-to-sales ratios fairly steady ever since rather than letting them drift back down towards the old lean baseline. Then tariff uncertainty through 2025 had firms pulling orders forward to get ahead of the next price rise, piling yet more onto the heap.

None of this reads like a temporary blip waiting to correct itself; and it appears more like companies institutionalising the buffer as a modern management practice. They’ve deliberately decided that carrying more is the price of not getting caught out again; but once a business makes that decision, the stock has to go somewhere other than a spreadsheet.

The interesting part: the ratchet only turns one way

There’s a bit I think gets overlooked in a lot of the commentary. The Just-in-time system has a correction built into it. Every quarter, somebody’s job is pushing inventory down to free up cash, and prove they’d trimmed the fat. The whole philosophy pulled in one direction, towards less.

But the Just-in-case system has no such floor. The incentives run entirely the other way, and they’re asymmetric. Nobody in a boardroom gets sacked for a warehouse that’s a bit too full, but plenty would get sacked if a shelf was empty during the one week demand spiked. When a disruption hits, buffers go up fast; and when the disruption fades, they quietly stay up because no one wants to be the person who stripped out the safety net right before the next shock. The redundancy capacity cushion ratchets. It perpetually seems to climb in every crisis, and barely retreats between them.

That changes what kind of demand this is; resilience-driven warehousing isn’t a cycle that booms and busts with the economy. It’s a step change that keeps stepping - a structural re-rating of how much space the physical economy needs just to feel safe. I accept the lean evangelists will push back hard on that, and in normal times they’d have a point. But we don’t appear to be in normal times.

Redundancy doesn’t add…it multiplies

The space problem is worse than “everyone’s holding a bit more,” because real resilience isn’t one bigger pile in one bigger shed. Genuine resilience is duplication - it’s dual-sourcing the same component from two suppliers on two continents. It’s decoupling buffers between each stage of production so a stoppage at one doesn’t starve the next. It’s spreading stock across more regional nodes so a single closed port or flooded motorway doesn’t strand your entire inventory in the wrong place.

Every one of those moves multiplies the number of locations stock has to sit in. Decouple a chain at five points and you’re no longer holding one buffer, you’re holding five, each needing its own building, its own racking, its own dock doors and its own staff to run it. Total floor space grows faster than total inventory value, because resilience by design scatters the same goods across more sites rather than consolidating them. You’re not simply holding more stuff. You’re holding it in more places, and places are the expensive part.

Fast space and slow space

Not all of this inventory behaves the same way though, and that’s reshaping what kind of buildings get built and where. Throughput stock (the stuff turning over constantly to feed e-commerce and next-day delivery) wants to be close to the customer. Companies pay a fortune for last-mile real estate near cities because speed is the whole point.

Safety stock is the opposite animal; it mostly sits still, waiting for a bad day that may never arrive. Parking that dead weight in premium urban logistics space would be foolish. Therefore, it heads for cheap, tall, heavily automated buildings out where land costs a fraction of the price, somewhere the rent on doing nothing is bearable. The global industrial real estate market seems to be splitting into fast space and slow space; two genuinely different property products with different economics, different locations and different tenants.

This is a big part of why nearshoring corridors are booming. Mexico pulled in over $20bn of foreign direct investment in a single quarter recently, with the largest slice heading straight into manufacturing, and inventory markets like Monterrey have swelled to north of 200 million square feet of industrial space. Shorter, more resilient supply lines need somewhere to hold their buffers, and it’s better to put that expense where the concrete and the ground underneath it is a cheaper liability.

The cost with no line item

So why isn’t anyone properly pricing all this?

Simply put: there’s no row in the accounts called “resilience.”

The inventory itself shows up neatly on the balance sheet, a number a finance director can quote to two decimal places, but the space holding it does not. It’s operating expense is split - smeared across the cost of goods, buried inside a third-party logistics invoice, or hidden in a lease that looks like healthy growth on paper - but is really just insurance against the next disruption. A company can tell you precisely what its stock is worth and have almost no idea what its cushion costs in rent, because that cost isn’t ever gathered into one place to be costed properly.

The cost of a cushion is more than financial precisely because the financial bit is the only part anyone bothered to measure. The square footage, the energy to light and heat it, the people to run it, the opportunity cost of capital sunk into a building full of stuff that’s deliberately not moving, all of it lands as a vague, distributed drag that never gets named – and you can’t manage what you refuse to add up.

Building less, charging more

The supply side is what turns this from an interesting observation into a genuine squeeze. Warehouse construction peaked in 2022, with something like 2,784 facilities entering the building stock, and completions topping 330 million square feet at the height of the cycle in 2023. Then it fell off a cliff. New supply slumped to around 48 million square feet in the first half of 2025, and speculative developers seem to have largely abandoned distribution centres in favour of building data centres instead.

A structural step-up in resilience demand is therefore arriving just as the pipeline of new space thins out. Vacancy has stabilised somewhere around the high-six to mid-seven percent mark depending on whose methodology you trust, big-box leasing more than tripled year-on-year in early 2026, and pricing power is creeping quietly back towards landlords.

The winners are obvious enough: owners of modern, high-cube, automated space in cheap secondary markets, and the nearshoring hubs soaking up manufacturing that’s moving closer to home. The losers are less obvious and a lot more deserving of sympathy. They’re the lean disciples who proudly handed back their buffer space in 2023 to look efficient on a quarterly call, and now have to re-lease it into a tighter, dearer market at the worst possible moment. There’s a grim little irony in the efficiency crowd now being forced into paying an efficiency penalty.

The cushion you can measure

The cushion isn’t going anywhere this decade. Tariffs, geopolitics and the lingering memory of bare shelves seem to have cemented that for the foreseeable future. But leasing ever more space is the lazy response, and it’s the one that quietly bleeds a business while hiding in the cost of goods.

The same research showing buffers ballooning also shows firms running AI-driven demand sensing cutting their safety stock by somewhere between 30% and 50% for the same level of resilience. That’s the real opportunity, and it’s the one the next ten years will reward.

The companies that come out ahead won’t be the ones sitting on the most stock in the most buildings. They’ll be the ones who know, almost to the pallet, how little they can hold and still sleep at night. Resilience you can actually measure is resilience you can deliberately shrink. Everyone else is just paying rent on their own anxiety, and calling it strategy.

TH

Share

Find me on Linkedin

You may find these of interest:

There’s a second grid that almost nobody talks about in those terms. It’s made of concrete, cranes and seawater, and it carries the physical economy the way the electricity grid carries the digital one. We call its junctions “ports”. And like the power grid, it’s over-concentrated, under-invested, and quietly setting the price of nearly everything you own.

Here’s the part that should bother you more than it does. That grid sits at the water’s edge, which is precisely where the weather is getting worse.

An invisible grid where you can’t see the pylons

Over 80% of world trade by volume moves by sea. In 2024 that was around 12.1 billion tonnes of stuff loaded onto ships [UNCTAD Review of Maritime Transport 2024]. IN realistic terms, that is not a slim majority, it’s pretty much all of it. Everything in your kitchen, your car, the components inside the phone or computer you’re reading this on, all of it spent part of its life on a boat.

But they didn’t pass through a thousand evenly-spread harbours; it funnelled through a relatively small number of mega-ports and a handful of canals and straits that the whole system leans on. You’ve experienced some of the repercussions of this setup already in recent times - remember when the Suez canal got blocked in 2021? Or when prices shot up due to the Russia/Ukraine conflict? And we’re all only just seeing the tide turn on fuel prices now the Strait of Hormuz has reopened following the peace deal between Iran and the USA.

This is the elephant on the quay - we’ve built a global economy that depends on a few dozen enormous, fixed, coastal ports and passages, and then we’ve assumed they’ll always be open, and always be accessible.

This is the same mistake we make with nearly everything. I’ve written about it at length in the context of hyperscale data centers, and I’ve argued at length why distributed beats giants in manufacturing. The premise of concentrating the load into a few big sites and you end up building spectacular efficiency on top of spectacular fragility. One bad day at one critical node and the delay ripples through everything plugged in behind it.

The difference is that a substation or a data center is affected largely by controllable factors – most things can be planned, scheduled or accommodated in advance. Security can be tightened, redundancies built into systems, fast re-routing of traffic or demand. They aren’t really affected by many uncontrollable factors, such as the the weather – they’re largely unaffected by a storm surge.

But a shipping port does.

High and dry, and underwater too

When people picture weather risk to ports, they picture the obvious version. A hurricane, a flooded terminal, containers floating off into the harbour. That happens, and it’s expensive. But the more interesting risk is the one that works in the opposite direction - drought.

Look at what happened to the Panama Canal. An extreme drought through late 2023 dropped the level of Gatun Lake, the freshwater source the locks depend on, so far that the canal had to ration itself. Daily transits fell from roughly 36 to 38 vessels down to around 18 by February 2024. Ships either waited, paid enormous sums to jump the queue, or sailed thousands of extra miles around the bottom of two continents. It took until late 2024 for capacity to recover. No storm. No flood. Just not enough rain in the wrong place, throttling a chokepoint the entire western hemisphere relies on.

The Rhine told the same story in 2022. A hot, dry summer dropped water levels so low that barges could only sail about a quarter full, capacity on Germany’s main commercial artery roughly halved, and operators slapped low-water surcharges on everything moving through. Chemicals, coal, grain, fuel. An entire industrial economy partly seized up because a river got shallow.

The climate now disrupts trade by giving us too much and too little water, sometimes in the same year, and the infrastructure that was built for a band of conditions we’re sliding out of at both ends.

Hit at both ends of the chain

Now layer the two together, because the weather doesn’t politely attack one link at a time.

In 2011, Thailand flooded. Thailand also happened to make a huge share of the world’s hard drives, somewhere between a quarter and 45% of global output depending on whose figure you take. Factories went underwater, and the world hard-drive output fell by as much as 30% in the final quarter of the year, and average drive prices jumped around 150% in the space of about six weeks. It took roughly a year for supply to recover. A flood on one floodplain in South-East Asia, and people in London and Los Angeles paid more for storage for a year.

This is the part that the shelf price never shows you. Weather can hit the factory at the source and the quay in transit and the port at the destination, and each hit compounds the last. The cost lands as a vague “supply chain issue”, gets folded into a freight rate nobody itemises, and arrives at the till as a number that’s just slightly higher than it used to be, with no label explaining why.

The premium on the premiums

This is where the hidden cost stops being a one-off shock and becomes structural, because there’s an industry whose entire job is to price exactly this risk - Insurance.

If you want to know where physical climate risk is going, don’t read the forecasts, read the insurers. They’ve already shown their hand on land. Insured losses in the US hit $112.7 billion in 2024, up about 36% on the year before. Carriers have simply walked away from the worst-exposed homes in Florida and California, with multiple insurers exiting or freezing new policies across 2022 and 2023. When the maths stops working, they don’t raise the price, they just leave.

Coastal port infrastructure sits on exactly the same risk curve. Sea-level rise, storm surge, heavier rainfall; all concentrated on assets that by definition can’t move inland. Marine cargo and the business-interruption cover behind it are repricing accordingly. And here’s the death spiral worth naming clearly: a port that becomes uninsurable is, for all commercial purposes, a port that’s closed. Nobody routes serious volume through a node they can’t insure. The premium becomes the price of trade, until one day the cover just isn’t offered, and the route quietly goes dark.

That cost doesn’t vanish. It gets spread across the freight rates of every route that’s still open, and from there onto you. You’re already paying a weather premium on your weekly shop. It’s just buried three layers deep in someone else’s insurance schedule.

Reshore, or made nearer?

So we should really accept that we have an equilibrium? If it comes to a point where importing simply costs more than making it at home, then importing is no longer viable?

In theory, yes. There’s a tipping point where the landed cost of an import, freight plus insurance plus delay plus reroute, climbs above the cost of producing the same thing domestically. The trouble is what’s waiting on the other side of that line. For a country like the UK, the honest answer is: not much. The factories aren’t there; and the once skilled workforce has thinned out or retired. And building national-scale capacity from a standing start is exactly the kind of single, enormous project we are reliably terrible at delivering on time.

Which means “produce it at home” is the right instinct pointed at the wrong solution. The answer isn’t one giant reshoring megaproject any more than the answer to compute was one giant data center. It’s the same move I keep coming back to: distribute it, and redesign the smaller thing. Many small local production sites rather than one national factory. Inland dry ports and multi-modal hubs that take the load off the coastal chokepoints. Modular and relocatable handling that doesn’t depend on armouring a single fixed quay against a sea that’s coming up to meet it.

And realistically, the equilibrium for most goods won’t be “home”. It’ll be “nearer”. Shorter sea legs, fewer chokepoints, supply that doesn’t have to gamble on a single drought-prone canal staying open. Made nearer, not made here. It’s less satisfying than full self-sufficiency, but it’s much more achievable.

There’s a genuine win-win in here, if we keep it honest. Build a meshed, distributed, weather-resilient logistics network and you get cheaper, steadier prices and a supply chain that bends instead of snapping.

The elephant on the quay isn’t going anywhere. The least we can do is stop pretending we can’t see it.

TH

Share

Find me on Linkedin

You may find these of interest:

There’s a video which first surfaced in 2008 featuring an employee from Sun Microsystems. For some reason, 18 years on, my Youtube algorithm threw this at me, and I was a little curious from the title alone ‘Shouting in the Datacenter’. In essence, someone stands in front of a full server rack rack full of spinning hard drives and shouts. He doesn’t touch it, or shake it - he literally just shouts. The latency spikes, throughput drops and the drives slow down because of the acoustic energy from a human voice.

You can also hear in that video that the sheer volume inside a data center. I’d wager that technology in the cooling systems have improved this to a large degree, but mechanical fan extraction still forms a huge part of the typical data center cooling methodology. And all of that is much more acoustic disturbance than a single human voice.

It’s a slow self-destruction of efficiency – noise affects server performance. So to overcome that, we need more server capacity to overcome the inefficiency of it.

I’ve been sitting with this idea for a few days. It started as a question about vibration isolation, turned into a question about acoustic physics, and ended up somewhere genuinely speculative; but I’m not bothered about being wrong. And largely, it’s not scientifically incoherent – so there may just be something in it.

A server rack is basically a vibration antenna

A server rack is, in essence, a precision-cut steel frame designed to hold equipment perfectly rigid, which it does brilliantly. What it also does, less brilliantly, is transmit vibration between every component mounted to it.

Each spinning hard drive generates its own vibration signature from the read head hovering nanometres above a platter, chasing sectors around at thousands of RPM. That vibration travels through the mount, into the frame, into the adjacent mount, and into the neighbouring drive’s head. Which then has to compensate, retrace, and wait for the right sector to come back around. Every I/O operation pays a performance tax on every move.

When the drives spin, it generates it’s own vibration; that vibration travels through the mount, into the frame, into the adjacent mount, and into the neighbouring drive’s head. Which then has to compensate, retrace, and wait for the right sector to come back around. Every I/O operation pays a performance tax on every move.

By how much though?

A 2009 study conducted in a world-class, raised-floor production data centre found ambient vibration caused performance degradation of up to 246% for random reads and 88% for random writes in an enterprise storage system. [Q Associates / Turner et al., “Effects of Data Center Vibration on Compute System Performance”, USENIX SustainIT 2009] Disk throughput dropped from 40 MB/s to 15 MB/s as vibration levels increased. One of the world’s largest producers of hard drives at the time, Western Digital, eventually patented ‘IsoVibe’ - a foam-and-baseboard suspension system that isolates drives from each other within an enclosure, just to manage the intra-rack noise floor.

Before you ask: yes, SSDs largely don’t care. Their solid-state architecture shrugs off vibration in ways spinning drives can’t. But as drive density increases and AI workloads push hardware closer to its thermal and mechanical limits, the vibration floor is still real; and the rack is still conducting it between every component. There’s a huge memory shortage at the moment too – so it may be a case of trying to get what we’ve got to work, until the supply and cost of the SSDs enable their use to become more prevalent.

For context, HDDs still massively outnumber SSDs because the drives are much larger in physical size but cheaper per terabyte. About 62% of enterprise storage by capacity reportedly still runs on spinning disk. So HDDs won’t disappear anytime soon; they’re the cheap, high-density option for bulk/cold storage and AI training data, giving the cheapest cost per terabyte. The data centers running the biggest HDD arrays (hyperscalers storing video, training sets, backups) are exactly the facilities where the 246% degradation figure bites hardest.

I think the deeper issue is actually more likely architectural. There’s been a good fifteen years spent building increasingly sophisticated isolation mounts, vibration-damped chassis, and acoustic baffles. All of them treat vibration as a management problem, but all of that engineering is downstream of the root cause.

The rack itself is the conductor – so I’d argue that should be where efforts are focused.

Standing still, standing waves

Acoustic standing waves are what happen when two sound waves of the same frequency travel in opposite directions and interfere with each other. The interference pattern creates nodes points in space where destructive interference means there is, effectively, no displacement. So for vibration, that means zero. Not reduced; totally absent.

This is the same principle used in acoustic levitation. Apply a standing wave field in the right geometry, and light objects are pushed toward those nodes by radiation pressure and held there, with no contact required.

Scale has always been the problem. In December 2025, physicists at the Institute of Science and Technology Austria published a paper overcoming what had been called “acoustic collapse” - the tendency for multiple levitated objects to clump together under acoustic attraction forces - by combining electrostatic charge with the acoustic field to keep objects stably separated. The demonstrated objects reached 98mm diameter and 0.608g mass. [ISTA / PNAS, December 2025, “Charging Particles to Overcome the Fundamental Limits of Acoustic Levitation”]. In simple terms, the research is tailored to other applications, with much lighter weights.

But server hardware weighs kilograms. Server-scale acoustic levitation is nowhere near currently demonstrated capability, and so I’m not going to pretend otherwise. But there’s a meaningful difference between “beyond current capability” and “physically incoherent.” The direction is right – so Id argue it as an engineering scale challenge, not a violation of known physics.

There are other cross-domain patterns; which appears in medical research. Acoustic tweezers (devices that use ultrasonic standing waves to trap and manipulate biological samples without contact) are standard kit in precision medicine labs. From nano-scale manipulation to millimetre-scale structures, all using the same underlying acoustic physics. The cross-domain question is what changes when you apply that precision to hardware sitting in a rack. It’s the same argument – the physics is perfectly sound, but it’s a question of engineering it to accommodate the weight burden.

No brackets required; it’s all about the nodes

If you design a rack’s mounting geometry around the nodal positions of a standing wave field; positioning each drive bay at a point of zero acoustic displacement - you get vibration isolation without foam, suspension springs, or IsoVibe. The acoustic architecture does the work; drives sit in silence because the wave geometry says that’s where silence lives.

This is the phononic crystal principle, already used in precision engineering to create structured acoustic “band gaps” - frequency ranges and spatial zones where vibration cannot propagate.

This is also, incidentally, the same design logic I’ve argued for from different angles in my articles on modelling nodal lattice structures to base alternative server architecture on; and my wafer server concept design. The conclusions always seem to circles back to the same place: the physical mounting architecture of hardware in a rack is an unsolved problem dressed up as a solved one.

Full acoustic levitation is the direction this points in; servers floating in an acoustic field, 360-degree airflow across every surface, no bracket restricting a cooling face, no rack frame conducting vibration from one chassis to the next. As I said at the start- speculative, but coherent.

Coherent, but still needs a caveat

The layer I flag as speculative is the same ultrasonic standing wave field that provides acoustic mounting could, in principle, carry data between servers at rack-level distances. Near-ultrasonic acoustic data transmission already exists - frequencies around 17–20 kHz are used for ad-hoc device communication with no network setup or pairing required, software-defined, deployable on existing hardware.

Current demonstrated speeds are modest (around 180 kb/s) at ultrasonic frequencies, which is nowhere near what inter-server communication demands. So the practical application of this as a primary data channel probably isn’t a near-term story. But it points at something worth thinking about; a rack where the same medium provides structural support, vibration isolation, and data transmission.

Data centers already spend considerable engineering budget fighting their own acoustic environment. The question is whether that same energy, designed in rather than fought out, does the opposite.

The acoustic principles are (literally and metaphorically) sound

Near-term, this is a redesign of rack mounting architecture around principles the acoustics community already uses. Phononic isolation geometry, acoustic cancellation arrays, nodal mounting positions. None of it requires levitation. It requires taking acoustic engineering seriously in a context that has historically treated sound as a problem to absorb.

I accept the engineering objections, and there’s quite a few aswell. Power consumption to sustain standing wave fields at server scale is unknown and probably significant. Structural stability under variable thermal loads is an open question. Of course, there’s the data transmission issue too. But these are the problems to solve, not reasons the concept fails.

TH

Share

Find me on Linkedin

You may find these of interest:

Data centers are basically heat engines running in reverse — and they’re wasting most of what they produce.

Data centers are basically heat engines running in reverse. You put electricity in, and almost all of it comes out the other side as thermal energy: from processors, from power conversion losses, and from cooling systems working overtime to push that heat somewhere it won’t cause problems. In 2025, hyperscale data centers converted somewhere in the region of 180–220 TWh of electricity into waste heat, and most of that heat went straight into the atmosphere.

Not because there’s no use for it, but simply because nobody built the infrastructure to do anything else with it.

That’s the starting point for a conversation the industry keeps almost having, but always manages to never get around to. Waste heat recovery in data centers is real. There are pilots, academic papers, and German regulations now mandating reuse targets.

The conversation usually ends at district heating; pump the warm water somewhere nearby, heat some buildings, and call it a sustainability win. That’s not necessarily wrong, but I’ve always thought it’s just a bit performative. And it’s a strange place to stop when you’re sitting on a hugely abundant potential power source, whilst simultaneously facing a structural energy shortage.

The Temperature Delta Problem

I’ll do my best to summarise the engineering case. A gas turbine running a combined heat and power (CHP) system produces exhaust gases at somewhere between 343–537°C. That’s more than enough to generate steam and run a secondary power cycle.

In comparison, standard data center air exhaust, usually comes out at 30–45°C in an air-cooled facility, rising to 50–60°C with liquid cooling. That’s too cool for conventional steam turbines, which is where this conversation usually fizzles out. To make that hotter, it’d have to be heated, which would use even more energy.

But organic Rankine cycle (ORC) systems use working fluids with lower boiling points than water, and they operate effectively from around 65°C upward, with reduced-efficiency operation possible from as low as 32°C.

NVIDIA announced in early 2026 that its next-generation AI systems can operate with 45°C inlet water, which makes waste heat recovery economics considerably more attractive than they were even twelve months ago. So this is quite exciting – and the delta between current exhaust temperatures and useful power generation is no longer fixed by physics; it’s now just a design problem.

But to be honest, it can get even more interesting than that, if we continue to steal the homework from energy suppliers.

This isn’t a completely revolutionary concept, and there are actually many hyperscale facilities are already running gas turbines as part of CHP configurations for on-site generation. In most cases, the thermal energy in gas turbine exhaust typically represents 60–70% of the original fuel input; and right now, most of that is being recovered in fairly basic ways.

The pressure question is worth asking though. Can you do more with that exhaust if you treat it as a pressurized working fluid rather than just a heat source? Combined-cycle configurations already do this at utility scale — a gas turbine drivs a generator, the exhaust feeds a heat recovery steam generator, and a steam turbine extracts a second round of power from what would otherwise be waste. Adapting that architecture to the modular, distributed footprint of a data center campus is admittedly a non-trivial challenge, but again – it’s an engineering problem, and not a physics one.

The supply chain secret

This is where the article stops being about engineering and starts being about strategy.

Gas turbine manufacturing is in a bit of a crisis. Global orders at the end of 2025 sat at 110 GW. Global manufacturing capacity sits somewhere between 60 and 70 GW. Lead times have stretched to five years. Prices are up 195% since 2019, heading toward $600/kW by end-2027 on the last published figures I could find.

In 2025 alone, 846 gas turbines were ordered globally, totalling over 100 GW — more than double 2024’s figures. GE Vernova, Siemens Energy, and Mitsubishi are all throwing capital at the problem, but you can’t double turbine manufacturing capacity overnight. Specialized labor shortages, hot-section component bottlenecks, and trade-related cost pressures mean this gap isn’t closing quickly.

Now consider who’s on the demand side of this equation. Hyperscalers spent roughly $364 billion on data center construction in 2025 (Microsoft alone had contracted 34.7 GW of clean power capacity as of late 2025).

These are organizations that think in decades, operate at enormous scale, and have the capital to make long-horizon bets. They’re also currently queueing up for turbines like everyone else; and paying the same inflated prices, waiting the same five years.

To me, this seems like a strange position for companies that have gotten comfortable owning their own undersea cables, designing their own chips, and building their own satellite networks.

It’s probably more of a venture than a vertical integration

Whilst Amazon, Meta, Oracle, Microsoft or Google could becomes a turbine manufacturer, that’s probably not the answer. MY argument is for less of a traditional vertical integration, and more of a venture-style co-investment.

For instance: a hyperscaler puts capital into a new manufacturing facility, or buys a stake in an existing production line expansion, in exchange for preferential capacity and locked-in pricing. The turbine manufacturer gets the capital it needs to grow faster than its balance sheet would allow. And in return, the hyperscaler gets supply chain security in a market where supply chain insecurity is materially affecting its ability to build and operate infrastructure.

It’s worth being specific about what “preferential capacity” actually means in a five-year-lead-time market. If you can jump the queue by two years because you helped fund the line that built your turbines, that’s a real competitive structural advantage.

The aerospace angle matters here too, because the machines best suited to data center applications aren’t conventional utility-scale turbines. Aero-derivative gas turbines, which adapt jet engine technology for ground-based power generation, have been doing this work for over 30 years. They’re lighter, quicker to ramp, and engineered to the kind of precision tolerances that data center operators already understand. Recent advances in blade materials, thermal barrier coatings, and ironically - AI-driven adaptive control systems - have pushed their efficiency and operational flexibility further still.

A co-investment thesis targeting manufacturers working on aero-derivative designs, rather than large-frame utility machines, would be well aligned with the specific operational profile of a data center campus - modular, sclable, and with tighter footprint constraints than a traditional power station.

The Decision That Hasn’t Been Made

The counterargument would be that hyperscalers should “stay in their lane”. Manufacturing is capital-intensive, cyclical, and far from their core competency, which I suppose is a fair point.

But I’d argue the ship has already sailed, and they’re already out of their their lane. They’re signing agreements with fusion startups, restarting nuclear plants, and buying hydroelectric capacity. Turbine manufacturing sits comfortably within the range of strategic bets they’re already placing, but to me the difference is this one has a direct operational payoff. It’s cheaper, and has faster access to the equipment that converts their own waste heat into power. And at a moment when power is the single biggest constraint on their growth.

There’s a real energy loop waiting to be closed. Data centers take in power, generate heat, and pay again for more power. The technology to interrupt that cycle exists; the capital to fund the infrastructure exists; and the supply bottleneck that makes vertical integration strategically attractive exists. What’s missing, so far, is the decision.

TH

Share

Find me on Linkedin

There are two numbers that, on their own, sound like good news for British tech:

• The first is the sheer weight of capital ready to build AI compute, and the UK makes good sense for european demand.

• The second is the government’s enthusiasm to wave it all in.

Put them next to a third number, though, and the optimism curdles: around 50GW of prospective data centre demand is queuing for grid access against a peak national load of about 45GW. We are, in other words, being asked to roughly double the entire country’s peak electricity demand - and funnel most of it into London and the South East - on a grid that was largely designed six to eight decades ago, and was barely coping before the AI wave hit our shores.

The proposals so far really fall down at a conceptual stage, and is a key indicator of how applying US construction models to infrastructure just doesn’t translate with the same efficiencies in the UK.

The hyperscale model is the motorway approach to infrastructure: build one enormous, high-capacity artery, pour everything onto it, and accept years of disruption and astronomical cost to lay it down. That’s seductive on a planning map; but Britain’s roads didn’t get good because we built a handful of motorways - the country runs on a dense, redundant web of B-roads that get you almost anywhere, reroute around a crash, and were mostly already there. I want to make the harder argument that for the vast majority of UK compute, the B-road network is the better piece of engineering, and not the consolation prize.

The motorway dream meets the British reality

What hyperscale needs just isn’t what we can provide. A single hyperscale AI campus wants somewhere between 100 and 300MW of firm power; 100MW alone being enough to power roughly 100,000 homes. It wants that power continuously, in one place, at the cheapest possible rate. In my road metaphor, that’s like a six-lane motorway demanding its own dedicated junction.

The UK fails to provide that energy on all three counts, and it’s worth being specific about why:

1. The power isn’t there, and won’t be for years. The demand connection queue didn’t creep up, it totally detonated. Contracted demand-side offers jumped from 41GW to 125GW between late 2024 and mid-2025, and interconnection queues in London have stretched to 7-10 years. Even after NESO took a machete to the speculative pipeline, only around 13GW of firm demand can connect before 2030, with the bulk (86GW) slated for the 2030 to 2035 window.

2. The power is the most expensive in the developed world. This is the part that gets glossed over in the AI gold-rush coverage in UK contexts. UK industrial electricity prices in 2024 were the highest of all IEA members for which data exists, both including and excluding taxes. At around 25.85p/kWh, that’s roughly four times US industrial prices and 46% above the IEA median. A data center is, functionally, a machine for converting electricity into compute. Choosing to site the most power-hungry machine humanity has ever built in the country with the highest cost electricity is a decision that needs a very good reason. Sadly, “the government is keen” is not one.

3. More than three-quarters of developers are already taking the next exit. This isn’t hypothetical. More than three-quarters of UK data centre developers are now actively looking at sites abroad rather than wait, and in 2025 and 2026 both AWS and Meta publicly paused construction on billion-dollar facilities to reassess whether promised grid connections would materialise at all.

A quick word on Britain’s track record with big things

Aside from the grid restrictions, it’s worth thinking about our history with megaprojects. Simply put, we’re total shit at them.

Take Hinkley Point C. First planned at £18bn with operations expected around 2025, the cost has now surged past £48bn, and won’t start generating until 2030 at the earliest. That’s a near-triple on budget and a five-year-plus slip, on a project whose entire job is to produce the cheap, firm power these data centers need.

Or HS2; the purest example we have of the motorway mindset. Originally estimated at £35-45bn in 2019, now revised to a range topping out at £102.7bn, with the full route not operational until somewhere between 2040 and 2043 - and they’ve quietly slowed the trains down to claw back money. A complete cancellation was dismissed because the remediation cost for work already done came in at £58bn. Let that sink in: the bill to stop exceeded the original budget to build. One grand line between two cities, decades late, and the rest of the network it was meant to relieve gets nothing in the meantime.

The pattern is consistent and it’s structural. Britain is poor at delivering single, monolithic, mega-scale infrastructure on time and on budget. So why would we architect our compute future as a string of these things, each one a bespoke decade-long fight with the grid, the planners and the local community?

The hyperscale campus concept is the HS2 of computing - enormous, singular, fragile, and perpetually three years from a press release apologising for the delay. Meanwhile, the unglamorous B-road network quietly does most of the actual work - and so that’s where we need to build our data centre capacity.

The case for the mesh

For the vast majority of UK workloads, the answer is a distributed, meshed network of small-to-medium sites. I’ve made adjacent versions of this argument for manufacturing and for modular container-based deployment, but the grid reality makes it sharper for compute than anywhere else.

1. It spreads the load instead of concentrating it. A 200MW campus needs that 200MW connection in one spot - which, in the UK, doesn’t exist without years of reinforcement. Twenty 10MW sites can each tap into existing local capacity, distribution substations, and the headroom already sitting in the network across dozens of towns. You’re not demanding one impossible new motorway junction; you’re using forty B-road turnings that are already tarmacked. This is the data-centre equivalent of avoiding the factorial scaling problems I covered in previous articles; scale comes from the volume of facilities, not the output of a single site.

2. It’s dramatically faster. The entire delay in UK data centre commissioning is the connection queue. Smaller sites that fit inside existing connections sidestep the queue almost entirely, especially when paired with on-site generation and storage. In the US, roughly one third of planned new data centre capacity by early 2026 was designed to operate wholly or partly independently of the public grid - up from effectively zero a year earlier. A mesh of energised, already-connected buildings - exactly the distressed-retail conversion play I’ve suggested in other articles, can be switched on now, not in 2035.

3. It improves latency, which is increasingly the whole game. AI inference (the bit users actually touch) wants to be close to them. A local data centre network puts compute in the centre of the towns and cities that consume it, which is the right architecture regardless of the grid argument. The grid constraint just happens to push you toward the thing you should be doing anyway.

4. It’s resilient by design. A single hyperscale campus is a single point of failure - for power, for cooling, for connectivity, and for planning objection. Close a motorway and everything stops; close a B-road and the traffic reroutes through the next village along. Same principle here - if one node drops, traffic redistributes. It’s the same logic as my Elastic Failover Exchange and Carbon Flow Failover pieces; distributed capacity isn’t just cheaper, it’s structurally more reliable, and it opens the door to trading and greening that idle redundancy rather than letting it sit there as dead weight.

We do still need the motorways, but just build them where they belong

None of this means hyperscale has no place. It means that the hyperscale DC campuses should be rationed to the few locations that genuinely justify them, rather than treated as the default. There’s a strong argument for a small number of large, power-hungry sites sited deliberately next to the grid’s actual strong points - close to existing substations, transmission nodes, decommissioned power-station connections, and emerging AI Growth Zones co-located with new generation. The government is already trying to shift data centre demand to unconstrained locations, and that’s the right instinct: put the heavy haulage where the carriageway can take it, and mesh everything else onto the B-roads.

That’s the real strategic prize for the tech firms, too. The operator that stops fighting for the handful of impossible 200MW connections and instead assembles a distributed estate of modest, fast, already-energised nodes will be deploying live capacity while its competitors are still in pre-application meetings. In a market where hardware risks becoming outdated before power is ever delivered, speed of deployment isn’t a nice-to-have, it’s actually the entire competitive moat.

A genuine win-win, if we keep it honest

Laying it all out, it’s a relatively obvious solution - the grid gets a load it can actually absorb, spread across the country instead of piled onto one overloaded junction in the South East. The tech firms get capacity now, lower latency, and resilience baked in. Towns well off the motorway map get investment and infrastructure they’d never see from a single rural mega-campus. And the nation sidesteps yet another HS2-shaped hole in the ground that’s perpetually over budget and behind schedule.

But I’ll end where I usually do. A meshed, distributed model is healthier precisely because it’s plural; many sites, many operators, many landlords, spread across many communities. The danger is that the same handful of hyperscalers with the deepest pockets simply buy up all the good B-road frontage the way they’d have built the campuses, and we end up with a toll road wearing a B-road’s clothes. The network should be distributed all the way down - not just the racks, but the ownership. Build the web of roads. As always, we just need to make sure no single company gets to own every junction on it.

TH

Share

Find me on Linkedin

You may find these of interest:

There are two stories in British infrastructure right now that nobody seems to be telling together.

The first is that the high street is on its knees. The second is that the country physically cannot plug in the data centers it wants to build. On the face of it these are unrelated problems — one is a retail story, the other an energy one. But put them side by side and something interesting happens: each one looks suspiciously like the answer to the other.

And there’s exactly one company whose two halves slot neatly into the two halves of the problem. Amazon runs one of the largest cloud platforms on earth and one of the largest e-commerce and logistics operations in the country. Most operators eyeing this opportunity would have to pick a use for the building. Amazon doesn’t.

A sector in managed decline

By now, we’re all familiar with the state of British retail. According to the Centre for Retail Research, 2025 saw 17,349 store closures and just under 202,000 redundancies - and that came hot on the heels of a 2024 that saw roughly 13,600 stores shutter, getting on for 400,000 retail jobs gone in the space of two years. The British Retail Consortium has pointed out that there are now fewer people employed in UK retail than at almost any point on record.

The vacancy figures tell the same story from a different angle. National retail vacancy is hovering around the 12-14% mark, but that headline masks a brutal north-south split. London and Cambridge sit comfortably below 9%, while towns like Newport, Bradford and Blackpool are pushing close to one in five units standing empty. Online shopping now accounts for somewhere north of a quarter of all retail sales; a shift Amazon did more than anyone to drive. Meanwhile, footfall across high streets, shopping centres and retail parks remains stubbornly 15-20% below where it was pre-pandemic.

The point og this isn’t to wallow in the decline; we’ve all grown accustomed to the convenience of online shopping, and we’re very unlikely to return to traditional retail shopping in the same way we once did.

The point is that this has produced a very specific kind of asset: large, structurally-sound, well-located buildings that nobody particularly wants to use as shops anymore, available at a discount, in the middle of towns where people actually live and work.

Sound familiar?

It should - because it’s very nearly a shopping list for a modern data center site. It’s also, almost incidentally, a shopping list for a last-mile logistics node.

They need to be repurposed - so that the existing retail can remain, whilst the real monetisation comes from diversifying their uses.

The buildings fit the brief

Strip away the retail signage and look at what these buildings actually are, structurally and electrically, and the appeal becomes obvious.

1. They sit where the demand is. Department stores and large high-street units occupy prime, central positions inside developed urban areas. For latency-sensitive workloads - and increasingly that means AI inference served close to the end user, rather than bulk storage shoved out in a field - being in the city rather than 200 miles from it is the entire game. That same centrality is exactly what last-mile delivery economics are built on.

2. They already pull serious power. A former department store, supermarket or shopping centre was built to run escalators, full-building HVAC, commercial kitchens, refrigeration and lighting across tens of thousands of square feet. That means a substantial existing electrical supply with meaningful amperage already connected to the grid - an asset that, as I’ll come to, is now worth more than the building itself.

3. They’re multi-storey and built to last. These are semi-modern, structurally robust buildings with plenty of economic life left in the fabric. Multiple floors give you something a flat industrial shed doesn’t: vertical separation between functions, and a roof and basement that can be put to clever use.

4. They’re cheap. A distressed retail asset in a secondary location is changing hands at a fraction of its replacement cost. Compare that to the going rate for “powered land” - Savills has clocked sites with existing grid connections trading at £8-15m per acre, against £4.5-6m for ordinary London industrial land. The premium is entirely about the power, not the ground.

The elephant in the substation

Here’s the problem that makes all of this urgent rather than merely interesting.

You cannot get a grid connection in this country. The demand connection queue ballooned from around 41GW of contracted offers in late 2024 to 125GW by mid-2025 - for context, peak national electricity demand in February 2026 was about 45GW. Developers have reported waiting anywhere from five to ten years for a connection, with some quoted figures stretching far beyond that. More than three-quarters of UK data center developers are now actively looking at sites abroad rather than wait.

The grid needs a generational upgrade, and the uncomfortable truth is that there isn’t the public money to do it at anything like the speed required - a bottleneck I’ve written about before as the real anchor on data center progress, not the ability to stack servers in a building. NESO’s recent cull of the connection queue, slicing it from over 700GW down to a couple of hundred, tells you how much of the demand was speculative - but it also tells you how ferociously everyone is scrambling for the connections that do exist.

Which is exactly why an existing, energised building is such a quietly valuable thing. You’re not buying the shop. You’re buying the connection, and getting the building thrown in.

For Amazon specifically, this is the route around a queue that is otherwise throttling AWS’s ability to land new compute on UK soil - the very compute it needs for the AI and inference demand growing faster than anyone can build for. A distributed estate of modest, already-energised urban sites is a way to add capacity now, close to users, without betting everything on a single hyperscale campus that can’t switch on until the 2030s.

Engineering above and below the bottleneck

An existing supply gets you in the door, but an AI workload will want more than the building’s retail-era allocation. Rather than join the back of the decade-long connection queue, the smarter play is to generate and conserve as much as possible on-site - and a multi-storey building is unusually well set up for it.

• Put the roof to work. A large, flat retail roof is prime real estate for solar PV; a private-wire array feeding the building directly, in the manner operators are already deploying to dodge grid delays.

• Look down as well as up. The basement footprint sits right against the ground, making these buildings natural candidates for ground-source/geothermal exchange to shoulder the cooling load - which is where most of a data center’s parasitic energy goes in the first place.

• Generate, store, and shave the peaks. On-site generation paired with battery storage turns the building from a passive load into something that can manage its own demand profile and lean on the grid connection only when it has to.

None of this gets you off the grid entirely, but it stretches a modest existing connection a great deal further. Crucially, it does so now, rather than in 2035.

The Amazon-shaped opportunity: compute upstairs, commerce downstairs

Here’s where this stops being a generic data center stategy, and becomes something only Amazon is really positioned to pull off. Simply gutting a high-street landmark and filling it with humming racks behind a blank façade would be a miserable outcome for everyone. The multi-storey layout lets you do something far more interesting - and Amazon happens to own both businesses that want the two halves of the building.

Upstairs: AWS, compute and AI. The upper floors become a compute node - energised, urban, low-latency. This is capacity for AWS’s cloud and the surging AI inference demand that increasingly needs to sit close to the people it serves rather than out in a remote campus. Each converted building becomes a small piece of a distributed edge network, plugged into AWS’s existing platform and operated by the team that already runs it. No competitor can integrate the racks into a live, global cloud with anything like the same low friction.

Downstairs: e-commerce and last-mile. The ground floor stays street-facing and working — but for Amazon, “retail space” means something specific. A central, well-connected unit is an almost perfect micro-fulfilment and last-mile delivery point: order online, dispatched from the heart of the town rather than a distribution park on the ring road; same-day collection lockers; returns drop-off; even a physical Amazon retail or Fresh footprint where it makes sense. The building feeds Amazon’s e-commerce machine from exactly the central location that makes last-mile economics work.

The elegance is that the two halves reinforce each other. The same building, the same energised connection, the same security and facilities team, the same logistics network that already moves Amazon’s goods can also move its hardware and spares. One acquisition, one operating model, two of Amazon’s core businesses fed at once. The compute makes the property pay; the fulfilment makes it pay twice.

And where a given site doesn’t suit either use, the ground floor still has civic value Amazon can bank as goodwill — reskilling and training centers for the post-AI labour market, in the very buildings that AI-era infrastructure now occupies, in the very towns that lost the retail jobs. For a company whose UK labour reputation is often heqavily scrutinized in the media, putting something genuinely useful back into those high streets is worth more than the floor space.

Even if Amazon doesn’t run it’s own retail space for it’s own enterprises, the operating model is the bit Amazon already understands: it runs and maintains the whole building, and where there are third-party ground-floor tenants, bills them through a service charge — the same arrangement any multi-let landlord uses, only here the landlord is running an AWS region upstairs and a fulfilment node downstairs.

A genuine win-win — if we keep it honest

Lay it all out and the alignment is almost too neat. Amazon gets prime, central, energised real estate at distressed-retail prices; sidesteps the worst of the connection queue; lands AWS and AI capacity close to users; and gives its e-commerce arm a last-mile footprint in the dead centre of town - all from a single class of cheap, overlooked building. The high street gets sustained private investment, a reason for footfall, and an anchor tenant with very deep pockets and no intention of leaving. And the town gets a community or skills asset funded by a commercial operator that’s still making a perfectly healthy return.

That’s the optimistic version, and I think it’s achievable. But I’ll end where I usually do on these ideas: this only works if it’s done in the open and within a competitive market. The very thing that makes Amazon perfect for this - that it already owns the cloud, the logistics and the retail brand - is also what should give us pause. There’s a version of this where one company quietly buys up the energised bones of the British high street and ends up owning both the compute and the commerce and the civic space of the places we live. National and community assets developed under a private umbrella are a fine thing right up until that umbrella becomes the only one in town.

Done well, the empty shop becomes the most useful building on the street again. We should just make sure it belongs to more than one landlord though; and so there’s as much opportunity for Oracle, Meta and Microsoft to deploy similar models also, although their benefits are not quite as clearly demarcated.

TH

Share

Find me on Linkedin

You may also find these of interest: