The draft/published workflow is a content lifecycle pattern where each prompt has two distinct states: draft, which is freely editable and used for development, and published, which is immutable and served to production applications. This two-state model provides the minimum viable governance for prompt deployment, ensuring that production prompts are intentional snapshots rather than accidentally saved works-in-progress.
In the draft state, a prompt can be modified freely. Authors can edit blocks, adjust instructions, add or remove examples, change variable definitions, and experiment with different approaches. Each save creates a new version in the prompt's history, allowing authors to compare changes and revert if needed. Draft prompts are available to development environments but never served to production.
Publishing is a deliberate action that freezes the current state of the prompt into a published version. Once published, that version is immutable — it cannot be edited, only superseded by a new published version. This immutability is important because it guarantees that the prompt serving production traffic is exactly what was reviewed and approved, with no possibility of accidental modification.
The workflow creates a natural checkpoint in the prompt lifecycle. Before publishing, teams can run evaluations against the draft, review changes in a diff view against the currently published version, and validate behavior in a staging environment. The publish action itself can be gated behind permissions, requiring specific roles or approval from designated reviewers.
After publishing, development continues in the draft space. The prompt's draft state is either reset to match the newly published version (providing a clean starting point for the next iteration) or retained as-is (allowing work-in-progress to survive the publication of an intermediate version). Both approaches have merits, and the choice depends on the team's workflow preferences.
This workflow model is intentionally simple, making it accessible to teams that are new to prompt management. More sophisticated workflows — staging environments, canary deployments, approval chains — can be layered on top as teams mature. The draft/published foundation ensures that even the simplest workflow maintains a clear boundary between development and production.