Inspiration
You drop a column. The PR looks harmless, CI is green, everyone approves. Two days later a finance dashboard three teams away goes blank — and nobody connects it to your merge. The thing you broke was never in the repo you reviewed. Tests can't see it. CI can't see it. But DataHub knows exactly what depends on that column — so Blast Radius asks it, at review time, before you hit merge.
What it does
Blast Radius is a GitHub Action. Open a PR that changes a table or a dbt model — before anyone merges, it reads the diff, asks DataHub what depends on the columns you touched, and comments with a verdict:
❌ Breaking — real queries and dashboards depend on this ⚠️ Review — someone still uses it, take a look ✅ Safe to merge — nothing actually reads this
The trick is how it decides: usage-weighted, not a node count. Drop discount_amount: two finance queries read it 11×/day → ❌. Drop gift_wrap off the same table: nobody queried it in 30 days → ✅. Most tools flag both — and get muted by Friday.
It also writes back to the graph: on a breaking change it tags the column in DataHub and files a short doc linked to the PR — so the next person who opens that table inherits the warning.
How we built it
Deterministic core, LLM at the edges. Diff parsing and lineage traversal are code, not an LLM guessing: sqlglot reads the dbt column diff, regex handles raw DDL, names resolve against the catalog, severity scores by real usage.
It talks to DataHub through the Agent Context Kit (datahub-agent-context) — the same tool layer behind DataHub's MCP server — for both reading lineage and writing the verdict back. Ships as a GitHub Action. ~128 tests, including live end-to-end runs against a seeded DataHub.
Challenges we ran into
Lineage wouldn't load at first. One bad piece of metadata in a batch was quietly killing the whole batch, so the lineage never showed up — it took me a while to figure that out. Then I had to see realistic query history (which queries read which columns, and how often) so the tool had real data to reason about. But the demo was the real fight: GitHub's cloud runner can't reach a DataHub running on my laptop. I tried a self-hosted runner — and it managed to uninstall my Python while setting itself up. In the end I tunneled DataHub out to the runner, and it finally worked.
Accomplishments that we're proud of
It actually works — live, on real pull requests, not a mockup. Three PRs, three correct verdicts (❌ / ⚠️ / ✅), with real query and dashboard names pulled straight from DataHub. It writes back to the catalog. The bot doesn't just comment and leave — it tags the affected column in DataHub and drops a short doc, so the warning lives where the data lives. And it's smart about severity: on the same table, one column is "breaking" and another is "safe to merge" — because it looks at who actually uses each column, not just how many things are downstream.
What we learned
The real power of DataHub for an agent isn't reading metadata — it's having one shared source of truth you can read from and write back to. The moment the bot wrote its verdict back as a tag and a doc, it stopped being a linter and became part of the catalog. Also learned to keep the important parts deterministic. Every fact comes from DataHub, not from an LLM guessing — and that's what makes people actually trust the verdict.
What's next for Blast Radius
CDC / streaming — a change-event topic (Debezium) is another downstream thing CI can't see; we want to flag column drops that break a stream.
Backend code awareness — read a Kotlin @Entity class so a field rename in the app warns about a finance dashboard three systems away.
Log in or sign up for Devpost to join the conversation.