Predictive Intelligence Is a Decision Problem

Prediction has quietly become the most reliable AI investment a business can make. It is older than the current wave, better understood, cheaper to run, and it does not hallucinate. It is also where a great many projects produce an accurate model and no change in how anything operates.

The reason is consistent: the forecast was treated as the deliverable, and the decision it was supposed to inform was never specified.

Start from the decision, not the data

The question to answer before any modelling is: what will somebody do differently, and when?

This sounds obvious and it is routinely skipped, because the data is interesting and the decision conversation is awkward. But it determines everything downstream, including several choices that are expensive to change later.

It sets the horizon. A demand forecast is useful only if it arrives further ahead than the lead time of whatever it triggers. If reordering takes six weeks, a two-week forecast is a report rather than a decision input — and a model optimised for two-week accuracy is optimised for the wrong thing.

It sets the granularity. If purchasing is done per supplier per month, a daily per-item forecast is not more useful, it is more numbers. Granularity should match the unit the decision is actually made in.

It sets the error trade-off. This is the important one. Almost no real decision treats over-prediction and under-prediction symmetrically. Understocking a critical spare part costs a line stoppage; overstocking costs shelf space. A model tuned to minimise average error will happily split the difference in a way that is wrong for the business, and the metric will look healthy while it does.

Accuracy is not the measure

Once the decision is defined, the honest evaluation is not how close the forecast was. It is whether decisions made using it were better than decisions made without it.

Those are different questions and they can diverge sharply. A model that is more accurate on average but occasionally very wrong on high-value cases can be worse in practice than a cruder model that is never badly wrong. And a highly accurate forecast for something nobody can act on has a value of zero regardless of its statistics.

The comparison also needs an honest baseline. Not a naive one — the actual current process, including whatever informal judgement the experienced person in the room applies. That judgement is frequently good, and a project that cannot beat it should find out early.

Where it earns its keep

The consistent wins share a shape: a decision made repeatedly, with a lead time long enough to act within, where being wrong has an asymmetric and quantifiable cost.

Maintenance timing, where a sensor pattern indicates a component degrading and the choice is whether to intervene at the next planned stop or wait. Demand and inventory, where the horizon matches procurement lead time. Staffing against predicted volume. Churn, where the intervention is defined and its cost is known. Collections prioritisation, where the resource is a finite number of people and the question is whom to call first.

What they have in common is that the model does not decide anything. It changes the order in which people do things, or the timing of something already planned.

The part that decides adoption

A prediction nobody understands does not get used, and this is where the majority of technically successful projects quietly die.

The person receiving the forecast needs to know what drove it. Not a full account of the model — the two or three factors that moved this particular prediction. "Flagged because vibration has trended up over eleven days and this component failed under a similar pattern twice before" is actionable. A score of 0.87 is not.

They also need to know when not to trust it. A model operating outside its training distribution should say so rather than producing a confident number. In practice that means predictions carry a confidence indication, and low confidence routes to a person instead of into the workflow.

Where it sits relative to agents

Prediction and agents solve different problems and are increasingly deployed together, which is worth stating plainly because they get conflated during procurement.

A forecast tells you something is likely. An agent can act on it — raise the order, book the engineer, open the case, notify the customer — within limits somebody set. That combination is where a lot of current value sits, and it works because each part does what it is good at: the model estimates, the agent executes, a person sets the bounds and handles the exceptions.

What does not work is asking a language model to do the forecasting. That is a job for a model trained on your own numerical history, and using the wrong tool for it is an expensive way to get a worse answer.

The question to ask first

Before commissioning a prediction project, ask what will change on the day the forecast is available, who will change it, and what it costs when the forecast is wrong in each direction.

If those have answers, the project is likely to land. If they do not, more data and a better model will not help — the output has nowhere to go.