What Data Readiness Is (and What It Is Not)

The distinction matters because the three adjacent disciplines all produce useful work, and they are all commonly mistaken for readiness. A mature organization can have a data foundation that still fails a specific AI workload. An organization with high overall data quality can still feed the wrong data to the wrong model. A strong governance program can fail to answer the question “is this model training set fit for purpose?” if no one has looked at the model training set.

Data readiness closes that gap. It asks a narrow question about a specific AI use case and produces a structured, defensible answer. This article defines the discipline, separates it from its cousins, and introduces the AI data lifecycle that will frame every module that follows.

Why readiness is a separate discipline

Enterprise AI programs fail on data more often than on anything else. Multiple independent studies over the past five years converge on the same diagnosis: model work gets the attention, data work gets the residual budget, and the projects die in the gap.¹ A peer-reviewed 2021 Google Research study coined the phrase data cascades for the compounding downstream failures that follow from weak data foundations.² The authors documented that practitioners across high-stakes applications routinely treated data work as a preliminary, one-time, pre-launch activity rather than as an ongoing engineering discipline.

A readiness practitioner exists to reverse that pattern. The discipline is concrete: walk an AI use case through the data lifecycle, score each stage against evidence, identify the gaps that will cause the use case to fail if unaddressed, and produce a single artifact — the readiness scorecard — that a sponsor, an auditor, and a product owner can each read and act on.

The readiness practitioner is not the data steward, not the data engineer, not the ML engineer, and not the governance lead. The practitioner coordinates across all four and produces a consolidated view that none of them would produce on their own. That consolidation role is what the AITM-DR credential certifies.

Readiness is scoped to a use case

The most common way the discipline goes wrong is to drift into a generic data-maturity assessment. A generic assessment can take months, costs a lot, and produces a report that is hard to act on because every finding has to be reconciled against every possible AI use case the organization might ever run. A readiness assessment is scoped to a specific use case and can be completed in two to six weeks.

Scope discipline is the practitioner’s first act. The sponsor will usually describe the use case loosely: “we want to use AI for customer support.” The practitioner tightens it into a testable readiness question: “is the organization ready to deploy a retrieval-augmented large language model that answers customer billing inquiries in English and German, drawing on a twelve-month window of billing-system records and a curated knowledge-base snapshot, served to tier-one agents as a suggestion layer with mandatory human-in-the-loop approval?” The second formulation can be assessed. The first cannot.

Readiness versus maturity

Data maturity measures an ongoing organizational capability. It asks whether the organization has durable practices for discovery, quality, governance, and stewardship that cover its data estate as a whole. Maturity is the multi-year operating standard; readiness is the point-in-time answer for one use case.

The two are related but not identical. A highly mature organization still has to run a readiness assessment for every new AI use case because:

• Use case risk tiers differ. A high-risk hiring model under EU AI Act Article 10 carries data obligations that a low-risk internal search assistant does not.³
• Data scope differs. A mature data program may have excellent coverage of customer and financial data and weak coverage of the HR data a specific use case needs.
• Use case timing differs. The generalized maturity snapshot is six months old; the readiness assessment must be current.

Conversely, a low-maturity organization can still have readiness wins. A startup with no formal data-governance program can still be ready for a narrow use case where the dataset is small, well-understood, and in the founders’ heads. The readiness practitioner’s job is to call that correctly rather than forcing a low-maturity organization through a maturity-scale gate that the specific use case does not require.

[DIAGRAM: MatrixDiagram — readiness-vs-maturity — 2x2 of “Organizational data maturity” (low / high) against “Use-case complexity” (low / high), mapping the four quadrants: mature + simple = readiness follows from maturity; mature + complex = readiness is narrower than maturity; immature + simple = readiness is achievable without maturity; immature + complex = readiness cannot precede maturity uplift]

Readiness versus quality

Data quality measures attributes of data against defined dimensions — accuracy, completeness, consistency, timeliness, validity, uniqueness, representativeness. Quality assessment answers: how good is this data? Readiness assessment answers: is this data good enough, right now, for this AI use case? Those are different questions and they can have different answers.

A dataset can have excellent classical data quality and still fail readiness because it is missing subgroup coverage that an EU AI Act Article 10(3) test would require. A dataset can have mediocre classical data quality and still pass readiness because the downstream model is robust to the specific defects present and the use case carries low risk tier.

The readiness practitioner uses data quality as input but does not confuse the two. Article 2 of this credential extends the classical quality dimensions with three AI-specific ones — freshness versus model training cutoff, labeling agreement, and distributional stability — because AI workloads surface quality failures that BI-era quality programs were not built to detect.

Readiness versus governance

Data governance is the policy, standard, role, and decision-rights infrastructure that says who can do what with data, on what basis, under what controls. Governance is the operating system; readiness is one of many programs running on it.

A strong governance program produces the evidence a readiness practitioner needs: catalog entries, lineage graphs, data contracts, datasheets for datasets,⁴ access policies, retention rules. A readiness practitioner in a strong governance environment spends most of their time assembling evidence rather than generating it. In a weak governance environment, the practitioner spends most of their time generating the missing artifacts from first principles, with the sponsor’s executive air cover.

The readiness practitioner should never attempt to fix the governance program through a readiness engagement. The engagement is scoped to the use case; governance reform is a separate program. What the practitioner does do is document every governance gap that blocked readiness evidence collection, so the governance program has a prioritized, use-case-anchored backlog.

The AI data lifecycle as the reference frame

Every readiness assessment walks the AI data lifecycle. The lifecycle has nine stages, adapted from ISO/IEC 8183 (AI data life cycle framework, 2023) into COMPEL’s operational form:⁵

1. Source — identify the data required for the use case and its candidate origins (internal systems, third-party feeds, open datasets, synthetic generation).
2. Profile — inspect candidate sources for shape, volume, distribution, and obvious quality failures before committing to them.
3. Acquire — contract, ingest, and land the data under governed access.
4. Label — attach target values, annotations, or preference signals where the use case requires them.
5. Prepare — clean, standardize, enrich, feature-engineer, and split into train, validation, and test partitions.
6. Version — produce an immutable, addressable snapshot that will be associated with a specific model version.
7. Validate — confirm the prepared dataset meets the quality, representativeness, and fairness thresholds the use case requires before training proceeds.
8. Monitor — observe the production data (and the data the model sees post-deployment) against drift, integrity, and quality signals.
9. Retire — decommission the dataset when the model is retired or the data becomes non-compliant to hold.

Each stage produces a governance artifact. Source produces a use-case scoping memo. Profile produces a data profiling report. Acquire produces a data contract and a signed data-sharing agreement. Label produces a rubric, a gold set, and inter-annotator agreement measurements. Prepare produces a feature-engineering record and a preprocessing log. Version produces an immutable snapshot reference and a dataset card. Validate produces a fitness-for-purpose memo. Monitor produces an ongoing drift and incident record. Retire produces a decommissioning certificate.

A readiness assessment checks, for the specific use case in scope, that each stage will produce its artifact and that the artifact will be defensible under the risk tier that applies.

[DIAGRAM: TimelineDiagram — ai-data-lifecycle — nine-stage horizontal timeline (source, profile, acquire, label, prepare, version, validate, monitor, retire) with the governance artifact expected at each stage written beneath, and the reference standards (ISO 8183, EU AI Act Article 10, NIST AI RMF MAP 2.3) annotated above the relevant stages]

Not every use case needs every stage

The lifecycle is comprehensive, not prescriptive. A retrieval-augmented generation use case on a curated internal knowledge base may skip the Label stage because no labels are produced; it will spend more effort on Version (the embedding index version is the dataset version) and on Monitor (drift of source documents directly affects answer quality). A tabular prediction use case on an internal transactional dataset will spend most effort on Profile, Prepare, and Validate. A computer-vision use case on third-party imagery will spend most effort on Acquire and Label.

The readiness practitioner should annotate the lifecycle with an explicit scope column per use case: which stages apply in full, which apply in reduced form, and which do not apply. That annotation is the first deliverable of the assessment and the reference point for every subsequent article in this credential.

Fitness for purpose — the readiness decision

The readiness assessment terminates in a fitness-for-purpose determination. The determination has three possible values: fit, conditionally fit, or not fit. ISO/IEC 5259 Part 1 (overview of data quality for analytics and ML, 2024) establishes the vocabulary; COMPEL operationalizes it with a standard decision form.⁶

• Fit — all material stages produce acceptable evidence, no gap exceeds a remediable threshold, the risk tier is matched by the available controls. The use case can proceed to training.
• Conditionally fit — gaps exist but are remediable within a documented timeline; the use case proceeds on the condition that remediation completes before the stage gate the gap affects.
• Not fit — at least one material gap cannot be remediated within the use case’s timeline or budget; the use case does not proceed until the foundation changes.

The practitioner never issues a simple yes or no. The determination is always accompanied by the evidence, the gaps, the remediation plan, and the risk-tier rationale. Article 11 of this credential teaches the scorecard that packages that determination for review.

Two case anchors

Two cases will recur through the credential as anchors for the diagnosis-and-remediation pattern.

Zillow Offers, 2021. Zillow shut its iBuying unit in November 2021 after reporting an $881 million writedown, citing the inability of its pricing model to adjust to a rapid housing-market inflection.⁷ The public disclosure language describes what a readiness practitioner would label a data drift failure in the Monitor stage — the distribution of inputs the model saw in production diverged from the distribution it had been trained on, and the monitoring and response posture was not adequate to catch and contain the divergence before it caused a loss. A readiness assessment conducted before the scale-up would have flagged the absence of drift monitors tied to hard-cutover thresholds, and the remediation would have reduced the blast radius of the eventual divergence.

Data cascades, Sambasivan et al., 2021. The Google Research team studying high-stakes ML applications across four countries found that 92% of ML practitioners reported experiencing at least one data cascade — a compounding downstream failure originating in an upstream data decision.² The study classified four recurring cascade patterns: physical-world brittleness (lab data that did not survive deployment contexts), inadequate domain-expert review, unexpected interaction of data and model, and poor cross-organizational collaboration. All four are addressed by the readiness discipline: scope, evidence, review plurality, and the scorecard’s cross-functional signoff path.

How the credential sequences

The ten articles that follow work through the lifecycle and the readiness dimensions in order. Article 2 extends data quality for AI. Article 3 builds data governance and data contracts. Article 4 covers lineage, provenance, and documentation. Article 5 covers labeling strategy. Article 6 covers feature stores and vector stores as governance artifacts. Article 7 covers bias-relevant variables and subgroup coverage. Article 8 covers privacy and minimization. Article 9 covers third-party data. Article 10 covers drift and sustainment. Article 11 assembles everything into the readiness scorecard.

The two labs give the practitioner hands-on experience profiling a provided dataset and authoring a data contract for a retrieval pipeline. The case study deep-dives the Amsterdam SyRI and Rotterdam municipal-algorithm cases, both of which failed along multiple readiness dimensions and both of which are foundational teaching material for the discipline.

Cross-references

• COMPEL Core — Calibrate: establishing the baseline (EATF-Level-1/M1.2-Art01-Calibrate-Establishing-the-Baseline.md) — the readiness assessment is a specialization of the Calibrate-stage discipline.
• COMPEL Core — Data as the foundation of AI (EATF-Level-1/M1.4-Art05-Data-as-the-Foundation-of-AI.md) — the macro argument that AI programs are data programs in the relevant sense.
• COMPEL Practitioner — Organizational readiness pre-assessment (EATP-Level-2/M2.1-Art03-Organizational-Readiness-Pre-Assessment.md) — the wider organizational readiness context within which the data readiness assessment sits.

Summary

Data readiness is a use-case-scoped, evidence-based determination of whether an organization can run a specific AI workload given its current data foundation. It is separate from maturity, quality, and governance, and it uses the AI data lifecycle as its reference frame. The practitioner produces a fitness-for-purpose decision supported by evidence, gaps, and remediation plans. The remaining ten articles of this credential build that competency dimension by dimension.