Claude Certified Architect

Glossary

Key terms for the CCAR-F exam, cross-linked from the lessons and study guides.

.claude/rules/: A directory of scoped rule files (with YAML frontmatter and glob matching) that load only when matching files are in context. Per-path rules keep the prompt small while still steering behavior for the relevant code.
.claude/rules/: A directory of markdown rule files that Claude Code loads alongside CLAUDE.md. A rule can carry YAML frontmatter with `paths:` globs so it is only injected when matching files are in play — the way to keep language- or folder-specific guidance out of every conversation.
@path import: Syntax inside `CLAUDE.md` (e.g. `@docs/style-guide.md`) that pulls another file’s contents into context instead of pasting them inline. It keeps memory files small and lets shared docs stay single-sourced.
/compact: A Claude Code command that summarizes the conversation so far, shrinking the working context while preserving key decisions. Use it during long sessions to keep the context window focused before it fills up.
/memory: A Claude Code command for viewing and editing the loaded memory files (`CLAUDE.md` at each scope). It lets you inspect and curate the persistent instructions Claude carries into every turn.
AgentDefinition: A declarative specification of a subagent — its name, system prompt/role, the tools it may use, and (optionally) model. Defining agents as configuration rather than ad-hoc code makes capabilities reviewable, reusable, and scoped to least privilege.
Agentic loop: The repeating cycle in which Claude reasons, emits a `tool_use`, receives a `tool_result`, and continues until `stop_reason` is `end_turn`. This loop — not a single call — is what turns the model into an agent that can act on the world.
Auto memory: Notes Claude Code maintains automatically across sessions, separate from the hand-written CLAUDE.md files; `/memory` lists loaded memory files and toggles auto memory. Treat it as a convenience, not the place for team conventions — those belong in a checked-in CLAUDE.md.
Bash (tool): A built-in Claude Code tool that runs shell commands (tests, builds, git). Because it can be destructive, it is a prime candidate for scoped permissions (e.g. `Bash(pnpm test:*)`) and hooks.
Batches for review: Using the Message Batches API to run large-scale, non-interactive review or evaluation jobs at the 50% batch discount. It suits offline grading, regression checks, or scoring many items where a 24-hour turnaround is acceptable.
Built-in tools: The tools Claude Code ships with — Read, Write, Edit, Bash, Grep, Glob, plus the subagent (Task/Agent) tool and web tools. Exam task statement 2.5 tests choosing among them (Grep → Read for incremental exploration; Edit, falling back to Read+Write when the anchor text is not unique).
cache_control: The `cache_control: { "type": "ephemeral" }` marker that sets a prompt-cache breakpoint on a content block so the stable prefix is reused across calls. The exam only requires knowing that prompt caching exists and helps repeated prefixes; implementation details are out of scope.
Chain-of-thought: Prompting the model to reason step by step before answering, improving accuracy on multi-step problems. The reasoning can be requested in a scratchpad or visible plan; for code, ask for a brief plan before the diff.
Citation: A single source reference for one claim (document, URL, tool result id, publication date). Requiring a citation per claim is the cheapest hallucination check available to a reviewer.
Citations: Source references attached to claims — either Claude's citations capability on provided documents or provenance annotations you ask for in the output — so a reader can verify each statement and spot unsupported ones.
Claude Agent SDK: The library (`@anthropic-ai/claude-agent-sdk` / `claude_agent_sdk`, formerly "Claude Code SDK") that exposes the same agent loop, built-in tools, subagents and hooks that Claude Code uses, so you can build custom agents programmatically. Headless `claude -p` runs on this loop; `AgentDefinition` objects scope each subagent's tools, model and prompt.
Claude Code: Anthropic's agentic coding tool (CLI and desktop): Claude reads files, runs commands and edits code in an agentic loop using built-in tools, guided by CLAUDE.md memory, rules, skills, hooks and subagents. It runs interactively, or non-interactively with `-p` for scripts and CI.
CLAUDE.md: A Markdown memory file Claude Code auto-loads to learn project conventions, commands, and constraints. Files merge by precedence — enterprise/user (`~/.claude/CLAUDE.md`) then project (`./CLAUDE.md`) then nested directories — so versioned rules persist and are reviewable.
Compaction: Summarizing earlier conversation to free context — manually with `/compact <instructions>` or automatically near the limit. It is lossy: persist decisions, modified-file lists and test commands in scratchpads or CLAUDE.md so they survive, and use `/clear` instead when the next task is unrelated.
Confidence calibration: Checking that a confidence score means what it says: among outputs the model marks "0.9", about 90% should be correct on a human-labeled set. Uncalibrated, self-reported confidence is an unreliable proxy and should not drive escalation on its own; once calibrated per field and document type it can set auto-accept and review thresholds.
Context isolation: Running a subagent in its own context window so its file reads and tool output never enter the parent's context — only a summary returns. This is the default for subagents (a *fork* deliberately inherits the parent conversation instead) and is the main lever for keeping long sessions reliable.
Context window: The maximum number of tokens (system prompt + conversation + tool results + the response) the model can attend to at once. Exceeding it causes truncation or errors, so managing what occupies the window is a core architecture concern.
Coverage annotation: An explicit statement of what was and was not examined (sources searched, files read, branches that failed) attached to a result. It lets a coordinator or human judge the limits of an answer and is the basis for re-delegating on gaps.
custom_id: A caller-assigned identifier (1–64 chars, alphanumeric/hyphen/underscore) attached to each request in a Message Batch. Because batch results return in arbitrary order, the `custom_id` is how you map each result back to its originating request.
Deterministic control: Enforcing behavior with code that runs the same way every time — hooks, schema validation, permission rules, hard-coded routing — instead of a prompt instruction the model may or may not follow. Safety gates, compliance checks and data normalization belong here; a prompt is advisory, a hook is a guarantee.
Dynamic decomposition: An orchestrator breaking a task into subtasks at runtime based on what it discovers, and re-delegating when a coverage gap appears (the iterative refinement loop). Contrast with a fixed prompt chain. The named failure mode is *overly narrow* decomposition, where subagents each see too little to do useful work.
Edit (tool): A built-in Claude Code tool that applies a precise string replacement to a file you have already read. It enables surgical, reviewable changes rather than rewriting whole files.
Empty result vs access failure: A tool call that succeeded but found nothing ("no matching orders") is a *valid* result and must be distinguished from a call that failed (`is_error`, timeout, permission denied). Conflating them either hides outages as "nothing found" or triggers useless retries when the information simply is not there.
end_turn: The `stop_reason` value indicating Claude completed its reply naturally and is handing control back. In an agentic loop, `end_turn` is the normal signal to stop iterating and surface the final answer.
Environment-variable secrets: Pass API tokens to MCP servers through environment variables (`"env": { "API_TOKEN": "${API_TOKEN}" }`) rather than committing literal credentials into `.mcp.json`. Credential-like variables are not expanded into remote `url`/`headers` fields, so keep them in `env`.
Error propagation: The risk that an early mistake (a bad tool result, a wrong assumption) flows downstream and corrupts later steps in an agent loop. Surfacing structured errors, validating outputs, and escalating uncertainty all limit how far errors spread.
Escalation: Handing a task from the agent to a human because it cannot or should not proceed: an explicit human request (honor immediately), repeated tool failures, a policy gap or silence, or ambiguous identity (several matching customers → ask for identifiers). Distinct from *approval*, which gates an action before it runs. Sentiment and raw self-reported confidence are unreliable escalation triggers; use explicit, testable rules.
Explicit acceptance criteria: Stating concrete, checkable success conditions in the prompt (what "done" means) rather than relying on the model to infer intent. Sharp criteria reduce ambiguity and make outputs easier to validate automatically.
Explore subagent: A read-only subagent used for read-heavy codebase investigation, returning a concise summary so the main session’s context stays small. It embodies subagent isolation applied to exploration.
Extended thinking: Claude's mode of producing internal reasoning before its visible answer, for harder problems. On current models the reasoning effort is platform-managed rather than set with a manual `budget_tokens`. Chain-of-thought *prompting* as a technique is a CCAR-Professional topic, not a CCAR-F task statement.
Few-shot prompting: Including a small number (typically 2–4) of input/output examples in the prompt to demonstrate the desired format and behavior. Examples drawn from real, in-style data steer output far more reliably than abstract instructions alone.
Field-level confidence: A separate confidence value for each extracted field (invoice total, due date, vendor) rather than one score for the whole document. It lets you auto-accept reliable fields while routing weak ones to review, and exposes which fields fail on which document types.
fork_session: Branching a session by copying its history up to a point into a new session with its own id, leaving the original untouched. Like `git branch`, it lets you explore alternative paths in parallel without losing prior work (CLI: `claude --resume <id> --fork-session`).
Glob (tool): A built-in Claude Code tool that lists files matching a pattern (e.g. `src/**/*.ts`). It is the fast first step for locating files by name before reading or editing them.
Glob pattern: A wildcard path expression such as `src/**/*.ts` used to scope rules (`paths:` frontmatter), permission rules (`Bash(git diff *)`), and the Glob tool's file search. `**` matches across directories; `*` matches within one segment.
Grep (tool): A built-in Claude Code tool that searches file contents by regex, returning matching files or lines. It locates code by *what it does* rather than its filename, complementing Glob.
Grep tool: Regex content search across files. It is the cheap first step of incremental investigation — find the handful of relevant files, then Read only those — instead of reading whole directories into context.
Hallucination: Confident generation of content that is unsupported or false — invented facts, APIs, or citations. Mitigations include grounding with retrieved context, provenance annotations, schema/validation checks, and asking the model to admit uncertainty.
Hard-coded control: Fixed program logic (if/else, a fixed pipeline order, a hook) that decides a step without consulting the model. Cheap, predictable and auditable — choose it when the decision is rule-based or high-stakes (a refund over a threshold always escalates), and reserve model-driven decisions for open-ended judgment.
Headless CI/CD: Using headless Claude Code inside pipelines to automate tasks like fixing tests or opening PRs, branching on JSON output (including `total_cost_usd`) and keeping the agent on a tight turn budget. The merge gate stays the same as for humans: the branch must pass CI.
Headless mode: Running Claude Code non-interactively via `claude -p "<task>"`, typically with `--output-format json` for a parseable result and `--allowedTools` to pre-approve tools. It is the entry point for CI/CD and scripted automation.
HITL escalation: A policy that routes a task to a human when the agent is uncertain, hits a permission boundary, or detects a high-risk action. Well-designed escalation captures the hard cases without forcing humans to review routine ones.
Hooks: Deterministic, event-driven callbacks (e.g. before/after a tool runs, or on session events) that execute code to enforce guarantees the model should not be trusted to self-impose. Use hooks for must-always rules like formatting, secret-blocking, or audit logging.
Hooks vs prompts: The design tradeoff between enforcing behavior with deterministic hooks versus requesting it in the prompt. Prefer hooks for non-negotiable, mechanically verifiable rules and prompts for judgment-based guidance the model should weigh.
Hub-and-spoke: A multi-agent topology where one orchestrator (the hub) delegates to specialized subagents (the spokes) that report back, with no spoke-to-spoke communication. It is the canonical pattern for parallelizable, decomposable work and contrasts with brittle deep agent chains.
Human in the loop: Keeping a person in the decision path: *blocking* approval before irreversible or high-stakes actions, and *sampling* review after the fact to measure quality. Keep the human while per-type, per-field accuracy is unmeasured or below target; automate only the strata where a labeled set proves the model is reliable.
Human-in-the-loop (HITL): Inserting human approval or judgment at high-stakes or ambiguous points in an agent workflow. HITL gates (e.g. confirm before a destructive action, or escalate low-confidence cases) bound risk where full automation is unsafe.
Incremental investigation: A debugging workflow that narrows scope step by step — Glob/Grep to locate, Read to confirm, then a targeted Edit — instead of loading the whole codebase at once. It keeps context lean and reasoning focused.
input_schema: The JSON Schema on a tool definition that declares its parameters, types and required fields. Together with the description it is the only information Claude has for deciding *whether* and *how* to call the tool, so name and describe each property for the model, not just the parser.
Interview pattern: For a larger feature, start with a minimal prompt and ask Claude to interview you (using the `AskUserQuestion` tool) about implementation, UI/UX, edge cases and trade-offs, then write the agreed spec to a file such as `SPEC.md`. Execute the spec in a fresh session so implementation starts with clean context and a written reference.
isError / is_error: A boolean on a `tool_result` block that marks the tool execution as failed. It lets Claude distinguish a tool error from a successful-but-empty result and decide whether to retry, escalate, or adjust its plan.
JSON Schema: A vocabulary for describing the structure, types, and constraints of JSON data. In Claude, tool `input_schema` is JSON Schema; a well-specified schema is the contract that makes tool calls and structured output reliable.
Labeled (gold) set: A set of inputs with human-verified correct outputs, stratified across document types and fields, used to measure accuracy and calibrate confidence *before* automating a path. Reviewer corrections from sampled production outputs should feed back into it.
Least privilege: Give every agent, subagent and tool only the capabilities its role requires: a triage agent without `process_refund`, a reviewer that is read-only, a CI run with an explicit `--allowedTools` list. Narrow tool sets also improve tool selection and make misuse impossible rather than merely discouraged.
Lost in the middle: The tendency of long-context models to attend best to information at the beginning and end of the context and overlook content buried in the middle. It motivates placing critical instructions and data near the edges of the prompt.
MCP configuration: Declaring which MCP servers a client connects to and how (command, args/url, transport, env/secrets), typically in a config file or `.mcp.json`. Scoping servers and their credentials carefully is part of least-privilege tool design.
MCP configuration (.mcp.json): Where Claude Code learns about servers: project scope in a checked-in `.mcp.json`, user and local scopes in `~/.claude.json`. Entries name the command or URL plus `env`, and support `${VAR}` / `${VAR:-default}` expansion so secrets stay out of the file.
MCP prompt: One of MCP's three primitives (tools, resources, prompts): a reusable prompt template a server exposes for the user to invoke. The CCAR-F guide discusses tools and resources only, so expect resources as *content catalogs* and tools as *actions* — prompts are low-priority exam material.
MCP resource: One of the three MCP primitives (alongside tools and prompts): read-only, addressable context such as a file, database row, or document that a server exposes for the model to read. Resources supply data; tools perform actions.
MCP server: A process that exposes tools, resources (and prompts) to an MCP client such as Claude Code or an Agent SDK agent. Choosing and configuring servers — and preferring a maintained community server over a custom one — is in scope; *deploying or hosting* MCP servers is explicitly out of scope for CCAR-F.
MCP transport: The channel carrying JSON-RPC messages between MCP client and server. Options are **stdio** (server runs as a local subprocess over stdin/stdout), **Streamable HTTP** (the current network standard), and **SSE** (the legacy HTTP transport, now deprecated).
Memory hierarchy (CLAUDE.md scopes): The layered CLAUDE.md scopes Claude Code loads and merges — managed/enterprise, project (`./CLAUDE.md`, walking up the directory tree), user (`~/.claude/CLAUDE.md`) and `CLAUDE.local.md` — with more specific scopes taking precedence (enterprise > project > user). `.claude/rules/` files and auto memory sit alongside it.
Message Batches: Asynchronous bulk processing of many independent requests at reduced cost: results within 24 hours with no latency SLA, each request tagged with a `custom_id`, and no multi-turn tool calling. Fit for offline re-grading, labeling and post-hoc audits — never for a blocking, interactive check.
Message Batches API: An asynchronous endpoint for submitting many Messages requests at once for processing within a 24-hour window at a 50% token discount. Each request carries a unique `custom_id`, and results are retrieved later — ideal for high-volume, non-interactive work like evaluation or bulk extraction.
Messages API: The primary Claude endpoint (`POST /v1/messages`) for sending a list of alternating `user`/`assistant` turns and receiving a model response. It returns structured content blocks (text, `tool_use`) plus metadata such as `stop_reason` and token usage.
Model Context Protocol (MCP): An open, JSON-RPC-based protocol that standardizes how AI clients connect to external servers exposing tools, resources, and prompts. MCP decouples capability providers from clients, so one server (e.g. for a database or API) works across any MCP-aware host.
Model vs hardcoded logic: The decision of whether to let the model reason about a step or to implement it as fixed code/control flow. Hardcode the deterministic, high-stakes, or cheaply-specified parts; reserve the model for ambiguous, judgment-heavy decisions.
Model-driven control: Letting Claude decide the next step, route or decomposition at runtime based on what it sees. Flexible for ambiguous, open-ended work; trade it for hard-coded control wherever predictability, cost or safety matter more than adaptability.
Multi-pass review: Improving output by running additional review passes — the model (or a separate reviewer agent) critiques and revises a first draft against criteria. It trades extra tokens/latency for higher quality on important deliverables.
Orchestrator (coordinator): The coordinating agent in a hub-and-spoke system: it decomposes the task, delegates to subagents, checks coverage, re-delegates on gaps and synthesizes the result. It is also the single place to centralize retry and escalation policy so handoffs are predictable.
Parallel execution: Running independent subtasks concurrently — e.g. fanning out several subagents or issuing multiple tool calls at once — to cut wall-clock latency. It only applies when subtasks have no ordering dependency; sequential work needs prompt chaining instead.
Partial failure: When some parallel subagents or tool calls succeed and others fail. Report per-branch status, surface failures structurally (`is_error`, not silent omission), retry or escalate only the failed branch, and never present a partial result as if it were complete — annotate what is missing.
Permission mode: The session-level baseline in Claude Code for how tool calls get approved — Manual/`default` (ask), `acceptEdits`, `plan` (read-only), `dontAsk` (deny anything not pre-allowed; locked-down CI), `bypassPermissions`, and `auto` (a classifier reviews actions). Set with `--permission-mode` or Shift+Tab; settings allow/deny rules layer on top of the mode.
Permission model: Claude Code’s allow/ask/deny controls governing which tools can run with or without confirmation. Pre-approve safe, idempotent tools and gate destructive ones; in automation, pass `--allowedTools` explicitly so runs complete without prompts.
Pipeline pattern: A fixed sequence of steps in which each output feeds the next (prompt chaining). Predictable and easy to test, but cannot adapt when a step discovers the plan was wrong. Community term, not guide language; the exam contrasts *prompt chaining* with *dynamic decomposition*.
Plan mode: A Claude Code mode where the model explores and proposes a change set **without writing files or running mutating tools**, pending approval. It catches wrong-file or wrong-architecture mistakes before they cost a round-trip and is recommended for any non-trivial change.
Plan vs direct execution: The choice between proposing a plan first (safe, reviewable, better for multi-file or risky work) versus executing immediately (fast, fine for trivial edits). Matching mode to task risk is a Domain 3 design decision.
Progressive summarization: Periodically compressing accumulated conversation or work into a running summary so the context window stays small while key facts survive. It is the core technique behind `/compact` and long-running agent memory.
Prompt caching: A feature that caches stable prefix content (long system prompts, tool definitions, documents) via `cache_control` so repeated requests skip re-processing it. Cache reads cost a fraction of normal input tokens, cutting latency and price for prompts with a large fixed prefix.
Prompt chaining: Decomposing a complex task into a sequence of steps where each step’s output feeds the next. Chaining improves reliability for ordered, dependent work; use it when later steps genuinely require earlier results, otherwise prefer parallel fan-out.
Provenance annotations: Tagging facts in context (or in output) with their source so the model and reviewers can trace claims back to evidence. Provenance supports grounding, reduces hallucination, and makes outputs auditable.
Read (tool): A built-in Claude Code tool that reads a file’s contents (optionally a line range) into context. Reading before editing is required so changes are grounded in the actual current text.
Resume (session): Continuing a saved Claude Code session: `--continue` picks up the most recent one, `--resume <session_id>` a specific one. A resumed session must be told which files changed while it was away; when its earlier tool results are stale, start a fresh session and inject a summary instead.
Router pattern: A first classification step directs each request to a specialised prompt, tool set or agent. Useful community vocabulary for a model-driven dispatch, but not a term used in the CCAR-F task statements — expect exam items to describe the behavior, not name the pattern.
Schema design: Crafting a JSON Schema with clear field names, descriptions, required fields, and enums so the model produces valid, unambiguous output. Good schema design — especially descriptive field docs — is one of the strongest levers for structured-output quality.
Scratchpad: A dedicated space (often a delimited section or hidden reasoning) where the model works through intermediate steps before producing a final answer. Scratchpads externalize chain-of-thought and keep reasoning separable from the deliverable.
Server-Sent Events (SSE): A one-way HTTP streaming format. Streaming and SSE are explicitly out of scope for CCAR-F, and the MCP HTTP+SSE transport was deprecated by the 2026-07-28 specification in favor of Streamable HTTP — if an option hinges on SSE details, it is usually a distractor.
Session: A persisted conversation thread (history, state, and context) that an agent runtime can resume later. Sessions let long-running or interrupted work continue without rebuilding context from scratch.
Session management: The practice of creating, persisting, resuming, and forking sessions to control an agent’s memory and continuity over time. Good session hygiene keeps context relevant and recoverable across long or multi-stage tasks.
Skill: A packaged, model-invoked capability — a folder with a `SKILL.md` (name + description) plus optional scripts and resources — that Claude loads on demand when its description matches the task. Skills extend behavior with reusable, progressively-disclosed expertise.
Slash command: A reusable, parameterizable prompt template invoked with `/name`, defined as a Markdown file under `.claude/commands/`. Slash commands turn repeated workflows (e.g. `/review`, `/release`) into versioned, shareable shortcuts.
State snapshot: A structured (often JSON) dump of task state — goal, decisions, done, next steps, modified files — written to disk so it survives compaction, a `/clear`, or a resumed session. Inject it into a fresh session instead of relying on lossy summaries.
stdio transport: An MCP transport where the client launches the server as a local subprocess and exchanges newline-delimited JSON-RPC over stdin/stdout. Best for local, single-user tools; it avoids network setup but does not serve remote clients.
stdio transport: The MCP transport in which the client launches the server as a local subprocess and exchanges messages over stdin/stdout — the norm for local tools. Transport selection and securing transports are out of scope for CCAR-F; know the name, not the wire details.
stop_reason: A field on every Messages API response stating why generation stopped. Core values are `end_turn` (finished naturally), `tool_use` (Claude wants you to run a tool), `max_tokens` (hit the output cap), and `stop_sequence` (matched a custom stop string); `pause_turn` can appear with long-running server tools.
Stratified sampling: Choosing outputs for human review by first partitioning the population into strata (document type, field, confidence band, stakes) and then sampling randomly *within each stratum*, so rare or high-risk segments are represented and so the accuracy of the auto-accepted, high-confidence path is actually measured. Contrast with plain random sampling, which is dominated by the common case.
Streamable HTTP transport: The current recommended MCP network transport: the server is an independent process handling many clients over HTTP POST/GET, optionally streaming responses with SSE. It supersedes the older standalone SSE (HTTP+SSE) transport.
Streamable HTTP transport: MCP's transport for remote servers (`claude mcp add --transport http …`). It replaces the older HTTP+SSE transport, which the 2026-07-28 MCP specification deprecates; Claude Code recommends HTTP and falls back automatically. Out of scope beyond knowing which is current.
Streaming: Receiving a Messages API response incrementally as server-sent events (set `stream: true`) instead of one final payload. Streaming lowers perceived latency for interactive UIs and lets clients render tokens as they arrive.
Structured errors: Returning tool failures as machine-readable, descriptive payloads (with `is_error: true` and a clear message) instead of opaque strings or silent failures. Structured errors let Claude diagnose the cause and self-correct within the agentic loop.
Structured output: Output produced in a machine-readable schema (usually JSON), commonly obtained by forcing a schema-shaped tool with `tool_choice`. It lets downstream systems consume model results programmatically instead of parsing prose.
Subagent: A separate agent instance, with its own context window and tool set, that an orchestrator delegates a focused task to. Subagents isolate context (keeping the main thread clean) and enable parallelism, but cannot see each other directly.
Subagent isolation: The property that each subagent runs in a fresh, separate context window and returns only a summary to its caller. Isolation prevents context pollution and lets noisy, read-heavy work happen without bloating the orchestrator’s window.
System prompt: The `system` parameter of the Messages API: role, instructions and stable context placed before the conversation. It is the natural prompt-cache prefix and the position the model attends to most reliably. In Claude Code, `--append-system-prompt` layers onto the default system prompt rather than replacing it.
Task tool (Agent tool): The Claude Code / Agent SDK tool that spawns a subagent. The exam guide uses the name **`Task`** ("allowedTools must include Task"); since Claude Code v2.1.63 the `tool_use` name is `Agent`, with `Task` kept as an alias. Answer exam items with the guide's wording.
Test-driven iteration: Give Claude a check it can run before it writes the code: ask for (or write) the tests first, confirm they fail, then implement until they pass. When a run fails, share the failing output verbatim rather than describing it — concrete input/output beats abstract description at every step of refinement.
Token: The unit of text a model reads and writes. Context windows, usage fields, pricing and caching are all measured in tokens; tokenization internals are explicitly out of scope for the exam.
Token budget: The deliberate allocation of the context window across system prompt, instructions, retrieved context, history, and response. Budgeting forces tradeoffs — what to keep, summarize, or drop — so the most relevant content stays in scope.
Tool description: The natural-language `description` of a tool: what it does, when to use it (and when not), what it returns and its constraints. Rich descriptions are what stop an agent defaulting to a built-in Grep instead of your MCP tool; vague ones cause mis-selection, especially as the tool count grows.
Tool descriptions: The natural-language `description` and per-parameter docs on a tool definition that tell the model when and how to use it. Clear, specific descriptions are the primary driver of correct tool selection and argument filling.
Tool scoping: Granting an agent or subagent only the minimal tool set it needs for its job (least privilege). Tight scoping reduces error surface, prevents unintended destructive actions, and keeps the model focused on relevant capabilities.
tool_choice: A request parameter that controls tool invocation: `auto` (model decides), `any` (must call some tool), `tool` (must call a named tool), or `none` (forbid tools). Forcing a tool is the standard way to coerce structured output via a single schema-shaped tool.
tool_result: A content block sent back in a `user` turn that returns the output of a `tool_use` request, keyed by its `tool_use_id`. Setting `is_error: true` signals the tool failed so Claude can recover or retry.
tool_use: A content block in which Claude requests that a named tool be invoked with a JSON `input`. When present, `stop_reason` is `tool_use`; the application executes the tool and returns the result as a `tool_result` block in the next user turn.
Training cutoff: The date after which a model has no knowledge. Anything newer — your codebase, today's API, recent events — must be supplied in context, otherwise the model may confidently hallucinate it. Also the reason to include publication dates when summarizing time-sensitive sources.
Validation-retry loop: Validating model output against a schema or checks (linter, tests), and feeding failures back so the model self-corrects. Distinguish syntax errors (always safe to retry) from semantic errors (may need a sharper criterion or a human).
Writer / Reviewer (independent review): Have a *different* Claude instance (a fresh session or subagent) review code than the one that wrote it: a reviewer with clean context is not biased toward code it just produced. In CI this means the review job is an independent instance, given the diff, existing tests, CLAUDE.md conventions and prior findings — not the generating session.