What Is a Semantic Layer, and Why AI Analytics Needs One

Short answer: A semantic layer is a shared, written-down definition of your business metrics and how tables join. When an AI tool asks it for “revenue” instead of guessing at raw tables, it uses the same definition your dashboards use. Vendor benchmarks report large accuracy gains from this, though they are vendor benchmarks, so treat the exact figures with care.

Ask three colleagues what “active customer” means and you may get three answers. A person can usually work out which one you meant from context. An AI model cannot. It will pick one, write perfectly valid SQL, and give you a confident number that may not match anyone’s dashboard.

I wrote about that failure in why AI analysts fail on bad metric definitions. This post is the constructive half: what a semantic layer is and how to get the benefit without a giant project.

What is a semantic layer?

Think of it as a dictionary and a rulebook that sits between your raw tables and everyone who asks questions of them. It defines:

• Metrics: “Revenue = sum of paid order amounts, excluding refunds, in the reporting currency.”
• Dimensions: the ways you can slice them (country, product, month).
• Joins: which tables connect and how, so nobody has to rediscover them.
• Rules: filters that always apply, such as “exclude test accounts”.

Common descriptions, such as Knowi’s, say the semantic layer centralises business logic so that every downstream consumer queries the same definition. The consumers can be a BI tool, a spreadsheet, a notebook or an AI assistant.

You may already have one without the name. A Power BI model with well-named measures is a semantic layer. So is a set of governed views in a warehouse.

Why does it matter more with AI?

When a model writes SQL against bare tables, it has to guess three things: which table holds the fact you want, how to join it, and what your company means by the metric. Guessing wrong produces a query that runs fine and answers a different question.

A semantic layer removes the guessing. The model doesn’t compose raw joins and aggregations. It asks for “revenue by month” and the layer supplies the agreed calculation.

There is evidence for this. dbt Labs published a 2026 benchmark comparing a semantic layer with text-to-SQL, and other write-ups such as Atlan’s discuss “metric drift”, where the same word gets calculated differently in different places. A caution I would apply to all of these: the companies publishing them sell semantic layers or related tools. The direction of the result makes sense to me, but I would not quote any single percentage as a promise for your data.

What does a semantic layer look like in practice?

Tools differ, but the idea fits in a few lines. Here is a metric written in a generic, YAML-style form, for illustration only:

metric: revenue
description: Paid order value, net of refunds, in EUR.
calculation: SUM(orders.amount_eur) - SUM(refunds.amount_eur)
filters:
  - orders.status = 'paid'
  - customers.is_test = false
time_dimension: orders.order_date
dimensions: [customers.country, products.category]

Notice how much is decided: currency, refunds, test accounts, which date counts. Every one of those is a place where two analysts could otherwise disagree.

How do I start without buying anything?

You don’t need a platform on day one. A workable first version:

1. List your ten most-used metrics. Revenue, orders, active customers, churn, conversion, average order value, and so on.
2. Write one paragraph for each. Formula, filters, source table, owner, and a known gotcha.
3. Put the logic in one place. A view in the warehouse, a Power BI measure, or a documented SQL snippet. Not in twenty separate reports.
4. Give the AI the definitions. Include them in the context you provide, so it uses your wording and formulas rather than inventing its own. I cover the prompting side in prompting an LLM for SQL you can trust.
5. Test with known answers. Ask the AI questions whose answers you already know and compare.

If you use Power BI, model first, then calculation groups is the same discipline. A clean star schema is a semantic layer’s foundation.

What are the limits?

• It doesn’t fix bad data. If the source has duplicates, every definition inherits them.
• It needs an owner. Definitions drift when nobody is responsible for them.
• It can’t answer everything. Questions outside the defined metrics still fall back to raw SQL, where the old risks return. I look at how the tools cope in text-to-SQL tools compared.
• Governance takes real effort. Agreeing on a definition is a people problem more than a technical one.

My opinion: the definitions matter far more than the tool. A shared document that everyone respects beats a fancy platform that nobody maintains. If you are a team of one with three metrics, a note at the top of your SQL file is enough.

Sources: dbt Developer Blog: Semantic Layer vs. Text-to-SQL, 2026 Benchmark Update, Atlan: Text-to-SQL for Enterprise: Metric Drift and Context Layer, Knowi: Semantic Layer for AI. The YAML example is illustrative and not the syntax of any specific product.

Thinking by Anthony, written with Claude.

Part of: AI for Analysts