Skip to content

PATTERN Cited by 1 source

Governed metric as headless-BI substrate

Pattern

Define each business metric once as a first-class object in the data platform's catalog (governance plane), with its measure logic, dimensional join graph, and AI-grounding metadata (display_name / comment / synonyms). Have every consumer — first-party BI dashboards, AI agents, SQL notebooks, third-party BI tools — resolve the same definition through a uniform tool-agnostic contract (e.g. MEASURE(metric_name)).

The pattern resolves the per-tool semantic layer drift failure mode by collapsing N tool-specific metric definitions into one governed primitive that lives in the same catalog as the underlying data, so governance + lineage + audit + AI grounding all flow through it uniformly.

Forces

  • Definitional drift across BI tools when revenue is computed in LookML, Tableau, Power BI, and SQL notebooks separately.
  • Governance gaps when each per-tool semantic layer has its own access control surface.
  • AI agent ambiguity when an LLM has to guess which revenue definition to use.
  • Refactoring cost when the metric logic changes — every BI tool's definition has to be updated.
  • Cost-attribution opacity when each tool runs its own aggregation pipeline and the bill is fragmented.

Solution shape (verbatim from the source)

"Metric Views in Unity Catalog solve this by providing a headless BI layer — a single, governed semantic layer where you define your data model and KPIs once, independent of any specific BI tool. […] AI/BI Dashboards, Genie, SQL notebooks, and third-party BI tools all resolve metrics from the same definitions. Define a metric once, and every consumer — human or AI — gets the same answer."

Three structural moves:

  1. Move the metric definition into the data platform's catalog. Not into the BI tool's semantic layer. The catalog (e.g. Unity Catalog) is where governance, lineage, and access control already live.
  2. Make the resolution contract tool-agnostic. A uniform MEASURE() SQL function (in Databricks) or equivalent abstraction in other systems. Every consumer that can issue SQL can resolve the metric.
  3. Capture semantic metadata with the definition, not separately. display_name / comment / synonyms live in the same object as the SQL logic, so AI agents can reason over the metric without per-tool prompt scaffolding.

Concrete steps

  1. Identify a metric that's currently defined in multiple places (revenue, MAU, retention, NPS).
  2. Pick the canonical SQL definition by negotiation with the business owner.
  3. Create a Metric View in Unity Catalog with measure logic + dimensions + grain.
  4. Annotate display_name, comment, and synonyms for AI grounding. Be generous with synonyms — "sales", "top line", "ARR" are all valid alternates for "revenue" depending on context.
  5. Point one consumer at the new Metric View first (low-risk — start with a SQL notebook or a single dashboard widget).
  6. Verify the numbers match the legacy definition.
  7. Migrate the next consumer.
  8. Once all consumers resolve through the Metric View, retire the legacy per-tool definitions.

Trade-offs

Choice Implication
Catalog-resident metric definition Governance is uniform; refactor cost drops to one place.
MEASURE() resolution contract Locks consumers to engines that support the contract; third-party tools need a connector.
Generous synonyms metadata AI grounding works well; some semantic ambiguity (does "sales" mean revenue or units?) needs disambiguation logic.
Catalog as governance plane Per-team metric ownership requires governance processes — without them, the headless layer just moves the drift inside the catalog.

Where this shows up on the wiki

Failure modes

  • Thin semantic metadata. A Metric View with empty synonyms and a perfunctory comment won't ground AI agents well — the headless win on the AI side is proportional to metadata richness.
  • Metric ownership ambiguity. Without process, two teams define revenue two ways inside the catalog itself. The pattern prevents drift across consumers but not across producers.
  • Materialization-or-not coupling. If the metric resolution always falls back to base-table compute (no materialization), performance can be worse than the per-tool aggregate-table shape it replaces. Mitigation: pair with patterns/auto-materialized-aggregation-via-semantic-layer.
  • Tool support gap. Third-party BI tools that don't natively understand MEASURE() need a connector or live SQL pass- through. The headless win is bounded by integration coverage.

Sibling patterns

Seen in

  • sources/2026-05-27-databricks-bi-serving-pointers-maximizing-for-performance-and-tco — first wiki canonicalisation as a pattern. Names the four-consumer surface (AI/BI Dashboards / Genie / notebooks / third-party BI), the open-standard provenance (SPARK-54119), and the AI-grounding-via-semantic-metadata shape. Reserved for future ingests: cross-vendor consumption stories, the metric-resolution wire protocol, federation across multiple semantic layers.
Last updated · 542 distilled / 1,571 read