If you have ever given a language model two instructions and watched it follow one while ignoring the other, you have run into a priority conflict. It feels like the model is being disobedient, but it is actually doing something sensible: when instructions disagree, it picks one based on a kind of pecking order. Learning that pecking order, called the instruction hierarchy, takes the mystery out of a lot of confusing model behavior.
This article assumes you know nothing about the topic. We will define every term in plain language, start from first principles, and build up to the point where you can predict and control which instruction wins. There is no math and no jargon you have to look up. By the end you will understand why that earlier instruction got ignored and how to make the right one win next time.
The goal is confidence. Once you see the structure underneath, conflicting instructions stop feeling like a bug and start feeling like something you can design around.
Start With a Simple Picture
Imagine you are a new employee on your first day. Your company handbook says one thing, your manager says another, and a customer asks for a third. When these disagree, you do not flip a coin. You follow a sense of who has more authority: the handbook outranks the customer, your manager fits somewhere in between.
A language model works similarly. It receives instructions from different sources, and those sources have different levels of authority.
The three common sources
- The system prompt: the application's standing rules, like the handbook.
- The developer or tool instructions: task-specific direction, like your manager.
- The user message: what the person typing asks for, like the customer.
When two of these disagree, the model leans toward the higher-authority source. That ordering is the instruction hierarchy.
What a Priority Conflict Actually Is
A priority conflict is simply a moment when two instructions cannot both be followed.
A concrete example
Suppose the system prompt says always respond in formal English and the user writes please reply casually, like a friend. Both are instructions. They point in different directions. The model has to choose, and the hierarchy nudges it toward the system prompt because that source has higher authority.
Why this matters to you
If you do not know the hierarchy exists, this looks like the model ignoring you. Once you know it exists, you understand that your user-level request lost to a higher-authority rule, and you know where to make a change if you want a different outcome.
Why the Hierarchy Exists at All
It might seem friendlier if the model just did whatever the latest instruction said. There is a good reason it does not.
Protecting the rules
Applications need rules that users cannot switch off. If a user could disable a safety guideline just by asking, the guideline would be useless. The hierarchy lets an application set rules that hold no matter what the user types. That protection is the whole reason the ordering exists.
A real-world parallel
This is why a customer cannot talk a cashier into ignoring store policy. The policy sits above the customer's request on purpose. The model's hierarchy is the same idea applied to instructions.
How to Make the Right Instruction Win
Once you understand the hierarchy, you can use it deliberately.
Put important rules in the right place
If something must always happen, put it in the highest-authority source you control, usually the system prompt. If something is just a default the user can change, put it lower or phrase it as a preference. Placement is your main lever.
Say which instruction wins, out loud
You do not have to leave it to chance. You can write the precedence directly: if the user asks for casual language, that is fine, but never drop the safety disclaimer. Spelling out the winner removes ambiguity. A fuller method for doing this is in A Sequential Method for Settling Instruction Conflicts.
Keep your top-level rules short
A system prompt crammed with dozens of soft suggestions is easy for the model to lose track of. A short list of genuine must-haves is easier for the model to honor. Reserve the top layer for things that truly cannot be overridden.
A Beginner's Checklist for Avoiding Conflicts
When your model ignores part of your instructions, walk through this.
- List every instruction you gave and where it came from.
- Find the two that disagree.
- Check which sits higher in the hierarchy; that is usually the one that won.
- Decide which one you actually want to win.
- Move or rephrase the loser, or state the precedence explicitly.
This simple routine resolves most beginner conflict problems without any advanced technique.
A Worked Example You Can Try
Seeing the idea in action makes it stick. Here is a small scenario you can reason through.
The setup
Suppose you are building a simple assistant. Your system prompt says always end your answer with a short summary line. A user writes please do not add any summary, just give me the answer. Two instructions now disagree: yours says add a summary, the user says do not.
Walking it through
The system prompt has higher authority than the user message, so by default the model leans toward adding the summary even though the user asked it not to. If that is what you want, you are done. If you would rather let users turn off the summary, you have two choices: phrase the summary as a default the user can override, or add a line saying if the user asks you not to summarize, skip the summary.
The lesson
You did not have to fight the model. You located the conflict, saw which source ranked higher, and decided whether to keep or relax your rule. That is the entire skill in miniature. The same reasoning, applied step by step, appears in A Sequential Method for Settling Instruction Conflicts.
Where to Go Next
Once the basics click, there is more depth to explore.
Adversarial conflicts
Some conflicts are created on purpose by people trying to trick the model into ignoring its rules. Defending against that is a more advanced topic, but it builds directly on the hierarchy you just learned. The complete picture is laid out in Mastering How Models Resolve Conflicting Instructions.
Testing your prompts
As you get comfortable, you will want to test that your intended instruction reliably wins, rather than checking by hand each time. That habit is what separates hobby prompts from production-ready ones.
Frequently Asked Questions
Why did the model ignore one of my instructions?
It almost certainly did not ignore it randomly. Two of your instructions disagreed, and the model followed the one from the higher-authority source. List your instructions, find the conflict, and you will usually see which higher-priority rule overrode the other.
Is the user message always the lowest priority?
In most applications, yes, the user message sits below the system and developer instructions on purpose, so users cannot override an application's rules. This is a feature, not a limitation. It is what lets applications enforce guidelines that hold regardless of what a user types.
How do I make the model follow my instruction instead of the system rule?
If the system rule is one you control, you can change or relax it. If it is a platform-level safety rule, you cannot and should not try to override it. For rules you own, either move your instruction higher or state explicitly that your instruction takes precedence in that case.
Do I need to be technical to understand this?
No. The instruction hierarchy is a concept about authority and precedence, not code. If you understand why a store policy outranks a customer request, you already understand the core idea. The rest is just learning where to place your instructions.
What is the simplest way to avoid conflicts entirely?
Keep your top-level rules short and your instructions consistent, and state precedence explicitly whenever two instructions might pull in different directions. Most beginner conflicts come from giving contradictory instructions without saying which one should win.
Key Takeaways
- A priority conflict is when two instructions cannot both be followed and the model must choose.
- The instruction hierarchy ranks instruction sources, usually system above developer above user.
- The hierarchy exists so applications can set rules users cannot switch off by asking.
- Make the right instruction win by placing important rules high and stating precedence explicitly.
- When the model ignores you, list your instructions, find the conflict, and check which ranked higher.