Every number this section of the site teaches you to compute rests on data you have to be able to vouch for. A fairness audit on labels that encode historical bias measures the bias twice. An eval score on a contaminated test set measures memorization. A model trained on a poisoned corpus fails in ways no offline eval predicts. Data integrity is the unglamorous floor under all of it, and it decomposes into six checks you can put in CI.
Provenance: can you answer where this came from
The datasheet discipline asks, for every dataset you train or evaluate on: who collected it, when, from what population, with what consent, with what preprocessing, and for what intended use [1]. The point is not the paperwork; it is that the questions surface disqualifying facts early. A dataset whose collection window predates your product's domain shift, or whose population excludes the users your fairness audit cares about, fails before any metric runs. Model cards extend the same discipline to the trained artifact [2]. The minimum viable version is a README per dataset version answering those questions, wired into the versioning and lineage you already keep.
Leakage: the feature that knows the answer
Label leakage means a feature that would not exist, or would not be populated, before the outcome it predicts: the discharge summary in an admission-risk model, the account-closed flag in a churn model, an ID column that correlates with the labeling batch. Leaky models post spectacular offline scores and collapse in production.
Detection is mechanical enough to automate. Per-feature association screens against the label (a single feature with implausibly high mutual information is a suspect), temporal audits (would this value be known at prediction time?), and the attribution check: a feature dominating SHAP importance that has no causal business being predictive is the classic tell. The cure is always the same, remove the feature and retrain, and the lesson always generalizes: add a leakage screen to dataset onboarding, not just to postmortems.
Split hygiene
Train-test separation fails quietly through duplicates and near-duplicates: the same user's sessions in both splits, paraphrases of one document on both sides, an augmented copy of a training image in test. Deduplicate across splits with fuzzy matching (MinHash on text, embedding similarity where paraphrase is the threat), and split on the entity that generalization is claimed over, not on rows: by user, by document, by time. Temporal tasks get temporal splits; a random split over time-series rows lets the model see the future and calls it validation.
Contamination and poisoning
Contamination is your test set inside someone's training corpus; it turns capability claims into memorization claims, and it has its own runnable recipe covering date-windowing and MinHash overlap detection. The integrity framing adds the internal case: your own fine-tune corpus can swallow your own eval set through a careless pipeline join, so the overlap check runs between your training exports and your golden sets on every data release, not just against public mirrors.
Poisoning is the adversarial cousin: Carlini et al. showed that controlling expired domains and exploiting snapshot timing makes injecting attacker content into web-scale training sets practical for a few tens of dollars, no exotic access required [3]. OWASP tracks it as LLM04 [4]. For most product teams the exposure is concentrated in what you ingest on purpose: fine-tuning data bought from vendors, user feedback loops that flow back into training, RAG corpora crawled from the open web. The proportionate checks are source allowlists, snapshot pinning with content hashes, anomaly screens on incoming batches (duplicate bursts, trigger-phrase repetition, distribution shifts), and treating "data that arrives from outside" with the same suspicion as code that does.
PII and licensing
Two scans that belong in the same CI job: PII detection (regex plus NER for names, addresses, government IDs, free-text fields that users typed secrets into) on anything leaving its origin system for a training or eval corpus, and license verification on anything ingested. Seed canary strings into corpora you release internally so that if they ever appear in model output, the leak has a name.
Figure: The six data integrity checks placed as CI gates along the pipeline: poisoning screens plus PII and license scans on every ingestion batch, datasheet and leakage screens at dataset onboarding, cross-split deduplication and entity-level splits on every split regeneration, and a contamination overlap scan including your own training exports on every data release. Any failed gate blocks the release with red-build semantics.
The checklist
| Check | Question it answers | Cadence |
|---|
| Datasheet present | Where did this come from, for whom, for what use | Every dataset version |
| Leakage screen | Does any feature know the answer | Dataset onboarding + schema change |
| Split hygiene | Do train and test share entities or near-duplicates | Every split regeneration |
| Contamination overlap | Is my eval set in any training corpus, mine included | Every data release |
| Poisoning screens | Did anything anomalous enter the pipeline | Every ingestion batch |
| PII and license scan | Can I lawfully and safely hold and ship this | Every ingestion batch |
TIP
Integrity checks are release gates, not research. Wire them next to your eval CI with the same red-build semantics: a failed overlap check blocks the data release the way a failed regression set blocks the merge. A check that runs quarterly by hand is a check that will be skipped in the quarter that mattered.