Principle:Langfuse Langfuse Prompt Authoring and Versioning
| Knowledge Sources | |
|---|---|
| Domains | Prompt Management, Version Control |
| Last Updated | 2026-02-14 00:00 GMT |
Overview
Prompt Authoring and Versioning is the discipline of creating, storing, and evolving prompt templates through an immutable, auto-incrementing version chain so that every change to a prompt is traceable, recoverable, and deployable independently.
Description
In LLM-powered applications, prompts are a first-class artifact comparable to source code. Prompt Authoring and Versioning addresses the need to manage these artifacts with the same rigor applied to traditional software: every modification produces a new, immutable version rather than overwriting the previous one.
The core problems solved by this principle are:
- Auditability: Teams must know who changed a prompt, when, and why. Each version carries metadata including the author (createdBy), an optional commit message, and a creation timestamp.
- Safe rollback: If a new prompt version degrades quality, operators can instantly revert by redirecting a label (such as "production") to a prior version without deleting anything.
- Parallel experimentation: Multiple versions can coexist simultaneously. A label system allows different environments (development, staging, production) to reference different versions of the same prompt name.
- Type safety: Prompts are classified into types (Text or Chat), and the system enforces that all versions of a given prompt name share the same type. This prevents accidental mixing of single-string prompts with structured chat message arrays.
A prompt is uniquely identified by the triple (projectId, name, version). The version number is a positive integer that auto-increments from the highest existing version of that name. Labels provide symbolic references on top of numeric versions, enabling human-friendly retrieval (e.g., "give me the production version of my summarization prompt").
Usage
Use Prompt Authoring and Versioning whenever:
- A team collaboratively maintains prompt templates that evolve over time.
- Prompt changes need to be tracked and auditable for compliance or debugging purposes.
- Multiple environments (development, staging, production) need to reference different prompt versions simultaneously.
- Rollback capability is required without data loss.
- Tags and labels need to be consistent or unique across all versions of a prompt name.
Theoretical Basis
The versioning model follows an append-only, auto-increment pattern:
FUNCTION createNewVersion(projectId, name, content, type, labels, author):
latestPrompt = findLatestVersion(projectId, name)
IF latestPrompt EXISTS AND latestPrompt.type != type:
RAISE error("Type mismatch with previous versions")
newVersion = IF latestPrompt EXISTS THEN latestPrompt.version + 1 ELSE 1
// The "latest" label is always applied to newly created versions
finalLabels = UNION(labels, {"latest"})
// Labels are unique: remove finalLabels from all previous versions
FOR EACH label IN finalLabels:
removeLabelFromAllVersions(projectId, name, label)
// Tags are consistent across all versions of the same prompt name
finalTags = UNION(providedTags OR latestPrompt.tags OR {})
IF tagsChanged(finalTags, latestPrompt.tags):
updateTagsOnAllVersions(projectId, name, finalTags)
// Validate dependency graph before persisting
parsedDependencies = parseDependencyTags(content)
resolveAndValidateGraph(projectId, newPromptId, content, parsedDependencies)
// Persist atomically
TRANSACTION:
INSERT prompt(projectId, name, newVersion, content, type, finalLabels, finalTags, author)
FOR EACH dependency IN parsedDependencies:
INSERT promptDependency(projectId, newPromptId, dependency)
// Cache management: lock -> invalidate -> unlock
lockCache(projectId, name)
invalidateAllCachedVersions(projectId, name)
unlockCache(projectId, name)
// Event sourcing for downstream consumers
emitEvent(newPrompt, "created")
FOR EACH touchedPrompt IN updatedPreviousVersions:
emitEvent(touchedPrompt, "updated")
RETURN newPrompt
Key invariants:
- Version monotonicity: Version numbers never decrease and never repeat for a given (projectId, name) pair.
- Label uniqueness: A label can only exist on one version of a prompt at any given time. Moving a label to a new version atomically removes it from the old version.
- Tag consistency: Tags are synchronized across all versions of a prompt name. Changing tags on a new version propagates to all existing versions.
- Type immutability: Once a prompt name is created with a type (Text or Chat), all subsequent versions must use the same type.
- Variable-placeholder disjointness (Chat type): For chat prompts, variable names (using {{varName}} syntax) and placeholder names must be distinct to avoid ambiguity during compilation.