Here's how a good organization handles change. Someone suggests it. It gets reviewed. People agree. It's made, written down and communicated. Then someone checks it worked.
Here's how bots often handle change: a line in a chat that quietly becomes the new rule, or quietly doesn't.
Change control in ISO
ISO covers planning of changes. It asks you to communicate the change, monitor whether it worked and review the results. A related ISO process covers controlling changes in day-to-day operations.
The point isn't to slow change down. It's to make sure changes are deliberate, known and checked.
The bot version
| Step | What it looks like for a bot |
|---|---|
| Propose | The bot or a person suggests: "Should this be the new default?" |
| Review | The owner looks at the exact change |
| Approve | The owner says yes |
| Make it | The skill or principles file is updated |
| Version it | New revision number and date, short note of what changed |
| Communicate | Other bots that use the file are told, or pick it up from the master |
| Check | Retest to confirm it works |
Bots don't change their own rules
This is the big one. A bot can suggest a change to its instructions. It shouldn't make that change on its own.
It's the same as with a new employee. If they see a better way, they come to you. You look at it together. Then the procedure changes. They don't just start doing it differently and hope you notice.
Version everything that matters
Put a revision number and date on each important instruction file. Keep a short log of changes:
Revision 8, October 20, 2026. Added: never test the owner's working bots.
Now anyone can tell which version a bot was running when something happened. See The current version at the point of use.
A real example
Our AN Creation skills carry revision numbers. The shared principles file says "Revision 1, October 18, 2026." The tester is on revision 8 as of October 20, 2026. Updates to the skill set happen only when the owner asks for them, and there's a changes log alongside the version file.
Check the change worked
A change isn't done when it's made. It's done when it's been shown to work. After updating a skill, run the bot through the task again, or run its test script. See Your tester bot is your internal auditor.
Changes ripple
In a team of bots, one shared file can affect several bots. Change the principles file and every bot that reads it changes behavior. That's powerful. It's also why shared files deserve the most care.
What this means for you
- Bots propose. You approve.
- Version important instruction files.
- Keep a short change log.
- Retest after each change.
- Take extra care with shared files.
Change is good. Quiet, unreviewed change is how systems drift.