In the RCCOF Framework™ (Role, Context, Constraint, Output format, Few-shot), Constraint is the negative layer. It enumerates what the model must never do, claim or write. Every other layer adds possibility; this one removes it. Constraint is where a prompt stops being a request and becomes a specification, because a specification is defined as much by what it forbids as by what it asks for.
What Constraint in RCCOF is
Constraint in the RCCOF Framework is the explicit enumeration of prohibited behaviours, prohibited vocabulary and prohibited claims. It is written in the negative on purpose. Where Role, Context and Few-shot describe what a good output contains, Constraint describes the boundary that a failing output crosses.
The layer exists because positive instruction has a ceiling. Telling a model to write clearly leaves the definition of clarity to its training distribution. Telling it that no sentence may exceed a stated length, that a listed set of words may not appear, and that no figure may be used unless supplied, converts a preference into something a reviewer can check mechanically.
Constraint is also the layer that survives model changes best. A new model version can shift the register a Role produces or the structure a Format request yields, but a prohibition on a specific word either held or it did not, and that is visible in one search.
Why negative instructions do work that positive ones cannot
Negative instructions do a kind of work that positive instructions structurally cannot, and understanding why prevents teams from trying to rewrite their constraints as encouragements. A positive instruction expands the space of acceptable outputs; a negative one contracts it. Only contraction produces determinism.
Consider the difference in what each one leaves undecided:
| Instruction | What it decides | What it leaves open |
|---|---|---|
| "Write concisely" | A direction | Every actual length |
| "No paragraph may exceed four sentences" | Every actual length | Nothing relevant |
| "Use a professional tone" | A direction | Which words count as unprofessional |
| "Do not use the words listed below" | Those words, exactly | Words not on the list, which is the point |
| "Be accurate" | Nothing enforceable | Which claims are permitted |
| "Do not state any figure not supplied in Context" | Which claims are permitted | Nothing relevant |
The right-hand column is where invented content comes from. A positive instruction that leaves a decision open does not leave it unmade; it delegates it to the model, which will make it from the statistical centre of its training data.
The five constraint classes in enterprise prompts
These five constraint classes cover almost every prohibition an enterprise prompt is likely to need, and separating them matters because each class is maintained by a different person on a different cycle. Mixing them into one paragraph means nobody owns any of them.
| Class | What it forbids | Owned by | Changes |
|---|---|---|---|
| Lexical | Specific words and phrases | Editorial | Quarterly, as the list grows |
| Structural | Lengths, counts, nesting depth | Content design | Rarely |
| Evidential | Claims, figures and citations not supplied | Legal or subject expert | Rarely, and never loosened casually |
| Positional | Comparisons, competitor naming, guarantees | Legal or brand | On policy change |
| Procedural | Asking the user questions, apologising, narrating its own process | Whoever owns the prompt | Rarely |
The evidential class is the one that prevents the failure everyone remembers. It is also the one most often written too softly: "try to avoid unsupported claims" is a lexical-sounding sentence that enforces nothing, while "no numeric claim may appear unless it is present in the Context block" is checkable by searching the output for digits.
The banned vocabulary list, and how to build your own
A banned vocabulary list is the most-copied and the least-transferable constraint in circulation, because the words that mark machine-written prose in one organisation are ordinary professional usage in another. Build the list from your own outputs rather than adopting somebody else's.
A method that produces a list worth enforcing:
- Collect twenty unedited outputs from your current prompts, before any human revision.
- Collect twenty published pieces written by your team and considered good.
- Find the words common in the first set and absent from the second. Those are your markers, not the ones on a shared list.
- Cut anything a subject expert would legitimately use. A banned word that appears in correct technical writing costs you accuracy to buy a stylistic tell.
- Re-run the comparison quarterly. Models change, and a list built against a previous version enforces yesterday's tells.
Ban phrases and constructions as well as single words. Sentence openings that hedge, paired constructions that assert one thing by denying another, and closing paragraphs that restate the opening are structural habits, and each of them can be stated as a prohibition.
Numeric and structural limits that actually hold
Numeric and structural limits are the constraints most likely to be obeyed, because they are unambiguous, and the ones most likely to be written in a form that cannot be checked. The difference lies in whether the limit is countable by a reviewer without judgement.
- Countable and therefore enforceable: sentences per paragraph, words in the opening paragraph of a section, number of columns in a table, number of items in a list, headings per document.
- Not countable and therefore decorative: "short paragraphs", "a few examples", "appropriate length", "scannable structure".
Set the limit at the value you actually want, not at a safety margin. A limit set loose to avoid awkward output will be used to its full extent every time, because the model has no reason to stay under it. If four sentences is the intent, four is the number to write.
One caution worth stating: limits interact. An answer-first paragraph capped at fifty words and a requirement to define a term in that same paragraph will conflict on any term that needs a long definition. When two constraints cannot both hold, the model will break one silently rather than report the conflict.
Comparative matrix: soft guidance against hard constraint
This comparative matrix puts soft guidance against hard constraint on each of the dimensions that decide whether a prohibition survives contact with a real generation run. The left column is what most prompts contain; the right is what makes review possible.
| Dimension | Soft guidance | Hard constraint |
|---|---|---|
| Form | Adjective or adverb | Prohibition with a countable object |
| Checked by | Reader judgement | Search or count |
| Disagreement | Two reviewers, two verdicts | One verdict |
| Survives a model change | Unknown until someone notices | Testable immediately |
| Automatable | No | Yes, which is the point |
| Cost when violated | Argument about taste | A specific line to fix |
Constraints that backfire, and why
Some constraints reliably make output worse, and the constraints that backfire share a single shape: each one prohibits something the model needs in order to satisfy another requirement in the same prompt. Recognising that shape is more useful than memorising a list of them.
- Banning a word with no permitted substitute. The model reaches for the next-nearest word, which is often worse. Ban the word and supply the replacement.
- Prohibiting hedging while demanding certainty about uncertain things. The result is confident phrasing applied to claims that should have been qualified, which is more dangerous than the hedge.
- Capping length while requiring exhaustive coverage. One of the two gives way, and the model chooses which without telling you.
- Forbidding the model to say it does not know. This converts every gap into an invention, and it is the single most costly prohibition in circulation.
- Banning a construction that appears in your own approved examples. The Few-shot layer then demonstrates exactly what Constraint forbids, and the layers fight.
The last of these is worth a standing check. Run your banned list against your own exemplars before shipping either, because a contradiction between layers is resolved silently and in an order nobody chose.
Constraint against Output Format: where the boundary sits
Constraint and Output Format both make statements about the shape of the result, which is why they blur. The boundary is simple to state: Output Format describes the structure the result must have, and Constraint describes what may not appear inside it.
| Property | Constraint | Output Format |
|---|---|---|
| Direction | Negative, removes possibilities | Positive, specifies a shape |
| Example | No paragraph may exceed four sentences | Each section opens with an answer paragraph, then a table |
| If violated | The content is non-compliant | The structure is wrong and extraction fails |
| Maintained | As policy and editorial standards change | As the delivery target changes |
A useful test when placing a rule: ask whether it would still apply if the output were delivered in a different structure. Rules about vocabulary and claims survive the change and belong in Constraint. Rules about headings, tables and ordering do not, and belong in Output Format.
Position of Constraint in the 5-layer RCCOF specification
Constraint occupies the third position in the RCCOF specification, after Role and Context and before Output Format. Its placement is deliberate: prohibitions written before the subject and audience are known are written against an imagined piece, and tend either to be too broad to hold or too narrow to matter.
- Role fixes who is speaking and with what authority.
- Context fixes what is true and who is being addressed.
- Constraint fixes what may not be done or claimed.
- Output Format fixes the structure the result must take.
- Few-shot fixes the register by demonstration rather than description.
Constraint is also the layer that most often needs to reference another. Evidential constraints point back at the Context block, because "no figure not supplied" is meaningless without a defined place where figures are supplied. The full specification sets out how the five layers combine.
Frequently asked questions about Constraint in RCCOF
These are the questions most frequently asked about Constraint in RCCOF once teams start writing prohibitions: how many are too many, whether a model can be trusted to obey them, what to do when constraints conflict, and whether a banned word list can simply be borrowed from somewhere else.
How many constraints are too many?
The practical ceiling is reached when constraints begin contradicting each other rather than when a count is exceeded. Before adding one, check it against the existing list and against your exemplars. A contradiction costs more than the constraint was worth, because the model resolves it silently.
Can a model be trusted to obey constraints?
Not on trust, which is why the class matters. Countable constraints can be verified after generation by counting, and lexical ones by searching. Treat the constraint block as a specification to check against rather than as an instruction that guarantees compliance.
What happens when two constraints conflict?
One of them gives way, the model does not report which, and the choice may differ between runs. This is the strongest argument for keeping constraints countable: a conflict between two countable rules can be detected by testing, whereas a conflict between two vague ones can only be argued about.
Can I reuse a banned word list from another team?
As a starting point only. The words that mark machine-written prose depend on your subject matter and your house style, and an imported list will ban terms your experts use correctly while missing the tells specific to your own outputs. Build the real list by comparing your generated and published work.
Which words does the RCCOF template ban by default?
The RCCOF master template bans leading, reputable, high quality and best in class. They are claims a reader cannot check, and a model reaches for them whenever it has no facts to offer.
What instruction stops a model from inventing facts?
RCCOF requires the explicit instruction: strictly use provided facts; do not infer or fabricate unverified claims. It works together with the Context layer, which must supply every number and proper noun.