ContextPatch

A DataHub-grounded agent that reviews risky data changes, generates safe patches, verifies them, and writes decisions back.

Comment

ContextPatch

Inspiration

Data changes often look tiny in code, but the real blast radius lives somewhere else: dashboards, saved queries, ML features, downstream dbt models, owners, assertions, and governance metadata. That is exactly the kind of context an agent needs before it should be trusted to change a data platform.

ContextPatch was built for the DataHub Agent Hackathon to answer one question: what would it look like if an agent did not just generate code, but used DataHub to make a defensible data engineering decision?

What it does

ContextPatch is a metadata-aware change guardian for data teams. It reviews a proposed data change, reads live DataHub context through the DataHub MCP Server, explains the downstream impact, generates a safe remediation patch, verifies that patch with dbt and DuckDB, and records the decision back into DataHub.

The demo includes four reusable hackathon scenarios:

  • Rename customer identifier
  • PII field introduced
  • Freshness/assertion failure
  • Dashboard-breaking model change

Each scenario changes the proposed diff, the risk reasoning, the generated patch, the verification command, and the writeback payload. The point is that DataHub changes the agent's behavior: lineage changes risk, ownership changes review routing, assertions change whether the change should proceed, and writeback preserves the decision for the next human or agent.

How we built it

The local stack runs DataHub OSS with Docker Compose, then loads a dbt/DuckDB demo fixture with finance, marketing, ML, and dashboard consumers. ContextPatch connects to DataHub through the MCP Server and exposes the agent workflow through a Vinext/React dashboard.

The backend flow is:

  1. read the proposed schema/model change,
  2. fetch DataHub context through MCP,
  3. map downstream lineage and ownership,
  4. score the risk,
  5. generate a compatibility-safe remediation patch,
  6. verify the patch with dbt and DuckDB,
  7. preview and record the DataHub writeback decision.

The repository includes setup scripts, a demo script, an architecture diagram, validation commands, sample outputs, and a judging-criteria mapping.

Challenges we ran into

The biggest challenge was making the demo honest. It is easy to build a dashboard that looks like an agent; it is harder to show that DataHub is actually changing what the agent decides. To make that visible, ContextPatch includes multiple scenarios, live DataHub/MCP status, risk evidence, generated patch output, verification output, and writeback receipts.

Another challenge was keeping the whole experience runnable on a laptop. DataHub, MCP, dbt, DuckDB, and the app all need to work together locally without requiring hosted infrastructure.

Accomplishments that we are proud of

  • Live DataHub MCP integration
  • Scenario selector with four realistic data-change stories
  • Evidence-backed risk scoring
  • Compatibility-safe patch generation
  • dbt/DuckDB remediation verification
  • DataHub writeback preview and real local decision-document writeback
  • A polished judge path that can be run locally

What we learned

DataHub is most powerful for agents when it is treated as the shared context layer, not just a catalog UI. Code can tell an agent what changed. DataHub tells it who depends on that change, what quality signals already exist, who owns the asset, and what knowledge should be written back after the decision.

What's next

The next step is to connect ContextPatch to real pull requests so it can comment on risky data changes before merge, open compatibility patches, and record final review decisions back into DataHub automatically.

Built With

Share this project:

Updates