Semantic Models
Advanced 13 min read Semantic Models

Governance for Semantic Models

Ownership, certification and lineage for definitions

Govern a semantic layer the way you'd govern software: owners and SLAs on metrics, certification tiers, versioned definitions, usage/lineage, and auditing access to the layer.

semantic governancemetric ownerscertificationlineagedata catalog
Prerequisites: The Semantic Layer Overview
Before we start

What you will learn

  • Assign owners and SLAs to metrics
  • Apply certification tiers to layer objects
  • Track lineage and usage of consumers
Introduction

What is this?

Semantic governance gives definitions management structure: every metric has an owner and documented SLA; layer objects are tiered (experimental → certified → certified-only-as-source); lineage maps models → metrics → reports; and access to the layer is auditable. Governed, because a semantic layer that loses owners and lineage becomes just another unowned SQL layer.

Motivation

Why do you need it?

  • Owners are what stop 'everyone quietly owns the Revenue metric'.
  • Certification tells consumers what they can trust and build on.
  • Lineage answers 'where is this number used?' at audit time.
  • Audit trails make the layer defensible under regulation.
Think about it

Mental model

Imagine

A bridge inspector's sign-off log

Think of

Semantic governance

Bridges get inspected, a sign-off log records who cleared them, and red/green tags tell drivers trust level. The semantic layer's log: metric owner, approval, test run, lineage and reverse-lineage. Nobody crosses an uncertified bridge silently.

Mechanics

How it works

  • Owner registry: named owner + alternate per metric, with SLA (freshness, drift, availability).
  • Certification tiers: experimental, candidate, certified — each with a review template.
  • Lineage: automated model→metric→report lineage in the catalog.
  • Access control: who may edit definitions vs consume vs approve.
  • Audit: change log on every metric (who, when, why, to what).

The governance loop around definitions.

Author
Test
Certify
Serve
Audit
Hands-on

Examples

A governed metric registration

A governed metric registration
metric: active_customers
owner: analytics-platform (oncall: @pmo)
sla: { freshness: 24h, drift_threshold: 1% }
tier: certified
lineage:
  inputs: [dim_customer, fact_activity]
  outputs: [report_mao, exec_dashboard, api v2]
access: { edit: [platform-eng], approve: [bi-leads] }
audit:
  - 2026-02-01 karthin changed lookback 24h->28h (PR #812)

Owner, SLA, tier, lineage and audit trail — the fields that make a metric governable rather than fashionable.

Real world

In production

  • A certified 'Revenue' metric gates new dashboards; experimental metrics are sandbox-labeled.
  • Lineage on 'Active Customers' shows exactly which board decks depend on it for audits.
  • A metric owner changes; SLAs and oncall pages re-route in the registry.
Guidelines

Best practices

  • Every metric has exactly one owner and a documented SLA.
  • Certify sparingly; certify means 'build on this'.
  • Automate lineage and audit via CI hooks, never by hand.
  • Review tiers quarterly; un-certify metrics past their usefulness.
Watch out

Common mistakes

  • Zero ownership: the layer's metrics drift and nobody notices.
  • Certifying everything (certification loses meaning).
  • Lineage documented in a slide deck that's already stale.
  • Access sprawl: every analyst editing shared definitions.
When things break

Debugging tips

  • A metric has no owner → the registry is incomplete; assign before changes.
  • Consumers skip certified metrics → either certification is trivial or discovery is weak.
  • Audit question ('who changed revenue?') → the change log must answer in seconds.
Interviews

Interview checkpoint

Test yourself

Quick quiz

0/2
1

Which field makes a metric actionable in an incident?

2

Certifying every metric strengthens consumer trust.

Go deeper

Official documentation

Data keys - data mesh and governance
docs