Your pipeline code lives in version control, so it has branches, a review before anything merges, and a history that answers who changed what. Your metadata gets none of that. The part everyone in the business actually has to agree on usually sits in an application database where branching, review, and history aren’t possible. That gap is why metadata version control is the missing half.

Software engineering settled this argument fifty years ago. Michael Fagan’s 1976 paper on design and code inspections turned code review from a courtesy into a measured practice. The branch-and-pull-request loop that later grew up around version control made it a reflex nobody argues about anymore. Data teams inherited that loop for their transformation code. But they left their definitions, mappings, classifications, and naming conventions outside it.

Metadata version control stands on five properties

The five together turn a model into something you can review like code:

Edits land on a branch, never on the main line directly. When two people work on different branches, neither sees the other’s half-finished thinking. The main line only takes work that’s been through the loop.

Deterministic file paths, at the grain people edit. The layout mirrors the catalog, and every file is named for the thing it describes. A pull request then reads like a map of what changed. Write a 200-column table as a single file instead and every one-column edit rewrites the whole thing. You end up with a diff nobody reads and a history that blames the wrong change.

Identity that survives a rename. Each reference carries a stable identifier alongside its readable name. So renaming a table moves every descendant file in one commit while the references keep resolving. Identity carried by name alone breaks the first time a name changes. And names always change.

A review that shows the exact difference. The reviewer sees before and after for each entity and can drop one change without abandoning the rest. The preview they work from matches what actually lands. Without that precision, a review nobody can read becomes an approval stamp rather than a review.

A commit gated by validation, and a history that answers questions. The validation gate is where your rules earn their keep. Naming conventions are the plainest case. A column name that breaks the agreed pattern fails at the gate rather than three weeks later in somebody’s report. The convention is checked at commit, and the diff shows the name that changed. You can still acknowledge the failure and commit, but the acknowledgement goes on the record.

The history records who changed what, when, and on which branch. That audit trail has to survive deletion.

Warning: Record a delete as a removal and the trail walks out with the object. Mark the object deleted instead, so its history stays. That mark is a suppression.

Where should data governance gates block metadata changes?

A governance requirement isn’t a validation rule, and it should never block you from committing metadata to a branch. When a half-governed draft can’t be saved, people stop saving drafts. The work moves into a spreadsheet, or into a model kept as a picture that never meets a schema.

So where do the governance gates go? Put them on generation, on the approval stamp, and on promotion to the main line. Those are the points where an incomplete model can cause real harm.

Nobody should ever be blocked from writing down what they just learned.

The alternative is a database nobody can diff

Metadata that lives only in application tables, updated in place, can’t tell you what it looked like in June. Nor can it show a reviewer a change before that change is already live. Because it can’t be branched while somebody thinks, two people editing the same subject area either take turns or collide.

Every data governance program built on that foundation ends up rebuilding half of this loop by hand, through change-request forms and screenshots pasted into tickets. That’s the cost of the missing loop, paid in process instead of in code.

Text files in a repository aren’t the sophisticated answer, but they’re the one that closes the loop. An auditor can read exactly what changed. A modeler can propose a definition without breaking anyone’s afternoon. When a rename goes wrong, you drop the change in review before it lands, and the Git history keeps the record.

The Data Lakehouse for Everyone answers three questions in Lineage, governance, and trust before go-live: where the number came from, who’s accountable for it, and what changed and who agreed to it.

This week, ask two questions about your own model: what did this definition say in June, and who approved the change? If the honest answer is a shrug, the review loop is what’s missing. And adding it doesn’t require anyone’s permission.

In DeltaVault, edits land on a branch, Review and Commit shows before and after for each entity, and a validation rule can block the commit until it’s acknowledged.