Prompt changes are production changes. They affect behaviour, safety, tone, latency and cost. If prompts live in ad hoc files, dashboards, or copied snippets, drift is inevitable and rollbacks are painful.
A prompt registry treats prompts as versioned artefacts with the same discipline you apply to code and configuration. It is a simple control that prevents a large class of reliability and governance failures (see configuration drift).
What belongs in a prompt registry
Most teams start by versioning a system prompt, then discover there are more moving parts. A useful registry can store:
- System templates. The main instructions and constraints.
- Tool schemas. Function descriptions and argument contracts.
- Policy modules. Refusal rules and disclosure requirements.
- Routing configs. Which model or route is used for which intents.
- Release metadata. Owner, rationale, risk level, and change ticket link.
Versioning and diffing prompts like code
Versioning is valuable only if you can understand changes. Use:
- Immutable versions. Every change produces a new version ID.
- Readable diffs. Highlight additions/removals and parameter changes.
- Structured fields. Separate policy, tone, tool rules and examples so diffs are meaningful.
For complex systems, treat "prompt" as a bundle: prompt text + policy + tools + routing.
Approvals and change gates
Not all prompt changes need the same process. Add simple gates based on risk:
- Low risk. Tone and formatting changes with peer review.
- Medium risk. Behaviour changes that require evaluation results.
- High risk. Tool changes, policy changes or security-sensitive changes requiring explicit approval.
This aligns with standard change management and reduces "shadow prompt" edits (see AI change management and change freezes).
Evaluation gates before rollout
Prompt updates should pass a small evaluation suite:
- Golden prompts. Regression prompts that represent key intents.
- Rubrics. Scoring for correctness, policy compliance and tone (see evaluation rubrics).
- Safety tests. Prompt injection and policy edge cases.
Evaluations can be lightweight and still catch the most common failures (see AI testing pyramid).
Safe rollout and rollback
Even with evaluation gates, production is different. Use rollout controls:
- Feature flags. Ship a prompt version to a controlled segment (see feature flags).
- Canary rollouts. Small exposure first (see canary rollouts).
- Fast rollback. One-click revert to a previous version with clear audit trails.
Operational telemetry
Prompt registries become powerful when you can connect versions to outcomes:
- Track the active prompt version per request.
- Measure success, refusal and escalation rates by version.
- Correlate incidents and alerts to recent prompt changes.
This turns prompt work into reliable operations instead of endless debate.
Prompt registries do not remove experimentation. They make experimentation safe. That is the difference between "prompt engineering" and production engineering.