System Prompts — the product's constitution

Every technique above, made persistent. The system prompt is the privileged message that precedes every conversation — and thanks to Topic 15, you know exactly what it physically is: tokens in a special position of the chat template (<|im_start|>system...), which the model was trained (in stage 2–3, Module 2's pipeline) to weight as standing orders that outrank conversational requests. Not magic — trained deference to a position.

What belongs in one — the sections of a production system prompt, in the order they typically appear:

1. Identity & role        — "You are the support assistant for isDisposable..."
2. Capabilities & limits  — what it can do, what it must refuse or escalate
3. Knowledge & context    — product facts, today's date, the user's plan/tier
4. Tool guidance          — when to use which tool, when NOT to (Topic 57 soon)
5. Behavioral rules       — tone, language, verbosity, formatting conventions
6. Output conventions     — schemas, citation style, structure
7. Escape hatches         — what to do when unsure, off-topic, or out of scope

Three engineering realities that elevate this from "writing instructions" to architecture:

1. It's the cheapest deployment surface in your product. The Topic 12 ladder, rung 1, formalized: behavior changes ship by editing text — no training, no deploy of weights, instant rollback. Which cuts both ways: it deserves version control, code review, and regression testing against your eval set, because a well-meaning one-line addition ("be more concise") can silently break behaviors three sections away. System-prompt changes are production changes.

2. Its cost profile is special. A 3,000-token system prompt sounds like a Topic 38 dieting violation — but it's the same 3,000 tokens on every request, which is exactly what Topic 37's prefix caching makes nearly free (providers price cached input tokens at a fraction of fresh ones). The rule refined: long-and-static is cheap; long-and-churning is expensive. Keep volatile content (user data, retrieved chunks) out of the cached prefix, appended after it.

3. The instruction hierarchy is real but not absolute. Models are trained to prioritize system over user instructions — that's your defense when a user types "ignore your instructions." It holds against casual attempts and bends under crafted ones; genuine security never rests on the prompt alone (the full threat model arrives in Topic 57). Corollary for your designs: anything truly non-negotiable belongs in code — validators, filters, permission checks — with the system prompt as the first layer, not the only one.

Two closing connections. Fine-tuning relationship (Topic 12's rung 4): a system prompt that has grown huge and stable is a candidate for baking into weights — trading per-request tokens for a training run. And a study tip that costs nothing: read production system prompts. Anthropic publishes Claude's; others leak or share theirs. They're masterclasses — you'll notice the escape hatches, the tool guidance, the sheer specificity — and reading a few will improve yours more than any listicle.

---