ASHRAE 90.1 · Direct-to-chip
Data centres & AI compute
Above 100 kW a rack, liquid cooling isn't an upgrade — it's the design. Lose flow and the silicon throttles before a human reads the alarm.
Mission-critical HVAC · data centre cooling · critical environments
The AI operating layer for mission-critical cooling.
Your chillers, CDUs and air handlers are physical machines, and your BMS, DCIM and controls already watch them. Running the response still happens outside all of it, on a phone at 03:14. This layer reads the same equipment and closes that loop.
Reads physical equipment through the systems you already run. Takes no control authority over any of it.
03:14A phone call
Where the loop is still manual0%
of organisations hit by a major outage believe better process would have prevented it
0×
rack density in a decade — roughly 5 kW to over 100 kW per rack
0
setpoints, valves or start commands it writes — read-only on the plant, by design
Uptime Institute annual outage analysis · industry rack-density reporting · read-only by design
01Mission-critical HVAC
One operating layer over every system that already watches your cooling.
It reads what your building systems see, works out what is actually wrong, and runs the repair through to proof.
01
It unifies what you already run.
BMS, BAS, DCIM, controls and sensors read into one place. Read-only — it takes no control authority and cannot change a setpoint.
02
It works out what is actually wrong.
Fifty alarms from one failing pump collapse into one incident, with one root cause, one owner and one clock.
03
It runs the work, and proves it.
The certified and cleared technician, the approved procedure, and telemetry confirming the condition genuinely cleared before anything closes.
03:17
Fifty alarms just came in. What is actually wrong?
Reading the BMS, the DCIM and the chiller plantRead the BMS, the DCIM and the chiller plant3 sources · 0.8s
All fifty are one incident. CDU-2E is losing differential pressure, and the two racks behind it are already above their class limit.
Alarms in50
Incidents out1
Affected load88 kW
Margin left9 min
What hangs off CDU-2E2 racks · 88 kW
| Asset | Reading | State |
|---|---|---|
| CDU-2E | Δp falling | Root cause |
| RACK-14 | 31.4 °C | Above class |
| RACK-16 | 30.8 °C | Above class |
Sent to the one OEM-authorised technician on shift, with the approved procedure attached.Closes on telemetry, not on a tap
One incident, end to end: fifty alarms read, one cause named, the qualified hand sent.
02Why not the software you have
Cooling stopped being comfort. The software didn't notice.
Building HVAC software was designed for comfort — schedules, setpoints, tenant complaints. A data centre, a hospital, a fab runs cooling as infrastructure. Same equipment, entirely different job.
The systems stop at 03:17. The incident doesn't.
Most software tells you a number moved.
We tell you what sits downstream of it, and how many minutes of margin are left before it matters.
Most software finds the nearest technician.
We find the one who is certified, cleared, on shift and permitted by the manufacturer to open that unit.
Most software closes when somebody taps Complete.
We close when the telemetry says the condition cleared — and reopen it when the telemetry disagrees.
03The operating layer
Devices below. Work above. One layer in between.
Your devices already produce the signal. Your teams already do the work. Nothing has ever owned the layer between them — so it happens on a phone call at 03:14.
The middle plane is the product. Everything else on this page hangs off it.
The physical layer
The subject of this software is machinery.
Every decision the layer makes begins at a piece of equipment — a compressor, a pump, a coil, a valve — and ends with a person who put their hands on it. It reads the plant. It does not command it.
Equipment it reads
- Chillers
- CDUs
- CRAH · CRAC units
- Cooling towers
- Pumps & valves
- Rear-door heat exchangers
- VFDs & meters
- Temperature · pressure · flow sensors
How that state reaches it
- BMS · BAS
- DCIM
- Controls · SCADA
- Historians
- OEM gateways
- Meters & sensors
Read-only on the plant. It reads equipment state and writes work to people — never a setpoint, a valve position or a start command. Those write scopes are not requested and not available.
Equipment classes and protocols are proven one site at a time with design partners. We name an integration once it is running on real plant, not before.
04Critical environments
Seven places where an excursion is a loss, not a complaint.
The equipment is ordinary. The tolerance, the redundancy and the paperwork around it are not.
Different standards, different consequences, one identical gap between the alarm and the qualified hand.
05Mission-critical HVAC, answered
Mission-critical HVAC, answered.
The questions that come up in every first conversation, including the ones that are really objections.
What is mission-critical HVAC?
Mission-critical HVAC is cooling for facilities where a temperature excursion causes loss rather than discomfort — data centres, hospitals, laboratories, cleanrooms and process manufacturing. The equipment resembles commercial HVAC. The tolerance, the redundancy and the governance around it do not.
How is data centre HVAC different from commercial HVAC?
Data centre HVAC is designed with redundancy, so a single failure rarely reads as an outage until the margin is already gone. Rack densities above 100 kW require liquid cooling loops, CDUs and rear-door heat exchangers rather than air alone. Access is governed by procedures and clearances that decide who may touch the equipment at all.
Does it connect to our physical equipment, or only to our software?
It connects to the physical equipment — chillers, CDUs, CRAH and CRAC units, cooling towers, pumps, valves and the sensors on them — through the software already wired to that plant. Live state arrives by way of the BMS, BAS, DCIM, controls, historians, meters and OEM gateways, and every one of those connections is read-only. Equipment classes and protocols are proven one site at a time with design partners, which is why none is named here as supported yet.
Doesn't the BMS already do this?
A BMS controls and observes equipment, but it does not run the response. It does not know which technician holds the OEM authorisation for that CDU, whether the required MOP was approved, or whether the repair actually cleared the condition. That work happens outside it, on a phone.
How is this different from a CMMS like Maximo?
A horizontal CMMS receives every alarm as its own event, so one failing pump can open fifty work orders for fifty downstream sensors. This layer holds the cooling chain, so it correlates those fifty signals into one root cause and gates dispatch on live certification and clearance rather than attaching a PDF checklist.
Is this predictive maintenance?
No — it acts on the condition the equipment is in now, not on a forecast of one. Predictive tools score the probability of a future failure; this layer takes a live physical condition, works out what sits downstream of it and how much thermal margin is left, and runs the qualified response through to verified closure. Failure prediction is a research direction here rather than a claim, and it will be described as one when a design partner's telemetry shows it worked.
Couldn't we build this on Dynamics 365 or Salesforce Field Service?
You could, and integrators charge accordingly. Both ship the generic IoT-alert-to-work-order pattern as building blocks, both are designed to manage internal teams inside one tenant, and neither understands cooling topology out of the box. The hard parts are correlation across a thermal chain and orchestration between a facility owner and an outside contractor on separate systems.
Is this field service software, or something else?
It is field service software — a field operating system for mission-critical cooling. It runs the dispatch, the procedure, the technician and the closure, which means it replaces the platform doing that work today rather than syncing with it. What it does not replace is the observation layer: your BMS, BAS, DCIM and controls stay where they are, and we only read them.
06Design partners
Four weeks. Nothing connected until you say so.
We are looking for a small number of design partners running critical cooling at real scale. This is the whole commitment.
Who we are looking for
- Mission-critical service contractorsMechanical and precision-cooling divisions carrying uptime SLAs across other people's sites.
- Colocation & enterprise operatorsMixed-vendor plant across several halls, without a hyperscaler-sized engineering team behind it.
- Critical facilities managementIn-house technicians, OEMs and subcontractors under a single availability commitment.
The whole commitment4 weeks
- Week 1
Nothing connected
We map one cooling system with your team — assets, dependencies, alarm sources. Nothing connected. A whiteboard exercise that produces a model.
- Week 2
Read-only, one feed
A read-only connection to one alarm feed, in a DMZ or against a historian. It writes nothing, anywhere.
- Week 3
Replay, 90 days
We replay your last 90 days of alarms and show what correlation would have caught, missed, and got wrong.
- Week 4
Shadow mode, live
Shadow mode on live alarms. Your team compares its call to ours on every incident, then decides whether this was worth the time.
Before you apply
- Which system raises your cooling alarms today?
- What happens between that alarm and someone qualified arriving on site?
- Where in that path do you lose the most time?