Change Orders for Data: What Capital Projects Know About AI Governance

In most enterprises, anyone with edit access can change what “customer” means. No signature, no impact assessment, and no record of what it used to mean.

Before I came to data, I spent five years implementing project controls software for Energy, Mining, and Construction clients. Budgets, contracts, change, and risk. Every system I built answered three questions:

• Is the project on budget?
• Is it on time?
• What changed since we last agreed?

When I joined The Modern Data Company just over a year ago, I recognized this problem in my first month. Capital projects already have a name for the fix: the change order.

Back to basics: why change orders exist

A change order is a formal record that the agreed scope, cost, or schedule of a project has changed. It captures five things: what changed, why, who approved it, what it costs, and what it touches.

It exists because nothing on a project stands alone. Push a concrete pour back a week, and the steel crew can't start, the crane sits idle while the rental clock runs, and the next delivery has nowhere to land. One change, many dominoes. Oil and gas runs the same logic: a well that blows past its approved budget doesn't just get more money. It gets a supplemental AFE, with a reason, a number, and a signature.

So project controls doesn't stop at “can we make this change?” It asks, “What does this change set off, and who needs to agree before it does?” That isn't bureaucracy. It is how a project keeps one version of the truth while hundreds of people make decisions at once.

Data has the same dominoes, but no change orders

Enterprise data is a capital project that never closes. Its domains depend on each other the way trades on a job site do. Change what “active customer” means in sales, and churn in finance, eligibility in risk, and targeting in marketing all shift with it.

Most of the time, those changes never get recorded. Not because everyone is careless, but because nothing asks them to. A merger brings in a second customer model. An analyst edits a metric in a dashboard tool. A source system renames a field. Every one of those changes makes sense where it happens. Together, they drift.

For years, people quietly absorbed that drift. The reconciliation teams. The workarounds everyone knows about. The one person who knew which number to trust. I hear about this person in almost every discovery call. That human buffer was the change control process all along. We just never called it that.

AI removes the buffer. An agent reads a definition and acts on it at machine speed. It does not notice that last quarter's revenue logic was different, and it does not pick up the phone to ask finance, either.

The interim Modern Data Report found that 57% of organizations are already piloting or running AI agents, while only 8.4% trust the data behind their AI enough to put into production. That gap is what uncontrolled change looks like at scale, and I'd bet a lot of that gap is drift nobody recorded.

Canonical model versioning is a change order for a definition

Data already has a discipline for it: canonical model versioning. Canonical model versioning is a change order for a definition. A canonical model is the shared definition of a core business entity, like customer, asset, or contract, that every system agrees to. It doesn't force sales, finance, and support into one meaning of "customer". Each of them is right for its own job. It names those meanings clearly, gives each one an owner, and links them so everyone knows which definition answers which question.

Versioning it means nobody edits that definition in place. A change produces a new, approved version, and the old one stays available until everyone who depends on it has moved. It is the same discipline as a change order, applied to a shared definition instead of a scope of work.

The parallel matters because it changes the question leaders ask. Not “is our data governed?” but “what is our baseline, who owns it, and how does it change?”

Five disciplines to borrow from the job site

1. Set a baseline before you govern anything. Project controls start with an approved budget, because you can't control change against nothing. In data, pick the handful of definitions your first agent will rely on, and publish them as version 1, each with a named owner each.
2. Tier your changes. On a project, not every change goes to the board. Small shifts within the project manager's delegated authority stay with the project manager. Anything that moves cost, schedule, or contract goes up. Do the same with definitions. A description fix is routine. A change to calculation logic needs the owner's sign-off, with affected domains consulted. Changing how records are identified, or what a single record represents, is a breaking change and needs a migration plan.

1. Assess impact before approval, not after. A change order without an impact assessment is just a wish. In data, lineage is where your impact assessment starts. It shows which products, dashboards, and agents will feel the domino effect before it falls.
2. Run versions side by side. A revised baseline never erases the original; You keep reporting against both until the variance is understood. Let consumers, especially agents, pin to a version and move on purpose. An agent should never wake up to a different definition of “customer” than the one it was tested on.
3. Read the change log as a risk signal. On projects, the change order log shows you where scope creep is coming from. In data, the definitions that change most often are where AI is most likely to break. That is where your testing and your owners should go first.

Start where you are

None of this needs a rebuild. When I implemented project controls software, clients almost never got a clean start. Projects were already underway, with crews on site and money committed. Nobody stopped the work to introduce change control. They added a process over the work already underway.

Data is no different. Leave the systems that work in place. Add a governed layer of shared definitions over them, version those definitions, and put every change through the five questions a project controls team would ask: what changed, why, what does it touch, what does it cost, and who approved it?

I am still learning the data world. But I have watched enough projects to know this: the ones that finish on budget are the ones with no changes. They're the ones where no change goes unrecorded.

So here is my question for you: What definition in your business changed last quarter, and who signed off on it?