prompt versioning

In an LLM application the prompt is not a comment in the code, it is the program: a few words rephrased can flip an output from correct to wrong, safe to unsafe, cheap to costly. Prompt versioning treats prompts and their templates as first-class deployable artifacts, each with a stable identity, a version history, and a controlled release process, so that a wording change is a tracked, testable, reversible deployment rather than an untracked edit buried in a source file.

Concretely, prompts are stored in a registry decoupled from application code, each version recording the template text, model and decoding parameters (temperature, max tokens, stop sequences), associated tool or function schemas, and evaluation results. This enables A/B testing one prompt version against another on live traffic, linking every production trace to the exact prompt version that produced it, rolling back to a known-good prompt when a new one regresses, and letting non-engineers iterate on wording without a full code release. The prompt becomes a parameter of the system, governed like a model weight rather than hard-coded.

The reason it matters is the same reason it is overlooked: prompts feel like text, not infrastructure, so teams edit them in place and lose the ability to explain a behavior change. The same discipline that gives models lineage, registries, evaluation gates, and rollback, applies to prompts, and combined with LLMOps observability it closes the loop from a prompt change to its measured effect in production.