How do system, developer, user, and contextual instructions differ?

Explains instruction authority while keeping provider-specific message roles separate from the application’s durable trust boundary.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

Higher-authority application instructions define the model’s role and constraints, while user instructions describe the current task. Retrieved documents, tool results, and quoted text should normally be treated as data, not as new authority. Exact role names and precedence rules vary by provider, so I follow the provider contract and make the application’s trust boundary explicit.

Full answer below

Practice focus

A practical understanding of instruction precedence, untrusted context, and why applications cannot treat every token as equally authoritative.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Overview
Providers expose different message APIs, but the durable design question is which source is allowed to define behavior and which source is only data.
Higher-authority application instructions define the model’s role and constraints, while user instructions describe the current task. Retrieved documents, tool results, and quoted text should normally be treated as data, not as new authority. Exact role names and precedence rules vary by provider, so I follow the provider contract and make the application’s trust boundary explicit.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
For a document assistant, the application instruction might say to answer only from supplied policy text and to report when the answer is missing. The user asks a question, and the policy document is clearly delimited as evidence. If that document contains text such as “ignore previous instructions,” it is still document content. Delimiters help communicate the boundary, but they are not a complete security control.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming every provider implements identical message roles.
Treating retrieved text or tool output as trusted instructions.
Believing XML or Markdown delimiters eliminate prompt injection.
Putting authorization policy only in a system message.

How do system, developer, user, and contextual instructions differ?

Practice focus

Answer path

Overview

Review signals

Follow-up prompts

Continue practice

Go deeper

Tech stacks

Skill areas

Human editorial direction

Was this drill useful?

Found this answer useful?