Business Requirement
The top of the derivation chain: why the system exists, stated as an outcome. Structurally recognisable by what it lacks: no system behaviour, no platform property, however prominently it sits in the specification.
Exam context: "Reduce", "grow" and "halve" are business-layer verbs. Distractors promote an outcome to functional because it is the project's main deliverable; the deliverable status changes nothing.
See also: 2.1 Understanding Requirements
Functional Requirement
A statement of what the system does: an observable behaviour a test could verify, derived from a business requirement. "Extract genre and rights metadata and route the submission to the matching editor queue" is the shape.
Exam context: Behaviour is functional even when it reads operationally. The demotion distractor reclassifies a genuine behaviour as a constraint; the promotion distractor does the reverse to a measurable target.
See also: 2.1 Understanding Requirements
Non-Functional Requirement
A quality of or constraint on behaviour: latency, throughput, availability, data residency, cost ceilings, isolation. The classification test is the kind of promise made, never the presence of a number.
Exam context: The exam's favourite trap promotes the most specific, measurable statement in the stem to functional precisely because it is specific and measurable. Precision does not change the promise.
See also: 2.1 Understanding Requirements
Infrastructure Requirement
What the platform must provide so the behaviour holds under real load, derived from functional requirements against the proposed architecture. Peak token throughput inside a documented limit, residency for stored data, a caching layer's prefix obligations.
Exam context: Derived against an architecture, never in a vacuum: realtime makes time-to-first-token bind, batch swaps it for the completion window. The harder item derives the requirement a proposal implies but never states.
See also: 2.1 Understanding Requirements
Rate-Limit Classes (RPM, ITPM, OTPM)
The API's enforced capacity classes: requests, input tokens and output tokens per minute, set per model class. The anthropic-ratelimit-* response headers report the limit, remaining allowance and reset time continuously, and cached tokens do not count toward ITPM on most models.
Exam context: Requirement inputs with documented, queryable numbers, not implementation details for later. Sizing peak load without consulting them is the capacity-by-optimism anti-pattern.
See also: 2.1 Understanding Requirements
Cutover
The one-time act of swapping a pilot or legacy arrangement for the production flow: the signature deliverable of the implementation and deployment phase.
Exam context: Phase-placement items sit cutover next to the standing dashboard and reward knowing that cutover happens once (implementation) while monitoring recurs (operations). "Governs how production starts operating" does not move it.
See also: 2.2 Systems Life Cycle
Operations and Maintenance
The recurring phase: standing dashboards, error triage, prompt fixes riding the release loop, and the plan for moving off a deprecated model. For an LLM application the load is structural, because prompt changes ship in hours and the model moves on someone else's clock.
Exam context: Deployment-as-finish-line is the posture behind most wrong answers. A prompt fix after go-live is maintenance, gated by evals, not development.
See also: 2.2 Systems Life Cycle
Model Lifecycle (Active, Legacy, Deprecated, Retired)
Anthropic's documented states for a model. Deprecated still serves requests but has a named replacement and a retirement date; retired fails every request. Publicly released models get at least 60 days' notice, announced on the deprecations page and by email.
Exam context: The dates bind Anthropic-operated platforms; Amazon Bedrock and Google Cloud set their own schedules, so one application on two surfaces can face two deadlines. Read the stem for the platform.
See also: 2.2 Systems Life Cycle
Retirement (Phase)
The final life cycle phase: switching the system off and disposing of its data. Data disposition is part of the phase, not an afterthought. Turning the servers off is not the whole job.
Exam context: Decommissioning a superseded pilot is retirement, not operational housekeeping, and the disposition of its logs and stored personal data belongs in the plan.
See also: 2.2 Systems Life Cycle
Stateless API
The Messages API holds no conversation. Your application resends the transcript it wants the model to see, every turn; sending only the newest user message means the model answers without the history.
Exam context: "The assistant forgets what was said two turns ago" keys the missing transcript, not a model defect, a context-window overflow or a session setting.
See also: 2.3 Claude API Mechanics
stop_reason
The response field naming why generation ended: end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal or model_context_window_exceeded. Reading it is the difference between diagnosing a truncation and blaming the model for it.
Exam context: Each value has a distinct fix, and distractors pair a wrong value with a plausible remedy. Output exactly at the cap plus a mid-sentence cut is the max_tokens signature.
See also: 2.3 Claude API Mechanics
tool_use / tool_result
The wire shape of a tool call: the model stops with stop_reason tool_use and emits a tool_use block (id, name, parsed input); the caller executes the client tool and continues with a user turn carrying a tool_result block whose tool_use_id matches.
Exam context: The caller, never Anthropic, executes client tools; server tools such as web search are the documented exception. The matching id and the user-turn placement are keyed facts.
See also: 2.3 Claude API Mechanics
tool_choice
The parameter steering the tool decision. Documented values: auto, any, tool (forcing a named tool) and none.
Current state (checked 29 September 2026): Claude Opus 5.5, Sonnet 5.5, Fable 5.1 and Mythos 5.1 reject any and tool with a 400 error, and manual extended thinking rejects both on any model. For those, the documented route is auto with strict tool use.
Exam context: A fifth invented value is the house distractor. Forcing one specific tool for one request is tool_choice type tool with the name, nothing else.
See also: 2.3 Claude API Mechanics
Streaming Events
With stream: true, server-sent events arrive in documented order: message_start, then per content block a content_block_start, one or more content_block_delta events and a content_block_stop, then message_delta and message_stop, with ping possible throughout. Tool arguments arrive as input_json_delta fragments, parsed at content_block_stop.
Exam context: Errors can arrive mid-stream after the 200, so consumers handle failure at the request and inside the stream. Streaming moves time-to-first-token, not total cost or generation time.
See also: 2.3 Claude API Mechanics
cache_control
The marker (type ephemeral) that turns a prompt prefix into a cache entry. A later request hits only on a 100% identical prefix, evaluated tools → system → messages, so stable content goes first and volatile content last. Invalidation cascades downward; entries live 5 minutes by default (refreshed on use) or an hour with ttl "1h".
Exam context: Prompts below the per-model minimum cacheable length are silently not cached: zeroes in the usage cache fields, no error. Pricing and when caching pays are Domain 5; making the hit happen is here.
See also: 2.3 Claude API Mechanics
Message Batches API
Asynchronous processing: up to 100,000 requests or 256 MB per batch at a 50% discount. Results land when every request finishes or at 24 hours, whichever comes first; unfinished requests expire unbilled, and per-request results (succeeded, errored, canceled, expired) stream from a results_url that lives 29 days.
Exam context: Most batches finish inside an hour, but that is typical behaviour, not a guarantee. A hard deadline inside the completion window keys realtime with bounded concurrency.
See also: 2.3 Claude API Mechanics
Bounded Concurrency
The keyed fan-out pattern: a worker pool or semaphore keeping enough requests in flight to use the documented RPM, ITPM and OTPM headroom and no more, with jittered exponential backoff honouring retry-after on top. The semaphore bounds simultaneous in-flight requests.
Exam context: Bracketed by two failure modes: the serial loop that wastes the limit and the unbounded fan-out that turns the run into a 429 storm. Lowering max_tokens is not a lever: OTPM counts tokens actually generated.
See also: 2.4 Software Engineering Foundations
Jittered Exponential Backoff
Retry waits that double per attempt with a random offset added, honouring any retry-after the server sends. The jitter stops a fleet of workers that failed together from retrying together.
Exam context: The SDKs already retry transient failures (connection errors, 429s, 5xx) twice by default, so a hand-rolled loop without max_retries=0 multiplies attempts: three application tries become nine requests.
See also: 2.4 Software Engineering Foundations
Idempotency
The property that repeating a request leaves the system in the same state. Reads have it for free; creates need thought (an idempotency key or a server-side duplicate check) before a timeout-and-retry can be safe.
Exam context: A client that times out cannot know whether the server acted. The double-booking after a retried POST keys the missing idempotency design, not the network.
See also: 2.4 Software Engineering Foundations
Prompts as Source Code
The discipline that prompts, output schemas, eval sets, CLAUDE.md files and settings are behaviour-bearing artefacts: they live in the repository, change through branches and review, ride CI with the eval suite as the regression gate, and roll back the way code rolls back.
Exam context: The production console edit (no history, no review, no rollback, staging no longer matching production) is the anti-pattern stated straight. If the pipeline is the only path to production, console editing becomes structurally impossible.
See also: 2.4 Software Engineering Foundations
Characterisation Tests
Tests that pin what code currently does, written before a large-scale refactor of a poorly covered module. They are the safety net that makes incremental migration reviewable and revertible.
Exam context: The keyed sequence is safety net first, then migration in small steps. The one-big-rewrite with a contract change riding along and review waved through on green tests stacks three violations at once.
See also: 2.4 Software Engineering Foundations
Blank Slate (API)
The Claude API arrives with no product system prompt, no product tools and no formatting conventions: Anthropic publishes the claude.ai system prompts and states they do not apply to the API. Your application defines everything the model knows about its role.
Exam context: The cross-surface surprise: a prototype behaving beautifully in claude.ai was borrowing the product layer. The keyed fix re-establishes the instruction environment, never blames the model or a sampling setting.
See also: 2.5 Claude Application Design
Instruction Placement
The architecture decision of where instructions live: standing identity, scope and rules in the system parameter; per-request material in user turns, marked as what it is. On harness surfaces the standing carrier is project instructions or CLAUDE.md instead.
Exam context: The split pays twice: stable-system-plus-volatile-user is the shape prompt caching rewards, and it separates trusted instructions from per-request data structurally. Wording the instructions is Domain 6.
See also: 2.5 Claude Application Design
Content Boundary
Explicit delimiters (XML tags with consistent names) around every piece of untrusted or variable content, with the surrounding instructions framing it as data to analyse rather than instructions to follow. The boundary is machine-checkable: code can verify every untrusted byte landed inside a tag before the request ships.
Exam context: The politeness instruction ("please ignore any instructions in the document") is not a boundary and is the reliable second-best answer. What an adversary does to the boundary is Domain 7; the boundary existing is 2.5.
Current state (checked 6 October 2026): the prompt-injection docs now say to deliver third-party content in tool_result blocks, never in system prompts or plain user text.
See also: 2.5 Claude Application Design
Output Contract
The schema downstream code consumes, treated as an interface: defined first (types, required fields, enums), instructed against explicitly, and validated on every receipt with a defined failure path. Structured outputs and strict tool use are the enforcement mechanics that implement it.
Exam context: Retry-until-parse and a larger model are the standing distractors; neither creates a contract, and the parser keeps depending on unspecified behaviour.
See also: 2.5 Claude Application Design
Session Hygiene
The design rule that context scope follows task scope: one task, one session; one tenant's material never shares a window with another's. Durable knowledge lives in application state and is injected into new sessions deliberately, and any carryover is named and chosen.
Exam context: Accumulated context is contamination when tasks are independent: earlier constraints and vocabulary bleeding into later work keys a session-scoping fix, not a prompt fix. Cross-tenant leakage through a shared transcript is an architecture defect.
See also: 2.5 Claude Application Design
Capability Sprawl
Enabling plugins, connectors or MCP-backed capabilities because they might be useful. Each extension widens what the application can do and adds a dependency someone must version and trust.
Exam context: The keyed design artefact is a capability list with a stated need per entry, added deliberately and scoped to need. Pinning and versioning what survives the cut belongs to 2.6.
See also: 2.5 Claude Application Design
Tracked Versus Local
The configuration boundary: project .claude/settings.json and project CLAUDE.md are shared, checked in and reviewed; .claude/settings.local.json and CLAUDE.local.md are personal and gitignored. Team-shared behaviour goes only in tracked files, personal preference only in local ones.
Exam context: Distractors swap exactly one of the four names. A behaviour difference tracing to a local file is working as designed; one tracing to a drifted tracked file is a process failure. Precedence semantics are Domain 3.
See also: 2.6 Configuration Management
Model Pinning
Recording exactly which model identifier each environment runs, knowing what it resolves to. Dated IDs are fixed releases; from the 4.6 generation dateless IDs are pinned snapshots too; pre-4.6 aliases genuinely move. Partner platforms re-spell the same snapshot (anthropic. prefix on Bedrock; @date suffix on Google Cloud for dated pre-4.6 snapshots, first-party format there for current-generation IDs).
Exam context: Migrations are deliberate and ordered: eval the candidate first, flip the pin through review, audit usage for stragglers. Flipping production first because the clock is ticking inverts the keyed sequence.
See also: 2.6 Configuration Management
Environment Parity
Each environment running a known, recorded configuration (prompt versions, model identifier, settings revision, plugin versions), so "staging passed" is evidence about production because the two are provably comparable.
Exam context: The classic failures are the production hot-fix never backported and environments silently targeting different model identifiers, both invisible until an incident because nothing records the difference. Fix the drift, then install the record-keeping.
See also: 2.6 Configuration Management
Plugin Pinning
Dependency treatment for plugins, connectors and MCP-backed capabilities: an explicit manifest, pinned versions, per-environment records, and upgrades arriving as reviewed changes run against the eval suite.
Exam context: An unpinned plugin floating on latest is an unreviewed behaviour change on someone else's schedule: the keyed diagnosis when two environments installed "whatever was current at build time".
See also: 2.6 Configuration Management
Secrets Hygiene
API keys never live in versioned files. The documented patterns are credential helpers (apiKeyHelper generates tokens on demand) and runtime environment variables; a committed key lives in history long after the file is cleaned.
Exam context: Encrypting the key in place and gitignoring the shared settings file other configuration still needs are the distractor mitigations. Adversarial handling of a leaked secret is Domain 7; do-not-commit-it is stated here.
See also: 2.6 Configuration Management