Semantic Layer: “Who owns the numbers?”

Governance, ownership, and data contracts at semantic layer scale

You have built the semantic layer. Metrics are defined, validated, and connected to dashboards. The first two or three definitions went smoothly. Then the third team asks to change the revenue metric — and nobody agrees on who gets to decide.

This is the governance problem. And it is not a technical problem. It is an organizational one.

Technical governance — row-level security, column masking, audit trails — matters and we will cover it. But the harder challenge at scale is the human side: who owns a metric definition, how changes get approved, what happens when two teams disagree, and how you prevent the slow drift that turns a well-governed semantic layer into a fragmented mess six months after launch.

This issue is about building the organizational infrastructure that keeps a semantic layer trustworthy over time — not just at launch.

The governance gap most teams don’t see coming

When organizations build their first semantic layer, governance feels like a solved problem. Revenue is defined. The owner is Finance. Everyone agreed. Done.

Then the company enters a new market. Currency conversion logic needs to change. Finance wants to update the definition. The Sales team built three dashboards on the old definition and is worried about breaking their numbers. Marketing used the metric in an automated report that goes to the board. The data engineering team is not sure which tool they are even supposed to update it in.

This is metric drift — and it does not happen because teams are careless. It happens because governance was designed for launch, not for change.

42% of data leaders cite metric inconsistency as their top barrier to trusted analytics in 2026. That number is not about bad definitions at launch. It is about definitions that were good at launch and drifted over time without anyone noticing until the board meeting.

The semantic layer does not solve this automatically. A semantic layer gives you the infrastructure to enforce governance. The governance itself — the ownership model, the change process, the contracts between teams — has to be designed deliberately.

The ownership model: from “data team owns everything” to stewardship

The most common governance failure at scale is centralized ownership of a decentralized problem.

When the data team owns every metric definition, two things happen. First, every change request becomes a ticket, and the data team becomes the bottleneck for every business question about what a number means. Second, domain teams stop trusting definitions they did not help create — and quietly build their own versions in spreadsheets and dashboards.

The model that works at scale is metric stewardship: domain teams own the business definition, the data team owns the technical implementation.

“Governance that depends on one team reviewing every change will not scale. The goal is to distribute ownership to the people closest to the business meaning — while keeping the data team accountable for implementation quality and consistency.” — Data Governance in 2026, Medium

In practice, this means:

• Finance owns the definition of revenue — what it includes, what it excludes, which edge cases apply
• The analytics engineering team owns the YAML that implements that definition in the semantic layer
• Finance approves any change to the business logic; analytics engineering approves any change to the technical implementation
• Neither team can change their half without the other signing off

This sounds like more process. In reality it is less — because it eliminates the constant back-and-forth of “is this definition right?” by establishing clear accountability from the start.

Data contracts: making ownership enforceable

Stewardship models fail when they live in a wiki nobody reads. The mechanism that makes ownership enforceable is a data contract — a formal, versioned agreement between the team that produces a metric and the teams that consume it.

A data contract for a semantic layer metric is not a legal document. It is a structured agreement that answers five questions:

1. What does this metric measure?

Plain-language description including what it excludes. Written for a Finance analyst on their first day, not for a data engineer.

2. Who owns the definition?

A named person — not a team. Teams rotate; named owners are accountable.

3. What are the SLAs?

How fresh is the data? What is the expected refresh cadence? What happens if the metric is unavailable?

4. How do changes get made?

The process: who proposes, who reviews, who approves, how much notice consumers get before a breaking change takes effect.

5. What is the version?

A version number or date that consumers can pin to. When a breaking change is made, the old version stays available for a defined deprecation period.

A data contract does not need to be elaborate. The minimum viable version is a YAML block in your semantic model’s meta field:

metrics:
  - name: monthly_revenue
    label: Monthly Revenue
    description: >
      Sum of recognized revenue for the period. Excludes
      refunds, chargebacks, and intercompany transactions.
      Uses revenue recognition date, not invoice date.
    meta:
      owner: jane.smith@company.com
      domain: Finance
      version: "2.1"
      effective_date: "2026-04-01"
      sla_refresh_hours: 24
      breaking_change_notice_days: 14
      consumers: [sales-dashboard, exec-report, ai-assistant]
      changelog: "v2.1 — Added intercompany exclusion per Q1 audit"

This block is version-controlled in Git alongside the metric definition. When a change is made, the changelog updates, the version bumps, and every consumer listed can be notified. That is governance that travels with the definition — not governance that lives in a separate document nobody updates.

The change management process that actually works

Most semantic layer governance processes fail at the same point: the first time someone wants to change a metric that has downstream consumers.

Without a process, what happens is: someone updates the metric, dashboards break, trust erodes, teams start building their own definitions to avoid dependency on a layer they cannot control. With an overly bureaucratic process, the data team becomes the bottleneck and teams route around it anyway.

The process that works has three characteristics. It is lightweight enough that people actually use it. It is formal enough that changes are visible before they land. And it distinguishes between non-breaking and breaking changes.

Non-breaking changes (no consumer approval required):

• Updating a metric description or plain-language explanation
• Adding synonyms for AI and search resolution
• Adding new dimensions or filters that do not change existing results
• Updating ownership metadata

Breaking changes (consumer sign-off required):

• Changing the calculation logic or filter conditions
• Renaming a metric or dimension
• Changing the time granularity or aggregation type
• Deprecating a metric entirely

The minimum viable change process:

1. Author opens a pull request with the proposed change and a clear description of what changes and why
2. Named metric owner reviews and approves the business logic change
3. For breaking changes: consumers are notified by tagging the PR and given a defined window (typically 14 days) to raise concerns
4. Analytics engineering reviews and approves the technical implementation
5. Change merges and deploys to production; changelog updates; consumers receive an automated notification

If your semantic model lives in dbt, this process is already built in — it is just a pull request. The governance is Git-native. The review is the PR. The changelog is the commit history. The notification is a PR mention. The only thing you need to add is the convention of tagging named owners and consumers.

Metric certification: the trust signal that matters

Once multiple teams are consuming metrics from your semantic layer, users need a way to know which metrics are trustworthy without reading every definition in detail. This is where metric certification comes in.

Certification is a lightweight status system with three tiers:

Certified — the metric has a named owner, a reviewed definition, at least one quarter of production usage, and has passed a validation check against source data. This is the only tier AI assistants and executive dashboards should consume by default.

Verified — the metric is technically correct but has not yet completed the full certification review. Available for exploration and analysis; not recommended for automated reporting.

Experimental — a new or in-progress definition. Available for development and testing only. Not for production consumption.

In dbt MetricFlow, certification status lives in the meta block. In AtScale, it is a first-class governance feature with workflow automation. In platform-native tools, it can be implemented as a tag in the semantic view definition.

“Without it, an LLM picks the field that sounds statistically right, not the one that finance approved. Certification workflows ensure named stewards review and approve metric definitions before AI agents consume them, making every AI-generated answer not just accurate, but defensible.” — OvalEdge, 2026

The certification tier is also the governance signal for your AI layer. When an AI assistant queries your semantic layer, it should be configured to consume only Certified metrics by default — and to surface the certification status alongside any answer it provides. This is what separates AI analytics that can be trusted from AI analytics that can only be audited after the fact.

Governance that travels: the “define once, enforce everywhere” principle

The final piece of organizational governance at scale is making sure security and access policies travel with metric definitions — not just with the tool that happens to be serving them.

The core failure mode is this: row-level security is configured in Tableau for one team, separately configured in Power BI for another, not configured at all for notebook access, and completely absent for AI agent queries. When a new tool is added, the access rules have to be set up from scratch. When a rule changes, it has to be changed in four places. And when an AI agent queries the warehouse directly, none of the rules apply.

The semantic layer is the right place for access policy — and it is the only place where “define once, enforce everywhere” is actually achievable.

When row-level security is defined at the semantic layer:

• A regional sales manager who queries through Tableau sees only their region
• The same manager querying through an AI assistant sees only their region
• A SQL client querying through the semantic layer API sees only their region
• Changing the rule happens in one place and propagates to every consumer

“A semantic layer enforces policies at a lower level. When access control exists in the semantic layer, it applies to every query path — BI tools, SQL clients, AI agents — regardless of which surface the query comes from.” — Data Lake House Hub, 2026

This is not just a security improvement. It is an organizational one. When security is defined in the semantic layer, the data team does not need to coordinate access rule changes across six tools. Domain teams do not need to worry about whether their data is safe to expose through a new consumer. And AI agents can be deployed without requiring a separate access audit for each new interface.

The governance checklist: what “done” looks like

Governance is never truly finished — but there is a clear threshold between “we launched a semantic layer” and “we have a governed semantic layer.” Here is the checklist:

Ownership

• Every production metric has a named owner (a person, not a team)
• Every metric has a named domain (Finance, Marketing, Product, etc.)
• Ownership is recorded in the metric’s meta block and version-controlled

Data contracts

• Every metric has a plain-language description that passes the 10-second test
• Every metric has a version number and a changelog entry for each change
• Breaking changes require consumer notification with a defined minimum notice period

Certification

• All production metrics consumed by AI assistants or executive dashboards are Certified
• Certification status is visible to all consumers at query time
• A quarterly review process checks that Certified metrics remain accurate

Access control

• Row-level security is defined at the semantic layer, not in individual BI tools
• AI agents are scoped to Certified metrics only by default
• A service account audit runs quarterly to confirm no unauthorized consumers have access

Change management

• All metric changes go through a pull request with a named reviewer
• Breaking changes are flagged automatically and trigger consumer notifications
• The changelog is current - every production metric has been reviewed in the last 90 days

If you can check every box on this list, you have a governed semantic layer. If you cannot, the gaps are exactly where metric drift, security mismatches, and AI governance failures will emerge.

TheDataBrief #SemanticLayer #DataGovernance #DataLeadership #DataStrategy #DataContracts