OpenLineage runtime dataturned into change impact
Callisto joins the run data your pipelines emit through OpenLineage to column-level lineage across platforms, so every pull request shows what it breaks and how the job behaves after the change.
Rows returned stayed at 18,420 on every run. Duration went from 38 s to 51 s.
Where the change lands
01 · The problem
Design-time lineage and runtime data
live in different tools
The catalog, the pull request and your OpenLineage run history each hold a piece. Nobody joins them before the merge.
| Name | Type | Runtime |
|---|---|---|
| finance_weekly | Dashboard | None |
| mart.revenue_daily | Table | None |
| stg_orders | Model | None |
| raw.orders | Table | None |
The catalog
Shows what depends on what. It draws the shape of the estate and says nothing about how a job behaves when it runs.
The pull request
Shows the lines that changed. It does not show how the job behaves once the change is live.
The run history
Records what ran. None of it is tied to the columns or the pull request under review.
02 · Who it’s for
Three readers ask three questions
of the same lineage
Engineers, platform leads and architects each ask something different of the same graph.
Asks
“Will this change break something I have never heard of?”
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
The downstream columns across platforms, and how the job behaves in the new version, in the pull request thread.
Downstream of stg_orders
mart.revenue_daily.revenuefinance_weekly.net_revenueorders_ingestAsks
“Which change made this job scan more data?”
Keeps them up
Velocity going up while stability goes down, with no way to prove which change caused what.
What they get
Runtime numbers from two job versions side by side: duration, rows returned, bytes returned, bytes scanned and records read per source.
Asks
“What is in our estate that nobody has mapped?”
Keeps them up
Committing to a migration plan built on an incomplete map, then finding a dependency after the cutover.
What they get
Design-time and runtime lineage in one graph, plus the systems Callisto sees in OpenLineage events but does not yet cover.
03 · How the graph is built
Four steps from OpenLineage events
to column-level lineage
Callisto reads what your pipelines already emit and marks which links it parsed and which it inferred.
Step 01
Read runs and datasets from OpenLineage
Callisto ingests the OpenLineage data your platforms produce, with Snowflake metadata and Avro on S3, into one cross-platform catalog.
Step 02
Derive column lineage from each job’s SQL
Callisto parses the SQL of each job to get column-level lineage, with no manual curation and no dependence on the OpenLineage column lineage facet.
Step 03
Mark the edges it cannot confirm
Edges matched by name are marked inferred and drawn dashed, so you can see which links were parsed and which were inferred.
Step 04
Flag the systems it is not covering
Namespaces that appear in OpenLineage events without a mapping show up as not yet mapped, so you can see where coverage stops.
04 · The difference
From which assets break
to how the job behaves
Design-time lineage tells you what a change touches. Callisto adds how the job behaves in the new version.
4 assets · 0 numbers
Same rows returned, four times the bytes scanned.
1 report · assets and runtime
05 · How it works
Open a pull request,
read the report in the thread
Step 01
Open a pull request
Callisto starts from the pull request your team already opens.
- A GitHub webhook starts the analysis
- GitHub is the only source control system supported today
Step 02
Compare job versions
The agent reads lineage and OpenLineage run metrics for the job before and after the change.
- Column-level lineage across platforms
- Duration, rows, bytes and bytes scanned per job version
- Records read from each source
3 downstream columns. orders_ingest scans 4x the bytes on v8.
Step 03
Read the report
The impact report lands in the pull request thread. You can also ask in Slack, web chat or the CLI.
- Affected columns, with inferred edges marked
- The runtime comparison between the two job versions
- 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 reports what a change will affect and how the job behaves after it. It does not 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
Callisto reads the OpenLineage data your platforms produce and combines it with Snowflake metadata and Avro on S3 in one cross-platform catalog. It uses the run data to compare how a job behaves between two versions, and joins that to column-level lineage so a pull request shows both what it touches and how the job behaves.
No. Callisto parses the SQL of each job to get column-level lineage, so it doesn’t depend on the facet being emitted.
Duration, rows returned, bytes returned, bytes scanned and records read per source, for two versions of the same job side by side.
Edges matched by name are marked inferred and drawn dashed, so a reviewer can tell a parsed link from a guess. Systems Callisto can’t read yet show as not mapped.
They show up as not yet mapped when they appear in events without a mapping, so you can see where coverage stops.
No. Callisto reports what a change will affect. It doesn’t apply the fix: it is read-only outside the comments it posts.
GitHub only today. The pull request flow doesn’t support GitLab, Bitbucket or Azure DevOps yet.
In the pull request thread where the report is posted. You can also ask in Slack, web chat or the CLI.
Join the waitlist
Bring one pull request.
Thirty minutes, your estate, one change you have shipped. Callisto traces it with you and changes nothing.
0–10 min
ConnectGitHub, Snowflake and your OpenLineage data, read-only.10–20 min
Pick one pull requestA change that touched a job or a model.20–30 min
Read the report togetherAffected columns, the runtime change and inferred edges.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.