Artificial intelligence

Everything anchors on the semantic layer

The target of a supervised model is almost always a business metric wearing a technical name. Churn, conversion, lifetime value, expected demand, fraud. Which means the model is optimising whatever that metric was defined to be, including every silent decision inside it. If churn in the model means ninety days of inactivity and churn in the board deck means a cancelled contract, the system will be trained to improve something the business does not steer by, and it will look wrong to everyone who is not the person who built it.

Features have the same dependency. They are the measures and dimensions of the semantic layer, reconstructed as of a moment in time, which is exactly the discipline the previous keys were about. A feature computed with today's definition over yesterday's history is not a feature, it is a leak. The semantic layer is what makes the difference between a model that agrees with the organisation and one that quietly argues with it.

Why a mature team spends its time here

The argument for investing in this area is the same one that justifies automation, applied to judgment rather than to execution. A person can make a good decision about a customer, a price, a route or a claim. A model can make a slightly worse decision than the best human, several million times a day, at a cost that does not rise with volume. Where the decision is repetitive and the data is there, that trade is overwhelmingly worth taking.

The compounding is statistical rather than mechanical. Once a system is in place, improvements arrive as small increments in accuracy, coverage or calibration, and each one lands across every decision the system touches without anyone being hired. That is the difference between scaling a capability and scaling a team, and it is why an organisation that has done the earlier work ends up spending a growing share of its effort here.

Patterns shift, so nothing is finished

A model is a snapshot of a relationship that existed in the training window. Customers change, competitors move, pricing changes, a product launch shifts the mix, and the relationship the model learned decays quietly while the pipeline keeps returning confident numbers. Nothing breaks. The predictions simply become less true.

So these systems need the same operational seriousness as any other production component, plus one dimension more. Monitoring has to cover performance and drift, not only uptime and latency: input distributions, prediction distributions, realised outcomes against predicted ones once reality arrives. Retraining needs a cadence and a trigger. New versions deserve a challenger period rather than a swap on faith. And a model whose value has faded should be retired deliberately, because an unmaintained model is worse than none: it carries the authority of a system while making decisions from a world that no longer exists.

What generative systems unlock

The generative wave changes who can ask questions. Natural language access means a stakeholder can interrogate the data directly instead of queueing for an analyst, which turns a two day round trip into a conversation. Dashboards can be assembled without code, from a description of what someone wants to see. Reconnaissance that used to take a week of exploration can be done in an afternoon, because the tedious part of orienting inside an unfamiliar dataset is the part these systems do well.

There is also quieter value in the plumbing: drafting documentation, proposing tests, explaining what a pipeline does, enriching a catalogue, summarising what changed. Work that was always worth doing and rarely worth a person's afternoon.

The constraint is the same one as everywhere else. These systems answer from the context they are given, so their usefulness is bounded by the quality of the metadata behind them. Pointed at a documented semantic layer they are remarkable. Pointed at a raw warehouse with four definitions of revenue, they are a confident source of wrong answers, delivered fluently enough that nobody checks.

It only compounds on what came before

This is the key that most depends on the others, which is why it is placed where it is. A model needs history that was never overwritten, which is the foundations. It needs somewhere to train and serve, which is the architecture. It needs pipelines that run without being nursed, which is the engineering and the automation. It needs definitions it can be trusted to optimise, which is the analytics.

Skipping ahead is the most common way these programmes fail, and the diagnosis is almost always misattributed. The model was not the problem. The problem was that the events had to be inferred from mutated rows, the training set could not be reproduced twice, and nobody could say with certainty what the target column meant.

Deciding what deserves a model

Not every problem does. If a handful of rules capture most of the value, write the rules: they are cheaper, explainable, and easy to change when the business changes its mind. The case for a model appears when the decision is made often, when the improvement per decision is worth something, and when the pattern is genuinely too complex or too shifting to be maintained by hand.

Then design for the failure. What happens when the prediction is wrong, who notices, how much it costs, and whether a person is in the loop for the expensive cases. Systems that assume they will be right are the ones that cause damage; systems built with an explicit answer for being wrong are the ones that get to stay in production and keep improving.