When a system prompt and a user prompt disagree, the system prompt wins. That single rule explains jailbreaks, and why a chatbot sometimes refuses a request its operator clearly wanted it to allow. Messages sent to a large language model carry a role, and those roles are ranked by authority: a higher-ranked instruction overrides a lower-ranked one when the two conflict. Get the ranking right and most prompting confusion clears up.
Most explainers stop at a two-way split, system versus user, and miss that the modern ladder has more rungs. OpenAI formalized a full chain of command, added a distinct developer role, and renamed the top tiers along the way. This post lays out the complete hierarchy, shows the precedence table you can screenshot, explains how OpenAI and Anthropic implement it differently, and connects it to the reason prompt injection keeps working.
System prompt vs user prompt: what a role actually is
A role is a label attached to each message in the conversation the model reads. Under the hood the model receives one flat sequence of text. Roles tell it where each chunk came from, and therefore how much to trust and obey it. Same words, different weight. A sentence that reads as an order from the rule-setting channel is merely a request when it arrives from the user channel.
Three roles do almost all the work. The system or developer message sets the rules: who the assistant is, what it must and must not do, the output format, the tone. The user message carries the end user's request. The assistant message is the model's own reply, fed back in on the next turn so the conversation has memory. Tool or function messages add a fourth role for returning results from external calls. None of these are special tokens the model obeys by magic. They are conventions the model was trained to respect, which is the detail that matters once you reach prompt injection.
The core rule, in one line: instructions with higher authority override instructions with lower authority when they conflict. Everything else is detail about which role sits where on the ladder.
The full instruction hierarchy: system, developer, and user
OpenAI's Model Spec defines a chain of command with four authority levels, ranked from highest to lowest: Platform, Developer, User, and Guideline. Platform rules cannot be overridden by anyone building on or using the model. Developer instructions, supplied through the API by the company building the app, come next. User instructions sit below that. Guidelines are soft defaults that the user or developer can implicitly override.
Later revisions of the Model Spec split and renamed the top tier. The December 2025 version lists five levels: Root, System, Developer, User, and Guideline. Root holds fundamental rules that nothing can override. System holds OpenAI's own centrally set policies. The two spec versions are worth holding side by side, because the count changed but the ordering did not. The practical takeaway stays the same: whoever set up the platform outranks the app developer, the developer outranks the end user, and soft defaults sit at the bottom.
| Authority level | Who sets it | Can it be overridden? |
|---|---|---|
| Platform / Root / System | The model provider (OpenAI) | No, not by developers or users |
| Developer | The company building the app, via the API | Only by platform-level rules |
| User | The end user typing in the chat | By developer and platform rules |
| Guideline | Soft defaults baked into the model | Implicitly, by a user or developer |
Read the table top to bottom and you have the answer to nearly every who-wins question. A user asking the model to ignore its app's safety rules loses, because in a conflict the developer outranks the user. A developer trying to override a platform-level safety rule loses, because the platform outranks the developer. A guideline that suggests a default tone yields the moment the user asks for something specific. The model is not weighing the merits of each request; it is resolving a conflict by rank, the way an org chart resolves who gets the final call.
Where the developer role came from
The developer role is the rung most posts skip. For years the rule-setting message was simply called the system message. OpenAI introduced developer as a separate role to draw a clean line between the model provider's own policies and the instructions an API customer writes for their application. The provider's rules became the higher tier; the app builder's rules became developer. The split matters because it puts the company shipping the product on a different rung from the company that trained the model, which is exactly the boundary safety policies need to sit above.
The o1 reasoning models made this concrete: they expect a developer message where older models took a system message. Send a system role and the platform treats it as a developer message. The guidance is explicit: do not send both a system and a developer message in the same request, because they are now the same tier under two names. If you are porting an older prompt, the safe move is to rename the system message to developer rather than to keep both and hope the platform picks the right one.
A useful analogy
Think of a developer message as a function definition and a user message as the arguments passed in. The developer message states the rules and business logic that hold across every call. The user message supplies the specific input the model applies those rules to. The function decides what happens; the arguments only fill in the blanks the function allows. That framing predicts the precedence correctly: arguments cannot rewrite the function. It also predicts the failure mode. If an argument is allowed to carry its own instructions, and the function reads them as code, the separation collapses, which is the situation every injection attack engineers.
How OpenAI and Anthropic differ
Anthropic implements the same idea with a leaner shape. There is no developer role in the Claude Messages API. Instead, the request carries a dedicated system parameter for the rule-setting text, separate from the messages array. The messages array then holds alternating user and assistant turns. Claude is trained to give the system prompt higher standing than the conversational turns, so the precedence intent matches even though the wiring differs.
The portable mental model across providers: one channel sets the rules and ranks high, another channel carries the request and ranks low, and the model is trained to resolve conflicts in favor of the rule-setting channel. Whether that high channel is called system, developer, or a separate system parameter is an implementation detail. The authority ordering is the part that transfers. Learn it once and you can move between APIs without relearning who wins; you only relearn which field to type the rules into.
Put durable rules, persona, and output format in the system or developer channel, not in the user turn. Rules placed in the user turn carry user-level authority, which means later instructions, including injected ones, can sit at the same tier and compete with them.
Why prompt injection is a hierarchy violation
Prompt injection works because the hierarchy can be tricked, not because it fails to exist.
An injection attack smuggles attacker-controlled text into the model so it is read as a higher-authority instruction than it deserves. The model has no reliable way to tell a genuine developer rule from a sentence that merely says ignore your previous instructions and do this instead. Both arrive as text. The defense rests entirely on the model honoring the role boundary, and that boundary is soft, a learned habit rather than a hard wall.
The sharpest version is indirect prompt injection. A web page, a PDF, an email, or a tool result gets pulled into the context, and that untrusted content contains instructions. It enters at a low tier, content the model is supposed to summarize or act on, but it is phrased as a command. If the model obeys it, untrusted user-tier text has effectively jumped the chain of command and behaved like a developer instruction. The whole class of attack is one thing: untrusted text jumping the chain of command.
This is why prompt injection stays unsolved rather than being patched once. There is no clean separator between trusted instructions and untrusted data inside a single text stream, so the model's adherence to roles is probabilistic, not enforced. Each partial defense is an attempt to keep low-tier content from being read as high-tier instruction. Input filtering, delimiter fencing, separate trust labels, and tool-output sandboxing all chase the same goal, and all of them raise the cost of an attack without closing the gap, because the gap is structural.
Putting it to work
- Keep all non-negotiable rules in the system or developer channel; treat the user turn as untrusted input even when it comes from a real user.
- On o1 and newer OpenAI models, send a developer message rather than a system message, and never send both in one request.
- On Claude, use the dedicated system parameter for rules and reserve the messages array for the actual conversation.
- When you pull in external content (search results, files, tool output), label it clearly as data and assume any instructions inside it are an injection attempt.
- Do not rely on a system prompt alone to block determined misuse; the role boundary raises the bar but does not guarantee the order is honored.
Where MemX fits
A model only knows what is in its context, so what you put there, and where it comes from, is the lever you control. MemX is a consumer AI memory app: an external memory layer over your own documents, photos, and notes across Android, iOS, and WhatsApp. It supplies grounded context to your assistant from sources you control, rather than relying on whatever a third-party page or tool happens to inject.
MemX is private by architecture: per-user keys, encryption at rest, and on-device-first processing. That design keeps your memory under your own control, which matters precisely because, as the injection problem shows, the model itself cannot be trusted to police where its context came from. Clean, owned context is one of the few levers a user actually holds.
01What is the difference between a system prompt and a user prompt?
The system or developer prompt sets the rules and ranks higher; the user prompt carries the request and ranks lower. When the two conflict, the model is trained to follow the rule-setting channel. So a user request to ignore the app's rules loses to the rules the developer set.
02What is the difference between a system prompt and a developer prompt?
They are now effectively the same tier under two names. OpenAI introduced developer to separate an app builder's instructions from the provider's own policies. On o1 and newer models, send a developer message; a system message is treated as one. Never send both in a single request.
03Does Claude have a developer role?
No. Anthropic's Messages API uses a dedicated system parameter for rule-setting text, separate from the messages array of alternating user and assistant turns. There is no developer role, but the system prompt still carries higher standing than the conversational turns.
04Why can users sometimes override system instructions anyway?
Because the hierarchy is honored probabilistically, not enforced. Everything reaches the model as one text stream, so a cleverly phrased user or injected message can be read as a higher-priority instruction. That gap is exactly what prompt injection and jailbreaks exploit.
05What is the full instruction hierarchy in OpenAI's Model Spec?
From highest to lowest authority: Platform, Developer, User, Guideline. Later spec revisions split the top into Root and System, giving five levels. Higher levels override lower ones, and the provider's rules always outrank both the developer and the end user.
