---
title: "Ask in #analytics and See Who Replies"
slug: "h7-ownership"
type: article
locale: en-US
canonical: "https://www.coremodels.io/connector/dbt/h7-ownership"
updatedAt: "2026-09-04T05:04:27+03:00"
---

# 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](https://www.getdbt.com/resources/state-of-analytics-engineering-2026)
(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.

## Recipes

- [Who decides what this column means?](https://www.coremodels.io/recipe/dbt/ownership-register): 41% of analytics teams say data ownership is ambiguous. dbt can tell you who owns a model. Nobody owns a definition.