Software has gotten very good at observing the world and very slow at understanding it. The result is operations that are heavily instrumented and barely comprehended. We think the next useful step is not another dashboard.
Walk a factory floor with an experienced engineer and watch what they carry in their head. They know what each machine does, how the lines depend on each other, what normal sounds like, and what does not. They can stand in front of a stalled conveyor and reason from the symptom to a likely cause before they have opened a single screen. That working model of the operation is the most valuable thing in the building, and almost none of it lives in software.
This is the gap our research keeps returning to. Over the last decade, industrial software got very good at one thing: observing. We instrumented everything. Sensors, historians, supervisory systems, and dashboards now capture more about an operation than any person could read in a lifetime. What we did not build is understanding. The software stores readings and draws charts, and it leaves the act of understanding to the person reading them. The operation ends up heavily instrumented and barely comprehended.
More Data Was Never the Bottleneck
The common response to an operational problem is to add another view. Another dashboard, another alert, another report. Each one is reasonable on its own, and together they produce a workplace where the answer to almost any question technically exists somewhere, and finding it under time pressure is its own full-time skill.
The bottleneck was never the availability of data. It is the absence of a system that holds a model of how the place actually works.
Here is what that costs, measured. An engineer knew that a 24 V output from their controller told an upstream flex conveyor it was safe to feed. They did not know the tag name, the routine, or the conditions, and they had been searching a 112 MB export by hand for eight or nine minutes without finding it when they asked. Tracing it returned the answer in about twenty seconds: the output, its four permissives, and the rung text behind each claim.
The interesting part is not the speedup. It is what the engineer was missing. Every belt on that line tells its upstream neighbor it can accept product through software, by passing a charge-enable bit into the next conveyor instruction. This one belt is the exception, because its upstream neighbor lives on a different controller, so its charge-enable leaves software and becomes a physical 24 V wire. Once you hold that topology, the odd output stops being odd. No dashboard holds that topology. It is a structural fact about the operation, and it lived only in the logic and in the heads of the people who had already gone looking for it.
Beside the Loop Means Reading Yesterday's Copy
This is where the distinction earns its keep. A system that sits beside the operation ingests exports and produces analysis after the fact. Exports lie, and they lie plausibly.
During a merge that was releasing product in slugs instead of its configured ratio, the obvious next move after clearing the deployed code was to read the tag values carried in the same export. Those values disagreed with a live read taken seventeen minutes earlier. Release counters only ever go up, and the export's counters were an order of magnitude below the live ones. A starvation override read active when the controller said it was inactive. The ratio read 3:1 when the controller was set to 4:1. A controller export embeds the project file's last stored offline values, not controller state at the moment of export, and every conclusion an analyst would draw off that column is wrong in a direction that looks reasonable.
The offline structure tells you where to read. The live values tell you what is true. A system that only has one of those is guessing about the other half.
That cuts in the other direction too. When four lanes were cleared out of an OEE metric and the engineer then dropped a zone enable to physically stop the belts, the belts kept moving. Two intuitive hypotheses followed, that the change had not stuck and that a larger enable would catch it, and both felt right. A handful of live reads disproved both and relocated the cause to a layer below the controller, where motorized roller cards run their own local accumulation logic and drain trapped product regardless of whether the zone has permission to run. Offline analysis could not have reached that. The alternative path was dropping progressively larger enables on a production line.
Reading Three Sources as One Picture
When we say intelligence should live inside the loop where work happens, we mean reading control logic, supervisory data, and the documents that describe an operation together rather than as separate feeds. The logic says how the system is supposed to behave. The live data says how it is behaving. The documents say why it was built that way. An engineer fuses those three constantly and effortlessly. Software almost never does, because the three were built as separate products owned by separate vendors.
The five hour palletizer stop is the cleanest demonstration we have. That diagnosis took the export for the rungs and the constants, live reads for which condition was actually false, and the floor to confirm the pallets were physically empty. There were two stacked root causes, and neither one is visible in any two of those three sources. A daily camera calibration flag that never re-set, gating every host move behind a status code. And a first-scan rung that assumes every pallet is full, armed by the very mode cycle used to diagnose the first cause.
Documentation counts as a source in the same way, including its absence. Reading an OEE state machine out of vendor instruction bodies produced an exact answer about states and thresholds, and it also produced a boundary: the service that computes the availability percentages could be named from a comment inside the instruction and not read, because it was not in the corpus. Naming the edge of what you can see is part of the answer, not a failure to answer.
The interesting unit of intelligence in an operation is not a prediction. It is a model of how the place works that stays current and can be reasoned over.
Why We Build to Find Out
We are a research lab, and the temptation in research is to study this on clean abstractions. The abstractions lie. The only honest way to learn whether a system can understand an operation is to point it at a real one, where the logic is messy, the documentation is stale, and the cost of being wrong is measured in downtime. That is why Nexus runs against production controllers and live hardware.
Building it taught us things no benchmark would have.
Most fault diagnosis turns out to be a traversal problem rather than an inference problem. A cross-reference on that cross-controller permit tag returned exactly one reference in the entire project, which is what a hardwired output to another controller looks like from inside the logic, and that single fact settled the question. The information needed to resolve a fault is almost always already present in the control system. The difficulty is reaching it and presenting it. The full dependency graph behind that one bit came back with 219 nodes, all correct and far more than anyone wants to read, which is a presentation problem rather than a retrieval one.
The value is also not in the system being clever. It is in being complete where a person under pressure takes a shortcut. When an engineer asked whether disabling two zone enable bits would reach the rest of a large control area, the useful answer was an untruncated cross-reference on both tags showing no motor outside the lane commanded by either bit, plus the finding that the shared merge conveyor at the end belongs to the adjacent zone. That is the difference between the command being contained and the flow being contained, and it is the answer an engineer can check in their own editor before touching a running area.
And we learned where the system has to stop, which turned out to be a sharper line than expected. The engine reads. It does not write. Across these sessions the corrective actions were taken by people: an engineer clearing enable bits, a controls engineer writing pallet counts back to empty, a technician chasing a motor cable.
The Shape of the Bet
The bet underneath all of this is that the next useful step in industrial software is not another layer of observation. It is comprehension. A system that holds the model an expert holds, keeps it current, collaborates with the people who run the operation, and, eventually, acts inside it with guardrails an operator can stand behind.
That last part is the furthest edge of the work, and it is not shipping. Forge and Atlas are where those questions live: what verification and accountability let a system act, and what it takes to keep a living model of an operation current as it changes. Nexus is the one running on a floor today.
We are early on a long arc, and the direction is clear enough to commit to. We are not trying to give operators a better view of their data. We are trying to put understanding where the work happens, in the loop, not beside it, and to find out where that idea holds and where it breaks.