Lineage and verifiability

Every DBT carries the IDs of the datasets it reads from. The project overview renders the full graph as a clickable DAG — sources on one side, derived tables and visualizations downstream. You don’t take any model’s word for what derived from what; the lineage is a row in the database you can read.

What counts as a parent

ST-1 parses every DBT’s SQL on save and records the tables it references. Sources, other DBTs, and WITH CTEs that resolve to project tables all show up as parents.

What happens when something upstream changes

• Edited DBT — re-materializes; downstream DBTs and visualizations re-read it on next render.
• Renamed dataset— DBTs that reference the old name break. ST-1 surfaces the breakage on each downstream DBT’s page rather than silently dropping rows.
• Deleted source — every downstream DBT breaks. The lineage view marks them so you can see the blast radius before confirming.

What the AI sees

The MCP get_dataset tool returns the SQL plus the list of parent dataset IDs. list_datasets includes the kind (source or dbt) so an AI can tell at a glance what sits where in the graph. Every transformation an AI runs leaves the same lineage rows a human edit would — they show up identically in the DAG.

Why this matters

Trust in AI analysis is mostly downstream of: can I reproduce what it did, can I see the chain, and can I check the numbers?SQL is canonical, lineage is explicit, every chart points at a real column. You don’t take the model’s word for it. You see what happened, and check it.