You've shortlisted. The platforms that made the cut passed the coverage, binding, and review tests in Which Governance Platform Can Show Your Policies Operating?, and now one or two of them get your glossary and a slice of your estate for a few weeks.
This guide covers that POC. It walks through five workflows where governance carries production weight in a large estate, what the governance team does in each one, the number to record, and what sits underneath all five.
Trusted BI. Reliable AI. Defensible governance.
Those are the outcomes on the table, and every one of them depends on a policy you can show operating when someone asks.
Before the first harvest
A POC that starts without scope turns into a feature tour. Settle four things in writing before any connector runs.
Scope. Name one policy that matters, such as the definition behind a figure in a regulatory filing, and every system in its path, including the oldest one. Then add the artifacts the workflows below need: an export of your current glossary, one executive Power BI or Tableau report, a term your glossary and your BI tools disagree on, a column classified as personal data, and an AI use case in pilot. Check every system against the Connector Explorer before the kickoff call.
People. You need the governance lead who owns the policy, two stewards who will run the review workflow, your data architecture lead to validate the platform design, someone from internal audit, and the person who signs off on the result. The data architecture lead is the one most often added late, and the evaluation slows down every time an architecture question waits for them.
Baseline. Record today's numbers before MetaKarta touches anything: hours to answer the last audit request about a past period, the coverage your current tooling reports and what it's a percentage of, how long the last definition change took from proposal to publication, and how many open policy exceptions sit in your tracking spreadsheet. Every workflow below ends with a number, and a number needs a before.
Exit criteria. Agree on the timeline and on what passing means for each check in the scorecard at the end of this guide, then get the sign-off owner to initial it. Put the renewal date of your current tooling on the same page. That page is what the business case gets built from.
How the program gets built
Everything in this POC lives on one shared metadata repository. Data Catalog harvests metadata from the source systems across 400+ native connectors.
Data Governance holds the glossary, the policies, the stewardship roles, and the workflow. Data Lineage computes column-level lineage by parsing the code that moves the data, and Semantic Hub compiles governed definitions into the systems that consume them.
The glossary is a custom model in that repository, so its terms, hierarchies, and relationships can be customized to match your program. Steward and workflow roles are assigned as responsibilities, and they inherit down the glossary hierarchy.
When workflow is enabled, the repository keeps a Published version of the glossary that most users see and a Development version where changes are drafted and reviewed. Hold onto that detail for the audit workflow below.
Bringing the program across
The trigger. The renewal of your current tooling is on the calendar, and the question in the room is what happens to the glossary, the steward network, and three years of program work.
The workflow. Import the glossary export as CSV or an Excel workbook. Legacy attributes convert on the way in: a Stewards attribute becomes the Steward object role, Status and State become workflow state, Definition becomes Description, and abbreviations become acronym terms. Import the terms file before the relationships file.
Then check what came across. Steward assignments inherit down the hierarchy, so a steward assigned at the domain level owns every term beneath it. Watchers receive notifications when objects change.
For domains your current glossary doesn't cover yet, Bootstrap from model creates terms from a well-documented harvested model, with term classification or semantic mapping links back to its data elements.
What the repository adds. Imported terms land in the same repository the catalog harvests into, so binding them to the estate is the next step on the same record.
The number to record. Import fidelity: the share of terms, relationships, and steward assignments that arrived intact, against the counts in your export. Record beside it the hours spent on manual cleanup.
Audit and compliance
The trigger. Internal audit names a reported figure and a closed quarter, and asks what its definition was then, who changed it since, and who approved the change.
The workflow. Enable workflow on the glossary and assign the Workflow Editor, Reviewer, Approver, and Publisher roles to the stewards in scope. Then make a real change: draft a correction to one term, start the review, have a second steward recommend approval with a comment, and approve and publish it.
Before approving, open Review Changes. It shows a table of differences between the published definition and the one under workflow, so the approver signs off on the change itself.
Now answer the audit question. The History tab on the term records every change with its author and timestamp. Compare Metadata between the configuration versions returns additions, changes, and removals side by side, color-coded.
The audit answer is a query.
What the repository adds. The lineage behind the definition versions with it, so the answer to "what did this mean last quarter" comes with the sources and transformations it read last quarter.
The number to record. Hours to answer one audit-style request about a past definition end to end, against your baseline.
Policy reaching the BI tool
The trigger. The glossary defines a metric one way, the Power BI measure computes it another, and the gap surfaced in a quarterly review.
The workflow. Start with coverage. On the executive report you chose, More Actions and Open Business Glossary returns the glossary term behind each field, with every undefined field listed.
Then bind the disputed term to the fields that implement it through term classification or semantic mapping. Definition lookup traces from the measure to its term, semantic usage traces from the term to every asset that depends on it, and Show Term Definitions puts the glossary definition beside the data flow. Follow the measure back through the BI model and the SQL, and the expression where it parts ways with the glossary is on screen.
Correct the definition through the workflow, then compile it. Ontology Modeling in Semantic Hub binds the term to the governed metric, and Semantic Hub compiles the metric into the native Power BI semantic model.
Policy applied where the data is used, versioned where it changed.
What the repository adds. The term, its bindings, the steward's approval, and the compiled metric are one record, so the definition running in the dashboard is traceable to the decision that approved it.
The number to record. Coverage of the executive report, measured against its actual fields, before and after binding. Record beside it the time from the disputed number to the diverging expression on screen.
Sensitive data
The trigger. A column holding personal data is classified in its source system, and an access review asks where else that data lives.
The workflow. Run data sampling and profiling on the source. Data classification proposes sensitivity labels as Sensitivity Label Data Proposed. Lineage then infers labels downstream through every data flow, as Sensitivity Label Lineage Proposed, across views, extracts, and reports.
A steward reviews each proposal and approves or rejects it. A rejection stops the inferred label from propagating further in that direction, and data masking detected in the ETL stops it too.
What the repository adds. The label, the lineage that carried it, and the steward's decision sit on the same objects the catalog shows and the policy governs.
The number to record. Downstream assets labeled from one classified source column, against the count your current tooling shows for the same column.
AI context and governance
The trigger. A text-to-SQL pilot works in the demo and stalls at the model risk review, because the program can't show which definitions the agent read or whether governance approved them.
The workflow. Bind the glossary terms the agent will use to the semantic model through Ontology Modeling, so each concept arrives at the agent attached to its approved definition.
Every concept is bound to a real asset from day 1.
Validate before anything ships. In Context Sandbox, run the pilot's business questions against the governed context, compare outputs with approved reference answers, and inspect which definitions supported each result.
Test the claim yourself, on your data, with the grounding visible.
Then serve it. A model deployed as a Snowflake semantic view is read natively by Snowflake Cortex Analyst. External agents connect to MetaKarta MCP, whose Semantic Hub Tools serve compiled context with per-user access tokens, so an agent surfaces only what its user may see.
What the repository adds. Lineage traces from the governed definition the agent consumed back to the source columns, which is the evidence the model risk review asks for.
The number to record. For the pilot's test questions, the share of answers that come back with the governed definition and its approval record attached.
What sits underneath all five
The trigger. This one usually surfaces at renewal, when someone adds up what it costs to keep a catalog, a governance workflow tool, a lineage tool, and a semantic product in agreement.
The workflow. Data Governance, Data Catalog, Data Lineage, and Semantic Hub read from and write to one metamodel. A sensitivity label applied in governance shows in lineage, the catalog entry, and the compiled definitions that depend on the column, with no sync step between them.
Compare that with the common production architecture, where each tool keeps its own metadata store and its own model of what a term is. Reconciling them is standing work that grows with every system added.
Documentation describes what should be true. Compilation makes it true.
The number to record. Integration hours: the sync jobs, exports, and reconciliation spreadsheets from your baseline that the POC estate ran without.
The POC scorecard
Six checks across the five workflows. Run them on your glossary and your estate, with your oldest system included, and fill in the last column from your baseline.
Weight the policy-reaching-BI check most heavily. A glossary definition landing intact in the report your CFO reads is the most legible evidence that the policy reached the estate, and it's the hardest of the six for an assembled stack to produce.
What one governed definition is worth in production
Every workflow in this guide runs on the same record: a glossary term bound to the fields that implement it, changed under review, versioned as it changes, and compiled into the systems that compute the numbers. That's why one record answers the auditor, settles the disputed number, follows the sensitive data, and grounds the agent.
MetaKarta is the Metadata Management Platform built on that repository. Meta Integration Technology, Inc. has spent nearly 30 years building the metadata connectors other vendors ship inside their own products, embedded as the OEM engine in Microsoft Purview, Informatica from Salesforce, IBM, Oracle, and Qlik Talend.
Data Governance, Data Catalog, Data Lineage, and Semantic Hub share one metadata repository, so the program you run today carries forward with its stewards, its glossary, and its history intact. Get in touch to learn more about running a governance POC on your own glossary.
