# AI change log

Connect every change to the problem it addresses and the checks performed. Changes to instructions or source documents can alter AI behaviour even when application code is unchanged.

Revision: 2026-09-24

## When to use it

When instructions, models, sources, rules or integrations change in a system that has already been tested or put into use.

## Expected output

A version history with rationale, impact, verification evidence and a release decision.

## 1. Describe the change

Record the proposal before applying it. Avoid vague labels such as “optimisation”: readers should understand what changes in everyday work.

### Identifier, author and version

Record date, author, starting version and a reference to the proposed configuration.

________________

### Problem and evidence

Link the case, defect or request motivating the change; distinguish the symptom from its suspected explanation.

________________

### Components and expected effects

List prompts, sources, fields and systems involved; specify behaviours that must remain unchanged.

________________

> Illustrative example, replace with your own: Illustrative example: revise date extraction to distinguish issue date from deadline after an ambiguous case. Other document fields must retain their existing meanings.

## 2. Check the impact

Repeat relevant checks and inspect connected behaviour for regressions. Fixing one case alone does not demonstrate an overall improvement.

### Reproduction and regression cases

List cases reproducing the defect, ordinary cases and cases where the system should request review.

________________

### Before and after results

Record correctness, critical failures, review requests and observed limits using identifiable configurations.

________________

### Approver and conditions

Specify who assesses operational impact and which defects or conditions prevent release.

________________

> Illustrative example, replace with your own: Illustrative example: the new instruction resolves the ambiguous date but omits an explicit deadline elsewhere. Release stays paused until the new failure is understood.

## 3. Track release and recovery

Keep the connection between versions and processed cases. For changed sources and data, describe how previous context can be reconstructed when permitted and necessary.

### Activation and affected cases

Record environment, time, included groups and how cases processed by the new version are identified.

________________

### Reversion and recovery conditions

Describe the previous version, stopping procedure and checks for effects already produced.

________________

### Follow-up and closure

Assign who observes initial results, when closure is decided and where regressions are recorded.

________________

> Illustrative example, replace with your own: Illustrative example: enable the correction for drafts only. If critical errors appear, restore the previous configuration and review cases from the affected window.

## Pitfalls to avoid

- Changing production configuration without being able to identify it.

- Recording code changes while overlooking sources, prompts and rules.

- Closing a change without inspecting its first live outcomes.

Stolen Orbit — https://stolenorbit.com/en/templates/ai-change-log/