A team improves an AI instruction in a shared document, and a familiar output suddenly changes. Nobody remembers which sentence was edited or why. The instruction has become part of a workflow, but it is still being managed like a disposable chat message.
Give shared instructions a version and a short change record. Save the previous version before replacing it, and identify which workflow or tool uses the current one. A file called final-new-revised does not reliably answer either question.
Record the reason, not only the wording
A useful change note might say: “Version 3 asks the assistant to mark missing source dates instead of guessing them.” It explains the intended behaviour and gives a reviewer something concrete to check.
Include the date, owner and relevant model or tool configuration where it affects the workflow. Do not put confidential input examples into a broadly shared change log. Use approved, anonymised or synthetic test material as appropriate.
Compare on familiar examples
Keep a small set of representative cases, including an awkward case that exposed the previous problem. Run the revised instruction and compare the outputs against explicit criteria. A nicer result on one easy example does not establish improvement across the whole task.
Check whether the change solved the intended issue while introducing another, such as missing a required field or becoming overconfident. Record uncertainty and keep a route back to the previous version if the workflow allows it.
Tell the people who depend on the instruction when its behaviour changes. If several copies exist, identify which ones need updating rather than assuming a central document updates every tool automatically.
Version history does not make AI output reliable by itself. It makes changes inspectable. When something goes wrong, the team can discuss a specific instruction and result instead of trying to reconstruct a series of undocumented edits.