A team edits the system prompt of a customer-facing Claude assistant by pasting new text into a hosted configuration console, which applies the change immediately. After a quality regression, the team could not establish which wording had been live the previous week or who had changed it, and the rollback took most of a day. The team must be able to attribute and reverse any future prompt change with the same speed as a code rollback. What should it change?
- AKeep editing in the console but require that each change be announced in the team channel beforehand, with the previous wording pasted in so it can be restored later.
- BKeep editing in the console and have a scheduled job snapshot the live prompt into object storage each night, so a previous day's wording can always be retrieved.
- CMove the prompt into a database row the application reads at startup, and record the edit timestamp on the row so the team can see when the wording last moved.
- DStore the prompt as a file in the application repository so that every change arrives as a reviewed, attributed commit, and let the deployment pipeline read the prompt from the released build. Correct
Why A is wrong: It creates a record, which is why it feels sufficient, but the record lives outside the release and depends on someone remembering, so the live text and the note can drift apart without anything detecting it.
Why B is wrong: Nightly snapshots do give a recoverable copy and are better than nothing, but a change made and reverted within a day leaves no trace, and the snapshot names no author and carries no review.
Why C is wrong: Reading from a row does centralise the value and the timestamp answers when, but a single mutable row keeps no prior versions, so the team still cannot see what the wording was or who replaced it.
Why D is correct: Correct, because it makes the prompt an ordinary versioned artefact, so history, authorship, review and rollback are the mechanisms the team already has for code rather than a second process built for prompts.