A prompt is used by twelve services, and an uncontrolled edit broke three of them. What do you put in place?
Why D is the answer
Central prompt management with versions, approval and rollback
Prompts need governance like code. Versioning and approval stop one edit reaching every consumer.
In detail
- Central management gives versions, approval and rollback.
- Pin consumers to a version.
Use case
An illustrative scenario, not a real incident.
One edit to a shared prompt breaks three services. With versions and approval, each service moves to a new version on purpose.
See it in different ways
flowchart LR A["Application"] --> B["Model abstraction layer"] C["Configuration"] --> B B --> D["Model A"] B --> E["Model B"]
sequenceDiagram participant S as Service participant L as Abstraction layer participant C as Configuration participant M as Model S->>L: Request L->>C: Which model? C-->>L: Model ID L->>M: Call M-->>S: Response
stateDiagram-v2 state "Draft" as s0 state "Approved" as s1 state "Live version" as s2 state "Previous version" as s3 [*] --> s0 s0 --> s1: review s1 --> s2: release s2 --> s3: rollback s3 --> [*]
Key point: Govern prompts like code.
Why the other options are wrong
- A. A wiki page listing the current prompt text for each service
- A wiki does not control what runs.
- B. A rule that only senior engineers may edit the shared prompt
- Seniority does not stop mistakes.
- C. A larger test environment that mirrors all twelve services
- A test environment alone gives no version control.

