The Column That Means Three Different Things
Semantic drift in shared data models is silent, slow, and devastating. Here's what it looks like and how to stop it.
There’s a column in your warehouse called status. It has values like active, pending, and closed. Every team uses it. Nobody agrees on what it means.
The sales team built a dashboard on it in Q1. Then the ops team started populating it differently in Q2. Then engineering migrated the source system in Q3 and kept the column name but changed the semantics. Now you have three overlapping definitions coexisting in the same field, and every query that touches status is quietly lying.
This is semantic drift. It doesn’t announce itself. It just slowly corrupts your metrics until someone notices a number that doesn’t add up and you spend a week debugging a column that was never consistent to begin with.
How It Happens
Shared schemas are a social contract. When the contract isn’t written down, everyone fills in the blanks with their own interpretation. Then someone adds a new integration, finds the column already exists, uses it, and doesn’t ask questions. This is how status ends up meaning “subscription state” in one pipeline and “fulfillment state” in another.
The codebase reflects this chaos. Filters like WHERE status = 'active' appear everywhere, each one making slightly different assumptions about what “active” means.
What It Costs You
- Dashboards that contradict each other and require human interpretation
- Analytics queries that silently return wrong results
- Data consumers who stop trusting the warehouse and start building their own extracts
- Onboarding that requires tribal knowledge to navigate safely
The last one is the worst. When a new engineer asks “what does status mean?” and the answer is “it depends on which team wrote the row” — you’ve already lost.
The Fix Is Not Technical
You can’t solve this with a migration. You can’t solve it with a constraint. You can solve it with a data contract: a formal, version-controlled definition of what each column means, who owns it, and what values are valid.
Write the contract before the column. Not after you discover the drift.
If the column already exists and already has drift — fork it. Rename status to subscription_status and fulfillment_status. Keep status around as deprecated. Yes, it’s painful. It’s less painful than the alternative.
The Actual Rule
If two teams use the same column for different things, you don’t have a shared schema. You have a collision waiting to surface at the worst possible time.
Name your semantics. Own your columns. When something means different things to different people, that’s not a column — it’s a bug with a misleading name.