AI-ready

Everyone says fix your data foundation. Fewer people describe what ready means, or how to get there.

Two teams, one question

Same company, same week, the same question asked twice.

The CFO asks the team that supports finance: what was net revenue in EMEA last quarter, how did it change, and why? The answer comes back in minutes. 6.5 million, down 28 percent. Discounting rose by half, returns rose more than fivefold, and 3.1 million of orders were placed and never booked.

The Head of Sales asks her own team the same question. Same region, same quarter, and the same orders underneath, because both teams are served by the same source system and their tables are identical. That answer also comes back in minutes. 11.0 million, up 10 percent, on higher order volume.

Two numbers, 68 percent apart, pointing in opposite directions, from the same rows. Nobody was careless. Nothing broke.

Figure 1. The same rows, the same question, two teams. Only one of them had written down what net revenue means.

Both tables carry the same columns, and they are perfectly ordinary ones: amount, discount, returns, and a status holding CONF or PEND. Nobody named anything badly.

The finance team had written two things down beside the data, in a file a machine reads: what the fields mean, and which arithmetic is certified as net revenue.

The sales team loaded the same data and pointed an agent at it.

So that agent decided for itself. It summed amount, which is the most common reading of that table and defensible from everything visible in it.

That is a constructed example. The pattern is not: 57 percent of enterprises say they have watched an AI agent be confidently wrong, 7 percent describe their data as fully ready for AI, and 88 percent believe their context is already operational. [ref 1] [ref 2]

Three reasons the wrong number went unnoticed

All three are visible in those same four columns.

• amount looks finished. The deductions sit in the next two columns and nothing says whether they have been applied.
• status decides what counts, silently. CONF and PEND are codes until someone writes down that a pending order was never booked. This alone was 3.1 million of the gap.
• The certified arithmetic lives in someone's SQL. So every new consumer re-derives it, and some derive it differently.

Familiar names are what let all three pass. When a column is called a or amt_2, everyone slows down: the analyst asks a colleague, the model flags an assumption, the reader sees the hedge. When it is called amount, the name implies its own meaning and nobody stops to check.

One gap, four workloads

Anything that consumes your data has to work out what the data means. The useful question is who does that work, and when.

• Operational applications resolve meaning at design time. A developer wrote the contract.
• BI resolves meaning at build time. An analyst decides net revenue is confirmed orders less discounts less returns, and encodes it into SQL.
• Machine learning resolves meaning at training time, once, with someone reviewing the features before the model ships.
• An agent resolves meaning at run time, alone, every time it is asked. Where the semantics are thin it makes a reasonable inference, and possibly a different one next week.

Figure 2. Each consumer resolves meaning at a different moment. Only one does it alone.

Every consumer of data before this one arrived with a person attached, someone who could ask a colleague what a column meant. Agents are the first data consumer that cannot ask.

Which is why data is often BI-ready without being agent-ready, and rarely the other way round. A dashboard that has been right for a decade reflects an analyst who resolved the meaning correctly and encoded it into the query. The knowledge is real. It simply lives in SQL rather than in the data.

Agents raise the bar in a familiar way. Anyone who has written a good prompt knows the feeling: the model performs in proportion to how precisely you say what you want. Data works the same way. Agents are asking us to be explicit about things we have carried informally for years.

Which raises a practical question. If the meaning has to be written down, how would you ever know that it was?

Where the evidence comes from

There is already a good description of what a ready dataset looks like. The data mesh community wrote it well before agents were reading anything, in six characteristics known as DATSIS: Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure. Underneath the six sit eighteen capabilities, and together they make a matrix most data teams will recognise.

The matrix tells you what to look for. It does not tell you where the evidence comes from, and that turns out to be the whole problem, because there are three categories and they are not interchangeable.

Emitted. Your platform produces it on its own, continuously. Registration, types and formats, who queried what, whether monitoring runs and the data is fresh. Excellent evidence, and it settles nothing that requires a decision.

Confirmed. A platform signal that a person checks. The owner field is populated, but has anyone actually signed off? A PII tag exists, but is it on the right columns?

Declared. A file you write and version, holding the decisions no platform can produce because they are judgments rather than facts. Vendors call it a semantic model or a data contract. It is the file the sales team did not have.

Figure 3. Every capability in the matrix is evidenced by exactly one of the three. Illustrative template, not a benchmark.

Map the eighteen and the shape of the problem appears. Four of the six characteristics lean on Emitted and Confirmed evidence, which is exactly why the platforms delivered them years ago: catalogs, naming standards, quality checks, monitoring, ownership, access controls. That was the right sequence, because those four are what people and dashboards needed most.

Self-describing and Interoperable are the two an agent leans on hardest, and five of their six capabilities are Declared. No platform can fill them. They wait on a file.

That file is a configuration. Six things it has to carry, none of them inferable from names, types or profiling:

• Scope, which rows count. Pending orders are placed, not booked.
• Grain, what one row is. An order, not a customer and not a line item.
• Meaning, what each field and each code value represents.
• Metric, which single arithmetic your company has certified.
• Time, which date governs, and whether history has been restated.
• Relationships, the keys that let two domains be asked about together.

Two conditions sit alongside: authority, which definition is certified and by whom, and visibility, whether what the agent can reach matches what the asker is permitted to see.

Standards for all of this already exist. Semantic models have an interchange specification backed by a broad vendor coalition, data contracts have a standard under the Linux Foundation, and the major platforms have shipped governed metrics, glossaries and domains. [ref 3]

Why the declared file is usually empty

Four reasons, and none of them is a tooling problem.

A reasonable hope that the model will work it out. Models are good at inference and getting better, but inference and decision are different things. Profiling a table will tell you a field holds money and that two tables share a key. It will not tell you that your company excludes pending orders from revenue, because that was settled in a meeting, not left as a pattern in the data.

It looks like a large-scale program. Framed as an enterprise metadata initiative, it waits behind everything else. Framed as part of defining one data product, a team can start it now and finish it in parallel with the pipeline work already scheduled.

The meaning is scattered. Technical metadata in the catalog, business definitions in a governance tool, tests in the transformation layer, metrics in the semantic layer, and the knowledge that decides whether an answer is right sitting with experienced people. Each is a legitimate system doing its job. What is missing is one place where it comes together in a form a machine reads at run time.

AI is already filling it in for you. Catalogs now draft a description for every field and propose glossary terms. It will save an enormous amount of typing. It will also generate more text than anyone can review, and people accept it precisely because it reads well. net_revenue described as "revenue net of deductions" is perfectly good English and still does not mention returns.

A right answer is the sum of the parts

Every part can be done well and still leave you with a wrong number. The definition can be certified while the status semantics are missing. The semantics can be written while two domains still disagree about region. Correctness is not a property of any single capability. It emerges from all of them working together on a real question.

You already test your data. Now test the meaning.

Every serious data product ships with tests. This column is never null. This total reconciles. This key is unique. All of them test values, and they are all worth having.

None of them tests whether the meaning is legible. A table can pass every quality check ever written and still tell an agent that net revenue grew 10 percent in a quarter when it fell 28.

That gap mattered less before, because BI had a person standing in it. A dashboard is a user interface: someone who knew the business looked at the number and said that cannot be right, and the error stopped there.

So a known-answer test belongs in the build-out of a data product, next to the quality tests you already run. Same discipline, pointed at meaning instead of values.

What a known-answer test is

You know the answer before you ask. That is not a weakness in the test, it is the mechanism, exactly as with a unit test: the developer already knows what the function should return, and writing it down is what makes drift detectable later.

Take the question this article opened with. You know it is 6.5 million, down 28 percent. Ask an agent:

Nothing about the data changed between those two rows. One file appeared beside it.

Amber to green, in one rule

Figure 4. Four lines in a file make the cell amber. Questions coming back right make it green.

A capability turns green when a question that depends on it comes back right. Until then it is amber: written down, and never checked.

The questions do not inspect the file, they depend on it. Change counts_as_revenue to true and the answer moves from 6.5 million to 9.6 million. That is why a right answer counts as evidence about the declaration, and why nobody has to sit and review the file by hand.

Which makes the amber count the number worth reporting. It is not a maturity score. It is how much of your readiness you are currently taking on trust, and it points at where the next wrong answer will come from.

Two moments are worth running it. Before go-live, because you can only prove a before if you measure before. And on a schedule afterwards, because definitions change, schemas drift, and an answer that was right in March can quietly stop being right in June.

None of this is a large program. It is one domain, a file, and a set of questions somebody already knows the answers to. And the questions are what hold it together. Ask what net revenue was in EMEA last quarter, and a right answer proves scope, grain, the certified metric and the status semantics all at once, because getting any one of them wrong changes the number. Readiness is not eighteen boxes ticked. It is a question your business actually asks, coming back right, for a reason you can point to.

Figure 5. The whole thing in one view. Two sources your platform already produces, one you write, assembled into the matrix, and none of it counting until a question with a known answer comes back right.

Try it

Everything above is in a public repo: github.com/lisamirkovic/ai-ready-data-kit. Clone it and run python3 walkthrough.py, and it walks the whole thing in about ten minutes. The two teams and their question, so you can reproduce the comparison at the top of this article. The declared file as a template to fill in for one domain. A known-answer test set that fails before the file exists and passes after it. And the readiness matrix generated from those two inputs rather than from a questionnaire.

Doing it on your own data is six steps, and only three of them are typing.

1. Pick the questions your people already ask, in the words they use. Five is enough to start. Not data quality metrics: questions someone senior asks and acts on.
2. Work back to the tables behind them. Usually under a dozen.
3. Establish the answers, once, with whoever owns the number.
4. Write the decisions into a declared file. One per domain.
5. Write the questions and their known answers beside it.
6. Run them, before anyone is given access and on a schedule afterwards.

Steps 1 to 3 are conversations, and they are the ones most readiness work skips. Steps 4 and 5 are two YAML files. Step 6 is a script.

The steps above fill the Declared source only. The other two are mechanical rather than difficult. Emitted values can be pulled straight from your platform's metadata, and Confirmed ones are the same pull with a person's sign-off recorded against it. Both can be expressed as YAML in exactly the same way, and feed the same matrix. Nothing about the approach changes; there is just more of it.

If you would rather not do it alone, that is the work I do, and it is narrow deliberately. One domain, proved: the five questions your people ask most, the definitions certified and written where a machine reads them, and a test set showing what your agent answered before the work and after it. The deliverable is not a maturity rating. It is a set of questions your agent now answers correctly, and the evidence of the difference. It sits alongside your tools rather than replacing any of them, on whichever platform you have already chosen.

References and materials

ref 1. VB Pulse survey, June 2026: 57 percent of enterprises have watched AI agents be confidently wrong. ref 2. State of Context Management 2026 and 2026 State of the Semantic Layer: the 7 percent and 88 percent figures. ref 3. Open Semantic Interchange · Open Data Contract Standard v3.1 · Unity Catalog, Data + AI Summit 2026

• The kit: github.com/lisamirkovic/ai-ready-data-kit: the two teams and their question, the declared file template, the known-answer tests, and the matrix. MIT for the code, CC BY 4.0 for the docs and data.

← All words