In this article: what we mean by "semantic" · why natural-language-to- is really a context problem · the times we have built this before · the ontologies that proposed all this for in 2001 · what changed in the last two years · a standard for the definition itself · the platinum layer and who owns it · what belongs in the layer · saying what you mean.
A few months ago I watched an agent answer a question nobody had quite asked it. The was reasonable ("what was net revenue last quarter?") and the agent, pointed at an ordinary warehouse, wrote ordinary SQL and returned a number to two decimal places with an air of total confidence. The number was wrong. It summed gross sales, counted a block of test transactions someone had loaded in March, and ignored the refunds table because nothing in the schema told it refunds were part of the story. To the person reading the answer, none of that was visible. They saw a figure, formatted nicely, delivered in a second.
That gap, between a number that looks like an answer and a number that is one, is what the closes. Over the last two years its job has changed from a reporting convenience into the interface an agent reads. I argued in an earlier article that data modelling matters more, not less, once software starts consuming your data directly. This is the other half of that argument: the model has to say what it means, somewhere software can read it, or the software will decide for itself.
What we mean by "semantic"
"Semantic" sounds more technical than it is. It comes from meaning (semantics is the study of what things mean) and a semantic layer is the place where the meaning of your data is written down, kept apart from the question of how the data is physically stored.
It helps to see one figure described three ways.
The middle column is what a database hands you: tables, a join, a filter. The right column is lineage, the trail back to source systems that lets you defend the number when someone disputes it. The left column is the semantic view, and it's the one organisations most often never write down, because for decades there was always a person who simply knew. Ask the analyst who built the report whether revenue includes refunds and they'll tell you, possibly with a small sigh. The semantic layer is what you get when you take that sigh and put it somewhere a machine can read.
Natural-language-to-SQL is a context problem, not a model problem
There's a tempting assumption that natural-language analytics is a hard AI problem waiting on a better model. It mostly isn't. Turning an English question into SQL is something current models do well, and the published have been climbing for years. What they keep showing is that the limiting factor is rarely the model's command of SQL syntax. It's whether the model has been told what the words mean.
Vendor write-ups put the lift at something like 40% to over 80% accuracy on business questions when a model is grounded in a governed semantic layer rather than raw schema. , for instance, reports reaching roughly 85–90% accuracy when it reads a semantic view's metadata . I'd treat the exact figures with caution (they come from people selling semantic layers) but the direction matches both the academic text-to-SQL benchmarks and what I see in delivery. A human analyst writing the same query carries a stack of unwritten knowledge: which accounts are test accounts, that the German subsidiary's numbers only became trustworthy after a 2022 migration, that "active" quietly excludes anyone who churned but hasn't been flagged yet. None of that is in the schema. A model handed the schema alone has to guess it, and a guess delivered in fluent SQL to two decimal places is the most dangerous kind.
The consumer changed
A dashboard is wired to its definitions once, by someone who'll notice next Monday if a number looks wrong. An agent rebuilds the definition on every question, from whatever context it can reach, and has no Monday-morning instinct that something is off.
We have built this before
The semantic layer is not new, even if the current excitement sometimes implies the industry just invented the idea of shared definitions. shipped its "universe" in 1990: a governed map of business terms over a relational database, so a report writer could drag Revenue by Region onto a page without writing a join . cubes did a version of the same thing. 's later made the idea feel modern again by treating the semantic model as version-controlled code .
If you've built in or , you've worked with a semantic layer whether or not anyone called it that. A Qlik app or a Power model is a small governed database in its own right (the data is loaded, the relationships are resolved, the measures are defined once) and on top of that prepared model a business user can build their own chart without re-deriving "margin" from scratch. That was the real promise of in the 2010s, and where it worked, it worked because the hard modelling was already done underneath. Where the model was thin, self-service produced a hundred subtly different versions of the same . That's the failure everyone remembers and few blame on the right cause.
The detour we took in between still irritates me. For a good decade, the semantic model inside a BI tool was treated by a lot of data teams as a lock-in nuisance: proprietary, in the way, something to be flattened into a flat extract so the "real" work could happen elsewhere. "Just give me the raw tables, I'll model it myself" was a point of pride. So we threw away governed definitions to avoid vendor lock-in, re-implemented them inconsistently downstream, and are now spending real money rebuilding the same capability as warehouse-native infrastructure. The idea was right in 1990. We just kept mislaying it.
Picture a quarterly review where two teams arrive with numbers for the same headline figure and the numbers don't agree. Half an hour goes by before anyone works out why: one team's definition of counts a category of held-away accounts and the other's doesn't, and the rule for which is correct was never written down. It lived in the working memory of whoever built the first report. That rule is exactly what a semantic layer exists to hold, and exactly what an agent will fill in with a confident guess if you leave the space empty.
Ontologies, and the agents that didn't come
There's an older and more ambitious version of this story, and it aimed straight at agents. In 1993 Tom Gruber gave the definition the field still uses: an is "an explicit specification of a conceptualization" , a written-down model of the things in a domain and how they relate. Where a semantic layer says what net revenue means, an ontology says what a customer is, what a contract is, that a contract belongs to a customer and contains line items. It describes the meaning, not the tables.
In May 2001, Tim Berners-Lee, James Hendler and Ora Lassila proposed building that meaning into the web itself. Their Scientific American article opened with software agents that arrange a course of medical appointments by reading machine-readable data off the web and negotiating across calendars, no human in the loop . The plumbing was RDF, which records facts as subject-predicate-object triples, and OWL, which let you declare the ontology those triples lived inside. The whole stack existed so software could act on meaning instead of guessing at it, and the consumer they kept naming was the "intelligent agent".
The agents didn't come. RDF and OWL took hold in pockets, life sciences, cultural heritage, parts of search, and stalled everywhere else. The reasons are worth keeping, because they are the same reasons a semantic layer succeeds or fails inside one company. Marking up meaning was extra work with no near-term payoff, so most people didn't bother. Where there was an incentive it ran backwards: Cory Doctorow's 2001 "Metacrap" essay pointed out that people will cheerfully supply false metadata to game whoever is reading it . And the formal layers were genuinely hard. Getting an OWL dialect right was a job for a logician, which is a poor fit for a format meant to spread by the million. Years in, Hendler's own summary of the problem was a question: where are all the intelligent agents?
What changed is not that we finally got the ontologies right. It's that the agent arrived, and it turned out not to need the formal stack. A language model absorbs the ambiguity that OWL tried to nail down with axioms: tell it in one sentence that test accounts are excluded from revenue and it will mostly comply, where the old vision wanted that encoded as a constraint a reasoner could enforce. The layer that works now reads more like documentation a machine happens to consume than an ontology a machine can reason over. The meaning still has to be written down. It just no longer has to be written in predicate logic.
What changed
Two things changed, and only one of them is obvious.
The obvious one is the consumer. A dashboard's definitions are set once and sit still; an agent reconstructs them every time it answers, and it answers on your behalf, fast, without a person reading over its shoulder. The associative work that a tool like Qlik does to keep business logic intact across a chain of clicks is the same work an agent now needs done across a chain of reasoning steps, except the agent will happily proceed without it.
A dashboard's definitions are set once and sit still; an agent reconstructs them every time it answers.
The less obvious change is the one I think matters more: the semantic layer is becoming a first-class, governed object inside the data platform itself, instead of something trapped in a BI tool's proprietary model. The major platforms have arrived at this from different directions and landed in nearly the same place.
Snowflake's Cortex Analyst reads a semantic model written in YAML; then promoted those definitions to governed, SQL-native objects, and Semantic View Autopilot reached general availability on 3 February 2026, drafting a first model by inferring relationships and suggesting metrics from existing query history and BI assets . built business semantics into as (define a metric once, query it across any dimension at runtime) and the same definition feeds for natural-language questions and agents . Zalando grounded Genie in those metric views to make natural-language queries reliable across dashboards and AI, which is roughly the whole argument of this article delivered as a case study . keeps the definition as version-controlled code beside the transformations through , exposed over an app can call . takes the headless route: one definition, several query interfaces, an open-source core and a dedicated AI endpoint, queryable by a dashboard, an embedded app and an agent at once .
Lay these side by side and the disagreement isn't about what a semantic layer should contain. It's about where it should live: in the warehouse, beside the transformations, or as an independent layer any platform can call. The shape is the same in every case.
One definition, one blast radius
Putting meaning in one place is the right move, and it also means a single wrong definition now reaches every dashboard, app and agent at once. The layer is worth testing harder than you ever tested the dashboards downstream of it.
The newest move tries to build the layer for you. At its Data and AI Summit in June 2026, Databricks introduced the , which it calls a continuously learned enterprise context layer: it reads your dashboards, queries, pipelines and documents and assembles a graph of how the business actually uses its data, ranking competing definitions by a PageRank-style measure of authority, who created one, how widely it's used, whether it's tied to certified data . It sits on top of the metrics, glossary and domains you still define by hand in Unity Catalog rather than replacing them. Twenty-five years after the bet everything on ontologies and lost, the word is back, in the product name and at the centre of the data platform, learned from usage this time rather than hand-authored in OWL .
A standard for the definition itself
If the definition can live in several places, the next question is whether it can move between them. That's the bet behind the . Convened by Snowflake in September 2025, OSI is an open, Apache-2.0-licensed, YAML-based specification for semantic metadata: a common format for metrics, dimensions and definitions (with per-dialect SQL expressions), so they can be exchanged across tools instead of re-implemented in each .
The membership is the part worth reading closely. Databricks was absent at the start and joined only at the v1.0 spec release. , which had been promoting its own Semantic Modeling Language as a rival, folded into the initiative by January. When companies that compete hard, and that each ship their own semantic-layer product, agree on a shared format for the one artifact that encodes a business's meaning, that's a stronger signal than any single launch.
| Members | Working groups | Spec |
|---|---|---|
| 50+ | 4 | v1.0 |
| Snowflake-convened | metrics, composability, catalog, ontology | GitHub, Jan 27 2026 |
Open Semantic Interchange (open-semantic-interchange.org); v1.0 spec finalized January 27, 2026 [R1].
Meaning gets portable
If a metric defined in dbt can be read by a Snowflake-native agent without anyone rewriting it, the question of where the layer lives stops being a bet you have to win up front. OSI is early and the spec is young, but the direction is set.
It's also why a roadmap line worth watching is Qlik's. Qlik has signalled that a shared semantic layer is coming to , without publishing much detail yet. Since Qlik joined OSI in January, the reasonable bet (and it is a bet, not a confirmed spec) is that this layer speaks the shared format rather than becoming another island, which is the whole point of joining a vendor-neutral standard. A vendor whose engine already holds governed definitions has an obvious interest in exposing them in a form other tools can read, rather than keeping them locked behind its own front end.
There's a more radical version of the same instinct, and it's interesting precisely because it points somewhere OSI doesn't. has proposed , a restricted SQL dialect you write against business concepts directly: SELECT publisher, total_records FROM ad_bids_metrics, where the engine expands the measures and inherits the security policy from the metrics view rather than making you re-derive either. The stated ambition goes further than a file format: that OLAP engines should one day treat MEASURE as a first-class SQL keyword, so a metrics view becomes a native database object and a plain SQL client could query governed metrics with nothing in between . Whether that particular future arrives or not, the instinct is the same as OSI's pulled one notch tighter: push the meaning down, closer to the data, in a shape that travels.
This is why I won't tell you where your semantic layer should live. I don't think the location is the decision that matters, and the industry is busy making it matter less. If the definition is portable, you can keep it beside your dbt models today and serve it to a warehouse-native agent tomorrow without rewriting the meaning. The decision that matters is whether the definition exists at all: written down once, in a form software can read.
The platinum layer, and who owns it
The layer has a natural home in the stack. Most lakehouses stage data in the tiers of the : bronze for raw landed data, silver for cleaned and conformed tables, gold for the curated, business-ready models that feed reporting . The pattern officially stops at gold. "Platinum" is the informal name teams reach for when they want a tier above it, and the semantic layer is the right thing to put there. It is thin, it sits on top of the gold tables, and it does more per line than anything beneath it: a small set of metric and entity definitions that fix what every number downstream is allowed to mean.
Two questions follow from putting it there, and the second is the one most teams underweight. The first is where it physically lives: warehouse-native, beside the transformations, or as an independent layer any tool can call. I argued above that portability is making that choice less binding than it looks. The harder question is who owns it. The platinum layer is where your business's meaning is written down in one place, which makes it the most valuable thing in the stack to control and the most consequential to hand to a vendor.
Palantir understood this earliest and built a company on it. Its central object is the Ontology: an operational layer that maps raw data to the objects, properties, links and actions of the real business, with everything else in hanging off it . Own that and you own the interpretation of the customer's world. The platform vendors are now arriving at the same ground from the other side. Databricks' Genie Ontology and Unity Catalog Semantics, Snowflake's semantic views, each want the layer that holds your meaning to live inside their platform . None of it is sinister. It is where the value landed once agents needed context.
This is why a portable format matters, and why I would treat OSI as a requirement rather than a nicety. Refusing a platform's semantic layer is not the hedge, since the platforms are where the agents and the governance already sit. The hedge is to keep the definitions in an open format you could carry out, so the platinum layer stays yours even while a vendor hosts it. Decide what your words mean, write them down once, and own the file.
Who owns the meaning
The platinum layer holds your business's definitions in one place, which makes it the most strategic thing in the stack to hand a vendor. Palantir built a company on owning it. Keep the definitions portable enough to walk out with, and the layer stays yours even when a platform hosts it.
What belongs in the layer
I wrote a fuller checklist for making a data model agent-usable in the earlier piece, so I won't repeat it. The semantic layer is the narrower thing living inside that: the part that records meaning, not just structure. At a minimum it carries metrics, each defined once (net revenue, active customer, AUM), as the calculation itself rather than a description of one. It carries dimensions and the grain they sit at, stated in words, so "monthly" and "per transaction" can't be silently swapped. The layer also carries synonyms, because the business says turnover, sales and top line and means a single thing. It carries descriptions written as documentation a machine will consume, because now one does. And it carries security expressed at the layer, so what an agent can see is governed by the model and not by hoping the prompt holds.
The part most teams skip is example questions and the SQL that answers them. That's doing more work than it looks. Databricks' own guidance for its natural-language interface is blunt about it: encode business logic as SQL expressions and worked examples, and fall back to plain-text instructions only when you have to, because structured definitions are more reliable than prose . Worked examples are how you teach the layer to handle the ambiguous questions a real business asks: the ones where the right join isn't obvious and a model left to itself will pick the join that happens to return a number.
Say what you mean
The semantic layer used to be a convenience for the people building dashboards. It's becoming the contract an agent reads before it answers on your behalf, and the stakes are different because the agent doesn't hesitate. Point a capable model at a warehouse with no semantic layer and it won't refuse the question. It will improvise: a definition of revenue, a guess about which accounts count, a clean figure to two decimal places. It will improvise differently next time, and no one in the meeting will see the seam.
Where that boundary finally settles, between the warehouse, the semantic layer, and whatever we end up calling the thing an agent reads, I don't know, and I doubt it's the fight worth having. The vendors will keep moving the layer around the stack. What they can't do for you is the part that actually decides the answer: sitting down, settling what your words mean, and writing it where the software can find it.
Final thought
They'll just notice, the first time they point an agent at the warehouse, that it already knows what "active customer" means, because someone, finally, told it.
The Semantic Layer Becomes the Agent Interface · June 2026 · Data. Accuracy-lift figures are vendor-reported and treated as indicative, not audited; the assets-under-management example is illustrative, not drawn from a specific engagement. Genie Ontology and several Unity Catalog Semantics features were in preview at the June 2026 Data and AI Summit. Full source records are in the References section above.
References17
- 1Snowflake, "Open Semantic Interchange (OSI) Specification Finalized" (v1.0 finalized January 27, 2026; Apache-2.0, YAML; 50+ member organizations) and the OSI project site and GitHub repository. snowflake.com ↗ · open-semantic-interchange.org ↗ · github.com ↗
- 2Snowflake, "Snowflake Delivers Semantic View Autopilot as the Foundation for Trusted, Scalable Enterprise-Ready AI" (Semantic View Autopilot GA February 3, 2026; Cortex Analyst reads semantic-view metadata). snowflake.com ↗
- 3Databricks, "Announcing General Availability and Open Sourcing of Unity Catalog Business Semantics" (metric views; define once, query across dimensions; guidance to encode logic as SQL expressions and worked examples). databricks.com ↗
- 4Databricks, "How Zalando built a unified data foundation for AI and analytics" (Genie grounded in Unity Catalog metric views). databricks.com ↗
- 5dbt Labs, "About MetricFlow" / dbt Semantic Layer documentation. docs.getdbt.com ↗ Accessed 2026-06-13
- 6Cube, semantic layer and AI documentation. cube.dev ↗ Accessed 2026-06-13
- 7Rill, "Introducing Metrics SQL: A SQL-based semantic layer for humans and agents" (Metrics SQL; the `MEASURE`-as-keyword ambition). rilldata.com ↗
- 8SAP BusinessObjects, the "universe" semantic layer (introduced 1990). en.wikipedia.org ↗ Accessed 2026-06-13
- 9Google Looker, "What is LookML?" (the semantic model as version-controlled code). cloud.google.com ↗ Accessed 2026-06-13
- 10Thomas R. Gruber, "A Translation Approach to Portable Ontology Specifications", Knowledge Acquisition 5(2): 199–220, 1993 (the definition of an ontology as "an explicit specification of a conceptualization"). doi.org ↗
- 11Tim Berners-Lee, James Hendler and Ora Lassila, "The Semantic Web", Scientific American, May 2001 (the original vision of machine-readable meaning consumed by software agents; the appointment-scheduling agent scenario; RDF and OWL). scientificamerican.com ↗
- 12"Semantic Web and Software Agents: A Forgotten Wave of Artificial Intelligence?", arXiv:2503.20793, 2025 (the agent-centred Semantic Web vision and why it stalled; Hendler's "where are all the intelligent agents?"). arxiv.org ↗
- 13Sinclair Target, "Whatever Happened to the Semantic Web?", Two-Bit History, 27 May 2018 (adoption failure; incentives; Cory Doctorow's 2001 "Metacrap"). twobithistory.org ↗
- 14Databricks, "What's new with Unity Catalog at Data + AI Summit 2026" (the Genie Ontology, a continuously learned enterprise context layer; Unity Catalog Semantics: Glossary, Domains, Metrics). databricks.com ↗ Accessed 2026-06-20
- 15Anirban Ghoshal, "From RAG to ontology: Databricks bets on context as the key to trusted AI agents", InfoWorld, June 2026 (Genie Ontology in preview; PageRank-inspired ranking of authoritative business definitions). infoworld.com ↗ Accessed 2026-06-20
- 16Databricks / Microsoft Learn, "What is the medallion lakehouse architecture?" (bronze / silver / gold quality tiers). learn.microsoft.com ↗ Accessed 2026-06-20
- 17Palantir, "Ontology overview", Palantir Foundry documentation (the Ontology as Palantir's operational layer mapping data to business objects, properties, links and actions). palantir.com ↗ Accessed 2026-06-20