UX Patterns Guide
UI + UX AI And Automation UX emerging

Model update notice

Provide a dedicated model update notice that connects lifecycle state, model version, deadline, affected usage, replacement, migration requirements, evaluation results, rollout status, and post-change verification in one actionable surface.

Open in lab Compare alternatives
Decision first

Choose this pattern when the problem matches

Use when

  • A model version, provider, lifecycle stage, availability, behavior, or replacement plan changes in a way users may need to understand or act on.
  • A product needs to help admins, developers, or workflow owners migrate AI surfaces safely before a deadline.

Avoid when

  • The message is ordinary product release news with no model behavior, lifecycle, or migration impact.
  • The user only needs confidence for one answer or source evidence for one claim.
  • The service is announcing alpha or beta maturity rather than a model lifecycle change.

Problem it prevents

AI model changes can alter or break high-value workflows, but products often announce them as ordinary feature news or hidden release notes, leaving users without impact scope, deadlines, replacements, testing paths, migration ownership, or rollback planning.

Test the behavior

Open the interactive example when you need it

The full lab is intentionally loaded on request. That keeps this reading page fast while preserving the strong and weak states, keyboard checks, and failure scenarios.

In the lab you can
  • switch between strong UI, weak UI, strong UX, and weak UX;
  • trigger required, empty, loading, error, and recovery states;
  • inspect keyboard and accessibility expectations beside the demo.
Launch Model update notice in the lab
Pattern anatomy

What a strong implementation has to make clear

User need

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.

Pattern promise

Provide a dedicated model update notice that connects lifecycle state, model version, deadline, affected usage, replacement, migration requirements, evaluation results, rollout status, and post-change verification in one actionable surface.

Required state

Informational model update state with model name, version, capability change, effective date, and no action required.

Recovery path

The notice says model updated but hides the old model, new model, version, or retirement date.

Access contract

Expose model names, dates, lifecycle stage, action requirement, affected count, and migration status as text, not color alone.

Quality bar

The difference between expert and weak execution

Strong implementation

Specific, visible, recoverable

  • An admin console banner says GPT-4o 2024-08-06 retires on 2026-10-01, shows replacement GPT-5.1, lists three affected assistants, links to migration tests, and marks provisioned deployments as manual migration required.
  • A model picker marks Legacy model in use, shows Deprecated and Retires in 42 days, compares replacement latency and cost, and lets the owner run an evaluation before switching.
  • A developer sees a model retirement notice, opens the affected endpoint list, runs a saved regression set against the replacement model, schedules rollout, and dismisses the notice only after migration is complete.
  • A support admin learns that preview deployments may be force-upgraded, reviews high-risk automation, pauses one workflow, and confirms the replacement model has the required region and tool support.
Weak implementation

Vague, hidden, hard to recover from

  • A broad New model available banner appears with no current model, replacement model, deadline, impacted flows, or action path.
  • A chat product silently changes model behavior overnight and users only discover the update after saved prompts produce different outputs.
  • The notice says better model coming soon but does not say whether existing API calls will fail, auto-upgrade, or produce different behavior.
  • A model deprecation email links to a changelog but the product UI still shows the retired model as healthy.
UI guidance
  • Render model update notice as a lifecycle-specific communication that names the current model, new or replacement model, affected product surface, effective date, retirement or shutdown date, expected behavior change, migration path, test window, and whether action is required.
  • Show affected deployments, prompts, workflows, fine-tunes, evaluations, APIs, quotas, regions, auto-upgrade status, provisioned or manual migration requirements, and owner or admin contact where the change can break or alter AI behavior.
UX guidance
  • Use model update notice when a model change can affect availability, output quality, latency, pricing, safety behavior, compliance, prompt compatibility, tool use, evaluations, or user trust.
  • Make the notice actionable: help teams identify impacted usage, compare replacement behavior, run regression tests, schedule migration, pause risky automation, and verify that the notice is no longer needed after migration or retirement.
Implementation contract

What the implementation must handle

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.

Interaction

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

Accessibility

  • Expose model names, dates, lifecycle stage, action requirement, affected count, and migration status as text, not color alone.
  • Announce status changes such as test completed, migration failed, auto-upgrade scheduled, or model retired without moving focus unexpectedly.
  • Use accessible tables or lists for affected workflows, deployments, owners, and replacement test results.
  • Provide meaningful link text such as Review affected assistants or Test replacement model instead of Learn more alone.

Review

  • 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?
Evidence trail

Source-backed claims behind this guidance

OpenAI API deprecations

OpenAI - checked

Supports model deprecation notices, replacement recommendations, shutdown dates, and migration planning.

Full agent/debug reference

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?
Accessibility
  • Expose model names, dates, lifecycle stage, action requirement, affected count, and migration status as text, not color alone.
  • Announce status changes such as test completed, migration failed, auto-upgrade scheduled, or model retired without moving focus unexpectedly.
  • Use accessible tables or lists for affected workflows, deployments, owners, and replacement test results.
  • Provide meaningful link text such as Review affected assistants or Test replacement model instead of Learn more alone.
  • Ensure countdowns and dates have absolute date text, not only relative time.
Keyboard Behavior
  • Tab reaches affected usage, test replacement, migrate, snooze, dismiss, rollback, and help actions in logical order.
  • Enter or Space activates migration and test controls.
  • Escape closes detail panels without dismissing required migration notices.
  • Arrow keys move within affected-item tables, tabs, segmented controls, or comparison views when used.
  • Focus returns to the triggering notice action after closing a migration, comparison, or affected-usage panel.
Variants
  • Deprecation notice
  • Retirement countdown
  • Auto-upgrade scheduled notice
  • Manual migration required notice
  • Preview model warning
  • Behavior change notice
  • Replacement model comparison
  • Affected usage inventory
  • Post-retirement blocked state

Verification

Source trail checked:

Saved items