Governed metrics: what they are and what enforces them

TL;DR. A governed metric is a metric with an enforcement point: one stored definition that a semantic layer compiles to SQL on every query, with access policy applied before the SQL is generated. The definition file is the smaller half of that. dbt and Cube both ship the machinery, and both now expose it to AI agents over MCP, which is where the idea gets tested honestly: dbt's own MCP server offers agents query_metrics and, in the same toolbox, text_to_sql and execute_sql. A metric is governed exactly as far as consumers cannot route around its compiled path, and most stacks still leave that route open.

Every semantic layer vendor now sells governed metrics. dbt describes its Semantic Layer as centralizing metric definitions so that a change "is refreshed everywhere it's invoked". Cube calls the semantic layer "the governed layer between your data warehouse and the tools that consume data". The adjective is doing a lot of work in both sentences, and the pages that rank for the term mostly leave it undefined: governed appears as a synonym for centralized, certified, or simply written down. It is a stronger claim than any of those. A metric definition is a file. Governed metrics are an architecture, and the difference between the two is where a query is allowed to travel.

The four properties that make a metric governed

Read the vendor material closely and governance decomposes into four operational properties. Each one is checkable against a running stack.

One definition, compiled at query time. The metric's logic lives in exactly one place, and consumers receive compiled SQL rather than copying the logic into their own queries. This is the load-bearing property. dbt's MetricFlow exists so that revenue is defined once in the project and every downstream tool queries that definition through the Semantic Layer APIs; Cube's model works the same way. Compilation is what makes a definition change propagate: edit the definition and the next query from every consumer picks it up, because no consumer holds a copy.

Access policy applied before compilation. Cube states the ordering precisely: row- and column-level permissions are "enforced before the SQL is generated". The layer decides what this caller may see, then writes SQL that can only return that. Contrast this with warehouse grants, which operate on tables and columns, an altitude too coarse to express "this role sees revenue, but only for its own region, and never the refund breakdown".

Ownership and change control. dbt's model governance features are the clearest published version of this: models marked public or private to control who may build on them, contracts that guarantee column names and types before a model builds, and versions that give downstream consumers "a smoother upgrade pathway and deprecation window" when a breaking change is unavoidable. A governed metric has someone accountable for its definition and a process for changing it that its consumers can survive.

Every consumer on the same path. The property that makes the other three matter. If the dashboard queries the layer but the finance spreadsheet queries an extract, the metric is governed for one consumer and folklore for the other.

A definition is not an enforcement point

The failure mode this vocabulary exists to prevent is old: the same question returning different numbers from different tools, because each tool's author restated the business logic and drifted. Centralizing the definition in a repo feels like the fix, and it is roughly half of one. Version control gives you history, review, and blame for the definition. It does nothing about the query path, and the query path is where the numbers are made.

The definition is identical on both sides. What differs is whether the query path is allowed to skip it.

The test for whether a metric is governed is therefore about routes, and it takes one question per consumer: can this tool reach the underlying tables without passing through the layer? A BI tool with its own metric store answers yes. A data scientist with warehouse credentials answers yes. A CSV extract refreshed weekly answers yes, with staleness added. Each yes is a consumer for whom the metric is defined but ungoverned, and each one re-derives the logic with some probability of drifting from it. The semantic layer does not need to be the only thing that can query the warehouse, but every consumer that reports the metric needs to be on the compiled path, or the one-version-of-the-truth claim quietly shrinks to one-version-among-several.

Agents made the bypass visible

For a decade the bypass problem stayed tolerable because the bypassing consumers were people, and people drift slowly. A spreadsheet formula wrong by one filter gets caught at quarter close. An LLM agent re-deriving a metric drifts per prompt. Cube's framing of the problem is accurate: point a model at raw tables and it has to re-derive the business on every question, so two phrasings of the same question can return two numbers. The governed alternative is that agents select certified metrics by name and never write the aggregation at all. This is the same argument we made about schema semantics in the context layer guide: the resolved meaning has to be served to the agent, because an agent that infers meaning per session infers it differently per session.

The tooling for the governed path now exists and is concrete. dbt's MCP server gives an agent, among others, these tools:

list_metrics               discover the metrics that exist
query_metrics              the layer compiles and runs the SQL
get_metrics_compiled_sql   inspect what the layer would run
text_to_sql                generate SQL from natural language
execute_sql                run arbitrary SQL on the platform

The first three are governed metrics working as designed: the agent names a metric, the layer compiles it, the number that comes back is the same one the dashboard shows. The last two are the bypass, shipped in the same server. There are good reasons to expose them; plenty of agent questions are not metric queries. But the combination means governance at the agent boundary is currently a convention about which tool gets called, and a convention held by a language model under a prompt is not an enforcement point. Whether an agent platform can hold that line at runtime, per call rather than per configuration, is exactly the gap we keep finding across agent-database launches: the specs deliver context and instructions to agents in ever cleaner formats, and leave what the agent may actually do to the harness.

The output side has the same shape. dbt Charts, an open YAML spec for dashboards that agents generate through chat, shipped its pitch on September 14, 2026 with a telling roadmap line: Semantic Layer support is planned, "so a board can use a metric as the project defines it instead of restating its SQL". Today, the chart an agent builds restates the SQL. The restated copy is the thing governed metrics exist to eliminate, and it is still the default output of the newest agent tooling in dbt's own ecosystem.

What a governed metric still does not carry

Suppose the architecture is complete: one definition, compiled access-checked SQL, every consumer routed through it, agents included. What the consumer receives is still only the definition and the number. Whether the definition is right is a different property, and nothing in the metric spec carries it. When we read the Apache Ossie interchange spec, the conclusion was that definitions travel and trust does not: a metric arrives with its formula and none of its provenance. Who validated this definition against the schema it reads? Has anyone confirmed that net_amount still means what it meant when the metric was written, or that the pipeline feeding it did not change semantics two migrations ago? A governed metric with a stale definition is arguably worse than an ungoverned one, because governance launders it: every consumer now agrees on the same wrong number, delivered over an audited path with permissions applied.

This is where metric governance stops being a semantic layer feature and becomes a context problem. The enforcement point guarantees consistency. Trust needs the layer underneath: whether the definition was validated, by whom, against which version of the schema, and whether what it reads has since drifted.

Datapace is building the context layer between your databases and your AI: resolved meaning validated by the people who own the data, the workload evidence beside it (cost, performance, usage and freshness, lineage), and a policy gate over what an agent may do and access, served over MCP. Governed metrics are the part of that picture the semantic layer vendors have built well; the validation and drift half is the part we are building. If you are deciding what your agents should be allowed to compute against production data, book a call.

Sources

1. dbt Labs, dbt Semantic Layer documentation (centralized definitions, MetricFlow, Semantic Layer APIs, access permissions).
2. Cube, What is a semantic layer? ("the governed layer between your data warehouse and the tools that consume data"; permissions "enforced before the SQL is generated"; SQL, REST, GraphQL, and MCP interfaces).
3. dbt Labs, About model governance (model access, contracts, versions, deprecation windows).
4. dbt Labs, dbt-mcp repository (list_metrics, query_metrics, get_metrics_compiled_sql, text_to_sql, execute_sql).
5. dbt Charts, Charts built for Chat, September 14, 2026 (git-tracked YAML dashboards; Semantic Layer support planned).