One customer. Four retention clocks.
Retention isn't a number. It's a rule that depends on the product, the region, and the use — and it lives where no query can see it.
The task was routine: build a churn-risk dataset. The agent joined support_transcripts to billing_invoices on customer_id and shipped twenty-six months of history to a training bucket. The query ran clean. Three retention rules were violated before anyone read the first row.
Retention was never one number. Billing records are kept seven years for tax. Support transcripts are cleared after 90 days — unless the account is under an open dispute. Product events expire at 13 months. EU rows run on shorter clocks than US rows in the same table. Each window is keyed on the product, the region, and the use case, and each was decided by a real person for a real reason. None of it is in the schema.
The sharpest rules aren't even about deletion. For analytics, the transcripts table may be used with customer_email masked. For model training, the free-text column must be omitted entirely — masking isn't enough. Same table, same columns, two different shapes depending on why you're reading it.
The agent saw none of this, because there was nothing to see. The table existed. The columns were typed. To a system that can only read structure, existence looks like permission. The query compiled, the join was correct, and the dataset landed with unmasked emails and fourteen months of transcripts that were supposed to be gone at three.
No error fired, because nothing in the warehouse knows the rules exist. They're written down — in a DPA, a policy doc, a compliance wiki. Retention is the clearest case of governance the warehouse can't see: the data quietly outlives its permission, and the first system to notice is an audit.
