The Rename You Didn't Make
There is a column in your project called status, and you have wanted to rename it for about eight months. It should be order_status — everyone agrees. You have not done it.
ImportEarly access
What breaks if I rename this?
dbt lineage tells you which models depend on this one. It cannot tell you who outside dbt is relying on this column.
Start with this recipe →No warehouse credential. No dbt Cloud token. Read-only.
For agents, no sign-in: /recipe/change-impact.json · /recipe/change-impact.md
Everyone has hesitated over a column rename. dbt gives you model-level lineage inside the project — dbt ls --select model+ — and that is genuinely useful, but it answers a narrower question than the one you are actually asking. It does not know that this column's values come from a vocabulary four other models also use, that its meaning is bound to a public term, that a reverse-ETL job and a partner contract both carry it, or who to ask before you touch it. So the honest answer is usually a Slack message and a hopeful deploy. This workspace answers it properly: ask any column, vocabulary or model what depends on it, and get back the governed usage, every estate carrying it and by what path, the external identifiers it is bound to, and the serializations it travels into. Ask before you change, not after the incident review.
What you do
- Ask any column or vocabulary what depends on it, governed usage, the estates carrying it and by what path.
- Answers are column- and concept-level, not dataset-level: a vocabulary reaches a model through the columns it governs.
- Available over the API today; the in-product panel follows.
The story behind this recipe
Guides for this recipe
Engineering
How it works: the import, the API, the MCP tools, the CI loop.