Book a demo

PRODUCT : semantic layer : GOVERNANCE

Governed metrics,
managed like code.

how governance works

How does AtScale govern metrics for AI and BI?

AtScale Governance applies data governance to the semantic layer. A change to what revenue means arrives as a pull request, with a diff, a reviewer and a way back. Warehouse permissions follow every person and every AI agent.

Every metric, dimension, hierarchy, relationship, calculation and security rule is stored as code. Each change is versioned, tested and deployed through the same CI/CD process as production software. Your existing warehouse permissions apply to every user and every AI agent. Domain owners manage their own definitions while a central team coordinates them, so every BI tool and AI agent works from one single source of truth for metrics.


THE PROBLEM

A changed definition can break every report and agent that uses it.

In most companies, business definitions live in BI tools, spreadsheets and prompts: what counts as revenue, how the fiscal calendar rolls up, which region a customer belongs to. Someone edits one in place, with no test against known answers and no way to roll it back, and the error shows up weeks later when two reports disagree. If an agent’s relying on that definition, it’s already acted on the wrong number by then.



how it works

A change to revenue is a pull request, with a diff and a blast radius

Every change to the semantic model arrives as a pull request, whether it’s a metric, a hierarchy or a security rule. In the example below, Finance proposes excluding intercompany sales from recognized revenue. Two reviewers look at the diff, the checks run, and only an approved version reaches production. If it turns out to be wrong, you can revert it in one click.

Recognized Revenue semantic metric: version history, model compilation, unchanged access rules, and review actions before merging a definition change.

What AtScale Governance manages

Governance covers the whole life of a definition, from the first draft to the query that uses it months later.

Version history and source control

Every object in the model keeps its full history in Git, with an author, a timestamp and a diff for each change. The semantic model, its test cases, modeling memory and semantic memory are versioned together. For example, a revenue metric might move to ASC 606 in v2 and drop intercompany sales in v4.

Review and testing

Each change opens a pull request with a named reviewer. Domain owners own their definitions, and a central team coordinates them. A change merges only if the model compiles and access rules don’t change. Canary, coming this fall, will rerun your test questions before and after each change and whenever you switch AI models, so a fix can’t quietly break an answer that used to be right.

Promotion and rollback

Approved versions move from dev to QA to production, and nobody edits a definition in a live environment. Rolling back is a revert.

Lineage and audit trail

Each metric points back to the dataset and column it comes from, and every query traces to the definition version that produced it. AtScale records every live and test interaction, and nobody can edit an entry once it’s written.

Lineage and audit trail

Row- and column-level security is defined once for every tool, perspectives hide parts of the model from some audiences, and each user’s identity passes through to the data platform.

Propose, review, promote

Propose.

A change to a definition arrives as a pull request against the model in your repository, in a text format a person can read without a tool.

Review.

AtScale runs both definitions and reports which metrics and which reports move. Canary runs your question suite against the change before it merges. (Canary coming this fall)

Promote.

The approved change moves through your environments the way code does, and reverts the same way when it shouldn’t have shipped.

People and agents see only what they’re allowed to.

Each user’s identity passes through to the data platform, so an agent never sees more than the person it works for. Row- and column-level security is defined once and applies the same way whether someone prompts Claude or Codex or opens a report in Excel or Power BI. Sign-in runs through Okta, Microsoft Entra ID (OIDC or SAML 2.0) or Active Directory (Kerberos).

the proof

Blue Yonder manages 600 semantic objects this way.

FAQs

How do we roll back a bad change?

In SML files in your own Git repository, one file per object, on GitHub, GitLab, Azure DevOps or Bitbucket. SML is open source under the Apache 2.0 license, so your definitions aren’t locked in a proprietary format.

Who can change a definition?

The domain owner opens a pull request, and a named reviewer approves it. Domain owners own their definitions while a central team coordinates them, so each team can move at its own pace.

Is a change tested before it merges?

Yes. A change merges only if the model compiles and access rules don’t change. Canary, coming this fall, will also rerun your test questions before and after each change.

Can I see which definition produced a number?

Revert the pull request in one click. The previous version goes back into production, and the history shows what changed and when.

Do agents follow the same access rules as people?

Yes. Every query traces back to the definition version that produced it, and each metric points back to the dataset and column it comes from.

Does it work with our identity provider?

Yes. Each user’s identity passes through to the data platform, so an agent never sees more than the person it works for. Row- and column-level security is defined once for every tool.

Do I buy Governance separately?

Yes. Sign-in runs through Okta, Microsoft Entra ID (OIDC or SAML 2.0) or Active Directory (Kerberos), and AtScale passes each user’s identity through to the data platform.

Is a change tested before it merges?

No. It’s part of AtScale, alongside ACE (the AI Computation Engine), Ava, the MCP server and CoModel (coming this fall).

See a change to your semantic model go through review.