Approve a breaking change to a published interface

In plain terms

Decide to change a contract consumers depend on. Where a consumer is autonomous, it will not complain. It will fail, or produce wrong output quietly.

What is being judged

Whether the migration window is survivable for every consumer, including the ones that cannot ask for more time.

Human-consumed interfaces have a feedback path. A developer reads the deprecation notice, or misses it and raises a ticket when the build breaks. Both outcomes surface. An autonomous consumer has neither: it does not read notices and it does not raise tickets. If it keeps working against a changed contract, the failure is silent and the output is confident.

The mechanism that replaces notification is invalidation. A fitness record states the interface specification version it was declared against. A change to the schema, enumerated values, error set or authentication method invalidates it, and AI consumption of an interface whose live version does not match its fitness record is a finding.

Note the trigger is narrower than “breaking change” and drawn differently. Adding an optional field is not breaking and does not invalidate fitness. Adding an undocumented enumerated value is not breaking for a human consumer and does invalidate fitness, because that is exactly the condition the declaration exists to prevent. The test is what an autonomous consumer can misread, not what breaks a build.

What this decision does not cover

It does not re-declare fitness, which returns to the Data Steward at L2-05 and L3-04. It does not decide the contract standard.

When it fires

On event. When a change to a published interface alters schema, enumerated values, error set or authentication. On retirement of an interface version.

On cycle. None.

What you need before deciding

The consumer list, including AI systems, from the interface catalog. Which fields each consumer actually reads, usually narrower than the interface offers. Current fitness records and their versions. The migration effort for autonomous consumers, which is evaluation and prompt rework rather than code changes.

How this goes wrong

Notifying only the consumers who can be notified: the deprecation notice goes to teams, the autonomous consumers are not on the list, and nobody notices until output degrades. Fitness surviving the change: the record still reads valid against a contract that changed, which is the defect the version binding closes. Migration windows sized for humans: a window that assumes a developer will act, applied to a consumer whose migration requires re-validation by a Model Owner who has not been told.

Related decisions

Invalidates L2-05 and L3-04 fitness declarations.

Upstream L2-04 contract standard.

Downstream re-declaration of fitness, and L3-01 re-validation where model behavior depends on the interface.

Instrument references

None. API versioning and deprecation practice is well developed and universally assumes a consumer that can be told.