At Google, one production ML feature could take the value -1 whenever an upstream call failed. That's not corrupted data by any schema's definition, -1 is a perfectly valid integer, and the field kept passing type validation without complaint. What changed was the meaning: the number had quietly stopped representing a measurement and started representing a shrug. The model kept serving on it, and because those corrupted serving observations flowed back into the next training batch, the failure didn't just persist. It compounded.
That's the gap between clean and ready in one example. A dataset can have valid types, consistent formats, and no unexpected nulls and still be unfit for the question someone is about to ask. A customer table can double-count a merged account without a single malformed row. A policy collection can be nothing but pristine, well-formatted PDFs with no reliable way to tell which one is current. Technical cleanliness is necessary. Google's -1 shows exactly how far short it falls of sufficient.
The research tradition behind "fit for use" makes the distinction explicit: quality depends on the task and the user, not on one universal score. A dataset that works fine for operational reporting can be wrong for a valuation model, because the model assumes a grain, a definition, or a historical relationship the data was never built to guarantee. Google didn't fix its -1 problem by tightening the schema. It added statistics, inter-batch comparisons, and presence checks, controls aimed at meaning and distribution, not just structure.
Start with the failure that matters
Before checking a dataset, name the decision. Then ask what would make the result wrong in a way that matters: a duplicate entity, an incomplete population, a stale rule, a changed definition, a missing relationship, or a source that can't be traced back to where it came from. Those specific risks, not a generic checklist, determine which checks are worth running.
- Fitness: does the data represent the decision's subject and grain?
- Integrity: are relationships, keys, and populations preserved?
- Meaning: are definitions, versions, and assumptions explicit?
- Timeliness: is the data current enough for this use?
- Evidence: can someone explain where it came from and what changed?
"Ready" doesn't mean perfect, and it never will, there's no such thing as a dataset with zero ways to be wrong. It means the ways this one could be wrong that actually matter for this decision have been tested, documented, and assigned an owner, before the decision starts depending on them rather than after someone notices the model's been quietly serving on -1 for a month.