Inspiration
Schema changes can look harmless in a pull request but fail far downstream. A single dbt column rename can break finance models and dashboards, while ordinary impact reports stop at describing the blast radius. I built LineageGuard to turn DataHub context into tested migration work and leave a durable result in the catalog.
What it does
LineageGuard accepts compiled before-and-after dbt manifests and normalises the schema change. It verifies the catalog baseline through DataHub, follows downstream column lineage, retrieves ownership and assertion evidence, and applies a deterministic, fail-closed risk policy.
For a supported rename, it creates a bounded compatibility bridge, deprecation metadata and an equality test inside a temporary project. It runs dbt seed, parse and build, then compares the compiled future with the original contract and calculates the residual risk.
Finally, LineageGuard writes the original and residual scores, decision, remediation state, source commit, evidence seal, decision tag and change passport back through the DataHub MCP Server. It reads the required state back before marking the writeback VERIFIED.
How I built it
LineageGuard is a Python CLI built around DataHub Core v1.6.0 and the official DataHub MCP Server v0.6.0. SQLGlot supports bounded SQL analysis and generation. dbt and DuckDB provide the reproducible build environment. FastAPI and Jinja provide the read-only change review interface.
The stable MCP release provides the main schema, lineage, ownership, mutation and readback flow. A narrow read-only GraphQL adapter retrieves native DataHub Assertion definitions that are not exposed by the pinned MCP release.
Challenges I ran into
A successful dbt build does not prove backward compatibility, so LineageGuard compares the newly compiled manifest with the original contract before accepting remediation.
DataHub projections can lag after a mutation. The writeback therefore uses a two-phase PENDING-to-VERIFIED protocol, exact document identity, bounded read-only retries and no blind mutation replay.
MCP capabilities can vary with the connected DataHub version. LineageGuard discovers tools at startup and fails closed when required evidence is unavailable, incomplete or ambiguous.
Accomplishments that I'm proud of
The retained run proves the complete loop against live DataHub Core and the official MCP Server. The original rename scores 88/100 BLOCK. The generated compatibility bridge passes dbt seed, parse and build, preserves the original interface and leaves a 12/100 PASS residual. The final PASS_WITH_REMEDIATION passport reads back as VERIFIED.
The repository includes 528 offline tests, three dbt and DuckDB integration tests, a live Core and MCP writeback-readback test, an Apache-2.0 license, reproducible setup instructions and sealed sample evidence from the verified run.
What I learned
Lineage is most useful when every decision remains tied to exact evidence. Owners, assertions and downstream assets must not be inferred or silently substituted. Testing the patch, inspecting the compiled future and reading the final catalog state back are separate proofs, and each one matters.
What's next for LineageGuard
The next step is to support more bounded schema-change patterns while keeping deterministic verification and fail-closed behaviour. I would also add provider-specific pull-request adapters, richer CI annotations and upstream fixes for the MCP assertion and lineage pagination gaps reproduced during development.
Log in or sign up for Devpost to join the conversation.