Who Owns Data Quality
The team that produces a field owns whether it is correct. A data team can measure and report. Placing the whole obligation downstream guarantees it fails.
Who needs this, what one row is, and why the obvious build breaks
Every lesson starts from the consumer, because designing from the source outward is this domain's characteristic mistake.
A column is wrong. Which team is accountable for it being right, and which team is merely the one who noticed?
Every downstream consumer, who currently cannot tell the difference between "this data is correct" and "the data team has not been told otherwise"; and the data team itself, which is usually held responsible for a property it has no mechanism to control.
Ownership is assigned per field and per dataset, not per pipeline. A single fact table typically contains columns owned by three different producing teams, and the useful ownership record is at the level where a human can actually change the value (Data Ownership).
Give data quality to the data team. They understand the pipelines, they have the tooling, they can write the checks, and centralising it means one team to hold accountable. This is how nearly every organisation starts, and it is a reasonable response to a real coordination problem.
A field stops being populated after a service deploy. The data team detects it within hours, writes it up precisely, and cannot fix it — the change is in another team's codebase and that team has other priorities (Data Contracts).
- A field stops being populated after a service deploy. The data team detects it within hours, writes it up precisely, and cannot fix it — the change is in another team's codebase and that team has other priorities (Data Contracts).
- The producing team has no idea anyone reads that column. It was an internal implementation detail, they were entitled to change it, and the first they hear of the dependency is when it breaks (Semantic Changes).
- The data team compensates in the transformation layer: a special case for the new format, a coalesce for the missing field, a filter for the bad rows. Three years later the model contains fifty such patches and nobody can say which are still needed (Data Engineering Anti-Patterns).
- Quality becomes a backlog. Detection is fast, repair is queued behind product work, and the average time from detection to fix is measured in quarters — which means the checks are producing tickets rather than correctness.
- The data team is held accountable for numbers in an executive review and can only report that the upstream source has been wrong since March. Accountability without authority produces exactly one behaviour: defensive documentation (Quality Alerting).
What is actually happening
- Correctness is decided where the value is written. Every downstream system can transform, validate, reject or annotate, and none of them can make a wrong value right. That is not an organisational preference; it is a property of the direction data moves (Source of Truth).
- A data team therefore has exactly three powers: measure, report, and refuse. It can detect that a field is wrong, tell people, and block the publish. It cannot cause the field to be correct (Contract Enforcement).
- Refusal is the only one of the three with teeth, and it is expensive, because it converts a producer's problem into a consumer's outage. That is why it works and why it must be agreed in advance rather than exercised unilaterally in an incident.
- The mechanism that actually shifts the obligation is a contract: an explicit statement of what the producer emits, checked at the boundary, with a failure that is the producer's to fix. Without a contract, every quality problem is discovered downstream and therefore lands downstream (Data Contracts).
- Ownership is only real when three things are attached to the same team: the ability to change the value, the alert when it is wrong, and the consequence when it stays wrong. Any two without the third produces the failure everybody recognises (Data Ownership).
Measure, report, refuse — and nothing else
A data team's relationship with a value it did not write is limited to three actions, and it is worth being precise about them because the limits are what the whole argument rests on. It can measure: run a check and know the field is wrong. It can report: tell the producer, the consumers, and anyone accountable. It can refuse: block the publish so the wrong value does not reach a dashboard.
What it cannot do is make the value right. It can substitute a guess, patch a special case, or filter the offending rows — and each of those is a fabrication dressed as a fix, because the underlying fact remains whatever the producing system recorded (Source of Truth).
This is why an ownership model that places the whole obligation downstream does not merely perform poorly; it is structurally unable to succeed. The team held accountable has no mechanism that reaches the cause. What it will produce instead — and this is entirely rational — is increasingly precise documentation of problems it cannot solve.
The alternative is not to abandon central capability. It is to split the obligation along the line where capability actually lies: producers own whether a value is correct, the platform owns whether anyone would find out.
All checks, alerts and accountability sit with the central data team. When a producer-side field breaks, the data team detects it, files a ticket, and compensates in the transformation layer while waiting. Quality metrics are reported by the team that cannot change them.
Each dataset and field has a producing owner. Checks live at the boundary as a contract that producer's own delivery pipeline can run. Quality alerts route to the producing team by default. The data team owns the platform — lineage, tooling, the dashboard, the standards — and publishes unfixed-issue age by owning team.
Correctness is determined at the point of write, so the only team that can change it is the one that writes it. Detection and repair being in different organisations converts every quality problem into a queued request, and repair latency then depends on another team's priorities rather than on the severity of the problem. Moving the alert to where the fix is possible shortens that path from quarters to hours, and the platform keeps the part it is genuinely best at — knowing that something is wrong at all.
One producer decision, four downstream consequences
The clearest argument for producer ownership is a concrete change. A checkout service splits a single country field into billing_country and shipping_country, keeping the original column populated with the billing value for compatibility. From the service's point of view this is careful, backwards-compatible work.
Downstream, the compatibility is the problem. The old column still exists, still has the same type, still passes every validity and not-null test, and now means something narrower than it did. Every consumer who understood country as "where the order went" is now wrong, silently, with no schema break to notice (Semantic Changes).
Read the silent flags below. The failures that are loud will be fixed within a day by whoever they page. The failures that are silent persist until a human with domain knowledge notices a number looks odd, which is a detection mechanism with no service level at all.
No downstream check catches this, because nothing observable changed. The only intervention that works is upstream: a contract that describes what the field means, so that narrowing its meaning is a breaking change requiring a conversation (Data Contracts).
- order_id: bigint
- country: text -- where the order went
- amount_minor: bigint
- placed_at: timestamptz
- order_id: bigint
- country: text -- now the billing country
- billing_country: text
- shipping_country: text
- amount_minor: bigint
- placed_at: timestamptz
change Two new columns added; the existing country column retained for compatibility and quietly narrowed from "destination" to "billing country". No type change, no removal, no null introduced.
| Consumer | Effect | How it shows up |
|---|---|---|
| Revenue-by-country dashboard | Attributes revenue to the billing country for every order shipped elsewhere. The number moves; nothing errors; the shape of the change looks like a business trend. | Silently — no error, wrong result |
| Logistics model keyed on destination | Silently switches which country it plans against. Every structural test passes because the column is present, populated and of the right type. | Silently — no error, wrong result |
| A model trained on historical `country` | Training data and serving data now mean different things for rows either side of the change, which degrades the model without any pipeline failing (Feature Pipelines). | Silently — no error, wrong result |
| A strict contract check at the boundary | Fails the batch if — and only if — the contract described the field's meaning and its allowed relationship to the new columns. A type-only contract passes this change happily. | Loudly — it raises |
| Reconciliation on total net revenue | Passes. The totals are unchanged; only the attribution moved, and reconciliation on a total cannot see a redistribution between groups (Reconciliation). | Silently — no error, wrong result |
| Per-group reconciliation by country | Fails, because the per-country sums no longer match the source's own per-country sums — one of the few automated signals that would catch this at all. | Loudly — it raises |
Who can detect it, who can fix it, who gets paged
The practical test of an ownership model is whether the third column of the table below matches the second. Where the team who can fix a failure class is also the team who hears about it, repair latency is short. Where they differ, every incident acquires a hand-off, and the hand-off is where quarters go.
Notice that the data team can detect nearly everything and fix almost nothing outside the transformation layer. That is not a criticism of data teams; it is the shape of the problem, and it is why a quality programme staffed entirely downstream plateaus at excellent detection.
The last row is the one worth arguing about in your own organisation. A wrong value at the source is invisible to every check in this module, and the only defence is a producer who validates against their own domain knowledge before the value is written (Business Validation).
Two of the six are genuinely the data team's to fix. In the other four the team that can repair the cause is upstream — and in three of them nobody is currently paged at all.
| Failure class | Who can detect it | Who can fix the cause | Who is usually paged |
|---|---|---|---|
| A field stops being populated after a deploy | Data platform, within a run, via a null-rate check. | The producing service team. Nobody else has the code. | The data team — which is the mismatch this lesson is about. |
| A field's meaning narrows without a type change | Nobody automatically, unless a per-group reconciliation exists. | The producing team, by treating meaning as part of the contract. | Nobody, until a human notices a number looks wrong (Semantic Changes). |
| Duplicate rows from a non-idempotent re-run | Data platform, via a uniqueness check. | Data platform — this one genuinely is theirs (Idempotent Data Pipelines). | The data team, correctly. |
| A join at the wrong grain inflating a measure | Data platform, via reconciliation on the summed measure. | Data platform. The bug is in the model (Grain: What Does One Row Represent?). | The data team, correctly. |
| Late data leaving a closed period short | Data platform, via completeness on the closed period. | Shared: the platform can widen the window, the producer can emit sooner (Late-Arriving Data). | The data team, which then has half a fix. |
| A wrong value written at the source | Nobody downstream, ever. It reconciles perfectly. | The producing team, through their own validation before the write (Business Validation). | Nobody, until a consumer with domain knowledge disputes the number. |
Choosing an ownership model
There is no correct model, only a fit between the number of producing teams, the maturity of the platform and what the organisation is willing to fund. What is not optional is answering the question explicitly, because the default answer — whoever noticed — is the one that fails.
The progression below runs roughly with organisation size, and the transitions are forced rather than chosen. Central ownership does not fail because someone read an article; it fails when repair latency stops being a function of severity and starts being a function of other teams' roadmaps.
Whichever model is chosen, the platform obligations do not go away. Someone has to own lineage, the check tooling, the dashboard and the standards, and distributing correctness without providing that platform is how a mesh becomes a set of disconnected teams each inventing their own quality programme (Data Mesh).
How many teams produce data, and what is the current repair latency for a producer-side failure?
when A handful of producing teams and one data team that genuinely knows every source and every consumer.
cost Works well and stops scaling at a predictable point. Detection stays fast; repair latency grows with the number of upstream backlogs the team is waiting on (Data Platform Engineering).
when Several product domains, each with enough analytical work to justify a dedicated person inside the team.
cost Puts modelling knowledge next to domain knowledge and fragments standards. Needs a strong central platform or every domain invents its own definitions (The Metrics Layer).
when Producing teams outnumber the data team and producer-side failures dominate the incident list.
cost Requires agreement, tooling producers can run in their own delivery pipeline, and the political will to block a batch. The highest-leverage change available and the hardest to start (Contract Enforcement).
when Datasets are consumed widely enough that consumers need a commitment rather than a best effort.
cost Real operational obligations — an on-call for a dataset, a freshness SLO, a documented contract — which is a genuine cost and the reason most "data product" initiatives stall (Data Products).
when Many domains, a mature platform team, and central bottlenecks that are demonstrably slowing everyone down.
cost The organisational model usually labelled data mesh. It redistributes the obligation and adds coordination cost; without a self-service platform and enforced standards it produces silos with better branding (The Self-Service Data Platform).
How to build it
Most important first.
- Record an owning team per dataset and, where they differ, per field. Make it a required attribute of registering a dataset rather than a documentation task somebody will get to (The Data Catalog).
- Route quality alerts to the producing team by default, with the data team informed. The alert going to the people who can fix it is most of the change (Quality Alerting).
- Give producers a contract to satisfy, checked at the boundary, so their obligation is expressed as something they can test in their own CI rather than as an expectation somebody holds about them (Contract Enforcement).
- Make consumption visible to producers. Most producer-side breakages are not negligence; they are a team changing something they believed nobody read (Impact Analysis).
- Keep the data team as the platform: measurement, tooling, lineage, the dashboard and the standards — not as the party responsible for every value in the warehouse (Data Platform Engineering).
- Escalate on unfixed quality issues by age, not by severity alone. A wrong field that has been known-wrong for a quarter is an ownership failure and should be visible as one (Data Incidents).
What this actually promises
Naming the guarantee you do not have is worth more than naming the one you do — everything downstream inherits the weakest promise in the chain.
- A contract at the boundary guarantees that data violating it does not enter the platform. It guarantees nothing about the producer fixing the cause — the batch is rejected and the field can stay wrong indefinitely (Data Contracts).
- An owner recorded in a catalog guarantees only that a name exists. Whether that team has agreed, has capacity, or still exists is outside the system (The Data Catalog).
- A data team can guarantee detection for the failure classes it has asserted, and communication. It cannot guarantee correctness, and any commitment it makes to correctness is a commitment it cannot keep (Data Quality).
- Nothing here guarantees that a consumer knows who to ask. The most common practical failure of ownership is not absence but obscurity (Data Discovery).
Can I trust it?
A green pipeline is evidence that code ran. These four fields are the evidence that the data is right.
- The measurable check on ownership is the age distribution of known-unfixed quality issues, grouped by owning team. It is uncomfortable, it is easy to compute, and it says more than any maturity assessment.
- Also track the fraction of quality alerts that reach a team able to fix the cause. If that number is low, the programme is producing documentation rather than correctness (Quality Alerting).
- It misses issues nobody detected, which are by definition absent from the count — so a falling issue count is ambiguous and can equally mean improving data or decaying checks (Data Tests).
- Ownership decides repair latency, which is the freshness property that consumers actually experience during an incident. Detection in an hour and repair in a quarter is a quarter-long incident.
- A boundary contract fails fast, which is a freshness cost paid immediately and deliberately: the dataset is late rather than wrong, and the producer learns at once (Contract Enforcement).
- Compensating downstream is faster today and slower forever. Each patch shortens this incident and lengthens the next one by making the transformation harder to reason about (Model Layering).
- Ownership decays faster than any technical artefact in this module. Teams reorganise, people leave, and an owner field pointing at a team that no longer exists is worse than an empty one because it looks configured.
- As a platform grows, ownership must move from a list to a property of registration: a dataset that cannot be registered without an owner cannot accumulate an unowned tail (Metadata: Technical, Operational and Business).
- When a producer changes what a field means without changing its type, ownership is what decides whether that conversation happens before or after the metric moves (Semantic Changes).
- Recovery from a producer-side error is upstream first, downstream second: fix the source, then backfill the affected range. Repairing downstream while the source stays wrong recreates the problem on the next run (Planning a Backfill).
- Where the source cannot be fixed retroactively — the true values are gone — the honest recovery is to annotate the affected period rather than to invent a correction (Dataset Documentation).
- Recovery from an ownership failure is a conversation, not a commit. The technical work is usually small; the agreement about who is paged next time is the deliverable (Data Ownership).
What can go wrong
- Accountability without authority: the data team answers for numbers it cannot control.
- Authority without accountability: producers free to change anything, with the consequences landing elsewhere.
- An owner recorded for a team that has reorganised, which routes alerts into a void that looks configured.
- Compensating downstream indefinitely, which accumulates patches nobody can safely remove (Data Engineering Anti-Patterns).
- A contract enforced so strictly that producers route around the platform entirely, which is the failure of the mitigation itself (Data Platform Anti-Patterns).
- Ownership assigned per pipeline rather than per field, so a table with three producing teams has one nominal owner who owns a third of it.
- "The data team owns data quality." They own measurement and reporting. Correctness is decided where the value is written, and no downstream team can supply it (Source of Truth).
- "Data mesh solves ownership." Data mesh is an organisational model with real operational cost that redistributes the obligation; it does not remove the need for contracts, platform tooling or measurement, and it fails outright without them (Data Mesh).
- "We have owners in the catalog, so ownership is handled." A name is not an obligation. Check whether that team receives the alerts and whether unfixed issues are visible to their leadership (The Data Catalog).
- "Producers cannot be expected to care about analytics." They can be expected to honour a contract they agreed to, which is a much smaller ask and the only one that works (Data Contracts).
- Ownership and data classification are the same record viewed from two directions: the team that owns a field is normally the team that must answer for its classification, retention and deletion (Data Classification).
- A dataset with no owner cannot honour a deletion request, because nobody is accountable for finding every copy. Unowned datasets are a governance liability before they are a quality one (Deletion Requests).
Operating it
- Known-unfixed quality issues by age and owning team, published where both the producing teams and their leadership can see it (The Data Quality Dashboard).
- Fraction of quality alerts routed to a team that can fix the cause, versus routed to the data team (Quality Alerting).
- Count of datasets with no owner, tracked over time, which is the single most predictive number about a platform's future (The Data Catalog).
- Contract violations per producer per period, which turns an anecdote about "that team" into a series (Data Contracts).
- Below a handful of teams, central ownership is correct and a contract programme is ceremony. One data team can genuinely know every source and every consumer (Data Mesh).
- Somewhere in the tens of producing teams, central ownership fails in a predictable way: detection remains fast and repair latency grows without bound, because the fixes are all in other people's backlogs.
- At hundreds of datasets and dozens of teams, ownership has to be a property of registration and contracts have to be machine-checked, or the unowned tail grows faster than the owned core (Data Products).
- The cost of producer ownership is producer engineering time: contracts to satisfy, alerts to answer, tests to run in their own delivery pipeline. That is a real and permanent tax on teams whose priorities are elsewhere.
- The cost of central ownership is a data team that grows with the number of upstream systems and spends its capacity compensating rather than building (Data Platform Engineering).
- The cost that is never budgeted is decisions taken on wrong numbers, which does not appear on either team's ledger and is usually larger than both (Data Quality).
- Pushing ownership to producers is correct and slow. It requires agreement from teams who did not ask for the obligation and will reasonably ask what they get in return.
- Boundary enforcement converts silent wrong numbers into loud outages, which is the right trade and will be unpopular the first time it blocks a release (Contract Enforcement).
- A data team that refuses to compensate downstream is protecting the platform's long-term coherence at the cost of appearing unhelpful in the short term, and that cost is paid by individuals in meetings rather than by the architecture (Data Platform Anti-Patterns).
Where this applies
Almost nothing here is universal. These labels say what each claim is specific to, and where a different engine, format, warehouse or scale would differ.
- ORG-SPECIFICThis is an organisational question with technical consequences, not a technical question. The same platform, tooling and checks produce completely different outcomes depending on whether producing teams receive the alerts and are measured on unfixed issues, and no architecture compensates for the wrong answer.
- SCALE-SPECIFICCentral ownership by a single data team is the correct answer below roughly a handful of producing teams, where one group can genuinely know every source and consumer. It fails predictably in the tens of teams, where detection stays fast and repair latency grows without bound because the fixes live in other backlogs.
- GENERALThe underlying asymmetry — that correctness is decided where a value is written and every downstream system can only transform, reject or annotate — holds regardless of organisation size or stack, and is what makes purely downstream ownership structurally unable to succeed.
Where the depth lives
This domain teaches how data moves and how you know it arrived intact. It hands the rest off by name.
- — DevOps / Production Engineering owns the "you build it, you run it" argument that this lesson applies to data. The reasoning is the same — accountability without the ability to change the system produces documentation rather than reliability — and the objections raised by producing teams are the same too.
- — Distributed Systems owns the coordination cost that appears whenever an obligation is split across autonomous teams. A federated ownership model is a distributed system with humans as nodes, and it inherits the same partition and consensus problems in a slower and less forgiving form.