A routine for every change

The Claude Code case in Chapter 1 turned partly on one line added to a system prompt, asking for shorter answers, which passed weeks of internal testing and still hurt the agent’s coding.¹ A one-line change to the text around a model made a new model, and the checks run before release could not catch it.

A change here means an edit to anything in what is served: the weights, adapters, numeric precision, serving engine, sampling settings, chat template, system prompt, harness or tools (Chapter 2). It includes the changes a provider makes on your behalf. The routine below applies to all of them, and it needs nothing more exotic than a fixed set of test items, a script that runs them, a log, a second person and the discipline to decide before looking. It has five parts:

1. Write the release thresholds before the change.
2. Compare old and new, both as served, item by item.
3. When something fails, roll back first.
4. Re-verify any repair on items it never saw.
5. Record who checked, and whether that person was independent of the fix.

Thresholds come first

Write down, before any result exists, what this change will be scored on and what result blocks the release. The rule names the items, the threshold, the approvers and the version to roll back to. A threshold chosen after the results tends to fit the results.

The threshold has to sit above the noise. Run the current version against itself on the same items, settings and hardware, and count how many answers change. Chapter 4 explains why reruns of an unchanged model disagree and how few items it takes to mislead; that count is the noise floor, and differences below it mean nothing. If another model grades the answers, run the grader twice on the same answers and add its disagreements to the floor. Keep the item set fixed and versioned between releases.

An average alone is a weak threshold. AIUC-1, a voluntary certification standard for AI agents, gives a swing of plus or minus 10% in evaluation performance as one example of a change material enough to need approval.² Averages hide trades: in a 2020 Microsoft Research study of model updates, new errors appeared on items the old model handled even when overall accuracy rose.³ So put a second number beside the average: how many items, above the noise floor, may go from pass to fail. Those are called flips.

Compare old and new as served

Who made the change decides when it can be caught. Your own change can be compared with the old version before any user sees it. A provider’s unannounced change reaches your users first and is caught only by scheduled runs of your own items against the live service.

The comparison runs item by item. Old and new, as served, answer the same items: refusals that must hold, legitimate requests that must not be refused, and the task itself. For agents, add tests of prompt injection and permission handling. List the items that flipped beside the averages. Write items for the failures your deployment cannot afford, such as turning away your own customers. A 2026 study of hosted model updates found that tests aimed at specific risk areas turned up regressions that overall metrics missed.⁴

The value of a check that finds nothing depends on the share of real failures it would have caught. Measure that share on your own system by planting failures you know about: a prompt line that once broke something, a deliberately degraded model, a replay of a past incident. Count how many the comparison flags, then run harmless changes through it and count the false alarms. Published examples are rare. One published fine-tuning auditor caught 56.2% of adversarial fine-tunes at a 1% false-alarm rate in its best configuration, and subtle, unintended safety loss from ordinary fine-tuning remained hard for it.⁵ Where a check finds nothing, the record should say how sensitive it was known to be.

Roll back first

The first repair is the previous version, kept ready to serve: old weights, adapters, template, prompt and engine settings. In the Claude Code case, two of the three changes Anthropic later traced were simply reverted.¹ Google’s site reliability workbook makes the case with a worked example: a team with no way back to a known good configuration has to find the defect, patch it and redeploy during the outage, which “will almost certainly prolong the user impact of the bug”.⁶

Anything other than rollback is itself a change and goes through the whole routine again. A retrained adapter, an edited prompt or a new filter can move behavior it never targeted. In one 2026 study, steering vectors built from entirely harmless data, meant only to make a model more compliant or keep its output in a fixed format, raised jailbreak success rates above 80% on standard benchmarks.⁷

Re-verify on unseen items

After a repair, rerun the whole comparison against the last good version, including the items that passed. Hold back test items the repair never saw. A fix tuned on the failing items can pass them and fail their neighbors.

Test in the setting where the problem was trained as well as where it was found. A 2026 study by Owain Evans’s group and collaborators found that common fixes for emergent misalignment, where narrow fine-tuning makes a model broadly misbehave, cleared standard evaluations while the misbehavior came back on prompts that resembled the training data.⁸ If the fine-tune used a particular template or document format, the re-check includes prompts in that format (Chapter 7). If the weights changed, any monitor or probe that reads the model’s internal activations was fitted to the old weights, and is worth rechecking on known examples before its scores are trusted again.

Whether a repair survives the next change, such as a later fine-tune, quantization or merge, is an open question (Chapter 16). Until it is answered, treat the repaired version as the new baseline and run the routine again at the next change.

Record who checked

A re-verification run by the party that made the fix is a self-check, and the record should say so. A self-check is still evidence; it carries its label. Auditing has worked this way for a long time. The US Securities and Exchange Commission’s auditor-independence rule asks, among its first questions, whether a service puts the accountant “in the position of auditing his or her own work”.⁹ AI evaluations often leave the question unanswered: a 2025 review of evaluation reports found that most omitted context such as the auditors’ backgrounds, their conflicts of interest and their level of access to the model.¹⁰

Independent need not mean outside the company. It means a function with no stake in the fix passing. The European Union’s change-management rules for financial firms require the functions that approve a change to be separate from those that request and implement it.¹¹ A small team can manage a version of this: someone who did not make the fix reruns the comparison from the record alone and checks that the verdicts match.

The change record

A change record lets someone who was not in the room check the release decision. It holds six things:

1. What was served before and after, identified by content hashes: weights and adapters, precision and cache settings, engine version, sampling settings, chat template, system prompt, harness defaults and tools, and the hardware and batch size.
2. Who asked for the change, who made it and who approved it.
3. What was measured: the item set and its version, the item count, the noise-floor run, the flips and the thresholds written beforehand. Name the surface tested. A 2026 audit of ChatGPT, Claude and Gemini found that evaluations run through the API scored 3.4 percentage points higher in accuracy, on average, than the same systems through their chat interfaces.¹²
4. What the measurement cannot show: contexts not sampled, agent paths not run, and whether the checker saw only outputs or the weights.
5. The decision and the way back: ship, hold or roll back, with the reason, any override and who made it, and the rollback target.
6. Who checked the repair, and whether they were independent of it.

Keep records where the next change and the next user complaint can find them. Hashes of what was served also expose a file that was swapped without anyone saying so (Chapter 8).

When the model is rented

A team that calls a provider’s model cannot hash the provider’s weights, but it still keeps a record; the measurement just becomes behavioral. A 2026 survey of nine API providers and seven inference hosts found that none published information that would let an outside party confirm the model being served was the one its documentation described.¹³ The record holds what the team controls and can see: the model identifier returned, the dated snapshot, its own prompt, harness and sampling settings, and its scores on its own items.

Run a fixed set of your own items on a schedule and after every announced change, against that set’s own noise floor. In summer 2024, a Stanford team using a statistical test found that 11 of 31 commercial endpoints for four Llama models served output that differed from Meta’s released weights.¹⁴

Pinning a dated snapshot moves a provider’s change to a date you choose. Anthropic, for one, promises at least 60 days’ notice before retiring a publicly released model.¹⁵ Pinning does not freeze the provider’s serving stack, which can still change underneath the name. Your rollback is the pinned snapshot while it lasts, a second provider, or a switch that turns the feature off. The contract can carry part of the routine: change notice, a deprecation window and a postmortem when a change breaks your items. The record should also state the checker’s access, since testing through outputs alone allows less scrutiny than access to weights and training details.¹⁶

The routine above draws on shared controls that the entries in Part Two name at the end of their fixes. Their short definitions follow.

Twelve shared controls

Control 1 · Served-artifact record

A list of everything that shapes what users get, identified by content hash where possible: weights and adapters, precision and cache settings, serving engine and version, sampling settings, chat template, system prompt, harness defaults and tools. Record what is actually served, which can differ from what was planned. Two versions can only be compared if both are written down this way.

Control 2 · Noise floor

Run the current version against itself, with the same items and settings, and count how many answers change. That count is the noise. A difference between old and new versions smaller than it is not evidence of anything.

Control 3 · Two-artifact battery

Run the old and new versions, both as served, on the same items: refusals that must hold, legitimate requests from your own traffic that must not be refused, and the task itself. For agents, add prompt-injection and permission tests. Compare the results item by item.

Control 4 · Flip report

List the items that passed before and fail now, next to the averages. Count only flips above the noise floor. An average can rise while important items break.

Control 5 · Rollback pointer

Keep the previous version deployable, one step away. That means the old weights, adapters, template, prompt and engine settings. Rolling back is the first repair to try.

Control 6 · Change log joined to reports

Log every change at every layer with a timestamp. Plot user complaints and thumbs-down rates against that log, and name the person who triages them. A complaint that lines up with a change is often the first sign of a regression.

Control 7 · Pin and watch

Use dated model snapshots rather than names that silently move, and watch the provider’s deprecation notices and changelogs. Rerun the old-and-new comparison whenever you move to a new snapshot, and on a schedule in between. Pinning a version delays a provider’s change. It does not stop one.

Control 8 · Graders out of reach

Keep graders, tests and answer keys outside anything an agent can read or write. Hash them before and after each run. An agent that can reach its grader can pass without doing the work.

Control 9 · Closed egress

Deny network access by default for each agent task, including package mirrors, and open only what the task needs. Keep production credentials out of evaluation and training sandboxes.

Control 10 · Paging drill

Fire a synthetic high-severity alert outside office hours and time how long a named person takes to acknowledge it. Run it on every alert route the safety case relies on. A route that has never been tested should be assumed broken.

Control 11 · Approval canaries

Mix requests that should be denied into real approval traffic, each harmless if approved. The share that gets approved is the miss rate of the human check.

Control 12 · Untouched holdout

Keep a small set of human-labeled test items that no training run, prompt search or optimizer ever sees. Use it to check results that tuned processes report. Once it leaks into tuning, replace it.

How this maps to existing change-control rules

Most of the routine is change control that regulated teams already run, pointed at a model. A record mapped to a requirement is evidence for an auditor to weigh. None of the texts below mentions a noise floor or flips; they ask for a decision and a record of it, and the routine supplies the numbers behind both.

Notes

1. Anthropic. “An update on recent Claude Code quality reports.” Engineering at Anthropic, 2026-04-23. https://www.anthropic.com/engineering/april-23-postmortem. A system-prompt line shipped after weeks of internal testing with no regressions on the evaluations run; one evaluation in a broader set later showed a 3% drop, and the line was reverted. ↩︎
2. Artificial Intelligence Underwriting Company (AIUC). “AIUC-1” (requirements E004 and C002). standard.aiuc-1.com, release of 2026-07-15. https://standard.aiuc-1.com/accountability/assign-accountability.md https://standard.aiuc-1.com/safety/conduct-pre-deployment-testing.md. E004 (Assign accountability, mandatory) lists changes requiring approval, including model selection and material changes to the meta prompt, “For example, +/-10% performance on evals”, each with an accountable approver; C002 (Conduct pre-deployment testing, mandatory) requires internal testing before deployment for changes requiring formal review or approval, with documented results and sign-offs. ↩︎
3. Srivastava, Nushi, Kamar, Shah, Horvitz. “An Empirical Analysis of Backward Compatibility in Machine Learning Systems.” arXiv:2008.04572, 2020-08-11. In classifier updates, backward compatibility often fell even when accuracy increased. ↩︎
4. Chishti, Oyinloye, Li. “Test Before You Deploy: Governing Updates in the LLM Supply Chain.” arXiv:2604.27789, 2026-04-30. In exploratory validation across several model versions, tests targeted at specific risk areas found regressions that overall metrics missed. ↩︎
5. Egler, Schulman, Carlini. “Detecting Adversarial Fine-tuning with Auditing Agents.” arXiv:2510.16255, 2025-10-17. With its best set of affordances, the auditing agent detected 56.2% of adversarial fine-tuning at a 1% false-positive rate; benign fine-tuning with unintentional subtle safety degradation remains a challenge. ↩︎
6. Warner, Davidovič, with Hidalgo, Beyer, Smith, Duftler. “Canarying Releases.” The Site Reliability Workbook (Google; O’Reilly), web edition, copyright 2018. https://sre.google/workbook/canarying-releases/. In a worked example, without the option to roll back to a previously known good configuration, patching and redeploying during the outage “will almost certainly prolong the user impact of the bug”. ↩︎
7. Xiong, He, Chen et al. “Steering Externalities: Benign Activation Steering Unintentionally Increases Jailbreak Risk for Large Language Models.” arXiv:2602.04896, 2026-02-03. Steering vectors from benign data raised jailbreak success to over 80% on standard benchmarks. ↩︎
8. Dubiński, Betley, Sztyber-Betley, Tan, Evans. “Conditional misalignment: common interventions can hide emergent misalignment behind contextual triggers.” arXiv:2604.25891, 2026-04-28. Interventions that reduced or removed emergent misalignment on standard evaluations left misalignment that returned on prompts resembling the training context. ↩︎
9. US Securities and Exchange Commission, 17 CFR 210.2-01. “Qualifications of accountants.” Electronic Code of Federal Regulations, current text, last amended 2021-06-09. https://www.ecfr.gov/current/title-17/chapter-II/part-210/section-210.2-01. The Commission looks in the first instance to four factors, among them whether a relationship or service “places the accountant in the position of auditing his or her own work”. ↩︎
10. Staufer, Yang, Reuel, Casper. “Audit Cards: Contextualizing AI Evaluations.” arXiv:2504.13839, 2025-04-18. Most evaluation reports reviewed omitted contextual information such as auditors’ backgrounds, conflicts of interest, and the level and type of access to models. ↩︎
11. European Commission. “Commission Delegated Regulation (EU) 2024/1774” (Article 17, ICT change management). Official Journal L, 2024-06-25. https://eur-lex.europa.eu/eli/reg_del/2024/1774/oj/eng. Recital 17 and Article 17 (ICT change management): approval functions separate from the functions that request and implement changes; fall-back procedures for unsuccessful changes. EUR-Lex shows a browser check to automated clients; the text was read in a browser. ↩︎
12. Wang, Baumann, Ho, Koyejo. “API Benchmark Scores Do Not Reliably Transfer to Chatbot Interfaces.” arXiv:2609.08861, 2026-09-08. API evaluations of ChatGPT, Claude and Gemini scored 3.4 percentage points higher in accuracy, on average, than the corresponding chat interfaces. ↩︎
13. Abraham, Bucknall. “Silent Updates: Measuring and Closing the Post-Deployment Disclosure Gap.” arXiv:2608.11803, 2026-08-12. In preliminary results for nine API providers and seven inference hosts, no provider published information letting an outside party verify that the served artifact is the one its documentation describes. ↩︎
14. Gao, Liang, Guestrin. “Model Equality Testing: Which Model Is This API Serving?” arXiv:2410.20247, 2024-10-26. In summer 2024, 11 of 31 commercial endpoints for four Llama models served output distributions different from Meta’s released weights. ↩︎
15. Anthropic. “Model deprecations.” Claude Platform documentation, living page. https://platform.claude.com/docs/en/about-claude/model-deprecations. At least 60 days’ notice before a publicly released model retires; requests to retired models fail. ↩︎
16. Casper, Ezell, Siegmann, Kolt, Curtis, Bucknall, Haupt et al. “Black-Box Access is Insufficient for Rigorous AI Audits.” arXiv:2401.14446, 2024-01-25. White-box and outside-the-box access allow more scrutiny than black-box access alone. ↩︎
17. † Artificial Intelligence Underwriting Company (AIUC), quoting ISO/IEC 42001:2023. “AIUC-1 × ISO 42001” (crosswalk entry for control A.6.2.5, AI system deployment). standard.aiuc-1.com. https://standard.aiuc-1.com/crosswalks/iso-42001.md. Quotes A.6.2.5 as requiring a documented deployment plan, with appropriate requirements met before deployment, and maps it to AIUC-1 C002. ↩︎
18. Board of Governors of the Federal Reserve System, with the OCC and FDIC. “Revised Guidance on Model Risk Management” (SR 26-2 and attachment). 2026-04-17. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm. Supersedes SR 11-7; footnote 3 of the attachment puts generative and agentic AI models outside its scope and leaves their controls to the bank’s own risk management and governance. ↩︎