Your product depends on something you do not control and that changes without asking. A model upgrade is a breaking change delivered by a third party, and the discipline for surviving it is the same discipline that lets you improve anything safely, which is why this topic sits next to evaluation rather than in operations.
| # | Lesson | The question it answers |
|---|---|---|
| 01 | A Model Upgrade Is a Breaking Change | Why does a better model make your product worse, and how often? |
| 02 | Version Pinning and What It Costs | What do you pin, and what do you give up by pinning? |
| 03 | The Migration Runbook | How do you move to a new model without a surprise? |
| 04 | Detecting Drift in Production | What signals move first when quality degrades? |
| 05 | Regression Suites for Prompts and Models | How do you keep a fix from being undone by the next change? |
| 06 | Deprecating a Model You Depend On | The provider retires it in ninety days. What now? |
| 07 | Vendor Risk and Multiple Providers | Is portability worth what it costs you in quality? |
| 08 | Prompt Drift | Why does a prompt that worked stop working, with no model change? |
| 09 | Corpus Drift | What happens when the knowledge behind retrieval goes stale? |
| 10 | Rate Limits, Outages and Degradation | What does your product do when the model is unavailable? |
| 11 | Planning Around a Moving Frontier | How do you commit to a roadmap when capability changes quarterly? |
| 12 | Worked: A Model Migration | One real upgrade, with the regression it nearly shipped |