01
A source exists, but its authority is unclear
Several systems contain a plausible answer, but nobody has decided which one is authoritative for this use case or how conflicts should be resolved.
AI Data Readiness
AI does not need all your data. It needs the right evidence for one decision.
Before building, test whether the data behind one AI use case is authoritative, usable, permitted and operable enough to support the intended decision.
TechOne position
Data readiness is not a property of a database. It is a property of a use case.
The same dataset may be sufficient for search, unsuitable for a financial recommendation and unacceptable for an automated action. Readiness can only be judged against a defined task, consequence and acceptance standard.
A platform, warehouse or vector database can make data available. It cannot decide whether the source is authoritative, whether the meaning is stable, whether model use is permitted or whether the result is reliable enough for the work.
- Define the decision before assessing the data.
- Test real and exceptional cases, not only a prepared demonstration.
- Separate technical access from permitted use.
- Preserve source, timestamp and business meaning.
- Treat missing and conflicting evidence as operating states.
- Assign ownership for quality after implementation, not only during assessment.
Why AI data projects stall
Data can exist and still be unusable for the decision.
Most readiness gaps are not solved by moving more data into one platform. They appear where authority, meaning, coverage, permission and ownership remain implicit.
02
The values match, but the meanings do not
A customer, order, margin, incident or completed task may be defined differently across teams and systems. A technically valid join can still produce a false business conclusion.
03
The normal cases work, but the exceptions do not
A demonstration succeeds on complete, recent records while duplicates, corrections, missing fields, unusual documents and historical changes remain untested.
04
Access exists, but permitted use is unresolved
A person or service may be able to read the source without being authorised to send the same data to a model, combine it with another source or expose it in an answer.
05
The data is current at review, but not maintained in operation
No owner monitors freshness, schema changes, failed feeds or deteriorating coverage once the AI workflow is in use.
06
The output cannot be traced to its evidence
The answer looks plausible, but the user cannot see which record, document, timestamp or rule supports a material claim.
Use-case readiness framework
Seven questions determine whether the data can support the work.
Each question produces a requirement that business, data and implementation owners can inspect and use.
-
Decision and outcome
What must the data support?
Define the exact answer, recommendation, draft or action, who uses it, what consequence follows and what makes the result acceptable.
OutputDefined use case, consequence boundary and acceptance criteria.
-
Source authority
Which source decides?
Identify which system, document or owner is authoritative for each material fact and what happens when sources disagree or are unavailable.
OutputSource hierarchy and conflict rules.
-
Meaning and contract
Do the values mean the same thing?
Check whether entities, fields, units, states, relationships and time periods are defined consistently enough for implementation and testing.
OutputUse-case data contract with explicit definitions.
-
Coverage and quality
Which real cases are supported?
Examine normal, missing, conflicting, stale and exceptional cases that the workflow must recognise and handle.
OutputEvidence of supported cases, gaps and unresolved assumptions.
-
Access and permitted use
Who may use which data?
Define which identities may retrieve, combine and expose the data and which fields require minimisation, redaction, review or exclusion.
OutputAccess and data-use requirements for implementation.
-
Freshness and provenance
Can the evidence be traced and trusted now?
Define how current the evidence must be, how its source remains visible and when an answer must refuse rather than rely on stale data.
OutputFreshness, lineage and refusal requirements.
-
Operational ownership
Who owns quality after release?
Assign responsibility for source changes, quality failures, access decisions, monitoring, correction and restriction of the use case.
OutputNamed ownership and operating requirements.
Assessment method
Inspect the evidence before designing the AI solution.
The assessment begins with one defined use case and follows the evidence from its business meaning to its technical and operating boundary.
Included scopeone selected AI use case and the data, owners, access decisions and representative cases needed to judge its readiness.
The assessment records what is supported, conditional, blocked or unknown. It does not assume that implementation should proceed.
How the assessment works
- 01
Define the use case
Clarify the intended output, user, consequence, human decision and acceptance criteria. Broad ambitions are reduced to a testable piece of work.
- 02
Map the evidence path
Identify the relevant systems, documents, owners, transformations, permissions and hand-offs. Separate authoritative evidence from convenient copies and undocumented assumptions.
- 03
Examine representative cases
Review normal work together with missing, conflicting, stale and exceptional cases. Record what is supported, conditional, blocked or still unknown.
- 04
Make the implementation decision
Decide whether the use case is ready to specify, can proceed under explicit constraints, requires remediation first or should be redesigned.
What you receive
Use-case data contract
Required inputs, business definitions, authoritative sources, freshness, permitted use and expected evidence for the selected use case.
Source and lineage map
Where each material fact originates, how it reaches the workflow and which system or owner remains authoritative.
Readiness evidence matrix
Each requirement recorded as supported, conditional, blocked or unknown, with the evidence and assumption behind the decision.
Access and control requirements
Identities, permissions, sensitive fields, redaction, retention, review and refusal requirements that implementation must preserve.
Remediation priorities
Data, process, access and ownership gaps ordered by their effect on the implementation decision.
Readiness decision brief
A recommendation to proceed to specification, proceed with constraints, remediate first or redesign, with the reasons and decision owners made explicit.
Decision, not a rating
A combined rating cannot reveal a critical blocker.
An unauthorised field, an unknown source, missing evidence for exceptional cases or absent ownership can change the decision even when other requirements are well supported.
- 01
Proceed to specification
The material data requirements are supported and the remaining work belongs in implementation.
- 02
Proceed with constraints
The use case is viable only within an explicit boundary such as draft-only output, named sources or mandatory review.
- 03
Remediate first
A defined data, access or ownership gap must be resolved before implementation can be judged responsibly.
- 04
Redesign the use case
The intended decision or action asks more of the available evidence than it can support.
Illustrative readiness decision, not a client claim
Proceed with constraints: prepare an order-status reply, but do not promise a delivery date.
The proposed use case prepares a customer-service reply from order, customer and carrier data. A person remains responsible for reviewing and sending the message.
Decision evidence
Supported
The ERP provides the authoritative order identifier, customer relationship and committed fulfilment state.
Decision evidence
Condition
A carrier estimate may be shown only with its source and retrieval time. It must not be presented as a contractual delivery commitment.
Decision evidence
Exception
Orders with missing carrier events, conflicting customer identifiers or a manual hold must be routed to a person without a generated status claim.
Decision evidence
Access boundary
The customer and order must come from the authenticated service case. A free-text identifier supplied in a prompt is not sufficient authority to retrieve another customer record.
Decision The use case may proceed to specification as a draft-only workflow with source timestamps, explicit exceptions and human review. Automated sending or delivery promises remain outside the approved boundary.
Fit before scope
When an AI Data Readiness Assessment is or is not the right start.
A good fit
- One priority AI use case or operational decision has already been identified.
- Teams disagree about source authority, definitions, permitted use or data quality.
- A demonstration works on selected examples but reliability on real cases is unknown.
- Data, security or process owners need a concrete boundary before approving implementation.
- Management needs evidence before funding a build, integration or wider rollout.
- Representative records, documents or cases can be examined with the appropriate owners.
Not the right fit
- There is no defined use case or decision to assess.
- The primary need is an enterprise-wide data-platform or analytics strategy.
- The requirement is to clean, migrate or reconcile a complete data estate.
- The implementation contract is already accepted and only build capacity is required.
- The expected output is legal advice, a security audit or compliance certification.
- No accountable business or data owner can participate in resolving definitions and exceptions.
Choose the right starting point
Data readiness sits between a chosen priority and controlled implementation.
Portfolio priorities
AI Adoption
Choose which AI opportunities deserve priority, ownership and investment before assessing one use case in detail.
Plan managed adoptionUnclear use case
AI Implementation Review
Clarify the intended outcome and the role of AI before testing whether the data can support it.
Review one initiativeImplementation foundation
AI Enablement
Turn agreed requirements into controlled integrations, permissions, workflow and acceptance tests.
Explore AI EnablementSystem boundary
MCP Architecture
Expose governed data and operations to AI clients without treating connectivity as proof of authority or quality.
Explore MCP architectureDirect answers
What teams ask before AI relies on operational data.
Is this a general data-quality audit?
No. The assessment examines whether specific data can support one defined AI use case. It does not score the quality of the entire data estate or create a generic data-improvement programme.
Do we need clean data before using AI?
Not every field has to be complete or perfect. The relevant question is whether the workflow can recognise missing, conflicting and stale evidence, refuse unsupported conclusions and route exceptions to the right owner.
How is this different from AI Adoption?
AI Adoption helps management select priorities, assign ownership and establish working rules across a portfolio. AI Data Readiness examines the evidence behind one selected use case before implementation.
How is this different from AI Enablement?
The assessment defines what the selected use case requires from its data and identifies the material gaps. AI Enablement implements the agreed process, integrations, permissions, controls and acceptance tests.
Can the assessment cover documents, email and other unstructured content?
Yes. Readiness still requires authority, provenance, permitted use, coverage and exception handling. A document being readable by a model does not make every statement in it current, authoritative or safe to use.
Does RAG or a vector database make our data ready?
No. Retrieval technology can help find relevant content. It does not establish source authority, business meaning, access rights, freshness, completeness or the consequence of using the retrieved information.
Will TechOne implement the recommended fixes?
Implementation can be considered after the assessment, but it is not assumed or included automatically. Any data preparation, integration, permission or workflow work receives its own agreed scope.
Does the assessment certify that the use case is secure or compliant?
No. It records the data-use, access and control requirements relevant to the implementation decision. Internal legal, security, privacy and risk owners remain responsible for their approvals, and specialist assurance may still be required.
What happens if the data is not ready?
The useful result may be a smaller use case, a constrained workflow, a specific remediation priority or a decision not to proceed. The assessment is not designed to justify implementation regardless of the evidence.
What should we provide with the initial request?
Describe the intended answer, recommendation or action, the people who will use it, the systems or documents expected to support it and what is currently unreliable or unknown. Detailed preparation is agreed only after the request has been reviewed.
Evidence before implementation
Test the data assumption before you fund the build.
Describe one AI use case, the decision or output it should support, and the systems or documents expected to provide the evidence. David will review the situation and reply with the proposed scope, preparation and price. Nothing is booked automatically.