An emergency-management office's public-alert drafter has accumulated a prompt with eleven prohibitions: do not speculate, do not use jargon, do not exceed two paragraphs, do not mention road names, and so on. Output quality has gotten worse, not better, and the model sometimes produces text that is technically compliant but useless. What should the office do?

A prompt built from prohibitions defines only the boundary of what is unacceptable and leaves the target itself unspecified. That is how an emergency-management office ends up with drafts that break no rule and help no reader: the model satisfied every constraint it was given, and not one of them described what a good public alert actually looks like.

A positive specification naming the alert's structure, its audience reading level, the elements it must contain, and its length gives the model something to aim at, and most of the prohibitions dissolve into it. A stated two-paragraph structure at a defined reading level makes "do not exceed two paragraphs" and "do not use jargon" redundant, and the shorter prompt is far easier for staff to review before an emergency.

Adding a twelfth rule that tells the model to check the other eleven lengthens the prompt and compounds the very problem it claims to solve; relocating the same prohibitions into the system parameter changes where they sit without changing the negative framing that is the actual defect; and lowering temperature to 0 makes output more consistent, so the office receives the same unhelpful alert more reliably.

Exam caveat: a few prohibitions still earn their place when a constraint is legal or safety-critical, since "never state an evacuation order that has not been issued" has no positive equivalent. Operational check: rewrite positively, keep only the constraints with legal force, and score a batch of drafts against the required-elements checklist rather than the old rule list.