The disagreement surfaced in a meeting about churn. Two teams presented numbers for the same quarter that differed by roughly a fifth, both extracted from the same warehouse, both technically correct. It took us most of a week to find the cause, and it was not a bug anywhere. It was a status field that sales used to mean the contract had lapsed, that support used to mean the customer had stopped responding, and that billing used to mean the last invoice had gone unpaid for ninety days. One column, three meanings, all of them legitimate in their own context, all of them silently merged the moment anyone wrote a query across departments.
This is the failure mode nobody puts on an architecture diagram. We spend enormous effort on pipelines, storage and lineage, on making sure the value that left the source system is the value that arrives in the report. All of that machinery was working flawlessly. What had never been agreed was what the value meant, and semantics do not travel through a data pipeline. They live in the heads of the people who enter the data, and those people were never in the same room, because there was no reason for them to be.
It gets worse with time rather than better. Each team builds dashboards on their own reading, executives learn to trust particular numbers, and downstream logic starts encoding the local interpretation. By the time somebody notices the contradiction, you are not correcting a definition, you are unpicking years of decisions taken on incompatible premises, and every team can produce a perfectly good argument for why their meaning is the real one.
What I now push for, always earlier than anyone wants, is that the definition gets an owner before the field gets a pipeline. Not a glossary page that goes stale in a quarter, but a named person who decides what the term means, whose decision is written next to the data itself and referenced by the queries that use it. When two departments genuinely need different definitions, they get two clearly named fields rather than one ambiguous one, which costs a little storage and saves a great deal of argument.
Data quality is not only about whether the values are right. It is about whether everyone reading them is thinking of the same thing.
– Serguey Shinder
Top comments (0)