Data Readiness Checklist

“Is our data ready?” cannot be answered. “Can I get these nine fields, for this population, at this freshness, with a known error rate?” can be answered in about a day, and it is the same question asked properly.

Readiness is not a property of your data. It is a property of a pairing — one decision, one field list. Change the decision and the answer changes, which is why a general data assessment tells you nothing you can act on.

Why this exists

This checklist prevents a specific death. A project clears a data review, gets an estimate, starts, and falls apart in week five because one field it depends on is present in the schema and empty in practice — or is a free-text box that six people fill six ways. A schema-level review cannot see any of that. A row-level one sees all of it in an afternoon.

So you trace fields, not systems. Start at the decision, list the fields the decision needs, and for each one pull a single real record and follow it from the screen where a human entered it to the query where you would read it. A sample of one, looked at with your own eyes, finds more than a profiling report. The profiler tells you a column is well populated. It cannot tell you the values are garbage of a syntactically valid kind.

Then the part everyone gets wrong. Three systems hold the same value and none of them agree. The instinct is to reconcile. Skip that and ask one question: when a customer complains that this is wrong, which system does somebody go and fix? That system is authoritative, whatever the architecture diagram says, because it is the one that gets corrected.

Before you pick, measure the disagreement rate, because that rate is the accuracy ceiling for everything you build on top. If two sources disagree on one record in ten, nothing downstream is going to be right about that field more than nine times in ten. Say that number at the start of the project rather than discovering it during user testing, when it becomes a defect instead of a constraint.

How to use it

Run it after the decision is named and before anybody gives an estimate. Out of that order it becomes paperwork.

One pass per field, and resist the offer to do it “for the whole domain” — that is how a one-day check becomes a six-week assessment nobody reads.

For each field, record who enters it, in what screen, under what pressure. Then ask that person what happens to them if they get it wrong. When the answer is nothing, treat the field as unreliable until proven otherwise. Fields captured under time pressure by somebody who gets no benefit from them are technically populated and practically noise.

Ask when the field’s meaning last changed, not how far back the rows go. Three years of history with a definition change fourteen months ago is fourteen months of history, and the rest is a different variable wearing the same column name.

Score red, amber or green per field, and let the decision inherit the worst field rather than the average. Eight excellent fields do not compensate for one that is empty.

Where it goes wrong

It says nothing about permission. Available and allowed are separate questions, and consent, contracts, regulated categories and vendor terms all live in the second one. A green checklist is not a legal opinion.

It measures the data as it sits today, not as it behaves under the load you are about to put on it. A field that is fine for two hundred rows pulled by hand can be a problem at daily volume, and an extract that works once is not the same as a pull somebody supports on a schedule. Ask who owns that pull at three in the morning, not whether the pull is possible.

And a red field is not a stop sign. Perhaps half the time the right response is to narrow the population — run the decision only where the data is good, publish the coverage number honestly, and expand later.