LineageGuard

Turn DataHub metadata into a safety layer for AI-driven data changes. LineageGuard detects hidden impact, blocks unsafe changes, generates a safe migration, validates it, and opens a GitHub PR

Comment

Inspiration

The most dangerous data changes often look harmless. A one-line schema change can be perfectly safe inside one repository while silently breaking dashboards, ML pipelines, finance queries, and systems owned by other teams. As AI makes software delivery dramatically faster, we believe the next bottleneck is no longer generating changes — it is trusting them. That inspired LineageGuard: what if DataHub could become the organizational safety layer for AI-driven delivery?

What it does

LineageGuard combines a proposed code change with DataHub’s organizational context before deciding whether that change is safe. It turns metadata into action:

understand impact → block unsafe changes → propose a safer migration → validate it → open a reviewable PR → preserve the verified result in DataHub.

The goal is not another red CI gate. The goal is to help AI-driven teams move fast without flying blind.

Demo Note: Everything shown in the demo is grounded in a completed LIVE run: real GitHub PRs, real DataHub lineage, generated migration artifacts, executable validation results, and verified decision memory written back to DataHub.

How we built it

We deliberately separated AI reasoning from safety authority. DataHub provides lineage, usage, ownership, and ML context. An LLM proposes structured remediation, while deterministic policy makes the safety decision, executable checks validate the generated change, and humans retain final merge authority. The prototype connects DataHub OSS, its MCP Server, GitHub, TypeScript/Node.js, Next.js, PostgreSQL, dbt, Docker, and isolated validation into one closed loop.

Challenges we ran into

The hardest problem was not generating migration code — it was making the result trustworthy. We had to handle stale source changes, incomplete organizational context, ML and query dependencies, exact validated-vs-published artifacts, repeatable GitHub effects, and verified DataHub write-back. That pushed us toward an evidence-first architecture rather than an “LLM says it looks safe” architecture.

Accomplishments that we're proud of

We built a real end-to-end change-safety loop where DataHub context actually changes the outcome. A change that receives ALLOW from repository-only analysis becomes BLOCK after organizational impact is discovered — and the workflow continues to a validated, review-ready replacement instead of stopping at the warning. Most importantly, the result closes the loop by writing verified knowledge back to DataHub for the next human or agent.

What we learned

More autonomous AI is not automatically better AI. For high-impact engineering changes, we found a stronger model:

AI proposes → deterministic policy decides → executable checks verify → humans retain final authority.

We also learned that metadata becomes dramatically more valuable when agents can use it not just to answer questions, but to prevent incidents before they happen.

What's next for LineageGuard

The hackathon prototype proves the complete change-safety loop end-to-end on a production-style schema migration. The bigger idea is much broader. We want LineageGuard to become a safety layer for agentic CI/CD — protecting schema changes, data contracts, transformations, ML dependencies, and other changes whose true blast radius extends beyond a single repository.

AI makes change generation faster. LineageGuard aims to make trust scale with it.

Built With

Share this project:

Updates