Enabling it
For a SQL model, declaring a type on any inline or reusable-schema column enables type enforcement automatically:MODEL(type_enforcement ...) switch. In this example, order_id and ordered_at are typed; source_system remains untyped and passes through unchanged.
Sources have related behavior but different configuration. A source can explicitly set type_enforcement: false; see Sources.
Compile-time checks
When SQL analysis can infer an output type, SQLBuild compares it with the declared type using adapter-aware normalization. A proven mismatch is a compile error when type enforcement is active. If SQLBuild identifies an output column but cannot prove its expression type, it reports an unproven-type warning rather than guessing. If the entire output shape cannot be inferred, static type checks and warnings cannot run. Static analysis does not rewrite the authored query. It determines whether the inferred output is compatible before warehouse execution.Runtime casting
Runtime enforcement inspects a staged relation. If a typed output column does not already have its declared type, SQLBuild rebuilds the staging or delta relation with an explicit cast:
Staged promotion is the default table mode. If a project selects direct table promotion, a typed model fails with guidance to use staged promotion because SQLBuild cannot inspect and reconstruct output before mutating the destination.
Type enforcement versus contracts
These controls answer different questions:
Type enforcement can be active with
contract none. Conversely, an enforced contract may contain untyped columns: exact shape validation still checks their names, but there is no declared physical type to cast or compare.

