What is Prompt Versioning?
Prompt Versioning is the practice of tracking prompt source history and binding each released LLM behavior to an immutable manifest of its runtime dependencies.
How It Works
Prompt Versioning has two related responsibilities. Source versioning uses Git or another reviewable history to record who changed prompt text, templates, examples, policies, and configuration. Runtime versioning identifies the exact behavior bundle that was evaluated and deployed, including the model revision, decoding parameters, tool schemas and authorization rules, retrieval corpus and index, output schema and parser, evaluation dataset, evaluator, and routing policy.
Prompt registries commonly expose movable environment tags such as staging or production. Those pointers are useful for promotion, but the application must resolve the tag to an immutable commit and record that resolution before execution. Otherwise two runs carrying the same friendly label can use different bytes. Store the exact rendered-prompt digest as well as the source template digest because variable values, imports, localization, and host-side transformations can change the final model input.
Treat the release record as provenance, not merely metadata. It should identify where, when, and how the deployable behavior bundle was produced, which reviewed sources and builder created it, and which attestations or approvals were checked. Secrets and personal data never belong in the manifest; use opaque references and separately authorized retrieval. Reproducible rollback requires the complete manifest digest, verified artifact bytes, and continued availability of every pinned dependency.
Key Characteristics
- Preserves reviewable source diffs, authorship, approval, and change rationale
- Separates source, resolved registry commit, rendered prompt, and deployed runtime identities
- Pins behavior-affecting dependencies with immutable revisions or content digests
- Links each release candidate to datasets, evaluator versions, and evidence
- Resolves mutable environment aliases to immutable revisions before execution and records the resolution
- Supports incident attribution and complete dependency rollback
Common Use Cases
- Tracing which prompt, model, index, and tool policy produced a response
- Reviewing a prompt-template change in a pull request before evaluation
- Reproducing an offline regression result from an immutable manifest
- Separating a prompt edit from a simultaneous model or retrieval migration
- Restoring a known-good release bundle during an incident
Example
Loading code...Frequently Asked Questions
Is Git enough for Prompt Versioning?
Git is a strong source-history foundation, but it does not identify deployed model, tool, retrieval, schema, dataset, evaluator, or routing revisions unless those dependencies are bound in an immutable runtime manifest.
What should a prompt release manifest include?
Include prompt and template digests, model revision and parameters, tool schemas and policy, retrieval snapshot, output contract, dataset and evaluator revisions, source commit, and routing configuration.
Why is a latest pointer not a prompt version?
A latest, staging, or production pointer is mutable and can identify different artifacts over time. Resolve it to an immutable commit before execution, record both values, and use the resolved revision plus content digest in evaluation, deployment, audit, and rollback records.
Should evaluation datasets be versioned with prompts?
Yes. Without dataset and evaluator revisions, a score change may reflect a changed test rather than improved application behavior, and the release evidence cannot be reproduced.
How does Prompt Versioning differ from Prompt CI/CD?
Versioning records source history and immutable release identity. Prompt CI/CD uses those identities to run checks, compare evidence, approve delivery, monitor production, and execute rollback.