What is data governance?
Data governance is the set of rules and accountabilities for how an organisation's data is managed: what exists, who owns it, who may use it, how much it can be trusted, and how long it lives.
In DataHub it is not a separate module with its own login. It is assembled from pieces you already know: the knowledge graph, data sets, policies and functions each carry one part of the job.
The five questions governance answers
Strip away the committee language and governance is five questions, asked of every piece of data an organisation holds:
| Question | What it is really asking |
|---|---|
| What do we have? | An inventory: the data, what it means, and what it relates to |
| Who is accountable for it? | A named owner per body of data, not a shared inbox |
| Who may use it? | Access, granted deliberately and reviewable |
| Can we trust it? | Where a figure came from, and in what condition |
| How long does it live? | Retention, expiry, and a defensible answer to "why do we still have this?" |
Most organisations can answer all five, in the sense that the answers exist somewhere: a register spreadsheet, a policy manual, an access matrix, a retention schedule in a PDF. The governance failure is rarely missing answers. It is that the answers live apart from the data they govern, so they are invisible at the moment someone actually touches the data, and they drift out of date without anyone noticing.
The whole DataHub approach to governance follows from one move: put each answer on the thing it governs.
How the pieces carry it
The knowledge graph: what we have, and who is accountable
You cannot govern what you cannot find. The knowledge graph is the inventory question answered continuously: every resource, series, event and document, named, classified and connected, instead of a register spreadsheet that was accurate the month it was written.
It also carries ownership, because accountability is a relationship like any other. The business knowledge layer connects data to the unit, role or person answerable for it, so "who owns this?" is a traversal, not an email thread.
Data sets: who may use it
Data sets are the unit of access. Deciding what goes in which data set is the access decision, and the permission model enforces it, with read and write granted independently. Reviews become tractable because the boundary is explicit: a quarterly pass over data set grants is a real control, a quarterly pass over "who can see what, across eleven systems" is not.
The same boundary governs what leaves continuously: a subscription is a standing delivery from a data set, so a grant is also a decision about what streams out, and a durable subscriber deserves its own narrowly-scoped service account.
Policies: the rules, recorded where the data lives
Policies put the retention rule, the access intent and the requirements on the data set they govern, findable by whoever opens it, instead of in a manual nobody consults. Recorded today; enforcement, rules the platform acts on automatically, is on the roadmap, which is exactly the right order: writing the rules down well is the slow, human part, and it can start now.
Functions: trust in derived numbers
Most governance frameworks obsess over stored data and ignore the computations, which is backwards: the numbers people act on are nearly all derived. Functions are where computation comes under governance: one sanctioned definition recorded in the model instead of four private spreadsheet variants drifting apart, and once execution ships, also the definition that runs. They are where lineage will accrue automatically, turning "can we trust it?" from an opinion into a walkable trail.
And underneath all four
Two disciplines make the pieces work, and both are governance even though neither looks like it:
- Naming and identifiers. Stable external ids and agreed conventions are what let the same thing be governed as one thing across systems, and a naming policy is how the convention stops being a document nobody reads and starts being a rule the platform applies.
- Contextualization. An ungoverned record is usually just an unlinked one; connecting data to what it describes is what brings it under governance at all.
Rules that act, not just rules that are recorded
A governance rule earns its keep at the moment somebody would otherwise break it, which means enforcement, and enforcement has four moments where it can happen.
Every rule has a cheap moment and an expensive one. Refusing a badly formed identifier as it is written costs nothing. Finding twelve thousand of them two years later, after they have been quoted in reports and wired into interfaces, costs a project. The whole value of putting rules on the data is that it makes the cheap moment available.
| Moment | What a rule can do there | Where that stands |
|---|---|---|
| At the write | Check the identifier against the convention, refuse it or raise a finding | Enforced today: naming policies run on every write |
| While it sits | Check the data is still fit: owner named, description filled, review not overdue | Recorded as a requirement policy; nothing checks it |
| At the read | Decide who may see it, and on what terms | Reads are gated, but by organization groups, not by a policy record |
| At the end of life | Expire what is past its retention, keep what is still owed to an auditor | Retention is recorded; nothing expires yet |
Only the first row acts on its own today. Lifecycle, access and requirement policies are declarative records, and enforcement is planned alongside measurement expiry. What is enforced and what is recorded →
Write the rule so that something could enforce it
Whatever enforces a rule in the end, a platform feature or an agent or a person with a checklist, all three need the same thing from it. A rule has to say what to check, on what, and what happens when it fails.
- Name the field, not the intention. "Descriptions must be meaningful" cannot be checked by anything at all. "Every resource of type Pump carries a description and a named owner" can be checked by anything, including a person in ten minutes.
- Give it a consequence. Refuse, flag for review, or notify a named role. A rule with no stated consequence is an opinion, and it will be treated as one.
- Keep the obligation next to it, so a successor can revisit the rule safely when the obligation changes. Writing a policy worth having →
The pleasant surprise is that a rule written this way is enforceable now, by something the platform did not have to ship.
The policy agent
A rule that names its subject, its test and its consequence is a rule an agent can carry out. So give it one: a policy agent is a single agent handed a single rule, with the tools to read that policy off the data set, walk the knowledge graph for everything the rule governs, compare each one against it, and raise a finding on whatever fails with a drafted correction attached.
One rule per agent, rather than one agent for governance, is what makes it reviewable. You can point at the rule it enforces, at the findings it raised, and at the ones it was wrong about, and change any of the three independently.
What makes this more than a scheduled query is the class of rule it can carry. A script can check that a description exists. An agent can judge whether the description says anything, whether a data set's membership still matches the purpose written on it, whether an owner who left the company is still named, whether two resources are the same pump entered twice. Those are the governance failures that actually accumulate, and every one of them is a judgement rather than a test.
Four things to hold on to before you point one at your data:
- It is a detective control, not a preventive one. An agent finds a breach after the fact; it cannot stand in front of a write the way a naming policy does. That is fine for most of governance, where finding out within the hour is a transformation on finding out next quarter, and it is not fine for anything where the damage is done at the moment of writing.
- It proposes, a person disposes. A policy agent must never close its own finding. The control is that somebody looked, so an agent that quietly resolves findings has removed the control rather than satisfied it.
- It runs inside the ordinary limits. Scope of data, tools it may call, actions it may take, and a log of what it did. The four limits worth setting →
- The rule stays the artefact, the agent is only the enforcer. When platform enforcement ships, the rules are already written and reviewed, and the agent hands that rule over rather than being rewritten around it.
Because both the policy and whatever enforces it are nodes in the model, "which rule governs this series, what enforces it, and when did it last run?" is a traversal rather than an email. That is the same structure the policies page draws, with an agent standing in the enforcer's place.
What this changes in practice
| The usual version | The version where rules live with the data |
|---|---|
| A data register, updated annually, stale by March | The graph is the register, current because it is used |
| Access reviewed by interviewing system owners | Access read off data set grants in one pass |
| Retention schedule in a PDF, applied by memory | Retention recorded per data set, enforced when expiry ships |
| "Where did this figure come from?" answered by whoever built it | Answered by the model, and eventually by the lineage trail |
| Governance as a committee that meets quarterly | Governance as properties of the data, reviewed quarterly |
The committee does not disappear, someone still decides the rules. What disappears is the gap between deciding a rule and the rule being visible where the data is touched.
Who does the work
Governance fails most often by being everyone's job, which makes it no one's. The data steward role carries it here: naming conventions, data set boundaries, policy quality, and the quarterly reviews. A few hours a month once the conventions are set, and the single strongest predictor of whether the model stays coherent.
Do not launch a governance initiative. Pick the one data set behind your most regulated report, name its owner, record its policies, and review its access. That is governance, running, on the data where it matters most, and it took an afternoon. Widen from there, data set by data set, the same way the model itself grows.
Where agents help
Governance fails between reviews rather than during them. An agent can run the checks continuously instead of quarterly: resources with no owner, data sets whose membership drifted from their stated purpose, series that stopped reporting, documents attached to equipment that no longer exists.
The shape that suits this work is one agent per rule rather than one agent for governance, which is worth reading before building either. The policy agent →
Whichever way it is scoped, it produces a queue of findings, each attached to the thing it concerns, and a person decides what to do about them. That division matters, because governance decisions are political as often as they are technical. Building AI agents →
- Data sets: the access boundary
- Policies: recording the rules today
- Functions: governing computation, not just storage
- Lineage and data quality: the trust question, and what is planned
- Who does what: the steward role that carries this
- Data lifecycle: retention and expiry, the "how long" question
- Building AI agents: what a policy agent is built out of, and the limits any agent runs inside