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". Snowflake's semantic views store "semantic business concepts directly in the database", with metrics as first-class objects that carry "a single authoritative definition with proper aggregation behavior". The adjective is doing a lot of work in all three 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 one place, and consumers receive compiled SQL rather than copying the logic into their own queries. Everything else depends on this 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. The database has its own controls at the same altitude, and they are not the weak point: Postgres row security policies restrict "which rows can be returned by normal queries" per user, and column grants restrict columns. Both attach to tables, and neither knows what a metric is. A rule like "this role sees revenue but never the refund breakdown" can only be written where the refund breakdown exists as a named measure, which is the layer. Row security below it is the second line, and a good one for the consumers that bypass the first.

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. We made the same argument 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. Snowflake's route shows the same question from a second angle. A semantic view can be attached as a tool on a Cortex Agent, and the documentation is candid about what happens next: the agent "reads the information captured in the semantic view definition and generates the SQL against the physical tables directly". The definition informs the SQL; it does not compile it. Whether the generated query can drift from the definition is a property of the agent, not of the view. Holding that line at runtime, per call rather than per configuration, is 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.

The definition became a securable object

Two releases since this post first ran moved the governance boundary without moving the enforcement point. Apache Polaris 1.8.0, released on September 28, 2026, made the metric definition itself a securable object: semantic models stored in the catalog now carry dedicated privileges for listing, creating, reading, updating, and dropping, grantable to catalog roles on an individual model, a namespace, or the whole catalog, with separate controls for managing model grants. That is real governance of the definition: who may read the revenue formula, who may change it, who may pass that right along. Notice what the privilege attaches to, though. It guards the document, and the catalog's authorization stops at its own API: the SQL a consumer writes after reading the model runs against the warehouse under whatever grants that consumer already held.

dbt opened the opposite door: it now reads Apache Ossie interchange documents natively from an osi/ directory, so a definition written in another tool can land in the project that compiles it. The support is deliberately narrow, spec versions 0.1.0 and 0.1.1 on a single dbt release line, and the converter drops constructs it does not implement while parsing continues, logging warning I078 rather than failing. A portable definition can arrive, compile cleanly, and be missing pieces. Both releases mature the definition side of the architecture, privileges on it and portability of it, and neither adds a compiled query path. The checklist from the top of this post survives both unchanged.

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.

Here 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).
6. Snowflake, Overview of semantic views (facts, dimensions, metrics; Cortex Agents generate SQL against the physical tables from the view definition).
7. PostgreSQL, Row security policies (per-user restriction of which rows normal queries can return).
8. Apache Polaris, 1.8.0 release notes, September 28, 2026 (dedicated privileges on semantic models at model, namespace, and catalog scope; separate controls for managing model grants).
9. dbt Labs, Ossie semantic models documentation (dbt v1.12 requirement, spec versions 0.1.0 and 0.1.1, osi/ directory, warning I078 on dropped constructs).