Chapter 4 of 7 · 20 min read
Conflicting requirements in a prompt
On this page
The previous chapter's failure had a known winner — a demonstration beats the rule it contradicts — and that is what made it fixable by editing the demonstration. Between two written rules there is no known winner. Both were put there deliberately, both are correct, and the model satisfies whichever one the sampled completion happens to reach first, which is why the failure looks like variance and gets treated as one.
The distinguishing property is arithmetic rather than attitude. Two requirements compete when they spend the same budget: output length, the single field a value must go in, the one label a classifier may emit. Where the budget is large enough for both, everything works and nobody notices the tension. Where the input pushes demand past the budget, there is no output that satisfies both rules, and no amount of firmer phrasing creates one.
The failure is arithmetic, not attitude
Take a research assistant whose prompt contains two requirements. The first is
Answer in at most three sentences. The second is
For every factual claim, give the source title, author, and publication date inline.
Both were written deliberately, both are things somebody wanted, and neither is
wrong on its own.
The two of them spend the same budget, and the budget is words, so the way to find out whether they can both be satisfied is to count. Three sentences of a research answer is roughly 55 to 65 words. An inline citation in the required form costs about 12 to 16 words: (Cross-Region Latency in Practice, Okafor, March 2024). Those two quantities are in the same unit, which is what makes it legitimate to set one against the other at all.
An answer that makes four factual claims owes four citations, and the cost of the four is the sum of their individual costs rather than anything smaller. Nothing in the citation rule lets one parenthetical serve two claims: each claim names its own title, its own author and its own date, so no text is shared between them, and multiplying the per-citation cost by the number of claims is therefore the correct operation. Four citations at the cheap end is four times twelve, which is forty-eight words. At the expensive end it is four times sixteen, which is sixty-four. That is where the 48 to 64 words of citation alone comes from, and all of it is owed before a single word of the answer itself.
Now put that bill against the budget it is drawn from. At the expensive end of both, sixty-four words of citation against a ceiling of sixty-five words leaves one word for the answer. At the cheap end of both, forty-eight against fifty-five leaves seven, which is a fragment rather than a sentence. Every combination in between lands in the same place, because the two ranges overlap almost exactly: the citations consume most or all of the words the length rule permits, and the content somebody actually asked for has nowhere left to go. There is no writing skill that fits that into 60 words.
What the counting shows is that the two rules are not disagreeing about style. They are competing for the same words. A disagreement about style can be split down the middle, because some intermediate register partially satisfies both parties and costs nothing extra to write. A budget cannot be split past the point where the demands on it sum to more than it holds, and on a four-claim question they do.
On a fixed set of 200 internal questions, 47% of answers exceeded three sentences, 44% omitted at least one citation, and 9% satisfied both. Those three figures sum to a hundred, which invites the reading that every answer falls into exactly one of them, and nothing about how they were computed guarantees that. An answer can run past three sentences and drop a citation at the same time, in which case it counts in the first group and in the second, and the three rates sum past a hundred. That they do not here is itself evidence about the failure: the answers are landing in one violation or the other and almost never in both.
That aggregate is what the team sees, and at the level of "47% too long" the natural reading is that the model is disobedient and needs firmer instruction. It is worth being clear about why that reading is tempting rather than careless. Nearly half of all answers breaking a stated rule is precisely what non-compliance looks like from a dashboard, and an aggregate carries no column that distinguishes a model ignoring an instruction from a model unable to obey two of them at once. Firmer phrasing also appears to confirm the theory, because it genuinely does move the metric it targets. What is actually true is that the instruction was never the binding constraint. The available words were, and no phrasing of a rule adds words to a budget.
Bucketing the same 200 questions by how many distinct factual claims a good answer requires says something different:
| Claims a good answer needs | Questions | Both rules satisfied | Dominant violation |
|---|---|---|---|
| 1 | 22 | 82% | — |
| 2 | 41 | 34% | mixed |
| 3 | 68 | 4% | length, then citations |
| 4 or more | 69 | 0% | citations dropped |
The compliant answers are almost entirely the one-claim questions. Past two claims, the two rules describe an empty set, and the row of zeroes at the bottom is not a behaviour that can be improved — it is the arithmetic being reported back.
That last phrase is meant literally, and the bottom row is where it can be checked. A four-claim question owes at least forty-eight words of citation, and the length rule permits at most sixty-five words in total, so on the questions whose citations run toward the expensive end the citation bill alone meets or exceeds the entire budget. The set of outputs satisfying both rules on such a question has no members. A compliance rate of zero across sixty-nine questions is what an empty set looks like once somebody measures it, and there is nothing in that row for a firmer instruction to act on, because there is no behaviour in it — only the absence of any output the two rules would jointly accept.
Backend systems produce this pattern in a form most engineers have already met, and it is worth setting out as an analogy rather than as a second instance of the same thing. An availability target of 99.99% and a synchronous write to a second region on every request are individually reasonable and jointly unsatisfiable at a certain request rate, and no one responds by writing "this is a hard requirement" in the design doc. Someone decides which property gives, or changes the system so the two requirements are not competing for the same budget. A prompt with a length ceiling and a per-claim cost is the same object in that respect, and both of those moves are available.
The analogy stops at one place, and the place it stops is worth knowing because a third repair lives there. A replication budget is a physical quantity. The round trip to the second region takes as long as it takes, nothing written in the design doc shortens it, and so the only things anybody can move are the availability target and the architecture. A prompt's budget is a sentence somebody wrote. The three-sentence ceiling was not discovered by measuring anything; it is a rule, and a rule can be rewritten to depend on the input in a way a network round trip cannot. That gives a conflicted prompt a repair with no counterpart in the datacentre — leave both requirements standing and let the ceiling itself grow with the number of claims — which is why there are three repairs here against the design doc's two.
Where the two rules collide
The arithmetic establishes that on a four-claim question no legal output exists. It does not say what the model produces instead, and the shape of what it produces is what makes the failure recognisable from outside.
A model produces text one fragment at a time, appending each fragment to what it has already written and running again on the longer text, and nothing in that loop revisits an earlier choice — the property topic 1.0, on what a language model is and the loop it runs, establishes about generation. Two consequences follow for the two rules here, and they are different consequences because the rules fall due at different moments.
The citation obligation falls due locally. Each time a factual claim finishes, the text sits at a position where a citation either follows it or does not, and that choice is made there, out of the fragments available at that position. The length ceiling falls due globally, and it can only be assessed against words that have already been written. By the time enough words exist for the ceiling to be in danger, those words are behind the cursor, and the loop offers no way to take them back.
So the collision arrives at one identifiable place in the completion: the position at which the words already committed, plus the citation now owed, exceed the ceiling. At that position the continuation has exactly two exits. It can stop — end the answer where it stands, leave the remaining claims uncited, and satisfy the length rule. Or it can continue — write the citation, then the next claim, then that claim's citation, and overrun the ceiling. No third exit is available, because the words already on the page are fixed and the only decision left is whether to add more.
Each exit is then internally consistent all the way to the end of the answer. A completion that stopped is short and under-cited throughout. A completion that continued is long and fully cited throughout. Neither drifts back toward the middle, because the loop only moves forward and the collision point was the last position at which both outcomes were still reachable. That is why the bad outputs arrive as two clean populations rather than as a spectrum of answers each a little too long and a little under-cited, and it is why the two violation rates in the aggregate above almost never overlap.
The proportions come out of the same picture. Which exit a given completion takes is settled by a sampled choice among the fragments available at the collision point, in the same way any other close call in the loop is settled. Two rules that both carry real weight in the prompt leave the fragments leading to each exit close in score, and a near-tied sampled choice comes out one way about as often as the other. Roughly half and half is what that looks like measured over a few hundred questions, and it reports the tie rather than a preference the model holds between your two rules.
The seesaw follows from the two exits directly. Strengthening a rule raises the score of the continuations that honour it. At the collision point those continuations are one of the two exits, so weight added to that exit has to come from somewhere, and the only other place it can come from is the exit opposite. It does not disperse into a third behaviour, because no third behaviour is reachable from that position. A firmer length rule therefore buys compliance on length and pays for it in citations at close to the rate it bought, and a firmer citation rule does the mirror image.
Three signatures that separate conflict from absence
Chapter 2's diagnostic tree ends at a branch where nothing is missing, and a conflict is the most common thing waiting there. Telling the two apart from the failure data alone matters because the treatments are opposite: an absence is repaired by adding a sentence, and adding a sentence to a conflicted prompt makes it worse.
That asymmetry is worth stating plainly, because "add a clause" is the reflex in both situations. A sentence added to a prompt with a missing slot supplies a decision the model was otherwise making for itself, and it competes with nothing, since nothing else in the prompt spoke to that decision. A sentence added to a conflicted prompt speaks to a decision two rules are already contesting. It becomes a third claimant on the same budget, and at the collision point the only thing it can do is push weight toward one of the two exits that were already there — which is to say it strengthens one of the two rules, and brings the seesaw with it.
The first signature is the seesaw. When you strengthen one requirement and a different metric moves in the opposite direction by a comparable amount, you have found two rules sharing a budget. An absent slot does not behave this way — adding the missing constraint about closed categories in chapter 2 raised the category-validity number and left the preamble number where it was, because those two failures had no relationship.
The second is bimodality, which is the two exits seen from the outside. A prompt with a missing slot produces failures scattered across a range of shapes, since the model is improvising on every call and the improvisation has no fixed number of outcomes. A conflicted prompt produces two clean clusters, each internally consistent and each fully compliant with one rule. Reading twenty failures by hand tells you which you have in about ten minutes: if the bad outputs look like two populations rather than a spectrum, look for two rules.
The third is that the failure rate tracks a property of the input. In the table above it is claim count, and in other conflicts it is document length, number of entities, or how many of your enum categories legitimately apply. The property is almost always the one that determines whether both rules can be satisfied at once, and finding it is the fastest way to state the conflict precisely enough to fix.
The dependence has a cause, and the cause is the comparison the arithmetic above performed. Whether both rules hold on a given input is settled by putting the demand against the budget, and at least one side of that comparison is a function of the input — four claims cost four citations where one claim costs one. Any input property that enters that comparison therefore appears as a gradient in the failure rate, and any property that does not enter it appears as nothing. If the failure rate is flat across every input property you can think of, you are probably looking at variance rather than conflict.
Deciding, or removing the competition
Once the conflict is named, there are three repairs, and the choice between them is a product decision as much as an engineering one.
| Repair | What it costs | When it is right |
|---|---|---|
| Declare a winner with an explicit tiebreak | The losing requirement is violated openly on some inputs | One requirement is genuinely more important, and the other is a preference |
| Move one requirement outside the other's budget | A change to the output shape and to whatever consumes it | Both requirements are real, and the conflict is over a shared resource like length |
| Make the budget scale with the input | Slightly less predictable output size | The tension is real but bounded, and the input property is measurable |
The first is a single sentence and it is under-used because it feels like an
admission of defeat:
If citing every claim would take more than three sentences, exceed the limit and cite everything.
That sentence removes the empty set — there is now a legal output for every
input — and it converts a coin flip into a deterministic rule that both you and
the model can check. Compliance on the 200-question set with that one addition
went to 6% over-length-without-cause and 5% citation omissions, and the answers
on four-claim questions got longer, which was the correct outcome and which
someone had to agree to.
The tiebreak acts on the collision point rather than around it. The two exits were previously close in score and were being sampled between on every call; it names which exit is correct, so the choice stops being close and stops being redrawn each time. The empty set is gone in the sense that matters, which is that some output now exists that the prompt endorses for every input it will see. The requirement that loses does so openly, on the inputs where it loses, and on the record — against the previous arrangement where it lost about half the time and silently.
The second repair is usually better when both requirements are load-bearing, because it removes the competition instead of adjudicating it. Citations do not have to live inline. Move them to a separate field, and the three-sentence budget governs prose only:
Return a single JSON object:
{
"answer": string, // at most 3 sentences, no citation text inside
"sources": [ // one entry per factual claim in "answer"
{"title": string, "author": string, "published": "YYYY-MM"}
]
}
Every factual claim in "answer" must have a corresponding entry in
"sources", in the order the claims appear.The mechanism behind that schema is different from the tiebreak's, and separating
the two is what tells you when to reach for which. A tiebreak leaves the collision
in place and decides it. The schema change dismantles the collision. Once citation
text lives in sources, the words counting toward the three-sentence ceiling and
the words carrying a citation are drawn from two different places in the object, so
writing one more citation consumes none of the budget the length rule governs.
There is no input at which the two demands sum past the ceiling, because after the
change they are not summed at all. The prediction that follows is that the
compliant share stops depending on claim count altogether rather than merely
improving at every count, and it is a prediction to check on the buckets rather
than on the aggregate.
On the same 200 questions this landed at 3% over-length and 2% missing sources,
and it made a check possible that was not possible before: the client counts
claims against sources.length and can flag a mismatch without any model
involvement. The cost was real — the Slack renderer had to grow a footnote
section, which was two days of front-end work, and that is the honest trade. A
prompt-only fix is cheaper and a schema change is better, and which one you take
depends on whether the consumer is yours to change.
The third repair scales the budget:
Answer in at most one sentence per factual claim, to a maximum of five sentences.
It works by tying the ceiling to the same input property that drives the demand,
so both sides of the comparison grow together and the position at which they
cross is never reached on any input inside the cap. This keeps answers short on
the questions where shortness was the point and lets them grow where the
requirement demands it. It works when the input property is something the model
can assess reliably; it works badly when the property is something like "how
novel is this question", which the model will estimate differently on every call
and which therefore reintroduces variance in place of conflict.
Not every tension is a conflict
The diagnosis is easy to over-apply, and over-applying it leads to prompts stripped of every requirement that ever appeared in a failure. "Be concise and thorough" is not a conflict, because concise and thorough are directions on a dial rather than a budget with a fixed size; the model resolves that tension the way a writer does, and the resolution is usually acceptable. "Use a warm tone" alongside "never speculate about the customer's feelings" reads like tension and is satisfiable on essentially every input. The test that separates them is whether you can construct a specific input on which both rules cannot simultaneously hold, and if you cannot, you are looking at a preference the model is weighing rather than an empty set it must escape.
Conflicts also occur across slots, not only between two constraints. A format slot
that says Reply with the category name alone and a task that says
explain your reasoning is the same failure with different labels; so is a
constraint against speculation sitting above a task that asks for a recommendation
on incomplete data. Neither pair looks like the length case on the surface, and
both are the same object underneath, because a budget need not be measured in
words. In the first the budget is the single reply, which can carry the bare
category or the category with a paragraph of reasoning and cannot carry both. In
the second it is the single recommendation, which can be withheld to honour the
constraint or given to honour the task and cannot be both at once. Any budget with
room for one occupant produces two exits, and everything derived above about two
exits applies unchanged. The special case where one party is an example is the
previous chapter's, and it is worth keeping separate because there the disagreement
has a known winner.
Finding conflicts before they reach production is cheaper than diagnosing them afterwards, and the exercise takes fifteen minutes. List every requirement in the prompt as a line item, note which ones spend a shared resource, and for each pair sharing a resource, try to write down the hardest input you can imagine. If you can produce an input where the pair has no legal output, you have found a conflict on paper before it cost you a quarter of your traffic. The requirements most worth checking are the ones added at different times by different people, because a prompt that was coherent when written acquires conflicts the way a schema acquires nullable columns: one reasonable addition at a time, each defensible on its own.
There is also a class of conflict you should not resolve in the prompt at all. When the two requirements come from two different stakeholders, writing a tiebreak sentence is making a policy decision on their behalf, quietly, in a file they do not read. The engineering work is to state the trade with numbers, which the table of claim counts does, and to let the people who own the requirements pick. Prompts that carry undocumented tiebreaks tend to acquire a second, contradictory tiebreak the following quarter when the other stakeholder complains.
Every claim in this chapter was a measured pair of numbers: 47 and 44, then 12 and 79, then 3 and 2. That is not incidental to the method, it is the method. A conflict is invisible in an aggregate and invisible in a diff, and the only thing that makes one visible is two metrics moving in opposite directions on the same set of cases — which means the fix for a conflicted prompt is unshippable until you can say what it cost and what it bought on a set of cases that did not move.
Anatomy of a prompt — read the current version at https://daviddominguez.dev/learn/en/anatomy-of-a-prompt/conflicting-requirements-in-a-prompt