Appendix M: AI Change Request Template

Review the Consequence, Not the File Size

A support assistant team replaces a long system prompt with a shorter version. The code diff is six lines, latency improves, and ordinary test prompts still pass. A week later, agents discover that the new prompt no longer requires citations for refund-policy answers. The change was labeled low risk because it was small; its behavioral effect was not reviewed at all.

An AI change request connects a proposed change to the system behavior and evidence it may invalidate. Models, prompts, retrieval corpora, thresholds, tools, interfaces, policies, and human procedures can all change outcomes. The useful question is not “How large is the diff?” but “Which claims, controls, populations, and operating assumptions could stop being true?”

Establish the Baseline Before Proposing the Change

Name the currently approved system version, release scope, acceptance evidence, risk record, and operating envelope. A reviewer cannot judge a change without knowing what the organization previously approved. Freeze the candidate components precisely enough to reproduce them: model identifier, prompt and policy versions, retrieval snapshot, data and feature pipelines, tool permissions, code, interface, and monitoring configuration.

Classify materiality from credible consequence and uncertainty. A routine change has bounded effects already covered by valid regression evidence. A significant change can alter important behavior, performance, control effectiveness, or workload and needs targeted re-evaluation. A material change can alter purpose, affected population, decision authority, rights or safety exposure, security boundary, data use, or maximum credible harm; it requires renewed cross-functional review and may require a new launch decision.

Do not let the requester make the final classification alone. Delivery pressure and familiarity with the implementation can hide downstream consequences.

AI Change Request

CHANGE IDENTITY
Request ID and title:
Requester and accountable change owner:
System and current approved release:
Baseline approval record and date:
Proposed release / immutable candidate:
Requested deployment window:
Reason: defect / performance / safety / security / policy / cost / provider / user need / maintenance
Related incident, monitoring signal, complaint, audit, or decision record:

REQUESTED CHANGE
Current behavior and configuration:
Proposed behavior and configuration:
User or operational problem addressed:
Expected benefit and measurable success condition:
What is explicitly out of scope:

COMPONENTS AFFECTED (mark and identify versions)
[ ] Model, adapter, fine-tune, or inference settings
[ ] System, developer, or user prompt
[ ] Policy, guardrail, classifier, or threshold
[ ] Training, evaluation, or production data
[ ] Retrieval corpus, index, ranking, or permissions
[ ] Feature or data pipeline
[ ] Tool, API, identity, permission, or action limit
[ ] Orchestration, memory, or agent plan
[ ] Application code or infrastructure
[ ] User interface, notice, explanation, or consent
[ ] Human review, escalation, fallback, or support workflow
[ ] Logging, monitoring, alert, or retention configuration
[ ] Provider, supplier, contract, region, or dependency
Versioned diff / artifact links:

CONSEQUENCE TRACE
Capabilities added, removed, or altered:
Populations, segments, languages, regions, or channels affected:
Data collected, inferred, retained, disclosed, or reused differently:
Decisions or actions whose timing, scale, or authority changes:
Human workload, information, authority, or fallback affected:
Security, privacy, safety, fairness, accessibility, or rights exposure:
Performance, availability, latency, or cost envelope affected:
Interfaces, downstream consumers, and undocumented dependencies:
Worst credible unintended consequence:
Uncertainties and assumptions:

EVIDENCE IMPACT (repeat for each affected claim or control)
Claim or control under review:
Prior acceptance condition and evidence link:
Why that evidence remains representative—or no longer does:
Replacement or regression evidence required:
Population, segment, environment, or failure mode covered:
Acceptance floor and decision rule:
Evidence owner, status, and review date:

MATERIALITY ASSESSMENT
[ ] ROUTINE: bounded behavior; approved regression evidence remains representative
[ ] SIGNIFICANT: important behavior, evidence, control, or workload may change
[ ] MATERIAL: purpose, population, authority, data use, risk tier, or credible harm may change
Proposed classification and rationale:
Independent reviewer and classification:
Required review forum and approvers:

EVALUATION AND REVIEW PLAN
Regression tests:
New or repeated offline evaluations:
Segment, accessibility, fairness, and harm checks:
Security, privacy, abuse, and adversarial checks:
Human and domain review:
Integration, load, resilience, and fallback tests:
Acceptance floors and non-tradeable gates:
Evidence owner and review date:

RELEASE AND RECOVERY PLAN
Shadow, canary, pilot, staged, or full-release path:
Initial scope, traffic, users, permissions, and duration:
Success, pause, and stop conditions:
Monitoring queries, dashboards, and alert owners:
Rollback target and maximum rollback time:
Data, index, schema, or side-effect reversal:
Irreversible effects and remedy:
Recovery verification:
Who may expand, pause, roll back, or terminate:

DOCUMENTATION AND COMMUNICATION
[ ] Model, system, dataset, evaluation, and risk records updated as applicable
[ ] User notices, instructions, limitations, and support material updated
[ ] Operators, reviewers, responders, and affected teams trained or briefed
[ ] Release notes describe behavioral and control changes
[ ] Supplier and downstream-consumer changes communicated
Links and owners:

DECISION
[ ] APPROVED for requested release path
[ ] APPROVED WITH CONDITIONS
[ ] RETURNED for evidence or revision
[ ] REJECTED
Approved scope and prohibited expansion:
Conditions, owners, due dates, and expiry:
Residual risk and accepting owner:
Approvers and timestamps:

POST-RELEASE VERIFICATION
Verification window:
Observed outcomes against success and guardrail measures:
Unexpected segment, workload, cost, or control effects:
Incidents, complaints, overrides, or rollback events:
Decision: expand / hold / revise / roll back / retire
Closure evidence and approver:

Materiality Triggers

The following conditions should normally prevent a routine classification:

• a new purpose, affected population, jurisdiction, language, or deployment channel;
• new personal or sensitive data, a changed lawful-use assumption, or materially different retention or sharing;
• greater action authority, broader tool permissions, or a larger blast radius;
• a provider, model, retrieval, or policy change that can alter output behavior in ways the current evaluation set does not cover;
• changed thresholds that redistribute false positives, false negatives, abstentions, or human workload;
• removal or weakening of oversight, appeal, fallback, monitoring, or security controls;
• an incident-driven fix whose side effects and recurrence risk have not been demonstrated;
• a change to a high-consequence workflow, even when the implementation diff is small.

Materiality is not permanence. A temporary experiment can still create material exposure, and a long-planned infrastructure migration may be routine when equivalence is demonstrated.

Worked Change: Retrieval-Ranking Upgrade

A policy assistant proposes replacing its lexical-plus-vector ranker with a neural reranker. The purpose and corpus do not change, but citation selection, latency, segment performance, and cross-tenant filtering order might. The requester initially marks the upgrade routine because permissions are enforced before generation.

The reviewer classifies it significant. Existing answer-quality evidence is no longer representative, and a ranking timeout could invoke a fallback path that has not been exercised at production load. The release plan repeats groundedness and citation evaluations by document type, verifies tenant isolation before and after ranking, load-tests fallback, runs a five-percent canary, and monitors unsupported-answer rate, retrieval latency, empty-result rate, and permission denials. Expansion requires every segment floor to pass; a cross-tenant canary or citation regression triggers immediate rollback.

The classification does not imply that the new ranker is unsafe. It recognizes that the change invalidates specific claims and specifies the evidence needed to restore confidence.

Review the Request Under Pressure

Return to the six-line prompt change from the opening. The missing citation instruction caused a visible support failure, so the team proposes an emergency fix: restore the old sentence, run the ordinary prompt suite, and deploy globally before the next shift. The request calls the change routine because the old wording was previously approved and rollback takes seconds.

Review that request before completing the form. Which claim does the restored sentence need to recover: citation presence, citation support, correct policy selection, or all three? Does the earlier approval evidence still represent the current model, corpus, interface, languages, and agent workflow? Ask whether the urgent global deployment is easier to reverse technically than it is to reverse after agents send unsupported policy advice. Then name the smallest initial scope that can reveal a regression, the stop condition, the person who may halt expansion, and the evidence needed to close the incident-linked change.

Now remove one convenience. Suppose the previous prompt version cannot be reproduced because its provider-side policy wrapper was never recorded. Restoring the sentence no longer restores the accepted bundle. The request must identify that uncertainty, route upward, establish a new pinned baseline where possible, and test the combined behavior rather than treating familiar text as evidence. A useful change record makes that uncomfortable fact visible before urgency turns it into an assumption.

Use this request with Change Management and Continuous Improvement, the AI Evaluation Plan, and the AI Launch Readiness Checklist.