ChangeGraph

See hidden consumers before a schema change ships, then generate a cited, backward-compatible migration plan instead of guessing from one repository.

Comment

ChangeGraph

Inspiration

A column rename can look harmless inside one repository and still break the dashboard, query, model, or contract that lives somewhere else. Source search cannot see the whole data estate, and a confident code generator can turn that blind spot into a production incident.

ChangeGraph starts with a different rule: metadata evidence comes before code. It uses DataHub context to identify the exact field, traverse its cited impact graph, and expose the owners, policies, assertions, dashboards, queries, and ownerless consumers that a repository-only review misses.

What it does

For the demo request, "rename warehouse.orders.total to gross_total," ChangeGraph:

  1. confirms the exact DataHub URN;
  2. discovers 11 downstream or governed synthetic assets with evidence IDs;
  3. blocks a direct rename using deterministic rules;
  4. creates an expand-migrate-observe-contract plan;
  5. generates only the additive expand phase, keeping total and adding gross_total as an alias;
  6. validates citations, allowed files, destructive SQL, and the dbt project; and
  7. previews the draft PR and DataHub decision payloads without writing either one before entrant approval.

The human impact is review clarity. A data engineer can see who needs to act, which unknowns still block the change, and what can safely happen first instead of discovering hidden consumers after deployment.

How DataHub is used

The repository includes a real local DataHub Core path. The official Python SDK seeds synthetic schema and lineage, GraphQL verifies a structured read, and the official MCP server is probed for search, lineage, and schema tools with mutation tools disabled. The resettable browser demo uses a labeled fixture replay of that synthetic graph; it never presents the fixture as a production catalog.

How we built it

TypeScript, Zod, React, Vite, Playwright, Vitest, DataHub Core, the official DataHub Python SDK and MCP server, dbt-postgres, Postgres 16, and an independently validated Apache-2.0 Agent Skill.

Measured evidence

The ten-case frozen synthetic evaluation compares ChangeGraph with a schema-only baseline. The release gates require zero invented assets, full citation coverage for metadata-derived claims, successful safe-patch validation, and abstention for stale or incomplete metadata.

Challenges

The hardest boundary was separating real integration proof from a portable demo. A local DataHub stack can prove the SDK, API, and MCP path, but a public judge should not need credentials. The solution is explicit dual evidence: live local probes recorded separately, and a persistent fixture-replay label in the resettable UI.

We also resisted making the approval step theatrical. The project can show exact write payloads, but no agent-created click is represented as a human approval.

Honest limits

  • The public graph is synthetic and does not prove production coverage.
  • DataHub metadata can be stale, incomplete, or permission-limited.
  • Lineage indicates dependency, not runtime criticality.
  • The MVP targets a bounded dbt/Postgres rename workflow.
  • No draft PR or DataHub decision write has been executed because the required separate entrant approval is not recorded.
  • The project does not claim incident prevention.

What's next

With entrant approval, the exact previewed draft PR and idempotent DataHub decision record can be exercised against scoped credentials. A public deployment and a clean logged-out run remain the final delivery checks.

Built With

Share this project:

Updates