The Impact Guardian

• 

  The Impact Guardian - Proves a data fix is identical to the penny, or refuses to ship it.

• 

  One screen: DataHub's lineage graph on the left, the agent's live work on the right. Propose a change, then press Test the Gate.

• 

  After the wrong fix, nothing errors and the graph goes quiet. Every ordinary check passes, and the numbers still can't be proven.

• 

  The blast radius, everything downstream broken. Real binder errors from a real query engine, not a language model's prediction.

• 

  The agent reads the blast radius through DataHub's own MCP server: nine downstream entities across four hops, then detonates the change.

• 

  The correct fix restores the filter. All four consumers reproduce the baseline exactly, same totals, same hash. Write-back unlocked.

• 

  Renaming one column breaks all four consumers with real engine errors: $1.17M and eight downstream entities down.

• 

  The wrong fix invented $129,697.96 with the same 90 rows and zero errors. The fingerprints don't match, so write-back is refused.

• 

  The trap, on purpose: right alias, but a quietly dropped status filter. Every query runs green. The mistake a code review waves through.

• 

  The gate does not negotiate. Row counts held steady while every revenue total inflated. Write-back stays locked until the numbers prove out.

• 

  Caught, fixed, and proven before anything broke, then written back to DataHub as a native incident, a tag, and a decision record.

• 

  Try it yourself, no setup needed: a hosted replay of real runs. Press Test the Gate and watch the database refuse a wrong fix.

Inspiration

Most data disasters aren't loud. A query runs fine, returns the right number of rows, and the totals are silently wrong. Every ordinary check — does it run, did it error, did we lose rows — passes, and a bad number lands on the CFO's dashboard. We wanted an agent that catches exactly that, and that can't fool itself into shipping a wrong fix.

What it does

Propose a schema change and the Impact Guardian traces the blast radius through DataHub's lineage, detonates the change in an in-memory DuckDB replica of the warehouse, writes the minimal fix, and verifies it by matching row counts, column totals to the penny, and a SHA-256 over every row against the pre-change baseline. Then it records an incident and a decision doc back into DataHub.

The key idea: the environment can say no. If a fix runs clean but doesn't reproduce the baseline exactly, write-back is mechanically refused. The agent can't declare its own work verified — only the database can. (In the demo drill, the agent's narration is scripted; the sandbox, numbers, hashes, and the refusal are all produced live by the same gate.)

How I built it

TypeScript and Next.js. The agent is a Claude tool-use loop. Lineage, schema, and search reads go through DataHub's official MCP server (GraphQL fallback), and results are written back as native DataHub incidents, tags, and doc-appended decision records. The sandbox is an in-memory DuckDB replica; verification fingerprints every consuming query. UI is React Flow.

Challenges

Making the gate genuinely un-foolable: no-change refusals, cross-checking sandbox state, invalidating prior passes on any new fix, and a canonical SHA-256 stable despite DuckDB's non-deterministic parallel aggregation.

Accomplishments

An agent whose environment can refuse it, shown live: a wrong fix that inflates revenue by $129,697.96 while row counts stay identical runs green through every ordinary check, and the gate still refuses it.

What I learned

The hard part of an autonomous data agent isn't generating a fix — it's proving the fix is safe. Verification, not generation, is the moat.

What's next

A production-apply path gated on the same proof, CI on migration PRs, and broader consumer coverage (BI tools, dbt exposures).

Built With

• anthropic-claude
• datahub
• duckdb
• model-context-protocol
• next.js
• react
• react-flow
• typescript
• vercel