What the AI Learns, and What It Is Never Allowed to Learn
Any system that can act on a building raises an obvious question: what stops it from doing something dangerous?
The usual answer in this market is a confidence score and a reassurance. Ours is structural. In TwinWorX, the parts that use judgement and the parts that set limits are different things, kept in different places, and only one of them is allowed near your equipment.
Three jobs, kept apart
The language model authors. It does not act. TwinWorX uses a large language model for the work that calls for language: drafting a fault rule from a sequence of operation, explaining a fault in plain English, summarizing what happened overnight. What it produces is a written rule your engineers can read before it ever runs. Its judgement is confined to authoring time. A language model never acts on your building.
The rule engine governs. Before anything executes, it is checked against hard safety limits, interlocks, and the relationships in your model. Is this a property this asset actually has? Is this value inside the safe range? Does it conflict with a sequence already running? Those limits are set by your engineers, and they are not learned. Where a proposal and a limit disagree, the limit wins, and the disagreement is logged. It proposes; a deterministic engine disposes.
Machine learning calibrates. The engineer diagnoses. Machine learning does one more job, and a narrower one than the market usually implies. It learns what "high" means for your particular asset: this air handler, at this load, in this season. It does not apply a number from a textbook to two thousand pieces of equipment. The engineering knowledge stays in the rule your team wrote. The calibration is what gets learned.
Why the result names a cause
Because the rule carries the engineering, what reaches your team is a fault with a cause attached.
Approach temperature running high, valve ninety-one percent open, load moderate, fouling signature is something an engineer can accept, challenge, or overrule on sight.
This asset is behaving abnormally, confidence 0.83 is not. A system that produces enough of those is switched off in year two.
Anomaly detection has its place. It catches what no rule anticipated. But an anomaly score is not a diagnosis, so it belongs in its own clearly labelled stream, where an operator always knows whether they are looking at a statistically unusual reading or a confirmed fault with a cause.
What approval does, and does not, do
People reasonably assume that a system which asks for approval is learning from the answers. In TwinWorX, approval does something more useful and more limited than that.
Autonomy is a ladder of four steps, not a switch:
Advise. The platform recommends. Your team decides what to do.
Approve. It proposes an action. Nothing runs until a person approves it.
Execute reversible. It acts on its own, but only where the action can be undone.
Execute. It acts on its own, within the limits your engineers set.
A facility opens on the first two steps. Each approval adds to the evidence that a strategy behaves the way your team expects on your equipment. A strategy moves up a step only on that accumulated evidence and on your sign-off, and you can move any step back down at any time, without us.
So approvals decide how far a strategy is trusted. They do not move the safety envelope. Nothing does. That stays where your engineers put it.
The boundary around all of it
Two things sit outside the ladder entirely.
Life-safety stays where it is. Fire and other code-mandated functions remain wholly within their native systems, connected read-only. TwinWorX supervises them. It does not replace safety systems, and it is not in the path of anything that protects people.
Every writeback runs behind seven controls: per-point enablement, elevated authorization, rate limiting, mandatory readback confirmation, automatic reversion to local control if communication is lost, immutable audit, and manual override, always available.
Why we built it this way
Most of the market sells full autonomy as the opening pitch. We have watched what happens when a system with authority acts on data it should not have trusted. In buildings, sensors drift, meters fail quietly, and points get renamed in a retrofit, and almost no building has the redundancy that lets you trust a reading without checking it.
Keeping judgement and limits apart, and letting autonomy climb only on evidence, is the slower answer. It is also the only version we have seen survive contact with a working operations team.
Ask us what it is allowed to do on your equipment.
Thirty minutes with one of our engineers.
