A new metadata function usually stalls in the same place. It has the mandate, the access, and a scored estate, and it's waiting on someone to say what active customer means.
Everyone assumes governance will supply that. Governance assumes it already did, in a document written two years ago and unopened since.
The default placement in this Kit puts execution with the platform or data engineering team and the Model stage with governance. That split only works if the seam between them is written down, and in most organizations it never is.
Requirements, not tickets
The productive framing is one an engineer already knows. Governance supplies definitional requirements. MetadataOps implements them and reports back what implementing them revealed.
A definitional requirement has four parts, and a request missing any of them goes back:
- The concept, named. Active customer, net revenue, billable event.
- The rule, in business terms. Precise enough that two people reading it would count the same population.
- The named owner. A person who would answer the phone today, not a committee and not a role that's currently vacant.
- The consumers that matter. Which reports or obligations this definition has to satisfy, because that determines what breaks when it moves.
What comes back is a bound definition, a list of the physical assets that implement it, and the conflicts discovered on the way. The conflicts are the valuable half. Implementing a definition is how an organization finds out it had three.
Who decides what
Write this table down once and the argument stops recurring. The rule underneath it: governance owns meaning, MetadataOps owns mechanism, and neither overrides the other inside its own column.
DecisionGovernanceMetadataOpsWhat a business concept meansDecidesImplements and binds itWho the named owner isDecidesRecords it and holds them to itWhich policy applies whereDecidesEnforces it in the estateWhether a definition change shipsApproves the meaningApproves the blast radiusWhich physical asset implements itConsultedDecidesWhich systems the definition compiles intoInformedDecidesWhat the completeness score isInformedOwns and reports itWhen a definition is retiredDecidesExecutes and confirms no consumer remains
The row that surprises people is the change approval, which is split. Governance approves that the new meaning is correct. MetadataOps approves that the estate can absorb it and the affected consumers have been told. Either one can hold the change, for different reasons, and both reasons are legitimate.
Three ways the seam fails
Governance has no write access and gets treated as advisory. Requirements arrive as opinions, the engineering team implements what's convenient, and the governance program discovers six months later that it documents an estate it doesn't control. The fix is procedural: no definition ships without a recorded governance approval, and the approval is a field in the change record rather than a message in a thread.
Governance answers slowly and the engineer proceeds anyway. The most common failure, and the most understandable. A definition is needed this sprint, the working group meets monthly, so the engineer picks the reading that matches the current code. That's how a shadow definition gets born inside the governed layer. The fix is a service commitment in both directions, covered below.
The owner cannot be named. The requirement arrives with a team name in the owner field. A team cannot answer a question about intent. When this happens, send it back once. If it comes back the same way, escalate it as a finding rather than absorbing it, because an unowned definition is a governance gap and recording it as one is what eventually gets it filled.
What each side commits to
Governance commits to a named owner per definition, a decision within a stated window on a definitional question, and notice before a policy change that alters what a definition has to satisfy.
MetadataOps commits to implementing an approved definition within a stated window, reporting every conflict found rather than resolving it quietly, publishing the impact list before a change ships, and giving governance the completeness score with its denominator on a fixed schedule.
Both sets are conditional on the other, which is why they get written down together and why this works as a standing interface rather than a queue.
When the definition is genuinely contested
Some questions have no answer waiting to be looked up. Two teams have used the same word differently for years and both are right within their own scope.
That's a distinct problem with its own resolution path, and it does not belong in the requirements flow. Route it out: the page on contested words covers what to do, and the short version is that picking a winner is the wrong move.
What matters for the interface is that a contested definition gets labeled as contested rather than sitting in a queue looking like a slow answer. The label tells the engineer to stop waiting.
If there is no governance function
Plenty of organizations running this practice have no governance team at all. The interface still exists; it just terminates somewhere else.
Find the person who would be asked in a dispute. For revenue it's usually someone in the finance close. For customer counts it's usually product or RevOps. Name them as the owner of that definition, in writing, and get their acknowledgment.
That's a lighter arrangement and it holds fine at small scale. What it can't do is resolve a conflict between two named owners, which is the moment an organization discovers it needs the governance function it has been doing without.
Set it up in one meeting
Four questions, one hour, with whoever holds governance today.
Who supplies definitional requirements, and in what form. What is the turnaround commitment in each direction. Who approves a definition change, and is it split. Where does a contested definition go, and who breaks the tie.
Write the answers on one page and circulate it. An interface that exists on a page survives the first disagreement. One that exists as a shared understanding does not.
Written by the team at MetaKarta and released under CC BY 4.0: free to use, adapt, and republish with attribution.
