How would you manage production prompts as versioned artifacts across a team?

## The failure this prevents The common shape: a prompt starts as a string in application code, gets moved into a database so non-engineers can edit it, and within a year nobody can answer three questions — what text was live at 14:00 last Tuesday, why the fourth paragraph exists, and who is allowed to change it. Meanwhile the prompt directly determines customer-visible behaviour, more so than most of the code around it. Managing prompts as versioned artifacts is the discipline that keeps those three questions answerable. ## The artifact A prompt should be a file, in the repository, on its own, so that a diff shows exactly which sentence changed. Templating variables belong in the file too; assembling the final text from four scattered fragments defeats the review. The version identifier can be a content hash, a semantic version, or a monotonic number — what matters is that it is emitted with the artifact and recorded in the request path. Alongside the text, a prompt benefits from a small header or sidecar recording: the owner, the model version it was tuned for, the eval set and score at its last change, and a changelog line per revision explaining *why* — not "improved wording" but "added escrow tie-break after INC-412". The why is what future engineers cannot reconstruct from the diff. ## Change control Every prompt change should be reviewable and gated exactly like code: - **Review by someone other than the author**, because prompts fail in ways that read fine to the person who wrote them. - **An eval run attached to the change**, showing the delta against the current baseline and which items flipped. A prompt change proposed without an eval number is a change proposed without evidence. - **A blocking gate** on the primary metric and on any case derived from a past incident. - **A recorded baseline update** when the change is accepted, so the next comparison starts from a documented point. ## Observability and rollback Every model response logged in production should carry the prompt version and the model version that produced it. Without that pairing, incident review is guesswork: quality complaints arrive days later, by which time the prompt may have changed twice. With it, you filter the affected window by version and immediately know whether the complaint predates or postdates a specific change. Rollback should be a deliberate, fast path — revert to a previous version identifier, redeploy or flip a config value, and record it. Two caveats are worth raising unprompted. First, if downstream code parses a structured output whose shape changed between versions, rolling the prompt back without rolling the parser back reintroduces a different break; version them together or keep the contract stable across prompt versions. Second, if responses are cached, rolling back the prompt does not roll back the cache, so cache keys must include the prompt version. ## Scar tissue and the right to delete Mature prompts accumulate defensive lines added after specific incidents. Each was justified once; collectively they bloat the prompt, and nobody removes them because removal is unbounded risk. This is the strongest practical argument for pairing evaluation with versioning: **every defensive line should arrive with an eval case that fails when the line is removed.** With that pairing, a later engineer can delete the line, run the suite, and either learn immediately that it still matters or remove it with confidence. Without it, the prompt only grows, and the accumulated instructions eventually start interfering with each other. ## Who may edit, and where The hard organizational question is that the people with the best judgment about prompt wording — support leads, clinicians, legal reviewers — are often not the people with repository access. There are two defensible answers and the tradeoff is genuinely contested as of mid-2026. - **Repo-only editing** keeps a single source of truth, real review, and atomic rollback, at the cost of a slow loop for domain experts who must route every wording change through an engineer. - **A prompt registry or management platform** lets domain experts edit and publish directly, with versions, staged rollout and audit built in. The risk is a second source of truth that drifts from the repo, and edits reaching production without the eval gate. The workable middle is a registry that is fed from version control, or one that enforces the same gates — review, eval run, staged rollout, instant rollback — regardless of who clicks publish. What is not defensible is a production prompt that any authenticated user can edit in a text box with no version history and no eval, which is where a surprising number of systems actually are. ## What an interviewer is listening for Not a tool recommendation. They want to hear that you treat prompts as behaviour-defining artifacts with owners, history, evidence attached to changes, traceability from a production response back to the exact text, and a rollback path — and that you can articulate the editing-access tradeoff without pretending it has a clean answer.