Meaning has no home in dbt. Bring a manifest; we turn `accepted_values` into a vocabulary you can govern and your agent can read.
The finance lead edits the row. You open the PR.
Import your manifest, no credentials. Give the columns that matter a definition, an owner and a permitted-value list — then point your agent at it, or publish the result back as property files your repo can review.
Recipes
Recipes for dbt
An LLM writing SQL against your warehouse has three bad options: guess from the column name, read the SQL, or ask a human. Give it a fourth.
Two files test the same column with different accepted_values. Both pass. Find the one that drifted.
41% of analytics teams say data ownership is ambiguous. dbt can tell you who owns a model. Nobody owns a definition.
Delete an accepted_values test and CI goes green — because the test is gone. Nothing compares the PR to what you agreed.
Meaning has nowhere to live in dbt. Govern it once, and let it reach the warehouse column comment.
dbt lineage tells you which models depend on this one. It cannot tell you who outside dbt is relying on this column.
dbt parse
# writes target/manifest.json — send that. No warehouse credentials.Models, columns, tests, and every `accepted_values` list as a named vocabulary. Ownership, stewardship and agent-guidance columns are added as grids.
GA
Early access — we run it with you
Not yet
Guides
Articles that explain the gap, then point at the recipe that closes it.
You have hit at least three of these this quarter. They arrive as unrelated annoyances, get filed under different headings, and get fixed — when they get fixed — by different people using different tools.
ProblemGrep a mature dbt project for `accepted_values` and count the hits on your order status field. In the estates we have looked at, the number is rarely one. The list appears in the staging model that first cleans the column, in two intermediate models, in the fact table, in three marts built for three teams, and in another four models a second squad wrote when it needed the same field and copied the nearest example it could find.
Recipe: One enum, every model
OutcomesThe 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.
Recipe: Publish governed meaning into dbt
GovernanceA dbt project is the most consequential text a data team owns. The definitions in it decide what gets built, what gets tested, and what every downstream consumer believes. CoreModels asks to publish into that text — governed descriptions, types, vocabularies, and bound ontology terms, emitted as dbt model property files with enforced contracts. Anything asking for that position should be judged less by what it can do than by what it will not do.
EcosystemPick one column — `status` in your orders mart — and count the tools that hold an opinion about it. dbt tests it and, if the model is contracted, refuses to build when its type changes. A catalog lists it, draws its lineage, and lets someone attach a note. An observability tool watches its distribution and raises an alert when yesterday looks unlike last week. A semantic layer exposes it as a dimension. Outside the warehouse, an API team ships a field meant to mean the same thing, and a streaming team keeps an enum on a topic meant to mean it again.
AgentsThis is no longer a hypothetical audience. dbt Labs' [2026 State of Analytics Engineering](https://www.getdbt.com/resources/state-of-analytics-engineering-2026) (n=363) reports **72% of teams prioritizing AI-assisted coding** and **71% concerned about incorrect data reaching stakeholders** — the same teams, describing both halves of the problem below.
Recipe: Stop your agent guessing what `status` means
Use caseThere is a column in your project called `status`, and you have wanted to rename it for about eight months. It should be `order_status` — everyone agrees. You have not done it.
Recipe: What breaks if I rename this?
Use caseSomebody wants to add a value to a status column. They are not being careless — they have checked that the value is real, and they have found the model. What they cannot find is the person who gets to say yes.
Recipe: Who decides what this column means?
Use caseYour mart has a contract. It is enforced, it is checked on every build, and it is genuinely good.
Use caseHere is a two-minute experiment worth doing on a branch before you read further.
Recipe: The PR your dbt CI passes
QuickstartMost 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.
Recipe: Publish governed meaning into dbt
APIThe 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.
MCP"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.
AutomationTry 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.
Recipe: The PR your dbt CI passes · What breaks if I rename this?
Deep diveCoreModels 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.
GuideAn agent pointed at your warehouse can already write SQL. The question is what it knows about the columns it writes against, and the honest answer is: the names, the types, and whatever free text happens to be in a description. Everything else it infers.
Recipe: Stop your agent guessing what `status` means
GuideTwo files in your project test the same column against different value lists. Both tests pass, so nothing has ever told you. This guide finds them, and turns the list into something that can only be defined once.
Recipe: One enum, every model
GuideOwnership registers fail in a predictable way: someone fills a spreadsheet in a week of good intentions, three people leave over the next year, and the file becomes an archaeological record of who used to work here. This guide builds one that does not do that.
Recipe: Who decides what this column means?
Podcasts
Short briefings on how CoreModels works with dbt.
Find a column with an allowed-values test, then another model testing the same column, and compare the lists. In most projects they do not match — and nothing has ever told you.
Two files can test the same column with different accepted_values lists and both pass. Each list is internally valid. dbt has no object that spans them, so the drift is invisible.
Someone querying your warehouse at eleven at night finds a column called status. If they are lucky the comment says "status". They guess — and they never file a ticket.
An agent writing SQL against your warehouse has column names, types, and whatever free text is in the description. Everything else is inference — unless the column can answer for itself.
Everyone agrees a column should be renamed. It has been that way for eight months — not because the rename is hard, but because nobody can tell you what it breaks.
Someone wants to add a value to a status column. They ask in the team channel. Two people reply, one of them hedging. That is not an ownership model.
Delete an accepted_values test, open a pull request, and everything passes. Every check in the pipeline compares the branch to the last commit — not to what the team agreed the column means.
A deep-dive technical discussion on why modern data stacks fail to maintain business definitions. We walk through a two-minute diagnostic experiment you can run on your codebase to expose where critical business rules have drifted across duplicated, unlinked files. We examine why traditional PR templates and external catalogs fail because they lack downstream dependents, and we explore how representing business definitions as first-class, named objects can structurally solve this. Finally, we discuss how configuring dbt's native persist_docs comment conduit physically pushes these governed meanings directly into database column comments to reach your downstream analysts in their native SQL autocomplete.
Two senior engineers analyze the "green-build illusion"—why local test suites can remain entirely green even when duplicate permitted-value lists have quietly drifted apart. Because dbt treats enums as isolated, independent string arrays, it lacks a native mechanism to compare them against one another. We discuss the severe operational cost of slightly-wrong data (such as a missed return status code) quietly eroding stakeholder trust on executive dashboards. Finally, we map out how to transition from fragmented string arrays to named, structured vocabularies, and share a practical workflow for sorting your vocabularies by reference count to identify high-leverage business terms.
We examine an invisible, daily breakdown in data communication: the analyst querying raw warehouse tables late at night. Lacking access to your dbt repository, they are forced to guess what ambiguous database columns signify, propagating silent inaccuracies without ever filing a ticket. We discuss why traditional documentation repositories fail to reach these users, and show how configuring dbt's persist_docs setting turns database column comments into a direct conduit. By pushing governed definitions straight into the physical warehouse comments, you meet external analysts exactly where they work, integrating business definitions directly into their SQL autocomplete.
AI coding agents and text-to-SQL systems excel at parsing names and data types, yet they consistently write incorrect queries because they lack access to underlying human intent. We explore the structural difference between SQL computation and semantic logic, analyzing the risks of silent, plausible errors (such as an LLM failing to distinguish between nuanced order return stages). We outline the "fourth option" for LLM integration: providing AI tools with a read-only, human-curated semantic model. Finally, we discuss why writing explicit descriptions of "common mistakes" for your 20 highest-leverage columns yields far better AI-generated SQL than paragraphs of dry documentation.
Why do development teams routinely avoid simple column renames? We break down the unbounded cost of discovering where a schema change propagates. Traditional model-level dependency graphs map internal lineage but completely miss external consumers (reverse-ETL pipelines, BI tools, direct database queries, and external APIs) and semantic owners. We discuss how tracking the conceptual relationship path of a vocabulary through a governed model transforms an endless manual search into a finite, 20-minute checklist, giving engineers the structural confidence to clean up their codebases.
Technical code ownership typically links individuals to physical files, but business definitions frequently span multiple models. This mismatch forces developers to make isolated business decisions they are not qualified to handle. We discuss how to structure a centralized metadata register based on persistent decision forums (which survive individual employee turnover) and explicit review cadences rather than fragile individual assignments. Finally, we analyze a proactive day-one operational strategy: blanket-assigning "wrong" owners to spark corrections and turn a vague cultural issue into a transparent, prioritized backlog of work.
Modern software development pipelines suffer from a systemic vulnerability: deleted constraints and tests go completely unnoticed in pull requests. Because standard branch-versus-main diffs evaluate only what currently exists, a branch that removes critical tests still passes CI green. We analyze how implementing a "fourth comparison"—evaluating compiled branch projects against a baseline governed model—enforces structural accountability automatically rather than relying on fragile human memory. We close with a practical implementation strategy: triaging and recording deliberate deferrals of existing drift to avoid creating noisy red builds on day one.