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 plant 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 was the absence of a system that holds a model of how the place actually works. A dashboard shows you a tag's value. It does not know that the tag is downstream of a permissive that lives three layers deep in logic written for a different line, or that the same module sits in the interlock chain of two other machines. The connections, the structure, the dependencies, all of that lives in the engineer, not the software.
What "Inside the Loop" Means
When we say intelligence should live inside the loop where work happens, we mean something specific. Not a model that sits beside the operation, ingesting exports and producing reports after the fact. A system that reads the same context an expert reads, in the same place, and reasons over it as one connected picture.
Concretely, that means 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 we built the three as separate products owned by separate vendors.
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. We have found that the abstractions lie. The only honest way to learn whether a system can understand an operation is to put it on a real floor, where the logic is messy, the documentation is stale, and the cost of being wrong is measured in downtime. That is why our first system, Nexus, runs on a working manufacturing floor rather than in a notebook. It reads a plant's control logic, supervisory systems, and documentation together, and reasons over them to diagnose faults and answer questions in plain language.
Building it taught us things no benchmark would have. We learned that most fault diagnosis is a graph-traversal problem, not a reasoning problem, because the information needed to resolve a fault almost always already exists in the control system. We learned that the value is not in the model being clever, but in it being complete and tireless where a person under pressure takes shortcuts. And we learned exactly where the system has to stop and hand back to a human, which turned out to be a sharper line than we expected.
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 is a long arc, and we are early on it. But 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. Everything we build is a way of asking that question more precisely, and finding out where the idea holds and where it breaks.