Model update notice

Problem Context

• Model providers may release new versions, mark models legacy or deprecated, retire preview models quickly, auto-upgrade standard deployments, require manual migration for provisioned deployments, or shut down endpoints after a date.
• A model update may change answer style, refusal behavior, safety policy, tool calling, structured output, latency, pricing, context length, region availability, fine-tuning support, prompt compatibility, or evaluation results.
• Users affected by a model update may include admins, developers, support leads, prompt owners, compliance reviewers, automation owners, and end users relying on stable behavior.
• The notice may appear in admin consoles, model pickers, API dashboards, assistant builders, workflow editors, release notes, notification centers, emails, or inline on affected AI surfaces.
• The product must distinguish informational upgrades from required migration, urgent retirement, risky behavior change, preview instability, and post-retirement failure states.

Selection Rules

• Choose model update notice when users need to understand and act on AI model lifecycle, version, capability, deprecation, retirement, replacement, migration, or auto-upgrade changes.
• Use notification banner when the message is a general page-flow notice and not specifically about model lifecycle, replacement, affected AI behavior, or migration.
• Use confidence / uncertainty display when the surface explains reliability of one prediction or output, not a platform model version change.
• Use warning text when the user is about to take a risky action and needs consequence copy, not when the main job is migration planning.
• Use phase / beta banner when signalling service maturity such as alpha or beta; use model update notice when a model version or lifecycle stage changed inside an AI capability.
• Use source grounding display when users inspect evidence behind an answer; use model update notice when model behavior or availability changed regardless of source coverage.
• Use activity log or audit log to record that a migration happened; use model update notice to warn, plan, test, and act before or during the change.
• Show current model, new or replacement model, lifecycle stage, effective date, retirement or shutdown date, affected surfaces, owner, action required, and testing path when the change can affect production behavior.
• Mark no-action, auto-upgrade, manual migration, preview retirement, behavior-only update, blocked deployment, failed migration, and completed migration states separately.
• Do not present model updates as decorative product marketing when users need deadlines, compatibility checks, or migration ownership.

Required States

• Informational model update state with model name, version, capability change, effective date, and no action required.
• Deprecated model state with replacement model, retirement date, affected usage, recommended migration path, and owner.
• Urgent retirement state with shutdown date, unavailable-after behavior, failure mode, support contact, and escalation path.
• Auto-upgrade scheduled state showing rollout window, old model, new model, expected behavior change, and testing option.
• Manual migration required state for provisioned or pinned deployments that will not auto-upgrade.
• Preview model short-notice state with production risk and rapid migration path.
• Behavior change state where model remains available but answer style, safety behavior, tool use, pricing, latency, region, or context support changes.
• Compatibility check state showing prompts, workflows, automations, fine-tunes, evaluations, API calls, or regions affected.
• Test replacement state with regression set, pass/fail results, differences, owner approval, and rollout plan.
• Completed, dismissed, snoozed, failed migration, rollback, stale notice, and post-retirement blocked states.
• Mobile compact notice state with model, deadline, affected count, and primary action visible.

Interaction Contract

• The notice identifies the current model and replacement or new model in user-visible text.
• Users can see whether action is required, whether auto-upgrade applies, and what happens if no action is taken.
• The notice links to affected assistants, prompts, workflows, API keys, deployments, fine-tunes, evaluations, or automations rather than only to a broad changelog.
• The product distinguishes lifecycle stage from status: preview, GA, legacy, deprecated, retiring, retired, auto-upgrading, and blocked are not interchangeable.
• Dismissing or snoozing the notice does not hide unresolved required migration from owners or admins.
• Testing, comparison, and migration actions preserve the old model until the user confirms rollout where manual migration is required.
• After migration, the notice records completion, replacement model, date, owner, validation evidence, and any residual behavior changes.
• If the model is already retired, the UI explains the failed call or blocked deployment and routes users to replacement and recovery.

Implementation Checklist

• Model current model ID, version, provider, deployment type, lifecycle stage, replacement, effective date, retirement date, shutdown behavior, affected surfaces, owners, required action, auto-upgrade state, and migration status separately.
• Inventory affected usage from model pickers, API logs, assistants, workflows, automations, fine-tunes, evaluations, prompts, integrations, regions, and quotas.
• Provide model comparison and regression testing using representative prompts, tool calls, structured outputs, safety cases, latency, cost, and source-grounding expectations.
• Separate notice dismissal from migration completion, and keep required notices visible to accountable owners until the work is verified.
• Handle preview short-notice, GA retirement, provisioned manual migration, auto-upgrade, no-replacement retirement, behavior-only update, and post-retirement failure as separate states.
• Log notice sent, viewed, snoozed, migration started, test completed, rollout approved, fallback used, rollback, and final completion.
• Check accessibility for status badges, dates, affected item tables, diff views, test results, countdowns, and live status updates.

Common Generated-UI Mistakes

• Announcing a model change as ordinary release news without affected usage, deadline, replacement, or action requirement.
• Using a dismissible banner that hides required migration before it is complete.
• Showing model deprecated without explaining whether calls still work, when they fail, or what replacement to test.
• Auto-upgrading a model without letting owners compare behavior in high-impact workflows.
• Using confidence or source-grounding signals to explain a model lifecycle change.
• Leaving retired models selectable after calls now fail.

Critique Questions

• Can users tell which model version is changing and when?
• Does the notice say whether action is required, auto-upgrade applies, or no action is needed?
• Can users find every affected prompt, workflow, deployment, or automation from the notice?
• Is there a test or comparison path before migration changes production behavior?
• Does dismissal mean only hidden for now, or verified migration complete?
• What state appears after the model is retired or a migration fails?