The decision first, the model second

There is one question we ask at the start of every data project, and it often causes difficulty: which decision, made by whom, how often, would change if this model worked?

When the answer is precise — "the department head decides every Monday which orders to bring forward, and today they do it on instinct" — the project has a good chance of reaching production. When the answer is generic — "we would have more visibility on our data" — the project will almost certainly stall at the pilot.

The pilot nobody adopts

The pattern repeats with striking regularity. A model is trained, the accuracy metrics look good, the demo goes well. Then the project enters a waiting phase that never ends.

The reason is rarely technical. It is that nobody defined, before starting, who would change their behaviour and what would happen to the old procedure. The model arrives in an organisation that already has a way of making that decision — usually a person with twenty years of experience — and there is no mechanism to establish which of the two prevails.

Starting from the decision changes the project

If you start from the decision, the order of work reverses.

You begin by observing how the decision is made today: who makes it, on what information, in what time, and what the current errors cost. That measurement is the baseline, and without it no improvement can be demonstrated.

Then you set the adoption threshold: what level of performance makes the model preferable to current practice. It is a management threshold, not a statistical one — often far lower than people assume, because the comparison is not with perfection but with what is being done now.

Only at that point do you choose the technical approach, and in many cases you discover no complex model is needed: what is needed is clean data, available at the right moment, in the screen where the decision is actually made.

The last mile

Integration into the workflow is not the final phase of the project. It is the project.

A recommendation that appears in a separate dashboard, to be consulted voluntarily, will be consulted for two weeks. The same recommendation inside the system where the person already works, with its reasoning next to it and the option to override it logged, becomes part of daily practice.

And that logging is worth far more than control: the times an operator overrides the recommendation are the richest source of model improvement available. They are the cases where somebody knows something the model does not.

A quick test

Before approving your next AI project, try completing this sentence: "If this works, [role] will stop [current practice] and start [new practice], and we will know because [indicator] will move from [value] to [value]."

If the sentence will not complete, the problem is not ready to be solved yet.