Data Readiness Assessment
A data readiness assessment checks, before any development starts, that the data an AI or analytics use case needs exists, is accessible, may be used and is sufficient for the task. The analyst starts from the decision that the use case must serve. On a real extract, the analyst checks each data set: its existence, owner, access, right of use, quality, volume, representativeness and lineage. The IIBA Guide to Business Data Analytics describes these checks. We sort them by Neil Lawrence's data readiness levels: the data is accessible, then trustworthy, then fit for the task. The analyst rates each data set as accepted, remediable or rejected. The decision on the use case follows from these ratings: go, fix first or stop.
Goal
A data readiness assessment establishes whether the available data is enough to deliver a specific use case and what the gap costs. It comes after the use case is framed and before anyone chooses a model or a vendor.
Neil Lawrence observes that project proposals pay little attention to data, underestimate the work it demands and give that work too few resources. Nithya Sambasivan and her co-authors interviewed 53 AI practitioners in high-stakes domains. They use the term "data cascades" for the negative downstream effects that a data problem sets off. These effects often stay invisible and surface late. Of the practitioners interviewed, 92% had experienced at least one.
The deliverable is a data readiness register. Each row describes one data set: the results of the checks, the band reached, the status, who is responsible for each gap and its estimated cost. CRISP-DM documents data understanding in reports on initial data collection, data description, data exploration and data quality. The register condenses the collection, description and quality reports into one row per data set. Exploration belongs to exploratory data analysis. The register shows the sponsor what the project will have to pay before the first model.
Usage
When to use
- A framed AI use case: check the data behind the blocks of the AI Canvas before committing a budget.
- Evaluating a vendor's offer: check that the organisation holds the data the solution assumes.
- Data that "must exist somewhere": obtain an extract before the plan depends on it.
- A new question put to data already in use: repeat the fitness check.
- A merge of two data sets already assessed: assess the combined set. It carries its own re-identification risks.
- A generative assistant over internal documents: assess the document corpus as a data set.
- A dashboard or an analysis without AI: apply the same checks to the sources before building the report.
When not to use
- No use case chosen yet: without a task, band A cannot be judged and the list of data remains guesswork. List and prioritise the use cases first.
- A data set accepted and loaded that now needs detailed study: move on to exploratory data analysis.
- Data from a system not yet built: nothing exists to assess. Define the elements in a data dictionary.
Description
Lawrence's readiness bands
In a 2017 position paper, Neil Lawrence proposed data readiness levels modelled on NASA's technology readiness levels. No standards body has adopted them. The levels form three bands labelled A, B and C. Each band holds sub-levels. They run from C4 for the least ready data to A1 for the most ready.
Band C concerns access. At C4, someone claims that the data exists. Nobody has seen it. Lawrence calls this hearsay data: "Sales must have a record of that." At C1, the data loads into analysis software. The ethical and legal questions about processing it are settled.
Band B concerns faithfulness. Does the loaded data describe what it claims to describe? Lawrence places the data scientist's main difficulty in this band: the gap between what people believe their data holds and what it holds. Reaching B1 is often the most expensive part of the project. At B1, the analyst knows the limits of the data set. Below B1, a faithfulness defect remains open.
Band A concerns fitness for a task. A data set enters this band only once the task is defined. A clean and complete data set may hold no trace of the target variable. The same data set can reach A1 for predicting cancellations and stay at B1 for predicting the response to an offer.
We sort the checks that the IIBA guide and CRISP-DM supply by these bands.
Data readiness levels
Reach, trust, fit to the task, then decide
- existence and owner
- access
- right of use
- quality measured on the extract
- missing values
- lineage
- volume and representativeness for the question asked
Start from the decision and the task
The analyst starts with the task because it determines the list of data to assess. The analyst works from the framed use case: the decision served, what the model predicts, the action that follows. From it comes the list of data needed: the input data, the target variable and the period of history. The list separates the data already collected from the data still to collect.
To plan the collection, the analyst also sets when and how to collect the data and how to validate it once collected.
Set the criteria with the business
The IIBA guide gives business validation to the stakeholders with authority over the data. They approve the sources and set the acceptance criteria. A criterion states, for example, what share of empty values is tolerable for the target variable or what period the history must cover. Before the checks, the analyst writes these criteria as testable acceptance criteria. A threshold set after the measurement bends to the result.
Check existence and owner
For each row of the list, the analyst notes who holds the data and in which system. A claim such as "the call centre records the reason for every call" stays at C4 until an extract confirms it. Without an extract, the project finds the empty field or the wrong period during development. The analyst asks the owner for a real extract covering the target period. A field description or a database schema does not replace the extract. The data dictionary says what the field should contain. The extract shows what it contains.
Check access and right of use
Access raises technical questions: the format, the location, the spread of the data across several systems. A register kept by hand, a PDF or a legacy file format are common cases. Internal data often costs less to obtain than external data. The IIBA guide adds the non-functional requirements of the source: privacy, security, retention period, collection frequency and service level agreements. A privacy or security requirement can on its own make a data set unusable.
The right of use raises legal and contractual questions. CRISP-DM asks the team to verify this right. Data collected to perform a contract cannot always train a model. A licence for external data may exclude that use. The analyst names the constraint and the department that rules on it. Personal data falls under the Federal Act on Data Protection.
Check quality on the extract
The analyst measures quality on the extract that the project will use. The IIBA guide names five characteristics and proposes a test for each. CRISP-DM and Lawrence add the coding of missing values.
| Characteristic | Question | Test on the extract |
|---|---|---|
| Accuracy | Does the value match what the source meant to record? | Compare a few records with what the business application shows |
| Completeness | Are the required fields filled in? | Count the null values per required field |
| Consistency | Is a value the same from one source to the next? | Compare the same customer in two systems. Check that a date field holds only dates |
| Uniqueness | Does a record appear only once? | Look for duplicates on the key |
| Timeliness | Does the data cover the requested period? | Compare the earliest and latest dates of the extract with the target period |
| Missing values | How are they coded, where and in what proportion? | Look for special values: 0, 9999, "unknown", 01.01.1900 |
Data that has passed through a spreadsheet needs an extra check. Lawrence cites the sort that leaves out one column and shifts values without an error message. He also places the check on the collection process in band B: was the collection random or selective? The IIBA guide states that validation stays high-level at this stage. Exploratory data analysis then examines the data in detail.
Trace the lineage
Lineage says where the data comes from, what transformations it went through and where it is stored. Without lineage, the analyst cannot judge quality. Aggregated data can hide its missing values. Lawrence reports a malaria forecasting project in Uganda. The district data had been aggregated without handling the missing values. At first the model showed no spatial correlation. On the raw data, the team handled the missing values and recovered the expected correlation. A processing error in band B produced a negative result in band A. Nobody had documented the aggregation. Lineage makes a step of this kind visible before modelling.
Two sources sometimes code the same information differently: digits in one, letters in the other. The analyst records that a mapping is needed. Data mapping then specifies it.
Judge volume and representativeness for the task
None of the sources cited sets a minimum volume. The answer depends on the task and the model. We advise asking a testable question: does each case that the decision must distinguish have enough examples in the history? An annual event such as a contract renewal needs several years of history. A canton with few customers or a recent product may have only a few dozen cases.
Representativeness is judged against the population the model will decide on. A survey whose sample differs from the target population is the classic case. A history that holds only the files an employee chose reflects that choice. These biases show up at this stage before a model learns them.
This check places a data set in band A for a given task. Another task gives another result.
| Check | Predict cancellation at renewal | Predict the response to a household and motor offer |
|---|---|---|
| Target variable | Cancellation date and reason in the policy system | Response recorded in the campaign tool |
| History | Six annual renewals | One campaign in 2025 |
| Population covered | All customers in French-speaking Switzerland | 4'000 customers in the canton of Vaud |
| Band reached | A1 | B1: the campaign sample covers a single canton |
Decide: go, fix first or stop
None of the sources cited sets out this three-way decision. It is our recommendation as practitioners. The analyst first gives each data set a status: accepted, remediable or rejected. The use case then receives its decision.
| Data set status | Condition | The register records |
|---|---|---|
| Accepted | Every check meets the criterion set for the task | The band reached and the date of the checked extract |
| Remediable | The gap closes at a cost and within a time that the use case justifies | The gap, who is responsible, the estimated cost, the date of the reassessment |
| Rejected | Either the gap costs more than the use case returns or the right of use is missing | The reason and the condition that would reopen the question |
The stakeholders with authority over the data approve the accepted sources and sign the register.
The decision on the use case depends on its required data sets. When all of them are accepted, the use case goes ahead. A required data set rated remediable leads to "fix first": the use case waits for the fix. A rejected required data set stops the use case. A rejected secondary data set narrows the scope. The team builds the model without it. Google advises launching a product without machine learning while the data is missing. According to that guide, a simple heuristic delivers part of the expected gain.
The IIBA guide accepts that a research question may be dropped when the data costs too much to obtain. Lawrence gives example statements that his levels make possible. One estimates the cost of bringing a data set to B1. Another postpones a study until a partner guarantees a C1 data set.
What skews the assessment
Quality measured on the warehouse. The data team states that the warehouse is clean. Yet the project filters one period, one product or one region. The analyst measures the project's extract, which carries its own defects.
A merge not reassessed. Two data sets assessed separately yield a combined set to reassess. According to Lawrence, medical data can be re-identified easily once it is linked with other data sets. Two different collection protocols also make the merge difficult.
Data work underestimated. Lawrence planned a few hours of a weekend to make the metadata of a conference's proceedings loadable. The work took about six working days. The data set held 3'198 papers and raised no privacy question. The register puts a figure on each gap so that this cost enters the budget.
AI considerations
An AI assistant that runs code speeds up profiling. From a data dictionary, it writes the queries that count null values, duplicates and special values. It condenses the output of a profiling tool into a list of anomalies to put to the owner. It reads a sample of a free-text field and estimates what the field holds. It drafts the questions to ask each data owner.
The assistant does not confirm that data exists. An assistant that states "your CRM probably records the date of last contact" produces hearsay. Its sentence stays at C4 like any claim without an extract. Nor does it judge the right of use: the lawyer and the owner rule on that. The extract often contains personal data. The analyst submits it only to an assistant that the organisation has approved. Otherwise the analyst works on an anonymised extract.
For a generative assistant that answers from internal documents, the data is those documents. We apply the same checks to the corpus. In band C: do the documents exist in readable form? Who has the right to read which? In band B: which version is authoritative? Which ones are out of date? In band A: do they cover the questions that users will ask? Retrieval-augmented generation corrects none of these defects: it passes them on in its answers.
The EU AI Act sets out similar checks in Article 10, paragraphs 2 to 4. The article applies to high-risk AI systems. It also reaches a Swiss provider that places such a system on the EU market. The data governance practices it requires include an assessment of the availability, quantity and suitability of the data sets needed and the identification of gaps. The data sets must be relevant, sufficiently representative and to the best extent possible free of errors and complete in view of the system's intended purpose. They take into account the geographical, contextual, behavioural or functional setting in which the system is used. A project outside the high-risk category can use these requirements as a checklist.
Examples
A household insurer in French-speaking Switzerland wants to predict which customers will cancel their policy at renewal. Policies and claims are required for the use case. Call reasons are secondary. The register at 30 June 2025 gives each data set a status.
| Data set | Existence and owner | Access and right of use | Quality on the extract | Volume and representativeness | Band | Status |
|---|---|---|---|---|---|---|
| Policies and cancellations | Policy system. Household products division | Extract received. Use approved by the legal department | 0.4% of policies without a renewal date | 180'000 policies, six renewals, all French-speaking cantons | A1 | Accepted |
| Claims | Claims system. Claims department | Extract received. Use approved by the legal department | Cause codes changed in 2022: digits before, letters after | Six years, all French-speaking cantons | Below B1: cause codes to reconcile | Remediable: code mapping table. Responsible: claims department. Estimate: 5 days. Reassessment in November 2025 |
| Call reasons | Call centre. Announced without an extract, then confirmed by the extract | Extract received. Right of use not examined: data set rejected | Free-text field. Empty in 41% of cases | Recorded since September 2024: a single renewal | B1: the history fails the band A check | Rejected for this use case. Reopen when the call reason becomes a mandatory choice from a list and the history covers three renewals |
No budget fills the missing history of call reasons. Only time fills it. For claims, five days of work on the code mapping make six years of history usable. That cost justifies fixing the data set.
Visualisations
The register fits in one table: one row per data set, one column per check, the band and the status at the end of the row. One colour per status makes the register readable for a committee. When several use cases share a data set, one column per use case shows the band that the data set reaches for each.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | List the data of the use case, find each owner, obtain the extracts. Access lead times dominate. |
| Execution | Medium | Profile each extract and compare the results with the business criteria. The effort grows with the number of data sets and sources. |
| Documentation | Low | One register row per data set. The analyst updates it with each new extract. |
Tooling
A spreadsheet is enough to keep the register. The analyst profiles an extract in SQL on the source database. In Python, ydata-profiling counts null values, duplicates and distributions per field. Great Expectations expresses quality checks as executable rules. OpenRefine lets the analyst explore an extract without programming. A data catalogue such as DataHub, Collibra or Microsoft Purview gives the owners and the lineage when the organisation keeps one. The data dictionary supplies the expected definition of each field, which the extract confirms or refutes.
Sources
No body of knowledge describes data readiness assessment as a technique in its own right. The IIBA guide describes its checks. Lawrence's bands are one author's proposal. The three-way decision is our synthesis.
- IIBA (2020), Guide to Business Data Analytics, §2.2 Source Data (§2.2.1 to §2.2.4) and §2.3.3 Explore Data: planning data collection, the non-functional requirements, data gaps, lineage, business and technical validation, the five quality characteristics.
- Lawrence, N. D. (2017), Data Readiness Levels, arXiv:1705.02245: bands C, B and A, hearsay data, the merging of data sets and the two case studies.
- Chapman, P. et al. (2000), CRISP-DM 1.0: Step-by-step data mining guide: the data understanding phase, its reports and the right to use the data.
- Regulation (EU) 2024/1689 on artificial intelligence, Article 10, paragraphs 2 to 4: data governance for high-risk systems.
- Sambasivan, N. et al. (2021), "Everyone wants to do the model work, not the data work": Data Cascades in High-Stakes AI, CHI '21: the notion of a data cascade and its frequency among 53 AI practitioners in high-stakes domains.
- Google, Rules of Machine Learning, rule 1: launch without machine learning while the data is missing.