Complementary tool for dbt→API contract validation at CI boundary — potential ecosystem cross-reference

[OGsiji]

Hey team,

I've been using Data Contract CLI for a while and wanted to flag a project I built that sits in an adjacent but distinct space — in case it's worth a mention in your ecosystem docs or opens a conversation about integration.

What the gap is

Data Contract CLI validates that live data matches a defined contract — post-deploy, warehouse-connected, runtime checks. What I kept running into was a different failure mode: a dbt model changes, the warehouse data looks fine, but the FastAPI service consuming it breaks because the schema no longer matches what Pydantic expects. That break happens in code, before deployment, and no amount of live data testing catches it at the right moment.

What I built

data-contract-validator — a CI boundary guard that statically validates dbt model outputs against FastAPI/Pydantic schemas (and recently, HubSpot CRM targets for reverse-ETL pipelines).

A few things worth noting:

Uses sqlglot for SQL parsing — handles CTEs, window functions, quoted identifiers correctly
Parses Pydantic/SQLModel from AST, no imports executed
Canonical type normalization so varchar vs str doesn't generate noise
Branch auto-matching across repos so a dbt PR checks against the right API branch automatically
Confidence-aware — warns rather than hard-failing when a model can't be fully resolved

Why these are complementary, not overlapping

Your tool answers: "Does the data in the warehouse match the contract?"

Mine answers: "Will the next dbt deploy break the API that depends on it?"

One is post-deploy monitoring. The other is pre-deploy static analysis. A team running both gets coverage at both boundaries.

What I'm proposing

A few things could make sense depending on your interest:

A mention in your "Comparison with Other Tools" page as a complementary tool covering the dbt→application layer boundary
A conversation about whether a bridge makes sense — e.g. your contract YAML as a validation target my tool checks against, or my validation results exported to your format
Nothing formal — just flagging it in case it's useful context for your roadmap

Happy to jump on a call or continue in this thread. No pressure either way — just thought the overlap was worth surfacing.

— Siji
github.com/OGsiji | data-contract-validator

[jochenchrist]

Interesting.

Somewhat releated to the breaking feature we want to bring back for ODCS: #1016

[OGsiji]

After reading through #1129 — the approaches are complementary at a deeper level than I initially stated.

The breaking command as designed compares two contract versions to classify changes by severity. What my tool does is sit upstream of that: it extracts the schema dbt actually produces (via sqlglot parsing + catalog.json) and normalizes it into a structured schema representation.

That extraction layer could feed directly into your breaking detection — teams without hand-authored contracts could use dbt as the contract source, generate a snapshot at each deploy, and pipe that into breaking to get severity-classified diffs automatically.

If there's appetite for a dbt source extractor as part of the ODCS toolchain, happy to contribute that directly. It's already built and tested — it would mostly be a matter of aligning the output schema to whatever format breaking expects as input.

[jochenchrist]

For dbt specifically, have you looked at the dbt commands: https://docs.datacontract.com/dbt

[OGsiji]

Thanks — I had seen the dbt commands, the import from manifest.json is solid. My approach is slightly different: static SQL parsing via sqlglot without needing manifest compilation or warehouse credentials, which is useful in pre-commit or lightweight CI contexts.

But the more distinct piece is probably the application layer boundary — validating that what dbt produces matches what FastAPI/Pydantic/CRM actually expects, which isn't something the dbt commands cover. That's where I've seen the most real breakage in practice.

Happy to keep the conversation there if that's more relevant.

[OGsiji]

@jochenchrist and @simonharrer, looking forward to knowing what you guys feel about us partnering on this.