You have the data. A 40 GB folder of images, a Parquet file someone handed you in a hurry, or a scrape you built over a weekend. The training script runs, the loss starts moving, and then something goes strange. Three days later you find out that six percent of your training rows are duplicates of your validation rows.

None of that is a modelling problem. It is an admission problem: the data got in without being questioned. The checks below take an afternoon at most, and each one exists because someone, somewhere, lost a week to it. Run them before the first epoch, not after.

Start With the Labels

1. Read a random sample by hand. Not the first fifty rows. A random fifty, drawn with a fixed seed. Read the input and the label together and ask whether a careful person would agree. If you find two mistakes in fifty, stop and assume the label set needs a pass before anything else is worth doing.
2. Count the classes and plot the histogram. An even split is not required, and rare classes are often real. What matters is whether the distribution is what you expected. A class with eleven examples cannot be learned; a class with 40 percent of the data will dominate the loss unless you weight it.
3. Normalize the label vocabulary. Cat, cat, cats and cats are four strings and two meanings. Whitespace, casing and stray punctuation create phantom classes that split your signal and confuse every metric you compute later. Freeze the final list in a schema file so the next person knows what is valid.

Duplicates Are Everywhere

Duplicates don't just inflate your dataset size. They distort your loss, and if they straddle a split boundary they leak. Look for them in two passes.

1. Exact duplicates. Hash file bytes for images and audio; hash a normalized row (lowercased, whitespace stripped, columns sorted) for tabular and text. The same scan often appears twice with different timestamps, or the same product listing appears under two IDs.
2. Near-duplicates. Perceptual hashes work well for images, especially for resized or re-encoded copies. MinHash or token n-grams catch text that has been lightly edited. Feature-similarity search helps with tabular rows. Pick a threshold, then look at the borderline pairs yourself instead of trusting the number.

If you can't explain how a duplicate was detected, you can't say whether it is safe to keep.

Leakage, the Quiet Failure

Leakage is any path by which information from the evaluation set reaches training. It rarely looks like a bug. It looks like a suspiciously good first result.

1. Split before you touch anything. Partition the raw data first, then explore, clean and transform each split separately. Cleaning the whole dataset and splitting afterwards is the most common way to leak.
2. Group leakage. Rows from the same person, session, device, document or hospital visit belong in the same split. Otherwise the model memorizes the group and you measure recall of things it has already seen.
3. Temporal leakage. For anything time-ordered, split by time. Train on January through September, evaluate on October. Random splits on time series quietly hand the model the future.
4. Preprocessing leakage. Fit scalers, tokenizers, vocabularies, imputers and target encoders on the training split only, then apply the fitted object to validation and test. Fitting on the full dataset is a one-line mistake with a long tail. While you are there, look for columns that encode the outcome — a cancellation_reason field in a churn dataset is the label wearing a disguise.

Licensing and Provenance

1. Check the terms for every source. Read the license of each dataset you merged. Note whether it permits commercial use, requires attribution, or carries a share-alike condition. Scraped sources have terms of use, and personal data usually has its own rules regardless of who posted it. Keep a written record of what you concluded and why. If the data will ship in a product or a paper, have a lawyer review the conclusion — this checklist is not legal advice.
2. Write a manifest. For each source: URL or internal path, access date, license name, row count, checksum. When a license quietly changes or a source disappears, the manifest tells you within minutes which experiments are affected.

Ranges, Units and Encodings

1. Sanity-check every column and channel. Print the minimum, maximum, count of nulls and a few random values. Most data bugs announce themselves in that output.

What "sane" usually looks like

• Images: consistent channel order (RGB versus BGR), consistent scale (0–255 or 0–1), no EXIF rotations that flip faces sideways, no truncated files that decode to gray mush.
• Text: one Unicode normalization form, consistent line endings, no HTML entities left in the strings, and a tokenizer that handles the scripts actually present.
• Tabular: one unit per column. Kilograms mixed with pounds, cents mixed with dollars, and timestamps from three different time zones will all learn beautifully and generalize terribly.
• Missing values: find every representation of "unknown" — -1, 0, empty string, N/A, NULL — and decide on one. A column where missingness is split across three codes hides a fourth of its signal.
• Sequences: fixed padding token, a truncation length you chose on purpose, and a count of how many samples got cut. Silent truncation is silent data loss.

Once these are settled, apply your normalization deliberately: divide images by 255 or by the dataset mean and standard deviation, standardize continuous features, and record both choices next to the model config. A normalization that exists only in someone's notebook is a bug waiting for a new teammate.

Make It a Script, Not a Ritual

A checklist you run once is a story you tell. A checklist that runs itself is infrastructure. Wrap each of the twelve checks in a function that prints a short report — counts, examples, warnings — and run it every time the data is refreshed. Datasets drift as sources are updated, and last month's clean set is not this month's clean set.

Keep the report next to the trained model, along with the data version and the manifest. When a result looks too good or a metric collapses, the first question is always which data went in. Having a one-page answer turns a three-day investigation into a ten-minute read. Do this once and you will never want to train on an unexamined dataset again.

Photo: Free-Photos / Pixabay