A municipal platform must draft resident notices in stages: summarize the incident, check tone policy, then produce the final message. Which application pattern supports that flow?
Select an answer to reveal the explanation.
Short Explanation
Resident notices are a three-act play: summarize, check the tone rules, then write the letter. Prompt chaining keeps those acts in order under city templates instead of one wild improvisation.
Full Explanation
Municipal resident notices often must be drafted in stages: summarize the incident, check tone policy, then produce the final message. Standardizing prompt-chaining patterns supports that flow—each communication stage feeds the next under shared municipal templates so policy checks are not skipped and outputs remain consistent across departments. Chaining is an application pattern for governed multi-step generation rather than one-shot improvisation.
Generating final resident notices with a single ungoverned free-form chat and no intermediate checks fails by concept: tone and policy gates never run. Skipping tone and policy stages and publishing raw model dumps straight to the public website fails communications governance and reputational risk controls. Replacing multi-stage drafting with a one-time classical clustering job that never writes prose fails the generative notice requirement.
Exam caveat: prompt chaining improves process control but can multiply latency and token cost; cache stable summaries where appropriate and fail closed if a policy stage rejects the draft. Templates and stage contracts should be versioned so legal/comms teams can approve changes. Chaining is not automatic publishing—final release may still need a human approver.
Operational check: run an incident through summarize → tone/policy check → final message stages, inject a tone-policy failure and confirm the chain stops or revises before publish, and verify stage inputs/outputs are logged for audit under the shared municipal templates.