dbt semantic layer vs. the AI interpretation layer: solving different problems

The term "semantic layer" is overloaded. In data engineering circles, it means one thing. In the AI analytics conversation, it means something else. Both definitions are legitimate. They solve different problems.

This post is not a dbt takedown. dbt is excellent at what it does. The point is that the two concepts sit at different levels of the stack, solve different problems, and serve different audiences. Understanding the distinction helps you invest in the right one — or both.

What dbt's semantic layer does

dbt's semantic layer (powered by MetricFlow) solves a consistency problem. When five teams query "revenue," they should all get the same number. Without a semantic layer, each team writes its own SQL, makes its own assumptions about filters and joins, and ends up with five different revenue figures in five different dashboards. Meetings turn into arguments about whose number is right.

dbt fixes this by defining metrics once, in code:

metrics:
    - name: revenue
      type: simple
      type_params:
          measure: total_revenue
      filter: |
          {{ Dimension('order__is_completed') }} = true
          AND {{ Dimension('order__is_test') }} = false

Now "revenue" means the same thing everywhere. Every BI tool, every dashboard, every ad-hoc query resolves to the same SQL. This is genuinely valuable. If you've ever been in a meeting where finance says revenue is $2.1M and marketing says it's $1.8M, you understand the problem dbt's semantic layer solves.

What dbt's semantic layer does not do

dbt tells every tool which number to use. It does not tell any tool what the number means.

After dbt ensures that "revenue" resolves to $2.1M across every query, the AI still has no idea whether $2.1M is good or bad, above or below target, caused by a seasonal spike or a new campaign, or consistent with what the team discussed last week.

dbt normalizes queries. It does not contextualize answers.

What an AI interpretation layer does

An AI interpretation layer solves the context problem. It encodes not what the metric computes to, but what it means — in the context of targets, history, platform behavior, team decisions, and related data from other systems.

The five-layer model covers this in detail, but the short version: metric definitions, domain expertise, business context, institutional memory, and cross-source intelligence.

Where dbt says "revenue = SUM(order_total) WHERE is_completed = true AND is_test = false," the AI interpretation layer says:

• Revenue target for Q2 is $6.3M (linked from Q2 planning doc)
• Revenue typically dips 5-8% the first week of each month (historical pattern)
• The team attributed last month's spike to the enterprise deal that closed March 28 (thread from #revenue-updates)
• When revenue drops, check Meta ad spend and checkout conversion rate in PostHog (cross-source pattern)

These are fundamentally different kinds of knowledge. One is computational. The other is interpretive.

Side-by-side comparison

When you need which

You need dbt's semantic layer when multiple teams query the same warehouse and get different numbers. This is a consistency problem that dbt solves well. It requires a warehouse, a dbt project, and someone who can write and maintain SQL models. Most teams that need this have 50+ employees and a dedicated data or analytics function.

You need an AI interpretation layer when your AI-generated reports describe charts instead of explaining them. This is a context problem. It does not require a warehouse, SQL, or a data engineer. It requires encoding the business knowledge your team already carries — targets, context, platform quirks, prior decisions — so the AI can use it.

You need both when you have a mature data stack (warehouse + dbt) and you also want AI-powered analysis. dbt gives the AI consistent data. The interpretation layer gives the AI the context to explain what that data means. They stack cleanly.

The 90% who don't have a warehouse

This is the part of the conversation that gets lost in data engineering discourse.

Most teams don't have a data warehouse. They don't have a dbt project. They don't have an analytics engineer. They have a Shopify store, a Google Ads account, a HubSpot CRM, and a spreadsheet where someone tracks the monthly targets. Their data lives in SaaS tools, not a warehouse.

For these teams — and they are the overwhelming majority — the dbt semantic layer is not an option. It solves a problem they don't have (query consistency across a warehouse) and requires infrastructure they don't want to build.

The AI interpretation layer is the only semantic layer that applies. It sits between their existing data sources and the AI that explains them. No ETL. No SQL. No warehouse. Link the planning doc, write a few sentences of context per source, and the AI starts producing analysis instead of narration.

This is not a criticism of dbt. It's an observation about where different tools sit in the stack. dbt is infrastructure for teams with data infrastructure. An AI interpretation layer is knowledge infrastructure for teams with business knowledge.

Complementary, not competitive

If you already run dbt, an AI interpretation layer does not replace it. It adds to it. dbt ensures your revenue number is $2.1M in every tool. The interpretation layer ensures the AI knows that $2.1M is 4% ahead of the Q2 monthly target, consistent with the trend since the pricing change in February, and $300k above where you were at this point last year.

Consistent data + contextual interpretation = analysis worth reading.

If you don't run dbt, the interpretation layer works independently. It pulls data from your source tools directly (Shopify, Google Ads, HubSpot, Xero, etc.) and layers context on top. The data doesn't need to pass through a warehouse first because the AI isn't writing SQL — it's reading API data and explaining what it sees.

Where to start

If you're evaluating which semantic layer to invest in, the decision tree is straightforward:

Do you have a data warehouse with multiple teams querying it? Look at dbt. Solve the consistency problem first.

Do you want AI-generated reports that actually explain your business? You need an interpretation layer. This is true whether or not you have dbt.

Do you have both needs? Build dbt for query consistency, then add an interpretation layer for AI context. They solve different problems at different levels.

For the five layers that make up a complete AI interpretation layer — metric definitions, domain expertise, business context, institutional memory, and cross-source intelligence — see the pillar post: What is a semantic layer, and why does your AI analytics need one?.

Chartcastr's semantic layer implements all five layers on top of your connected data sources, no warehouse required. If you already have dbt feeding a warehouse, it works alongside it — the AI gets both consistent data and the context to interpret it.