net_revenue
| Name | Type | Changed |
|---|---|---|
| net_revenue | Dashboard | — |
| mart.revenue_daily | Table | — |
| stg_orders | dbt model | — |
| raw.orders | Table | — |
The catalog
Shows what depends on what, as it stands today. Not what changed on Friday.
Root cause analysisfor data incidents
Callisto walks back from the symptom through column-level lineage, versioned metadata history and Datadog logs, to the change that caused it.
app.callisto.example/investigate
net_revenueDropped Mondayorders_ingestAirflow · daily 23:45?
raw.ordersSnowflake · table?
stg_orders.amountdbt model · column?
mart.revenue_dailySnowflake · table?
net_revenueDashboard · Finance
Definition changedv13 → v14 · Fri → Mon
Sunday run succeeded
Inferred
Ten merges since Friday. Which one?
Cause
stg_orders.amount v13 → v14
Ruled out
orders_ingest
Also read by
customer_ltv.valueorders_weekly.grosschurn_features.aovReads the estate you already haveGitHubSnowflakeOpenLineagedbtAirflowDatadog
01 · The problem
When a number moves,
the answer is in four places
The catalog, the orchestrator, the warehouse’s query history and the logs each hold a piece. Nobody joins them before the next standup.
orders_ingestActive
| Run | State |
|---|---|
| Sun 23:45 | Success |
| Sat 23:45 | Success |
| Fri 23:45 | Success |
| Thu 23:45 | Success |
The orchestrator
Says the job succeeded. It does not say the calculation downstream of it moved.
service:orders_ingest
INFOextract_orders started
INFOextract_orders finished
INFOloaded raw.orders
INFOrow count check passed
The logs
Show the run was clean. They say nothing about which column a change touched.
02 · Who it's for
Built for whoever gets the 9am message
Two people read the same broken number and ask different questions. Callisto answers both in the thread.
Asks
“Which change broke
this number?”
Keeps them up
Merging something that breaks a dashboard they have never heard of, then being the person whose change it was.
What they get
The column, the version and the day it changed, the other readers it hit, and the run that rules ingestion out.
3 readers depend on amount
models
stg_orders
stg_users
mart_revenue
schema
stg_orders.sql
1select
2 order_id,
3- amount,
4+ amount − refund_amount as amount,
5 created_at
6from raw.orders
Readers of amount
customer_ltv.valueorders_weekly.grosschurn_features.aovAsks
“Who else needs to know before we change this?”
Keeps them up
Hearing about a broken number from the finance lead before hearing it from the tools, with no record of which change reached which team.
What they get
One answer in the incident thread: the cause, the version it landed in, and every other reader of the column, checked on every change.
Readers of stg_orders.amount5 readers · 4 systems
dbtmart.revenue_dailyparsed
Snowflakefinance_weekly.net_revenueinferred
dbtcustomer_ltv.valueparsed
dbtorders_weekly.grossparsed
dbtchurn_features.aovparsed
Edges matched by name are marked inferred.
03 · How the trace is built
Four checks, one context
Callisto’s agent reaches the catalog, lineage, versioned history and Datadog logs in a single turn.
Start at the dashboard column and walk back through every table, job and source that feeds it, at column level. Column 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 yet mapped.
Pick any two versions of a column or model and see what changed between them. Versioned metadata history is read as of that point, so Friday’s definition is still there on Monday.
Match each job run to the Datadog logs for the same window, so a clean run can be ruled out in one step instead of reading through log lines.
From the changed column, list every other reader downstream: the tables, dashboards and features that select it, with inferred edges marked as inferred.
CallistoLineagePull requestsOwners
net_revenue
UpstreamDownstream
Inferred
stg_ordersorder_idamountrefund_amountcreated_at
mart.revenue_dailydayrevenueorder_countregion
finance_weeklyweeknet_revenueordersregion
raw.ordersorder_idamountcreated_at
orders_ingestAirflow · daily 23:45
Parsed from SQL
Inferred from a name match
100%
stg_orders.amountUpstream sources (3)
raw.ordersSnowflake · table
amountraw.orders column
orders_ingestAirflow · daily 23:45
Open traceChanged v13 → v14, Fri
Parsed from SQL
04 · The difference
From four tabs to one answer
Without Callisto you join the catalog, Git, query history and logs by hand.
Without Callisto
CatalogWhat depends on what?
CommitsWhich merge landed?
Query historyWhat ran, and when?
Log explorerWhat each run said?
?Joined by hand, every time
4 tools · 0 joins
With Callisto
Finance workspace
data-incidents
finance
analytics
platform
# data-incidents
PK
Priya K. 9:04 AM
@callisto why did net_revenue drop on Monday?
Callisto APP 9:05 AM
Likely cause: stg_orders.amount changed Fri → Mon.
Sunday’s orders_ingest run was clean.
Three other columns read it.
TRACE
✓ 2 reactionsorders_ingestraw.ordersamountrevenue
Parsed from SQL · v13 → v14Message #data-incidents
1 thread · 1 answer
05 · How it works
Ask, trace, answer in one thread
CallistoAPP
@callisto why did net_revenue
drop on Monday?
BISend
Step 01
Ask
Ask in the channel where the incident already is.
- Slack, the pull request thread, web chat or the CLI
- In plain words, where the incident is already being discussed
- Walking upstream
- Comparing versions
- Checking Datadog
- Mapping readers
Step 02
Trace
Callisto reads lineage, metadata history and Datadog logs together.
- Lineage, parsed from each job’s SQL
- Versioned history, read as of any point
- Datadog logs for the run
- Reads Snowflake, OpenLineage providers, dbt, Airflow and GitHub
LIKELY CAUSE
stg_orders.amountv13 → v14Calculation changed Fri, live Mon.
Ruled out
orders_ingestrun cleanAlso read by
customer_ltv.valueorders_weekly.grosschurn_features.aovCopy as postmortem
Step 03
Answer
You get the change, when it landed, and what else it touched.
- The change, the version and when it landed
- What was ruled out
- Every other reader of the column
- 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.
- Engineers using AI coding tools on pipeline code.
Not a fit
- Single-platform shops.
- Small teams where one person holds the whole picture.
- 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 finds the cause and where to fix 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
You bring the symptom, such as a number that moved. Callisto’s agent walks back through lineage, versioned history and Datadog logs to the change most likely responsible.
No. You bring the incident, such as a number that moved and the day it did, and Callisto investigates it. It does not monitor your data or raise alerts.
No. Callisto finds the cause and where to fix it. It is read-only outside the comments it posts, so your engineers make the change.
Callisto reads metadata, lineage and run history, plus the Datadog logs for the run. It is a single-tenant deployment and read-only.
Snowflake, OpenLineage providers, dbt, Airflow and GitHub, plus Datadog logs for the run.
Edges matched by name are marked inferred, and systems Callisto can’t read yet show as not yet mapped. A reviewer can tell a fact from a guess.
Pull request comments work on GitHub today. GitLab, Bitbucket and Azure DevOps are not supported yet.
In Slack, the pull request thread, web chat or the CLI. Ask in plain words, in the channel where the incident is already being discussed.
Join the waitlist
Bring your last incident.
Thirty minutes, your estate, one incident you have had. Callisto traces it with you and changes nothing.
0–10 min
ConnectGitHub, Snowflake, Airflow and Datadog, read-only.10–20 min
One incidentA number that moved, and the day it did.20–30 min
Read the trace togetherThe cause, what was ruled out, and who else is affected.
Single-tenant deployment. Callisto reads metadata, lineage and run history. It is read-only outside the comments it posts.
Reads the estate you already haveGitHubSnowflakeOpenLineagedbtAirflowDatadog