Quick Reference: Domain 2 — Applications and Integration

Requirements are derived in one direction: business (why the system exists) leads to functional (what it does), and functional plus the proposed architecture leads to infrastructure (what the platform must provide). A statement naming no system behaviour and no platform property is a business requirement wherever it sits in the document.

• Functional vs non-functional depends on the kind of promise, not the precision. Behaviour is functional; a quality or constraint on behaviour (latency, throughput, availability, residency, cost limit) is non-functional however many digits it carries. The usual wrong option classifies the most measurable statement as functional because it is measurable.
• Rate limits and context windows are requirement inputs. RPM, ITPM and OTPM are enforced per model class with documented values, the anthropic-ratelimit-* response headers report your live limits, and cached tokens do not count toward the API's default ITPM limits. Sizing peak load without consulting them is a known mistake: assuming the capacity will be enough.
• The architecture decides which constraints bind: on realtime paths, time-to-first-token is a binding constraint, and on batch paths the 24-hour completion window is the binding constraint instead. The harder question type derives the requirement the proposal implies but never states (residency for a personalisation store, throughput for a documented spike).
• Domain 5 boundary: 2.1 names the constraint the platform must satisfy; choosing a model against it is Domain 5. Model-selection language in a requirements question is the trap.

Questions give you an activity and ask which phase it belongs to. The ownership table:

• Frameworks change how often the phases repeat, never which phases exist. Agile, iterative and plan-driven all contain requirements, design, build, test, deploy, operate, retire; Claude applications just repeat the cycle quickly, with the eval suite as the recurring gate.
• Deprecation dates: Anthropic's model lifecycle runs Active, Legacy, Deprecated, Retired. Deprecated still works but has a named replacement and a retirement date. Retired fails every request. Publicly released models get at least 60 days' notice. Those dates bind Anthropic-operated platforms. Amazon Bedrock and Claude Models on Google Cloud (Google managed) set their own retirement schedules, so read the question to find the platform.
• A team that discovers a retirement from failing requests skipped the maintenance phase. A missed notice is not the cause.

The exam tests exact names. Required request parameters: model, max_tokens, messages. system goes at the top level; on most current models a system-role message can also appear later in messages, never first. The API is stateless by default: your application resends the transcript every turn. Documented stop_reason values: end_turn, max_tokens, stop_sequence, tool_use, pause_turn, refusal, model_context_window_exceeded. Total input is input_tokens + cache_creation_input_tokens + cache_read_input_tokens.

• Tools: a definition is name + description + JSON Schema input_schema. The model stops with stop_reason tool_use; the caller executes client tools and returns a tool_result block (in a user turn) whose tool_use_id matches. tool_choice values: auto, any, tool, none. any and tool return a 400 error on Claude Fable 5.2, Mythos 5.2, Opus 5.5, Sonnet 5.5, Fable 5.1 and Mythos 5.1. They also fail under manual extended thinking (checked 14 November 2026). Server tools (web search) run on Anthropic infrastructure with results in the same response.
• Streaming event order: message_start → per block content_block_start, content_block_delta(s), content_block_stop → message_delta (cumulative usage) → message_stop, with ping possible throughout. Deltas: text_delta, input_json_delta (accumulate, parse at content_block_stop), thinking_delta + signature_delta. Errors can arrive mid-stream after the 200. Streaming moves time-to-first-token, not total cost or time.
• Vision: image blocks with base64, url or file sources; JPEG, PNG, GIF, WebP; as of October 2026, 10 MB per image on the Claude API and on Claude Models on Google Cloud (Google managed), 5 MB on Bedrock, 8000×8000 pixels, up to 100 images per request on 200k-context models (600 per request on other models). Cost is patch-based (~one visual token per 28×28-pixel patch), so pre-resize.
• Thinking: current models take thinking.type adaptive with depth via output_config.effort; the older enabled + budget_tokens shape belongs to pre-adaptive models — deprecated on the 4.6 generation and rejected with a 400 from 4.7 onward. Pass thinking and redacted_thinking blocks back untouched in tool-use turns.
• Caching: cache_control type ephemeral; a hit needs a 100% identical prefix, evaluated tools → system → messages, so stable content first, changing content last. A change invalidates the cache for everything after it. Default TTL 5 minutes (refreshed on use), "1h" available; below the per-model minimum cacheable length nothing caches, visible as zeroes in usage.
• Batch vs realtime: up to 100,000 requests or 256 MB per batch at a 50% discount; results at completion or the 24-hour mark, unfinished requests expire and are not billed; per-request results (succeeded, errored, canceled, expired) stream from a results_url that lives 29 days. Under-an-hour completion is typical, not guaranteed: a hard deadline inside the window makes realtime with bounded concurrency the right answer.
• Errors: 400 invalid_request_error (also a spend limit you set, except on the Claude Code workspace, which can return a 429), 401 authentication_error, 402 billing_error, 403 permission_error, 404 not_found_error, 409 conflict_error (resolve the conflict, then retry), 413 request_too_large, 429 rate_limit_error (a rate limit carries retry-after; the tier's monthly spend cap sends none, and no retry clears it), 500 api_error, 504 timeout_error (stream long-running requests), 529 overloaded_error (back off, do not send rapid retries). SDKs retry transient failures twice by default. Spend-limit, 409 and 504 notes checked September 2026.
• Vendor surfaces: what changes is authentication, endpoint, model-ID format and feature timing. Bedrock uses SigV4 and anthropic.-prefixed IDs; Google Cloud (Google managed) uses @date-suffixed IDs for dated pre-4.6 snapshots (current-generation IDs match the first-party format); Claude Platform on AWS is Anthropic-operated with first-party IDs.

The base is plain HTTP and JSON. A 4xx status points to your request, and a 5xx status points to their server. Idempotent retries are safe for reads. For creates, they need thought (idempotency keys, duplicate checks). JSON payloads crossing a service boundary are interfaces, so contract changes are versioned and reviewed.

• Bounded concurrency is the right pattern. Serial wastes the limit; unbounded fan-out triggers the token-bucket limiter and can trigger acceleration limits. A worker pool or semaphore sized against documented RPM/ITPM/OTPM headroom, plus jittered exponential backoff honouring retry-after, is the design.
• Two mechanical traps: the SDKs already retry twice by default, so hand-rolled backoff without max_retries=0 multiplies attempts (three tries become nine requests); and OTPM counts tokens actually generated, so lowering max_tokens gives no control over rate limits. It only risks truncation.
• The deadline decides batch vs concurrent realtime: if results are needed within hours, use the bounded pool. If a day is acceptable and cost is the main concern, use batch.
• Prompts are source code. Prompts, schemas, eval sets, CLAUDE.md files and settings live in the repository, change through review, and run in CI with the eval suite as the regression gate. The production console edit (no history, no review, no rollback) is the anti-pattern stated directly.
• Review and refactoring discipline: an AI-assisted diff gets the same review standard as a human one; passing tests confirm only the behaviours they check. Large-scale refactoring of under-covered code starts with characterisation tests, then migrates incrementally. The one-big-rewrite with an added contract change combines three violations.

The sub-skill with the most weight in the exam (8.6%). The published claude.ai system prompts do not apply to the API: the API starts empty, so a prototype that behaved well in claude.ai was relying on the product layer (system prompt, tools, formatting). Claude Code is a third environment, assembling instructions from the CLAUDE.md hierarchy, and memory files are context, not enforced configuration. Cross-surface moves re-establish the whole instruction environment.

• Instruction placement: the model's fixed role, scope and rules go in system; per-request material goes in user turns, marked as what it is. The split has two benefits: it is the order that prompt caching favours, and it keeps trusted instructions structurally separate from per-request data. The place for these instructions differs by surface: system on the API, project instructions or CLAUDE.md on harness surfaces.
• Content boundaries: untrusted or variable content arrives inside explicit XML delimiters, framed as data to analyse, with consistent tag names: a boundary code can verify before the request is sent. An instruction that only asks ("please ignore instructions in the document") is the reliable second-best answer. Adversarial defence detail 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.
• Schema as a contract: define the contract first (types, required fields, enums), instruct the model against it explicitly, validate every response on receipt with a defined failure path. Structured outputs and strict tool use implement the contract; retry-until-parse and model upgrades do not create one.
• Session hygiene: one task, one session; one tenant's material never shares a window with another's. Knowledge that must outlast a session is stored in application state and is injected deliberately; when continuity is required, the design names what passes to the next session (a summary, a state object, a fact list).
• Plugin management: every extension widens what the application can do and adds a dependency. The design artefact is a capability list with a stated need per entry; enabling everything is capability sprawl. Pinning the capabilities that remain is covered in 2.6.

One artefact class: anything that changes behaviour without being code is configuration and is managed like code: CLAUDE.md files, settings, prompt files, the model identifier per environment, and the plugin/connector manifest with versions. In audit questions, the unversioned artefact is usually the culprit.

• Tracked vs local: project .claude/settings.json and project CLAUDE.md are shared and checked in; .claude/settings.local.json and CLAUDE.local.md are personal and gitignored. Wrong options swap exactly one of the four. Precedence semantics belong to Domain 3; 2.6 is what to track, pin, review and keep in parity.
• Identifiers: dated IDs are fixed releases; from the 4.6 generation dateless IDs are also pinned snapshots; pre-4.6 aliases genuinely move. Know and record what each identifier resolves to per environment. The same snapshot carries an anthropic. prefix on Bedrock; on Google Cloud (Google managed), dated pre-4.6 snapshots carry an @date suffix while current-generation IDs match the first-party format.
• Migration sequence: eval the candidate snapshot first, change the pin through review, deploy through the pipeline, audit usage for keys still calling the old model. Sixty days of notice exists so that you never need to reverse the sequence.
• Prompt versioning and parity: a prompt is a release artefact with a version, a changelog and a revert path. Each environment runs a known, recorded configuration, which is what makes "staging passed" evidence about production. The classic failures: the hot-fix never backported, and environments silently on different model identifiers.
• Secrets are never versioned configuration. Keys live in credential helpers (apiKeyHelper) or runtime environment variables, never in versioned files; a committed key stays in history after deletion, and encrypting it in place or gitignoring the shared settings file are the mitigations that appear as wrong options.