Give a powerful AI model access to your data warehouse and ask a simple business question. Very often the answer is confidently wrong: it picks the wrong table, forgets to exclude refunds, or uses calendar months when finance uses fiscal ones. The model is not the problem. It simply does not know your business definitions. In 2026 the fix has a familiar name, the semantic layer, and every major data platform is racing to offer one.
Why AI gets business questions wrong
Take "What was revenue last month?" An AI working straight from tables has to make several decisions that are not in the data itself:
- Which table?
orders,invoicesorpayments? Each gives a different number.- Which amounts?
- Gross or net of VAT? Including refunds, discounts and cancelled orders?
- Which month?
- Calendar month, fiscal month, or the last 30 days?
- Which currency?
- Converted at today's rate or the rate on the day of the sale?
A semantic layer answers those questions once, in code, and every tool that asks for "revenue" gets the agreed answer.
Model with raw tables onlyModel with business context
Snowflake's figures from Summit 2026 for structured business questions. Results vary by data and question; the direction is consistent across vendors.
What a semantic layer contains
- Metric
- A named, agreed calculation:
net_revenue = SUM(amount) - SUM(refunds), with filters such as "exclude test orders". - Dimension
- The ways you slice a metric: region, product, customer segment, fiscal month.
- Relationships
- How tables join, so the agent never has to guess the join keys.
- Descriptions
- Plain-English explanations of each metric and column. AI models read these.
- Time logic
- Fiscal calendars, rolling windows, period-over-period comparisons.
A worked example
Here is the same metric defined in two popular formats. The idea is identical: a measure, how to aggregate it, and the dimensions it can be grouped by.
semantic_models:
- name: orders
model: ref('fct_orders')
defaults:
agg_time_dimension: order_date
entities:
- name: order_id
type: primary
- name: customer_id
type: foreign
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: region
type: categorical
measures:
- name: net_revenue
description: "Order value excluding VAT, minus refunds. Test orders excluded."
agg: sum
expr: amount_ex_vat - refund_amount
metrics:
- name: net_revenue
label: Net revenue
type: simple
type_params:
measure: net_revenueversion: 1.1
source: analytics.fct_orders
filter: is_test_order = false
dimensions:
- name: order_date
expr: order_date
- name: region
expr: region
measures:
- name: net_revenue
expr: SUM(amount_ex_vat - refund_amount)
- name: net_revenue_28d # rolling window measure
expr: SUM(amount_ex_vat - refund_amount)
window:
- order: order_date
range: trailing 28 day
semiadditive: lastOnce defined, an agent or a dashboard asks for net_revenue by region and the layer writes the correct SQL. Nobody, human or machine, has to remember to subtract refunds.
The options in 2026
dbt semantic layer
Platform-neutral- Lives in
- your dbt project
- Engine
- MetricFlow, open source
- Works across warehouses
- Version-controlled with your models
- Needs a dbt setup to serve queries
Best if you already use dbt and want portability.
Databricks metric views
In the lakehouse- Lives in
- Unity Catalog
- Used by
- Genie, dashboards, SQL
- Window measures for rolling metrics
- Governed with your data
- Databricks only
Best if Databricks is your main platform.
Snowflake semantic views
In the warehouse- Lives in
- Horizon Catalog
- Used by
- CoWork, CoCo, Cortex Sense
- Autopilot can draft and refine definitions
- Feeds Snowflake's agents directly
- Snowflake only
Best if Snowflake is your main platform.
How to start
- 1
Pick ten metrics that matter
Revenue, orders, active customers, churn: the numbers leadership asks about every week. Agree each definition in writing with its owner.
- 2
Clean the models underneath
A semantic layer on messy tables just spreads the mess. Build tested fact and dimension tables first.
- 3
Write descriptions for humans and machines
One or two sentences per metric and column. AI models use them to choose correctly.
- 4
Define the layer in code
Use dbt, metric views or semantic views, and keep it in version control with reviews.
- 5
Test with real questions
Ask your AI assistant 20 questions with known answers, before and after. Track the accuracy over time.
- 6
Expand gradually
Add metrics as people ask for them, not all at once.
Check your understanding
1/3Why do AI models often get business metrics wrong when given raw tables?
The SQL is usually fine; the business logic is what's missing.
2/3What does a semantic layer store?
It is the single place where definitions live, used by every tool.
3/3What is the Open Semantic Interchange for?
OSI aims to make metric definitions portable across vendors.
You got 0 out of 3.
The foundations matter: start with Star schema data modelling and your first dbt project, then see how the platforms compare in Snowflake vs Databricks for AI agents.
Sources: dbt semantic layer and MetricFlow documentation; Databricks metric views documentation; Snowflake Summit 2026 announcements (semantic views, Cortex Sense, OSI). Accuracy figures are vendor results; measure them on your own data.
Alessandro Ecclesie AgazziWritten by Alessandro Ecclesie Agazzi, analytics engineer in London. Updated 28 October 2026. About me