# Semantic Layers for AI: dbt, Snowflake Semantic Views and LookML

Canonical URL: https://www.martechdevs.com/blog/semantic-layer-ai

By [Jafrin Akter Alo](https://www.martechdevs.com/authors/jafrin-akter-alo)

Data Engineer and Co-founder, martechdevs

Published: 2026-07-24

Last updated: 2026-10-13

An AI analyst can write valid SQL and still answer the wrong business question. It can sum recurring revenue across daily snapshots, count people when you meant accounts or use today's customer segment to explain last year's performance. A semantic layer makes those choices explicit and reusable, provided the AI actually uses the governed definitions.

For a small data team, the aim is not to model every concept in the company. Start with the metrics that drive decisions, define their populations and aggregation rules, and expose them through a query path you can inspect.

dbt Semantic Layer, Snowflake semantic views and LookML can each help. The best fit depends on where your trusted models live and how people and agents will consume them.

## A semantic layer connects a business question to a calculation

A semantic layer describes business entities, metrics, dimensions and relationships above the physical tables. It gives “monthly recurring revenue by plan” a defined meaning instead of asking every dashboard author or AI agent to reconstruct it.

The useful definition includes more than a formula. It should answer:

- What is being counted or valued?
- At what grain does the source store it?
- Which records qualify, and which are excluded?
- Which date, timezone and currency rules apply?
- Which dimensions can safely divide the result?
- Can values be summed across time, entities or both?
- Who owns the meaning, and how is a change released?

Documentation can explain these choices. A semantic query engine can also use supported definitions to construct the calculation. Those are related capabilities, but they are not identical.

An AI with a glossary and unrestricted SQL access can still ignore the glossary. An agent calling a metric query interface has a more constrained calculation path, but can still select the wrong metric, filter or time window. Test both the definition and the interpretation.

## Define several precise metrics instead of one vague revenue field

“Define revenue once” is good advice only if it means giving each concept one maintained definition. It should not mean forcing bookings, invoices, collected cash and recurring revenue into the same number.

A founder asking whether the business can afford another hire may need collected cash and a cash forecast. A growth manager comparing acquisition cohorts may need a defined recurring-revenue measure. A finance report may use a separate recognition policy. Agree those requirements with the relevant owner.

Give each concept a clear name and explanation. A broad synonym such as “revenue” should trigger clarification when the available metrics represent materially different things.

For a first implementation, choose three to five decision-critical metrics. For example: qualified pipeline created, new paying workspaces, end-of-day recurring revenue and activation rate. Each needs a known population and date basis. The number of metrics in the catalogue is not the success measure.

## A worked example: recurring revenue is not additive across days

The following fictional dataset has one row per workspace per UTC snapshot date. The monthly recurring revenue amounts have already been normalised under an agreed business definition. This example isolates snapshot aggregation; it does not prescribe how your finance team should define recurring revenue.

```csv
snapshot_date,workspace_id,plan,mrr_usd
2026-10-11,A,Starter,100
2026-10-11,B,Team,200
2026-10-12,A,Starter,120
2026-10-12,B,Team,240
```

End-of-day MRR is $300 on 11 October and $360 on 12 October. Summing all four rows produces $660. That is a valid sum of the column, but it is not the closing MRR for the period.

The increase is $60, or 20% relative to $300. It is not $660 of new recurring revenue, and the dataset cannot tell you how much cash arrived in the bank.

The calculation is additive across workspaces at one snapshot. It is not additive across snapshot dates. That distinction belongs in the model and the query contract, not only in someone's memory.

Here is an original, vendor-neutral planning contract:

```yaml
metric: mrr_usd_eod
owner_role: finance_lead
version: 1
source_model: reporting.workspace_daily
source_grain:
  - snapshot_date
  - workspace_id
value_column: mrr_usd
aggregation: Sum across workspaces at one complete snapshot date
time_behavior: Never sum daily snapshots into period revenue
reporting_timezone: UTC
currency: USD
period_default: Ask whether closing MRR or average daily MRR is wanted
dimensions:
  plan: Plan recorded on the selected snapshot date
missing_snapshot: Mark unavailable and investigate completeness
not_equivalent_to:
  - Collected cash
  - Invoiced amount
  - Recognized revenue
```

This is a design record, not importable dbt, Snowflake or LookML syntax. Translate it into the constructs supported by your chosen implementation, and test the resulting query behaviour.

A reference query against the fixture is deliberately simple:

```sql
SELECT SUM(mrr_usd) AS closing_mrr_usd
FROM workspace_daily
WHERE snapshot_date = '2026-10-12';
```

It returns $360 only because the selected snapshot is complete and the grain is correct. If workspace B's 12 October row is missing, the query returns $120. That does not prove B churned.

Using each workspace's most recent row would instead combine A's $120 with B's stale $200, producing $320. That silently mixes dates. Decide how missing snapshots are represented and validate completeness before presenting a total.

## dbt Semantic Layer: keep metric definitions with the data models

The [dbt Semantic Layer](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl), powered by MetricFlow, defines metrics above dbt models and makes them available to downstream consumers. It is attractive when dbt already owns the modelling workflow and several tools need the same definitions.

[MetricFlow's join logic](https://docs.getdbt.com/docs/build/join-logic) uses declared entities to find valid paths and avoid unsupported fanout or chasm joins. Those declarations still need to match the data. Calling a duplicate identifier “primary” does not repair the source model.

For the MRR example, first build and test the daily workspace model. Then express its aggregation and time behaviour using the supported semantic constructs. If a consumer cannot safely request a closing snapshot, expose a constrained model or query path that can.

Check the [current semantic-model specification](https://docs.getdbt.com/docs/build/semantic-models) before copying YAML from an old tutorial. The documentation for dbt v1.12 and later places semantic configuration within model definitions; legacy examples use a different layout. Mixing the two can leave a project with definitions that are not recognised or do not mean what the author intended.

Also distinguish the engine from the hosted service. [MetricFlow can run locally with self-hosted dbt](https://docs.getdbt.com/docs/build/metricflow-commands). The managed downstream Semantic Layer service has its own account and setup requirements. “We use dbt” is not enough to establish that a particular hosted integration is enabled.

This path fits a team that wants metric logic reviewed alongside model changes. It is less attractive if nobody can maintain the dbt project and the existing trusted definitions already live elsewhere.

## Snowflake semantic views: keep business meaning in the warehouse

[Snowflake semantic views](https://docs.snowflake.com/en/user-guide/views-semantic/overview) are schema-level metadata objects describing logical tables, relationships, dimensions, facts and metrics. They can be queried through SQL and used by Cortex analysis tools.

They fit a Snowflake-centred team that wants business definitions close to its warehouse objects and available to native analysis workflows.

The [semantic-view SQL documentation](https://docs.snowflake.com/en/user-guide/views-semantic/sql) includes non-additive dimensions for metrics that should not be aggregated across certain dimensions. That is relevant to a snapshot metric like MRR. Use the supported time and aggregation behaviour deliberately, and test monthly, daily and as-of questions separately.

There is a second distinction to preserve: Snowflake's overview describes Cortex Agents reading semantic definitions and generating SQL against physical tables. Do not assume every AI answer was calculated through a `SEMANTIC_VIEW(...)` query merely because a semantic view was supplied as context. Inspect the actual query path.

For direct semantic queries, the [query reference](https://docs.snowflake.com/en/sql-reference/constructs/semantic_view) restricts which dimensions can accompany a metric based on relationships and grain. A semantic view is not permission to combine every dimension with every measure.

Use the existing warehouse engineering process to review definitions and upstream quality. AI-assisted model creation can accelerate drafting; a person who understands the business still needs to approve the meaning.

## LookML: reuse definitions that already support trusted Explores

LookML defines the modelling layer behind Looker. In the standard [Looker conversational analytics](https://docs.cloud.google.com/looker/docs/conversational-analytics-overview) Explore path, the AI selects fields and query settings, and Looker generates the query through LookML.

That is a strong starting point when finance, product and growth already use maintained Explores. Moving the same definitions into a second AI-specific model creates another place for them to drift.

Looker's [symmetric aggregates](https://docs.cloud.google.com/looker/docs/best-practices/understanding-symmetric-aggregates) can protect supported aggregations against join fanout, but they depend on unique primary keys and correct relationship declarations. They do not decide whether your “revenue” measure should include refunds or use an end-of-day snapshot.

For MRR, expose the intended snapshot selection and measure together. Check the result when someone changes a date filter from one day to a month. A well-labelled sum field can still invite an invalid calculation if the Explore leaves the time behaviour ambiguous.

Choose this path when the LookML model is the maintained source of business logic and Looker is an important consumption route. If other tools need the same metrics, verify their actual integration path. Copying a LookML description into another agent does not make that agent execute Looker's calculation.

## Make the AI use the intended calculation path

After choosing a modelling home, draw the route from question to answer. The diagram should identify where the metric is selected, where SQL is generated, which identity executes it and where the result is checked.

![A business question is resolved into an approved metric definition, then follows a governed metric query or context-guided SQL route before result and access checks and an evidenced answer.](https://www.martechdevs.com/assets/blog/semantic-layer-ai.svg)

Prefer a governed metric query for a question already covered by an approved metric. If generated SQL is needed for exploration, make that route visible and evaluate it separately. A raw query that happens to match the metric once is not proof of continued consistency.

The [dbt remote MCP setup](https://docs.getdbt.com/docs/dbt-ai/setup-remote-mcp) distinguishes semantic, discovery and SQL toolsets and allows tools to be disabled. It also gives different authentication requirements for SQL execution. Configure the toolset around the task instead of assuming that connecting dbt forces every question through a metric API.

This is the difference between a semantic layer existing and a semantic layer being used. Record which metric or query produced the answer. For recurring executive reporting, that evidence should be easy to retrieve without reconstructing a chat transcript.

## Test access separately from metric correctness

A correct number can still be inappropriate for the person asking.

In dbt's [Semantic Layer setup](https://docs.getdbt.com/guides/sl-qs), a service token maps to an underlying data-platform credential; that credential's access policies govern execution. Personal-token authentication can use personal credentials. Do not assume a shared integration token automatically represents each chat user's warehouse identity.

Snowflake documents `SELECT` on the semantic view for direct querying, without requiring `SELECT` on its underlying tables. Its current guide also requires `SELECT` on a view you do not own when using it with Cortex Agents. Test the complete query route under the intended role; view access and direct-table access are different grants.

In Looker, [`hidden` is a presentation setting](https://docs.cloud.google.com/looker/docs/reference/param-field-hidden), not a security boundary. Removing a field from a picker should not be your method for protecting restricted data.

For each implementation, include a permitted user, a restricted user and a service identity in the review. Check both result rows and exposed metadata. Metric definitions can themselves reveal sensitive business rules even when no customer rows are returned.

## Build a regression pack around business meaning

Use a small fixed fixture like the one above, then add realistic cases from your own reporting. Keep the reference results independently reviewable.

Test at least these behaviours:

1. A total at one complete snapshot matches the reference result.
2. A multi-day request does not sum a non-additive metric across time.
3. A missing snapshot is distinguished from a measured zero.
4. A segment uses the intended historical or current dimension value.
5. A join does not multiply the metric's population or amount.
6. An ambiguous metric name prompts clarification.
7. A restricted identity cannot retrieve disallowed data.
8. A request outside the model's scope is identified as unsupported.

Separate source-model checks from semantic-query checks and AI interpretation checks. If the source contains duplicate workspace-date rows, repair the model. If the semantic definition sums snapshots, repair the metric. If the agent chooses cash collection when asked for MRR, repair selection and instructions.

Do not treat successful compilation as business validation. Syntax checks establish that a definition or query can be processed. They do not establish that it answers the intended question.

## Change definitions without rewriting history silently

Metrics evolve. A new pricing model may add usage charges. The company may change how it classifies suspended subscriptions. An acquisition definition may move from first contact to first qualified opportunity.

For each change, record the old and new meaning, owner, effective date, affected consumers and whether historical values will be restated. A correction to bad data and a change in business policy need different explanations.

Run old and new definitions against the same periods. Explain the difference before switching dashboards and agents. If the change alters a key metric materially, provide a bridge between the old and new totals so a founder does not mistake a definition change for growth.

Keep one authoritative implementation for each intended definition. Multiple platforms may consume or mirror it, but name the owner and test that the copies stay aligned. “One definition” is an ownership and release discipline as much as a technology choice.

## Choose the smallest maintained implementation

Start with dbt Semantic Layer when the modelling team already works in dbt and needs reusable metrics across consumers. Start with Snowflake semantic views when the warehouse and native analysis workflow are the natural home. Start with LookML when trusted Explores already carry the business definitions.

If there is no trusted source model yet, a reviewed reporting view and a few fixed queries can be a useful first step. Expand into a broader semantic graph when additional questions and consumers justify its maintenance.

The [warehouse AI analyst comparison](https://www.martechdevs.com/blog/ai-analyst-for-your-warehouse) covers the application choice. Make that choice after deciding where the definitions should live, so the next interface does not create a competing metric catalogue.

Before releasing the first metrics:

## Checklist

- [ ] Entity grain and source uniqueness are checked.
- [ ] Metric names distinguish different business concepts.
- [ ] Time, currency, eligibility and non-additive behaviour are explicit.
- [ ] Supported dimensions and join paths match the actual data.
- [ ] Agents use the intended query path and expose its evidence.
- [ ] Access is tested under the identities that will use the system.
- [ ] Version changes include reference cases and a consumer rollout plan.
- [ ] A business owner and a technical owner can resolve disputed results.

If every AI answer still needs someone to reconcile three revenue definitions, improving the prompt is unlikely to solve the underlying problem. Our [warehouse and CDP work](https://www.martechdevs.com/data-warehouse-cdp) can establish the models and tests, while [AI-ready data preparation](https://www.martechdevs.com/ai-ready-data) connects those definitions to the tools that consume them. Begin with the number your team most often argues about.

## Frequently asked questions

### Do AI agents need a semantic layer?

Agents answering recurring business questions benefit from explicit, maintained definitions. That can start with a narrow reporting model and approved queries. A formal semantic layer becomes more valuable as metrics, relationships and consumers multiply. It does not remove the need to test interpretation or source quality.

### Is a semantic layer the same as a data warehouse?

No. The warehouse stores and processes data. The semantic layer adds business meaning and supported calculation relationships above that data. Snowflake semantic views live inside the warehouse, while other approaches use separate modelling or query services.

### Should we use dbt Semantic Layer or Snowflake semantic views?

Choose based on the maintained modelling workflow and consumption routes. dbt is a natural candidate for definitions owned with dbt models across tools. Snowflake semantic views fit warehouse-native definitions and analysis. Test the same difficult metric through both before creating duplicate implementations.

### Does LookML guarantee that AI answers are correct?

It provides a governed modelling path for supported Looker queries. Correct results still depend on the model, keys, joins, filters and the question's interpretation. The model cannot supply missing source data or decide an undefined business policy.

### Can a glossary or Agents Schema replace a semantic query engine?

A glossary or metadata discovery layer can help an agent find and understand a definition. A semantic query engine applies supported metric logic when producing results. They can complement each other. Check whether the answer actually used the governed calculation rather than assuming that access to documentation was enough.

## Sources

1. [dbt Semantic Layer overview](https://docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl)

2. [MetricFlow join logic](https://docs.getdbt.com/docs/build/join-logic)

3. [Current dbt semantic-model specification](https://docs.getdbt.com/docs/build/semantic-models)

4. [MetricFlow local and platform commands](https://docs.getdbt.com/docs/build/metricflow-commands)

5. [Snowflake semantic views overview](https://docs.snowflake.com/en/user-guide/views-semantic/overview)

6. [Snowflake semantic-view definitions and privileges](https://docs.snowflake.com/en/user-guide/views-semantic/sql)

7. [Snowflake SEMANTIC_VIEW query reference](https://docs.snowflake.com/en/sql-reference/constructs/semantic_view)

8. [Looker conversational analytics overview](https://docs.cloud.google.com/looker/docs/conversational-analytics-overview)

9. [Looker symmetric aggregates](https://docs.cloud.google.com/looker/docs/best-practices/understanding-symmetric-aggregates)

10. [dbt remote MCP setup and tool configuration](https://docs.getdbt.com/docs/dbt-ai/setup-remote-mcp)

11. [dbt Semantic Layer setup and credentials](https://docs.getdbt.com/guides/sl-qs)

12. [Looker hidden field behaviour](https://docs.cloud.google.com/looker/docs/reference/param-field-hidden)