A silent model swap still needs change control

When a Bedrock (or any) model ID changes underneath a product, demos often treat it as a config tweak. From a Business Analysis lens it is a change request — even if nobody filed a ticket.## Why "same prompts, new model" is not freeTeams swap models for good reasons: price, latency, a new capability, or a provider sunset. The UI may look identical. The prompts may stay. Users may not notice for days. That is exactly why silent swaps are dangerous: the product still appears healthy while behavior drifts.Things that commonly move when the model ID changes:1. Refusal and safety style — what used to escalate now answers, or the reverse.2. Latency and timeout pressure — a slower model turns a "wait" into a user-facing failure.3. Cost per successful task — same feature, different bill shape.4. Tool-calling shape — field names, missing fields, or partial results that the next step assumed were stable.5. Tone and confidence — support tickets that look like "the AI got dumber" without a deploy in the changelog.None of that requires claiming a production fleet. It shows up in student demos the first time someone "just tries the newer model."## What I would put in the BRD / change recordBefore treating a model ID change as routine ops, I would write:- Trigger — who may change the default model, and with what notice.- Baseline suite — a small set of frozen cases (happy path, refuse, empty retrieval, partial tool result) that must be re-run.- Pass/fail for product, not only accuracy — latency budget, cost ceiling per task, and "must escalate" cases.- Rollback — how to pin the previous model ID if the suite fails or support spikes.- User-visible note — when the change is silent vs when the product should say something changed.- Log fields — model ID, region, and whether this request used the fallback model.A useful acceptance criterion looks more like:Given the default Bedrock model ID changes from A to B, the frozen baseline suite still meets the refuse/escalate cases, p95 latency stays under the agreed budget, and the previous model ID remains pin-able within one config change.## Questions I would ask early1. Is the model ID a product decision or only an engineering preference?2. Which behaviors must not change without a human review?3. What is the cost and latency budget after the swap — not only "it still answers"?4. Who owns the rollback if support volume jumps and nothing "broke" in CI?A silent model swap is still a requirements change. Put it under change control before the next "drop-in" update trains users — and the team — that drift is normal.I'm a university student exploring AI Business Analysis and learning AWS. If you document model ID changes differently in your acceptance criteria, I would like to learn how you phrase them.