That AI Feature Should Have Been a SQL Query

The most useful sentence we say in a discovery workshop is some version of: that is a query, not a model.

It is also the least popular, so I want to make the case properly, because the pattern is now costing organisations real money and — more importantly — real credibility with the people who were supposed to use the thing.

The shape of the mistake#

A team wants to know which customers are likely to churn. Or which patients will not attend. Or which students are at risk. Someone frames it as a prediction problem, because it is phrased as a question about the future, and prediction problems get models.

Then discovery starts, and it turns out:

• The domain experts already know the answer with high confidence, and they can articulate the rule. Patients who have missed two of their last four appointments and live more than a certain distance away miss the next one about half the time.
• The data to compute that rule exists, in three systems, unjoined.
• Nobody has ever put the answer in front of the person who could act on it.

The bottleneck was never predictive accuracy. It was the join and the last mile. A model would eventually rediscover, imperfectly and unexplainably, the rule the staff already stated in one sentence — and it would take six months instead of two weeks.

The four questions that settle it#

We run these in every scoping session. They take twenty minutes and they resolve most cases.

1. Can a domain expert state the rule?

If an experienced practitioner can describe what makes something high-risk in one or two sentences, encode that first. You get an interpretable baseline, immediate delivery, and a benchmark any future model must beat. If they cannot articulate it but can reliably recognise it, that is genuine tacit knowledge and a legitimate case for learning from examples.

2. Is the outcome even uncertain?

A surprising number of “predictions” are lookups. “Which invoices will be late” — some of them are already late. “Which students are at risk” — some already have the attendance record that defines risk. Before modelling the future, check whether the present is fully visible. Frequently it is not, and making it visible is the entire deliverable.

3. Is the relationship stable?

Machine learning assumes tomorrow resembles the training data. If your process, product, or population changed six months ago, your historical data describes a system that no longer exists. Rules can be updated by a human when policy changes. A model trained on the old regime degrades silently and blames itself.

4. Does anyone act on it, and how?

If the intervention is the same regardless of the score — everyone in the flagged list gets a phone call — then you need a ranked list under a capacity constraint, not a calibrated probability. “Top 50 by risk score” is a ORDER BY ... LIMIT 50. The precision of the underlying estimate barely matters as long as the ranking is roughly right, which a simple heuristic usually achieves.

What we build instead, and why it wins#

The default recommendation is a three-stage ladder, and most projects stop at stage two.

Stage one: make it visible. Join the data, compute the obvious aggregates, put them where someone can see them. This is the highest-value, lowest-risk work in the entire engagement and it is nearly always skipped because it is not exciting.

Stage two: encode the expert rule. Take the practitioner’s sentence, implement it, and measure how well it does. You now have a number to beat and a system in production that people already trust because they can read the logic.

Stage three: model the residual, if there is one. Where the rule is measurably wrong — where experts disagree, or the rule performs badly on a subgroup — that is a real learning problem with a defined target and an existing baseline. Now a model is worth building, and you can prove it earned its place.

Teams that start at stage three ship in six months with no baseline, no trust, and no way to demonstrate value. Teams that walk the ladder ship in three weeks and know exactly whether stage three is worth funding.

Two cases from our own work#

A hospital group asked for a machine learning model to predict outpatient no-shows. Discovery found the appointment system, the transport booking system and the demographic record had never been joined. A single query over the joined data — prior no-show count, distance band, appointment lead time, time of day — produced a ranked list that let the booking team overbook intelligently. Deployed in under a month inside the existing Hospital Management System screens. It has been running since, and no one has yet found a business case for the model, because the rule captures most of the signal and nobody has to explain it to a governance committee.

A school trust wanted an at-risk-student model. Same finding: attendance, assessment and pastoral records lived in three places with no shared identifier. The first deliverable was entity resolution and a joined view. The second was a rule the heads of year wrote themselves in a two-hour workshop. The School ERP dashboard surfaced it in the morning register. Teachers used it on day one, precisely because they had written the rule and could argue with it.

In both cases a model may eventually add value at the margin. In both cases it would have added nothing at all if built first, because the data it needed did not yet exist in joinable form.

The uncomfortable incentive#

Why does this keep happening? Because “we built an AI system” is fundable and “we joined three tables” is not. Boards ask about AI strategy. Nobody asks about the identity crosswalk.

The way through is not to argue against AI. It is to reframe the plumbing as the AI programme’s first phase, which is honest — you genuinely cannot build the interesting version without it. AI implementation is mostly data engineering with a model on top. Sequencing the data engineering first is not a delay to the AI work; it is the AI work, done in the order that makes it succeed.

Then, when the data is joined, resolved and flowing, build the model. It will be better, faster to build, and easier to defend. And sometimes you will find you no longer need it, which is a good outcome that nobody puts in a case study.

---

We have talked more clients out of models than into them, and they are still clients. If you want an honest read on whether your problem needs one, ask.