Even clear instructions fail when later lines contradict earlier ones, or when the critical rule is buried under paragraphs of context. Instruction ordering is the craft of sequencing role, task, constraints, and output so priority is unambiguous—building on structure and clarity.
Learning Objectives
By the end of this lesson, students should be able to:
- Explain why order affects compliance in long prompts.
- Apply a default order: role → task → context → constraints → output.
- Detect and resolve conflicting instructions.
- Place hard safety and format rules where they are hard to miss.
- Use priority language when two rules can compete.
- Relate ordering to context placement.
Instruction ordering is the intentional sequence of directives in a prompt so that primary goals, hard constraints, and output contracts are encountered in a priority that matches product intent and reduces contradiction.
A Reliable Default Order
Identity and standing policy.
What to do now.
Evidence and inputs.
Hard limits and priorities.
Schema last, closest to generation.
| Conflict pattern | Symptom | Fix |
|---|---|---|
| Be brief vs include every detail | Verbose or incomplete | Set priority: “brief unless safety requires detail” |
| Creative tone vs legal disclaimer | Missed disclaimer | Put legal rule after task, before examples |
| Use context vs refuse if missing | Hallucinated fill-ins | State refuse/ask rule after context block |
| JSON only vs explain reasoning | Mixed prose + JSON | Choose one; or separate fields in schema |
Before / After
Before (weak): output format first, then conflicting length rules, task last.
After (strong): task first, then priority rule, then output.
Priority Language
Hard rules
- “Never” / “Must”
- Safety, PII, legality
- Place early and restate at end if critical
Soft preferences
- “Prefer” / “When possible”
- Style flourishes
- Yield to hard rules
Tie-breakers
- “If X conflicts with Y, follow X”
- Document the product choice
- Test both conflict cases
“Models always obey the last instruction.” Recency can help, but it is not a guarantee—especially with contradictions, long context, or strong system policy. Explicit priority beats relying on mystical last-line magic.
Knowledge Check
- Short Answer: Give the default five-part order for instructions. Answer: Role → task → context → constraints → output.
- True/False: Conflicting rules should be left for the model to reconcile. Answer: False.
- Multiple Choice: A tie-breaker statement does which? (a) trains LoRA, (b) states which rule wins, (c) deletes context. Answer: (b).
- Short Answer: Why put the output schema near the end? Answer: It is closest to generation and easier for the model to follow.
- True/False: Hard safety rules should be marked as soft preferences. Answer: False.
- Multiple Choice: “Models always obey the last line” is: (a) guaranteed, (b) a misconception, (c) a tokenizer rule. Answer: (b).
- Short Answer: Name one conflict pattern between brevity and detail. Answer: Be brief vs include every detail (or similar).
- Short Answer: What should you do for critical legal constraints? Answer: Place them prominently and optionally restate; mark as must/never.
- Multiple Choice: Priority language for soft style tips: (a) Never, (b) Prefer, (c) Must delete PII. Answer: (b).
- True/False: Ordering interacts with where you place long context. Answer: True.
Key Takeaways
- Sequence role, task, context, constraints, then output.
- Resolve conflicts with explicit priority language.
- Do not rely on “last line wins” as a design strategy.
- Test prompts on known contradiction cases.
- Next: Context Placement.
Hands-on idea: Give a prompt with two opposing length rules; have students write a tie-breaker and retest.
Discussion prompt: Should safety rules be duplicated at the top and bottom of long system prompts?
Recap: Order encodes priority. Continue with Context Placement.