The output ignores one of your instructions, consistently or run by run. The reply is a paragraph though the prompt says "one line only" — or it is one line though the prompt says "explain fully". The team responds by strengthening the losing rule: capitals, exclamation marks, "YOU MUST". It works for a day, then the other rule starts losing instead. No error is ever raised; the model never says it was given contradictory orders.
A prompt that grew by accretion: several people appended rules over weeks and nobody read the whole text top to bottom recently. Typical fights: "be brief" versus "explain every field", "reply only with JSON" versus "add a friendly closing line", a 50-word limit versus 300-word few-shot examples, "never guess" versus "always fill every field". Common in shared chat-window prompts and in system prompts inherited from another team. Linked module: 3.3 (Prompt engineering as engineering).
Two instructions cannot both be satisfied, so the model resolves the conflict for you — silently, and not by your priorities. Which rule wins depends on position, phrasing, the examples, and the input itself, which is why the winner can flip between runs and why emphasis is an arms race, not a fix. Examples outrank written rules in practice: a length limit loses to long examples nearly every time. Confirm by audit, not by rerunning: read the prompt as a specification, list every rule in a table, and mark each pair that cannot hold together. A test run per conflict shows you which side currently wins — that is evidence, not the repair.
Decide what the feature actually requires — that decision belongs to you, not the model. For each conflicting pair, keep one rule and delete the other; if both matter, split them across two prompts or two output fields (a strict JSON extraction prompt, and a separate customer-reply prompt, as in module 3.3). Re-read the few-shot examples and rewrite any that contradict a surviving rule. Then rerun your eval set and add one case per former conflict — a case that fails unless the surviving rule is honoured — so the fight cannot quietly return.
Give every production prompt an owner and a changelog, and review prompt diffs the way you review code diffs — a new rule must name the rule it might fight. Re-read the full prompt aloud after every third edit; conflicts hide from skimming. Keep examples and rules in agreement as a checklist item. When output misbehaves, hunt for a conflict before adding emphasis — capitals are how a prompt tells you nobody has audited it.
Q: "The model keeps ignoring one of your instructions. What is your process?" Strong answer: suspect instruction conflict before model failure, audit the prompt as a spec and list rule pairs that cannot coexist, note that examples override written rules, and resolve by deleting or splitting rather than shouting. Finish with the regression step — an eval case that locks in the surviving rule — and you sound like someone who has maintained prompts, not only written them.