agent contract enforcement blocked a legit schema evolution
Unblocks legitimate schema changes past dbt contracts for analytics engineers supervising repair agents. Use when a contract blocks a schema change the business actually wants. Not for contract violations from bugs.
TL;DR
The contract did its job and caught a schema change; now decide deliberately whether the change is wanted. If yes, update the contract in schema.yml to the new shape (add the column, change the type), get owner sign-off, and rebuild. Contracts change via versioned updates, not silent drift.
Error
agent contract enforcement blocked a legit schema evolutionSteps
Read the contract violation: which column or type changed, and what the contract demands. Expected: You know the exact delta between the model output and the contract.
Confirm the change is legitimate with the data owner: is the new column or type the intended evolution? Expected: A yes with a reason, or a no meaning the model change was the bug.
If legitimate, update schema.yml: add the column to the contract with its type and constraints, or change the type deliberately. Note it in the changelog. Expected: The contract describes the new intended shape.
Run dbt build --select the_model and notify downstream consumers of the schema change. Expected: Build passes; consumers know about the new shape.
When to use
- a contract blocks a schema change the business approved
- adding a column to a contracted model fails the build
- a type change is intentional but the contract still demands the old type
When not to use
- the contract caught an accidental change (then the contract is right; fix the model)
- there is no contract (then this error cannot happen)
- downstream breaks from the change (that is consumer migration, separate step)
Tool compatibility
- dbt model contracts in schema.yml
- dbt build enforces at materialization
- changelog or PR description for the contract change record
Variant phrasings
agent tried to bypass the contract instead of updating it
Bypassing (dropping the contract, loosening types silently) defeats the purpose. Update the contract deliberately or revert the model change.
contract blocks a type widening like int to bigint
Usually safe for consumers; update the contract and note the widening. Narrowing needs more care.
Why it happens
Contracts are change-detection, not change-prevention. When they block, the right response is a conscious decision: approve the evolution and update the contract, or reject it and fix the model. Agents tend to pick a third option (bypass), which is how silent drift happens.
Edge cases
- Version your contracts alongside the models; a contract change without a model version note confuses the next reader.
- Some teams require a deprecation period for column removal even with contracts; check your team's policy.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_xaIOJcRXcIpGaAIQ9EhkVQ