Domain 4 questions rarely ask you to define a technique. They hand you a scenario — a flaky JSON parser, a model that ignores an instruction, a downstream system that must never receive a malformed field — and ask which tool fits. The trap is that several techniques can produce the same output, so surface-level definitions won't separate them. What separates them is the question each one actually answers: am I steering behavior, or guaranteeing structure? am I describing a rule, or enforcing it?
This guide compares six pairs that get confused because they overlap in outcome while differing in mechanism. The through-line is a reliability ladder for getting structured data out of a model. As of the 2026 Anthropic Messages API, that ladder runs: strict tool use / output_config.format (schema-enforced via constrained decoding — strongest) > a non-strict tool schema (model is steered toward the shape but not constrained) > prompt-based "return JSON" prose (weakest — the model may still add prose, wrap in code fences, or drift). Knowing where a technique sits on that ladder answers most Domain 4 comparison questions.
One more mental model runs underneath all six: the difference between asking the model to comply and making compliance impossible to violate. A prompt is a request. A schema is a contract. A hook or a validator outside the model is a gate. When an exam scenario uses words like "must," "guarantee," "never," or "enforce," it is signaling which of those three you need — and it is usually not the prompt. (Note: as of current Claude models — Opus 4.6+, Sonnet 4.6+, and Fable — assistant last-turn prefill returns a 400 and should be treated as legacy; the modern answer for "force the shape" is a schema, not a prefilled {.)
Few-shot examples vs Explicit instructions
Both aim to make the model behave a certain way, so they feel like substitutes. They are not. Explicit instructions describe the rule in prose ("classify sentiment as positive, negative, or neutral; return only the label"). Few-shot examples demonstrate the rule by showing worked input to output pairs and letting the model infer the pattern. Instructions scale to policies that are easy to state but hard to show; examples scale to patterns that are easy to show but awkward to articulate.
| Dimension | Few-shot examples | Explicit instructions |
|---|---|---|
| Purpose | Show the pattern; let the model generalize from cases | State the rule directly in prose |
| Reliability/strength | Strong for format/style/edge-case behavior that is hard to describe | Strong for policies that are simple to state and enforce verbally |
| Best for | Nuanced tone, tricky formatting, ambiguous edge cases, implicit conventions | Clear-cut rules, constraints, ordering, do/don't lists |
| When NOT to use | When the rule is trivially stateable (wastes tokens; examples can over-anchor) | When the behavior is easier to show than to tell (e.g. a subtle output shape) |
Few-shot examples vs JSON Schema (tool use)
This is the single most confused pair in Domain 4 because both can make output look structured. The difference is steering vs guaranteeing. Few-shot examples of JSON nudge the model toward a shape by demonstration — but nothing stops it from adding a stray field, dropping a required one, or wrapping the object in prose. A JSON Schema attached via strict tool use (or output_config.format) constrains generation through constrained decoding: the model literally cannot emit tokens that violate the schema. Examples influence probability; a schema enforces grammar.
| Dimension | Few-shot (example JSON) | JSON Schema (strict tool use) |
|---|---|---|
| Purpose | Steer the model toward a shape by demonstration | Enforce the exact shape via schema-constrained decoding |
| Reliability/strength | Best-effort — shape is likely but not guaranteed | Guaranteed valid against the schema (types, required fields, enums) |
| Best for | Prototyping, loose/variable shapes, showing tone alongside structure | Production payloads a downstream system must parse without failing |
| When NOT to use | Anywhere a malformed field breaks a consumer | When the shape is genuinely open-ended, or you only need a rough format nudge |
Tool use vs JSON output (prompt-based)
Both end in a JSON object, so they read as equivalent. The reliability gap is large. Tool use defines a tool with an input_schema; the model returns arguments validated against that schema (and with strict: true, constrained during decoding). Prompt-based JSON just asks in prose — "return your answer as JSON" — and hopes. The prose approach sits at the bottom of the reliability ladder: the model may emit valid JSON, or wrap it in ```json fences, or prepend "Sure, here's the JSON:", or miss a field under load. Tool use moves the shape from hope to contract.
| Dimension | Tool use (schema) | JSON output (prompt-based) |
|---|---|---|
| Purpose | Get schema-validated arguments the model must fill | Ask the model, in words, to format its answer as JSON |
| Reliability/strength | High — validated; strongest with strict: true / output_config.format | Lowest rung of the ladder — best-effort, drift-prone |
| Best for | Function/agent calls, extraction into a fixed shape, machine-consumed payloads | Quick throwaway scripts, human-in-the-loop output, low-stakes formatting |
| When NOT to use | When you don't actually need structure (adds ceremony) | Any pipeline that parses the output without a human checking it first |
Concrete examples vs Prose specification
When you need the model to hit a specific format, you can either paste a real example of that format or describe it in words. A concrete example anchors the shape unambiguously — the model sees the exact indentation, field order, delimiter, or layout. A prose specification describes it ("a markdown table with three columns, right-aligned numbers") and leaves interpretation room. Prose scales and stays readable; a concrete example removes ambiguity that prose almost always leaves behind. This is the format-level cousin of few-shot vs instructions.
| Dimension | Concrete example | Prose specification |
|---|---|---|
| Purpose | Anchor the exact format with a real, copyable instance | Describe the format and its rules in words |
| Reliability/strength | High for format fidelity — leaves little to interpret | Moderate — precise for rules, looser for exact layout |
| Best for | Exact layouts, delimiters, whitespace, field ordering, sample outputs | General constraints, conditional rules, things with many valid instances |
| When NOT to use | When one example would over-constrain a format that should vary | When the layout has fiddly details prose can't pin down ("...like this") |
Test-driven iteration vs Prompt refinement
Both are ways to make a prompt better over time, which is why they blur. Prompt refinement is ad-hoc: read the bad output, reword the prompt, eyeball the next result, repeat. Test-driven iteration builds a structured evaluation loop — a set of cases with expected outcomes, run automatically, scored, with regressions caught when a change that fixes one case breaks three others. The signal source is the difference: refinement leans on human impression; test-driven iteration leans on measured results and error metadata (which cases failed, how, and whether a change moved the score up or down).
| Dimension | Test-driven iteration | Prompt refinement (ad-hoc) |
|---|---|---|
| Purpose | Improve via a measured eval loop over many cases | Improve by rewording based on the latest output |
| Reliability/strength | High — catches regressions, quantifies change, scales | Low — impression-based, no regression safety net |
| Best for | Anything shipped, reused, or maintained over time | Early exploration, one-off tasks, quick spikes |
| When NOT to use | The absolute first draft, before you know what "good" means | Any prompt whose quality you need to defend or keep stable |
Prompt instructions vs Hooks/programmatic enforcement
This is the deepest distinction in Domain 4, and the one exams love: the difference between asking the model to comply and enforcing the rule outside the model, deterministically. A prompt instruction ("never output a Social Security number," "always include a disclaimer") is a probabilistic request — the model usually obeys, but obedience is not guaranteed and can be perturbed by adversarial input or edge cases. A hook / programmatic enforcement is code that runs outside the model — a validator, a post-processing filter, a schema check, a hook that rejects or rewrites output — and it holds every time, regardless of what the model felt like doing. A must-hold rule cannot live in a prompt, because a prompt has no enforcement mechanism.
| Dimension | Prompt instructions | Hooks / programmatic enforcement |
|---|---|---|
| Purpose | Ask the model to behave a certain way | Enforce the rule deterministically, outside the model |
| Reliability/strength | Probabilistic — usually obeyed, never guaranteed | Deterministic — holds 100% of the time by construction |
| Best for | Soft guidance: tone, style, preferences, defaults | Hard invariants: safety, redaction, schema validity, access control |
| When NOT to use | For any rule that must hold (safety, compliance, data integrity) | For fuzzy/subjective goals code can't cleanly evaluate (tone, helpfulness) |
Key takeaways
- 01Structured-output reliability ladder (top to bottom): strict tool use /
output_config.format> non-strict tool schema > prompt-based "return JSON". Match the rung to how much a malformed field costs. - 02Steering vs guaranteeing: few-shot examples and prose steer toward a shape; a JSON Schema guarantees it via constrained decoding.
- 03A prompt is a request, a schema is a contract, and a hook is a gate — scenarios that say "must," "never," or "guarantee" are asking for a contract or a gate, not a request.
- 04"Should" rules (tone, style, defaults) live in the prompt; "must" rules (safety, redaction, schema validity) live in deterministic code outside the model.
- 05Show vs tell: demonstrate patterns that are hard to describe (few-shot / concrete examples); state rules that are easy to articulate (instructions / prose spec).
- 06Improve prompts with a measured eval loop and error metadata (test-driven iteration), not by eyeballing the latest output (ad-hoc refinement) — that's how regressions get caught.
- 07Assistant last-turn prefill is legacy: it returns a 400 on current Claude models (Opus 4.6+, Sonnet 4.6+, Fable). To force output shape, use a schema, not a prefilled token.
- 08When output 'usually' works but 'occasionally' fails, the fix is almost never more prompt wording — it's climbing the reliability ladder or moving enforcement outside the model.
Common mistakes
Answering "add more/forceful instructions" for a scenario with intermittent malformed output.
Intermittent failure is a reliability-ladder problem. Move to a non-strict tool schema, then to strict tool use / output_config.format — enforcement, not emphasis.
Treating a JSON Schema and a few-shot JSON example as interchangeable ways to get structured output.
Examples steer (best-effort); a schema guarantees (constrained decoding). Use the schema whenever a downstream consumer must not receive a malformed field.
Putting a must-hold rule (redaction, safety, valid schema) in the prompt as a strong instruction.
Prompts are probabilistic. Enforce hard invariants in code outside the model — a hook, validator, or schema check that holds every time.
Iterating on a prompt by rewording and eyeballing the next result.
Build an evaluation suite with expected outcomes; measure each change and watch for regressions. Impression-based tuning silently breaks previously-working cases.
Reaching for assistant prefill (a prefilled {) to force JSON output.
Prefill on the last assistant turn now returns a 400 on current Claude models. Use output_config.format or a strict tool schema instead.
Frequently asked
Is prompt-based "return JSON" ever the right answer on the exam?
Only when the output is reviewed by a human or the cost of a malformed response is near zero — quick scripts, exploration, low-stakes formatting. The moment a program parses the output unattended, the reliability ladder says use a tool schema (strongest with strict: true or output_config.format).
How do I quickly tell a 'steering' technique from a 'guaranteeing' one?
Ask what stops a bad output. If the answer is "the model probably won't" (few-shot, prose spec, concrete example, prompt instruction), it's steering. If the answer is "the mechanism physically can't produce it" (constrained decoding from a schema, or a validator outside the model), it's guaranteeing. Scenarios with 'must,' 'never,' or 'guarantee' need the second kind.
Why can't a strongly-worded instruction enforce a must-hold rule?
A prompt is a request the model complies with probabilistically. Even CRITICAL: you MUST never... can be missed under edge cases or adversarial input. Deterministic guarantees require enforcement outside the model — a hook, filter, schema, or validator that runs regardless of what the model generated.
Few-shot examples vs explicit instructions — is one strictly better?
No; they answer different questions. Tell (instructions) when the rule is easy to state; show (few-shot) when the pattern is easier to demonstrate than describe. Strong prompts frequently do both. It only becomes a wrong answer when you use examples to try to guarantee structure — that's a schema's job.
Is assistant prefill still a valid technique for shaping output?
Treat it as legacy. On current Claude models (Opus 4.6+, Sonnet 4.6+, and Fable), a prefilled last assistant turn returns a 400. The modern, higher-reliability replacements are output_config.format for response shape and strict tool use for validated arguments.
Independent, unofficial study material. Not affiliated with, endorsed by, or authorized by Anthropic. Every example is original and written to teach the public exam objectives — no real exam questions are reproduced. Technical details reflect Claude, the Anthropic API, Claude Code, and MCP as of July 25, 2026; always confirm specifics against current official documentation.
Test yourself
Turn what you just read into answers you can check.