Threxa

The blast-radius gate for data model PRs. Missing lineage never returns SAFE.

Comment

About Threxa

Threxa is a blast-radius gate for data model pull requests.

The idea came from a simple problem I kept thinking about while working with data systems: a SQL or dbt change can look completely harmless inside a GitHub diff, yet still break dashboards, reports, marts, and downstream models owned by people who never touched the pull request.

A normal code review can tell you what changed in the code. It usually cannot tell you who or what will break downstream.

That gap is what I wanted Threxa to solve.

Instead of building another generic AI code reviewer, I built Threxa around one strict rule:

Missing lineage, unresolved entities, or an unparseable diff must never produce a SAFE verdict.

When a pull request changes SQL or dbt models, Threxa analyses the diff, resolves the affected entities inside DataHub, traces their downstream lineage, calculates the blast radius, and posts a deterministic verdict back to the pull request.

The verdict can be:

  • SAFE
  • RISKY
  • BREAKING

The LLM helps parse the diff and explain the result, but it never decides the final severity. The severity comes from deterministic application logic based on the type of change and the lineage information returned from the catalog.

How I built it

Threxa starts with GitHub pull request webhooks.

When a PR is opened or updated, the webhook handler checks whether the pull request contains relevant SQL or dbt changes. PRs without data-model changes are skipped instead of creating unnecessary analysis runs.

For relevant changes, the pipeline:

  1. Reads the changed files and diff.
  2. Uses an LLM to extract structured data-model changes.
  3. Resolves the affected models and columns against DataHub.
  4. Queries downstream lineage using the official mcp-server-datahub.
  5. Calculates the blast radius.
  6. Scores the change with deterministic application logic.
  7. Posts or updates a verdict comment on the GitHub pull request.
  8. Sets a GitHub commit status.
  9. Stores the analysis so it can be inspected from the Threxa dashboard.
  10. Writes relevant change information back into DataHub.

For merged breaking changes, Threxa can also raise incidents against affected downstream assets in DataHub.

The application itself is built with Next.js and TypeScript. The deployed application runs on Cloudflare Workers, with Postgres persistence through Neon and Prisma.

The live product is available at:

https://threxa.breachresponse.xyz

Why DataHub matters

DataHub is central to Threxa rather than being an extra integration added for the hackathon.

A GitHub diff can show me that a model or column changed, but the DataHub catalog tells Threxa what depends on that model.

That lineage information is the core input needed to calculate the blast radius.

Threxa uses the official DataHub MCP server to query catalog information and lineage. It also writes change information back to DataHub and can raise incidents for merged breaking changes.

Without the catalog, Threxa cannot make the type of downstream-impact decision it was designed to make.

Challenges I faced

One of the biggest challenges was preventing false confidence.

It would have been easy to make the system return SAFE whenever it could not find downstream dependencies. That would create a dangerous failure mode because missing lineage does not necessarily mean there is no impact.

I changed the scoring model so uncertainty fails toward caution.

If Threxa cannot resolve an entity, cannot verify the blast radius, or receives an invalid parser result, it does not silently mark the PR safe.

For example:

  • A destructive change with unverified lineage becomes RISKY.
  • An ambiguous catalog entity is treated as unresolved instead of guessing.
  • An unparseable data diff produces an explicit failed analysis.
  • Unknown change types are treated conservatively.
  • Duplicate webhook deliveries are deduplicated by the PR head SHA.

Another challenge was deployment.

The original deployment stopped working and the public URLs returned 404s, so I rebuilt the deployment path and moved the application to Cloudflare Workers.

That also forced me to work through runtime limits, database connectivity, webhook timing, and external service communication.

The webhook now acknowledges GitHub quickly and performs the heavier analysis asynchronously within the worker execution model. I also added a hard analysis budget so a failed external dependency cannot leave a run permanently stuck.

During the final review I went through a separate adversarial code-review pass and closed 14 findings covering correctness, reliability, parser validation, false-SAFE behavior, pagination, ambiguous entity resolution, webhook security, and idempotency.

The test suite grew from 13 tests to 27 tests as part of that process.

What I learned

The biggest lesson from building Threxa was that AI should not automatically own every decision inside an AI-powered product.

The LLM is useful for understanding messy pull request diffs and generating readable explanations.

Severity is different.

Whether a database change should be considered safe or breaking is a decision that needs predictable rules, especially if the result could eventually block a merge.

That is why Threxa separates language-model reasoning from deterministic scoring.

I also learned how important uncertainty handling is when working with real catalog data.

Lineage systems are never guaranteed to contain a perfect representation of the real world. A useful system has to communicate when its information is incomplete instead of pretending to know more than it does.

That principle became one of the core design decisions behind Threxa.

Real end-to-end proof

I created a separate demo repository and ran real pull requests through the deployed Threxa pipeline.

In the first demo PR, a column is removed from a model. Threxa resolves the model in DataHub, discovers five downstream assets, and returns a RISKY verdict because column-level impact cannot be fully verified for every consumer.

In the second demo PR, the entire model is removed.

The same downstream assets are affected, but because removing the model destroys the entity every consumer depends on, Threxa returns BREAKING and sets the GitHub commit status to failure.

The difference between the two results comes from deterministic scoring rules, not random model output.

The demo repository is available at:

https://github.com/mystiquemide/threxa-demo

The main repository is available at:

https://github.com/mystiquemide/threxa

Threxa is still hackathon software, so there are limitations around production authentication, load testing, catalog completeness, and operational scaling.

But the full path shown in the demo is real: GitHub webhook, diff analysis, DataHub resolution, lineage traversal, deterministic scoring, PR verdict, commit status, database persistence, dashboard output, and catalog write-back.

Built With

Share this project:

Updates