Your finance report shows one revenue number, the sales dashboard shows another, and now an AI assistant has produced a third. A data warehouse and a semantic layer do different jobs, and the gap between them is where that third number comes from. The warehouse (or lakehouse) stores cleaned, connected data and runs queries on it. The semantic layer sits on top and defines what the data means: which metrics exist, how they’re calculated, how tables join and who may see what.

Semantic layer vs. data warehouse at a glance

What are metric definitions, and why do they matter?

A metric definition is the single agreed formula for a business number. Take net revenue: gross invoice amount, minus credit notes, excluding intercompany sales and test accounts, converted to euros at the monthly rate, recognised by invoice date. That’s five rules. If the sales dashboard, the finance report and an AI assistant each build them separately, you get three different numbers and a meeting to argue about them.

A semantic layer stores the definition once, in code, with an owner and version history. Typical elements are:

• Measures and metrics: sums, counts, ratios and derived metrics such as margin percentage or 90-day retention.

• Dimensions: the attributes you can group and filter by, such as date, region, product line or customer segment.

• Entities and relationships: how orders, customers and products join, including which joins are safe.

• Descriptions and synonyms: plain-language explanations, for example that “turnover” means net revenue, which also help AI models.

• Access rules: row- and column-level security that applies whichever tool queries the data.

Which semantic layer tools are common?

Open Semantic Interchange (OSI), an initiative Snowflake and partners launched in 2025, is working on a vendor-neutral format so definitions can move between these tools. Keep an eye on it, but plan around the tools you run today. For BI tool choices, see Power BI vs. Tableau vs. Fabric.

How does a semantic layer reduce wrong answers from AI?

Text-to-SQL, where an LLM writes SQL from a natural-language question, looks impressive in demos on a few clean tables. In a real warehouse with hundreds of tables, ambiguous column names and undocumented business rules, it fails in predictable ways:

• Wrong joins that multiply rows, for example joining orders to order lines and then summing order totals.

• Missing filters, such as including cancelled orders, test customers or intercompany sales.

• Different metric logic from finance, such as gross instead of net revenue.

• Wrong time logic, such as order date instead of invoice date, or calendar instead of fiscal year.

• Answers that look plausible, so errors are rarely caught by the person asking.

With a semantic layer, the assistant no longer writes the calculation. It maps the question to a governed metric, dimensions and filters, for example net_revenue by region for last fiscal quarter, and the semantic layer generates the SQL. The model’s job shrinks from writing correct SQL to choosing the right metric, which is a much easier task. Results match the dashboards, access rules still apply, and every answer can show which definition it used.

You can also expose a semantic layer to agents as a tool, for example through an MCP server, so every assistant in the company uses the same metrics.

What we see in delivery: definitions people can find

At a global consumer goods company, analysts and data developers depended on a handful of experts to learn which data existed and how to get access. We built a data and analytics portal on top of the company’s central data catalog, so users could browse data products, request access and get approvals in one place. Before writing code, we ran a three-day Lean Inception workshop to agree requirements, and later an Event Storming session to map the data request process across several services.

The lesson for semantic layers: a governed metric only helps if people and AI assistants can find it and know who owns it. Read more about what an enterprise data hub is.

How do you introduce a semantic layer?

1. Start with 10 to 30 metrics that leadership uses every week, and agree each definition with its business owner.

2. Model them on the existing warehouse or lakehouse. No data needs to move. A medallion architecture gold layer is a natural base.

3. Point dashboards at the semantic layer first, so numbers reconcile before AI uses them.

4. Add descriptions and synonyms, then connect an AI assistant and test it on 50 to 100 real business questions with known answers.

5. Extend domain by domain, and treat metric definitions as code with reviews and tests.

A first version for one domain typically takes 4 to 8 weeks when the underlying data is already modelled.

How RUBICON helps with semantic layers and AI-ready data

We build warehouses, lakehouses and semantic models, and connect them to BI tools and AI assistants so everyone works from the same numbers. Our data engineering and analytics and BI teams usually start with one domain and the metrics leadership reviews every week.

We’re about 55 people, 40+ engineers, a Databricks Partner and a Microsoft Solutions Partner for Cloud & AI Platforms. If you’re deciding where your metric definitions should live, our architects can look at your stack with you.

Frequently asked questions