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 →Just manifest.json. No warehouse credential, no dbt Cloud token, no writes to your repo.
Opens the CoreModels app at this recipe. Sign in with Google or Microsoft.
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 imported source 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, every imported source that carries it, and by what path.
- You ask about one column or one vocabulary, not a whole model. The answer follows the governed meaning; it does not trace which downstream column it became.
- 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.