
Metadata and ontology have become the foundation AI reads from
| 18 min ReadCategory: Data Governance | Tags: #metadata, #ontology, #semantic layer, #context layer, #knowledge graph, #ai agents
An AI agent with access to the tables answered 0 of 13 questions correctly. When the team added context around the data, one layer at a time, the same model answered 92 per cent correctly.
Last updated: October 2026.
In short: An AI agent that is to answer questions about an organisation’s own data needs more than access to the tables. The measurements from 2026 show that the models write better SQL every year, but that the correct answers come when the columns have descriptions, the business rules are written down and the metrics have an owner. Metadata, semantic layer and ontology are words for parts of the same layer, and the layer can be built step by step without a separate ontology project.
An AI agent at a medical clinic was asked how many appointments the clinic had available. It wrote a query that filtered on slot_status = 'Available', but that value does not exist in the data, because the column uses Open and Filled. The query ran, returned zero rows and gave no error message. The agent answered confidently, and completely wrong.
The example comes from an experiment at the analytics firm Data Culture, where Opeyemi Fabiyi and colleagues measured what it took before the agent answered correctly. The error did not go away with a new model or a better prompt. It went away when the columns got descriptions that said which values they can hold, and what the values mean.
The models have become much better over the past year, and that matters. But the last stretch towards correct answers on your own data comes from the layer around the data: the descriptions, the business rules, the metrics with an owner and the link between the tables and the business concepts. The layer is called metadata, semantic layer, context layer or ontology, depending on who you ask, and this article is about what it consists of and how you build it.
What do the measurements show?
Three independent measurements point the same way. Context around the data raises the share of correct answers more than switching models, and the business rules give the biggest improvement. Better models have nearly doubled the accuracy of text-to-SQL since 2023, but a model cannot know what is not written down anywhere.
Fabiyi and colleagues built the agent for the clinic and asked it 13 business questions with known answers. They added one layer of context at a time and measured two things after each layer: whether the agent wrote a query that ran, and whether the answer was correct.
With raw tables the agent managed nothing. With a modelled table it wrote queries that ran for 38.5 per cent of the questions, but none of the answers were correct. It used the wrong status field, included internal entries and did not know which rows to leave out. With column descriptions all the queries ran, and 15 per cent of the answers were correct. Fabiyi calls the descriptions the single layer that matters most, and they were what made all the queries run. The biggest jump in correct answers still came when the business rules were written in, from 15 to 77 per cent. With defined metrics, verified example queries and a fixed evaluation, the agent ended at 92 per cent. Whether 92 per cent is good enough is another question.

The same team ran a parallel experiment on data from a shop, where the agent wrote queries that ran for 80 per cent of the questions with only the modelled table. Fabiyi writes that the more specialised the field, the more important the descriptions become. Along the way the team also found that some answers marked as wrong were correct, just formatted differently from the answer key, and corrected the evaluation. That is a point in itself, because without an evaluation set no one knows whether the layer works.
The result agrees with an older measurement. In 2023 Juan Sequeda, Dean Allemang and Bryon Jacob at data.world asked GPT-4 questions about an insurance database, with no examples in the prompt. Directly against the SQL database, the model answered 16 per cent of the questions correctly. With a knowledge graph that described the concepts and the links between them, it answered 54 per cent correctly.
dbt Labs has asked the same eleven questions of models from 2023 and 2026, 20 times each. With GPT-4 in 2023, text-to-SQL gave the correct answer 32.7 per cent of the time. With Claude Sonnet 4.6 and GPT-5.3 Codex in 2026, both reached 64.5 per cent. Then the team modelled three new tables in dbt. Text-to-SQL with Sonnet 4.6 rose to 90.0 per cent, and the answers through the semantic layer rose to 98.2 per cent. The semantic layer answered correctly every time on the questions it covered, but could only answer what had been modelled. The accuracy came at the cost of coverage.

Not even the largest environments manage without it. In January OpenAI described the data agent it uses internally, over more than 600 petabytes and around 70,000 datasets. The agent builds on six layers of context: how the tables are used, annotations from people who know the data, descriptions generated with Codex, institutional knowledge, memory from earlier questions and context while the agent runs. Without context, even strong models can give wrong answers, they write.
So the choice of model matters, and the difference from 2023 is large. But when the model only gets the tables, without modelling or descriptions, none of the measurements get above 65 per cent correct answers.
What is the difference between metadata, semantic layer, ontology and knowledge graph?
Metadata describes the data, a semantic layer defines the metrics, an ontology describes the concepts in the business and how they relate, and a knowledge graph is data stored according to an ontology. The boundaries are fluid, and vendors use the words differently, so ask what the layer promises before you choose.
| Term | What it describes | The question it answers | Example |
|---|---|---|---|
| Technical metadata | Tables, columns, data types, owner and lineage | What exists, and where does it come from? | slot_status is text with the values Open and Filled |
| Business glossary | The definition of each business term | What does the word mean here? | An available appointment is a slot with status Open, where we can see patients for a consultation with a doctor |
| Semantic layer | Metrics, dimensions and joins across the tables | How is the number calculated? | Capacity utilisation is filled slots divided by all slots |
| Ontology | The concepts, the relationships between them and the rules that apply | How do things fit together? | Only business customers can have sales contracts |
| Knowledge graph | Data stored as nodes and edges according to an ontology | Which things are connected to each other? | Customer 123 has sales contract 456 |
The word ontology is the most confusing. Massimiliano Geraci wrote in July that it is now used for three things, each with its own meaning. The original meaning is a formal model in RDF or OWL, with classes, properties and rules, and an engine that can reason its way to what no one has written down. The second is a virtual model on top of SQL, where the concepts are mapped to the tables that already exist in the data platform. The third is a governed layer for metrics, defined once and used by BI tools and agents, and this is what the large platforms almost always mean when they say semantics. The first promises that the machine can infer new facts, while the third promises that the number will be the same wherever someone asks. Geraci writes that automatic generation of ontologies went from research demo to a checkbox on every major data platform in about twelve months, and he reads the gap between the meanings as a map of where the weight is shifting.
Beneath the noise lies a good point. Juha Korpela, who writes about modelling in the newsletter Context and Chaos from Atlan, distinguishes between two planes. The data plane is the technical objects, such as tables, schemas and fields, spread across several platforms. The knowledge plane is the meaning: the concepts, the definitions and the relationships between them. The table dim_cust in one schema and clients_aggregate in another may be about the same customers, but nothing in the tables says so. The knowledge plane can say that the business has two types of customer, business customers and private customers, that only business customers can have sales contracts, and that both can place orders.

Korpela writes that the two planes must be kept separate and linked, because it is the link that tells an agent what cust_lt_val means. Without the knowledge plane, the agent guesses based on how things usually are. That often works for the general, and fails on what is specific to the business, which is often the most valuable part. The other failure he describes is semantic silos, where each solution gets its own definitions, and none of them agree with each other across solutions.
Why has metadata become more important with AI?
Before AI, metadata was documentation for people, and a missing description did little harm. An agent reads the descriptions as instructions, and where a description is missing, it fills in its own assumption. That is why ownership, sensitivity and permitted use must now be described so that a machine can read them without misunderstanding.
In the old world, metadata was something dutiful teams filled in after the fact. An owner field, a sensitivity label, perhaps a description no one read. AI has turned that on its head.
In its review of AI data readiness, McKinsey writes that metadata must become the control layer for unstructured content. Autonomous systems use context signals to decide what can be used and how it should be interpreted. Ownership, sensitivity and permitted use must be clearly stated for every extract, not just for the source documentation. Metadata is no longer an archive. It is the instructions AI reads before it answers.
David Effiong at Data Culture writes that outdated documentation only confuses a human a little, while for an AI system it becomes wrong reasoning at scale, without anyone noticing. Martin Sahlen has written about which types of metadata exist, and what they are worth, in the guest post The value of metadata.
The most boring job in the field, writing down what a column means, has become one of the most important.
What does an AI agent need that BI did not?
A report in a BI tool needs to know what a metric is and how it is calculated. An agent that has to explain the number also needs to know when the definition changed, which quality problems existed in the period, and what the number must not be confused with. Without that, the agent answers anyway, just not necessarily correctly.
Effiong splits this in two. The first is retrieval, whether the system finds the right number in the right place, and most modern data platforms are good at that. The second is reasoning, whether the system knows what the number means, when it can be trusted, and what it must not be mixed up with. That is what few have built.
A system can fetch churn_rate for the last quarter without any trouble. To answer why customer churn rose, it needs the definition, whether the definition has just changed, known quality problems in the period and circumstances outside the data.
Effiong writes that a semantic layer built for BI and one built for AI are not the same, even if they look alike in YAML. The layer for AI also needs the relationships between the metrics and the common confusions, a record of when the definitions changed, known quality problems per period and the business rules that live in the analysts’ heads. He calls the layer a contract between the team and the agent. It is the same idea as data contracts, just with a new recipient that takes everything literally.
Artyom Keydunov, co-founder and CEO of Cube, writes that an agent that has to guess the definitions from column names will readily create fifteen versions of “active customer”.
In what order should you build the layer?
Start with a set of questions with known answers, and add one layer at a time while you measure. The order below follows the measurements from Data Culture, and adds ownership and the link to the business concepts, which the other sources point to. Each step also makes the data easier for people to use.

- Evaluation set: Choose ten to twenty questions your business users ask, with answers you know are correct. Without an answer key you do not know whether the next layer helps, and you will not discover that the answer key itself can be wrong.
- Modelled tables: An agent that reads raw tables manages nothing. Tables that mirror the business, with clear names, are the floor, and data modelling is the craft that creates them.
- Column descriptions: Describe each column with the values it can hold and what the values mean. This is what made the clinic agent stop looking for Available.
- Business rules: Write down which rows to leave out, which statuses count, and what is internal. This knowledge only exists in people’s heads, and it gave the biggest jump.
- Metrics with owners: Define the metrics once, and give each of them a business owner, as we describe in the article on data ownership.
- Verified example queries: Add queries you know give the correct answer, for the questions that keep coming up.
- Link to the business concepts: Connect the tables to the concepts in the business glossary or the ontology, so that the same term means the same thing across solutions.
The owner in step 5 is not a formality. Ella Pham wrote in 2024 that a semantic layer without owners of the metrics works against its purpose. Users still argue about what the numbers mean, but can no longer fix them themselves.
This is not an ontology project. Korpela writes that a model of the business does not need to be a documentation effort spanning several years, but can grow out of the knowledge that already exists. Thiago Baldim describes the same thing from SafetyCulture. There, AI in BI was not the main goal, but a nice-to-have. The team cleaned up the data model, the tests, the documentation and the ownership, and the run time on the same data fell from 14 to 1.5 hours. When the agent arrived on top, the first errors were caused by columns that were undocumented or wrongly documented. After a month the analysts had 90 per cent fewer requests for one-off extracts, and almost half the company was asking questions of the data with AI every day.
What are the vendors doing?
All the major data platforms have launched a semantic layer or an ontology in the past year. For an organisation, this means the definitions can sit close to the data, but also that they can become locked into one tool if no one keeps track of where they live.
Snowflake made Semantic View Autopilot, which drafts semantic views, generally available in February 2026. Databricks made business semantics in Unity Catalog generally available and open source in April, with metric views for the metrics. Microsoft has an ontology in Fabric IQ in preview, which describes the business concepts and links them to the data in Fabric.
More interesting than the individual products is the work on an open standard. Apache Ossie, which was called Open Semantic Interchange until the project was accepted into the Apache Incubator in June 2026, aims to make the definitions vendor-neutral. The question then changes from which vendor’s semantic layer you choose, to which definitions can be moved between them. In theory, at least. When we tested the standard at our internal day in October 2026, we found that today it is most useful as a map of the definitions you already have, not as a shared engine that makes all the tools calculate the same way.
What we see at Glitni
The pattern recurs in the projects we are involved in. The value rarely lies in a new model or a new platform, but in the classic work of writing down what the columns mean, coding the business rules that only exist in people’s heads, giving the metrics an owner and making the link between data and business concepts clear.
A client who pays us to write good column descriptions and a tidy semantic model is investing more in AI than one who buys yet another integration with a language model. It sounds almost disappointing, but that is where the measurements point, from 92 per cent at Data Culture to 98.2 per cent at dbt Labs.
The work pays off regardless. A tidy knowledge plane gives faster answers, fewer arguments about the numbers and a foundation people trust, with or without an agent on top. AI is just the reason many organisations are finally prioritising it.
A test
Ask your AI agent, or your BI tool, what “active customer” means in your organisation. Compare the answer with what finance means, and what sales means. If the three answers differ, you do not have a model problem. You have an ontology problem, and no new platform will solve it for you.
How many versions of your most important term are in use right now?
Frequently asked questions about metadata and ontology for AI
Why does an AI agent give wrong answers on our own data? Because it lacks the context people carry in their heads: what the columns and values mean, which rules apply, and how the metrics are calculated. The agent then guesses from names and general knowledge, and a query can run without errors and still give the wrong answer. In the Data Culture experiment, column descriptions and business rules raised the share of correct answers from zero to 77 per cent, with the same model.
What is the difference between metadata, a semantic layer and an ontology? Metadata describes the data, such as tables, columns, owner and lineage. A semantic layer defines the metrics and how they are calculated. An ontology describes the concepts in the business and how they relate, and a knowledge graph is data stored according to an ontology. Vendors use the words differently, so ask what the layer promises before you choose.
Do we need a separate ontology project? Rarely. The model of the concepts can grow out of the work on data modelling, documentation and ownership. Start with an evaluation set, describe the columns and write down the business rules, and add the link to the business concepts where the same term is used in several solutions.
Does it help to switch to a better language model? Somewhat. dbt Labs measured that text-to-SQL nearly doubled its accuracy from GPT-4 in 2023 to the models from 2026, from 32.7 to 64.5 per cent. When three new tables were modelled in dbt, it rose to 90 per cent, and through the semantic layer to 98.2 per cent. The context gave more than the model upgrade.
In what order should we build the layer? Evaluation set, modelled tables, column descriptions, business rules, metrics with owners, verified example queries and the link to the business concepts. Measure against the evaluation set after each step, so you can see what each layer adds.
Sources
- Opeyemi Fabiyi: The Boring Work That Makes AI Analytics Actually Work, Data Culture, 28 April 2026. Figure 1 is based on the figures from this source.
- David Effiong: Analytics Engineering for AI Projects: Context as Infrastructure, Data Culture, 21 April 2026.
- Jason Ganz and Benoit Perigaud: Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update, dbt Labs, 7 April 2026. Figure 2 is based on the figures from this source.
- Juan Sequeda, Dean Allemang and Bryon Jacob: A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model’s Accuracy for Question Answering on Enterprise SQL Databases, arXiv, November 2023.
- Bonnie Xu, Aravind Suresh and Emma Tang: Inside OpenAI’s in-house data agent, OpenAI, 29 January 2026.
- Massimiliano Geraci: Everybody Ships an Ontology Now. Nobody Agrees What the Word Means., LinkedIn, 1 July 2026.
- Juha Korpela: Conceptual Modeling Is the Context Engineering Nobody Is Doing, Context and Chaos, Atlan, 15 April 2026. The examples in figure 3 are his.
- McKinsey: review of AI data readiness, 23 June 2026.
- Thiago Baldim: The journey to Agentic BI, Medium, 15 April 2026.
- Artyom Keydunov: Building BI for Agents, Cube, 30 June 2026.
- Ella Pham: #30 - The why, how and what of semantic layer, Data & Beyond, 9 June 2024.
- Snowflake: Semantic View Autopilot, 3 February 2026, and the documentation for semantic views.
- Databricks: Unity Catalog Business Semantics: Now GA and Open Source, 2 April 2026, and the documentation for metric views.
- Microsoft: Ontology in Fabric IQ, documentation, read 9 October 2026.
