Why do some conditions get dropped and not others?

There is no stable rule, which is the awkward part. The same request run twice can drop different requirements, so a condition that held during testing is not guaranteed afterwards. That is why anything that must hold every time needs a check rather than a stipulation.

Does splitting the request help?

Usually, and it is the most reliable remedy available. Fewer conditions per request means fewer competing for attention, which is the same reason chaining works. It costs more requests and it addresses the actual cause rather than restating the requirement more firmly.

Are prohibitions harder than requirements?

Generally yes. Asking for something to appear is a single action to perform; asking for something never to appear has to hold across the whole answer. Requests built largely from things to avoid are the ones most likely to disappoint, and rewriting them as positive requirements often helps.

Glossary

Instruction following

Instruction following is how reliably a system does what it was actually told, and it degrades as the number of conditions that must all hold at once goes up.

In plain terms

Whether it did what you asked. Not whether the answer was good, which is a separate question, but whether the specific things you stipulated actually happened. Ask for four conditions and you will often get three, with nothing indicating which one went missing.

Why it matters

Because it decides whether a request can be relied on rather than checked. Anything with several conditions that must all hold is being trusted to hold all of them, and the failure is silent: what comes back is fluent, plausible and quietly missing one requirement nobody reread the request to notice.

How it works

Reliability falls as conditions accumulate, and not gently. One or two stipulations are followed almost always. Six competing ones, some of which pull against each other, are followed selectively, and which one gets dropped is not stable between attempts. That instability is what separates this from ordinary software behaving incorrectly.

Negative conditions are followed less reliably than positive ones. Asking for something to be included is more dependable than asking for something to be left out, because the second requires noticing an absence throughout rather than performing an action once. Requests built mostly from prohibitions are the ones that disappoint most often.

The failure is silent, which is the operationally important part. Nothing reports that a condition was dropped; the answer simply arrives without it, looking exactly like an answer that met every requirement. Detecting it means rereading the original request against the result, which is the step nobody does at volume.

It is a stated axis of comparison rather than a hidden property. Vendors describe strength at following detailed instructions as a selling point, and the corpus reflects that: one assistant's page names understanding detailed instructions and holding context across long conversations as its distinguishing strengths. That framing is a fair signal that it varies between products.

How many things must all hold at once

Laying this out as a count rather than as a quality makes the practical response obvious, which is why it is worth doing. The instinct on discovering a dropped requirement is to restate it more firmly, move it to the front, or write it in capitals, all of which treat the problem as one of emphasis. If the cause is that eight things are competing, emphasis merely changes which one gets dropped. The move that actually works is to reduce the count, either by splitting the request into stages or by moving the requirement out of the request entirely and into a check that runs afterwards. That second option is the one worth reaching for whenever a condition genuinely must hold every time, because no amount of instruction reliability turns a request into a guarantee.

Seen in the wild

An assistant described as particularly strong at understanding detailed instructions and holding context across long conversations, which is this property named as a selling point.
Claude
A general assistant whose own documentation warns that it can misunderstand context or make unsupported assumptions, so important output should be reviewed.
ChatGPT
A step inside an automation where a fixed instruction runs over every record, so a condition dropped occasionally is dropped invisibly at volume.
Make

Common misconceptions

People assume

A missed condition means the request was unclear.

In fact

Often it was perfectly clear and simply competing with five others. Clarity helps and it does not remove the effect, which is about how many requirements are being held at once rather than how well any one is expressed. Rewriting for clarity when the real problem is quantity produces no improvement.

People assume

It will be obvious when something was ignored.

In fact

It is obvious only if you reread the request against the answer, which is exactly the check that gets skipped once results start looking good. The output is fluent and complete-seeming either way, so nothing about it draws attention to the requirement that went missing.

Telling them apart

Instruction following vs Hallucination

Instruction following

It did not do what you asked.

Hallucination

It stated something that is not true.

Both produce a confident wrong answer and they need different checks. One is caught by rereading the request, the other by checking the world.

Questions

Why do some conditions get dropped and not others?: There is no stable rule, which is the awkward part. The same request run twice can drop different requirements, so a condition that held during testing is not guaranteed afterwards. That is why anything that must hold every time needs a check rather than a stipulation.
Does splitting the request help?: Usually, and it is the most reliable remedy available. Fewer conditions per request means fewer competing for attention, which is the same reason chaining works. It costs more requests and it addresses the actual cause rather than restating the requirement more firmly.
Are prohibitions harder than requirements?: Generally yes. Asking for something to appear is a single action to perform; asking for something never to appear has to hold across the whole answer. Requests built largely from things to avoid are the ones most likely to disappoint, and rewriting them as positive requirements often helps.

Key takeaways

Reliability falls as conditions accumulate, and which one drops is not stable.
Prohibitions are followed less reliably than requirements.
The failure is silent: nothing reports that a condition went missing.
Splitting the request addresses the cause; restating it more firmly does not.

Tools that use this

Claude
Detailed instructions and long-conversation context named as strengths.
ChatGPT
Documentation warning that context can be misunderstood and output needs review.
Make
A fixed instruction over every record, where a dropped condition is invisible.