Two pieces published this month, from two different vantage points, are describing the same unfinished architecture without naming it.
A Forbes Technology Council piece from a 40-year process control veteran argues that industrial AI should sit above trusted control as a decision layer, not replace it — that regulatory control keeps a plant stable, advanced process control coordinates it, optimization decides where it should run, and AI's job is to ask whether that target is still the right one. My own piece last week argued that physical AI needs to answer three structurally different questions — predict, prevent, eliminate — and that almost no one is building for the third one, because it doesn't have a fast feedback loop.
Put those two arguments next to each other and a gap opens up that neither piece closes on its own: nobody has specified what the data and retrieval architecture underneath all three of these question types actually looks like. Everyone agrees AI needs to sit above control, not inside it. Almost no one has said what "above" is built out of.
The control hierarchy and the intelligence hierarchy both stop one layer short
The process control hierarchy — regulatory control, APC, optimization — answers "how" and "what." Industrial AI, in that framing, adds "why": why is this still the right operating target given today's conditions, not yesterday's. That's a real and useful addition. But it still assumes the optimization loop is worth running. It never asks whether the workflow generating the target in the first place should exist.
My own predict/prevent/eliminate framing has the same shape from the other direction. Predict and prevent both live comfortably inside existing industrial AI investment — forecasting a bearing failure, recommending a corrective action before it happens. Eliminate is the one that asks whether the underlying process — the manual calibration step, the QA checkpoint, the approval chain — needs to run at all. I checked the maintenance maturity models this week: reactive, preventive, condition-based, predictive, prescriptive. Every one of them stops at "recommend the optimal action." None of them has a stage that asks whether the action, or the process around it, should exist. Schneider Electric's own framing of its Cognite acquisition describes the intended trajectory as predictive analytics maturing into autonomous recommendations and eventually closed-loop optimization — which is the industry's most capital-backed roadmap, and it still doesn't reach the elimination question.
So the gap isn't a gap in ambition. It's a gap in architecture. Nobody has built the thing that would let an organization ask "should this exist" with the same rigor it currently applies to "what will happen" and "what should we do about it."
The organizing principle: ground truth determines architecture, not the other way around
The three question types don't just need different models. They need different data architectures, because each one has a fundamentally different source of ground truth.
Predict is confirmed by the sensor stream itself. A forecasted bearing failure either happens or it doesn't, on a timeline short enough to train against. This is why time-series retrieval and streaming anomaly detection — layered metric streams evaluated in real time against learned baselines, the kind of architecture I built and validated at Severity-1 scale a decade ago — remain the right foundation for this layer. The retrieval problem here is temporal: what happened in this asset, in this window, relative to its own history.
Prevent has no direct observation, because the ground truth is a counterfactual — the failure that didn't happen. That has to come from somewhere synthetic: a digital twin generating simulated outcomes under different control actions, or engineered root-cause logic that encodes what a domain expert already knows about a failure mode. Recent digital twin research bears this out directly — twins that assimilate new observational data at each step and recommend the next control action, refining their own transition model as they go, measurably outperform static ones. That's a working example of a twin standing in for the counterfactual a sensor can't record. The retrieval problem here is relational and physical: what does this asset's constraint envelope look like, and what does the twin's simulated state say happens next. This is also where hybrid modeling earns its place — a purely data-driven model can find a mathematically strong relationship that violates thermodynamics, so the twin has to be grounded in first-principles constraints, not just historical pattern-matching.
Eliminate has the slowest and noisiest ground truth of all: a business outcome — cycle time, cost, error rate — that shows up weeks after an organizational change, not after a single inference. There's no sensor reading that confirms a removed step was the right call. This is where retrieval-augmented reasoning over the unified asset and process data — PLM, MES, SCADA, ERP, contextualized through a shared industrial data model — has to be paired with staged human-in-the-loop trial, not model confidence. An open-weight model reasoning over this layer is not answering "is this true" the way it is at the predict layer. It's answering "is this process still justified," and the only real evaluator is a human decision-maker watching the outcome play out.
What the architecture actually looks like
Laid out as a stack, this becomes a retrieval router sitting beneath a shared reasoning layer, not a single vector index doing everything:
- Unified data foundation — asset and process data contextualized through a shared industrial data model, the same pattern the recent Schneider Electric–Cognite and Emerson–AspenTech consolidation is built around. Without this layer, none of the three question types has anything reliable to query against.
- Time-series and streaming layer — feeds Predict. Sensor data, anomaly scoring against learned baselines, no semantic search required.
- Graph and physical-constraint layer — feeds Prevent. Asset hierarchy, operating envelopes, thermodynamic and mechanical limits, plus the digital twin's simulated state. This is where hybrid modeling lives.
- Document and semantic layer — feeds Eliminate. Manuals, process narratives, historical change records, retrieved and reasoned over, not just matched by similarity.
- Reasoning harness — the layer that decides which question type a given query actually is, and routes accordingly. This is a harness-design problem, not a model-size problem: what produces something resembling judgment is a trained pattern of attending to the right signals in the right sequence, taught deliberately rather than assumed to come free with a larger model.
- Trust-tightening layer — the same principle the Forbes piece makes for control applies here to the architecture as a whole. Recommendations sit above execution until they've survived real operating conditions; only then does integration tighten. This is true for a predicted bearing failure, and it's true, at a much slower pace, for an eliminated QA step.
Why this matters now
The capital moving into this space — Schneider's acquisition of Cognite, Emerson's completed AspenTech consolidation, the broader pattern across Siemens, ABB, Honeywell and Rockwell — is being spent almost entirely on the data foundation and the predict/automate layers. That's necessary and it's not wrong. But it means the architecture being built at scale right now has no place in it for the question that produces the largest outcome: not "run this faster," but "does this need to run at all." An organization that treats predict, prevent and eliminate as the same retrieval problem, solved by the same vector index, will get a system that's fluent everywhere and reliable nowhere. One that architects ground truth by layer, from sensor-confirmed to twin-simulated to human-adjudicated, has a real shot at answering all three honestly.