Data quality has two owners

A data platform can continuously check whether the data is correct: whether a column is populated, whether a value is unique, whether a table was refreshed on time. That can happen in real time, a few times a day or every night. If all those checks pass, the data counts as good quality. And yet a number sometimes comes out that nobody in the meeting trusts.

That is because data quality holds two questions that are easily mixed up. The first is about the data itself: is it technically correct? The second is about the meaning: is the right thing being computed? Those questions belong to different people, and that difference is easily overlooked.

The first question is about the shape of the data, the second about the meaning behind it.

The data has to be technically correct

The first question is technical in nature. On the data platform it is checked with automated tests, for example in dbt: checks on completeness, on uniqueness, on freshness. Those tests run continuously or at fixed moments and catch real errors, from missing rows to duplicate records and data that went stale.

This is serious work, and it belongs with IT: close to the source, on the platform, with the tooling to spot deviations quickly. Without this layer there is no reliable base. This layer alone is not enough.

A correct table can still give a wrong number

A table can be complete, unique and current and still produce a number the business does not recognise. The data is then technically fine, while the outcome computes something nobody agreed on. "Active customer" might for instance still count someone who has bought nothing for three months. Credit notes are included in revenue, or exactly not.

No technical test sees that. A dbt test on completeness or uniqueness does not know what the business meant by a concept. Such a test checks the shape of the data, not the meaning behind it.

Two questions, two owners

Behind those two questions sit two responsibilities. IT makes sure the data is technically correct. The business decides what "correct" means: which definition applies, which rules count, what a concept precisely means. They are two disciplines, both needed, and they complement each other.

IT guards the shape of the data, the business guards its meaning.

In practice many organisations assign only the first. There are tests on the platform, but nobody is appointed as the owner of the meaning. The data is then guarded and the meaning is not, and it is exactly in that gap that the number nobody trusts appears.

The data contract connects the two

A data contract brings both sides together. The business captures the definition and owns it: what counts, what does not, over which period. It does not stay a document in a drawer, because it becomes the specification that is enforced on the platform. IT translates the definition into tests that run in dbt alongside the technical checks.

The contract turns an agreement into a test that runs on the platform.

If such a test fails, that means more than "the data is dirty". It means reality has drifted from what was agreed. And the contract shows who decides about it: the owner of the meaning, not some shared mailbox.

What remains

Data quality then becomes more than a cleaning job for IT: a shared agreement between IT and the business, captured in a contract and guarded on the platform. Technology guards whether the data is correct, the owner guards what it means, and the contract holds both to the same number.

Data that looks clean is therefore not automatically correct. Data only becomes correct once someone has captured the meaning behind it and keeps standing behind it.