Most of the current conversation about physical AI and IT/OT convergence asks the same question in different clothes: how do we act on operational data faster? PLM, MES, SCADA, and ERP get stitched into a unified intelligence layer, an AI model predicts a failure, and the system schedules maintenance before the failure happens. That is a real capability, and it is worth building. It is also the easy version of the question.
The harder question is the one most of these architectures are not built to answer: should this workflow exist at all?
Automation inherits the workflow. Intelligence interrogates it.
Connecting PLM, MES, SCADA, and ERP into a common data layer is table stakes now — the industrial AI vendors pitching Lighthouse factories and IT/OT convergence have made that case well. But a system that ingests those sources and gets faster at executing the existing process is still operating inside the process's own assumptions. It never asks whether the process is the right one. A step that exists because a machine required manual calibration in 2011 gets automated in 2026, not questioned.
Asking "should this exist" requires something different from a prediction pipeline. It requires a system you can converse with — one built on top of the same PLM/MES/SCADA/ERP data, but oriented toward open-ended questions rather than a fixed dashboard of KPIs. A RAG pipeline against those sources, augmented with a reasoning layer, can start to answer why a workflow exists, not just how to run it faster.
Open-weight models can be a legitimate part of that architecture, particularly where deployment control, customization, or OT data constraints make local inference valuable. But model choice is not the hard part. The hard part is deciding what questions the intelligence needs to be able to answer in the first place.
Three question types, three different problems
I'd break the questions an industrial intelligence layer needs to handle into three categories, because they are not the same problem and they do not get solved the same way.
Predict — what will happen. This is the most mature category and the one most physical AI pitches are built around: forecast a bearing failure, a quality drift, an energy spike. It has a clean feedback loop. The sensor stream eventually confirms whether the prediction was right, so historical replay against real outcomes gives you a reward signal you can train against.
Prevent — what should happen to avoid a bad outcome. This is harder, because the ground truth is a counterfactual: the failure that didn't happen. You cannot observe that directly. The signal has to come from a digital twin generating synthetic ground truth, or from engineered root-cause logic that encodes what a domain expert already knows about failure modes. This is closer to the layered anomaly-detection and root-cause work I did a decade ago at Sev-1 scale — that kind of engineered causal structure is a more credible reward source here than open-ended model reasoning alone.
Eliminate — whether the workflow should exist. This is the one almost nobody is building for, and it is not a claim about machine behavior at all. It is a claim about a human process wrapped around the machine. There is no sensor reading that confirms "removing this step was correct." The ground truth is a business outcome — cycle time, cost, error rate — that shows up weeks or months later, after an organizational change, not after a single inference. It is a slower, noisier signal, and it needs a different evaluation loop: human-in-the-loop review, or a staged trial of the process change itself, not a replay of historical sensor data.
| Question type | Where the ground truth comes from | How a recommendation gets evaluated |
|---|---|---|
| Predict | The sensor stream itself — the outcome is directly observed | Historical replay against real outcomes; a clean reward signal you can train on |
| Prevent | A counterfactual — the failure that didn't happen, which is never observed directly | Synthetic ground truth from a digital twin, or engineered root-cause logic encoding known failure modes |
| Eliminate | A business outcome — cycle time, cost, error rate — visible weeks or months later, after an organizational change | Human-in-the-loop review or a staged trial of the process change; no sensor replay can confirm it |
Training a system to answer all three the same way is where these projects quietly fail. The model can sound equally confident predicting a bearing failure and recommending you eliminate a QA checkpoint. Only one of those claims is actually grounded in a directly verifiable feedback loop.
What this looks like on the manufacturing floor
Consider a recurring quality checkpoint in a manufacturing process.
- Predict tells you that process conditions are trending toward an out-of-spec result.
- Prevent identifies the intervention needed to keep the process within tolerance.
- Eliminate asks a different question: if continuous sensing can demonstrate process stability, prediction can identify excursions early, and intervention can prevent them, does every scheduled manual checkpoint still need to occur — or can some of that work become exception-based?
The objective is not to eliminate the control. It is to ask whether intelligence allows us to preserve or improve the control while eliminating the work that historically existed to provide it.
That distinction matters. Physical AI should not simply make an existing quality process faster. Its economic value may ultimately come from changing how the control objective itself is achieved.
Reasoning has to be engineered, not assumed
This is also why "the model can reason" is the wrong starting assumption.
A model does not arrive with causal judgment about your plant. What looks like useful reasoning emerges from the system around it: the context it receives, the sequence of questions it is asked, the operational evidence it can retrieve, the constraints it must respect, and the feedback against which its recommendations are evaluated.
That makes reasoning quality as much a harness and evaluation problem as a model-selection problem.
For eliminate-type questions, this becomes especially important. The system isn't simply predicting an observable machine state. It is recommending a change to an operating model. The quality of that recommendation therefore depends on how deliberately the system incorporates process context, SME judgment, organizational constraints, and eventual business outcomes.
The harness has to structure how the model encounters that evidence and how its conclusions are challenged. What looks like reasoning is not something an enterprise should simply assume because a model performs well on a benchmark. In an industrial environment, reasoning has to be grounded in the operating context in which the recommendation will actually be acted upon.
Open-weight models can make parts of this architecture attractive where an organization wants greater control over deployment, adaptation, data handling, or model behavior. Frontier models may be appropriate where their capabilities justify a hosted architecture. Hybrid approaches can use both. The architectural choice should follow the operating requirement rather than become the strategy itself.
The model matters. But the quality of an eliminate-type answer depends at least as much on how deliberately the system has been taught what evidence matters, what constraints cannot be violated, and how a recommendation will eventually be judged.
Define the questions before you build the harness
The instinct across most industrial AI investment right now is to build the data foundation first and assume the reasoning capability will follow. It is closer to the other way around.
Define which of the three question types — predict, prevent, eliminate — the intelligence actually needs to answer for a given workflow, because that decision determines what evidence is required, what feedback signal is available, and therefore how the reasoning and evaluation harness needs to be designed.
Skip that step and you get a system that is fluent on all three and reliable on maybe one.
The organizations that will get real value out of physical AI are not necessarily the ones with the most complete data layer or the most capable model. They are the ones willing to ask a system built on top of that data layer the uncomfortable question — not "how do we run this faster," but "does this need to run at all" — and are prepared to act on an answer that eliminates work rather than automates it.