What You Inherit
Lesson 1 of 3 in In Production: What Alignment Does and Doesn’t Guarantee.
You never deploy “a model.” You deploy a model plus everything its maker trained into it after pre-training — and this domain has shown you exactly what that is. SFT taught it the Chat template and its formatting habits. Preference training (RLHF or DPO) taught it what kind of answer to prefer: how long, how hedged, how organized. Safety training taught it where to refuse. Reasoning training, where applied, taught it when to think longer. None of that lives in your code. All of it arrives with the Weights.
Call this the behavior profile: the set of dispositions a post-trained model brings to every request before you write a single line of prompt. In production it shows up as concrete, sometimes surprising defaults —
- Format habits. Some models reach for markdown headers and bullet lists unprompted; some default to flowing prose; some wrap answers in preamble (“Great question!”) or trailing summaries. That is Instruction tuning data showing through.
- Refusal boundaries. Each vendor drew different lines, with different training data and different annotator guidelines. The same borderline request can sail through one model and be declined by another.
- Persona and tone. Warm or clipped, first-person or impersonal, apologetic or direct — a trained disposition, not a runtime setting.
- Verbosity. Preference training tends to reward thorough-looking answers, so many assistants run long by default. Verbosity is also a cost: output tokens are the ones you pay most for and wait longest for.
| Dimension | Set by | Steerable by prompt? | What that means for you |
|---|---|---|---|
Output format habits | SFT demonstrations + preference training | Largely yes — explicit format instructions and examples work well | Specify format every time; never rely on the default surviving a model swap |
Verbosity | Preference training (length correlates with preferred answers) | Partly — “be concise” helps but drifts back over long conversations | Verbosity is a token bill; measure output length per model, not per prompt |
Persona and tone | SFT + preference training + vendor persona work | Partly — you can layer a persona on top; the trained one shows through under stress | Test tone on hard cases (complaints, refusals), not happy paths |
Refusal boundaries | Safety-focused preference training and related methods (e.g. constitutional AI) | Mostly no — you can add refusals via instructions; removing trained ones is unreliable by design | Map where the boundary sits on your domain before you commit |
Instruction-following priority | Instruction tuning — including that system messages outrank user turns | No — this is the mechanism prompts rely on, not one they can rewrite | How firmly system beats user varies by model; probe it, it is your first defense layer |
Reasoning effort | Reasoning training, where the vendor applied it | Partly — “think step by step” or effort controls where exposed | Longer Chain-of-thought (CoT) means more latency and more tokens; budget for it |
Read that table as a division of power. The right-hand column is yours; the left two belong to whoever ran post-training. When two models answer the same prompt differently — one in bullets, one in prose; one declining, one complying — you are not seeing noise. You are seeing two different post-training runs, two different Preference data sets, two different annotator guidelines. A model swap is a behavior-profile swap, even when the Benchmark scores look interchangeable — capability numbers say little about format habits or refusal boundaries.
Why a prompt cannot retrain the model
At inference time the Weights are frozen; the only thing you control is the context. Conditioning on different tokens moves the model to a different region of its learned distribution — it never changes the distribution itself. Post-training already decided how responsive each behavior is to context: instruction-following works because SFT and preference training rewarded following instructions, and system-over-user priority works because training examples encoded it. Prompts pull levers that training installed.
Two mechanisms limit how far the levers reach. First, preference optimization deliberately narrows the policy: RLHF-style training (typically with a KL penalty to a reference model) concentrates probability mass on response styles the reward preferred, so behaviors the training pushed away from — complying with flagged requests, dropping all hedging — sit in low-probability territory that ordinary instructions rarely recover. Second, trained dispositions are context-sensitive statistics, not rules: push a prompt far from the training distribution and behavior gets less predictable, not more obedient. That cuts both ways — it is why exotic prompts sometimes bypass safety training (next lesson), and why your carefully engineered persona can wobble on inputs unlike anything in your test set.
The honest summary: prompting chooses where in the trained distribution you operate. Only training moves the distribution — which is why the Adapting LLMs domain treats fine-tuning as the next rung when prompting plateaus.
In production
On managed platforms, the behavior profile is invisible in the console and everywhere in production: every hosted model arrives with its own post-training, and the platform gives you conditioning knobs, not training knobs.
AWS
Amazon Bedrock hosts models from multiple providers behind one API, which makes profile differences easy to feel: the same request routed to a different model family returns different formats, refusal choices, and lengths, because each provider ran its own post-training. The system-prompt field and inference parameters shape sampling and conditioning only — swapping the model ID is the act that swaps the trained profile.
Azure
Azure AI Foundry separates the model catalog from your deployment configuration: the catalog entry carries the trained behavior profile, while your deployment carries the system message and parameters that steer it. Two deployments of different models with an identical system message are not interchangeable — the message conditions two different trained policies and lands differently on each.
Google Cloud
Vertex AI exposes system instructions as a first-class request field alongside a Model Garden of differently post-trained models. The mechanism to internalize: system instructions ride the request, so they steer per call, while the profile rides the checkpoint — a Model Garden choice is a post-training choice, and instructions tuned for one model need re-testing on the next.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.