For consultancies and SIs
Map the client’s estate in daysand leave it running
Callisto builds a column-level, cross-platform map of the estate from the metadata it already produces. After handover it stays behind as the tool the client’s team uses to check every change.
Estate coverage
client-estate
Single-tenant · read-onlyRead · 4
Seen, not mapped · 2
01 · The problem
Discovery is slow and manual,
and the map decays when you leave
Mapping a client’s estate by hand is slow, and it produces a deliverable that decays the moment the team leaves.
| Asset | Feeds | Status |
|---|---|---|
| raw.orders | stg_orders | Listed |
| stg_orders | ? | Listed |
| finance_weekly | ? | Listed |
| reverse-ETL sync | ? | Not found |
The inventory
Built by hand, asset by asset. Slow to assemble, and only as complete as what got found.
Slide 14 · Estate lineage
The deliverable
A lineage diagram in the handover deck. It is right on the day it ships.
Changes since handover
The decay
The estate keeps changing after the consultancy leaves. The map doesn’t, and the client stops trusting it.
02 · Engagements
Three kinds of engagement,
one estate to map first
AI transformation, migration and governance work all start in the same place: what is in the estate, and what depends on what.
The client asks
“What depends on this before we move it?”
What goes wrong
Committing to a migration plan built on an incomplete map, then finding a dependency after the cutover.
What you hand over
Design-time and runtime lineage in one cross-platform graph, read as of any date, so the estate can be compared before and after the cutover.
The client asks
“Can the client’s team ship AI-written pipeline code without breaking production?”
What goes wrong
Agents write a correct change for the problem in front of them and cannot see what it breaks three systems away.
What you hand over
An impact report on every GitHub pull request, including how the job behaves in the new version, in the thread where the client’s team reviews.
The client asks
“Will the client still trust this map a year from now?”
What goes wrong
A catalog that is stale, absent or kept in a spreadsheet, and nobody able to prove which change caused what.
What you hand over
Versioned metadata history with point-in-time reads, and every system Callisto sees but does not cover listed as not mapped.
03 · How discovery works
Four steps from read-only access
to a map of the estate
Callisto builds the map from metadata the estate already produces, and marks how sure it is about each link.
Step 01
Connect to the estate, read-only
Callisto reads OpenLineage, Snowflake and Avro on S3 into one cross-platform catalog. Each deployment is single-tenant.
Step 02
Derive column lineage from each job’s SQL
Column-level lineage comes from parsing the SQL of each job, with no manual curation and nothing to rebuild by hand.
Step 03
Mark the links it cannot confirm
Edges matched by name are marked inferred and drawn dashed, so the client can see which links were parsed and which were inferred.
Step 04
List the systems it does not cover
Namespaces that appear in the metadata without a mapping are listed as not yet mapped, so everyone sees where coverage stops.
04 · The difference
From a deliverable that decays
to a tool the client keeps using
A hand-built map is right on the day it ships. Callisto keeps reading the estate after you hand over.
4 documents · 0 updates
Still in use after the engagement ends.
1 deployment · still in use
05 · How an engagement runs
Connect, map,
and hand over something that keeps running
Step 01
Connect
Point Callisto at the client’s estate. It reads metadata, lineage and run history, and nothing else.
- Read-only outside the comments it posts
- Single-tenant: one deployment per client
Step 02
Map
Callisto builds the column-level map across platforms and says where it stops.
- Column-level lineage, no manual curation
- Inferred edges marked and drawn dashed
- Unmapped namespaces listed as gaps
3 downstream columns. orders_ingest scans 4x the bytes on v8.
Step 03
Hand over
The client’s team keeps the map and gets an impact report on every pull request.
- Reports in the GitHub pull request thread
- Questions in Slack, web chat or the CLI
- Stays with the client after handover
06 · Is this you?
Where it fits, and where it doesn’t
Fits
- Boutique data consultancies delivering AI transformation, migration or governance engagements.
- Client estates on Snowflake, plus at least two other platforms.
- Clients with something consuming data outside the warehouse: BI, reverse-ETL, notebooks or applications.
- Clients reviewing pipeline code in GitHub pull requests.
- Engagements where the map has to outlast the handover.
Not a fit
- Client estates on a single platform.
- Small client teams where one person holds the whole picture.
- Clients on GitLab, Bitbucket or Azure DevOps. The pull request flow is GitHub only today.
- Clients that prohibit AI tooling outright. A local-model story is coming.
- Engagements that need a data catalog, a glossary, data quality monitoring or data diffing. Those are different products.
Callisto maps the estate and reports what a change will affect. It does not apply fixes: it is read-only outside the comments it posts.
Evaluating it for your own team? →See how Callisto tells you what a change will break, across every platform, before it lands.07 · FAQ
Questions consultancies ask
before an engagement
It takes over the mapping. Callisto derives column-level lineage by parsing each job’s SQL, with no manual curation, across OpenLineage, Snowflake and Avro on S3, and joins it to runtime data from job runs. Your team spends its time on what the map shows rather than on building it.
Callisto itself, running on their estate: impact reports on every GitHub pull request, the cross-platform lineage graph, versioned history with point-in-time reads, and questions answered in the pull request thread, Slack, web chat or the CLI.
OpenLineage, Snowflake and Avro on S3, plus GitHub for pull requests. Systems that appear in the metadata without a mapping are listed as not yet mapped, so the gaps are visible from the start.
Column lineage is derived by parsing each job’s SQL. Edges matched only by name are marked inferred and drawn dashed, so the client can tell a parsed link from an inferred one.
No. Callisto is single-tenant by design, so each client estate gets its own deployment.
No. Callisto reports what a change will affect. It does not apply the fix: it is read-only outside the comments it posts.
GitHub only today. The pull request flow does not support GitLab, Bitbucket or Azure DevOps yet.
No. Callisto does metadata, lineage and runtime impact. It is not a data catalog, a glossary, data quality monitoring or a data diffing tool.
Join waitlist
Bring one client estate.
Thirty minutes, read-only. Callisto maps it with you and changes nothing.
0–10 min
ConnectA client estate, or your own sandbox: GitHub, Snowflake and OpenLineage data, read-only.10–20 min
Walk the mapColumn-level lineage, inferred edges and what isn’t mapped yet.20–30 min
Read one pull request reportWhat the client’s team gets on every change after handover.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.