VARCOTT
Engineering software for liquid-cooled AI factories

The limit of a hall is set by one device on each path, and that device moves.

A rack is served by a chain of devices between the utility and its power shelves, and by a second chain between the facility water and its cold plates. Its real limit is the device on those chains that is closest to its own limit at this hour, and that device changes with the load, the weather and the configuration. VARCOTT models the devices of a liquid-cooled hall from their makers' data, keeps the record of how they connect true to the hall, and computes that limit every hour. The same model answers four questions an operator has.

A reference hall, illustrative numbers: the power and the coolant of one row move through the day at the pace the model sets, and the device in blue is the tightest on the path at that hour.
01 · Where you are

The four questions are asked by different people in the same hall, and each has its own page.

The pages share the model, the record and the alarm engine underneath, so whichever question you start with, the next one is partly answered already.

Capacity · the facilities and electrical lead

How many more racks can this hall carry, and which device stops it carrying more?

A hall built to the sum of nameplates leaves part of its provisioned power unused, because the limits were set once at design with a margin at every level. VARCOTT computes the real continuous limit of each device per hour, names the tightest device on each group's path, and sizes the racks you can add to the hottest hour the hall will see while that limit is in force. The first step is a headroom study on one operating hall.

Usable megawatts
Utilisation · the people who place the load

How much work can this hall take tonight, on which rows, until when?

An inference hall is paid for at its busiest hour and runs well below it at night. The same limit, computed per row for the coming hours, tells the scheduler how much batch work the facility can admit without the night becoming the hour every device is at its limit. The gain is measured on the racks, group against group.

The hours
Operations · the shift and the controls engineer

Is this alarm real, is it one rack or the whole loop, and what did the system already do?

Alarms from the building management system, the power monitoring, the coolant distribution units and the leak detection land in one list under your alarm matrix. Each is judged on its value and on the quality of its data, and the readings that answer the shift's questions sit beside it. After an event, the timeline and the record the grid operator asks for.

Alarms and events
Records · the DCIM owner and the commissioning lead

Is the record of what is connected to what still true, and will this change hold?

The record of panels, phases, breakers, whips, coolant branches and leak zones is checked against the hall's own readings every day, so a wrong record is found before a wrong decision. A move, add or change is predicted before it is made and confirmed after it. Commissioning of a liquid-cooled hall is verified against the model, and the calibrated model is the deliverable.

The record that stays true
02 · What is common

Inside the hall the parts repeat, so the models, the records and the alarm sets are built once per generation and fitted to each site.

The rack, its power shelves, the coolant distribution unit and the leak response of a liquid-cooled AI hall follow published designs and repeat from hall to hall. The physics of each of those parts is the same wherever it is installed, so VARCOTT models each class once per platform generation from its maker's data. What differs per site is how the parts are connected, the redundancy, the plant upstream, the climate and the controls, and that is what the record and the fitting capture. The models are then solved together as one hall, on one clock, so what happens in the power distribution shows up in the coolant loop and in the GPUs in the same step; the limit of a group of racks, the evidence beside an alarm and the check of a record all come from that coupled solution, not from any device on its own.

The cooling-loop model covers the coolant distribution unit with its heat exchanger, pump, valve and controls, the manifolds, the pipes and the racks' cold plates, and is verified test by test against the Lawrence Berkeley National Laboratory's Modelica Buildings library. The power-distribution, facility-water and GPU-heat models are built the same way, each device from the standards and the maker's curves, and where a maker provides its own model or performance data we use it. The alarm engine follows the ISA-18.2 alarm lifecycle and runs on live data. All of it runs on your own hardware, reads the systems you already have and writes to none of them. The engineering page explains the parts, the models and how they connect to the vendor's software.

Engineering
03 · Integration

The GPU vendor's software takes the facility's limits as an input the site supplies, and VARCOTT produces that input from the models.

The vendor's power controller caps GPUs inside a power budget and imports the facility topology as a file with one operating limit per device. VARCOTT produces that file with the limit computed rather than typed, publishes the facility's state and margins on the same event bus the vendor's tools read, and keeps everything that needs a facility engineer's signature on the facility side. If you build or integrate software for AI factories, the conversation we are looking for is technical: what the facility side can give your software that a nameplate cannot.

Ask for a technical conversation
04 · Next step

Start with one hall and one question.

Each page above ends with its own first step, scoped in one call. If you are not sure which question is yours, describe the hall and we will tell you where we would start.