# Blast Radius Analysis Using Altimate Code

# 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](https://docs.altimate.sh/getting-started/) 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](https://github.com/altimateanas/ecommerce_demos), 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."*

![Altimate Code is an agentic harness for data engineering.](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/80e6c164-2932-4c78-bc7e-cf795dc17933.png align="center")

*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`:

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/9fdf62f6-a929-471d-98e9-a77ce73c98e3.png align="center")

| # | 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:

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/c50f73df-6320-4fed-8fc1-a7d0d5a33a6d.png align="center")

`int_order_enriched.sql` – **BREAKING**

Directly selects `orders.total_cents` on line 31:

```sql
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:

```sql
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`:

```sql
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:

```yaml
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.

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/27757262-64fd-4a02-941d-cf646a9095da.png align="center")

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:

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/c12bdf06-d31e-4360-a6d7-cea47f7074fe.png align="center")

| # | 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?"*

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/d24768f8-dcc5-40e0-abb6-d49f04bafbb8.png align="center")

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.

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/2ec8b3e5-3cfc-4194-95c2-3fcf8b27ac18.png align="center")

`stg_orders.sql` – aliased the source column:

```sql
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:

```sql
orders.gross_revenue_cents,  -- was: orders.total_cents
```

`int_customer_lifetime.sql` – updated the aggregation:

```sql
sum(gross_revenue_cents) as lifetime_revenue_cents,  -- was: sum(total_cents)
```

`sem_orders.yml` – updated both metric definitions:

```yaml
-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:

```yaml
-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:

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/7a51f847-993b-4524-93d4-1e5ec034f8c4.png align="center")

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:

![](https://cdn.hashnode.com/uploads/covers/6961decc69c600e13d6a9156/3db3c89b-02a5-44ed-9c56-89f7ddd41f48.png align="center")

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:**

1.  Clone the CartWave demo project: [https://github.com/altimateanas/ecommerce\_demos.git](https://github.com/altimateanas/ecommerce_demos.git)
    
2.  Set up your database connection
    
3.  Launch [Altimate Code](https://docs.altimate.sh/getting-started/)
    
4.  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.