Build data quality rules the business actually trusts

Your data quality dashboard is green. Completeness 99 percent. Validity 98 percent. Every critical element ticked. And the business teams still pull their own numbers, still argue in meetings, still quietly route around the data you govern.

A green dashboard is not trust. Often it is the opposite: a confident number reported against nothing.

The rule that protects nothing

Here is how most rules get built. You take the data quality dimensions as a checklist. Completeness, so flag the nulls. Validity, so flag the bad formats. Timeliness, so check the load date. You generate a rule per box, per critical field. The grid fills in. It looks complete.

What that skips is the only question that matters: what happens in the business when this field is wrong? Nobody asked. So when the rule says "100 percent complete," nobody can tell you who benefits. When it drops to "50 percent valid," nobody can tell you who loses, or whether that 50 percent is even a problem the rule was ever taught to understand.

The rule reports a number against nothing, and reports it with false confidence. That is why the green does not buy trust.

The same field, built the other way

Take employee tax classification. Built dimension-first, you get three rules: flag empties, flag values outside the code set, flag mismatches with the country code. Run them on a real table and half the alerts are false. Some empty values are wrong because onboarding dropped the field. Some are correct because the person is a contractor whose classification lives elsewhere. The rule cannot tell the difference, so the steward spends the week explaining why the rule is wrong.

Now build it from the consequence instead. Ask first: what breaks? If classification is missing for an employee whose onboarding is complete, payroll withholds at the wrong rate, the year-end statement is wrong, the company is exposed to a finding. The owner is the head of payroll.

That one answer shapes the rule. It fires only where onboarding is complete. It excludes contractors, because an empty value there is correct. It checks the value against the tax authority's code set. Same field, same data. One rule the head of payroll understands and trusts, instead of three that cry wolf.

Trust comes from consequence, not coverage

A rule the business trusts is one whose failure someone would actually feel. That is the whole test. When it passes, you can name who benefits. When it fails, you can name who loses. When it fires on a value that is odd but legitimate, it already knew the condition, so it stays quiet.

Build rules this way and something else happens: the rule library shrinks. Fewer rules, fewer false alerts, less time triaging firings on fields nobody can connect to a consequence. The dashboard has fewer green boxes and a lot more trust behind each one.

The hard part

Consequence-first is harder, which is why teams default to the checklist. The checklist lets you produce rules without naming the consequence, sharpening the business need into a rule, or designing the control around it. That skipped work is exactly the work that earns trust, and holding it across 30 or 50 fields, under a Friday deadline, in an organisation that asks for dimensional metrics, is where most stewards slip back.

enabledat holds the method as a structure: from the business need, to the rule that expresses it, to the control that protects it. The chain stays visible, so the rules you ship are the ones someone will defend.

Stop chasing green. Build the rule someone would miss if it were gone.

Request early access to the beta.