A water utility wants approved prompt templates stored centrally with separate stages for draft, staging, and production. Which pattern best matches that governance need?
Select an answer to reveal the explanation.
Short Explanation
Utilities promote valve-procedure updates from draft to field-approved—prompts need the same pipeline. Park templates in a controlled S3-style repo and promote draft → staging → production. Emailing Word docs or baking prompts into AMIs is how versions get lost.
Full Explanation
Water-utility prompt governance that needs approved templates with distinct draft, staging, and production stages matches a controlled repository pattern: store templates in a governed object-store (or equivalent) with explicit promotion stages from draft to staging to production. That gives review gates, rollback, and environment isolation so experimental wording never silently becomes the resident- or operator-facing system prompt. Emailing Word documents until someone pastes into Lambda is not staged promotion and lacks reliable version identity. Hard-coding production prompts only inside AMI images that cannot be versioned couples prompt change to image rebuilds and fights rapid, auditable edits. Generating a fresh random system prompt at runtime so stages are unnecessary abandons governance entirely. Exam caveat: “draft / staging / production” language maps to staged artifact promotion in a controlled store—not email chains, AMI baking, or random prompts. Operational check: require promotion tickets between stages, block runtime fetch from draft in production accounts, tag objects with stage and version, and periodically verify the production alias points at the approved object version.