Open Data Infrastructure
dbt Core Model Contracts and Open Catalogs
Where dbt Core model contracts help, where open catalogs still matter, and how to avoid confusing checks with control.
A dbt model contract can stop a bad transformation from changing shape. It cannot tell the whole data platform who owns the table, who can use it, or why an agent should trust it.
The practical problem
dbt Core model contracts are valuable because they make model shape explicit. Column names, data types, and constraints are not left entirely to convention. That is good analytics engineering hygiene.
Open catalogs solve a different problem. They coordinate table identity, metadata, permissions, namespaces, and engine access across the lakehouse. Confusing a model contract with catalog governance creates a gap right where ODI needs control.
Core idea: dbt contracts define transformation expectations. Open catalogs carry infrastructure context across tools and engines.
The boundary to keep clear
Use dbt contracts to protect model interfaces. They are especially useful when downstream teams depend on stable schemas, data types, and documented transformations.
Use catalogs to protect platform behavior. The catalog should know table identity, namespace ownership, allowed operations, storage locations, and engine access. That context has to survive outside a single transformation project.
Use lineage to connect them. A model contract without lineage is a local promise. Catalog metadata without transformation context is an incomplete story. The useful architecture links both.
What breaks first
- Teams believe a passing model contract proves the table is governed.
- Catalog entries show tables but not transformation intent, ownership, or quality status.
- AI tools consume modeled data without understanding freshness, policy, or lineage.
- Warehouse-specific model behavior leaks into an open lakehouse migration.
Questions to ask
Use these questions when dbt Core and open catalogs meet.
- Which guarantees belong in the dbt model contract?
- Which guarantees belong in the catalog and policy layer?
- Can lineage connect source tables, models, exposures, and AI consumers?
- Can another engine read the governed table without losing contract context?
- Who owns the escalation path when contract and catalog facts disagree?
For adjacent topics, read Semantic Layers in the Agent Era, Metadata Is a Real Infrastructure Layer, and How Open Catalogs Help AI Systems Understand Data.
Sources to start with
Start with dbt contracts, then connect them to catalog and lineage systems that can travel beyond dbt.