The two pieces before this one were about the schema as a long-lived interface and about the real cost of changing it. Both assume something that usually isn’t true: that everyone agrees on what the fields mean. In practice a column called active_users has a definition somewhere — logged in within thirty days, excluding internal accounts, counting the trial tier but not the churned ones — and that definition lives in the head of whoever wrote the query, or in code three services away, or nowhere at all. The name is a label. The meaning is a set of decisions nobody recorded.

This is how two dashboards end up disagreeing and both being right. One counts a signup at account creation, the other at first successful action; one excludes refunded orders, the other includes them because the refund happened in a later period. Nobody made a mistake — they made different reasonable choices about ambiguous cases, and the ambiguity was invisible because both columns had sensible names. The disagreement surfaces months later in a meeting, and the ensuing investigation is expensive precisely because there’s no written definition to check either implementation against.

The failure gets worse with time, because definitions drift silently. The code that populates a field changes to handle a new case, and the field’s practical meaning shifts without anything announcing it: rows before the change mean one thing, rows after mean something slightly different, and a query spanning both silently mixes them. This is the same shape as the migration problem from the previous piece, except there’s no ALTER statement to notice — the schema is identical, only the semantics moved. Anyone analyzing that column a year later has no way to see the seam.

The fix is unglamorous and cheap relative to what it prevents: write the definition down next to the thing it defines, and treat changes to it as changes. A column comment stating what counts and what’s excluded. A note recording that the rule changed on a given date and what it was before. A single agreed definition for the handful of metrics the business actually argues about, referenced rather than reimplemented per query. None of this requires tooling anyone doesn’t already have — it requires deciding that the meaning is part of the data rather than tribal knowledge attached to whoever built it.

Which is the thread’s point, and the reason the schema deserves more care than the code around it. Structure and meaning both outlive the systems that produced them; the difference is that structure is at least visible in the schema, while meaning survives only if someone bothered to record it. Years later, the table will still be there and the people who knew what it meant will not. What you wrote down is what the data will still be able to say for itself.