dbt

Most integrations treat dbt as somewhere to read from. This one also publishes back: governed meaning leaves CoreModels as dbt model property files with enforced contracts, one file per model, colocated beside that model's own `.sql`. This walkthrough runs the whole loop — artifacts out of dbt, meaning governed on top of them, contracts back into the repo, `dbt build` green. Nothing here needs a warehouse credential or a dbt platform connection: artifacts in, artifacts out. CoreModels never writes to your repo and never opens a pull request. Generate returns files; your own PR flow lands them.

The dbt connector declares Import, Audit, and Generate, and four routes carry the loop that matters: push artifacts in, check them against governed meaning, publish contracts back out, and ask what the last import knew. This is the route-by-route reference — role gating, request bodies field by field, exact response shapes. Throughout, `https://coremodels.example.com` stands in for your deployment, `$TOKEN` for your bearer token, and `$PROJECT_ID` for the 32-character hex id of the governing project. The vendor key is `dbt`. One property runs through all four: no credentials — artifacts in, artifacts out. CoreModels never connects to your warehouse, never runs dbt, never reads a dbt platform API, and never writes into your repository; Generate hands back files, and your own PR flow lands them.

"Generate the contracts for `stg_orders` and `stg_customers`, and tell me if anything won't apply cleanly." That sentence is an afternoon of dbt property-file maintenance, and an agent connected to CoreModels over MCP can answer it with real tool calls instead of plausible-looking YAML. Four vendor integration tools give the agent the same governance surface a human gets over HTTP: the same role checks, the same read-only guarantees, and the same honest ledger of what could not be represented.

Try this on a branch first, because it reframes what the gate is for. Take a model with an `accepted_values` test, delete the test, and open a pull request.

CoreModels publishes governed meaning *into* a dbt project. You call Generate and get back dbt model property files with enforced contracts — one per model, colocated with the model's own `.sql` — which your own pull request flow lands in the repo. CoreModels never writes to your repo, never opens the PR, never runs dbt, and never connects to a warehouse; it returns files. Which means the files have to be checkable. Every line the generator emits traces back to a fact recorded in the governed model, and where a fact is missing it omits the line and says why rather than guessing. This is the mechanism in the order it runs, so an engineer reading the output can verify it against the rules instead of trusting it.