Build a data quality framework: from business rules to owned fixes

A data quality framework defines what good data means for a specific use, how the business checks it, and who acts when it falls short. It connects rules, measures, ownership, and repair work. A dashboard full of failed checks is only one part of that framework.

Quality depends on the decision the data supports. A customer address may be complete enough for a regional report but still lack the detail needed for delivery. Therefore, start with use cases rather than a universal score.

This article explains how to define quality dimensions, write useful rules, set thresholds, and route fixes. It also shows how to pilot the framework on one business dataset and avoid common measurement traps.

Begin with a business use and a data owner

Choose a decision or workflow that already matters. Examples include paying suppliers, shipping orders, planning stock, or producing a monthly revenue report.

Then identify the records and fields that decision needs. For a payment workflow, supplier identity and approved bank details may matter more than a marketing category.

Name an accountable business owner and the technical teams involved. The owner should decide what the data must support, while engineers help implement and monitor the checks.

The UK government’s Data Quality Framework provides a useful foundation for treating quality as fitness for purpose. Apply that idea to a bounded dataset before expanding across the organization.

Use quality dimensions as questions

Dimensions give teams a shared vocabulary. They work best when each one becomes a question about a real use, rather than a label in a report.

Completeness: do the required values exist?

Check whether necessary fields and records are present. For example, every approved supplier may need a payment method and an accountable owner.

However, a filled field can still contain a placeholder or wrong value. Completeness should not stand in for accuracy.

Validity: do values follow the agreed format and domain?

Validity checks whether a value meets defined rules. A date should parse as a date, and an order state should belong to the approved list.

For example, a postal code can match a format but still refer to the wrong address. A valid-looking value is not automatically a true one.

Uniqueness: do records repeat where they should not?

Check whether a business entity appears more than once under the same identity rule. Supplier duplicates can split spending history or create payment risk.

First define what counts as the same entity. Similar names alone may belong to different businesses, while one business may use several trading names.

Consistency: do related values agree?

Consistency checks relationships within or across systems. An order total should follow its agreed calculation, and a shared customer status should follow a common mapping rule.

Differences are not always errors. Two systems may use different definitions for a legitimate reason. Document those definitions before imposing a comparison.

Timeliness: is the data current enough?

Timeliness concerns the use, not simply the age of the record. A daily report and a dispatch screen can need different update intervals.

Measure the latest useful source update where possible. A pipeline can run successfully while copying data that has not changed because its upstream source stopped.

Accuracy: does the value reflect reality?

Accuracy often needs evidence beyond the dataset itself. A correctly formatted phone number may still belong to the wrong contact.

Use suitable verification, source reconciliation, or sampled review. Be clear about the limits of the evidence so a score does not imply more certainty than the process provides.

Turn expectations into testable rules

Write rules in business language first. “Every approved invoice has a supplier ID” is easier to review than a query with an unexplained filter.

Next, define the scope. Does the rule apply to all invoices, only approved invoices, or only invoices created after a certain process change? Scope affects both the result and the repair workload.

A useful rule record includes its purpose, dataset, fields, logic, threshold, owner, severity, and response. Also include the rule version and review date.

For example, a required invoice identifier may have a zero-tolerance rule in the payment flow. A descriptive category used for exploratory analysis may allow a review queue rather than block the process.

Data validation tools can automate some checks. The Great Expectations documentation introduces one approach to building validation workflows. Choose tools after the business rules are clear, so the framework does not become a list of whatever checks the product makes easiest.

Set thresholds according to impact

Not every failure deserves the same response. A missing critical identifier can stop work, while a small formatting issue may wait for a scheduled cleanup.

Assess severity using the likely consequence, the affected population, and how quickly someone needs to act. Then assign a route for each level.

For instance, an order feed that omits a required delivery field may hold the affected record for review. A trend in noncritical product descriptions may create a weekly work item.

Avoid thresholds chosen solely to make a dashboard green. Also avoid a blanket zero-tolerance policy that stops useful work for every minor issue. The response should reflect a deliberate business decision.

Review thresholds after the pilot. False alarms may reveal poor scope or weak logic, while missed issues may show that the rule measures the wrong thing.

Measure quality without hiding the denominator

A quality percentage needs a clear population. If the check examines only records that already passed an earlier filter, the result may exclude the worst data.

Show how many records you tested, how many failed, and which records you excluded. This gives users a basis for interpreting the score.

Also distinguish a record with several failures from several distinct failed records. Counting every failed field as a separate bad record can exaggerate the affected population.

Do not average unrelated dimensions into one number without explanation. A high completeness score cannot cancel out a serious accuracy problem in bank details.

Oxen’s data observability guide explains how freshness, volume, and shape changes can reveal pipeline issues. Combine those signals with business-level rules rather than treating either one as a complete solution.

Build a repair workflow, not just alerts

Every important failed rule needs an owner and a next step. The team should know whether to correct a record, retry a load, contact a source owner, or pause a downstream process.

Attach enough evidence to the issue: rule, affected record identifiers, time, source, and expected behavior. Avoid exposing private values in broad alert channels.

Next, decide where the correction belongs. Editing a reporting table may fix today’s report while leaving the source error intact. Where possible, repair the authoritative source and let the corrected value flow through.

Track repeated issues by cause. If staff keep repairing the same missing field, the entry form or integration contract may need a change. A framework should reduce recurrence, not institutionalize manual cleanup.

Finally, confirm the fix. A closed ticket should link to a passing check or other suitable evidence. This makes the repair process traceable.

Handle exceptions and uncertain records explicitly

Some records legitimately fall outside a normal rule. For example, a one-time supplier may follow a different approval process from a contracted supplier.

Record the exception, its reason, owner, scope, and review date. A hidden filter is harder to audit and can expand beyond its original purpose.

Also create a state for uncertain data. A value that needs review should not masquerade as confirmed. Downstream users need to know whether they can use it for the intended decision.

Where a manual override is necessary, preserve the original evidence and the person who approved the change. Then decide whether the next source update should replace the override or trigger another review.

Connect quality with governance

Data governance defines responsibilities, shared meanings, and control over data. Quality checks provide evidence about whether data meets those expectations.

For example, governance may define the approved meaning of “active customer.” The quality framework can check that systems apply the required states and identifiers consistently.

Oxen’s data governance software guide covers the wider ownership and definition layer. Keep these responsibilities connected so rule disputes have a clear decision-maker.

Also coordinate changes. A new product status or source field can affect many checks. Version the rule and communicate its effective date rather than treating every new value as an unexplained failure.

A worked example: supplier payment readiness

Suppose a business wants to reduce avoidable payment holds. It starts with approved supplier records used by the accounts team.

The business owner defines required identity, payment, and approval fields. Engineers then add checks for missing identifiers, invalid state values, duplicate supplier references, and stale approval evidence.

Failed critical checks route the record for review before payment use. Less urgent descriptive issues enter a cleanup queue. The accounts team verifies the correction in the source system.

Next, the team compares failures with actual payment holds. If a rule creates many alerts but rarely explains a hold, it revisits the logic. If a common hold has no matching check, it assesses whether a new rule would help.

The example describes a possible process, not a claimed customer result. Its purpose is to show how the framework links rules to a decision and a repair path.

Run a pilot before buying a broad platform

1. Select one dataset and one business use.
2. Agree on critical fields and definitions.
3. Profile the data to understand its current shape.
4. Implement a small set of reviewed rules.
5. Route failures through an owned repair workflow.
6. Review false alarms, missed issues, and operating effort.

For cross-system totals, add a reconciliation step. Oxen’s data warehouse planning guide explains why consistent history and definitions matter when several sources feed analysis.

Evaluate tools against the pilot’s needs. Check supported sources, scheduling, access control, evidence storage, and how easy it is to change a rule. The most useful platform is one your team can operate consistently.

Separate entry controls from downstream checks

A field-level validation rule can prevent some bad data at entry. A downstream check can find problems introduced by imports, transformations, or older records. Use both where the business risk justifies them.

For example, a form can require an approved supplier identifier, while a nightly rule checks that imported invoices reference existing suppliers. The checks cover different routes into the same workflow.

Also provide clear feedback at the point of entry. A rule that rejects a value without explaining the accepted format may create repeated support work. Make the correction path understandable to the person who can act.

When several sources disagree, preserve their evidence until the owner resolves the conflict. Automatically selecting the latest value may hide a legitimate difference in meaning or authority.

Make quality part of normal work

A practical data quality framework connects purpose, rules, evidence, and owned fixes. Start with one meaningful use case, prove the response process, and expand with clear definitions. Quality improves when the business can act on failures, not merely count them.