The Constraint That Needed Its Own Section

The problem

I built a contract-review helper for a paralegal team, meant to summarize indemnification and liability clauses in plain language. The prompt I started with was one paragraph. Who the assistant is, what to do, the clause text itself, and the constraint never provide legal advice, only summarize factually, all run together in the same block of prose. It read fine. It looked like a complete, reasonable prompt.

I tested it against twenty seeded clauses, five of them deliberately worded to tempt the model into an opinion. Things like "does this clause protect us?" phrased as part of the clause context, questions a paralegal might genuinely ask but that the assistant had no business answering with anything beyond what the clause literally says. On those five advice-tempting clauses, the assistant slid into "you should" and "this protects you" language in at least three of them. The instruction not to do that was sitting right there in the prompt. It just wasn't sitting anywhere the model treated as binding.

The mechanism matters here: the model didn't ignore an instruction it somehow missed. The instruction was present, in writing, the whole time. It was buried mid-paragraph, one clause among several, competing for weight against the role description, the task description, and the clause text itself, all packed into the same undifferentiated block. A constraint sitting inside a paragraph of prose has to compete for the model's attention with everything else in that same paragraph, and on the cases where the input itself was pulling hard in the opposite direction, the buried instruction lost.

The pattern

The fix didn't touch the instruction's wording at all. I kept the exact same sentence, never provide legal advice or opinion, state only what the clause says, and gave it its own labeled section instead of leaving it embedded in prose. The full prompt became four clearly labeled blocks: Role, describing who the assistant is and who it serves. Task, describing what to do with the clause. Context, the actual clause text. Constraints, the non-negotiable instruction, now sitting alone in its own section rather than sharing real estate with three other concerns.

Nothing about the model's underlying instruction-following changed. What changed is structural. A labeled Constraints section reads to the model as a distinct, binding block, not one more clause it might or might not bother weighting the same as everything around it. I reran the identical twenty clauses, including the same five advice-tempting ones, and adherence improved measurably on exactly the cases I'd built to test it. The other fifteen clauses, the ones that weren't designed to tempt advice-giving in the first place, held steady. Nothing about the four-section structure made the summarization itself worse.

I think of this as RTCC now, shorthand for Role, Task, Context, Constraints, and it's become the default shape I reach for whenever a prompt needs to carry an instruction that absolutely cannot get lost in the noise of everything else the prompt is doing. The mechanism isn't about giving the model new information. The clause context and the constraint were both present in the original single-paragraph version too. It's about giving the model a structural signal for which pieces of the prompt are load-bearing rules and which pieces are descriptive scaffolding, a distinction a flat paragraph simply doesn't carry.

Design considerations

The obvious question is why this works at all, since nothing about the actual content changed, only its arrangement on the page. My working explanation is that models trained on enormous amounts of structured technical writing, documentation, specs, contracts with their own labeled sections, have learned that a labeled heading changes the weight of what follows it. A paragraph of continuous prose reads as one register, everything roughly equally weighted, equally skippable, equally negotiable. A labeled Constraints heading reads as a different register entirely, closer to a contract clause than a sentence in a story, and the model treats it accordingly. That's an inference from behavior. I can't point to something inside the model and prove it directly. It's my best explanation so far, and I'd revise it the moment better evidence showed up.

The calibration question that actually matters in practice is deciding what belongs in Constraints versus what belongs in Task or Context. It's tempting to lump everything remotely rule-shaped into the Constraints section until it becomes its own sprawling paragraph, which just recreates the original problem one level up. I reserve Constraints specifically for instructions that must never be violated regardless of what the input contains, the kind of thing where getting it wrong is a compliance or safety failure. A stylistic preference, keep summaries under three sentences, belongs in Task instead, because getting that wrong costs you quality, and quality misses and compliance failures call for entirely different levels of urgency. Mixing the two back together inside Constraints dilutes exactly the signal this structure exists to create.

There's also a real limit to how far labeling alone can carry a prompt. Four sections help the model tell rules from description. Resisting an input that's actively adversarial, someone constructing a clause specifically engineered to make the constraint look inapplicable, is a separate problem those four sections were never built to solve. RTCC is a prompt-authoring discipline, and it lives entirely inside the space the model is reasoning over. For a constraint where the cost of a single miss is genuinely severe, refund limits, irreversible actions, anything where a wrong output has real consequences before a human ever reviews it, labeling a section more clearly still asks the model to comply. Checking compliance independent of the model's own reasoning takes a separate piece of engineering, and RTCC alone doesn't supply it. RTCC earns its keep for the ordinary case, a constraint getting lost in prose it shouldn't have had to compete with. For the case where you can't afford to trust the model's compliance at all, no matter how clearly the instruction is labeled, that separate enforcement layer is what actually closes the gap.