Module 5 · The Systems & Data Layer · Chapter 23 of 32
Data Governance and Quality
Ungoverned data does not just hand you a wrong number; it lets someone change what a number means without anyone noticing. Governance is the change process and the stewardship that keep the data model trustworthy while it keeps changing.
10 min read
Someone once handed me a list of 167,699 accounts and asked me to delete the junk. The org had swallowed years of imported lists, trade-show scans, and half-finished enrichment, and the request was reasonable on its face: the database was full of records nobody trusted, so clear them out. Before touching anything I ran a pilot on 803 accounts a prior audit had already flagged as bad. Exactly one of them cleared the bar to delete. The other 802 had a contact attached, or an opportunity in their history, or a case, a signed contract, ARR, a child account, or a live portal login. Delete any of those and you do not clean the database, you punch a hole in the pipeline, the renewal, or the audit trail, and you find out weeks later when a number moves and nobody can say why.
That pilot reset how I think about the whole discipline. Governing a live data model is not a cleanup sprint, and removal is not the primary verb. The last chapter, Integrations and the RevTech Stack, picked a system of record and wired the stack to sync to it. That decision comes with a bill this chapter has to pay: a synced stack propagates a wrong value faster than a siloed one ever could. Governance is what keeps the thing you sync worth syncing.
The operating mechanics of quality (the five areas I actually govern, the entry-time validation that catches a bad record for free, and the operating metrics I put on a monthly dashboard) live in the CRM and data governance reference. This chapter sits one layer above that loop. It is about the two things a reference article cannot script for you: how the data model changes without breaking, and who, or what, is allowed to change it.
The data model is a contract, and contracts have a change process
Back in The Data Model and The Metrics Spine we agreed on a standardized, tool-agnostic structure: the Bowtie, instrumented with volume, conversion, and time metrics. Revenue Architecture is blunt about what happens next. Once the data model is agreed, adherence to it has to be enforced through a change-request process reviewed by someone who understands the model, because a change to the data model is a change to the numbers a company is valued on. That is the part most teams skip, and it is the part that quietly does the most damage.
Here is the failure I have watched happen more than once. Someone decides the rule that stamps an SAO date is too strict, or that “Segment” should mean something slightly different, and they change it in an afternoon. No dashboard breaks that day. But every conversion trendline built on that definition now bends, and three weeks later a funnel metric moves in a board deck. The number did not move because the business changed. It moved because a definition changed, and now nobody can tell the two apart. A definition change disguised as a field edit is the most expensive edit in the org precisely because it leaves no fingerprints.
So a definition change does not happen in the field. It happens in a process.
- 1
1. Propose the change in writing
Name the field or definition, state what it will mean after the change, and say why. A definition change is a proposal, not a keystroke, so it never starts as one.
- 2
2. Map the blast radius
List every VM, CR, and Δt on the Bowtie that depends on it, then the dashboards, comp plans, and board metrics downstream. Redefining what stamps an SAO date moves every funnel trendline sitting on top of it.
- 3
3. Route to the model steward
One named owner of the data model reviews it, because the framework treats a data-model change as a valuation change, not a cosmetic one. The steward is allowed to say no.
- 4
4. Version and communicate
Set an effective date, decide whether to restate history or fork the definition going forward, and tell every team that reads the metric before it shifts under them.
- 5
5. Enforce, then watch the leading signals
Ship the validation and field history that make the new definition stick, then confirm it took by watching reject rate and reconciliation time, not by assuming.
The process looks heavy written out. In practice it is a short form and a fifteen-minute review, and it exists to make one thing impossible: a silent change to a number the company runs on.
Stewardship: someone owns the model, not just the fields
The reference article assigns a named owner to each critical field, which resolves most day-to-day fights over which value is right. Governance at the model level needs one more role: a steward for the model itself. Revenue Architecture assigns exactly this in a deployment, one owner per model, and the Data Model steward is the person the change-request routes to in step three. Their job is not to know every field. It is to understand what a definition change does to the metrics leadership watches, and to carry the authority to block a change that would quietly rewrite history.
Stewardship also covers a question the field-owner model does not: not what a value should be, but who is allowed to write it. That question got sharper the day we turned on Salesforce’s hosted MCP server and any rep could ask an AI agent to edit an account.
Leading and lagging data-quality signals
The Metrics Spine taught a shape worth reusing here: on the Bowtie, the left-side inputs lead and the right-side outcomes lag, so you steer on the leading ones. Data quality has the same shape, and the book never names it, so I will. A leading data-quality signal tells you a trust problem is forming while you can still fix it for free. A lagging one tells you the problem already went public.
| Leading signals (steer on these) | Lagging signals (the bill arriving) | |
|---|---|---|
| What it is | Validation reject rate on entry, new duplicates created per week, change-requests in flight, write-access exceptions | Reconciliation time on the board pull, dashboard-versus-Finance variance, records failing an audit |
| When you see it | At the moment a record is created or edited | Weeks later, in a review, in front of leadership |
| Cost to act on it | Seconds, at the field | Hours of reconciliation plus a credibility hit that lingers |
| The governance move | Instrument entry, change-control, and write-access so bad data never propagates | Post-mortem the miss, then push the control left to a leading signal |
Most teams instrument only the lagging column, because that is where the pain is loud. The whole point of governance is to spend your attention on the quiet left column instead, so the loud one stops happening.
The remediation ladder: detect, disposition, remediate, prevent
Back to the 167,699 accounts. The bad-data program did not run as a purge. It ran as a loop, and every flagged record earned a verb before anything happened to it.
Detect is where scoring and, increasingly, AI research earn their keep: an account-research harness that reads the open web and returns a verdict with evidence, so “this record looks fake” becomes “this record is fake, here is the redirect and the headcount that proves it.” Disposition assigns the verb. Remediate does the work, and this is where deduplication lives. Prevent closes the loop by fixing the entry path so the same class of junk cannot refill the tank next quarter, which is the only step that makes the whole program finite instead of eternal.
Deduplication is the remediation verb with the most money on it, and it is worth ranking by that money rather than by alphabetical convenience. Across roughly 160,000 accounts we found about 7,200 duplicate clusters covering some 18,500 records. Rather than run a blind merge script, we sorted the clusters into a risk-tiered review queue (slam dunk, easy call, needs attention, manual review) and surfaced each cluster’s merge impact first: how many contacts and how much open pipeline the merge touches, and which fields conflict. A slam-dunk merge with zero pipeline at risk gets auto-actioned; a cluster where two reps are each working live pipeline on a different record goes to manual review, because merging it wrong loses a deal. The entry-time dedup and the ranked SQL sweep that keep this from recurring are in the governance reference; the point here is that dedup is a disposition decision, not a batch job you run and forget.
What this leaves you holding
Governance is not a project you finish. It is two controls you keep running: a change process so definitions cannot move without a steward and a paper trail, and a remediation loop so bad records get a verb instead of a purge. Underneath both sits the discipline of steering on leading signals, so the reconciliation-time surprise in a board meeting stops being how you learn your data broke.
Those two controls exist to protect one thing: the trustworthiness of the raw data at the bottom of the stack. That matters because every metric leadership looks at is built on it, and a metric is only as honest as the layer beneath it. In the next module we climb that stack. The Hierarchy of Metrics is about picking the right metric for the right altitude, from the raw data model up to the investor numbers, and it only works if the foundation you just learned to govern is telling the truth.