Your catalog knows what it depends on. Not what it costs.
Data lineage maps what a change touches. Operational lineage shows how the jobs actually run. Callisto checks both on every pull request, before it merges.
Impact report for core.orders
Downstream (data lineage)
| Asset | Relationship |
|---|---|
| dbt · mart.orders_enriched | downstream |
| Tableau extract · revenue_daily | downstream |
| Reverse-ETL sync · orders_to_crm | inferred |
| Scheduled notebook · churn_features | downstream |
inferred = matched by name, not parsed from SQL
Runtime, V0046 → V0059 (operational lineage)
| Metric | Change |
|---|---|
| Bytes scanned | ↑ 4× |
| Result rows | unchanged |
| Result bytes | unchanged |
| Duration | ↑ longer |
01 · The gap
The change that looked clean
The PR changed a join. Lineage found four dependents, tests passed, same rows came out. Three days later the job was scanning 4× the bytes.
Data lineage, at merge time
The map
Which tables, models and dashboards depend on the thing you’re about to change.
Answered: “What reads this table?” Four things. None of them broke.
Operational lineage, three days on
The meter
How long a job actually ran, how many rows, how many bytes scanned, for its last run, compared to the run before it.
Answered, too late: “Why is this job scanning 4× the bytes?”
Without joining runtime metadata to data lineage, you can’t predict a change’s operational impact. Callisto combines both with code analysis to predict it before merge, without running anything.
02 · How it works
Two kinds of history. One comment.
Callisto reads how your jobs are connected and how they actually ran,
joins the two per job version, and posts the result on the pull request.
1Reads lineage
dbtOpenLineage
Column-level edges parsed from each job’s SQL
Snowflake
Tables, views and their dependencies
2Reads run history
AirflowSnowflake
Duration, rows and bytes scanned for every job version
Joins them per job
version
V0046
V0059
3Posts on the pull request
GitHubc
callisto commented · Impact report
for core.orders
4 downstream consumers
Bytes scanned↑ 4×
Runs as a GitHub App integration. Read-only outside the PR comments and suggested changes it posts.
Inside the report
-
dbt · mart.orders_enriched
order_idorder_total
-
Tableau extract · revenue_daily
order_totalorder_date
-
Scheduled notebook · churn_features
customer_idorder_date
-
Reverse-ETL sync · orders_to_crm
order_idcustomer_id
column-level
Every consumer, column-level
Parsed from each job’s SQL. No manual curation.
core.orders
revenue_daily
orders_to_crm
inferred · matched by name
Inferred edges are marked
Matched by name, not parsed, and drawn dashed, so you know how each edge was found.
Coverage
snowflake.coremapped
airflow.pipelinesmapped
s3.avro_exportsmapped
legacy_reportingnot yet mapped
Gaps shown, not hidden
Namespaces Callisto hasn’t mapped yet are listed in the report, not left out.
Runtime · V0046 → V0059
Duration↑ longer
Result rowsunchanged
Result bytesunchanged
Bytes scanned↑ 4×
Records read · raw.order_lines↑ higher
Bytes scanned
V0046V0059
Relative, illustrative.
Runtime, version against version
Duration, rows, result bytes, bytes scanned and records read per source, from warehouse and orchestrator run history.
Ask where you work
Follow-up questions in the PR, or in Slack, web chat and the CLI.
It reports what the run history returned, and doesn’t
guess. Read-only outside the comments it posts.
03 · Why it’s rare
Lineage and runtime live in different places.
Lineage comes from code and catalogs. Runtime comes from query history and run events, per job version. Most tools read one side.
Design-time
lineage tools
How everything is
declared to connect. Not
how any of it ran.
Bundled platform
catalogs
Great inside one platform.
Your estate isn’t in one.
Manifest-based
PR checks
At review, but bounded
to one tool and blind
to runtime.
Callisto
Both sides, per job version,
on the PR. Gaps shown,
not hidden.
Three kinds of tool. None of them reads runtime.
Illustrative estate.
The most common alternative
Building it yourself. It works until the estate changes.
Teams that hit this gap often build their own operational lineage. It’s the clearest sign the need is real, and a system someone has to keep matching an estate that doesn’t stop moving.
Homegrown
04 · Who it’s for
Who feels the gap first.
Each role asks a different question at review.
Callisto answers all three on the same pull request.
Data / analytics engineer
“If I merge this, what breaks, and what gets slower?”
Keeps them up
Being the person whose clean-looking change broke a dashboard, or quietly quadrupled a scan.
What they get
Downstream consumers, column-level, plus the runtime comparison, on the PR before review signs off. Follow-ups answered in the thread.
@callisto who reads order_total?
2 consumers read order_total:
Data platform lead / engineering manager
“Which change made this job scan 4× the bytes?”
Keeps them up
Velocity up, production stability down, and no way to prove which change caused which incident.
What they get
Change management that lives in review instead of in a meeting. A written record per pull request, runtime cost visible before merge, and a review bottleneck that does not grow with agent output.
@callisto where does the extra scan come from?
Records read from raw.order_lines rose between V0046 and V0059.
Data architect / enterprise data lead
“What does this change reach, and what isn’t mapped yet?”
Keeps them up
Committing to a migration plan built on an incomplete map of the estate.
What they get
Design-time and runtime lineage in one landscape, impact assessment per proposed change, point-in-time (ASOF) reads of how the estate looked, and an explicit list of what is not yet mapped.
@callisto which namespaces are mapped?
3 namespaces mapped, 1 not yet:
Evaluating this for clients? For consultancies and SIs
Join waitlist
See an impact report on
your own pull request.
Thirty minutes, your estate, one open PR. Callisto reads
GitHub and posts comments. It changes nothing else.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.
-
0–10 min
Connect
GitHubSnowflakeRead-only access to GitHub and
your warehouse -
10–20 min
Open one real PR
Pull request #[your PR]Callisto runs on a change you’re
already making -
20–30 min
Read the report together
Impact report for [your table]