The economics of meaning flipped

In this chapter

Two readers, one question. What a model does with stated meaning that it can’t do with a schema.
The numbers and the platforms. What an ontology adds on enterprise questions, and the semantic layer every platform now ships.
Where the AI stops. Why the line a person holds sits exactly where models read badly.

Can a model really do more with stated business meaning than with a schema? Benchmarks that test turning a plain question into a database query, text-to-SQL benchmarks, have measured it. Every major platform now builds on the answer.

Two readers, one question

Ask an AI assistant how many customer accounts you lost last quarter. Hand it only the schema of two systems: an order management system with a Customer table and a sales system with an Account table. It has to guess which table is the customer, or whether both are. It’ll count rows in a table that holds one row per customer version and report versions as customers.

Every guess arrives in confident prose.

Now hand the same assistant a description of what your data means, written for a machine. That’s the ontology, and from it the assistant learns that a customer account is a thing the business tracks, an entity named Customer Account. The order system identifies one by customer number, and that number is only unique within one company code of the order system. So the account’s business key is the pair, company code and customer number, from record source awlt. The sales system identifies a Customer Account by its own account identifier, from its own record source.

It also learns that the customer table holds a row for every version of an account, so one row is one version of a Customer Account. Only the current version should be counted. And the Status column is tied to a defined business attribute whose list of codes says which codes mean closed.

The question and the model haven’t changed. The answer has, because the second reader was handed meaning as text. The first had to rebuild it from column names.

The same assistant asked one question twice: handed only the schema it guesses, handed the ontology it answers.

How much does an ontology lift AI accuracy?

In 2023, Sequeda, Allemang and Jacob built a benchmark from an enterprise schema. They asked a large language model business questions against it two ways. Posed directly against the SQL schema, the model “achieves an accuracy of 16%”. Keep the questions and the model the same, and “this accuracy increases to 54% when questions are posed over a Knowledge Graph representation of the enterprise SQL database”. The knowledge graph was an ontology over the same tables, so nothing about the data moved.

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

In 2026 a paired benchmark tested three of the most capable models of the day. It found that 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 the document, the three models 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 company’s 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, the questions that needed more than four tables scored zero against the schema. Against the ontology, whose relationships were explicit, they scored over a third.

AIMS (AI-ready, Meaning-first Silver) answers both. Every business attribute a column is tied to carries a description. Each relationship states the role it plays and how many rows on each side can match, its cardinality. So an agent finds the column, and joins without doubling a row.

Benchmarks are tidy and your estate isn’t. But the lift didn’t come from a bigger model or a cleverer prompt. It came from an ontology written over tables that already existed. That’s exactly what this book tells you to build.

Our post “Meaning before machinery” says the model now writes working code in minutes, and that “the bottleneck has moved to the one thing the machine cannot know on its own: what your business means.”

Two benchmark groups as bars: accuracy rose from 16 to 54 to 72 percent when an enterprise schema was replaced by an ontology, and from 8 to 10 to 78 when a pharmaceutical schema gained a document saying what its tables mean.

The vendors settled the direction

You don’t have to take it from us. Every major platform now says in its own documentation that answer quality depends on curated semantic context. Each has built its own semantic layer to hold it.

Databricks describes its knowledge store, which grounds its Genie assistant, 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.”

Microsoft’s Copilot documentation for its reporting tool is the most candid: “Without preparation, Copilot can misinterpret the data and return generic or inaccurate results.” The ontology item in 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.”

Notice what none of those objects asks for: a restructured silver. Each sits over the tables that already exist and supplies the meaning as context. That’s the AI era’s answer to where modeling goes.

Gartner’s May 2026 release put it flatly: “Traditional schema-based data models alone no longer suffice for agentic AI because they lack business context and data meaning.”

In September 2025 Snowflake, Salesforce, dbt Labs and more than a dozen others launched the Open Semantic Interchange initiative, now Apache Ossie, in the Apache Incubator. It aims to define “a common, vendor-neutral semantic model specification that standardizes how semantic metadata is defined and shared”. You only need an interchange format when every vendor’s object is an island.

Written first, the meaning generates what the vendors annotate

Each of those objects annotates tables that already exist. It’s in one platform’s format, read by that platform’s assistant, and written after the data landed. None generates the tables or drafts the marts. None exports a contract saying what one row is, in a form that a code generator working from metadata on another platform, a template engine, can read.

They’re the right idea at the wrong altitude: a semantic layer over a physical layer still built the old way.

AIMS inverts that order. The meaning layer, the business model plus the mappings that tie silver columns to it, is written first, in the catalog, on no platform in particular. The silver layer is generated from it. The marts are drafted from it. And the same metadata is what the agent reads. So “use my platform’s semantic layer and stop” isn’t the end of the argument.

Where the AI stops

The economics flipped because a model reads meaning, and the limit of what it may decide follows from what it reads badly. It’s reliable at drafting, and 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.

So AIMS draws a line there. The AI proposes, with evidence or a stated assumption on every suggestion. 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 isn’t a brake on the AI. It’s the reason the result can be trusted.

The flip, stated

Before, meaning had to be structural to be usable by a machine. So it was expensive to add (a table per concept, another per fact about it) and expensive to change (a migration per changed definition). Third normal form and Data Vault were right to pay that price when it was the only price on offer.

After, meaning is metadata a machine reads. It’s cheap to add (a sentence in the catalog, mapped to a column) and cheap to change (edit the sentence, regenerate what depends on it, compare the contract). It no longer has to be carried by the shape of the tables.

So the tables can keep the shape of the source, with integration built only where a specific business requirement calls for it.

Meaning moves from inside the table shapes into a catalog that a person, a template engine and an AI agent all read.


The structural answer	A vault answers the churn question with four or five tables for the order system alone, loaded before the first query, where the meaning layer answers it with six lines of metadata.
What the agent reads	The entity, its grain sentence (one row is one Customer Account version from record source awlt), its business key and record source, the sold-to relationship from Sales Order, the code list, and the status attribute that uses it.
Yours to decide	How much of the AI’s drafting a person reviews, knowing that every decision changing meaning or values stays with a person, whatever the model’s confidence.