Where Data Quality Fits in a Data Governance Program

Data quality sits inside data governance, not beside it. Governance decides what the data means, who owns it and what "correct" is; quality measures whether reality matches that definition and routes the gaps to someone who can act. Treating them as competing programmes is the reason most quality initiatives produce dashboards and no improvement.

The framing matters because it determines who is accountable when a rule fails — and that, rather than the rule engine, is what makes quality work.

Is data quality the same thing as data governance?

No, and the relationship is one-directional.

Governance is the operating model: definitions, ownership, policy, classification, access. Quality is one of the disciplines that operating model runs. You cannot measure whether a value is correct until somebody has decided what correct means, which is a governance output.

This ordering has a practical consequence that teams discover the hard way. A quality programme launched without governance produces rules invented by whoever wrote them — usually a data engineer inferring intent from the schema. Those rules fail, the failures go to a queue, and nobody can adjudicate whether a failure is a real defect or a wrong rule. Within a quarter, the alerts are muted.

Run it in the correct order and the same rule has an owner: the data steward for that domain approved the definition the rule encodes, so when it fails there is a person who can say whether the data is wrong or the rule is.

Which dimensions are actually worth measuring?

The classical dimension list runs to eight or more. Four of them carry most of the value in practice, and the rest are usually special cases.

Completeness. Are required values present. The cheapest rule to write and the most commonly violated — a mandatory field that became optional through three years of form changes.

Validity. Does the value conform to its definition: a national ID matching the expected format, a currency code in the permitted set, a date within a plausible range. Validity failures are usually source-system or integration defects and are cheap to fix once identified.

Consistency. Does the same fact agree across systems. Customer status active in the core system and closed in the CRM. This is the dimension that produces the "three departments, three numbers" problem, and it is the hardest to fix, because fixing it requires deciding which system is authoritative — a governance decision, not a technical one.

Timeliness. Is the data current enough for its use. A warehouse two days behind is fine for trend reporting and useless for an operational decision. Timeliness failures are frequently misdiagnosed as accuracy failures.

Uniqueness and accuracy complete the standard list. Uniqueness — duplicate customer records — is really a master data problem and usually needs its own treatment. Accuracy, meaning correspondence to the real world, cannot be measured internally at all: you can only test it against an external reference, which is why in practice it is asserted rather than measured.

Start with completeness and validity on the critical data elements. They are mechanical, they produce findings immediately, and the findings are almost always real.

Where should quality rules come from?

Three sources, in descending order of value.

From regulatory and reporting requirements. If a field appears in a supervisory return, its constraints are already written down somewhere. These rules justify themselves and nobody argues about their priority.

From incidents. Every reconciliation break, every report that had to be reissued, every "the number looked wrong" escalation is a rule waiting to be written. This is the highest-yield source and the most neglected, because incidents get resolved and not mined.

From profiling. Run a profile across the critical tables — null rates, distinct counts, value distributions, format patterns — and the anomalies suggest rules. Profiling is where a catalog earns its place: OvalEdge profiles connected sources and surfaces the distributions, so rule authoring starts from evidence rather than from a workshop.

What should not generate rules: a desire for coverage. A programme that sets a target of "500 rules by year end" will hit it and learn nothing. Rules have a maintenance cost, and a rule nobody acts on is worse than no rule, because it trains people to ignore the queue.

Who fixes a failing rule?

This is the question that decides whether quality management works, and the answer has three parts that must be separated.

The steward decides what a failure means. Real defect, acceptable exception, or a rule that was wrong. Only somebody who knows the business process can make this call.

The custodian implements the fix. Correcting the data, patching the pipeline, or changing the source system.

The source system owner funds the root cause. This is the part programmes skip, and it is why the same failures recur. If nulls appear because a form does not require the field, no amount of downstream correction fixes it — the fix is in the application, owned by a team with its own backlog and no incentive to prioritise a data quality ticket.

Escalating that trade-off is what the monthly governance forum is for. A quality programme without an escalation path is a programme that cleans the same data forever.

Making the economics visible helps. Sector research puts the cost of poor data quality in the millions of dollars a year for a typical enterprise, with analysts spending a substantial share of their time on data preparation rather than analysis. Those are the numbers that move a root-cause fix up someone else's backlog.

How do you avoid a rule library nobody reads?

Four constraints that keep the programme alive past year one.

Cap the rule count per domain. Twenty to thirty rules covering the critical elements, actively maintained, beat hundreds that nobody triages. If a new rule matters more than an existing one, retire the existing one.

Route by severity, not by volume. A failure that affects a regulatory figure pages someone. A failure in an analytical table raises a ticket. A cosmetic inconsistency goes into a monthly report. Uniform alerting on everything is functionally identical to no alerting.

Measure the queue, not the rules. The meaningful metric is how long a failure waits before someone decides what it means. Rule count and pass rate are vanity metrics — pass rate in particular rises whenever a difficult rule is quietly disabled.

Retire rules deliberately. A rule that has passed continuously for a year is either protecting something valuable or measuring something that cannot fail. Review annually and remove the latter.

Where does quality sit relative to the catalog?

The catalog holds the definition; the quality engine tests against it; lineage explains the blast radius. All three are needed and they are frequently bought separately, which creates its own integration problem.

The practical value of having them together is failure triage. When a rule fails on a column, column-level lineage answers the two questions that follow immediately: where did this value come from, and what downstream reports consume it. Without lineage, both answers are an afternoon of investigation per incident, which is what turns a quality queue into a backlog.

This is also the argument for putting governance before quality tooling in the sequence — a point that recurs in the level 2 to level 3 transition, where the catalog gets deployed to carry an operating model that already exists rather than to create one.

How does AI change the quality requirement?

It raises the stakes in a specific and under-discussed way.

A traditional analytical pipeline has a human between the data and the decision. An analyst producing a report notices that the figure is implausible and investigates. That human check absorbs a meaningful share of quality failures before they reach anyone.

Retrieval-based AI systems remove that check. A document with a stale or incorrect value gets retrieved, the model grounds its answer in it, and the answer is delivered fluently and confidently to a user who has no way to assess whether the source was correct. The model does not know the value is wrong; it has no basis on which to know.

Two consequences worth planning for:

Retrieval scope needs a currency rule. A superseded policy document sitting in the same folder as the current one is a quality defect that becomes a wrong answer. Versioning and effective dates need to be metadata the retrieval layer can filter on, not a naming convention.

Grounding must be inspectable. When the answer is wrong, the question is which source it came from — which requires citation back to the retrieved document, a requirement that also shows up in the audit trail expectations of ISO/IEC 42001.

The broader point is that AI does not tolerate mediocre data any better than analytics does; it just fails less visibly. That is the practical reason governance work precedes AI deployment rather than following it.

Key points

• Quality is a discipline inside governance. Rules require an approved definition and a named owner, or their failures cannot be adjudicated.
• Start with completeness and validity on critical data elements. Consistency is the expensive one because it requires deciding which system is authoritative.
• Source rules from regulatory requirements, from past incidents, and from profiling — never from a coverage target.
• Separate three responsibilities on failure: the steward decides what it means, the custodian fixes the data, the source system owner funds the root cause.
• Cap rules per domain, route by severity, measure queue age rather than pass rate, and retire rules annually.
• Lineage is what makes triage affordable: without it, every failure costs an afternoon of investigation.
• AI systems remove the human plausibility check that used to absorb quality failures, so retrieval scope needs currency rules and inspectable grounding.

Yukon Labs implements OvalEdge with the quality and stewardship model configured together, because a rule without an owner is a dashboard. If you are not sure where your programme currently stands, the data and AI readiness assessment starts by profiling what is actually there. For the wider context, see data governance in Azerbaijan.