Build your semantic layer: one definition of every metric
Revenue means one thing in the dashboard, another in the notebook and a third to the AI assistant. Data Workers reconciles the definitions you already have into one governed set that BI, people and agents all read, with a named owner for every metric and every change.
Before and after
| Today | With Data Workers |
|---|---|
| Revenue defined three ways in dbt, the BI tool and a notebook | One governed definition with a named owner |
| A semantic layer project that stalls at "which version is right" | Conflicts surfaced, ranked and settled by the owner |
| AI assistants that write raw SQL and guess | Agents that answer through the governed metric first |
| A metric change that breaks dashboards nobody listed | Every consumer checked before the change ships |
| Numbers nobody can trace | Each answer with its source and its definition |
Step 2 of 4 on the AI maturity curve for data teams. Once agents can work inside your warehouse, the next question is which numbers they are allowed to quote. A semantic layer (also called a metrics layer) is where governed metrics live, and agents are only as trustworthy as the definitions they read. If you are weighing the build, what a semantic layer is and a six-step build guide cover the basics; this page is about running it as an operating model.
How it works
1. Find every definition
The Data Context & Catalog agent reads your dbt models, BI tools and notebooks and lists every definition of each metric with list_semantic_definitions. Bring the definitions you already have, such as dbt MetricFlow; nothing is rewritten into a new tool. Where two definitions disagree, it says so and points to the authoritative one with get_authoritative_source.
2. Settle one governed definition
For each conflict, the agent drafts a single definition with define_business_rule and sends it to the metric owner. Nothing becomes governed until a named approver signs off, and every change keeps a signed receipt.
3. Serve it to BI, people and agents
Dashboards, analysts and AI agents resolve the metric through resolve_metric before any raw SQL is written, so "revenue" means the same thing every time. When someone corrects an answer, the correction is remembered with correct_response. The same governed set powers asking questions in plain language.
The impact metrics we move
- •Conflicting definition reconciled: from about a month to 8 h
- •Metric change checked against every consumer: from about a week to 1 h
- •Answer with its source: from about a day to seconds
Where teams start
- •dbt Semantic Layer or MetricFlow. Import the metrics you have and check them against the tables underneath. See the dbt guide.
- •Cube, AtScale or a BI-tool model. One governed view across the definitions you already run, as in this note on Cube, AtScale and MetricFlow.
- •The five metrics the board asks about. Revenue, active customers, churn, margin and pipeline, each with one owner.
- •No semantic layer yet. Start from the definitions buried in dashboards and SQL, and settle them one metric at a time.
- •An AI assistant that disagrees with the dashboard. Point it at the governed set before you widen access.
What powers it
The Data Context Wizard keeps the shared understanding of your estate: what each table means, who owns it and which source is the trusted one. The Data-Agents Swarm does the work, with the Data Context & Catalog agent reading and proposing definitions and the Data Science & Insights agent answering questions from them. The Autonomous Data-Conductor routes each proposal to the right owner, Autopilot Routines flag documentation gaps and stale definitions as they appear, and Autopilot Standards can hold each domain to a rule such as "every metric has an owner". Spellbook Data Catalog keeps a page per metric and table, in preview. See how it plays out in governed product metrics and AI-ready data teams.
Previous step: Bring agents into your data lake or warehouse. Next step: Make your data catalog agentic.
The climb: from assisted to autonomous to agentic
Every transformation runs on the same ladder from our thesis. Today agents watch (L0), suggest (L1) and act after approval (L2), and each domain's owner decides how far to go. L3 and L4 are where a domain can go on its own review record, not something running now.
The pilot
- •Scope. The governed definitions for one domain, such as revenue and customer metrics, and one consumer: a BI tool or a chat assistant.
- •First week. Agents start by watching and suggesting: they list every definition and show the conflicts, with receipts.
- •By week two. The first governed definitions are approved by their owners and served to the consumer you chose; anything sensitive stays with a named approver.
- •At day 30. We review the impact metrics against your baseline:
- •Conflicting definition reconciled: from about a month to 8 h
- •Metric change checked against every consumer: from about a week to 1 h
- •Answer with its source: from about a day to seconds
- •Cost. Start with a pilot ($7,500 one-time, credited in full against the first year). Scale is from $1,000 a month and Enterprise from $3,000 a month, billed annually, with unlimited seats, no usage meter and no markup on model spend. See pricing.
FAQ
Do we have to replace our semantic layer? No. Agents read the definitions you already keep, for example in dbt MetricFlow, and flag where they disagree.
Who decides what a metric means? The named owner of that metric. Agents propose; people approve.
What if the agent is wrong? Answers show their source, SQL is checked against the warehouse before it runs, and corrections people make are remembered.
What if the data to answer is missing? The agent says so instead of guessing.
Which stacks does this work with? dbt, common BI tools and the chat assistants your teams use, through 50+ connectors.