AI products are sold on the promise that they improve over time. Models are upgraded, prompts are refined, retrieval indexes are refreshed with new documents, and some systems learn from the feedback their users give. In a chat assistant, that is mostly welcome. In a system that helps decide who gets a bursary, a permit or a claim payment, it is a problem, because each of those changes can alter outcomes for real people without anyone with authority deciding that the outcomes should change.
Policy changes in a well-run organisation go through approval. A board amends the threshold, the amendment has an effective date and a record, and staff are told. A model upgrade that quietly makes the extraction step read informal-earnings affidavits differently can shift outcomes just as much, and it often goes through no approval at all, because it was treated as a technical update.
This final part of the series is about closing that gap. Amatola Bursary Agency, the fictional agency we have followed, treats any change that can affect a decision as a change to the decision system, whatever its source.
Four ways decisions change without a policy change
The model changes. A provider releases a new version, or the team switches to a cheaper model. Extraction accuracy shifts, usually up overall and sometimes down on particular document types. Draft reasons change tone and emphasis.
The prompt or instructions change. Someone improves the extraction prompt to fix one problem. The fix changes behaviour on cases nobody looked at.
The retrieval index changes. New guidance documents are added, old ones expire, a re-indexing job changes how text is split. The assistant now retrieves different context for the same case.
The system learns from feedback. If corrections made by officials are fed back to fine-tune or adjust the model, the model's behaviour drifts towards the patterns in those corrections, including any mistakes or inconsistencies in them.
Because of the separation set out in Part 6, none of these can directly change the rule. They can change the facts that reach the rule and the reasons people read, which is enough to change outcomes.
One gate for every change
Amatola puts all four kinds of change, plus ordinary rule changes, through the same gate.
Shadow run on past cases. The changed system is run against a fixed replay set of past cases, without affecting any live decision. The replay set includes the golden scenarios from Part 7 and a sample of recent real cases, stratified so that less common document types and applicant groups are represented.
Difference report, case by case. The output is not an accuracy score. It is a list of every case where the extracted facts, the outcome or the reasons changed, with the old and new values side by side. An accuracy score that rises from 94 to 96 per cent can hide two hundred cases that flipped in both directions (illustrative figures). The list shows them.
Owner approval and release note. The rule owner reviews the differences, with the AI engineer explaining why they occur. If the changes are improvements, the owner approves and the release is recorded with a note: what changed, why, which cases would have been affected and from when it applies. If any changes reflect a shift in how the policy is applied, they are treated as an interpretation change and recorded as one.
Release. Only then does the change reach live decisions. The case file from Part 4 records the new model, prompt and index versions from that point on.
Pin everything that can move
The gate only works if the things it controls cannot change without it. In practice that means pinning:
- Model versions. Use a specific dated model version rather than an alias that the provider moves. Where a provider retires a version, the retirement date is a scheduled change that goes through the gate in good time.
- Prompts and instructions. Store them in version control and reference them by version, not by editing text in a console.
- Retrieval indexes. Build indexes as versioned artefacts. A refresh produces a new version that is tested and released, not an in-place update.
- Feedback loops. Collect corrections continuously, but apply them to the model only in deliberate, versioned training or tuning runs that go through the gate.
Pin the version before you pin your hopes on the platform covers the platform side of this. The decision-system point is narrower: every pinned version is part of the evidence for every decision made with it.
Drift without a change
Outcomes can also shift with no change to the system at all, because the cases change. A new employer starts issuing payslips in a format the model reads poorly. A drought changes the income profile of applicants from one district. A new school starts submitting results in a different layout.
The production signals from Part 7, appeal rates, overturn rates, "cannot decide" rates and extraction confidence by document type, are how Amatola sees this. A sustained shift triggers a review. If the review finds the system handling new inputs badly, the fix goes through the gate like any other change. If it finds the policy producing unintended outcomes in new circumstances, that goes to the policy owner as a possible rule change.
What "continuous improvement" should mean
None of this argues against improvement. Amatola's system is better than it was a year ago, because corrections were collected, models were upgraded and prompts were refined. The difference is that each improvement was visible, tested against real cases, approved by someone accountable for the outcomes and recorded.
That is the theme of the whole series. Rules become explicit and owned (Parts 1 to 3). Every recommendation keeps its evidence (Part 4). Appeals test the rules and correct them (Part 5). The model reads and writes but does not decide (Part 6). Testing proves each part separately (Part 7). And change, from any source, passes through the same gate. Together, those are what make it possible to use AI in consequential decisions and still answer the question every affected person is entitled to ask: why was this decided, and who decided it?
For public bodies, Can South Africa build machine-readable government? sets out a bounded way to start.
Back to the beginning: Part 1, A policy document is not an executable rule. All parts are on the series page.
How CloudNala can help
CloudNala helps teams put change control around AI-assisted decisions. We inventory everything that can change an outcome, pin model, prompt and index versions, build the replay set and the case-by-case difference report, and set up the approval and release record so that improvements reach live decisions only with the approval of the person accountable for them.
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 an AI Decision Review or write to us at consult@cloudnala.co.za