Inspiration
Every data team has lived this someone renames or drops a column upstream and nobody finds out until a dashboard shows a wrong number days later. DataHub already shows you lineage and impact but it stops at "here's what's affected." We built the agent that goes further trace the break and actually fix it.
What it does
Splint is a deterministic incident response pipeline for breaking schema changes. Given a schema diff, it:
- Resolves the affected DataHub asset and traces downstream lineage across platforms (Snowflake, dbt, Looker, Tableau)
- Identifies the blast radius and owners via DataHub's ownership metadata
- For dbt/SQL-remediable cases, generates a corrective patch
grounded only in real schema, lineage, and repo evidence and
validates it with real
dbt parse/dbt compile - Opens a real GitHub PR with the fix
- Reports (never fakes) impact on BI tools like Looker/Tableau, since there's no safe way to auto-patch those
- Writes the full incident record back into DataHub via
save_document, so the next engineer or agent inherits the context
How we built it
Built with Claude Code across 14 verifiable phases one deterministic orchestrator not a multi-agent swarm because reliability mattered more than sounding sophisticated. The DataHub MCP Server handles all reads and the write-back. The LLM is used in exactly two bounded places: patch generation and incident summarization both evidence constrained, so the model can't reference a table, column, or owner that wasn't actually retrieved from DataHub or the dbt repo.
Challenges we ran into
The biggest one wasn't code it was infrastructure. Running DataHub's full quickstart stack (Kafka, MySQL, OpenSearch, GMS, frontend) locally on an 8GB machine repeatedly hit real memory ceilings. We moved to a GitHub Codespace with more headroom to get a genuine, live DataHub instance running rather than fake the integration.
We also built and tested a hallucination guardrail for the patch generator and proved it works under real adversarial pressure: when prompted to fabricate a column, the underlying LLM complied, but our deterministic evidence binding check caught and rejected the fake output before it could ever reach a PR.
What we learned
That the safety mechanism mattering more than the model. Our guardrail doesn't depend on any one LLM behaving well it depends on code that verifies every claim against real, retrieved evidence. We proved that by swapping providers mid-build and watching the guardrail still hold.
What's next for Splint
Packaging as a GitHub Action so any team can drop it into a workflow with a few lines of YAML no server to host, no infrastructure cost.
Log in or sign up for Devpost to join the conversation.