-
-
LineagePulse — the first responder your data graph actually wakes up to. Built for the DataHub Agent Hackathon 2026
-
The full test suite passing in 2.93s — 18/18 green. Real terminal, real pytest, real CI-ready code.
-
The live demo at lineagepulse.onrender.com — every route works in DRY_RUN mode with no DataHub or LLM credentials required.
-
A freshness violation auto-bumped to CRITICAL because an ML model is in the blast radius. DataHub's mlModel entity makes this structural.
-
The Apache 2.0 source on GitHub 18 tests, Dockerfile, Render config, full demo runbooks, 2 deterministic scenarios.
-
The Slack Block Kit message posted to the impacted owners severity, blast radius, root cause, suggested fix, all in one thread.
-
The structured incident Document written back to DataHub via save_document — the next agent inherits the knowledge.
Inspiration
When a dataset breaks in production, data engineers spend 90 minutes clicking through DataHub, copying owner emails, and pinging Slack channels. The failure is usually obvious in retrospect and the impact is usually obvious to whoever owns the lineage graph — but no agent is watching it. We built LineagePulse to be that agent.
What it does
LineagePulse is a multi-agent system that closes the full incident-response loop on top of DataHub's context graph.
Three cooperating sub-agents (Detector, Investigator, Responder)
read lineage, ownership, quality signals, and ML metadata via the
official datahub-agent-context SDK, walk the upstream and
downstream blast radius, and post a Slack message to the right
owners — all in under 60 seconds. The structured incident record
is then written back to the DataHub graph as a Document, so the
next agent that touches the same asset inherits the knowledge.
When the blast-radius walk finds an ML model in the downstream
graph, the agent automatically bumps severity to CRITICAL. A
broken dataset that feeds a production model is a different class
of incident than a broken dashboard, and the agent treats it
that way. DataHub's first-class mlModel entity makes this
inference structural rather than heuristic.
How we built it
- Detector — polls DataHub for failing assertions via
get_dataset_assertionsandsearch, produces a structuredIncidentobject. - Investigator — walks lineage with
get_lineage, attaches owner / domain / description / quality viaget_entities, and asks an LLM to author a root-cause + fix report. - Responder — writes the incident Document back to DataHub
using
save_documentand posts a per-owner Slack message with severity, blast radius, root cause, and a fix. Built on the same LangGraph-style orchestration pattern as DataHub's own open-source Analytics Agent. Apache 2.0, pip installable, 18 unit tests, full demo runbooks, and a deployed live demo.
Challenges we ran into
The hardest part was wrapping the official datahub-agent-context
LangChain tools behind a stable interface that worked in both
production and DRY_RUN mode (so judges could try it without
spinning up a DataHub instance). We solved this with a thin
abstraction that decouples the agent logic from the SDK, and a
test suite with mocked tool surfaces that verifies the right tool
is called with the right arguments.
The other challenge was ML lineage — making the agent understand
that an mlModel in the downstream graph means the incident is
production-critical. We solved this by making the severity bump
a property of the lineage walk itself, not a separate heuristic.
Accomplishments that we're proud of
Closed the read-write loop on DataHub — the agent doesn't just read the context graph, it writes incident Documents back so the next agent inherits the knowledge. The hackathon rubric explicitly rewards this property.
ML-aware severity bump — when the lineage walk finds an ML model in the downstream graph, severity automatically bumps to CRITICAL. A broken dataset that feeds a production model is a different class of incident than a broken dashboard, and the agent treats it that way using DataHub's first-class
mlModelentity.Three cooperating sub-agents with separate tool surfaces — Detector, Investigator, and Responder are independently testable, follow the same LangGraph pattern as DataHub's own Analytics Agent, and exchange state through a shared
Incidentobject.Production-shaped out of a hackathon build — Apache 2.0, pip-installable, 18 unit tests, full demo runbooks, Dockerfile, CI workflow definition, a deployed live demo on Render, and a 49-second screencast that runs in any browser.
Zero required credentials to try — judges can run the demo and inspect the full Slack / DataHub Document output without spinning up a DataHub instance, an LLM key, or a Slack workspace.
What we learned
The DataHub Agent Context Kit is genuinely production-shaped. The
save_document tool closes the read/write loop in a way most
catalog tools don't. We came away convinced that the right way
to build agents on top of a metadata platform is to treat the
graph as a read-write knowledge substrate, not a passive
index.
What's next for LineagePulse
- Schema-change detection (column adds / drops / deprecations)
- A GitHub PR responder that opens a fix-PR with the suggested dbt model
- A PagerDuty integration for SEV-1 incidents
- A small web dashboard showing the recent incident feed
Log in or sign up for Devpost to join the conversation.