One metric, defined once

Define the metric once in version-controlled code, and serve it everywhere through an API. That is the entire pitch, and it is a good one - it moves metric truth out of tool configuration, where it is invisible and unreviewable, into a repository where it gets a diff, a reviewer and a history.

The dbt Semantic Layer, built on MetricFlow, serves that definition over JDBC, GraphQL, a Python SDK, and a dbt MCP server. Note the last one: the same definitions that feed a dashboard also feed an agent. Hold that thought - it is the whole argument of Part 4.

The vocabulary is worth learning exactly, because every competing product uses some variant of it:

• Semantic models - the mapping from your physical tables into the layer.
• Entities - "the join keys of your semantic model."
• Dimensions - "the ways you want to group or slice/dice your metrics."
• Measures - the raw aggregatable columns.
• Metrics - what the business actually asks for, built from measures.

This is the most useful sentence in dbt's own FAQ, and it will save you months of pointless meetings:

Read the diagnostic out of it. When two teams report different revenue, there are only two possibilities, and they need completely different responses:

• Different aggregation - one team sums gross, the other sums net of refunds. These are genuinely two metrics and should be named as two metrics. This is rare.
• Same aggregation, different filter or grain - one team excludes internal test accounts, one reports on order date and the other on ship date, one is in the reporting currency and one is not. This is the same metric, sliced differently. This is almost always what is happening.

The practical consequence: most "our numbers disagree" fights are filter and grain disputes, not definition disputes. A semantic layer helps enormously with the second kind, because filters and grain become explicit parameters on a shared definition rather than invisible choices buried in someone's WHERE clause. But it only helps if you diagnose correctly first. Teams that treat every disagreement as a definition problem end up with forty near-identical metrics and are worse off than when they started.

Shape only - the point is which blocks exist, not the exact syntax of any one version:

semantic_model:
  name: orders
  entities:
    - name: order_id      # primary -> the grain of this model
    - name: customer_id   # foreign -> how it joins to customers
  dimensions:
    - name: ordered_at    # the ways you slice the metric
    - name: sales_region
  measures:
    - name: order_total   # the raw aggregatable column

metric:
  name: revenue           # defined once, served everywhere
  type: simple
  measure: order_total

Nothing here is difficult. That is exactly why the layer gets underestimated - the YAML is the easy half, and Part 2 is about the half that is not.

Take an orders table with one row per order, carrying an order total. Take a line-items table with one row per product in that order. Join them so an analyst can slice revenue by product category, then sum the order total.

An order with three line items now contributes its total three times. The SQL is valid. The query runs. The dashboard renders. The number is wrong by however many line items the average order carries, and it is wrong in a way that scales with your business, which means it looks like growth.

That is a fan-out join. A chasm join is its cousin: two independent one-to-many relationships hanging off one table, multiplied against each other. Both produce plausible, confident, wrong numbers - the same failure signature you will meet again in b9.

The second thing that surprises buyers. MetricFlow generates SQL at query time. Nothing is precomputed by default - dbt says so directly: "you're not materializing any data by default."

So the semantic layer does not save warehouse spend. Every query still hits the engine, and now it hits the engine with generated SQL rather than hand-written SQL. What the layer actually does to your cost structure is move it: from human duplication to machine compute plus a licence fee. That is very often a good trade, because the human duplication was costing you reconciliation meetings, wrong decisions and analyst attrition. But it is a trade, and a finance stakeholder who was told "this will reduce our warehouse bill" will remember that sentence.

Present the trade honestly and it survives the budget review. Present it as a saving and it does not.

Credit where due: these come from dbt's documentation, not from a competitor's comparison page. Any vendor whose docs list constraints this plainly is easier to plan around than one whose docs do not.

Open Semantic Interchange (OSI) is a Snowflake-led effort announced 2025-09-23: a standardized YAML format for exchanging semantic models between tools. Partners include Alation, Atlan, Cube, dbt Labs, Hex, Sigma and ThoughtSpot.

The reason to care is portability. Right now, the definitions you write are the deepest lock-in in the stack - deeper than the table format, because a metric definition encodes business agreement that took nine months of meetings to reach. If those definitions become an exchangeable artifact, the switching cost of a semantic layer drops sharply, which is exactly why an announcement with this partner list is interesting.

Two honesty notes. First, a partner list is an announcement, not an implementation - the useful question is which of those seven have shipped import and export against it. Second, we could not verify a v1.0 date or repository at the time of writing, so treat OSI as a direction of travel, not as something you can build a migration plan on today.

A small, concrete exercise you can repeat on any vendor in any category.

Notice which direction the error runs. The vendor is understating its own number, which tells you exactly what happened: someone hardcoded the figure into the page during a redesign and nobody has touched it since. That is the general lesson - vendor stat blocks are frozen marketing artifacts, not telemetry. They are a snapshot of a number on the day a designer wrote the HTML.

Two follow-ons. Stars themselves are a weak proxy for anything: they are cumulative, never decay, and reward age over activity. And if a vendor's own homepage number is two years stale, ask the same question of every other number on that page - especially the ones you cannot check against an API.

Consider two scenarios that look completely different and are structurally identical.

Scenario one. A second BI developer joins, is pointed at the warehouse, and builds a revenue dashboard. They do not know that internal test accounts are excluded, that revenue is reported on ship date, or that one region's currency conversion happens upstream. They write reasonable SQL. Their number differs from the existing dashboard by four percent. It takes three weeks and two meetings to find out why.

Scenario two. An agent is given warehouse credentials and asked for revenue by region. It writes reasonable SQL. It does not know any of those three things either, because none of them are written down anywhere the agent can read. Its number differs by four percent. Nobody investigates, because nobody knows to.

Same failure, same cause: the business logic lives in people's heads and in tool configuration rather than in an addressable artifact. The only differences are speed and volume. The second BI developer produces one wrong dashboard a fortnight and is eventually corrected by a colleague. The agent produces forty wrong answers before lunch, each one delivered with the same confident formatting as a correct one, to people with no way to tell the difference.

This is why "we will add the semantic layer later, after we ship the AI assistant" is the sequencing error the whole course exists to prevent. The assistant does not create the problem. It removes every human checkpoint that was quietly containing it.

The corollary is more encouraging than it sounds: the work you do on this layer is not BI work that also happens to help AI. It is the same work, and it is the best-returning investment available at this point in the stack, because it pays out twice. b9 is the evidence session that measures exactly how much it pays.