For decades, the only way to make a machine use what your data means was to build that meaning into the tables. Now a model reads it as a sentence. And the benchmarks have measured what that sentence is worth.

That flips the economics of data modeling.

Two readers, one question

Ask an AI assistant how many customer accounts you lost last quarter. Hand it only the schema of an order system with a Customer table and a sales system with an Account table. It has to guess which table is the customer, and it’ll count every customer version as a customer, in confident prose.

Now hand it a description of the things your business runs on: how each is identified, how they relate and what describes them. Written down, that’s your business model. Written so a machine can read it, it’s an ontology.

From it, the assistant learns a customer number is only unique within one company code. So the order system tells accounts apart by company code and customer number together. That pair is the account’s business key, and it only means something inside the system that issued it, the key’s record source. The assistant also learns to count only an account’s current version, and which status codes mean closed.

The question and the model haven’t changed. The answer has, because the second reader was handed meaning as text.

How much does an ontology lift AI accuracy?

Benchmarks that test turning a plain question into a database query, text-to-SQL benchmarks, have measured that gap.

In 2023, Sequeda, Allemang and Jacob asked a large language model business questions over an enterprise schema. Against the SQL schema, the model “achieves an accuracy of 16%”. Over an ontology of the same tables, written as a knowledge graph, “this accuracy increases to 54%”.

Nothing about the data moved.

A follow-up a year later added the ontology’s rules and let the model decline. Accuracy rose to 72 percent, “including an additional 8% of ‘I don’t know’ unknown results”.

A 2026 paired benchmark by Rumiantsau and Fokeev tested three of the most capable models of the day. A written guide to what the tables and their measures mean, a semantic layer document, “improves accuracy by +17 to +23 percentage points across all three models”. With it, the three were statistically indistinguishable. The model isn’t the variable. The context is.

Which kind of meaning does which job? In 2024, Painter and colleagues gave a model a pharmaceutical safety database of more than five hundred tables. Cutting its schema document to the thirty-six essential tables lifted the share of queries an expert passed from 8 percent to 10. A document describing what the tables meant lifted it to 78.

Descriptions find the right table and column. Structure gets the number right. In the 2023 benchmark, questions needing more than four tables scored zero against the schema and over a third against the ontology, whose relationships were explicit.

The platforms write meaning over the tables

Every major platform has built its own semantic layer for that kind of meaning. Databricks describes its knowledge store as “a collection of curated semantic definitions that enhances Genie’s understanding of your data and improves response accuracy.” Snowflake says its semantic views “address the mismatch between how business users describe data and how it’s stored in database schemas.” The ontology item in Microsoft Fabric, still in preview, promises to “ground agent experiences in governed definitions, relationships, metrics, rules, and source mappings instead of relying only on raw schemas or prompts.”

None asks you to rebuild your tables first. Each sits over the ones you already have.

Meaning used to cost a table, and now it costs a sentence

Before, a machine could only use meaning built into structure. Two long-standing ways to design a data warehouse, third normal form and Data Vault, gave every business thing its own table. Adding meaning cost a table per concept. Changing it cost a migration. Those methods were right to pay that price when it was the only one on offer.

Now meaning is metadata a machine reads. Adding it costs a sentence, mapped to a column. Changing it means editing the sentence and regenerating what depends on it. That sentence needs one home your team and the model share. That’s the catalog.

A lakehouse moves data from raw bronze through cleaned silver to report-ready gold. With meaning written over the tables, silver can keep its sources’ shape, and integration gets built only where a specific business requirement calls for it. That approach is AIMS, short for AI-ready, Meaning-first Silver.

Where the AI stops

So what can’t a model work out for itself? It drafts reliably, but it’s unreliable at what a business key really identifies, at the rules your business never wrote down, and at whether two identifiers in two systems are the same customer. Take the first. Nothing in the order system’s schema said a customer number is only unique within one company code. Someone had to write it down.

So AIMS draws a line where models read badly. The AI proposes, with evidence or a stated assumption on every suggestion. In AIMS, a person approves every decision that changes meaning or values, however confident the model is. That line is the approval boundary.

The AI does most of the hours and a person carries most of the risk. That split is why you can trust the result.

Count your next question in sentences

What the assistant learned about the order system comes to six lines of metadata. A Data Vault holds the same meaning in four or five tables for the order system alone, loaded before the first query.

  1. Try that on the question your finance team asked last week.
  2. Write down what an assistant would need to answer it, from what one row means to which codes mean closed.
  3. Build a table only where a requirement still asks for one.