OpenRename customer_id
stg_orders.sql+1 −1
2order_id,
3−customer_id,
3+customer_id as cust_id,
4amount,
5from raw.orders
The diff
Shows the line that changed. It says nothing about who reads that column downstream.
PR impact analysisbefore you merge
Callisto reads every GitHub pull request against column-level lineage and runtime metrics, then posts what the change will break in the PR thread.
app.callisto.example/pull-requests/482
PR #482Rename customer_id to cust_id3 readers breakstg_orders.customer_iddbt model · column
ANALYTICS.ORDERSSnowflake · table?
mart.revenue_by_regionSnowflake · table?
Revenue by regionTableau · extract?
churn_featuresNotebook · name match
Column renamed in this PRcustomer_id → cust_id · stg_orders
orders_daily ran on V0046
Inferred
A one-line rename. Who reads customer_id?
Breaks
ANALYTICS.ORDERSmart.revenue_by_regionRevenue by regionRuntime
stg_orders V0046 → V0059
Also read by
churn_features Inferred
Reads the estate you already haveGitHubSnowflakeOpenLineagedbtAirflow
01 · The problem
When AI writes the change,
the impact sits in three places
The diff, the catalog and the warehouse each hold a piece. The reviewer sees the diff, and agents now write more of them.
customer_id
| Name | Type | In this PR |
|---|---|---|
| stg_orders | dbt model | Not shown |
| ANALYTICS.ORDERS | Table | Not shown |
| mart.revenue_by_region | Table | Not shown |
| Revenue by region | Extract | Not shown |
The catalog
Lists what depends on what as it stands today. It has no view of a change that hasn’t merged.
stg_orders
| Run | Status | Bytes scanned |
|---|---|---|
| Thu 23:45 | Success | |
| Wed 23:45 | Success | |
| Tue 23:45 | Success | |
| Mon 23:45 | Success |
The warehouse
Records what a job scanned after it ran. By the time it shows a jump, the change is already live.
02 · Who it’s for
Built for whoever reviews the PR
Two people look at the same PR and ask different questions. Callisto answers both in the PR thread.
Asks
“What will this rename break?”
Keeps them up
Merging something that breaks a dashboard they have never heard of, then being the person who renamed the column.
What they get
Every downstream reader of the column across platforms, before review starts, and how the new job version runs.
3 readers depend on customer_id
models
stg_orders
stg_users
mart_revenue
schema
stg_orders.sql
1select
2 order_id,
3- customer_id,
4+ customer_id as cust_id,
5 amount,
6from raw.orders
Readers of customer_id
ANALYTICS.ORDERSmart.revenue_by_regionRevenue by regionAsks
“Which of our changes reach other teams’ work?”
Keeps them up
Finding out a change reached another team from that team, after the merge, with no record of who reads what.
What they get
One report on every pull request: what breaks, in which platforms, and which links are only inferred.
Readers of customer_id4 readers · 3 platforms
SnowflakeANALYTICS.ORDERSparsed
Snowflakemart.revenue_by_regionparsed
TableauRevenue by regionparsed
Notebookchurn_featuresinferred
Edges matched by name are marked inferred.
03 · How the report is built
Four checks, one pull request
Callisto’s agent reads the diff, lineage, versioned history and runtime metrics for every PR, then writes one report.
Start at the changed column and follow it through every table, job and extract that reads it. Lineage is parsed from each job’s SQL. Edges matched by name are marked inferred, and systems Callisto can’t read yet show as not mapped.
Callisto compares each affected job’s runtime metrics between versions. A new version that scans four times the bytes of the last one shows up in the report before it ships.
Versioned metadata history is read as of any point, so the report compares the change against what was true on the day, not only against today’s catalog.
One comment lands in the pull request: what breaks, how the job will run, and what to check by hand. It is read-only, so it posts comments and changes nothing.
CallistoLineagePull requestsOwners
stg_orders.customer_id
UpstreamDownstream
stg_ordersorder_idcustomer_idamountcreated_at
ANALYTICS.ORDERSorder_idcustomer_idregiontotal
mart.revenue_by_regionregioncustomer_idrevenue
churn_featurescustomer_idtenure
Inferred
Parsed from SQL
Inferred from a name match
stg_orders.customer_idDownstream readers (4)
ANALYTICS.ORDERSSnowflake · table
mart.revenue_by_regionSnowflake · table
Revenue by regionTableau · extract
churn_featuresNotebook · inferred
Changed in PR #482
Parsed from SQL
04 · The difference
From four tools to one comment
Without Callisto a reviewer checks the catalog, the orchestrator, query history and the BI tool by hand, for every pull request.
Without Callisto
CatalogWho reads this column?
OrchestratorWhich jobs run this model?
Query historyWhat the job scans today?
BI toolWhich dashboards use it?
?Checked by hand, every pull request
4 tools · 0 joins
With Callisto
Rename customer_id to cust_id #482
Openwants to merge 1 commit into main
ConversationCommitsChecksFiles changed
callisto bot 2 minutes ago
Renaming customer_id breaks 3 readers: ANALYTICS.ORDERS, mart.revenue_by_region and the Revenue by region extract. churn_features matches by name only.
TRACE
✓ 2 reactionsstg_orderscustomer_idANALYTICS.ORDERSRevenue by region
Parsed from SQL · V0046 → V0059 · scans 4x the bytesReply to @callisto
1 pull request · 1 comment
05 · How it works
Open, trace, report in one PR
Title
Rename customer_id to cust_id
Description
Align naming with the users model.
Webhook · callistoCreate pull request
Step 01
Open
Your team opens a pull request on GitHub the way it already does.
- A GitHub webhook starts the workflow
- No new step in your review process
- Parsing the changed SQL
- Walking downstream
- Comparing job versions
- Mapping readers
Step 02
Trace
Callisto reads lineage, metadata history and runtime metrics together.
- Lineage, parsed from each job’s SQL
- Runtime metrics across job versions
- Versioned history, read as of any point
- Reads Snowflake, OpenLineage providers, dbt, Airflow and GitHub
IMPACT REPORT
stg_orders.customer_idrenamedBREAKS
ANALYTICS.ORDERS+2RUNTIMEscans 4x the bytes
CHECK
churn_featuresinferredPosted to PR #482
Step 03
Report
You get what breaks, how the job will run, and what to check by hand.
- Every downstream reader of the changed columns
- Runtime change between job versions
- Systems not covered yet, named in the report
- Read-only: it posts comments and changes nothing
06 · Is this you?
Where it fits, and where it doesn’t
Fits
- Snowflake, plus at least two other platforms.
- Something consumes data outside the warehouse: BI, reverse-ETL, notebooks or applications.
- Airflow, Dagster or similar, and more than one team touching the same tables.
- Pipeline code reviewed in GitHub pull requests.
- Engineers using AI coding tools on pipeline code.
Not a fit
- Single-platform shops.
- Small teams where one person holds the whole picture.
- Teams on GitLab, Bitbucket or Azure DevOps. The pull request flow is GitHub only today.
- Organisations that prohibit AI tooling outright. A local-model story is coming.
- Anyone looking for a data catalog, a glossary or data quality monitoring. Those are different products.
Callisto shows what a change will break. It doesn’t apply the fix: it is read-only outside the comments it posts.
For consultancies and SIs →Faster estate discovery, and a tool the client keeps using after handover.07 · FAQ
Questions teams ask before they try it
It checks a pull request against everything downstream of the code it changes, before the merge. Callisto traces the change through column-level lineage, compares runtime metrics between job versions, and posts the result as a comment in the PR.
GitHub only today. The pull request flow doesn’t support GitLab, Bitbucket or Azure DevOps yet.
No. Callisto shows what a change will break. It doesn’t apply the fix: it is read-only outside the comments it posts.
Callisto reads metadata, lineage and run history. It is a single-tenant deployment and read-only outside the comments it posts.
It compares how a job runs across versions, such as the bytes scanned. A new version that scans four times the bytes of the last one shows up in the report.
Snowflake, OpenLineage providers, dbt, Airflow and GitHub.
Edges matched by name are marked inferred, and systems Callisto can’t read yet show as not mapped. A reviewer can tell a fact from a guess.
In the pull request thread, where the report is posted.
Join the waitlist
Bring your next pull request.
Thirty minutes, your estate, one change you’re about to merge. Callisto reads it with you and changes nothing.
0–10 min
ConnectGitHub, Snowflake, dbt and Airflow, read-only.10–20 min
One pull requestA change your team is about to merge.20–30 min
Read the report togetherWhat breaks, how the job runs, and what is inferred.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.
Reads the estate you already haveGitHubSnowflakeOpenLineagedbtAirflow