// measurement
The number that approved the model.
A machine learning system gets approved for use on the strength of a measured figure. An accuracy, a detection rate, a false-alarm rate. That figure is a measurement, and like any measurement it can be biased by a defect in the procedure that produced it.
Data leakage is such a defect. When information about the label, or information that will not exist at decision time, reaches the model through the training or validation pathway, the reported figure is biased upward. The model itself may be fine or it may be junk. What is certain is that the number used to approve it does not estimate field performance, and nothing in the reported metrics indicates that. The deficiency surfaces in production, or it does not surface at all.
Four ways it happens
the evaluation scores the model on information it would not have had at the moment of decision. A random split of a time series does this by default. The model looks robust and was quietly graded on the future.
a feature encodes the answer. Often it is a field populated downstream of the outcome, or a proxy so tight it is the label under another name. Accuracy is excellent and the feature will be empty when it matters.
scaling, imputation, feature selection, or resampling fitted on the full dataset before the split. The validation fold has already seen the statistics of the training fold. The bias is small per step and compounds quietly across a pipeline.
the same subject, device, patient, or session appears in both partitions under different identifiers. The model recognises the entity rather than learning the task, and performance collapses on genuinely novel entities.
Why the usual defenses do not close it
Static analyzers inspect pipeline code and catch structural contamination. They do not catch leakage that is a property of the data, because the code is correct.
Grouped and temporal cross-validation prevents several classes when applied correctly. Whether a given pipeline applied it correctly is itself unverified, and contamination introduced upstream of the split survives every choice of splitting scheme.
Holding out a test set assumes the held-out data is clean. If the contamination is in the source, the holdout inherits it and confirms the wrong answer with more confidence.
What an honest answer requires
A detector is only useful if you can state how often it is right, and that is harder than building the detector. True leakage base rates in the wild are unknown, so detection performance cannot be inferred from field data. It has to be measured against cases whose contamination is known by construction: injected classes, at known locations, at parameterized severities, against matched clean controls.
Then the quantities that matter are the operating characteristic, not an accuracy score. Detection probability and false-alarm rate per class and severity, with intervals. Repeatability across runs and reproducibility across independent implementations. Transfer measured by holding out whole datasets and whole model families, because a method that works only where it was developed is not a test method.
And the failure regimes have to be published. Contamination subtle enough to evade detection at an operationally acceptable false-alarm rate will exist. A high false-alarm rate makes a detector worse than none, because people stop acting on it. Knowing where a method stops working is the part a program office actually needs.
What we are building
We are building an open measurement harness for a specific version of this problem: integrity of federated aggregation. When nodes train locally and return model updates, a node whose feed has drifted inside nominal bounds returns a well-formed update that the aggregator has no basis to reject, and the fleet-wide metric is dominated by healthy nodes, so the degradation does not appear anywhere.
The baseline is established. Round-to-round variance in a healthy federation scales sharply with data heterogeneity, which means a fixed detection threshold cannot hold across a realistic fleet and false-alarm rate has to be reported per heterogeneity level rather than as one number. The detector is not built yet, and we are making no detection claim until the curves exist. They will be published when measured, including the regimes where it fails.
If you are running an evaluation whose number decides something expensive, that is the work we do. See the capability statement.
Common questions
Data leakage occurs when information about the label, or information unavailable at decision time, reaches the model through the training or validation pathway. It biases the reported performance figure upward, so the number used to approve the model does not estimate what it will do in the field. Nothing in the standard metrics reveals it.
The most common structural cause is that the evaluation was biased rather than the model being wrong. Temporal splits that grade on future information, features populated downstream of the outcome, preprocessing fitted before the split, and the same entity appearing in both partitions all inflate the reported figure. The model is then measured honestly for the first time in production.
Partially, and how well is an open question. Static analyzers catch structural contamination in pipeline code but not leakage that is a property of the data. Answering it properly requires measuring detection probability and false-alarm rate against cases whose contamination is known by construction, and publishing the regimes where detection fails.
studio@anchor163.com
// copied