Context Patterns / Patterns

Negative Constraints

"Don't do X" is weaker than it looks. Negative instructions activate attention on the prohibited thing and leave the model without a path forward. Reserve them for hard stops; use positive framing everywhere else.

The Pink Elephant Problem: Why 'Don't Do That' Fails with LLMs , Anthropic: Prompting Best Practices , 0xeb/TheBigPromptLibrary (MIT)

The Problem This Solves

System prompts often accumulate prohibitions around hallucinated URLs, git pushes, competitor discussion, system prompt disclosure, punctuation, apology, and whatever broke last week. By the time a prompt reaches ten “do not” instructions, it has told the model ten things to think about, and those are precisely the things it should avoid.

This is the pink elephant problem applied to context engineering. Telling someone not to think of a pink elephant activates the concept; negative instructions work the same way, loading the prohibited behavior into the attention window and leaving the model working against itself.

None of this means negative constraints are useless. It means they should be reserved for real hard stops, while behavioral guidance should usually be reframed into the action you want.

How It Works

Negative constraints fall into two categories.

Hard stops are absolute prohibitions with serious consequences if violated: never include API keys in generated code, do not execute destructive database operations without explicit confirmation, never reveal another customer’s data. Since these boundaries are binary, negative framing is appropriate; the behavior either happens or it does not, and the boundary needs to be unmistakable.

Behavioral shaping is different. Instructions about style, scope, tone, and approach are poorly served by negative framing. “Don’t be verbose” gives the model less to work with than “respond in three sentences or fewer.” “Don’t hallucinate” is not actionable, while “base every factual claim on the provided documents” gives the model a positive path.

The reframe test is simple: for every “do not” in a system prompt, ask what the model should do instead. If there is a clear positive action, write that. If the constraint is genuinely binary and violation has real consequences, keep the negative.

Place hard stops at the start or end of a system prompt where attention is strongest; a critical constraint buried in paragraph four of a long prompt is close to invisible.

Example

A customer support bot starts with this constraint block:

Don't make up information you don't know.
Don't discuss competitor products.
Don't promise refunds or discounts you can't authorize.
Don't be rude or dismissive.
Don't use technical jargon.
Don't give legal or financial advice.

Each instruction activates the prohibited behavior and leaves open what the model should do instead. The safer version gives a route through each scenario:

Base all factual answers on the provided knowledge base.
If the knowledge base doesn't cover a question, say:
"I don't have information on that. Let me connect you
with the support team."

Focus only on questions about [Company]'s products
and services. If asked about other companies, redirect:
"I'm only able to help with [Company] questions."

For refund or discount requests: acknowledge the request,
then say you're escalating to the billing team. Do not
commit to any specific outcome.

Use plain language. No acronyms unless the customer
used them first.

The remaining negative is a real hard stop: never share order details with anyone who has not verified their account email first. That belongs in negative form because the boundary is binary and the consequence is real.

When to Use

  • Hard stops where violation has security, compliance, safety, or privacy consequences
  • Scope boundaries where the model should refuse or redirect, as long as the prompt includes what to say next
  • Review passes on prompts that have accumulated more than two or three “do not” instructions

When Not to Use

  • Behavioral guidance that can be expressed as a positive instruction
  • Style constraints, which should be phrased as the target style rather than the style to avoid
  • Structural problems better solved with a schema, a tool boundary, a retrieval filter, or a narrower role
  • Role Framing removes many prohibitions by defining who the model is and what belongs in scope
  • Tool Descriptions define when a tool should be used, which is usually stronger than telling the model not to use it elsewhere
  • Grounding solves the hallucination problem better than telling the model not to hallucinate
  • Schema Steering constrains output by making invalid fields unavailable