Prompt versioning treats prompts as code rather than as configuration strings.
Every prompt lives in version control with a history.
Changes go through review and are evaluated before shipping.
You can roll back a prompt exactly as you would roll back code.
Prompts hardcoded across a codebase are impossible to improve safely.
Prompt versioning treats prompts as code rather than as strings scattered through a codebase.
A prompt change is a behaviour change, and it deserves the same handling as a code change.
Every prompt lives in version control with a history and an author.
Changes go through review, since a small wording edit can shift behaviour widely.
They are evaluated against a fixed set before shipping.
Rollback is then a matter of reverting a commit, exactly as with code.
Log the prompt version with every request, or you cannot connect a complaint to a change.
Prompts hardcoded across many files cannot be improved safely.
Nobody can tell which copy is current or what changing one will break.
Centralise them in one place, whether files or a prompt management service.
Templates with named variables keep the changing part separate from the instruction.
Record the model version alongside, since a prompt tuned for one model may fail on another.
Keep the evaluation results with the version, so you know what it scored.
Do not edit prompts in production configuration without review, however tempting it is.
The discipline matters more than the tool you use to enforce it.
One question on this card. Every option explains itself once you pick, right or wrong.
22 concepts in this module, then a graded test with every answer explained.