Executive Summary
Most enterprise governance programs have the artifacts a governance program is supposed to have. There's a business glossary with a few thousand terms, a policy library approved by a committee, a stewardship RACI, and a catalog that reports coverage every quarter.
For a long time, those artifacts were the deliverable. A reviewer asked whether the organization had a policy, and the program produced it.
Four things changed the question:
- Auditors and regulators began asking to see policies operating in the systems that produce reported figures, on dates they choose.
- AI governance reviews began asking which definitions an agent read before it answered, and who approved them.
- Catalog renewals began arriving with adoption numbers that describe effort more than outcome.
- Steward turnover and reorganizations began exposing how much of the program lived in specific people's heads.
Each of those moves governance from documenting policy to proving it operates. A program that has to prove operation needs its definitions bound to the systems that compute, its changes reviewed and versioned, its coverage computed from the estate, and its history queryable on any date.
This paper covers what that requires, how well-run programs quietly fall short of it, and a diagnostic you can run against one of your own policies this week with no vendor in the room.
Why the Question Changed
For most of the past two decades, governance produced documents and the documents were reviewed. A glossary entry existed or it didn't. A policy was approved or it wasn't.
That standard was reasonable when a person sat between every definition and every decision. An analyst read the glossary, wrote the report, and answered for the number.
Four pressures removed that person, or moved them far enough away that the documents stopped being sufficient.
Auditors started asking for implementation
SOX, BCBS 239, GDPR, CSRD, and ISSB all contain some version of the same request: show how the control is implemented, and show it for the period in question.
An approved policy answers the first half of an older question. Implementation evidence means showing the definition the reporting system used, who approved it, when it last changed, and which reports carried it. Most programs can produce the policy in minutes and the implementation evidence in weeks.
AI made definitions machine-read
Structured AI interfaces like Snowflake Cortex Analyst and Databricks Genie read a semantic definition before they generate SQL. Agents connected through the Model Context Protocol read whatever context they're given.
A glossary entry that a person might consult becomes, for an agent, either the definition it uses or a document it never sees. AI governance reviews now ask which one it was, and they ask before the system goes into production.
Renewals started measuring outcomes
Catalog contracts renew on a fixed clock, and the adoption report travels with the renewal quote. Coverage percentages that held flat for three years are hard to defend as progress, even when the program behind them is working hard.
The renewal conversation has moved from "is the catalog being used" to "did the policy reach the systems that compute the numbers." Most adoption metrics weren't built to answer the second question.
Programs proved fragile to turnover
Steward networks are usually part-time and cross-functional, with few stewards reporting to the governance lead. When a domain steward leaves, the context behind a set of definitions often leaves too.
A reorganization can turn a stewardship RACI into a historical document in a week. Programs that depend on specific people continuing to show up carry the same institutional risk they were chartered to reduce.
The market moved at the same time
Gartner revived the Metadata Management Magic Quadrant in November 2025, after five years. Categories come back when buyers start asking new questions of an old discipline, and enforcement is the new question.
Where This Shows Up First
The shift rarely arrives as a single event. It shows up in four ordinary situations that go worse than they should.
The closed-quarter request. Internal audit names a revenue figure from two quarters ago and asks what its definition was at quarter close. The glossary shows today's definition. Reconstructing the earlier one takes three people, two weeks, and a search through email.
The glossary that disagrees with the dashboard. The glossary defines net revenue as excluding returns. The Power BI measure finance uses doesn't subtract them. Governance learns about the gap when a CFO asks why two reports disagree.
The AI review that can't sign off. A text-to-SQL pilot works in the demo. The model risk review asks which definitions the agent used and whether governance approved them. The program can show the approved definitions but can't show that the agent read them.
The steward who left. The steward for customer data moves to another role. Six months later, a definition change in that domain sits unreviewed, because the workflow lived in his inbox.
Each of these gets filed as a different problem: an audit problem, a data quality problem, an AI problem, a staffing problem. They resolve to the same missing capability, which is a program whose definitions are bound to the systems that use them and whose history is recorded as it happens.
What a Governance Program Now Has to Do
Documenting policy is still necessary. Proving operation adds five requirements.
Bind every definition to the fields that implement it
A glossary term describes a concept. The columns, measures, and report fields that compute it are where the concept either holds or drifts.
Passing looks like: for any governed term, a list of every physical field that implements it, across the warehouse, the transformation code, and the BI tools, and for any report field, the term that defines it.
Without that binding, the glossary and the estate are two separate records that agree only as long as someone checks.
Compute coverage from the estate
Coverage is a ratio, and the denominator matters. A program that measures documented assets against assets someone registered measures its own activity.
Passing looks like: the inventory of assets collected directly from the systems that hold them, with coverage reported against that inventory and undocumented fields listed by system and by report.
When the denominator comes from the estate, coverage describes the estate. When it comes from the catalog, it describes the catalog.
Review and record every change to a definition
A definition change is a production change, whether or not the tooling treats it as one. Someone proposes it, someone should review it, and someone should approve it before it takes effect.
Passing looks like: a defined workflow from proposal through review, approval, and publication, with the reviewer's comments and the approver's name recorded, and a readable difference between the published definition and the proposed one.
A change made by editing a wiki page passes the day it's made and fails the first time someone asks who approved it.
Answer for any date someone else picks
Auditors and regulators choose the date, and it's rarely today. The question is what the definition said then, who had changed it, and which systems carried which version.
Passing looks like: version history on every governed object, with attribution, comparison between any two versions, and the lineage that existed at the time.
Adding a time axis after the fact means reconstructing history from tickets, logs, and memory. It has to be recorded as changes happen.
Reach the systems that consume the definition
A definition that lives only in the glossary is a recommendation. The BI tool, the warehouse, and the agent each compute or read their own version.
Passing looks like: the governed definition present in each consuming system, in a form that system uses, with a way to confirm the definition running in production is the one that was approved.
This is the requirement most programs were never equipped to meet, because their tooling was built to describe systems from the outside.
How Well-Run Programs Quietly Fall Short
These gaps are hard to see from inside a program that's doing its job. Each of the six below is observable this week without a vendor conversation.
The glossary has no physical bindings
How you'd notice: pick a governed term and ask which warehouse columns and BI measures implement it. The answer comes from a steward's memory or a spreadsheet.
What it costs: divergence between the definition and the measure is invisible until someone escalates a number.
Coverage counts registrations
How you'd notice: ask what the coverage percentage is a percentage of. The answer is the assets someone added to the catalog.
What it costs: the metric can hold steady while the estate grows underneath it, and leadership reads the flat line as stalled effort.
Changes skip review
How you'd notice: find the last change to a high-impact definition and ask who reviewed it. The answer is the person who made it.
What it costs: every unreviewed change is an audit finding waiting for a sample to land on it.
History lives in email
How you'd notice: ask what a definition said two quarters ago. The answer involves searching inboxes or asking the steward who was there.
What it costs: every audit question about a past period becomes a reconstruction project with an external deadline.
Sensitivity labels stop at the source
How you'd notice: a column is tagged as personal data in the source system. Ask whether the views, extracts, and reports that read it carry the same label.
What it costs: sensitive data spreads through derived assets that no one classified, and access reviews sample the gaps.
The program depends on specific people
How you'd notice: list the definitions whose context sits with one steward. Then ask what happens to them if that person leaves this quarter.
What it costs: turnover resets progress, and the program spends its next year rebuilding what it already knew.
What the Gap Costs
Three costs, and only the first usually shows up on a staffing plan.
The reconstruction cost. Every audit request about a past period, every AI governance review, and every regulatory inquiry gets answered by people assembling evidence by hand. Count the hours from the last three requests. That time comes out of the program's capacity every cycle.
The drift cost. Definitions that diverge between the glossary and the measure produce conflicting numbers, and each conflict costs a meeting, a reconciliation, and some of the program's credibility with the business. The cost grows with every BI tool and every agent added to the estate.
The renewal cost. A program that can't show enforcement evidence renews its tooling on adoption metrics, or spends a year building the case for a change. Either way, the decision gets made on weaker evidence than the program deserves.
A Diagnostic You Can Run This Week
Pick one policy that matters: the definition behind a figure in a regulatory filing, a board-reported KPI, or a classification rule for personal data. Run these six questions against it using the tooling you already own.
Count the passes. The pattern matters more than the score.
Failures in questions 1 and 2 point at a glossary that isn't bound to the estate. Failures in 3 and 4 point at changes that aren't reviewed or recorded as they happen. Failures in 5 and 6 mean the policy stops at the edge of the governance tooling.
Then run the same six against a second policy owned by a different steward. If the scores match, the gap is in how the program connects to the estate. If they differ, it may sit with one domain.
Write the answers down. In a vendor evaluation, they become the list of things you ask to see demonstrated against your own glossary.
What Comes Next
Two things follow from the score.
The first is architectural. Governance tooling can sit in a few places: beside the estate as a documentation system, inside one data platform as that platform's governance features, or on a shared repository that harvests the estate, binds definitions to it, and deploys approved definitions back into the systems that consume them.
Where the tooling sits decides which of the requirements above are reachable. A documentation system can meet the review requirement and struggles with binding and reach.
A single platform's governance features meet several requirements inside that platform and stop at its edge. Most estates run more than one platform and several BI tools.
The second is operational. Every gap above is a decay problem: definitions that matched once, labels that covered the source once, a steward network that was fully staffed once. The work of keeping metadata accurate as the estate changes needs an owner, a lifecycle, and a quality measure.
The name for that practice is MetadataOps: metadata management run as a continuous enterprise operation. Its lifecycle runs Harvest, Model, Version, Compile, Verify. The MetadataOps Kit covers the practice, the lifecycle, and a metadata quality scoring model.
Conclusion
Governance programs are being asked a different question than the one they were built to answer. The artifacts still matter, and the evidence now has to show the policy operating in the systems that compute and consume the numbers, on any date someone picks.
MetaKarta builds that into the Metadata Management Platform. Data Catalog harvests metadata from the estate across 400+ connectors into one shared metadata repository.
Data Governance binds glossary terms to the fields that implement them, runs every definition change through a review and approval workflow, and keeps version history on every object. Data Lineage traces each definition from source to report.
Semantic Hub compiles approved definitions into the native artifacts of the BI tools and warehouses that compute the numbers, so the definition running in production is the one governance approved. Get in touch to learn more about how MetaKarta turns an approved governance policy into evidence you can query on any date.
