An agent asked for net revenue by sales rep before the 2025 territory change can do one of two things. A model writing raw SQL finds a reps table, an invoices table and a join key, and returns a number. A semantic layer with no definition for pre-change territories returns an error. The number looks better in a demo. The error is the one you want behind a board deck.
That difference is most of what remains of the case for the enterprise ontology. It holds only if a named person decided the definitions on a known date. The 2026 wave of products that generate those definitions automatically puts the guess back in, now carrying the word "ontology." This post argues for budgeting the agreement, not the graph.
The original pitch for ontologies in AI was accuracy, and it arrived with a strong number. In 2023, Sequeda and colleagues at data.world, then a seller of a knowledge-graph data catalog, tested GPT-4 zero-shot on an insurance-domain enterprise schema. Over the raw SQL schema it averaged 16.7% execution accuracy. Over a knowledge graph built from an ontology plus mappings, it reached 54.2%, a little more than 3x. On high-schema-complexity questions, SQL accuracy was 0%. The paper's own conclusion recommends buying a data catalog with a knowledge-graph architecture, so treat those figures as a vendor's benchmark too.
The models have improved since. In April, dbt Labs reran the benchmark on the same ACME Insurance dataset: 11 questions, each run 20 times. In dbt's runs, text-to-SQL went from 32.7% with GPT-4 in November 2023 to 64.5% with Claude Sonnet 4.6. The semantic layer scored 72.7%. After an LLM added three dbt models, text-to-SQL hit 90.0% and the semantic layer 98.2%.
Both configurations show the same 8.2-point gap. As a ratio, that's about 1.13x and then 1.09x. Don't set those beside the 2023 3x as one trend line: that figure compared a knowledge graph with raw SQL in data.world's setup, while dbt compared its semantic layer with text-to-SQL in its own. What dbt's rerun does show is a single-digit gap between a defined layer and a current model. Discount even that. dbt sells the semantic layer, and 11 questions on one schema is a small sample. To get text-to-SQL working, dbt loaded the entire schema into context, which it says isn't practical for larger datasets. On a real warehouse the gap could widen again. The evidence is suggestive, not conclusive. Evidence this thin can't carry a platform purchase on accuracy alone. Forrester, for one, has adopted the language anyway. In an analyst blog post it now calls the context layer "the next evolution of semantic layers and knowledge graphs," built "through graph-based ontologies and linked context."
The dbt post says the important part itself: "With text-to-SQL, failure looks like a plausible but incorrect answer. With the Semantic Layer, failure looks like an error message." And more bluntly: "Text-to-SQL will cheerfully give you a wrong number."
At 90% accuracy, the remaining misses arrive formatted exactly like the hits. They come with two decimal places, a chart and a confident sentence. The case here is that a number that looks right invites fewer checks than an error does. The failure produces output that passes for success, so nothing prompts a check. An error message gets noticed the first time it appears.
So the durable value of a defined layer is its boundary. Inside the definitions it answers. Outside them it refuses.
The boundary cuts both ways. A layer that refuses out-of-scope questions answers in-scope ones with full confidence. If the definition inside the boundary is wrong, the layer returns a wrong number with the authority of a system known to say "can't answer." If users learn that the layer refuses when it doesn't know, they'll reasonably read every answer it does give as checked. That plausibly makes a wrong definition more dangerous there than in text-to-SQL, where users have less reason to drop their skepticism.
That makes the definitions the load-bearing part, and the 2026 products are automating exactly that part.
The vendors deserve a fair reading. Microsoft's Fabric IQ ontology, in preview, can generate an ontology from Power BI semantic models, and "changes follow a proposal-first model so users can review them before applying them." A rule there is "a natural-language statement of business logic linked to ontology concepts." Snowflake's Semantic View Autopilot uses query history accessible to the creating role "to generate both relationships and verified query suggestions," which you can review and apply. Databricks' Genie Ontology, also in preview, gives each snippet "an authority score based on where it was generated from, how often it is used, and how fresh it is," then "ranks the most relevant snippets, resolves conflicts, and answers."
Review buttons exist. The risk is in what the review checks. In Databricks' score, usage frequency and freshness measure popularity, and source measures provenance. None of the three records who agreed to a definition. Snowflake's suggestions start from queries people already ran. The most-used definition of "active customer" can be the one finance stopped accepting last quarter, because old dashboards still run it every hour. A suggestion mined from query history encodes what people ran, wrong queries included.
Read "resolves conflicts" twice. Two competing definitions of a term amount to a business decision, and here a ranking function settles it at question time. TopQuadrant, which sells formally governed ontologies and so has a stake in this point, puts it most sharply: an inferred definition "can tell you how a term is currently used. It cannot tell you what anyone agreed."
Voltaire wrote the logic down in 1759. In Candide, Pangloss proves "that things cannot be otherwise than as they are": the nose was "formed to bear spectacles," and so "we have spectacles." An ontology mined from usage reasons the same way. The definition exists and the dashboards run it, so it must be the right one. Rank by popularity and freshness, and whatever wins is, by construction, the best of all possible definitions. Nobody had to agree to it for it to win.
"Models will close the last 8 points too." Maybe, on accuracy. But take two valid definitions of active customer: a paid invoice in the last 90 days, or a login in the last 30. Both are computable from the schema, and both are defensible. No amount of schema reading tells a model which one the organization adopted. That's a decision. It's recorded somewhere or nowhere, and a better model doesn't change which.
"Inferred definitions beat nothing." For ad hoc exploration, yes. dbt's own recommendation is "Text-to-SQL for ad hoc analyses and smaller datasets." Exploration has a human in the loop: an analyst sees an odd number, changes a filter and reruns, so a wrong definition costs one query. A KPI or a board deck runs on a schedule without anyone reading the SQL, so the same wrong definition repeats in every report until someone notices the trend is off. An automated action skips even that. Those three need a signature.
"Palantir-style ontologies are about actions." Correct. TopQuadrant's guide describes Palantir's model as object, link and action types: verbs as well as nouns, and who is permitted to trigger them. Action permissions check who may trigger "approve refund." They don't check what the refund rule's nouns mean. A rule keyed to "active customer" approves the wrong refunds if that definition is wrong, however tight the permission. So signed definitions sit underneath action permissions. One doesn't replace the other.
Write one card per term an agent is allowed to use. The values below are illustrative.
term: net_revenue
definition: >
sum(invoice_amount - credit_amount)
where invoice_status = 'paid'
and invoice_date between :start and :end
owner: <one named person>, Controller # never "Finance"
decided: 2026-10-05
source: authored # generated | authored
test:
question: "Net revenue for Q3 2026 (2026-07-01 to 2026-09-30)"
must_return: 18420000
must_refuse:
- "Net revenue by sales rep before the 2025 territory change"
- "Net revenue before 2023-01-01 (pre-migration billing)"
review_trigger:
- schema change to invoices or credits
- pricing or billing-terms change
The rule that makes the card work: a generated definition stays source: generated, owner: none and is excluded from agent answers until someone signs it. Generation drafts the card. A person turns it into a record.
Any ontology product should pass four checks before purchase:
Every signed card costs an owner's time. As an illustrative figure, 40 terms at 30 minutes each comes to 20 hours of a senior person's calendar before any re-signs. A small team where one analyst is the agreement doesn't need cards. That person's head is the ontology of record. A domain whose definitions change weekly will drown in re-signs. Those teams should keep agents in exploration mode and keep their output out of KPIs entirely.
The ontology worth budgeting for is the agreement, not the graph. When an executive asks for net revenue by sales rep before the 2025 territory change, the right answer is the first line under must_refuse, and the controller's name next to it.