Governance is downstream of a name
[originally posted at Engineer of Data Substack]
Last week, I wrote:
Observable Run – every execution leaves a durable, queryable record of what ran, with what, and how it ended.
I called it a pattern.
It is also a door.
Behind it is the question every data team eventually gets asked – by an auditor, a regulator, a new VP, or a 2:00 AM incident:
Can you prove it?
You can describe what your pipelines do. You built them. They run, every night, correctly enough to ship.
But describing is not proving.
- The auditor asks for evidence and you assemble it by hand, after the fact, hoping the logs reach back far enough.
- The VP asks whether last quarter ran clean, and the honest answer is “probably.”
- You can say what a pipeline does. You can’t show what it did – on that day, with those inputs, under whose authority.
- Two environments drift apart, and no one can say when, or who changed what.
None of that is carelessness.
I have been the person opening folders in that meeting, assembling proof by hand while someone waited.
You are not ungoverned because you were sloppy.
You are ungoverned because the work was never named.
Strip the theater off governance and it is one plain capacity: the ability to answer questions about your system with evidence. What ran. With what. Who authorized it. Whether it did what you intended. Whether you can show it.
You cannot answer a single one of those about a thing that has no name.
A nameless estate is ungoverned by default. Not because anyone chose not to govern it. Because governance has nothing to hold.
Software engineering made its systems answerable years ago – provenance, audit trails, change control, signed releases. It could, because it named and structured the work first. Data engineering borrowed the tools and skipped the names. So our estates resist the very questions the business has started to ask.
And it is asking.
Governance was never really about paperwork. It is about ownership, operational consistency, and the trust that rides on both. Every “I think so” in answer to “can you prove it” is a quiet withdrawal from that trust. This is where data programs gain or lose their standing – not in the demo, but in the audit, the incident, the quarter that has to reconcile.
So the move is not to write more documentation about what should happen.
The move is to bind governance to what did happen.
Naming is never the destination.
It’s the precondition.
A name makes a thing inspectable. Inspectable makes it provable. Provable is governance.
You can’t govern what you can’t name.
Governance you cannot prove is governance you cannot trust.
So when they ask you to prove it – and they will – you can answer with a story, or you can answer with the record.
One of those is governance.
P.S. I shepherd SSIS Catalog Compare because this principle demanded a tool – one that inspects an estate and proves what’s deployed against what should be. The tool is downstream of the principle. The principle is the post.
Comments