The table nobody owns

There is a particular conversation that happens in week three of a rescue engagement. We ask where a field comes from. Someone says it comes from a table in the warehouse. We ask who maintains that table. There is a pause.

Then: “I think Dave set that up? He left in 2023.”

Why this kills projects specifically

An unowned table is not merely a documentation problem. It has four properties that are individually survivable and collectively fatal:

• It changes without warning. Schema drifts, a column quietly starts arriving null, an upstream system is migrated. Nobody announces it because nobody is responsible for announcing it.
• It has no correctness contract. There is no agreed definition of what a row means, so two teams can both be right and disagree.
• It cannot be fixed. When it breaks, there is no one to escalate to. The fix becomes a project of its own, unbudgeted, in the middle of your build.
• It fails silently. A model does not crash when its inputs degrade. It keeps returning plausible numbers that are increasingly wrong.

That last one is the real danger. A pipeline that fails loudly gets fixed on Tuesday. A model quietly drifting on a stale input can run wrong for a quarter.

What we do in week one

Before anything is built, every proposed input gets three questions:

1. Who owns this? A named person or team who would be paged if it broke. Not “the data team”.
2. What is the contract? What does a row mean, what are the valid ranges, what is the expected freshness, and what happens when it is late.
3. How would we know? If this input silently degraded, what would tell us, and how quickly.

Any input that fails all three is either dropped from the design or becomes a prerequisite piece of work with its own owner and its own timeline. This is not a formality. We have ended engagements at this step, and the client was better off for it.

The uncomfortable version

Sometimes the honest answer is that the interesting model is not buildable yet, and the valuable work for the next six months is instrumentation: capturing the outcome you want to predict, assigning ownership to the inputs, and getting a clean twelve months of history.

That is a worse sales conversation and a better engagement. Data collection is not glamorous, but a year later you have something to build on. The alternative is a model that demos beautifully and is quietly switched off in March.

A test you can run today

Pick the field your most important report depends on. Ask, in writing, who owns it and what happens if it stops arriving. If you get a confident answer within a day, you are in better shape than most organisations. If you get a pause, you have found the thing to fix before you spend anything on models.