Domain 4 · 20% of exam

Prompt Engineering & Structured Output glossary

43 terms drawn from this domain’s 6 lessons and the sources they cite. A term that matters in more than one domain appears on each of their pages.

The full glossary is searchable across all five domains, and the domain curriculum explains where each term is used.

Attention dilution: The failure mode where an agent processing too many items in one pass gives thorough analysis to the first few and skims the rest, flagging a pattern in one file while approving identical code in another. The fix is a multi-pass architecture — a dedicated local analysis pass per item so each gets the full attention budget, then a separate cross-item integration pass — not a bigger context window, because the problem is attention quality rather than context capacity.
Batch lifecycle: A batch begins processing immediately and its `processing_status` moves through `in_progress`, `canceling`, and `ended`; poll until it ends. Every request then resolves to one of four result types — `succeeded`, `errored`, `canceled`, or `expired` — and only `succeeded` is billed, so a stalled or cancelled batch costs nothing for work that never ran. platform.claude.com › creating-message-batches
Batch request constraints: A batch is capped at 100,000 requests or 256 MB, whichever comes first, with an oversized batch returning 413 `request_too_large`. Almost any Messages API request can be batched, but `stream: true` and the stateful Threads parameters `store`/`previous_thread_event_id` are rejected. Parameter validation is asynchronous, surfacing only after the batch ends — so dry-run one request against the synchronous API first. platform.claude.com › batch-processing
Batch results retrieval: Results appear as a `.jsonl` file at `results_url`, populated only once the batch has ended, in no guaranteed order. Stream them rather than bulk-downloading, and note the 29-day availability window runs from `created_at`, not from `ended_at`. platform.claude.com › batch-processing
Batch SLA calculation: Work backwards from the 24-hour maximum: a 30-hour SLA leaves 6 hours of buffer, so the final batch must be submitted at least 30 hours before the deadline and batches submitted every few hours keep one always in flight.
Batch tool-calling limitation: A batch request cannot execute a client tool and continue the same logical turn, because threads are stateful and batch requests are not. Server tools do run their full agentic loop inside the batch worker, but a result returning `pause_turn` needs a new follow-up request to continue. Anything needing mid-turn client tool execution belongs on the synchronous API. platform.claude.com › batch-processing
Batch vs synchronous: Blocking workflows — pre-merge CI checks, real-time review feedback, anything a developer waits on — stay on the synchronous API. Latency-tolerant workflows — overnight technical debt reports, weekly audits, nightly test generation — move to the Batch API for the 50% saving. Moving everything to batch for the savings is the exam's classic wrong answer.
Calibration: Mapping reported confidence to actual accuracy by running labelled validation sets — data where the answer is already known — through the system, then setting routing thresholds from the result. Judge whether the correct final state was reached rather than whether a specific process was followed, and keep manual testing, which catches edge cases evals miss.
Confidence-based routing: Reporting high-confidence findings directly and routing low-confidence ones to human review. Raw self-reported confidence is uncalibrated — a form of the model judging itself — so it is unfit for automated decisions until thresholds are calibrated, and it is never a substitute for explicit criteria defining what counts as a valid finding.
Context rot: The documented phenomenon that accuracy and recall degrade as token count grows, which makes curating what is in context as important as how much space there is. Context is a finite resource with diminishing marginal returns — the model draws on a limited attention budget that every added token depletes. platform.claude.com › context-windows
custom_id: The per-request identifier in a batch, matching `^[a-zA-Z0-9_-]{1,64}$`. Results can come back in any order, so always match results to requests by `custom_id` and never by position. platform.claude.com › batch-processing
detected_pattern: A field on a structured finding that tags which specific construct triggered it, so dismissal rates can be analysed by pattern. When one pattern is dismissed consistently the documented fix is a formal rule or prompt refinement for that pattern — not another retry. claude.com › building-agents-with-the-claude-agent-sdk
Duplicated-work failure: The delegation failure where vague per-subagent task descriptions cause two agents to research the same topic while another goes uncovered. The fix is to give each subagent an objective, an output format, guidance on tools and sources, and clear task boundaries. anthropic.com › multi-agent-research-system
enum: The JSON Schema field restricting a value to a fixed set of labels. For classification tasks the documented advice is to use a tool with an `enum` field of valid labels, or structured outputs, rather than asking for a category in prose — few-shot examples teach which label is right, the enum guarantees only defined labels can be emitted. platform.claude.com › claude-prompting-best-practices
Evaluation rubric: The criteria an LLM judge scores against, in Anthropic's documented case factual accuracy, citation accuracy, completeness, source quality, and tool efficiency. The shape that proved most consistent was a single call with a single prompt outputting a 0.0-1.0 score plus a pass/fail grade, run against roughly 20 representative queries — enough to see the impact of a change. anthropic.com › multi-agent-research-system
Examples with reasoning: Each few-shot example must show the input, the output, and why that decision was chosen over plausible alternatives. Examples without reasoning teach literal pattern-matching; examples with reasoning teach the generalisable decision principle.
Explicit categorical criteria: Prompt criteria that state precisely what to flag and what to skip — bugs and security vulnerabilities in, minor style preferences out — instead of vague instructions such as "be conservative" or "only report high-confidence findings". Severity levels must be defined with concrete code examples per level, never prose descriptions, or the model has to interpret what the level means.
False-positive trust problem: A high false-positive rate in one finding category destroys developer trust in every category, even ones running at high accuracy. The counter-intuitive fix is to temporarily disable the noisy category, refine it against concrete examples, and re-enable it once precision improves — putting system-wide trust ahead of category completeness.
Few-shot examples: The most effective technique for consistent output, and the right answer when detailed instructions still produce inconsistent formatting, inconsistent judgement on ambiguous cases, or empty fields for data that is present in an unusual format. Use 2-4 targeted, diverse examples: fewer than two establishes no pattern, more than four wastes tokens and risks context rot. anthropic.com › effective-context-engineering-for-ai-agents
Forced-selection prefill: With `tool_choice` set to `any` or `tool`, the API prefills the assistant message to force a tool call, so the model emits no natural-language response or explanation before the `tool_use` blocks even if explicitly asked. Any field logging Claude's pre-call reasoning will be empty. platform.claude.com › define-tools
Independent review instance: A separate Claude invocation with no access to the generating session's reasoning, so it judges the output on what it sees alone. A reviewer in a fresh context sees only the diff and the criteria, never the justification that produced the change — the strongest form goes further and tries to refute the result rather than re-confirm it. code.claude.com › best-practices
is_error: The optional boolean on a `tool_result` block that signals a client-tool execution failure; return the error text as `content` with `"is_error": true` and Claude incorporates it into its response. Server-tool errors are handled transparently by Anthropic's infrastructure and are not your responsibility. platform.claude.com › handle-tool-calls
Malformed-call retry: Claude's own model-level behaviour: when its tool call is invalid or missing required parameters, it retries 2-3 times with corrections before apologising to the user. This is a separate mechanism from `isRetryable`, which applies after your tool has run and failed. platform.claude.com › handle-tool-calls
max_tokens: An absolute ceiling on generated output, not a target — the model may stop earlier, so a short result is not evidence that your criteria suppressed output. Exceeding it produces `stop_reason: "max_tokens"`, handled by raising the limit or continuing the response. platform.claude.com › messages
Message Batches API: The asynchronous API charging 50% of standard prices unconditionally. Most batches finish in under an hour but the maximum processing window is a hard 24 hours with no latency guarantee — processing slows under demand — so design for the worst case, not the common one. platform.claude.com › batch-processing
Optional/nullable fields: The primary schema-level defence against fabrication: if a field is required, the model is pressured to invent a value when the source has none; if it is nullable, it can honestly return `null`. Related patterns are an explicit `"unclear"` enum value for genuinely ambiguous sources, and an `"other"` value paired with a freeform detail string.
pause_turn: The `stop_reason` returned when a long-running server-tool turn is paused, typically because a server-tool loop hit its internal iteration limit. Handle it by appending the assistant response to `messages` and re-requesting unchanged — never by treating the turn as done. platform.claude.com › handling-stop-reasons
Prefill: The retired workaround of pre-writing part of the assistant turn to force JSON or YAML output. Its documented successor is the Structured Outputs feature, and from Claude 4.6 and Mythos Preview a prefilled last assistant turn returns a 400 error. The API's own prefill under `tool_choice` `any`/`tool` is a different mechanism and still active. platform.claude.com › claude-prompting-best-practices
Retry effectiveness boundary: Retries fix format mismatches, structural errors, misplaced values, and missed line items — anything the model can correct by re-examining information it already has. They cannot produce information genuinely absent from the source document; that extraction is flagged for human review or returned as null, not retried again.
Retry-with-error-feedback: The correct retry shape: send back the original document, the failed extraction, and the specific validation error — for example "line items sum to £450 but stated_total is £500". A naive retry without the specific error usually reproduces the same mistake.
Right altitude: The Goldilocks zone criteria should sit in, between two named failure modes: hardcoded brittle if/else logic, which creates fragility and maintenance cost, and vague high-level guidance, which gives the model no concrete signal. The goal is the minimal set of information that fully outlines expected behaviour — good heuristics plus explicit guardrails, not a laundry list of edge cases. anthropic.com › effective-context-engineering-for-ai-agents
Rules-based feedback: The documented best form of feedback: clearly defined rules for an output, plus which rule failed and why — code linting is the canonical example. The documented weakest is LLM-as-judge, described as "generally not a very robust method" with heavy latency tradeoffs. claude.com › building-agents-with-the-claude-agent-sdk
Self-correction schema fields: Schema fields that make discrepancies visible without external logic: `calculated_total` alongside `stated_total` with a `total_discrepancy` flag when they differ, and `conflict_detected` booleans marking a source that contradicts itself rather than silently picking one value.
Semantic errors vs syntax errors: `tool_use` with JSON schemas eliminates syntax errors — malformed JSON, missing fields, wrong types — but not semantic ones: line items that do not sum to the stated total, values placed in the wrong fields, or fabricated values. Semantic errors need validation logic and retry loops outside the schema.
strict: true: The tool-definition flag enabling schema validation of tool inputs. `tool_choice: "any"` alone guarantees only that a tool is called; combining it with `strict: true` guarantees both that a tool is called and that its input strictly follows your schema. platform.claude.com › implement-tool-use
Structured output reliability hierarchy: `tool_use` with JSON schemas above prompt-based JSON. The tool's schema constrains the shape of what Claude returns, eliminating syntax errors such as missing brackets, trailing commas, and unquoted keys; asking for JSON in a text response gives no structural guarantee and will periodically produce unparseable output.
Structured Outputs feature: A separate, newer mechanism from tool use: `output_config.format` constrains a plain JSON response through constrained decoding, with no tool call needed. It is generally available on Claude 4.5 and later. The first use of a schema costs extra latency while the grammar compiles; compiled grammars are cached for 24 hours from last use, and the feature adds a hidden system prompt that slightly raises input tokens on every call. platform.claude.com › structured-outputs
Structured-output schema constraints: The constrained-decoding grammar supports the basic types plus `enum` (strings, numbers, booleans, nulls only), `required`, and `additionalProperties`, which must be set to `false` for objects — any other value is rejected. Not supported: recursive schemas, external `$ref`, numerical constraints (`minimum`, `maximum`, `multipleOf`), and string constraints (`minLength`, `maxLength`). platform.claude.com › structured-outputs
Subagent context isolation: A subagent's context window starts fresh with no parent conversation; the only content crossing the boundary is the Agent tool's prompt string. Intermediate tool calls and results stay inside the subagent, so heavy exploration never accumulates in the coordinator's context. code.claude.com › subagents
system (parameter): The top-level request parameter where a system prompt lives, alongside `model`, `messages`, and `max_tokens`. There is no `"system"` role in the Messages API, and appending criteria as an extra user message does not create the separation you might expect — consecutive same-role messages are combined into a single turn rather than rejected. platform.claude.com › messages
temperature: The amount of randomness injected into the response: default `1.0`, range `0.0`–`1.0`, with values closer to `0.0` for analytical work. Even at `0.0` results are not fully deterministic, so it is not a precision control — lowering it cannot invent a decision boundary the prompt never defined. platform.claude.com › messages
tool_choice: The parameter controlling how the model interacts with tools, with four documented types: `auto` (model decides; default when `tools` are provided), `any` (must call some tool, chooses which), `tool` (must call the named tool), and `none` (may not call any tool; default when no `tools` are provided). platform.claude.com › messages
Writer/Reviewer pattern: Session A implements, a second independent session reviews, and Session A then addresses the feedback. The same split works for tests, with one Claude writing tests and another writing code to pass them. Its documented basis: a fresh context improves code review since Claude will not be biased toward code it just wrote. code.claude.com › best-practices