## 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

```text
agent contract enforcement blocked a legit schema evolution
```

## Steps

1. 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.

2. 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.

3. 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.

4. 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