Sometimes you need to tell a model what not to do. How you phrase it matters.
Prefer Positive Framing
"Use plain language a 12-year-old could follow" works better than "Don't use jargon". Positive instructions describe the target; negative ones only fence off one area.
When Negatives Are Needed
Some constraints are naturally negative: don't mention competitors, don't give medical diagnoses, don't include personal data. State them clearly and explain why.
Be Specific
"Don't make promises about delivery dates" is clearer than "be careful about commitments".
Explain the Reason
"Don't quote prices, because they vary by region and the assistant can't see the customer's region" lets the model handle related cases sensibly.
Provide the Alternative
Tell the model what to do instead: "If asked about pricing, explain that it depends on location and link to the pricing page."
Hard Constraints Need Code
For rules that must never be broken — legal disclaimers, prohibited content, data that must not leak — don't rely on prompts alone. Add programmatic checks on outputs.
Test the Edges
Try inputs designed to tempt the model into the prohibited behaviour, and confirm it responds correctly.