What separates the strong data governance examples from the weak

Governance is mostly a set of small written artifacts. People imagine a program and end up with a policy document, when what actually changes behavior is a dozen short records that anyone can find and read.

This page shows twelve of them as skeletons. Every value in the examples is invented; the point is the fields, not the content.

What to take away

1. A concept definition

The single most useful artifact. One per governed concept.

The excluded row does more work than any other. Most definitional arguments turn out to be arguments about exclusions that nobody had written down. A general data dictionary does the same job at field level, and the concept definition sits above it in business language.

2. A change notice

Sent before the change, not after.

Concept, what is changing, why, the date it lands, whether history is restated or the change applies forward only, who to contact, and the one chart or report most likely to move. Five lines. The last line is what makes people read it.

3. An access role

Not a list of people. A role with a purpose.

4. A data quality test

One line of intent, one line of implementation, one line of what happens when it fails.

The intent line is the one people omit and the only one that survives a rewrite of the implementation. Something like: no completed order should exist without a matching customer record.

5. An incident record

What broke, when it was noticed, how it was noticed, what the reader saw in the meantime, and what changed as a result. The blameless postmortem format from operations transfers almost unchanged, and the useful field is how it was noticed, because too often the answer is that a reader told you.

6. A lineage note

For a governed concept: which sources feed it, which transformations touch it, and which published artifacts depend on it. Kept as a short list rather than a diagram, because a list stays current and a diagram does not.

7. A retention entry

How long the data is kept, in what form, and what happens at the end. Public records bodies have solved this shape already, and the structure of a records control schedule is a reasonable template: a class of record, a retention period, and a disposition action.

8. A deprecation notice

Attached to the artifact itself rather than sent by email. Names the replacement, the date the old one stops being maintained, and the date it disappears. Two dates, because people need a window in which the thing still exists but carries a warning.

9. An exception register

Every governance rule gets broken somewhere for a real reason. Record the exception, the reason, the owner, and a review date. Unrecorded exceptions become the rule within about a year.

10. A dispute record

Two definitions in use, the two owners, what was decided, by whom, and on what date. Short and mildly uncomfortable to write, which is why it works: it makes the cost of not deciding visible.

11. An ownership handover

When an owner changes role, one record: concept, outgoing owner, incoming owner, date, and open items. Without this artifact, concepts become unowned silently, and the discovery happens during an incident.

12. A review log

For each governed concept: date reviewed, reviewer, outcome. Three columns. Its purpose is to show which concepts have not been looked at in two years, which is information nobody else in the organization has.

How these fit together

The first three are the working set. A concept definition says what a number means, a change notice says when that meaning moved, and an access role says who can see the data behind it. Everything else supports those three.

A useful test: pick any published number and try to walk from it to a definition, an owner, and a date it was last reviewed. If you cannot do that in two minutes, the artifacts either do not exist or are not findable, and findability is the same problem as existence here.

Related reading on this site

The reasoning behind these artifacts is in data governance. Their failure modes are in nine governance mistakes. Artifact one's metric definition is in writing a metric definition.

The publication promise that decides how much of this a given artifact needs is in the three publication tiers. The reporting discipline that consumes these records is in building a report worth keeping.

Common questions

Where should these live?

Wherever people already look, even if that is imperfect. An artifact in the right system that nobody visits is worse than a plain page in the place your team actually reads.

Twelve artifacts sounds like a lot of overhead.

Nine of the twelve are written once per concept or once per event. Only the review log and the exception register need regular attention, and both take minutes.

Do we need a tool for this?

No. Every one of these works as a plain document with a table. Buy a tool when the number of concepts makes finding them hard, which is later than most people expect.

What if nobody will agree to be an owner?

Then name the person who would have to change what they do if the definition changed, and tell them they are the owner. Ownership is rarely volunteered and is usually accepted once it is stated plainly.