Data Readiness Checklist for AI & ML: 42 Checks Across Seven Dimensions
Data Readiness Checklist for AI & ML: 42 Checks Across Seven Dimensions
Most AI programmes that stall do not stall on modelling. They stall in week fourteen, when someone discovers that the "orders" table has three definitions, that the outcome label exists for only 40% of cases, and that the source system overwrote the status history the model needed.
This checklist exists to move that discovery to week two, where it costs a remediation plan instead of a quarter.
It is the assessment we run before committing to a build. Forty-two checks across seven dimensions, each with the evidence you should be able to produce, a scoring rubric that converts findings into a go/no-go, and a remediation playbook for the gaps you will find.
What "data ready" means
Data readiness for AI is the measured fitness of a dataset for a specific decision — whether it contains the right entities at the right grain, with sufficient accuracy, completeness, consistency, timeliness and provenance, under a documented legal basis, to train and operate a model whose errors are acceptable to the business.
Two words in that definition do the work.
Specific. Readiness is not a property of a database; it is a property of a dataset relative to a decision. The same warehouse can be fully ready for a demand-forecasting model and completely unready for a credit-decisioning model, because the second needs labels, provenance and adverse-action defensibility that the first does not.
Measured. Readiness is a score with evidence behind it, not a workshop opinion. If a check cannot be evidenced with a query, a document or a named owner, it scores zero regardless of how confident the room feels.
This is the prerequisite stage of the enterprise data science and AI implementation guide. In that model it is Stage 2 — the gate between "we have an idea" and "we are funding a build".
Why this is the real bottleneck
Three independent lines of evidence point at the same constraint.
The cost of not doing it is quantified. Gartner research puts the average annual cost of poor data quality to an organisation at $12.9 million. That figure predates the current AI cycle; the marginal cost has risen since, because a model propagates a data defect into every downstream decision at machine speed and scale.
The failure pattern is consistent. MIT's NANDA GenAI Divide study found roughly 95% of enterprise generative AI pilots delivering no measurable return, with the causes concentrated in brittle workflows and poor fit to the operating reality rather than model capability. In practice, "poor fit" usually means the data did not describe the process the tool was supposed to improve.
It is now a regulatory requirement, not just an engineering one. Under the EU AI Act, high-risk systems carry explicit data-governance obligations under Article 10 — the training, validation and test datasets must be relevant, sufficiently representative, and examined for errors and completeness, with documented provenance. Following the Digital Omnibus, those obligations apply to Annex III systems from 2 December 2027 and to Annex I embedded systems from 2 August 2028. Organisations that have never produced a dataset datasheet will find that deadline expensive.
The practical implication: an AI programme without a readiness gate is not moving fast. It is deferring a stop.
The seven dimensions
Readiness decomposes into seven dimensions. They are not equally important for every use case — a demand forecast cares more about timeliness and granularity than about label coverage; a credit model cares more about accuracy, provenance and legal basis — which is why the rubric below weights them per use case.
Dimension | The question it answers | Typical failure symptom |
|---|---|---|
1. Completeness | Is everything the decision touches actually in the data? | Edge cases and small segments silently absent |
2. Accuracy | Does the data mean what it claims to mean? | Reconciliation breaks at month end |
3. Consistency | Do two systems agree on the same entity? | Three "active customer" counts |
4. Timeliness | Is the data fresh enough for the decision cadence? | A next-best-action model scoring on yesterday's behaviour |
5. Granularity | Is the data at the grain the decision operates on? | Only monthly aggregates for a daily decision |
6. Lineage | Can you prove where each field came from and what it touched? | An incident you cannot trace to a source |
7. Legal basis & governance | Are you permitted to use it this way, and can you prove it? | A launch blocked by a privacy review |
The 42-point checklist
Score each check 0–3 using the rubric in the next section. "Evidence" is what you must be able to show an auditor, a sponsor or your future self — not what you believe.
Dimension 1 — Completeness (checks 1–6)
# | Check | Evidence to produce |
|---|---|---|
1 | Every entity the model scores is present in the data, and unobserved cases are counted | Coverage query: distinct entities in the decision universe vs in the dataset, with the gap quantified by reason |
2 | Missing values are profiled per field
and per segment , not just overall | Null-rate table by field × segment × period |
3 | Historical depth covers a full business cycle plus training and validation windows | Date-range coverage statement against the model's window requirements |
4 | For supervised use, outcome labels exist for a sufficient share of records | Label coverage rate, by segment and by period |
5 | Negative outcomes are captured, not only positive ones | Query showing non-events (non-churn, non-fraud, no-defect) are recorded |
6 | Every segment the model will act on has enough volume to evaluate | Segment volume table against minimum sample thresholds |
Dimension 2 — Accuracy (checks 7–13)
# | Check | Evidence to produce |
|---|---|---|
7 | Field-level validation rules run continuously in production, not once at ingestion | Validation suite, its schedule, and the last 30 days of failures |
8 | Key measures reconcile to a financial or operational control total within a stated tolerance | Reconciliation report with tolerance and current variance |
9 | Known data errors are logged with a materiality assessment | Error register with owner, severity and remediation status |
10 | Duplicate rate is quantified and de-duplication is deterministic and documented | Duplicate analysis plus the matching rule set |
11 | Extraction accuracy from documents or free text is measured on a held-out sample | Precision/recall on a labelled sample, with the sample definition |
12 | Manually entered and proxy fields are identified, with their error rate estimated | Field inventory flagging manual/proxy fields and the error estimate |
13 | Third-party data has documented freshness and accuracy SLAs | Vendor contract clauses and delivery-quality history |
Dimension 3 — Consistency (checks 14–19)
# | Check | Evidence to produce |
|---|---|---|
14 | Each entity and metric has one definition, versioned in a semantic layer | Semantic layer entries with version history and owners |
15 | The same entity reconciles across systems within a stated tolerance | Cross-system entity count comparison with variance explained |
16 | Units, currency, timezone and encoding are normalised at a defined layer | Normalisation rules and where they are enforced |
17 | Reference data and code lists map to one canonical set | Code-list crosswalk with coverage percentage |
18 | Identifiers are stable, never reused, with a maintained crosswalk | Key strategy document plus crosswalk table |
19 | Status and category history is preserved, not overwritten | Slowly-changing-dimension design and a worked example |
Dimension 4 — Timeliness (checks 20–25)
# | Check | Evidence to produce |
|---|---|---|
20 | The freshness requirement is stated in terms of the decision cadence | Written requirement: decision frequency vs required data age |
21 | Actual end-to-end latency is measured, not assumed | Latency measurement from source event to feature availability |
22 | Ingestion schedules match real source-system availability windows | Schedule map compared with source batch completion times |
23 | Late-arriving and out-of-order data is handled by a defined rule | Handling rule plus tests demonstrating it |
24 | Backfill and reprocessing have been tested, with a stated duration | Backfill run log with elapsed time and completeness check |
25 | Freshness is monitored with alerting and a named owner | Monitor configuration and the on-call rotation |
Dimension 5 — Granularity (checks 26–31)
# | Check | Evidence to produce |
|---|---|---|
26 | The grain of the data matches the grain of the decision | Written mapping: decision unit (case, transaction, customer-day) vs table grain |
27 | Every required feature can be computed at that grain without destructive aggregation | Feature-to-source mapping showing computability |
28 | Entity resolution operates at the level the model requires | Resolution logic, match rates and false-merge estimate |
29 | Historical grain changes are documented, including system migrations | Grain-change log with effective dates |
30 | Event-level detail exists where sequence or process features are needed | Event table specification and a sample reconstruction |
31 | Organisational and geographic hierarchies are available at decision level | Hierarchy tables with effective-dated history |
Dimension 6 — Lineage (checks 32–37)
# | Check | Evidence to produce |
|---|---|---|
32 | Column-level lineage runs from source system to model feature | Lineage graph covering the model's inputs |
33 | Transformation code is version-controlled, reviewed and tested | Repository link, review policy, test coverage for critical transforms |
34 | Data contracts exist with upstream owners and are enforced | Contract documents plus enforcement evidence (schema checks, CI) |
35 | Schema changes trigger notification to the model owner | Notification path and the last three change records |
36 | Training runs use reproducible, immutable data snapshots | Snapshot mechanism and one reproduced past run |
37 | A model-to-data dependency map shows what breaks if a table changes | Dependency map reviewed in the last quarter |
Dimension 7 — Legal basis & governance (checks 38–42)
# | Check | Evidence to produce |
|---|---|---|
38 | Lawful basis and purpose limitation are documented per data source | Data inventory entry per source with basis and permitted purposes |
39 | Access is minimised: the model reads only the fields it needs | Access-control configuration and role definition |
40 | Retention and deletion propagate into training data and model artefacts | Deletion runbook, including retraining implications |
41 | Personal and special-category data is inventoried, with a DPIA where required | Classification inventory and completed assessments |
42 | Dataset documentation exists for regulated or high-risk use: relevance, representativeness, known limitations | Dataset datasheet per model, aligned to Article 10 expectations |
The scoring rubric
Score each check on four levels. The distinction that matters is between documented and evidenced: a policy that nobody can demonstrate is a 1, not a 2.
Score | Meaning | Test |
|---|---|---|
0 | Absent | Nobody can point to it |
1 | Ad hoc | It happens sometimes, undocumented, person-dependent |
2 | Documented | Written down and followed, but manual, unmonitored or inconsistent |
3 | Evidenced and automated | Enforced by system, monitored, with a named owner and current evidence |
Weighting. Apply dimension weights per use case, total 100%:
Use case type | Completeness | Accuracy | Consistency | Timeliness | Granularity | Lineage | Legal basis |
|---|---|---|---|---|---|---|---|
Operational / real-time | 15 | 15 | 10 | 25 | 20 | 10 | 5 |
Financial / regulated | 10 | 25 | 15 | 10 | 10 | 15 | 15 |
Analytics / forecasting | 20 | 15 | 15 | 15 | 15 | 15 | 5 |
Generative / RAG | 20 | 20 | 10 | 10 | 10 | 15 | 15 |
Convert to a weighted score out of 100. Then apply the gate:
Weighted score | Verdict | What happens next |
|---|---|---|
83–100 | Ready | Fund the build; monitor the remaining gaps in production |
65–82 | Conditionally ready | Fund, with a named remediation plan for every check scoring ≤1, and a re-score at the end of Stage 3 |
Below 65 | Not ready | Do not start modelling. Fund remediation as its own workstream with its own exit criteria |
Two rules keep the gate honest. Any check scoring 0 on Legal basis caps the total at "not ready", regardless of arithmetic — you cannot build your way out of an unlawful basis. And the readiness score is presented to the sponsor, not just to the delivery team, because the decision to proceed with a known gap is a business decision, not a technical one.
Running the assessment in 30 days
The assessment is a bounded piece of work, not an open-ended audit.
Week 1 — Scope the decision. Write down the decision the model will change, its cadence, its volume, the entities involved and the required output. Map each to the data sources you believe contain it. This document defines the assessment's boundary; without it, the work expands indefinitely.
Week 2 — Profile the data. Run the queries. Coverage, null rates by segment, label coverage, duplicates, date ranges, latency measurements, cross-system reconciliation. This is where most of the score is decided, and it is mostly SQL.
Week 3 — Collect the evidence. Lineage graphs, contracts, validation suites, access configuration, legal basis records, dataset documentation. Interview the upstream owners. Every check that cannot produce an artefact scores 0 or 1 — resist the temptation to accept an assurance.
Week 4 — Score, weight, plan. Produce the weighted score, the verdict, and a remediation plan: for each gap, the fix, the effort, the owner and the sequence. Present it with the two numbers the sponsor needs — the score today, and the score required to start.
Keep the assessment team independent of the build team. In organisations where the same people run both, readiness scores inflate by roughly a dimension.
Remediation playbook
The findings cluster. These are the ones we see most, with the fix that actually works.
Finding | Typical root cause | Fix | Effort | Owner |
|---|---|---|---|---|
Three definitions of the same entity | No semantic layer; each team modelled locally | Define once, version it, publish it, and add tests that fail on drift | 4–8 weeks | Data platform |
Label coverage below 50% | Outcome never captured, or captured in free text | Instrument the outcome at source; back-label from history where defensible; scope the model to the labelled population | 6–12 weeks | Business owner + data engineering |
Status history overwritten | Source system keeps only current state | Introduce effective-dated snapshots going forward; accept a history gap and bound the model's claims | 4–6 weeks | Source system owner |
Reconciliation breaks monthly | Late-arriving data and unmapped adjustments | Define the tolerance, add late-arrival handling, publish a reconciliation report | 3–5 weeks | Finance + data |
Latency far above the decision cadence | Batch ingestion for a real-time decision | Move the specific features to streaming or micro-batch; do not re-platform everything | 6–10 weeks | Platform |
No column-level lineage | Pipelines built in notebooks, undocumented | Adopt a lineage-capable orchestrator; instrument the model's critical path first | 8–12 weeks | Data engineering |
Grain changed at a migration | Historic and current systems record different units | Document the break, build a bridge table, exclude the pre-migration period if it cannot be reconciled | 3–6 weeks | Data engineering |
No lawful basis recorded | Data landed in the warehouse without purpose mapping | Inventory, map purposes, restrict access, complete assessments | 4–8 weeks | Privacy + legal |
Sequence remediation by what the model actually consumes, not by table. A table with 40 columns of which the model uses six needs six columns fixed. Organisations that remediate whole tables spend four times as long for the same score.
Five traps
1. Self-assessment by the team that wants approval. Readiness scoring done by the build team trends optimistic, not through dishonesty but through familiarity — they know which workaround to apply. Use an independent assessor, or at minimum require an artefact for every score above 1.
2. Confusing presence with fitness. "It's in the warehouse" answers a different question. Fitness is presence plus definition plus accuracy plus grain plus freshness, for this decision.
3. Testing quality once. A quality score is a snapshot; quality is a process. Checks 7, 25 and 35 exist because the failure mode is not bad data at assessment time — it is good data that silently degrades in month five.
4. Leaving legal basis to the legal team. Privacy and legal can advise on basis; they cannot inventory your data flows. The inventory is an engineering artefact and it belongs to the data owner.
5. Remediating everything. The goal is not a clean estate. It is a defensible dataset for one decision, with the rest of the estate on a planned trajectory. Scope to the decision, document the rest, move.
Frequently asked questions
How long does a data readiness assessment take? For a single defined use case, 30 days is realistic: one week to scope the decision, one to profile the data, one to collect evidence, one to score and plan. Broader enterprise assessments take longer only because they multiply the number of decisions being assessed — not because each one is harder.
What is a good data readiness score? 83 or above out of 100 (weighted) is ready to fund. 65–82 is conditionally ready: proceed with a named remediation plan and re-score before production. Below 65, remediate before modelling. A perfect score is not the goal and usually indicates the assessment was too easy.
Can we start the model while remediating the data? Yes, for most checks — with one exception. Never start modelling on an unresolved legal basis or an untested label definition, because both invalidate the result rather than delay it. Everything else can run in parallel, provided the evaluation harness uses the remediated data when it lands.
Is data readiness the same as data quality? No. Data quality is one of seven dimensions. Readiness also covers grain, timeliness, lineage and legal basis, which are the dimensions that most often block a build and are least often measured by data-quality tooling.
Do we need all 42 checks for a generative AI or RAG use case? The set applies, with different weights. For RAG, the emphasis shifts to document coverage and extraction accuracy (checks 1, 5, 11), chunk-level granularity and freshness (26–31), and lineage of the retrieval corpus (32–37). Legal basis rises in importance because the corpus usually contains unstructured personal or licensed content.
How often should the score be refreshed? Re-score at the end of Stage 3 and then quarterly for systems in production, focusing on the checks that can decay: accuracy, timeliness and lineage. A readiness score that is more than a quarter old is a historical document.
Get the working checklist
The version above is the reference. The working version is a scored spreadsheet — all 42 checks, the weighting calculator, the verdict thresholds and the remediation tracker, so you can run the assessment without rebuilding it.
Download the 42-point data readiness checklist — or if you would rather have it run independently against your lead use case, talk to the Data & AI Practice.
If you are still choosing which use case to assess, start with the enterprise data science and AI implementation guide — Stage 1 explains how to score and sequence the portfolio before you spend a month on readiness.
For organisations whose data estate is the constraint rather than the model, our data warehousing and analytics engineering work is usually the upstream fix, and big data and analytics covers the reporting layer that has to agree with whatever the model says.
Reviewed by the Marsables Data & AI Practice. The checklist reflects assessment work across finance, supply chain and operational analytics programmes. Regulatory dates reference the European Commission's AI Act implementation timeline as amended by the Digital Omnibus on AI; they are not legal advice.