Sovereign AI Cloud
The building decides the design
Rack density and cooling method constrain everything above them, and they are the layer most programmes discover last. A short account of why we walk the floor before we draw anything.
Design conversations tend to start at the top. Which models, which orchestration, which storage. That is the interesting end and it is where the people in the room have opinions.
The constraint sits at the other end, in a building somebody else designed several years ago for a different purpose, and it does not care about any of those opinions.
Layer 1
Where the binding constraint almost always sits
Last
Where most programmes look at it
Months
Lead time on the changes it forces
Three questions that settle most of the design
Before anything is drawn, three answers determine what is possible.
- What can a rack draw. Not what the specification says, what the distribution board and the upstream supply actually allow with the rest of the floor still running.
- How is heat removed. Air has a ceiling. Above it you are into liquid, and liquid is a facility project with a facility approval path and a facility lead time.
- What can the floor carry. Dense racks are heavy. Raised floors in older rooms frequently cannot take them where you want them, which changes the layout and therefore the fabric.
Every one of those has an answer that can be established in a day on site and cannot be established at all from a document pack.
You cannot assess a building from photographs, and a specification describes what was installed rather than what is available now.
Why the document pack is not enough
Facility documentation describes the design intent at handover. What has happened since is rarely written down. Circuits have been consumed by equipment that arrived one item at a time. Cooling capacity has been quietly committed. A room commissioned at a comfortable density is at its limit and nobody produced a document saying so.
We have walked into rooms where the available power was less than half what the pack implied, in every case for entirely ordinary reasons accumulated over years. Designing against the pack would have produced a system that could not be energised.
What changes when the constraint is real
Once the facility number is known, the design becomes a series of consequences rather than preferences. Density drives the node count. The node count drives the fabric. The fabric drives the storage placement. The whole stack falls out of the building, and it falls out quickly.
That is a better position to be in than it sounds. A design derived from a hard constraint is defensible in procurement, because every choice traces back to a measured fact rather than an argument about vendors.
When the answer is that the building cannot do it
Sometimes it cannot, and saying so early is the most valuable thing the assessment does. The options are then a facility upgrade with its own timeline and budget, a different site, or a colocation facility that already has the density.
All three are workable. What is not workable is discovering the constraint after the hardware has been ordered, which is where a meaningful number of programmes end up, holding equipment they cannot energise.
What to do before you talk to anyone about hardware
Get someone to walk your intended room and establish available power per rack, current cooling method and headroom, and floor loading in the specific bays you intend to use. Write down the numbers rather than the impressions.
Those three figures will tell you more about what you can build than any vendor conversation, and they will make every vendor conversation afterwards shorter and considerably more honest.
Start here
Establish what your building can carry before you order hardware.
Every sovereign cloud assessment includes a physical site visit to measure power headroom, cooling capacity, and floor loading.