Use this any time a project has an AI making a decision from a fixed list of options (categories, statuses, labels) that a separate part of the system also depends on.
Steps
- Recognize these as two genuinely separate places, even though they describe the same concept: the AI's instructions (a prompt, hardcoded in application logic) and the system's data model (a database table, a config file).
- Whenever adding, removing, or renaming an option, update both deliberately, in the same sitting, not "when I get to it."
- Write down the update procedure as a short SOP the first time, rather than relying on remembering it correctly every time. A future version of the same task, done from memory months later, is exactly when this kind of drift happens.
- After any category change, test it explicitly: does the AI actually use the new option, and does the downstream system actually track it.
Gotcha
If only one side gets updated, the failure is quiet rather than loud. A new category added only to the database will just always show zero activity, since nothing ever gets assigned to it. A new category added only to the AI's prompt will get assigned to real data that then has nothing to compare against downstream. Neither produces an error message, both just quietly stop working as intended.
Quick reference
Two-place checklist for any AI-plus-database category system:
- Updated in the AI prompt (what it's allowed to choose)
- Updated in the database (what the system tracks against)
- Tested end to end after the change