REROUTE — Supply-Chain Incident Response on DataHub

A supply chain is a lineage graph. When a node fails, REROUTE maps the blast radius, finds the reroute, and writes the incident back to DataHub ,so the graph always tells the truth.

Comment

Inspiration

Data teams find out about broken pipelines the same way supply chain teams find out about broken suppliers: downstream, too late, from someone angry. While exploring DataHub for this hackathon, something clicked. Lineage, ownership, incidents. These aren't just data catalog concepts. A physical supply chain maps onto them almost one to one. A factory is a dataset. A goods flow is lineage. A plant manager is an owner. A port shutdown is an incident.

So instead of bolting a dashboard onto a database, I made DataHub itself the metadata backbone of a supply chain, then put an agent on top that does the work a war room usually does.

What it does

REROUTE keeps a live digital twin of a supply chain inside DataHub. When something breaks, it answers the three war room questions in seconds.

What's affected? Click any node to fail it, or let the monitoring agents flag one. A deterministic breadth-first traversal over the lineage DAG computes the blast radius: every downstream node, weighted by business impact and hop distance. No LLM guessing here. It's graph math.

Who owns it? Ownership lives in DataHub, so REROUTE knows immediately which owners to notify. These are real corpUser profiles grouped under a Supply-Chain domain, not strings in a config file.

What's the reroute? Weighted Dijkstra finds alternate paths around the failed node, with the cost and time trade-off per lane. In the demo, when the Port of Singapore fails, the Malaysia to Dallas lane recovers via the Hong Kong air hub: $2,800 more, sixteen days faster. The Rotterdam lane has no alternative, so it gets flagged severed with severity High.

Then the part I care most about. REROUTE writes everything back. The disruption becomes a real DataHub incident carrying the full rationale. Impacted assets get tagged. DataHub's own health banner starts warning downstream consumers. When the operator actions the reroute, REROUTE resolves the incident. Full lifecycle, raise to resolve, all in the graph. The next person (or agent) inherits everything.

One more thing: every sentence of the agent's explanation cites the DataHub URN it came from, with a confidence score computed from lineage completeness. If the graph is incomplete, it says "needs human review" instead of bluffing. The AI explains; the math decides.

How I built it

The agent reads DataHub through the official DataHub MCP Server (get_lineage over stdio), with direct GMS GraphQL as an automatic fallback. Before acting, it cross-checks DataHub's lineage against its own local computation.

Writes go through the OpenAPI entities endpoint (datasets, lineage, ownership, domains, corpUsers, tags, institutional-memory backlinks, plus a custom reroute platform) and GraphQL mutations: raiseIncident, addTags, updateIncidentStatus, updateDescription.

The deterministic core, blast radius and reroute, is pure TypeScript graph code with 59 unit tests. The app is Next.js 16 + React, with a hand-rolled layered-DAG SVG renderer for the lineage UI. Monitoring agents run on Google ADK + Gemini, and Supabase stores user supply chains. The public demo twin runs database-free, so judges can try everything with zero login.

Challenges

The honest one: DataHub rejected my first live write-back because tags must exist as entities before you can attach them. The docs don't shout about that. Live-testing against a real quickstart instance caught it, along with one wrong GraphQL input type. That's exactly why the whole flow is verified end to end against a running DataHub instead of mocks.

The design challenge was trust. LLM narratives sound right even when they're wrong. I ended up inverting the architecture: algorithms produce every fact, the narrative must cite a URN for every claim, and weak grounding gets flagged for humans.

What I learned

DataHub's aspect model is expressive enough to be a general operational graph, not only a data catalog. Ownership plus lineage plus incidents turn out to be exactly the primitives incident response needs, in any domain, not just data pipelines.

What's next

Node-health assertions so DataHub's UI shows red/green health natively. Slack notifications driven by the Ownership aspect. And MCP tools so any agent, not just mine, can ask "what breaks if this node fails?"

Disclosure (pre-existing code)

Everything in this repository was built during the hackathon window. This is a new repository with no pre-existing codebase behind it.

Built With

Share this project:

Updates

Submission history