Ask in #analytics and See Who Replies

Somebody wants to add a value to a status column. They are not being careless — they have checked that the value is real, and they have found the model. What they cannot find is the person who gets to say yes.

So they ask in the team channel. Two people reply, one of them hedging. The value ships. Six months later a report is wrong in a way that takes a day to trace, and the retrospective concludes that "we should have a process for this."

dbt Labs' 2026 State of Analytics Engineering (n=363, surveyed late 2025 – early 2026) found 41% still report ambiguous data ownership as an obstacle — effectively unchanged year over year, while over the same period the importance placed on trust in data rose from 66% to 83% and 71% said they were concerned about incorrect data reaching stakeholders.

Read those together. The thing everyone agrees matters more went up seventeen points. The thing underneath it did not move at all. That is the signature of a problem process cannot reach: teams have been trying, and ownership stays where it is, because you cannot fix trust in a definition nobody owns and there is nowhere to record who owns one.

What dbt actually gives you

dbt has ownership constructs and they work. Groups assign models to a team. Model-level owners appear in the docs site. Meta fields hold whatever convention you adopt.

All of those describe who maintains the SQL. That is a real and useful fact, and it is not the fact you need when someone wants to change what a column means.

The person who owns fct_orders.sql is the person who will fix it when it breaks. The person who decides whether return_pending belongs in the status vocabulary might be in operations, might be the analyst who defined the returns process, might be a committee. Conflating them means the question routes to whoever is nearest the code, who then makes a business decision they were never asked to make.

And there is a structural reason dbt cannot close this. Ownership in dbt attaches to files. Meaning does not live in a file — the same concept appears in eleven of them. There is nowhere in the dbt project to put "this concept is owned by X" such that all eleven inherit it.

Ownership as a property of the meaning

Move it up one level. The owner attaches to the concept — the column's meaning, the vocabulary behind it — rather than to any file that happens to use it.

That gives you a register: every column and every vocabulary carrying an owner, a steward team, a review cadence, when it was last reviewed, and where the decision gets made. It sits as columns in a grid you can sort and filter, because it is not a separate system — it is metadata on the model, and the model already knows how to carry metadata.

Two fields in that list earn more than they look like they should.

A decision forum, not just a person. "Who decides" resolving to a named individual is fragile; people change teams and leave. Resolving to a forum — a weekly review, a working group, a named channel with a defined convention — survives that. It also makes the honest answer available: sometimes nobody decides, and the fix is to schedule the conversation rather than to guess.

A review cadence, with a last-reviewed date. Definitions rot quietly. A cadence turns "is this still right?" from a question nobody asks into a thing with a date on it.

The most useful view is the empty one

Filter the register to everything with no owner. That list is your actual to-do, and it is usually longer and more alarming than anyone expects — which is the point. Ambiguous ownership feels like a vague cultural problem right up until it is a filtered grid with a count on it.

Start with the vocabularies rather than the columns. Vocabularies are where the arguments happen: the permitted values of a status, the categories of a customer, the tiers of a plan. Get those owned and a surprising amount of the ambiguity resolves, because most of the disputes were about definitions, not about columns.

A default is better than a blank. Assigning an entire domain to one team on day one is imperfect and it is still a large improvement, because it makes the exceptions visible — and the exceptions are what you actually needed to find.

Why this is worth doing before anything else

Every governance workflow you might build later needs this and cannot substitute for it.

A review workflow needs to know who reviews. A notification needs somewhere to route. An escalation needs an owner to escalate to. An impact answer that says "this affects four contracts" is only actionable if it also says who to talk to about each. Build any of those on an estate where nothing has an owner and you get a mechanism firing into a void.

That is the argument for doing it first even though it is the least impressive-looking item on any roadmap. It is configuration, not engineering — a set of columns and a grid — and it is the prerequisite for the things that do look impressive.

The dbt quickstart that ships with the CoreModels integration docs covers the import; the ownership columns are there when you arrive.