Prediction Is Not the Product
AI predictions create value only when they lead to decisions, actions, and feedback. Predictive maintenance taught me that the real product is what happens next.
What predictive maintenance taught me about action, workflow, and feedback loops.
When I first worked on predictive maintenance, I thought the goal was fairly simple.
Detect the problem before the machine fails.
If the model was accurate enough and the alert arrived early enough, the system was doing its job.
That is an understandable way to think about predictive maintenance. Much of the field has focused on using condition data to anticipate failures before they occur. But research is increasingly moving beyond prediction toward systems that support actual maintenance decisions and actions.[1][2]
After working with real users, I started to see the same gap from a product perspective.
Knowing that something may fail and knowing what to do about it are two different problems.
That gap changed the way I thought about products.
1. A prediction is more like a weather forecast
Imagine your weather app tells you:
There is an 85% chance of heavy rain tomorrow.
The prediction can be perfectly useful without doing anything itself.
You change your commute. You bring an umbrella. A construction team changes its schedule.
The forecast creates value because someone changes what they do next.
Predictive maintenance works in much the same way.
Suppose an AI system says:
Bearing failure probability: 83%.
That isn't the end of the job.
It creates another series of questions.
Who receives the alert? Do they trust it? How urgent is it? Can the machine be stopped? Does the production team agree? What should be inspected? What evidence is needed before maintenance is approved?
Researchers have described predictive maintenance as a socio-technical system, where the interaction between maintenance personnel and the technical system is itself critical to achieving the maintenance objective.[3]
In other words:
The model produces information. The organization produces the outcome.
Figure 1 — A prediction is only the middle of the system
Physical World
↓
Sensing
↓
Data
↓
Prediction
↓
Explanation
↓
Decision
↓
Action
↓
Outcome
└────────────→ Feedback / New Data
Figure 1 — Prediction is only one step in a larger product loop. Conceptual illustration by the author.
2. The real work often starts after the alert
I saw this repeatedly in industrial environments.
An alert could be technically correct, but that didn't mean someone could immediately stop a production machine.
Stopping equipment has a cost of its own.
The maintenance engineer may need evidence that the problem is real. They may need to coordinate with a production team, explain the risk to a manager, or fit the repair into an existing maintenance schedule.
In products I worked on, users sometimes opened the service not simply to see what the AI predicted, but to obtain information they could use for those decisions.
Our customer analysis showed a workflow that continued well beyond the alert: users inspected the machine, planned maintenance, prepared information for internal reporting, took action, and later returned to check whether the condition had improved.
That changed an important assumption for me.
I had thought the product's job was:
Detect the failure.
The user's actual job looked closer to:
Detect → Understand → Explain → Decide → Act
A technically correct prediction that cannot be translated into a decision can still create very little operational value.
Human-in-the-loop predictive maintenance research points in the same direction. Explainability alone is not enough; effective decision-making also depends on how people interpret results, add context, and incorporate them into their work.[2][3]
3. Prediction and prescription are different problems
There is a useful distinction in maintenance research.
Prediction asks:
What is likely to happen?
Prescription asks:
What should we do about it?
Predictive approaches are relatively mature, while translating predictions into actionable maintenance recommendations remains a harder problem.[1]
A dashboard might say:
Abnormal vibration detected.
But the user's real questions may be:
Can I keep running this machine until Friday?
What should I inspect first?
Do I have enough evidence to stop production?
To answer those questions, the system needs more than a prediction. It needs context — time, cost, safety, operating conditions, and other constraints.[1]
Figure 2 — Prediction vs. prescription
PREDICTION
│
▼
"What may happen?"
│
▼
Failure risk
│
│ + Context
│ + Cost
│ + Safety
│ + Constraints
▼
PRESCRIPTION
│
▼
"What should we do?"
│
▼
Action
Figure 2 — Prediction estimates what may happen; prescription connects that information to a decision. Conceptual illustration by the author, based on the distinction discussed in prescriptive-maintenance literature.[1]
The closer a product gets to answering the user's real decision, the closer it gets to the user's actual job.
4. The workflow creates the next dataset
Suppose maintenance actually happens.
The engineer replaces a bearing, adjusts alignment, or decides that no immediate action is necessary.
What happens to that information?
Was the prediction correct? Was the suspected component actually damaged? Did the machine return to normal afterward?
Those outcomes contain information the model did not have when it made the prediction.
Without them, the system accumulates predictions.
It does not accumulate experience.
We usually think of machine learning as:
Data → Model → Prediction
But in a real product, some of the most valuable data is created afterward:
Prediction → Decision → Action → Outcome → Feedback → New Data
Human-in-the-loop maintenance research has explored the same idea: expert feedback can become part of how predictive systems adapt and improve over time.[3][4]
This is not unique to maintenance.
A document AI extracts a value. A sales model identifies a promising lead. A coding agent generates a patch.
In every case, the same question remains:
What happens next?
Someone approves the result, modifies it, acts on it, or sends it into another system.
That response is part of the product — and it may create the context the AI was missing.
This is why I no longer see workflow as an implementation detail.
The workflow is part of the product.
And it leads to a useful question for almost any AI product:
Does your AI know what happened after someone used its output?
If not, it may be missing the very data that could make it better.
Prediction is not the product
AI is making prediction, generation, and analysis cheaper.
As these capabilities become easier to build, I think more product value will move outward:
Context → Workflow → Action → Feedback
The model can tell you something.
The product has to make that information useful.
Prediction is not the product.
The product is what happens next.
And there is another problem hiding inside that loop.
Much of the context needed to make better decisions is never recorded in the first place.
That is what I want to explore next:
Tacit Knowledge Is the Missing Dataset.
References
[1] Orošnjak, M., Saretzky, F., & Kedziora, S. (2025). Prescriptive Maintenance: A Systematic Literature Review and Exploratory Meta-Synthesis. Applied Sciences, 15(15), 8507.
[2] Amaliah, N. R., Tjahjono, B., & Palade, V. (2025). Human-in-the-Loop XAI for Predictive Maintenance: A Systematic Review of Interactive Systems and Their Effectiveness in Maintenance Decision-Making. Electronics, 14(17), 3384.
[3] Towards Using Digital Intelligent Assistants to Put Humans in the Loop of Predictive Maintenance Systems. IFAC-PapersOnLine, 54(1), 2021, 49–54.
[4] A multi-dimensional feedback engine for governed adaptation in human-in-the-loop predictive maintenance. Results in Engineering, 30, 2026, 110370.
