A semantic layer for AI: give the model your definitions, not just your tables

Point an assistant at a warehouse and ask for revenue last month. It finds orders.amount, sums it and gives you a figure. It doesn't know that finance excludes refunds, recognises annual plans monthly, reports in GBP, and stopped counting the reseller channel in March. None of that is in the schema. All of it is in someone's head, a dbt model or a LookML file.

The vendors building AI analytics say this outright. Snowflake: "Generic AI solutions often struggle with text-to-SQL conversions when given only a database schema", which is why Cortex Analyst reads semantic views (Snowflake docs). Microsoft: without a prepared semantic model, "Copilot can misinterpret the data and return generic or inaccurate results" (Power BI docs). dbt: assistants connected to its Semantic Layer through the dbt MCP server "use your governed metrics instead of guessing at raw tables" (dbt docs). Looker's Conversational Analytics goes furthest: it doesn't query your database directly at all, but selects fields and filters and lets Looker compose the query from LookML (Google Cloud docs).

The research points the same way, from an unexpected angle. A 2026 audit of two leading text-to-SQL benchmarks found annotation errors in 52.8% of BIRD Mini-Dev items and 62.8% of Spider 2.0-Snow items, many of them questions ambiguous enough to have more than one reasonable answer (Jin et al., January 2026). If the experts writing the answer key couldn't agree what a question meant, the model was never going to work it out from column names. Definitions have to be written down somewhere a model can read them.

A semantic layer for AI is the same thing as a semantic layer for people, with more attention paid to the words. The parts that matter:

An illustrative metric, not any one vendor's syntax:

metric: net_revenue_retention
description: >
  Recurring revenue this month from customers who were paying
  12 months ago, divided by their recurring revenue then.
  Includes expansion and contraction; excludes new customers.
synonyms: [NRR, net dollar retention, NDR]
grain: month
filters: exclude internal and test accounts
owner: finance-analytics

The description and synonyms lines are the ones teams skip and models need most. A human analyst asks what "NDR" means; a model maps it to whatever looks closest.

We'd almost always start with the layer you already maintain. Count's own experience converting customers' LookML and Snowflake models taught us that "no one really wants to maintain more than one semantic layer" (semantic interoperability), and an AI project is a poor reason to start a second.

Details from each vendor's documentation, checked 22 October 2026.

If you have nothing yet, a dbt Semantic Layer is the most portable choice because so many tools can read it, but a written glossary in a Claude project is a respectable start and takes an afternoon. Standards are moving too: the Open Semantic Interchange (OSI) specification aims to make models portable between tools, though as our post notes, adoption is early.

Using dbt as the example, because it's the most widely readable. Steps from dbt's and Anthropic's own docs:

1. Copy the MCP URL from dbt: Account settings → Access URLs → MCP Endpoint URL. The format is https://YOUR_DBT_HOST_URL/api/ai/v1/mcp (dbt remote MCP docs).
2. Add it in Claude under Customize → Connectors → + → Add custom connector, paste the URL and sign in through OAuth (public beta). On Team or Enterprise, an Owner adds it under Organization settings → Connectors first (Claude help centre).
3. Decide what it may do. With token auth, dbt's headers x-dbt-disable-toolsets and x-dbt-disable-tools narrow access, for example switching off the sql toolset so Claude can only query governed metrics. With OAuth, use Claude's own Search and tools menu to switch off tools you don't want.
4. Tell the project to prefer metrics. A few lines of instructions do most of the work:

For any number about our business, use the dbt Semantic Layer first
(list_metrics, then query_metrics). Quote the metric's description
before the value. If no metric fits, say so and ask before writing SQL.
Never answer a business number from general knowledge.

On Snowflake the equivalent is a Cortex Agent or Cortex Analyst tool over semantic views, exposed through Snowflake's MCP server. Snowflake recommends making the agent the only client-facing tool for governed questions, because direct SQL can bypass the agent's governance (Snowflake docs). More on each in dbt MCP and Snowflake MCP, and the whole stack in AI for data teams.

A semantic layer moves the guessing; it doesn't end it. Four gaps stay open.

• The model still chooses the metric. Ask "how are we doing on retention?" and it has to pick between gross revenue retention, net revenue retention and logo retention. Good synonyms and descriptions help. They don't decide for it.
• The definition can be wrong. A governed metric is consistently computed, which isn't the same as correct. If the layer counts trial accounts as customers, every AI answer will too, with total confidence.
• Questions fall off the edge. Ask about something the layer doesn't model and the assistant either writes raw SQL or, in Copilot for Power BI's case by Microsoft's own description, answers from general knowledge. Instruct it to say when it has left the governed metrics.
• The narrative isn't governed. The number can come from the layer while the sentence explaining it ("retention rose because of the pricing change") comes from nowhere.

This is why grounding and checking are different jobs. The semantic layer makes the number consistent; you still need to see which number it used and what the explanation rests on.

1. Did it use a governed metric? Look for the metric's name in the tool call. If the answer came from SQL the model wrote, treat it as unreviewed.
2. Is it the right metric? Read the description it used. NRR or GRR? Customer or revenue churn?
3. Check the filters it added. Governed metrics take filters at query time; a stray date or segment filter changes the answer without changing the definition.
4. Separate number from narrative. The value may be governed; the "because" usually isn't. Ask what data supports the explanation.
5. Run the same question phrased differently. If two phrasings hit two metrics, add a synonym to the layer.

To do this claim by claim, connect Count to Claude or ChatGPT and ask it to audit the answer. Each claim is labelled as a citation, an assumption, model knowledge or a hallucination, and the reasoning chain shows whether it rests on a query, a definition or nothing at all. For checking AI answers more generally, see how to check AI answers.

What is a semantic layer?

Does AI need a semantic layer?

Can Claude use the dbt Semantic Layer?

Is a semantic layer the same as a data catalog?