Your AI workflow is only as ready as the data it uses.

Start with one decision, then trace its inputs

“We have years of data” does not tell you whether an automation can use it. Start with the output you want: a draft quote request, an internal product answer, or a routed support ticket. List the facts that output depends on. For each fact, name the source and the person who can resolve a disagreement.

Consider a hypothetical apparel quote assistant. A customer email may establish the requested quantity, while a product catalog establishes the variant identifier. An old spreadsheet may contain a price, but that does not make it the approved pricing source. Write down that distinction before asking a model to combine the records.

Use a field-level readiness check

The UK Government Data Quality Framework treats quality as fitness for the intended use. It distinguishes completeness, uniqueness, consistency, timeliness, validity, and accuracy. A filled-in field can still be wrong; a correctly formatted date can still describe the wrong event. The linked framework provides the terminology. The workflow checks below are DBAI’s practical planning approach.

Inspect ordinary records and the awkward ones

Ask the workflow owner for a representative sample from the actual sources. Include normal requests and known exceptions: missing variants, duplicate accounts, stale inventory, corrected orders, and conflicting attachments. Track how the sample was selected. A handpicked set of clean records can demonstrate the happy path but cannot establish readiness across the workload.

Record counts as well as examples. If you report the share of requests missing a required field, state the denominator, date range, and source. Separate defects that prevent a safe action from defects that only limit convenience. A missing optional description and an unresolved customer identity should not carry the same weight.

Choose freshness limits around the decision. Product descriptions and stock availability may need different limits. Also distinguish a successful import from fresh source data: copying yesterday’s unchanged feed today does not make the underlying facts current. There is no universal percentage or timestamp threshold that makes every business workflow ready.

Copy this readiness worksheet into your project brief

# AI data readiness — one workflow
Workflow and intended output:
Business owner and decision date:
Actions allowed during pilot:
Actions requiring human approval:

## For each required input
Field / fact:
Authoritative source and source owner:
Record ID and matching rule:
Allowed users / customer scope:
Required format, units, and meaning:
Source update time / last successful import:
Maximum acceptable age for this decision:
Missing, duplicate, or conflicting value rule:
Evidence retained to trace the output:

## Sample review
Sources, date range, and selection method:
Records reviewed / records failing each check:
Normal cases and known exceptions included:
Unrepresented cases and limits of this review:

## Decision
Ready for a bounded pilot / repair first / narrow scope:
Blocking issues, responsible owners, and due dates:
Fallback process while a record is unresolved:
How corrections reach the source and downstream copies:
Acceptance checks to rerun after repairs:

What this looks like in DBAI’s work

The published Exora INK case study describes a SanMar SFTP catalog feed ingested and normalized through n8n, then synchronized to WooCommerce. The storefront, customer chatbot, and internal assistant use a shared data layer. That is a concrete example of the source-to-system plumbing an AI workflow depends on.

The buying lesson is to scope that plumbing with the assistant. Ask which system owns product facts, how variants are matched, and what happens when an import fails. The case study supports the architecture example; it does not establish a data-quality score or a measured result for the hypothetical quote workflow above.

Make a readiness decision you can act on

Data readiness is an input decision. Pilot acceptance is an output decision. Bring the worksheet to your implementation partner, then agree how you will test the resulting workflow. A clear boundary now is more useful than discovering halfway through a build that nobody owns the source.