What We Learned Pointing Nexus at a Real Site

Nexus is the first place our research meets real industrial systems. It reads a site's control logic, supervisory systems, and documentation together, and reasons over them to diagnose faults and answer questions in plain language, cited to the exact rung. We have run it against two dozen full production controllers exported straight off working sites, some of them 110 to 160 megabytes, and validated its live read and diagnosis against a real running controller. That contact with reality, rather than a simulator, changed what we believed about the problem. These are the notes.

Diagnosis Is Mostly Retrieval

We went in expecting the hard part to be reasoning. It was not. On a real controller, the information needed to resolve most faults already exists inside the control system. The alarm points at a tag, the tag maps to a rung, the rung depends on a permissive, the permissive depends on a module's state. The chain is fully determined. Nobody needs to be clever to follow it. They need to follow all of it, quickly, without skipping a link.

That reframed the whole system for us. The value of Nexus is not that it reasons better than an experienced engineer. It is that it traverses the complete dependency graph every time, while a person under pressure pattern-matches to the most likely cause and stops. Most of the time the shortcut is right. When it is wrong, it costs the rest of the shift. Our engine does that traversal deterministically: a root-cause trace on a 110 megabyte controller returns in tens of milliseconds, at zero model credits, identical every run. The retrieval is the part that has to be exact, and it is the part a probabilistic model should not be doing alone.

The Model Has to Read What the Engineer Reads

The second lesson was about inputs. Early on we were tempted to feed Nexus clean, normalized data. Real sites do not have clean, normalized data. They have an Ignition project, a set of Studio 5000 exports full of nested Add-On Instructions, and device diagnostics from the network, none of which agree on naming and all of which assume a human will bridge the gaps.

Nexus only became useful when it read those sources the way the engineer does, together and in their native messiness, rather than waiting for someone to clean them first. The messiness is the job. A system that requires the operation to be tidy before it can help will never help, because operations are never tidy. The proof we cared about was not a synthetic benchmark: it was the full tool surface running across 24 real production controllers with zero parser errors, and 137 of 137 AI-written program documents graded rung-accurate by three independent Controls Engineers.

Completeness Beats Confidence

The most valuable diagnoses were not the obvious single-sensor faults. An experienced engineer finds those quickly with or without a system. The high-value cases were the faults with several contributing conditions, where the first cause looked sufficient and the second one was hiding.

We have measured exactly this gap. On a blind study over one real controller, we ran eleven frontier models two ways: alone over the raw export, and connected to the engine. Asked which of two online edits was actually executing, the models got it right zero times out of thirteen on their own and eleven out of eleven with the engine underneath. On a deep trace with 37 genuine root signals, a model grepping by hand reached between four and thirteen of them. With the engine it returned the complete set, cited, every time.

That kind of systematic, exhaustive cross-referencing is exactly what a person cannot do in real time while a production manager is asking for an ETA. It is also exactly what a system holding the full model does for free. Completeness is worth more than confidence.

Knowing Where to Stop

The lesson that mattered most was about the boundary. There is a clean line between the part of diagnosis that is retrieval and the part that is judgment. Tracing the dependency chain to a root cause is retrieval, and Nexus owns it. Deciding whether a degraded module should be replaced now or nursed to the end of the run is judgment, and that stays with the engineer.

This is built into the system on purpose. Nexus reads live values, diagnoses, and recommends; acting on the site stays behind human confirmation and never touches safety logic. Moving a system safely from analysis to action is the hard frontier, and we are deliberate about earning each step of it. We did not have to argue people into trusting the read and the diagnosis, because we made the boundary legible. When Nexus shows its trace, the path from symptom to cause, the engineer can see exactly what it did and confirm it against one physical observation. Trust came from transparency, not from accuracy claims.

What Held Up

What held up is the architecture. A deterministic engine does the exact retrieval and cites it; the model renders that into plain language. That split is why the system gets better as the models on top of it improve, instead of being replaced by them. We validated the live read and diagnosis against a real running controller, where the engine evaluated a root-cause graph of more than a thousand nodes against the live conditions and named the blocking cause, graded right against independent ground truth.

The end goal is bigger than fault diagnosis. We are building toward a system that holds a complete, current model of how an operation runs and reasons over all of it, the logic, the live values, the documents, the history, as one connected picture, so the knowledge that used to live in a few engineers' heads is answerable by anyone, with receipts. Nexus is where that research first meets a real site. It is one expression of our Operational Intelligence work, and it is the one teaching us the difference between studying understanding and watching it hold up where being wrong costs real money.