Stage 6 — System Prompt as Architecture
System prompt is not just “text at the top”, it is an architectural behavior layer.
Stage topics
- How to write system prompt
- Behavior instructions
- Model limitations
- Persistent rules
What system prompt is architecturally
System prompt defines:
- allowed behavior style,
- action boundaries,
- conflict priority rules,
- refusal policy.
It should be a stable contract, not a random wishlist.
How to write system prompt
Practical structure:
- Role and responsibility scope.
- Allowed/forbidden actions.
- Output formats.
- Safety rules.
- Uncertainty behavior.
Persistent rules
Persistent rules are always-on constraints:
- never expose secrets,
- never execute unsafe actions,
- always follow output contract.
They should not depend on a specific user request.
Model limitations
System prompt does not make model omnipotent.
It sets boundaries, but does not replace:
- backend checks,
- authorization,
- output validation.
System prompt as an operating contract
A system prompt should be written like a policy document that the runtime can test indirectly. It should define responsibility, boundaries, and conflict handling before individual user tasks arrive. If the system prompt says “be helpful” but does not define forbidden actions, the model may still produce unsafe help. If it says “be concise” but the workflow needs audit evidence, concision can conflict with compliance.
The useful mental model is layered authority. System rules define the outer boundary. Developer instructions define the workflow. User messages provide task-specific data. Retrieved documents provide evidence, not authority. This hierarchy must be explicit because production failures often come from treating all text as equally important.
| Layer | Controls | Should not control |
|---|---|---|
| System | Safety, identity, global limits | Per-request facts |
| Developer | Workflow rules and output contracts | User's private goal |
| User | Task and user-provided context | Hidden policy |
| Retrieved data | Evidence for claims | Instruction priority |
Stage takeaway
A strong system prompt means controllable behavior at architecture level, not “lucky wording”.
Beginner explanation
A role in a prompt is not decoration. It defines what responsibility the model should take. “You are an assistant” says almost nothing. “You are a technical editor for a learning article; explain to a beginner without jargon and define terms before using them” creates useful behavior. A good role includes responsibility, audience level, and quality criteria.
Context is the factual material the model should use. It may be an article, error log, product requirement, or API field list. If context is missing, the model completes the answer from probabilities. If context is too broad, focus is lost. Therefore context should be selected and labeled: what source it is, whether it is trusted, and how it should be used.
Constraints say what is forbidden or required. Examples: “do not invent API methods”, “say when data is missing”, “return only JSON”. Constraints should be testable. “Do it well” is not testable; “return 5 questions, each with 4 options and exactly one correct=true” is testable.
Mini scenarios from real projects
- Team adds many system rules, but behavior is still unstable: instructions conflict with each other.
- Works on one case but fails on adjacent case: constraints do not define applicability boundaries.
- Different developers interpret “assistant style” differently: behavior criteria are not operationalized.
Fast decision rules
- Write system rules as testable instructions, not generic wishes.
- Every constraint should have a purpose: quality, safety, or predictability.
- Review system prompt regularly and remove outdated/conflicting rules.
Self-check questions
- What distinguishes a strong system prompt from a long wish list?
- How do you detect conflicting instructions inside system rules?
- Which rules should be persistent and which should stay context-specific?