A model upgrade quietly turned our AI output into templates
Three times this summer our own AI steps fell back to generic output without an error anyone could see. A timeline, and what a model change exposed.
3 min read Provecta Group
On 1 July we wrote about a drafting step in our back office that had been returning fallback skeletons instead of real drafts, with no error. We said then that a fallback must say it is a fallback, and that we had written the lesson down so we would not pay for it twice.
This week we paid for a version of it twice more. Here is the timeline, because the details are more useful than the summary.
28 July, just after midnight. We fixed a problem where engagement plans and proposals generated in our back office were coming out generic. A real plan takes the model 45 to 55 seconds to write. The internal time limit on those two steps was lower than that. When the limit hit, the code fell back to a standard template plan and carried on. One client engagement had a plan that read like it could belong to anyone.
The cause was the same family as the June problem, in a different place. The fix was the same too: give those steps enough time to finish within the hosting limit. Plans already generated as templates needed regenerating by hand.
28 July, an hour later. Having now been caught twice by silent fallbacks, we added a daily health check. Every morning it pings each live system we run, tests the AI connection and looks for signs that output came from the fallback path instead of the model. If anything is red, it sends an alert to whoever is operating the platform.
29 July. We found the bigger one.
Newer models in the family we use for most generation reject a setting that older models accepted. It controls how varied the model's wording is, and our shared code had always sent it. Sent to a newer model, it produced an error. That error was not one our code treated as worth retrying, so every generation that used a newer model failed, and each failure fell back to a generic template.
The scope was everything that called that shared code on a newer model: plans, proposals, document drafts, contract drafts, replies. The health check we had added the day before did not catch it, because its test called a smaller, older model without that setting. The test passed. The real work was failing.
The fix itself was small. Leave the setting out for newer models, and if that specific error ever comes back, strip the setting and retry the same model.
Why a model change is an accuracy problem
Most firms think about AI accuracy as the model saying something false. This failure had nothing to do with what the model knew. The model never got to answer. A template answered for it, and the template looked plausible.
Model changes make this more likely, and they are becoming routine. Vendors release new versions often, defaults change, older versions get retired. Any automation that quietly picks up "the latest model" can change behaviour overnight without anyone touching it. If that automation has a polite fallback, the change can be invisible.
What the memory did, and did not, do
It did not prevent any of the three failures. A person reading output closely found each one.
What it did was make each fix travel. After the 29 July fix we wrote a reference note into our company memory, the shared record every AI working session reads before it starts. It names the setting, which model families reject it, and which of our other systems share the same code and need the same change before they move to a newer model. Those other systems are not all fixed yet. The note means nobody will rediscover the problem from scratch when they are.
If you run AI anywhere in a workflow
Before your next model change, or right now if you do not know which model your tools use:
- Write down five real tasks your AI automation does, with an example of good output for each.
- After any model change, run all five and compare length and substance against the examples. Templates tend to be short and generic, which makes them easy to spot side by side.
- Make sure any health check tests the same model and the same settings as the real work. A test that uses a different path proves the different path works.
Run a quick check on your operating setup at pgco.world/tools/os-health. Book 20 minutes at pgco.world/book.