The data comes first

A support team wanted to know which tickets were about to breach their service agreement, early enough to move somebody onto them. The first model was excellent. Precision and recall both in the high nineties, on a held-out set, on a year of real tickets. Everyone was pleased for about four days, which is how long it took to notice that the model was quiet during the morning when the queue was filling up and confident at six in the evening about tickets that had already been resolved.

One of its strongest features was the resolution channel. That field is populated when a ticket closes. The model had found the most reliable signal in the dataset, and the signal was the future.

Nobody had been careless. The dataset was assembled by exporting the ticket table, which is what a ticket table looks like: current state, not state at the time of the decision. Choosing a different algorithm would not have helped. Tuning would have made it worse, because tuning would have pushed the model further towards the feature that was ruining it.

Leakage, defined narrowly

The scikit-learn documentation puts it in one sentence: "Data leakage occurs when information that would not be available at prediction time is used when building the model." The consequence is stated just as plainly: overly optimistic performance estimates, and then poorer performance when the model meets genuinely new data.

The definition is worth memorising because it gives you a test you can apply to any feature without knowing anything about the model. Stand at the moment the prediction has to be made. Ask what your systems actually hold at that instant. Anything not in that set is not a feature, whatever the training table says.

Leakage arrives in a few recognisable shapes.

Through the target. A column that is a consequence of the outcome rather than a cause or a precursor. Resolution channel is one. A discharge code in a hospital admissions model is another. These are the easiest to explain afterwards and the hardest to spot in advance, because they usually have innocent names.

Through preprocessing. Scaling, imputing missing values, selecting features, or fitting an encoder on the whole dataset before splitting it. The scikit-learn guidance is direct about this: "Always split the data into train and test subsets first, particularly before any preprocessing steps", and where a transformation needs a statistic, "the average should be the average of the train subset, not the average of all the data". The effect is smaller than target leakage and much easier to introduce, because it happens in a single line of tidying that reads as good practice.

Through the split itself. Near duplicate rows landing on both sides. The same customer appearing as forty rows, split at random. Time series cut randomly rather than chronologically, so the model trains on next month and is tested on last month. In each case the test set is no longer independent of the training set, and the score measures recall of things already seen.

This is not a rare failure

It would be comforting to treat leakage as a beginner's mistake. The published record says otherwise.

Kapoor and Narayanan surveyed research that applies machine learning across scientific fields and found leakage in 329 papers spanning 17 fields, frequently producing what they describe as wildly overoptimistic conclusions. They propose a taxonomy of eight distinct kinds of leakage, which tells you something about how many ways there are to get this wrong. In their own reproduction study, on civil war prediction, every paper claiming that a complex machine learning model beat logistic regression failed to reproduce once leakage was corrected, and the older statistical approach performed comparably.

Read that last part carefully, because it is the practical point of this article. The reported advantage of the sophisticated model was an artefact of the data preparation. Once the preparation was fixed, the modelling choice stopped mattering.

The labels are data too

Supervised learning treats labels as ground truth. They are usually the noisiest thing in the dataset.

Northcutt, Athalye and Mueller examined ten of the most heavily used benchmark datasets in vision, language and audio, and estimated an average of at least 3.3 percent label errors across them. These are the datasets the field uses to decide which methods are better than which other methods. They also found that model ranking can invert once the labels are corrected: on ImageNet with corrected labels, a ResNet-18 outperforms a ResNet-50 when the prevalence of originally mislabelled test examples in the evaluation rises by just six percentage points.

A smaller model beating a larger one because of label quality is not a curiosity. It is the same lesson as the civil war study, arriving from a different direction. Comparisons between models are only as trustworthy as the labels the comparison is scored against.

In commercial work the label problem is usually worse than in benchmarks, and it is rarely random. Labels come from a business process, and business processes have their own logic. A fraud label often means "someone reported it", not "it was fraud". A churn label means whatever the CRM's definition of churn was on the day the export ran, which may have changed twice since. Before anything else, find out who or what produced each label, and what would have to happen for a wrong one to be created.

The world does not hold still

A dataset is a photograph of a period. Deployment happens later, somewhere else, under conditions that have moved on.

Koh and colleagues built WILDS as a benchmark of distribution shifts that arise naturally in real deployments: differences across hospitals in tumour identification, across camera traps in wildlife monitoring, across time and location in satellite imagery. Their finding across those ten datasets is blunt. Standard training gives substantially lower out-of-distribution performance than in-distribution performance, and the gap persists even for models trained with existing methods designed to close it.

Sculley and colleagues had made the systems version of this argument a decade ago, listing changes in the external world alongside data dependencies and hidden feedback loops as sources of long-term maintenance cost in machine learning systems. Their framing is that the quick win is not free; the ongoing cost simply arrives later and lands on somebody else.

For a working team the implication is a design constraint, not a warning. If your evaluation split is random, it estimates performance on the past. If you want an estimate of performance in production, split the way production differs from training: by time, by site, by customer, by device. The number will be lower. It will also be the number you actually get.

What a usable dataset looks like

Enough of what goes wrong. A dataset that is ready to model against has a short list of properties, and each one is checkable before any training run.

• A defined decision moment. You can name the instant the prediction is made and list what is known then. Every feature is drawn from that list.
• A label with a written definition and a named source. Who created it, from what event, with what delay, and what a wrong one looks like.
• A split that reflects the deployment gap. Time-based, or by group, or by site. Random splitting is the exception that needs justifying, not the default.
• Groups that stay whole. Every row belonging to one customer, patient or document sits on one side of the split.
• A known population. What is in the data, what was excluded and why, and which segments are thin. Thin segments are where the model will fail first and where nobody will be watching.
• A recorded collection process. Gebru and colleagues proposed datasheets for datasets by analogy with the electronics industry, where no component ships without a document describing its operating characteristics and recommended uses. A page describing motivation, composition, collection and intended use costs an afternoon and answers most of the questions a reviewer will ask in year two.

None of that is glamorous, and that is roughly the point. Sambasivan and colleagues interviewed 53 practitioners working on high-stakes AI in India, East and West African countries and the United States, and found what they call data cascades, compounding downstream problems caused by data issues, in 92 percent of them. Their framing of the cause is uncomfortable and accurate: data is the most undervalued and de-glamorised part of the work, while carrying the heaviest consequences in exactly the domains where the stakes are highest.

Where this leaves the model choice

Model selection matters. It matters most once the dataset underneath it is sound, and its effect is usually smaller than the effect of the decisions described above. Training, as What a model actually learns sets out, adjusts parameters until a loss is small on the rows it was given. Change the rows and you have changed the thing being learned, whatever algorithm is doing the learning.

The order of operations we use on delivery work follows from that. Establish the decision moment and the label definition. Build the split that mirrors deployment. Get a trivial baseline scored on that split, an average or a hand-written rule, so there is a floor to argue against. Only then try models, and treat any large jump in the score as a suspect to be investigated rather than a result to be celebrated.

The support ticket model was eventually rebuilt on a snapshot of what each ticket looked like at the four-hour mark, with the resolution fields removed and the split taken by week rather than at random. Its scores were far lower than the first version's. It was also the first version that was any use on a Tuesday morning, which was the entire point of building it.

References

1. Common pitfalls and recommended practices. scikit-learn documentation, version 1.9.0, 2026.
2. Leakage and the Reproducibility Crisis in ML-based Science. Sayash Kapoor and Arvind Narayanan, arXiv, 2022.
3. Pervasive Label Errors in Test Sets Destabilize Machine Learning Benchmarks. Curtis G. Northcutt, Anish Athalye and Jonas Mueller, NeurIPS Datasets and Benchmarks Track, 2021.
4. WILDS, A Benchmark of in-the-Wild Distribution Shifts. Pang Wei Koh and colleagues, arXiv, 2020.
5. Hidden Technical Debt in Machine Learning Systems. D. Sculley and colleagues, Advances in Neural Information Processing Systems 28, 2015.
6. Everyone wants to do the model work, not the data work, Data Cascades in High-Stakes AI. Nithya Sambasivan and colleagues, SIGCHI, ACM, 2021.
7. Datasheets for Datasets. Timnit Gebru and colleagues, Communications of the ACM, 2018.