How TwinWorX works
1 model of your operation. 3 stages of what you can do with it.
TwinWorX is an open, intelligent digital twin platform for operating and optimizing the built environment. It connects the systems you already own into one live model of your operation, and what you do with that model grows in three stages, at your pace.
One platform for campuses, hospitals, portfolios, ports, and industrial sites.
Start with the model, not the dashboard
Most operational software treats your operation as a list of points. It knows the values. It does not know that the valve feeds the coil that conditions the air that serves the room the reading came from.
TwinWorX holds that structure: every asset, every space, and how they relate. That is how it traces a comfort complaint to a stuck valve two systems upstream, and it is what all three stages read from. Connect it once. Name it once.
1
Stage 1 of 3 · What is happening?
Connect everything. See everything. Control what needs controlling.
Situational awareness and command control
**Illustrative operator view: one air handler, in focus from its alarm.
Connect what you already own.
Building automation, metering, lighting, access, process, and clinical systems, from any vendor and protocol. TwinWorX sits above your existing controls; nothing is ripped out.
See it in one place.
From a portfolio map down to a live equipment schematic, with views built for each role and alarms that reach whoever is on call, on their phone.
Alarms with context, commands with a record.
Every alarm arrives knowing its asset, its space, and what is upstream of it. Every command is authenticated and audited. A historian is included, with no tag limit and no retention limit.
Stated plainly: nearly every client starts here, and it is worth having on its own. Without it, analytics has nothing to work on and autonomy has nothing safe to control.
MOVE TO STAGE 2 WHEN
The data underneath is worth analysing.
Go deeper: the TwinWorX platform technical overview →
2
Stage 2 of 3 · What is wrong, and what is it costing?
Find what is wrong, what it costs, and what to fix first.
Analytics
It arrives knowing your equipment.
More than 1,000 fault rule templates across more than 120 equipment classes, from chillers to steam plant, switchgear, and medical gas. Your team adds its own in plain English, with no change order.
Root cause, not symptom.
Faults are traced through the model to the cause, with the alarms it produced grouped under it. TwinWorX Copilot explains any of them in plain language, from your model.
What to fix first, in dollars.
Faults are ranked by cost and by how often they recur, then sent to your work order system with the diagnosis attached. Energy shows actual against expected, weather normalized, building against building.
Stated plainly: rules that depend on timing need two to three months of normal operation to tune. Dollar figures are engineering estimates, not verified savings.
MOVE TO STAGE 3 WHEN
Your team has watched it long enough to trust it.
Go deeper: inside the TwinWorX fault library →
3
Stage 3 of 3 · What should be done, and who decides?
Earn the autonomy before you hand over the keys.
Analytics
A ladder, not a switch.
It advises first, then proposes actions a person approves, then acts on its own where an action can be undone, and only after that on any action within your limits. Each step is promoted on evidence and your sign-off, and you can take any step back at any time, without us.
A language model never acts on your building.
It proposes; a deterministic rule engine checks every proposal against limits your engineers set. Life-safety systems stay connected read-only, and every writeback runs behind seven controls.
Automation you build.
Workflows run sequences across every connected system. An air handler's functional performance test, for example, runs overnight and leaves a test record by morning.
Stated plainly: this is the slower answer, and the only version we have seen survive contact with a working operations team. Almost nobody starts here, and we would talk you out of it if you tried.
Go deeper: what the AI learns, and what it is never allowed to learn →
Built for where you are going.
Deployed for where you are.
Why autonomy has to wait for the data
Every algorithm is limited by the data underneath it, and in buildings that data is often not good enough to act on. Sensors drift. Meters fail quietly and keep reporting. Points get renamed in a retrofit and nobody updates the drawing.
TwinWorX holds that foundation steady. Values are normalized and tagged against open standards, a device that stops talking is flagged the day it stops, data health is reported daily, and a rule will not evaluate on a stale reading. An action built on that is one you can defend.
Evaluating TwinWorX for your IT or security team? Connectivity, model ownership, deployment, AI governance, and security are on one page written for architecture and procurement review.
Bring us your systems list and your worst recurring problem.
Thirty minutes with one of our engineers. We will tell you which stage you are ready for, and if TwinWorX is not the right answer, we will say so.
Prefer to read first? Why e-Magic → · Where TwinWorX is used →