I started studying causal inference because prediction was no longer enough for the problems I cared about. A factory model can tell me that a defect is likely. An engineer still has to decide what to change. That gap—between forecasting an outcome and choosing an intervention—looked like the natural home of causal AI.
At first, the promise felt almost irresistible. Draw the right causal graph, combine it with data, and recover the mechanism behind the process. Instead of another black-box score, we might get an answer to the question manufacturing teams actually ask: if I change this parameter, what happens next?
Why the idea is so attractive in manufacturing
Manufacturing is full of correlations that look actionable and are not. A temperature signal may rise before a quality failure because both are driven by a third condition. A high-performing shift may appear to have a better process when it simply receives a different product mix. A maintenance action may seem effective because it is performed only on machines that were already being watched more closely.
Causal thinking forces us to name those hidden assumptions. It separates what we observed from what we believe would happen under an intervention. That discipline is valuable even before a model is trained.
Prediction asks what will happen. Industrial decision-making asks what will happen if we act.
Where my enthusiasm broke down
The deeper I went, the less I believed in causal inference as an automatic answer machine. A causal graph does not arrive from nowhere. Someone has to decide which variables matter, which arrows are plausible and which operating regimes can be compared. In a real plant, sensors are incomplete, process definitions change and interventions are rarely random.
This is not a failure of the mathematics. It is a reminder that the hard part sits at the boundary between data and domain knowledge. If the process assumptions are weak, a beautifully estimated causal effect can still be operationally wrong. Large language models do not remove this problem. They can help organise hypotheses and documentation, but they cannot make an unidentifiable question identifiable by sounding confident.
What I kept
I did not abandon causal thinking. I abandoned the fantasy that a causal library could replace engineering judgment. Three habits stayed with me:
- Write down the intervention before building the model. If no one can say what action the result would change, the analysis is probably not ready.
- Make assumptions visible. A debatable causal diagram is more useful than an invisible assumption buried inside a feature table.
- Design for learning. When certainty is impossible, recommend the smallest safe experiment that can reduce uncertainty.
My position today
Causal AI is neither the tears of the large-model era nor a shortcut to truth. It is a demanding way to connect evidence, mechanisms and action. In industrial AI, that connection matters more than a small improvement in benchmark accuracy.
The most useful system will not claim to know every cause. It will show what it believes, where that belief comes from, which constraint could invalidate it and what an engineer can safely test next. That is less magical than the original promise. It is also much closer to how factories actually improve.