Connect dbt

The Meaning Gap in Your dbt Project

The incident that finally exposes the gap is usually small. A refactor touches a staging model, `order_total` quietly comes out of a `CASE` expression as text instead of a number, and `dbt build` goes green — because nothing in the project ever asserted that `order_total` is a number. Three days later a finance dashboard shows revenue as zero, an analyst files a ticket, and four people spend an afternoon doing archaeology in git history to find out when the column changed and who was supposed to care.

A Governed dbt Estate, One Week In

Here is the same Thursday, twice.

Governing a dbt Estate Without Touching It

Our dbt integration never asks for a warehouse credential, a dbt Cloud token, or write access to your repository. That is not a missing feature — it is the governance design, and every other trust property follows from it.

Recipe: Contract YAML from governed truth

dbt Is One Voice in Your Data Estate. Meaning Has to Outlive Them All.

Map a modern data platform and dbt sits at the narrow waist. Below it, a warehouse — Snowflake, BigQuery, Databricks, or several at once — holds the physical tables. Above it, BI dashboards, notebooks, reverse-ETL jobs and, increasingly, a semantic layer consume what dbt builds. Around it, orchestrators schedule runs and ingestion tools land the raw data it starts from. dbt's great achievement is owning the middle: transformation as versioned, tested code.

Recipe: Semantic layer portability

Stop Letting AI Agents Guess What Your dbt Columns Mean

Large language models are dangerously good at plausible schemas. Ask an agent to write a dbt model joining orders to customers and it will produce clean SQL against `customer_id`, confidently test `status` for values like `active` and `cancelled`, and cast `order_total` to a sensible numeric type. Every one of those choices is a guess dressed as knowledge. In your estate the key might be `customer_key`, the status taxonomy might include `partially_refunded`, and `order_total` might be governed as a decimal for a regulatory reason no manifest comment explains. The SQL parses. The guesswork ships.

The Consumers dbt Can't See

Ask a dbt team who consumes their marts and you get a confident list: the BI dashboards, the declared exposures, maybe a semantic layer. Ask the *warehouse* the same question and the list is longer and stranger — a reverse-ETL job syncing `customers` into a CRM, a feature pipeline reading `orders` into a model store, another team's scheduled export three schemas away. Every one of those readers depends on your mart's schema. Not one of them is protected by anything dbt can enforce.

Recipe: External contract of record

Your Contracts Stop at sources.yml. Your Drift Doesn't.

Every dbt engineer has lived this incident. An upstream team renames a column — or the ingestion tool retypes one, or a platform migration drops one — and the first anyone hears of it is a failed `dbt run` at 6 a.m.: `invalid identifier 'ORDER_TOTAL'` somewhere in a staging model. The upstream change may have been perfectly legitimate. The problem is where it was discovered: at runtime, in your project, by the on-call.

Recipe: Source truth gate

Two dbt Projects, One Business

Somewhere in your company, two dbt projects both know what a customer is. They disagree.

Recipe: Two projects, one truth

dbt to CoreModels: Zero to First Audit

Your dbt project already produces everything CoreModels needs. There is no agent to install, no warehouse credential to hand over, and no dbt Cloud connection to configure — the integration works entirely from build artifacts that `dbt` writes to your `target/` directory on every run. In this tutorial we take a real dbt project from nothing to a completed schema audit: extract the artifacts, import the estate into a governed CoreModels project, run the first audit, and read the result line by line.

Recipe: dbt governed baseline

The Complete HTTP Surface of the CoreModels dbt Integration

This is the reference we wish every integration published: every route, every role, every request body, and every response shape for governing a dbt estate with CoreModels over plain HTTP. The dbt connector declares all three capabilities — Import, Audit, and Generate — so every verb below is live for `vendor = dbt`. (Not every connector can say that; the discovery route tells you per vendor, and a verb a connector doesn't support fails honestly rather than pretending.)

Driving dbt Governance from an AI Agent over MCP

Ask an AI agent "did anything in our dbt project drift from what the business agreed it means?" and it should not have to screen-scrape a dashboard or guess. CoreModels exposes its dbt integration as first-class MCP tools, so an agent connected to your CoreModels server can check integration status, audit a manifest, and produce enforced dbt contracts — with the same role checks and the same read-only guarantees as the HTTP API. This article walks through the four integration tools an agent uses for dbt, with real arguments.

A CI Drift Gate for dbt: Fail the PR, Feed the Badge, Keep the Trail

A pull request retypes `order_total` from a numeric to a string, and every test in the dbt project still passes — because the tests never encoded what the column *means*, only what it does. A nastier variant: a PR *deletes* the `accepted_values` test on `order_status`, and CI goes green precisely because the assertion is gone. Branch-vs-main tooling can't flag either one as a violation, because both branches are internally consistent; the thing being violated lives outside the repo. That is the difference in comparison target this gate exists for: it checks the PR against the *governed model* — the agreed meaning — so the retype surfaces as `field-type-drift` and the deleted test as `enum-constraint-removed`, each failing the build with a comment explaining exactly which governed agreement it breaks. This article builds that gate with CoreModels: the audit endpoint CI calls, a portable curl+jq version, the ready-made GitHub Action, the README badge, the rolling history behind it, the re-audit that catches drift in the other direction, and the scheduled heartbeat that keeps the whole loop honest between pull requests.

Recipe: Governed contract gate for dbt CI

How a dbt Estate Maps into the Governed Graph

`model.jaffle_shop.orders` is a node in dbt's manifest. After a CoreModels import it is a governed Type with a vendor identity, a metadata mixin carrying its native types and tests, lineage edges to its parents, and — if a semantic model projects it — membership in a Component. This article is the precise account of that mapping: what each dbt construct becomes, what rides the metadata mixin, how native types are approximated (and where the exact string survives), which audit rules the connector contributes, and where the mapping is honestly lossy.

Recipe: Contract YAML from governed truth