ImportEarly access

Publish governed meaning into dbt

Meaning has nowhere to live in dbt. Govern it once, and let it reach the warehouse column comment.

No warehouse credential. No dbt Cloud token. Read-only.

dbt emits one artifact class — tables in one warehouse — and gives governed meaning nowhere to live: description is free text, meta is unvalidated, and accepted_values is a string list duplicated into every model that touches the field. This recipe closes that loop. Import the artifacts dbt already produces, govern meaning on top (descriptions, a named vocabulary behind an enum, an ontology term a human binds), then generate the contracts back as one property file per model, colocated beside each model's own .sql. One governed vocabulary generates accepted_values in every model that uses that field; a bound ontology term rides out both structurally (meta.coremodels.maps_to) and in the column description, which persist_docs carries into the warehouse column comment. Generation is deterministic, so a re-run with no meaning change is an empty diff. CoreModels returns files — your own PR flow lands them.

What you do

Govern the meaning in the grid; generate one property file per model, colocated beside its .sql.
The bound term rides in the column description (the field persist_docs pushes to the warehouse comment) and in meta.
Every run hands you a loss report. No meaning change means no diff.

Guides for this recipe

Strategy

Why the problem exists, and what changes once it is fixed.

Outcomes

The Ticket Nobody Files

The enum problem is the one everybody recognizes, and it is not the whole of what changes. Once meaning is governed once and published back into dbt, a set of small recurring chores stop happening — and one of them was costing you a morning a month without ever being on a roadmap.

Engineering

How it works: the import, the API, the MCP tools, the CI loop.

Quickstart

Manifest In, Contracts Out: A dbt Round Trip in Five Steps

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.

← All dbt recipes Start with this recipe →