A model catalogue needs an exit date beside the selection

A model can be the right choice today and still need a retirement plan. I would make that plan part of selection, while the team remembers why it chose the model and can still test alternatives calmly.

Reuters’ July 28 report, carried by The Spokesman-Review, describes Business Insider reporting that Amazon was winding down several Nova models while developing a new frontier effort. Amazon’s quoted response says it continues to support the Nova models customers rely on. The report does not supply customer migration deadlines.

Those statements should not be compressed into “your endpoint disappears tomorrow.” They do make a model catalogue worth reading as present availability, rather than a complete promise about future support.

Define the change that would trigger a move

An exit plan does not need to predict the supplier’s roadmap. It needs to state what the application will do when a material condition changes. Formal end-of-life notice is one trigger. An unacceptable quality regression, a changed deployment requirement or loss of a needed capability could be another.

I would record the reasons for the original choice in user terms. Perhaps the model extracts a particular document structure accurately, handles a required language or meets a response-time target. “It was in our cloud account” may explain convenience, but it does not define what a replacement must preserve.

That distinction matters when the catalogue offers a successor. A new model with the same brand may still need different prompting, produce different formats or behave differently on difficult cases. Those are possibilities to test, not claims about any Nova replacement.

The point of an acceptance set is to keep the migration tied to the work. A broad benchmark improvement does not establish that the successor preserves the particular behaviour the application needs.

Rehearse the smallest meaningful replacement

For a hypothetical image-description service, I would retain a permitted set of representative inputs and the criteria used to accept the output. Run a candidate replacement against that set, inspect disagreements and measure the changes the integration requires.

Then exercise the switch in a disposable environment. Can requests be redirected without losing their status? Can the team identify which model produced each result? If the new version performs badly, is the old one still available for rollback during the transition? A retirement deadline can make that last option temporary, so the plan needs a fallback beyond “switch back.”

I would assign an owner to watch the supplier’s formal lifecycle notices and set a date to review the plan. That review date is ours; it should not be presented as a vendor-announced shutdown date when none has been verified.

There are costs to carrying alternatives. Maintaining several complete integrations for every small feature can become wasteful. The depth of the rehearsal should follow the consequence of losing the model and the time the organisation would need to replace it.

I have not independently verified the internal portfolio reporting or tested Nova migration paths. The public support statement also deserves its place beside the report. The recommendation does not depend on treating either as a secret schedule.

A model-diverse platform can make substitution easier. It cannot make the customer’s acceptance criteria disappear. The catalogue supplies candidates; the application team still owns the decision that one is a suitable replacement.

Choose a model with explicit acceptance criteria, a migration trigger and an owner who will rehearse the exit before a deadline forces it.