Stolen Orbit
ENIT
Let’s talk
FREE TEMPLATE · FILL IN, DOWNLOAD, REUSE

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.

By Stolen OrbitRevision

When to use it and what to produce

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

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

Fill in the fields below and download your document. The website does not send or save answers: closing the page may lose them. Examples are illustrative and should be replaced with your process data.

Download the complete blank template (.md)

1. Describe the change

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

See a worked example

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

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

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

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

2. Check the impact

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

See a worked example

Illustrative example: the new instruction resolves the ambiguous date but omits an explicit deadline elsewhere. Release stays paused until the new failure is understood.

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

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

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

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.

See a worked example

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

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

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

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

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.

Take the next step together.

Use this document to start a discussion about scope, evaluation and project ownership.

Review the text before sending. Only your email is needed alongside the message; other details are optional.