The notice arrived by email on a Tuesday. The model version behind Kudu's in-app assistant would be retired in ninety days, and customers should move to the newer version, which the provider described as more capable in every respect. The product owner forwarded it to the team with one line: "Can we just switch?"
The developers switched it in a test environment the same afternoon and asked the assistant twenty questions. The answers read well, arguably better than before. The release manager, who had long since learnt to ask for evidence rather than impressions, asked what the twenty questions proved. The honest answer was that they proved the new model could write fluent sentences about repeat prescriptions. Nobody had written down what the assistant had to do well, so nobody could say whether the new model did it.
Kudu Pharmacies is fictional, and its systems and figures are illustrative. Kudu's app, Kudu Repeat, lets patients request repeat prescriptions for collection or delivery. Since the earlier parts of this series, Kudu has added an assistant that answers questions about request status, collection times and stock, and can start two bounded workflows: requesting a repeat and changing the collection store. It does not give clinical advice. Questions about medicines go to a pharmacist.
A model change is a release
Earlier parts treated code changes as the thing a release decision is about. An AI feature adds new kinds of change that alter behaviour without touching code: a new model version, an edited system prompt, a refreshed retrieval index, a changed tool, a new threshold. Each one can change what patients are told. Each one deserves a release decision.
The problem is that teams usually evaluate these changes informally, by trying a few examples, because nobody has defined what the assistant must do. Without that definition, every evaluation is a matter of taste. Part 4 showed that a passed test is not readiness. With AI features the gap is wider: there may be no test at all, only an impression. Evals that gate real work sets out the forms of evaluation a team can use. This part adds two things that decide which of them a given change needs: a written definition of good, and a classification of the change itself.
Write good down before the change
The first step is a document that states, in testable terms, what the assistant must and must not do. Anthropic's documentation on defining success criteria recommends criteria that are specific, measurable, achievable and relevant, and gives the example of replacing "safe outputs" with a measured rate on a stated number of trials (checked on 5 November 2026). That is the right spirit. Kudu's definition of good has four kinds of statement, because each is tested differently.
Hard rules are things that must never or always happen. The assistant never recommends a dose, a substitute medicine or whether to take two medicines together. It never tells a patient a held request is ready, which is requirement RX-214 from Part 1 restated for the assistant. It always returns its workflow requests in the agreed schema. Hard rules are tested with automated checks, pattern rules plus a classifier for the dosing and interaction rules, and any hit blocks release.
Required behaviours are things the assistant must do in defined situations. When a patient asks a clinical question, it hands over to a pharmacist with the question attached. When a request is held for pharmacist review, it says so plainly and gives the expected time. Required behaviours are tested against a labelled set of cases, and the threshold is close to perfect.
Quality judgements are qualities that need judgement to assess: whether the status explanation is accurate, clear and appropriately brief. These are tested with a rubric, scored by people or a calibrated model judge. The Whoever Writes the Rubric series covers how to write and calibrate that rubric; this part does not repeat it.
Outcome measures are what Kudu wants to happen in the real world: fewer calls to stores about request status, a low rate of patients asking the same question twice, no complaints about misleading status messages. These are measured live, after release.
The document is short, owned by the product owner, and co-signed by the senior pharmacist who acts as clinical owner for the app, as in Part 1, for the hard rules and required behaviours. It is versioned. When it changes, that is also a release.
Classify the change
Not every change needs every evaluation. Running a full human review for a typo fix in the prompt wastes the reviewers' attention, and running only assertions for a model migration misses most of what can go wrong. The second step is to classify each change by what it is likely to break.
| Change | What it most often breaks | Cheapest evaluation that can catch it |
|---|---|---|
| Model version | Required behaviours and tone; format compliance; resistance to manipulation | Full assertions; labelled required-behaviour set; rubric sample; full adversarial suite; staged rollout |
| System prompt | The behaviour the edit targeted, and its neighbours | Assertions; required-behaviour cases near the edit; rubric sample; adversarial sample |
| Retrieval source or index | Factual accuracy of answers; instructions planted in content | Assertions; accuracy cases drawn from the changed content; full adversarial suite |
| Tool, workflow or tool permission | Schema, side effects, authorisation | Assertions; workflow tests; full adversarial suite |
| Threshold or policy | Hand-over rates and edge cases | Required-behaviour set at the boundaries; adversarial sample; live monitoring of hand-over rate |
The table is CloudNala analysis based on how these changes typically fail, not a published standard. Each team should adjust it as its own incidents teach it where failures actually come from.
Route each change to the evaluation that can see its failure
The third step makes the classification operational. Every change carries a change type in its work item, and the pipeline uses that type to decide which evaluation layers run and which thresholds apply.
The routing principle is simple: run the cheapest evaluation capable of detecting the failure this change is likely to cause, and do not skip a layer the change could plausibly break. Assertions are cheap and run on every change. The labelled required-behaviour set is moderately expensive, because it needs pharmacist-labelled cases, and runs on any change that can alter behaviour. Rubric review is expensive in reviewer time and runs on a sample sized to the risk. Adversarial cases run in full whenever a tool, a tool's permissions, a retrieval source or the model changes, and a sample runs on every other change; they are the subject of the next part. Live monitoring runs always, with thresholds that tighten for the first days after a high-risk change.
The routing rules belong in the release record. Part 3 set out the minimum metadata that links a work item to a release decision. For AI changes, add the change type, the evaluation layers that ran, their results against the thresholds in the definition of good, and the version of the definition itself.
What the migration actually showed
Kudu ran the model migration through the full route.
- Assertions: all passed. The new model never recommended a dose in 400 adversarially phrased prompts, always used the schema, and never confirmed a held request.
- Required behaviours: this is where it failed. On the labelled set of 180 cases, the new model handed clinical questions to a pharmacist less often than the old one. It had become more willing to give general information, such as "this medicine is usually taken with food", before suggesting the patient speak to a pharmacist. None of those answers broke a hard rule, because none recommended a dose. They did break a required behaviour, because the definition of good says clinical questions are handed over, not partly answered.
- Rubric: the new model scored slightly better on clarity, which is why the twenty-question trial had looked good.
The team did not revert. It added an explicit instruction about clinical questions to the prompt and a harness check that routes any answer mentioning a medicine's use, effect or interaction to the pharmacist queue regardless of the model's choice. The required-behaviour set then passed at the agreed threshold. The release went to five per cent of users for a week, with the hand-over rate and repeat-question rate monitored, then to everyone, three weeks before the retirement date.
The point is not that the new model was worse. On most measures it was better. The point is that "better" is not a release criterion. The definition of good is, and it caught a change in behaviour that a fluent demonstration would have hidden.
Common failure modes
- Defining good after the result is known. If thresholds are set after the evaluation runs, they tend to be set where the new version happens to land.
- One aggregate score. A single quality number averages hard rules, behaviours and tone together. A failed hard rule must never be offset by better tone.
- Treating provider upgrades as safe. A provider's claim that a version is more capable is a published claim about general performance, not evidence about your use case.
- Skipping the definition for small changes. Small prompt edits are where unreviewed behaviour change most often enters, precisely because they feel small.
- No owner for the definition. If nobody owns the document, it drifts from the product, and evaluations test the assistant you used to have.
A release checklist for model and prompt changes
- Is there a current, versioned definition of good, with hard rules, required behaviours, quality judgements and outcome measures?
- Did someone with the authority to do so sign off the hard rules and required behaviours?
- Does the change carry a change type, and did the pipeline route it to the layers that type requires?
- Did every hard rule pass without exception, and did each other layer meet its stated threshold?
- Is there a staged rollout with live thresholds and a named person who can stop it?
- Does the release record name the definition version, the layers run and their results?
Key points
- Model versions, prompts, retrieval content, tools and thresholds all change behaviour, so each change is a release.
- Write good down before the change: hard rules, required behaviours, quality judgements and outcome measures, each tested differently.
- Classify every change by what it is likely to break and route it to the cheapest evaluation that can detect that failure.
- Never let a better score on one layer offset a failure on another, and never treat a provider's upgrade claim as evidence for your use case.
- Record the definition version, the layers run and their results in the release record.
Next: Part 11, Red-teaming tool-using agents. All parts are on the series page.
How CloudNala can help
CloudNala helps teams prepare for model migrations and prompt changes before the deadline arrives. We work with your product owner and domain experts to write a testable definition of good, classify your change types, set up evaluation routing in your pipeline and design a staged rollout with live thresholds, so that the next provider notice becomes a routine release instead of a gamble.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Release Evidence Review or write to us at consult@cloudnala.co.za