Two dbt Projects, One Business

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

Project A's customers has a status column with five accepted values; project B's has four, and one is spelled differently. A's customer_id is a number, B's is a string with a prefix. Each project is internally consistent, fully tested, green in CI. The disagreement is invisible precisely because every tool that could see it operates inside one project — and it stays invisible until a cross-team join produces numbers nobody can reconcile, or an executive asks why two dashboards disagree about churn.

This is the multi-project problem, and in mid-2026 dbt's answers to it are notably thin. dbt-meshify, the tool for restructuring projects into a mesh, was archived by dbt Labs in 2025. Cross-project ref — the mechanism that would at least make dependencies explicit — is gated to the Enterprise tier. And for teams trying to merge projects outright, dbt's own documentation calls consolidation an enormous task with no universal solution. The honest summary: if two of your dbt projects model the same business concept differently, no dbt-native tooling will tell you, and the official remedies are either paid, archived, or manual.

Acquisitions make the theoretical case concrete. The company you just bought has a dbt project. So do you. Both have an orders, a customers, a revenue — and integration planning starts with weeks of spreadsheet archaeology to discover where the definitions actually differ, column by column, value by value.

A referee that belongs to neither project

The structural fix is the same one that works for dbt-versus-warehouse disagreements: a governed model that neither side owns, holding the definition both sides are checked against.

Both estates, one workspace. Each project's manifest.json imports as its own vendor-side estate in the same CoreModels workspace — the history, snapshots and audits track them separately by project name, side by side. Nothing about either repo changes; imports are artifact-first and credential-free, so bringing the acquired company's project in requires exactly one file from their CI.

A shared definition, deliberately. The governed model holds one definition of the shared concept — customers, its columns, their types, the taxonomy of status, the reference from every customer_id. Where the concepts arrived with different native identities, linking them to the shared definition is explicit, reviewed work, and that is a feature: an identity assertion between two teams' core entities should be a decision with a name on it, not a string-similarity guess. For large estates, the mapping does not have to start from a blank page — the transformation engine's AI-assisted mapping proposes candidate plans, and every proposal goes through human review before anything is applied; suggestions are never authoritative.

Divergence as findings, not archaeology. Once the shared definitions exist, each project's fresh manifest audits against them — the same audit machinery that powers the single-project CI gate, now pointed at two estates. Every disagreement surfaces as a finding with a stable code and an exact subject: the value B's status carries that the governed taxonomy doesn't (enum-widened), the type mismatch on customer_id (field-type-drift), the column one project has and the other lacks (coverage findings). The weeks of spreadsheet archaeology compress into a findings report — dated, per-column, re-runnable on every change, and equally legible to both teams because it comes from neither.

Convergence with evidence. From there, mesh governance becomes ordinary drift management. Both projects gate their PRs against the shared definitions, so the gap can only narrow deliberately. The generated contract YAML gives each repo an enforced local copy of the shared meaning. And the audit history answers the program-management question — "are the projects actually converging?" — with a trend line instead of a status meeting.

What to expect honestly

The governed model does not merge your projects; consolidation remains an engineering program, and deciding which definition wins remains a human, political act — the referee makes the disagreements precise, it does not adjudicate them. Nor does this replace cross-project ref: dependency plumbing between projects is dbt's territory. What it replaces is the vacuum where divergence detection should be — the fact that today, two projects can disagree about the business for years and no tool will say so.

One business, one meaning, however many projects: import both estates, define the concept once, and let the findings tell you exactly how far apart your projects really are.

The import and audit mechanics are the standard dbt connector flow (see the dbt quickstart that ships with CoreModels); the cross-estate walkthrough shows two estates reconciled in one workspace.