Your data quality problem is an ownership problem.

The clean-up cycle

The sequence rarely varies. An executive notices two reports disagreeing. A data quality project is chartered. Duplicates get merged, validation rules get added, reference lists get aligned. Six months later the numbers finally match.

Then the project team disbands. A new sales channel arrives with its own address format. A department creates a free-text field to get around a constraint that was too rigid. An integration inserts records without going through the agreed rules. Eighteen months after the project closed, the gaps are back, and the organization usually concludes that another clean-up is needed.

That conclusion is wrong, because it answers a continuous phenomenon with a one-time response. No data stays correct on its own. It stays correct because someone is accountable for its correctness, and holds the authority that goes with it.

Where ownership actually belongs

The instinctive answer is to hand the data to the technical team that hosts the database. It is the worst available option: that team understands storage, not meaning. It can guarantee a field is populated. It can never guarantee the value is right.

The data mesh work published by Zhamak Dehghani states the opposite principle: ownership belongs to the business domain that produces the data and understands what it means. The team running contracts owns contract data. The team running logistics owns shipment states. Each exposes its data to the others as a product, with explicit expectations for quality and availability.

The shift sounds bureaucratic and is intensely practical. It replaces an unanswerable question — "why is the data wrong?" — with an addressable one: "who decides what an active customer is, and who do we go to when the definition stops working?"

Data with no owner does not belong to everyone. It belongs to the last system that wrote to it.

Recognizing an ownership problem

Most symptoms filed under data quality are in fact describing the absence of anyone accountable.

What a governance platform will not replace

Governance platforms — catalogues, lineage, classification — are useful and often necessary at scale. What they do not do is create accountability; they record it. A catalogue rolled out without named owners produces a thorough inventory of data nobody answers for, which mainly improves visibility of the problem.

The order that works reverses the usual project sequence. Name an owner per domain first, with a written mandate. Document the authoritative definitions next, including the ones part of the organization will dislike. Introduce tooling last, to make those decisions searchable and verifiable.

1. Name a business-side owner per data domain, with authority to settle a definition.
2. Write down the authoritative definitions, and the systems required to conform to them.
3. Declare a service expectation: freshness, correction turnaround, how to report an issue.
4. Measure gaps at domain level and report them to the owner, not to the platform team.

Organizations that take this step often find their data was not bad so much as orphaned. The definitions existed, scattered across people's heads and spreadsheets, with nobody empowered to arbitrate when they diverged. That arbitration, not the tool, is what holds quality in place over time.