What is Blast Radius
Blast radius refers to the potential extent of damage.
For example, before you knock down a wall in your house, you want to know if there's plumbing behind it, electrical wiring within it, or if it's holding up the floor above.
Same idea with data. Before you rename a column, change a formula, or update a filter, you need to know what depends on it. That could include downstream models, dashboards, reports, or other workflows.
Need for Blast Radius Analysis
Often when you rename a column and push it to production, everything seems fine. Two days later, finance pings you on Slack: the weekly revenue dashboard has been broken since Tuesday.
You dig in. The column you renamed was referenced in three other models. One of those models feeds a Tableau workbook. That field is the denominator in the revenue metric on the CFO's dashboard.
Nobody documented any of this. The dependencies existed in the relationships between systems, invisible until something broke. This is the blast radius problem.
Altimate Code fixes this. Before any change goes through, it maps out the full impact automatically. It produces a detailed blast radius report (what will break, what's safe, what needs someone to sign off) and also performs the changes.
I ran a workflow using Altimate Code to verify this.
The workflow: renaming total_cents to gross_revenue_cents
I ran this on my open-source CartWave E-commerce dbt project, a real analytics codebase with staging models, intermediate transformations, mart tables, and a semantic layer on Snowflake.
stg_orders is a simple staging model that reads raw order data and explicitly picks the columns that are needed. The finance team wants us to rename total_cents to gross_revenue_cents to align with GAAP terminology.
The prompt
I gave Altimate Code this prompt:
"Rename the column total_cents to gross_revenue_cents in stg_orders as the finance team wants to align with GAAP terminologies. Before performing the changes, show me the blast radius of the same."
One column, one rename. It should have been straightforward, but it wasn't.
What Altimate Code did
After receiving the prompt, Altimate Code ran through a series of steps before changing a single line of code. Here's what happened, in order.
https://youtu.be/Npf7fHK43-k
Step 1: It loaded the dbt-analyze skill and scanned the project.
Altimate Code started by tracing the dependencies. It read the model SQL, searched every file in the project for references to stg_orders, and checked YAML config files for column-level references.
Within seconds it found five files that depend on stg_orders:
| # |
File |
What it is |
| 1 |
int_order_enriched.sql |
Combines order data with customer info |
| 2 |
int_customer_lifetime.sql |
Calculates lifetime value per customer |
| 3 |
mart_return_analysis.sql |
Report table for analyzing returns |
| 4 |
sem_orders.yml |
Defines business metrics like "total revenue" |
| 5 |
_staging.yml |
Documents what each column means |
Five files depend on this model. But how many of them actually use the column we're renaming? That's the question that matters.
Step 2: It checked each file for column-level references to total_cents.
Altimate Code checked more than whether a file depended on stg_orders. It opened each downstream file and looked for direct references to total_cents.
Here's what it found:
int_order_enriched.sql – BREAKING
Directly selects orders.total_cents on line 31:
orders.total_cents, -- directly uses the column we're renaming
Explanation: This file asks for a column called total_cents. After the rename, that column won't exist anymore. The query will fail.
int_customer_lifetime.sql – BREAKING
Sums total_cents across all orders on line 22:
sum(total_cents) as lifetime_revenue_cents, -- adds up all order values
Explanation: Same problem. The column disappears, the math breaks.
mart_return_analysis.sql – SAFE
This one depends on stg_orders but only uses customer_id and order_date:
orders.customer_id, -- doesn't touch total_cents
orders.order_date, -- doesn't touch total_cents
Explanation: It never references the renamed column. No changes needed.
sem_orders.yml (semantic layer) – BREAKING
Two metric definitions reference total_cents by name in their formulas:
measures:
-name: total_revenue_cents
agg: sum
expr: total_cents # references the column by name
-name: avg_order_value_cents
agg: average
expr: total_cents # references the column by name
Explanation: This is the one that would have bitten me. The semantic layer is a YAML config file, not SQL. It doesn't show up if you're just grepping through .sql files. But if you rename the column and forget to update these metric definitions, every dashboard using "total revenue" or "average order value" breaks silently.
Step 3: It traced the impact further downstream.
Altimate Code didn't stop at the first layer. It followed the chain: if a breaking model feeds another model, that downstream model could be affected too.
Two mart tables sit downstream of int_customer_lifetime: mart_customer_360 (full customer profiles, contains PII) and mart_customer_cohorts (customer segmentation). But neither one references total_cents directly. They use a derived column called lifetime_revenue_cents, which int_customer_lifetime produces from total_cents and then passes downstream under its own name.
Think of it like fixing a pipe in the basement. The faucets upstairs keep working as long as the pipe gets repaired properly. These two marts don't need code changes, they just need int_customer_lifetime to be fixed first.
One thing worth noting: mart_customer_360 is tagged compliance: 'CCPA / GDPR' and contains_pii: true. It doesn't need code changes here, but in a governed environment, you still want to know that a compliance-tagged table sits in the blast radius.
Step 4: It presented the full blast radius report.
Altimate Code assembled everything into a single view:
| # |
File |
What it is |
Impact |
Details |
| 1 |
stg_orders.sql |
The model being changed |
RENAME |
total_cents becomes gross_revenue_cents |
| 2 |
_staging.yml |
Column documentation |
RENAME |
Update column name and description |
| 3 |
int_order_enriched.sql |
Order enrichment model |
BREAKING |
Directly references orders.total_cents |
| 4 |
int_customer_lifetime.sql |
Customer lifetime value |
BREAKING |
Uses sum(total_cents) in a calculation |
| 5 |
mart_return_analysis.sql |
Return analysis report |
SAFE |
Uses stg_orders but never touches total_cents |
| 6 |
mart_customer_360.sql |
Customer profile (PII) |
CASCADING |
Safe once int_customer_lifetime is fixed |
| 7 |
mart_customer_cohorts.sql |
Customer segmentation |
CASCADING |
Safe once int_customer_lifetime is fixed |
| 8 |
sem_orders.yml |
Business metric definitions |
BREAKING |
Two metrics reference total_cents by name |
The bottom line: Five files need changes. Three are safe.
Then the agent asked me:
"I've identified 6 files that need changes across 3 layers (staging, intermediate, semantic). The 2 mart models downstream are safe because they reference derived column names. Shall I proceed with the rename?"
It didn't just run ahead. It stopped, showed me everything, and waited for the go-ahead.
Step 5: I approved. It applied all changes at once.
After I said yes, Altimate Code updated all five files in a single pass. No partial updates, no window where half the models use the old name and half use the new one.
stg_orders.sql – aliased the source column:
total_cents as gross_revenue_cents, -- raw data keeps actual source column name, downstream sees new name
The raw data still has a column called total_cents. Instead of changing the source, the staging model gives it a new name. Everything downstream sees gross_revenue_cents from here on.
int_order_enriched.sql – updated the reference:
orders.gross_revenue_cents, -- was: orders.total_cents
int_customer_lifetime.sql – updated the aggregation:
sum(gross_revenue_cents) as lifetime_revenue_cents, -- was: sum(total_cents)
sem_orders.yml – updated both metric definitions:
-name: total_revenue_cents
description:"Sum of gross revenue in cents (GAAP-aligned)"
expr: gross_revenue_cents # was: total_cents
-name: avg_order_value_cents
description:"Average order value in cents (GAAP-aligned)"
expr: gross_revenue_cents # was: total_cents
_staging.yml – updated the documentation:
-name: gross_revenue_cents
description:"Gross revenue in cents, aligned with GAAP terminology"
Step 6: It built the entire project to confirm nothing broke.
Altimate Code ran altimate-dbt build across all thirty-four models:
Thirty-six passed. Zero errors. Every staging view, intermediate table, and mart, including the PII-tagged mart_customer_360, built cleanly.
Step 7: It verified the column lineage end to end.
As a final check, Altimate Code traced the data flow from source to destination to confirm the rename propagated correctly:
The source column TOTAL_CENTS flows through the alias in staging, propagates correctly to both intermediate models, and the derived column names downstream (lifetime_revenue_cents) stay the same. Exactly what the blast radius report predicted.
Column Changes Are Never Just Column Changes
A simple rename turned out to touch five files across three layers plus the semantic layer. Without the blast radius check, I would have updated stg_orders, run the build, and moved on. The semantic layer would have broken silently. Finance would have found out before I did.
How to read a blast radius report
Every downstream asset gets one of four labels:
| Label |
What it means |
What to do |
| BREAKING |
Directly uses the thing being changed. Will fail. |
Update before or alongside the change |
| CASCADING |
Depends on a breaking file, but doesn't use the changed column directly |
Verify it works after the upstream fix. Usually no code changes. |
| SAFE |
Depends on the changed model but never uses the specific column |
Nothing |
| UNKNOWN |
Can't determine impact (dynamic SQL, runtime-generated column names) |
A human needs to look at it |
The report also flags compliance tags. In our case, mart_customer_360 carries compliance: 'CCPA / GDPR' and contains_pii: true. It didn't need code changes here, but those flags make sure the right people know a compliance-tagged asset is in the blast radius.
Try it out yourself:
I ran this on a real project. To reproduce it:
Clone the CartWave demo project: https://github.com/altimateanas/ecommerce_demos.git
Set up your database connection
Launch Altimate Code
Give Altimate Code the prompt "Rename the column total_cents to gross_revenue_cents..." from the article above
It'll scan the project, map every dependency at the column level and show you a structured report before changing anything.
