Model version pinning and change notification

What it does

It stops the model changing underneath the system. Each call names a specific model version, so the provider's updates do not reach production until the organisation chooses to move. A new version is treated as a change: tested against the evaluation suite, compared with the baseline and approved. Engineering owns the mechanism and the system owner approves each move. It is configured at build and operates on every call and at every provider release.

How to implement it

• Call dated or numbered versions, never an alias that tracks the latest.
• Record the version in use in the inventory and with every logged output.
• Subscribe a monitored address to the provider's change and deprecation notices.
• Run the evaluation suite on a schedule against the live model, to detect change that was not announced.
• Qualify each new version through change management before switching.
• Pin other moving parts as well: embedding models, safety filter settings, tool versions.

Evidence it operates

Design: a standard requiring pinned versions; configuration showing them. Operation: version recorded in logs; scheduled test runs with results; change records for each version move; notices received and actioned.

Where it fits

Built into the integration and exercised at every provider release. It is the primary control, with the evaluation suite and regression testing, for unannounced upstream model change, and it supports uncontrolled AI change. It feeds AI change management.

Limits

Not every provider or product allows pinning, and products that embed a model rarely expose the choice. Providers can alter filters and infrastructure behind a pinned version. Pinning delays change and does not avoid it: versions are retired, and the organisation then has to move by the provider's date.