It Ignores the Rule Buried in the Prompt: Where to Put Instructions

July 24, 2026 · Claude Certified Architect (CCA) Prep (part 41)

▶ Watch on YouTube & subscribe to The Stack Underflow

Your system prompt is 40 lines long. Somewhere around line 22, sandwiched between a tone guideline and a formatting note, sits the one rule that actually matters for this deployment: never quote a price without the disclaimer, always cite the source document, never suggest an off-label use. And the model skips it. Not always — just often enough that QA keeps filing the same bug, and every fix you try (louder wording, more repetition, a bigger model) buys you a few percentage points and then plateaus. This is a structure problem wearing a compliance costume, and it is exactly the kind of scenario Domain 4 of the Claude Certified Architect exam expects you to diagnose correctly.

The one-sentence version: A buried instruction isn’t ignored because the model is careless — it’s ignored because your prompt didn’t tell the model it was a rule; structure it as one (role, then rules, up front and labeled), and adherence stops being a gamble.

The question

The model keeps ignoring a rule buried deep in a long system prompt. Best fix?

• A) Say it louder in caps everywhere
• B) State explicit criteria, structured and prominent (role → rules → task)
• C) A bigger model
• D) Repeat the whole prompt twice

Pause here and pick an answer before you scroll — this is a Domain 4 question type (Prompt Engineering & Structured Output, 20% of the CCA exam) that rewards understanding the mechanism, not guessing the label.

The answer

B — state explicit criteria, structured and prominent, with a clear role → rules → task organization.

The mechanism is straightforward once you separate two things people conflate: saying an instruction and structuring it as an instruction. A rule dropped into paragraph three of a wall of prose is, to the model, indistinguishable from background color — tone guidance, style preference, context. A rule pulled out into its own labeled section, placed early, and phrased as an explicit criterion reads as a constraint the model is meant to check its output against.

BEFORE — buried rule, low adherence
┌───────────────────────────────────────────────────────┐
│ You are a helpful assistant for Acme Corp. Be friendly │
│ and concise. Always mention our new product line when  │
│ relevant. Never quote a price without including the    │
│ mandatory disclaimer text. Try to keep responses under │
│ 200 words. Use a warm, conversational tone. Avoid      │
│ jargon. If asked about competitors, redirect politely.  │
└───────────────────────────────────────────────────────┘
        ↑ the load-bearing rule is one clause among ten,
          no different in weight from "be friendly"

AFTER — structured, prominent, high adherence
┌───────────────────────────────────────────────────────┐
│ ROLE                                                    │
│   Helpful assistant for Acme Corp.                      │
│                                                          │
│ RULES (must follow, in priority order)                  │
│   1. Never quote a price without the disclaimer text.   │
│   2. If asked about competitors, redirect politely.      │
│                                                          │
│ TASK                                                     │
│   Answer the user's question. Warm, concise, <200 words.│
└───────────────────────────────────────────────────────┘
        ↑ the rule is labeled, sectioned, near the top,
          and framed as a constraint — not a preference

Three things change when you move from the “before” prompt to the “after” one, and each does real work:

1. Labeling. A heading like RULES or CONSTRAINTS tells the model “this block is a checklist, weigh it accordingly” — the same way a bolded warning in a manual gets read differently than a footnote.
2. Position. Placing rules up front, right after the role, means they land before the model has built up a long context of task detail to reason over. This is the same “recency and primacy beat middle” effect covered in Lost-in-the-Middle and Context Rot — content in the middle of a long prompt is statistically the least attended-to.
3. Explicitness. “Be professional” is a vibe. “Never quote a price without including the disclaimer text” is a criterion — testable, unambiguous, and structurally distinct from stylistic preferences the model is free to weight more loosely.

Why the other options fail

• A) Say it louder in caps everywhere. Volume is not structure. ALL-CAPS THROUGHOUT A PROMPT doesn’t tell the model which of ten capitalized sentences is the one that must never be violated — it just raises the noise floor uniformly, so nothing stands out. Emphasis only works when it’s selective; apply it everywhere and it stops meaning anything.
• C) A bigger model. A larger model may follow instructions more reliably on average, but it does not fix a structural problem — it papers over it probabilistically. The same buried, unlabeled rule in the same messy prompt will still get missed sometimes, just less often. You’ve spent a cost and latency budget instead of five minutes reorganizing a prompt, and the failure mode is still latent.
• D) Repeat the whole prompt twice. Duplicating the entire prompt doubles the token count and duplicates the same low-signal structure — the buried rule is now buried twice, in the same relative position (middle-ish) both times. Repetition of an unstructured block doesn’t create the “this is a constraint” signal; it just gives the model twice as much prose to skim.

The concept behind it

This question is really about a general principle: an LLM’s attention to instructions is not uniform across a prompt, and it is not proportional to instruction length or volume — it is shaped by structure and position. Once you internalize that, a whole class of “the model ignores my instructions” bugs becomes diagnosable instead of mysterious.

Practical rules that follow from the mechanism:

A useful mental model: role → rules → task → format is not a stylistic preference, it’s a scaffold that matches how attention degrades across a long context. Role tells the model what lens to reason through. Rules — stated as explicit, prioritized, structurally distinct criteria — are the constraints every output must satisfy, and they belong as close to the top as the role itself. Task is the actual work. Format is how to package the answer. When all four blur into one paragraph, the model has to infer which sentences are load-bearing; when they’re separated and labeled, it doesn’t have to infer anything.

This also explains why “prompt engineering” as a CCA exam domain has drifted away from wording tricks and toward architecture. The skill being tested isn’t finding a magic phrase — it’s building a prompt whose shape communicates priority. That same instinct — force structure instead of hoping for compliance — is why forced tool_choice beats “please return JSON” for guaranteeing valid JSON output, and why diverse, well-organized few-shot examples outperform a pile of similar ones. Structure is the lever; wording is a minor adjustment on top of it.

FAQ

Does instruction placement matter more with longer system prompts? Yes, and the effect compounds. A 200-token system prompt has little room for a rule to get truly buried. A 4,000-token system prompt has plenty of room, and everything in the unstructured middle competes for the same limited attention. The longer your prompt grows, the more disciplined the role/rules/task/format separation needs to be — see Lost-in-the-Middle and Context Rot for the underlying mechanism at the context-window level, not just the prompt level.

Is putting rules in caps ever a good idea? Sparingly, yes — for a single non-negotiable line, capitalizing it can help it stand out visually. The failure mode in option A isn’t capitalization itself, it’s applying it everywhere, which erases the contrast that made it useful in the first place. One emphasized line beats ten.

If structuring the prompt doesn’t fully fix adherence, what’s next? If a rule is truly safety- or compliance-critical and prompt structure alone isn’t hitting the reliability bar you need, move enforcement out of the prompt and into the pipeline — validate the output against the rule programmatically and retry or reject on failure, the same bounded-retry pattern covered in Bounded Retries for LLM Output. Prompt structure raises the base rate; validation catches what still slips through.

Does this apply to tool descriptions and few-shot examples too, or just system prompt rules? The same “structure and position beat volume” principle applies broadly. A tool description with the critical constraint buried in a run-on sentence gets ignored the same way a system-prompt rule does — put the non-negotiable part first and label it. Few-shot examples have an analogous failure mode: burying the range of acceptable outputs in near-identical examples teaches the wrong distribution, which is the subject of Diversity in Few-Shot Prompting.

Not affiliated with, authorized, or endorsed by Anthropic. “Claude” and “Claude Certified Architect” are trademarks of Anthropic. These are original practice questions for study, not real exam content — verify current exam details on Anthropic’s official pages.

Where this fits in the CCA series

This is Domain 4 (Prompt Engineering & Structured Output, 20% of the exam) — the domain where prompting stops being wording tricks and becomes contracts you can trust. Start with the full exam breakdown if you’re new to the series, and if agent architecture or tool design is more your gap, MCP Explained on One Diagram and RAG vs Context Engineering cover the other two intro pillars.

Sibling D4 questions worth working through next: How Do You Guarantee Valid JSON? covers forcing structure with tool_choice rather than hoping for it, Your Few-Shot Examples All Look the Same covers the distribution-defining role of examples, and Force the Tool, or Let It Decide? covers the four tool_choice modes this same “force it, don’t ask nicely” instinct comes from. As of mid-2026 the CCA-F exam runs on Pearson VUE (roughly $125, retakes permitted, 60 questions in 120 minutes, pass mark around 720/1000 across five domains) — verify current logistics on Anthropic’s official pages before you register. Browse all tutorials for the rest of the series.