Cooling Begins at the Interface

A direct liquid cooling project can look mature in a slide deck and still be undefined at the one place that matters: the boundary between the servers and the building. Pumps may be sized, CDUs may be shortlisted and rack densities may be quoted, yet nobody has frozen which loop owns temperature, pressure, fluid quality, isolation or failure response.

That is why direct liquid cooling specification should begin at the interface, not with a product catalogue. In my view, the best specification is less about choosing a cooling technology than making every hand-off testable.

Fact: on 3 October 2026, a Schneider Electric technical article published by DCD highlighted material compatibility, contamination, server coupling, failure blast radius and unknown future rack density as recurring specification risks. The piece is vendor-authored, so it should not be treated as a neutral standard. Its practical point is nevertheless sound: liquid cooling physically couples infrastructure to the IT equipment in a way conventional room air does not.

Inference: that tighter coupling moves part of the technology road map into the real-estate and facility-design critical path. It also changes what investors, developers and operators should verify before calling a hall “AI-ready.”

The interface is the product

A useful design starts by separating three systems. The facility water system rejects heat at building level. The coolant distribution unit transfers heat and normally separates facility water from the technology cooling system. The technology loop serves manifolds, hoses, quick connects and cold plates at rack and server level.

ASHRAE’s 2023 data-center handbook chapter describes liquid-cooling classes by the maximum facility liquid supply temperature and notes that common architectures use a heat exchanger or CDU between facility water and IT equipment. The Open Compute Project cold-plate workstream produces requirements and guidance from the cold plate to the CDU, while its coolant distribution unit workstream focuses on integration with facility systems. Those references do not remove project-specific engineering. They give the parties a shared vocabulary.

For due diligence, I would ask for one controlled interface schedule showing, at each boundary, the design and operating supply temperature, return temperature, flow, pressure, pressure drop, fluid chemistry, filtration, materials, leak-detection logic and party responsible. If any field is marked “by vendor” without naming the vendor, model or acceptance test, the design is still an assumption.

This discipline is the cooling equivalent of distinguishing IT load from campus power. A headline density does not prove that the building can deliver the required flow and temperature across every operating state.

Three envelopes, not one design point

The specification needs at least three operating envelopes.

The first is the IT envelope. It should define supported server families, heat captured to liquid, residual air-cooling load, minimum and maximum flow, acceptable coolant, connection type and control response. “Up to 140 kW per rack” is not enough. A hall with a few dense racks and a long tail of lower-density racks can impose a very different hydraulic profile from a uniform deployment.

The second is the CDU envelope. It covers heat-transfer capacity, pump turndown, redundancy, controls, isolation, service clearances and concurrent maintenance. A CDU nameplate is not deliverable capacity if the equipment cannot maintain the required secondary-loop conditions during a pump failure, filter change or planned maintenance. Vertiv’s current CDU product overview illustrates how one product family can span liquid-to-liquid and liquid-to-air configurations. That flexibility is useful, but it also shows why “CDU included” is not a specification.

The third is the facility envelope: ambient design conditions, water temperatures, available heat-rejection plant, electrical load for pumps and fans, water treatment, freeze protection and the transition between economised and mechanically assisted modes. NVIDIA’s DSX facilities reference design uses a 45°C liquid-cooling design point and redundant CDU groups as part of a defined system architecture. This is a reported reference-design value, not a universal target. A different server platform, climate, heat-rejection method or operating philosophy may require another envelope.

The point is not to copy a reference design. It is to show, quantitatively, where the chosen project sits relative to one.

Readiness changes when the server is not yet known

Colocation and speculative developments face a harder problem: the future tenant and server bill of materials may not be fixed. Oversizing every pipe and CDU protects against one risk while creating cost, low-load control and stranded-capacity risks elsewhere.

I prefer a staged readiness model. The base building should reserve physical routes, structural loads, valve zones, electrical feeds, controls points and heat-rejection interfaces. Tenant fit-out should then select the secondary-loop modules against a declared server envelope. Expansion should be possible by repeatable increments, not by reopening the entire mechanical concept.

That approach belongs in development-readiness assessment, because cooling decisions interact with programme, procurement and energisation. It also belongs in pre-lease due diligence: the tenant schedule should say which interface parameters are conditions precedent, which are design-development items and which are performance guarantees.

My view: “liquid-ready” should never be a binary label. It should be a maturity statement. A site may be pathway-ready, plant-ready, CDU-ready or validated for a named IT platform. Those are materially different products.

Commissioning must cross the contractual boundaries

Individual factory tests do not prove that the system works as an integrated cooling chain. The commissioning plan should follow heat from the chip boundary to final rejection and back through the controls.

At minimum, the test script should cover low and high load, rapid load change, loss of a pump, loss of a CDU, filter fouling or simulated pressure increase, loss of communications, leak alarm, isolation of one rack branch, restart and operation during scheduled maintenance. Water quality and material compatibility need baselines and acceptance limits, not simply a maintenance recommendation.

This is where the data-center commissioning readiness evidence pack becomes decisive. The owner’s requirements, sequence of operations, points list, factory tests, site acceptance tests and integrated systems tests must describe the same architecture. If each package uses different loop names or temperature bases, the project is not ready to test.

Cooling should also be reconciled with behind-the-meter power assumptions and grid-upgrade scope. Pumping, chillers and heat rejection consume power; changing the cooling architecture can change the electrical balance and the amount of IT capacity that can actually be delivered.

Heat reuse is an output, not a slogan

Warm-water systems may improve the quality of recoverable heat, but reuse is not created by a high return temperature alone. A credible scheme needs an offtaker, a network, a seasonal load profile, compatible temperatures, redundancy, metering, commercial terms and a delivery programme.

The correct investment question is therefore not “does the design support heat reuse?” It is “what quantity and grade of heat is available, when, at which interface, and who is committed to take it?” The same evidence discipline used for community and permitting risk should be applied to the local heat system. Benefits should be supported by counterparties and infrastructure, not presented as automatic consequences of liquid cooling.

What I would require before approval

Before a cooling concept passes an investment or design gate, I would expect a controlled interface schedule, a named IT envelope, a facility-water operating map, hydraulic calculations for normal and degraded modes, materials and fluid compatibility evidence, a redundancy and maintenance narrative, a metering plan and an integrated commissioning script.

I would also expect every capacity statement to identify its basis. Schneider Electric’s 7.392 MW liquid-cooled reference design is useful precisely because it ties cooling to a defined AI cluster architecture. It should not be converted into a generic cost or capacity benchmark without preserving that scope.

PowerlandMap treats cooling readiness in the same way it treats market-intelligence evidence: source the claim, state the boundary, preserve the unit and expose what remains unverified. That matters for site comparison, investment underwriting and delivery management alike.

The central lesson is simple. Direct liquid cooling specification is not a mechanical appendix. It is the contract between compute and infrastructure. If that contract is explicit, testable and owned, liquid cooling can unlock higher density without hiding risk. If it is vague, the project may be “AI-ready” only in marketing copy.

For a structured comparison of cooling readiness alongside power, capacity, permitting and delivery evidence, request access to PowerlandMap.