You gave the model five rules: stay under 200 words, use second person, include a CTA, no exclamation marks, and do not mention competitor names. It came back at 180 words, in second person, with a CTA and no exclamation marks, and then casually dropped two competitor names in the third paragraph. The constraint you cared about most was the one that disappeared.
Fastest fix: pull the one rule that would block shipping out of the rule list, put it in its own labeled section at the top of the prompt, restate it once at the bottom, and add a one-line self-check that makes the model quote the proof it obeyed. That alone fixes most cases.
Why it happens: when a prompt has many rules, the model weights them roughly equally and tends to drop whichever one conflicts with another or sits mid-prompt where attention is thinner. This is the documented “lost in the middle” effect (Liu et al. 2023, still measurable on long-context evals as of June 2026): models attend most to the start and end of a prompt, and accuracy for a fact or rule buried in the middle can drop by 30% or more. No production model has fully removed this position bias because it is structural to how transformers attend. So the fix is not to repeat the rule louder; it is to move it where attention is high, phrase it as a hard binary, and verify it in the output.
Common causes
Ordered by frequency.
1. Critical constraint buried in the middle of the prompt
You wrote a 400-word brief and the critical rule is in paragraph 3. Models pay disproportionate attention to the start and end of long prompts. The middle is where rules quietly die.
How to spot it: open your prompt and locate the dropped constraint. If it is more than 50% of the way down and not in a labeled section, that is the cause.
2. The constraint conflicts with another rule
Rule A: "sound enthusiastic and energetic". Rule B: "no exclamation marks, no superlatives". The model picks one and quietly violates the other. Usually it picks the one that is easier to satisfy locally.
How to spot it: list your rules. Are any of them in tension? The dropped one is usually the harder-to-satisfy half of a pair.
3. Soft phrasing makes the rule optional
"try to avoid mentioning competitors" reads as a preference. "do not mention any of the following names: X, Y, Z" reads as a rule. Soft language gets soft compliance.
How to spot it: re-read the constraint. Words like try, prefer, ideally, if possible all signal “negotiable” to the model.
4. Long context pushes the constraint out of attention
In a 6k-token system prompt, a rule on line 8 is competing with 200 lines of subsequent content. By the time the model is generating, the rule may have rolled out of high-attention positions.
How to spot it: prompt is long and the dropped rule is not in the first 500 or last 500 characters.
5. The rule lives in a different turn than the request
If you said "always use second person" 4 turns ago and now you say "write a follow-up", the rule may not be re-activated. Long chats lose constraint anchoring.
How to spot it: scroll up. The constraint was established in a different turn and was not repeated when you made the current request.
6. The rule is negative but the example shows the negative behavior
"do not include legal disclaimers" followed by "here is an example: <example with a legal disclaimer at the bottom>". The model often imitates the example shape and ignores the negation.
How to spot it: check whether any example or reference document in the prompt violates the rule you stated.
Before you change anything
- Confirm which constraint was dropped and that it was actually in the prompt.
- Write down the exact prompt, the model, and any prior turns where rules were established.
- Save the bad output verbatim — quote the lines that violate the constraint.
- Note which other constraints WERE satisfied, to identify any conflict.
- Check whether the same prompt drops the same constraint across multiple runs (deterministic vs sampling).
Information to collect
- Full prompt text and any system prompt.
- The list of rules in order, with their exact wording.
- The output that violated the rule, with violations highlighted.
- The model, temperature, and tool-use settings.
- Any examples or reference documents that may have undermined the rule.
Shortest fix path
Ordered by ROI.
Step 1: Identify the one non-negotiable constraint
Out of your N rules, pick the one rule whose violation would block shipping the output. Everything else is secondary. If you cannot pick one, your prompt has unclear priorities and that itself is a cause.
Step 2: Hoist it to a dedicated top section, and restate it at the bottom
Move the rule to where attention is highest. Put it in its own labeled section at the top, then restate it in one line at the very end of the prompt so it sits in both high-attention positions:
# Non-negotiable constraint
Do not mention any of these competitor names: Acme Corp, BetaCo, Gamma Inc.
If you would otherwise name one, write [REDACTED] instead.
# Task
<the actual task>
# Style rules
- Under 200 words
- Second person
- Include a CTA
- No exclamation marks
# Reminder
The competitor-name rule above is the one hard requirement. Re-check it before you answer.The hard rule now lives at the top and the bottom, the two positions the model attends to most.
One 2026 nuance: structure beats volume. Putting the rule in its own section is what helps; shouting it does not. Newer Claude models (Sonnet 4.6, Opus 4.7) can actually over-react to CRITICAL!, YOU MUST, and NEVER EVER and produce worse output, so keep the wording calm and direct rather than all-caps and exclamatory. A plain # Non-negotiable constraint header outperforms a wall of capitals.
If you are prompting Claude, wrap the sections in XML tags instead of Markdown headers (<constraints>, <task>, <style>). Anthropic’s own guide treats XML tags as the primary way to keep instructions, context, and constraints from bleeding into each other, and Claude follows tagged sections more reliably than prose.
Step 3: Use binary language, not soft language
| Soft (drops easily) | Hard (sticks) |
|---|---|
"try to avoid X" | "do not include X under any circumstances" |
"ideally under 200 words" | "output must be 180-200 words; reject if outside" |
"prefer second person" | "use only 'you' and 'your'; do not use 'we', 'I', or 'they'" |
"keep it professional" | "do not use slang, emojis, contractions, or exclamation marks" |
Step 4: Add an output self-check
End the prompt with:
Before you finish, verify:
1. Did you mention Acme, BetaCo, or Gamma? (Y/N)
2. Quote the line that proves you obeyed rule 1.
If any check fails, rewrite the output and re-check.The self-check forces the model to reread its own output against the rule.
Step 5: For agentic systems, add a programmatic guardrail
For automation, do not rely on the prompt alone. Add a post-generation regex/keyword check:
banned = ["Acme Corp", "BetaCo", "Gamma Inc"]
if any(b.lower() in output.lower() for b in banned):
raise ConstraintViolation("competitor mentioned")If the model violates, retry with the violation included in the prompt: "your previous output mentioned BetaCo on line 4. Rewrite without any competitor name."
When the constraint is about shape (a field must exist, an enum value, a max length, valid JSON), the strongest guardrail is not a prompt at all. Use the vendor’s structured-output mode, which constrains generation at the token level so the model literally cannot emit output that breaks the schema:
- OpenAI: Structured Outputs with
strict: trueand ajson_schemaresponse format. As of June 2026, plain JSON mode is treated as legacy because it only guarantees valid JSON syntax, not schema adherence; strictjson_schemais the production default. - Anthropic / Google: enforce shape with tool-use / function calling and an
input_schema, then read the validated tool arguments instead of free text.
Also remember the instruction hierarchy: a rule in the system (or developer) prompt outranks the same rule in a user message. If a constraint must never be overridden, put it in the system prompt, where the model is trained to give it higher privilege than later user turns.
Step 6: Resolve conflicts before generation
If your “enthusiastic” rule conflicts with your “no exclamation marks” rule, decide which wins and remove the other, or specify how to reconcile: "sound enthusiastic through verb choice and concrete numbers, not punctuation or superlatives."
How to confirm the fix
- The non-negotiable constraint is satisfied in 5/5 consecutive runs.
- The model’s self-check at the end correctly identifies whether the rule was followed.
- A teammate reading the output without seeing the prompt cannot find a violation.
- The programmatic check (if you added one) passes.
If still broken
- Reduce the prompt to the bare minimum: hoisted constraint + task + 1 example. Build back up.
- Try a stronger model. Constraint following is capability-bound, and frontier models honor long rule lists far better than small/fast ones. As of June 2026, Claude Opus 4.7 and GPT-5.5 (Thinking) hold many-rule prompts noticeably better than their cheaper siblings (Sonnet 4.6, GPT-5.5 Instant); for Gemini, use Gemini 3.1 Pro.
- Move the constraint into a system prompt, or a ChatGPT Custom GPT / Project instruction, or a Claude Project, instead of a one-off user message, so it carries higher privilege and persists across turns.
- For very long prompts, split the work: have one call generate and a second call check the constraint and rewrite if it fails.
- Lower temperature to 0.3-0.5; high temperature increases constraint drops. (Some
Thinking/reasoning modes ignore the temperature knob; in that case, rely on the structural fixes above instead.)
Prevention
- Default discipline: every prompt has at most one
# NON-NEGOTIABLEsection with one rule. - For recurring workflows, encode constraints in the system prompt, not the user message.
- Treat dropped constraints as a prompt bug to fix, not a model failure to forgive.
- After any prompt rewrite, re-test with 3 runs to confirm the constraint sticks.
- Maintain a checklist of common non-negotiables (no PII, no competitor names, no fabricated stats) you paste into briefs.
FAQ
Why does the model drop the one rule I care about most and keep the trivial ones? It does not rank your rules by importance; it weights them by position and ease. A rule that sits mid-prompt, or that is harder to satisfy than a competing rule, is the one that slips. Move the critical rule to the top and bottom, and make it the easiest to obey (a hard binary), not just the most emphasized.
Should I just write the rule in ALL CAPS or add “CRITICAL!!!”?
No. As of 2026 the consensus is that structure beats volume, and shouting can backfire: newer Claude models over-react to CRITICAL!, YOU MUST, and NEVER EVER and can produce worse output. A calm, clearly labeled section in a high-attention position works better than capitals.
Is this a model bug or my prompt? Almost always the prompt. Constraint dropping is predictable from position bias and rule conflicts, and it reproduces. Treat a dropped constraint as a prompt bug you can fix structurally rather than a model failure to wait out.
My constraint is a format rule (must be JSON, must have field X). What is the most reliable fix?
Do not fight it in prose. Use the vendor’s structured-output mode: OpenAI Structured Outputs with strict: true and a json_schema, or tool-use with an input_schema on Claude and Gemini. These constrain generation so the model cannot emit output that breaks the schema.
It worked in a short chat but breaks in a long one. Why? Long chats lose constraint anchoring. A rule set 4 turns ago may not be re-activated for the current request. Restate the rule in the turn where you make the request, or move it into the system prompt / a Project so it persists.
How do I know it is actually fixed and not just lucky? Run the same prompt 5 times. The non-negotiable constraint must hold in all 5. Single passes are noise because sampling means one clean output can still be a near-miss.
Related reading
- Conflicting instructions weaken output
- Latest sentence overrides earlier rule
- Long prompt degrades output
- Negative constraints stated too vaguely
- Mixed-tone instructions
Tags: #Troubleshooting #Prompt #Prompt quality #Prompt engineering