Correlation Runs the Dashboard. Causation Runs the Plant.
An anecdote from early in my data science career makes this concrete. Two motors on the same site, with no process or electrical connection between them, and the data showed Motor B reliably overheating a few hours after Motor A, every single day. For a while, that looked like a real finding — watch Motor A, and you could see Motor B’s trouble coming.
The actual cause had nothing to do with either motor. Motor A sat on the east side of the installation and caught the sun first; Motor B, further west, caught it a few hours later. Both were heating up from the same source — the day’s solar load — just offset by geography. Fix Motor A, and Motor B keeps overheating right on schedule. The correlation was real. The causation it seemed to indicate was not.
Every plant has a dashboard, and every dashboard is primarily a set of data views, and most of those views are post-mortem: they show what already happened. There is a pattern-matcher behind it now beyond the usual post-mortem views. Show it enough history, and it will find things that move together. Corrosion rates and steam-trap proximity. Vibration and ambient temperature. Throughput and a dozen variables - that may be correlated, but not related.
Some of those correlations are real mechanisms. Most are coincidence wearing a p-value. The dashboard can’t tell you which is which. Neither, reliably, can the model behind it, not because the model is bad, but because correlation was never built to answer the real question: why this happened.
Two things that look alike
Here is the distinction the rest of this piece rests on, and it fits in a sentence: correlation tells you what moves together; causation tells you what happens if you reach in and change one thing.
Say a model notices that pipe spans near steam traps corrode faster. Correlation stops there — a pattern, filed and dashboarded. Causation asks the next question: why? In this case, engineering already knows the mechanism, and it has a name — corrosion under insulation, driven by moisture ingress where a leaking trap wets the lagging. That mechanism is what tells you where to strip insulation and inspect, not the correlation. The correlation and the mechanism can point at the same pipe spans and still license completely different actions.
Judea Pearl gave this distinction a ladder: association at the bottom (what do I observe?), intervention in the middle (what happens if I act?), counterfactual at the top (what would have happened if I hadn’t?). Most industrial AI today lives on the bottom rung by construction — it was trained to predict, not to intervene. A plant, on the other hand, is run almost entirely on the top two rungs. Every maintenance decision is an intervention. Every root-cause investigation is a counterfactual. An AI that only climbs to the first rung is answering a different question than the one being asked of it.
The historian isn’t the plant
A related trap, specific to how these systems are usually built: point a large language model at a historian — the time-series database every plant already runs — and let it retrieve and summarize. It will produce fluent, plausible-sounding operational narrative. It has still done nothing but retrieval.
Retrieval is not grounding. A historian records what happened; it does not encode why, and it certainly does not encode what the relevant standard permits, what the failure mechanism actually is, or what limits apply before a recommendation is safe to act on. An AI that reads the historian well can sound like it understands the plant. Sounding like it and grounding in it are different claims, and only one of them survives an audit.
You cannot A/B test a blowout preventer
There is a reason this problem does not get solved the way it gets solved in software: you cannot move fast and iterate on a safety-critical system. Consumer AI can be wrong at scale and cheaply corrected — ship, observe, retrain. An industrial system that touches a pressure boundary or a safety-instrumented function does not get that feedback loop. You do not learn a blowout preventer’s failure modes by occasionally letting it fail.
Which means the causal structure has to come from somewhere other than trial and error at the point of use. It has to be grounded before deployment, not learned in production — in physics, in the standard that governs the equipment, in the failure history the industry has already paid for in incidents. Grounded reasoning is, in part, an admission that some domains cannot afford to learn the way machine learning usually learns.
Where the causal knowledge actually comes from
None of this argues against using AI to help build the causal picture — only against trusting an unreviewed one.
A live, useful pattern in the field right now: AI proposes candidate causal relationships from data and failure history at build time, and a subject-matter expert reviews and certifies them before anything reaches an operator.
AI is fast at hypothesis generation. The standard, and the engineer who knows it, are what turn a hypothesis into something worth grounding a decision in.
That is also where Engineering Knowledge and Grounded Reasoning meet. Engineering Knowledge is the standards, the failure mechanisms, the physics that already exist. Grounded Reasoning is the discipline of making sure an AI’s inferences are constrained by that knowledge rather than running loose on correlation alone. Neither works without the other.
A preview, not the deep dive
Grounded reasoning is one half of what a trustworthy recommendation actually requires — the other half is what happens once that recommendation exists: who is accountable for acting on it, and how. Both halves answer the same provocation — a confident wrong answer is worse than a refusal — and neither reasoning nor governance alone closes that gap.
This is one of seven dimensions this program is built around, and it deserves a volume of its own — the causal ladder, the historian trap, and where causal knowledge comes from are each worth far more than a paragraph. We will name and discuss the shape of the whole thing in next article.
Correlation will keep running the dashboard. It should. But the plant runs on causation, and until the reasoning underneath an AI’s recommendation is grounded in the same mechanisms an engineer would cite, the dashboard and the plant are not talking about the same thing.