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.

But owning the middle is not the same as owning the meaning. The definition of orders — its columns, their types, the values status may take, what customer_id must reference — is a fact about your business, and the business does not live inside any one tool. The warehouse has its own opinion of every column's type. The BI layer has its own semantic definitions. The ingestion tool has its own catalog. Each tool holds a partial, dialect-flavored copy, and no copy is the referee.

That is the ecosystem problem our dbt integration is built for — and why it is built the way it is.

The artifact interface: meeting dbt where it publishes

dbt already publishes a remarkably complete description of itself. Every command writes manifest.json; dbt docs generate adds a catalog with warehouse-real column types; projects that define semantic models produce a semantic manifest describing entities, dimensions, measures and exposures. These artifacts are dbt's public, documented output — which makes them the right integration surface.

CoreModels reads exactly those files and nothing else. There is no warehouse session, no dbt Cloud connection, no plugin inside your project. We track the artifact formats as they evolve — the connector tolerates manifest schema versions 10 through 12, handles versioned models, dbt Mesh's cross-project references, and disabled or ephemeral nodes — because integrating through published artifacts, tolerantly, is what keeps an integration stable while the ecosystem underneath it moves. When dbt's manifest gains fields, an open-world parser keeps working; oddities are reported honestly rather than becoming failures.

One neutral model, twenty-one connectors

Here is the part that matters even if you only use dbt today: inside CoreModels, dbt is one connector among twenty-one — warehouses like Snowflake, BigQuery, Databricks and Microsoft Fabric; catalogs like AWS Glue; schema registries like Confluent; movement and orchestration tools like Airbyte and Airflow; platforms like Salesforce, Neo4j, REDCap and cBioPortal; and content platforms like Contentful, Sitecore, Drupal and WordPress. Every one of them parses into the same neutral estate model: datasets with fields and checks, plus lineage. Vendor-specific detail — a dbt materialization, a contract flag, a native type string — travels as metadata on the neutral model, never as a private concept beside it.

Neutrality is not an aesthetic choice; it is what makes several things possible at once.

It makes governance portable. Because the governed model is neutral, the same definitions that audit your dbt project can generate artifacts in other dialects, and export as JSON Schema, LinkML, Avro, SQL DDL and more. Your meaning is written once and spoken in many formats — instead of being trapped in the dialect of whichever tool first recorded it.

It makes tools composable rather than competitive. The most telling verb in the integration layer is reconciliation: when a dbt model and the warehouse table it materializes are both governed — one imported from the dbt manifest, one from the warehouse's information schema — CoreModels links them as the same physical relation, with reciprocal same-as assertions on both nodes. Two vendors' views of one table stop being two entries in two catalogs and become one governed entity seen from two sides. That is only possible because neither vendor's vocabulary is the master vocabulary. And the same neutrality answers a question dbt currently answers with an enterprise price tag: when two dbt projects describe the same business concept — a mesh, or the aftermath of an acquisition — a shared governed model is the vendor-neutral place to find out whether they actually agree.

And it makes the future cheap. Connectors are deliberately isolated: adding the next one never changes how the dbt connector behaves, and every connector gets the same verbs — import, audit, generate where supported, history, badge — through the same interface. A platform team learns the model once and applies it to the whole estate.

The semantic layer, included

The ecosystem around dbt is consolidating on an idea worth taking seriously: metrics and semantic models as first-class citizens. Our connector follows it. When your project defines semantic models and exposures, they become governed projections — components that link to the model they project and to the specific field elements their entities, dimensions and measures reference. Coverage auditing extends to them, so "is our semantic layer actually governed?" gets a numeric answer alongside the same question for tables and columns. Exposures — the dashboards and applications declared as consumers — join the same graph, which closes the lineage story from source to screen.

Portability is the unfinished half of that consolidation, and it is where neutrality pays again. Apache Ossie — the open semantic interchange spec, in the Apache Incubator — is the format the ecosystem chose for moving semantic definitions between tools, but adoption so far is lopsided: dbt can ingest Ossie files, and almost nothing anywhere produces them. CoreModels exports the governed model as an Ossie 0.1.1 semantic-model document — the exact spec version dbt reads from an osi/ directory — so definitions governed once have a standards-shaped way out, not just a way in. (Honest scope: the export carries semantic models and their datasets; metric metadata captured at import rides projection metadata, and full metric-spec round-tripping is not claimed.)

Neutrality is also an exit

There is a quiet test for any governance layer: what does leaving look like? Our answer is that the artifacts we generate are plain, standard files you own. The dbt contracts we emit are ordinary schema.yml — enforced model contracts with data types, constraints and tests — that dbt enforces natively, with no CoreModels runtime anywhere in your build. The exports are standard formats readable by anything. If CoreModels vanished tomorrow, everything it generated would keep working, because none of it is proprietary.

That is the ecosystem bet in one sentence: tools should compete on what they do, and interoperate on what things mean. dbt is very good at what it does. CoreModels holds the meaning — neutrally, so that dbt, your warehouse, your semantic layer and whatever you adopt next can all be audited against the same definitions instead of drifting apart in private dialects.

If your estate is more than just dbt — and it always is — start with the dbt quickstart in the CoreModels docs, then point the same governed project at your warehouse connector and reconcile the two.