Data quality framework: the operating model behind data you can trust

Every organization says it wants better data quality, and most attack it with a cleanup: a team fixes a bad dataset, declares victory, and watches the same problems return within weeks. Quality is not a cleanup, it is an operating model. This article covers the framework that makes data quality durable: the dimensions to measure, where checks belong, how to score quality, and how it differs from the observability tooling it is often confused with.

Why cleanups fail and frameworks last

A one-time cleanup treats the symptom. It corrects the values in a dataset without changing the process that produced the bad values, so the defects reappear at the source rate. Six weeks later the dataset is dirty again and the exercise repeats, which trains the organization to believe quality is unachievable.

A data quality framework treats the process. It defines what good means, enforces it automatically on every run, measures the result, and assigns someone to own it. The difference is not effort, it is where the effort goes: into the pipeline and the operating model rather than into a periodic firefight.

The dimensions, briefly

Quality has to be measurable before it can be managed. Six dimensions cover most of what matters: completeness (are required values present), accuracy (do they reflect reality), consistency (do systems agree), timeliness (are they fresh enough), uniqueness (is each entity present once), and validity (do values obey the rules). Each becomes one or more automated tests. The point of naming them is not taxonomy; it is that "improve data quality" is not actionable while "raise completeness of the customer country field above 99 percent" is.

Where checks belong: push upstream

The highest-leverage decision in a quality framework is where the checks run. The instinct is to validate at the end, in the report, because that is where problems are noticed. That is the most expensive place to catch them.

A check at ingestion catches a bad batch before it propagates into every downstream table and dashboard. A check at the report catches it after it has already fed decisions. The same rule, moved upstream, changes from damage assessment to damage prevention. Tools like Great Expectations, dbt tests and Soda make it practical to assert expectations at each stage of the pipeline, and the framework should place the most important checks as close to the source as possible. Data contracts take this to its conclusion, moving the guarantee to the producing system so violations are caught at the boundary.

Scoring: making quality a number

An abstract commitment to quality changes nothing. A quality score does. The framework assigns each dataset a score, computed from its checks across the dimensions, and surfaces it in the data catalog next to ownership and lineage.

That single number does two jobs. For the owner, it is a measurable target and an accountability: a dataset dropping from 98 to 85 is a visible regression someone must address. For the consumer, it is a signal: an analyst choosing between two datasets can see which one is trustworthy before building on it. Quality that is not scored is quality that is debated; quality that is scored is quality that is managed.

Roles: quality needs owners

Technology enforces rules but does not decide them. Whether a value is correct in business terms is a judgment only the domain knows, which is why a quality framework is also a set of roles.

• Data owners are accountable for the quality of the datasets their domain produces, including the score.
• Data stewards define the rules, adjudicate edge cases and maintain the business meaning behind the checks.
• Data consumers report issues and set the quality expectations their use cases require.

Without these roles, measured defects have no home: the score drops and no one is responsible for raising it. This is the same accountability structure that underpins data governance, applied specifically to quality.

Quality versus observability

Data quality and data observability are often sold together and are not the same thing, and understanding the difference prevents buying one when you need the other.

Quality is assertion. You know completeness matters for a field, so you write a rule that checks it, and the rule passes or fails. It catches the failures you anticipated.

Observability is discovery. It monitors the data's own behavior (row counts, distributions, freshness, schema) and flags anomalies you did not write a rule for: a table that suddenly has half its usual rows, a column whose values shifted. It catches the failures you did not anticipate.

A mature framework uses both: explicit quality rules for the known requirements, and observability for the unknown unknowns. Relying only on rules means you are blind to novel failures; relying only on observability means you have no defined standard to hold data to.

Failure patterns

From the field, the patterns that keep quality out of reach:

1. Cleanup instead of framework. Fixing values without fixing the process, so defects return at the source rate.

2. Checks at the end. Validation only in the final report, catching problems after they have fed decisions.

3. No score. Quality as a slogan with no number, so it is argued about rather than managed.

4. No owners. Measured defects with no one accountable to fix them.

5. Observability mistaken for quality. Anomaly detection bought as if it defined a standard, when it only detects deviation from the data's own past.

Talk through your data quality framework

DNA Solutions helps European enterprises make data quality durable: measurable dimensions, automated checks pushed upstream in the pipeline, quality scores surfaced in the catalog, and the ownership that keeps them from slipping. Whether you are escaping the cleanup treadmill or combining explicit rules with observability, we build quality as an operating model rather than a periodic firefight. Talk to us.