Data Readiness: What Your Data Must Look Like Before an AI Project

The data problem is usually the real project

Teams scope an AI feature around the model and discover the data isn't reachable, isn't labelled, or isn't current. Data readiness is the assessment you do before committing a timeline, because if the data isn't there, building the data pipeline is the project and the model is the easy part.

Can you reach it?

• Is there a usable API for the data the feature needs — order status, application state, product attributes? If order data lives in a system with no API, that integration is the real work.
• Is it fresh at read time, or a nightly snapshot? A fraud model or a support agent needs current state, not yesterday's.
• Can you get it inside the latency budget? A reporting query isn't a point lookup.

Do you have labels?

Supervised models need outcomes. Some domains hand them to you — fraud chargebacks, search clicks, resolved-or-not on a ticket. Others need a human to adjudicate, cold, against a written rubric. If there are no labels and no cheap way to get them, that's a cost and a delay to plan for, not a footnote.

Is the content current and consistent?

For anything grounded in documents — a support agent, semantic search — the answers are only as good as the source. A vague returns policy produces a vague agent. Inconsistent attributes across suppliers produce weak search. On our semantic-search engagement the first weeks of transcripts effectively audited the product data; expect the same, and budget for the cleanup.

Is there enough history?

A behavioural model needs history to compute features and to train — velocity aggregates, "seen before" flags, a customer's normal pattern. A brand-new product line or a low-volume flow may not have enough signal yet, and no model fixes that.

Can you reconstruct the past correctly?

If you'll train on historical data, each training row needs feature values as they were at that moment, not as they are now. Without a time-versioned store or an event log to replay, point-in-time-correct training sets are hard, and the model that looks great offline underperforms live.

The assessment is a deliverable

Data readiness isn't a gut check — it's a short report: for each data source the feature needs, does it have a usable API, is it fresh at read time, are there labelled outcomes, is there enough history, and can the past be reconstructed correctly. Each answer is green, amber, or red, with the amber and red items costed as work. The pipeline write-ups in our portfolio open with exactly this — the non-functional and data constraints assessed before any model was picked, because they're what decide the timeline.

The cost of skipping it

A project scoped without a readiness check tends to discover, in week three, that the order API doesn't exist, or that there are no labels, or that the product data is too inconsistent to ground a search. Now the "AI project" is a data-engineering project with an AI feature bolted on the end, and the original estimate is fiction. An afternoon of readiness assessment up front is the cheapest risk reduction available.

Where this stops being right

• A feature over data you fully control and already serve — the readiness check is quick.
• An unsupervised or rules-based approach — the labels requirement drops, though reachability and freshness still apply.
• A prototype to learn something — you can work with whatever data you have and note the gaps.

FAQ

What's the most common data blocker? No usable API for the transactional data the feature needs. Building that integration is often the bulk of the timeline.

We have no labels — can we still build? Sometimes, with rules or unsupervised methods, or by standing up a labelling process. But "no labels" is a real cost and delay, not something to discover mid-project.

How much history is enough? Enough to compute the behavioural features and to train and validate with a time-based split. Low-volume or brand-new flows may not be there yet — and for a supervised model, you also need enough matured labels, which for slow signals like chargebacks or loan defaults can lag the raw history by months.

ISTRALLEN runs a data-readiness assessment before committing a build timeline — reachability, labels, freshness, history; see what we do.