In March, someone updated the definition of active customer. They had a good reason. The old definition counted accounts with any login in 90 days, and the product team wanted it scoped to accounts with a billable event.
They made the change in the catalog UI. It took forty seconds.
In June, the quarterly retention deck showed a trend the team couldn't explain. It took two engineers a week to work out that the metric had been redefined in March, and a further three days to establish what the old definition actually said, which they eventually recovered from a Slack thread and a screenshot.
Nothing about that failure is exotic. It's the ordinary consequence of a layer that never got an operations discipline.
Every other layer got a deploy step
Look at what happened to the rest of the stack over the last fifteen years.
Application code got version control, code review, and a deploy pipeline. Infrastructure got declarative configuration and a state file, so a change can be planned, applied, and reverted. Transformation logic got tested, versioned, and promoted through environments. Even schema migrations got a framework with an up and a down.
The pattern is the same everywhere: a change is proposed, reviewed against what's already there, applied to a lower environment, verified, promoted, and reversible if it goes wrong.
Metadata skipped all of it.
In most organizations, a business definition is edited directly in a production interface by whoever has permissions, applied instantly, with a change record that captures who and when and rarely captures what.
Those definitions govern financial reporting. They increasingly govern what AI systems tell people. And they're the one artifact in the stack with no deploy step.
Four operations metadata usually lacks
Diff. Given a definition today and the same definition six months ago, show what changed. This is the question every audit eventually asks and the one most tooling answers with a timestamp.
Environments. A place to make a definition change and observe its effects before it reaches production reporting. Analytics engineers have this discipline for transformation code. Definition changes bypass it entirely and land straight in production.
Impact analysis ahead of the change. Which reports, models, and downstream systems consume this definition today, and what breaks if it moves. Run afterward, this is forensics. Run first, it's a review, and it's the difference between a change that ships with a known blast radius and one that ships blind.
Rollback. Return the definition to its previous state, with the same confidence you'd revert a bad deploy.
Any team that has run a production system will recognize all four as table stakes. The gap is that metadata has been treated as documentation, and documentation gets edited. Infrastructure gets deployed.
Why the tolerance for this ran out
For most of the last decade, the cost of a silent definition change was bounded. A human looked at the report, noticed the number was odd, and asked someone. Slow, expensive, and survivable.
Two things changed that.
Agents now query the same definitions, and they don't find numbers odd. A system asked for active customers retrieves whatever the current definition returns and reports it with the same confidence it reports everything else. The human check that used to catch drift has been removed from the path.
And regulated reporting now asks organizations to demonstrate how a figure was produced. Demonstrating it for the current quarter is one problem. Demonstrating what a definition meant two years ago, and proving nothing changed since, is a different problem entirely, and it's the one that arrives with a deadline attached.
Both pressures point at the same missing capability. When the human in the loop disappears and the evidence bar rises at the same time, the ability to show what a definition said, when it changed, and who approved it stops being hygiene and becomes the control itself.
What the operated version looks like
An operated estate puts its definitions under version and configuration management across development, test, and production environments, the same way it already treats transformation code.
In practice that means a definition change is made in a lower environment, reviewed against the current production state, and promoted deliberately. Every change is logged, attributed to a person, timestamped, and reversible. Impact analysis runs before promotion, so the set of affected reports and downstream systems is known while the change is still a proposal.
The March scenario becomes unremarkable under that model. The definition change appears in a change history with an author and a date. The previous definition is retrievable in full. The list of reports affected was produced before the change shipped, and the retention deck was on it.
This is also what makes MetadataOps a fair name for the practice. Ops implies a lifecycle: a build, a test, a deploy, a diff, and a rollback. Applied to metadata, those are the same five operations that every other layer of the stack already takes for granted.
Where to start
Pick one business definition that has changed in the last year and try to answer three questions about it.
What did it say before. Who changed it. Which reports were affected at the moment it changed.
If those answers take more than a few minutes, or if any of them come from a Slack thread, that's your finding. It's also the most concrete version of the problem you can put in front of a data leadership review, because everyone in the room has lived the June version of it.
