Glossary — Terms, Examples & API Fields
A
| Open explanation | Plain meaning |
|---|---|
| A/B testing and iteration — experiment record + pre-registered decision rule | Comparing two versions (prompt, tier, retrieval setting) on the same golden set offline and then on a traffic split online, with a decision rule written before the results: a primary metric threshold, guard metrics for every other slice and family, safety and security at 100%, and a canary window. |
| Accuracy–latency trade-off (per-step justification) | Every setting that raises answer quality costs time somewhere: a larger model tier, extended thinking, more retrieved chunks, a verifier call. |
| Adoption metrics (usage, quality, cost, trust) | The small set of numbers that say whether an AI-tooling rollout worked: whether people use it, whether output quality held, what it costs, and whether people trust it. |
| Agent loop | Repeated model calls with tool results returned between calls, until the application stops the run. |
| Agent Skills — procedure, not a connection | Agent Skills is an open format for reusable task instructions in SKILL.md, optionally bundled with scripts and references. |
| Agent-to-agent delegation (judgment in, typed result out) | An orchestrating agent hands a bounded subtask to another agent that runs its own loop with its own tools and context, and receives a structured result that matches a declared schema. |
| Agentic system | An application where a model chooses some next steps and requests tools within an execution loop. |
| AI-assisted debugging (the tool versus the production service) | Supporting developers when a Claude-powered thing misbehaves — and telling apart the two things that can misbehave. |
| Allowlist | An explicit set of permitted items or operations. |
| Architecture decision record (ADR) | A short, numbered document that records one architectural choice: the context, the decision, the alternatives rejected and why, and the consequences. |
| Architecture documentation (the joined view + decision log) | The one versioned document where the runtime view (which step runs on which tier with which prompt), the data view (what enters prompts, what is logged, retention, region), the SLA table, the decision log (links to every ADR), and the operations section (runbook, on-call, dashboards) are joined. |
| Artifacts of orchestration | Records a coordinator uses to organize work. |
| Audit log record (one decision, fully reconstructable) | The record schema written for every guardrail verdict, routing decision, approval, and tool execution: run and turn, actor, pseudonymized subject, data classification, event, tool and argument hash, model tier, verdict, approval, execution flag, idempotency key, redaction counts, retention class, and residency. |
| Audit trail | A durable record that helps reconstruct decisions and actions. |
| Augmented LLM (one call + retrieval + tools + memory) | The building block of every pattern in Building Effective Agents: a single model call that the application enhances with retrieval (documents the application supplies), tools (actions the model may request), and memory (state the application carries between calls). |
| Authentication versus authorization (who vs may) | Authentication proves who a caller is: the harness to the model endpoint with an API key or cloud IAM role, the user to the harness with a validated session token, the harness to each MCP server with a scoped token. |
B
| Open explanation | Plain meaning |
|---|---|
| Backpressure | Slowing or pausing earlier work when a later stage cannot keep up. |
| Bash — Claude Code tool | Run a shell command through the agent runtime. |
| Batch API | A provider interface for submitting many requests for asynchronous processing. |
| Batch processing — requests now, results later | Your application submits independent requests together and collects results later. |
| Batching versus concurrency — use each at the right stage | Batching groups work. |
| Bedrock / Vertex — same body, different endpoint and credential | Amazon Bedrock and Google Vertex AI serve Claude with the same Messages request body; what changes is the endpoint the SDK targets and how the harness authenticates — a cloud IAM role or service account instead of an API key — plus where calls are audited and which network boundary applies. |
| betas — which optional API features this request opts into | betas is a Python SDK argument listing the exact beta feature names your request needs. |
| Bias, fairness, transparency — as design requirements | Ethical considerations turned into requirements with measurements and gates: bias is a measured gap in outcome or error rates across defined groups; fairness is the criterion chosen for that gap (equal error rate, equal opportunity, or equal outcome — they conflict) and who signed it; transparency is what the user sees (disclosure, path to a person) and what the auditor can reconstruct (evidence, model tier, reviewer, reason codes). |
| Budget | An application limit on time, turns, tokens, or spending. |
| Build vs buy (the agent-stack decision) | Deciding, per layer of the stack, whether to write it, adopt a product, or use a framework: the harness loop, the tool layer, the model access layer, and orchestration. |
| Business value pillars (efficiency · transformation · productivity · cost · performance SLAs) | The five kinds of value a Claude solution is justified by, as the CCAR-P blueprint names them. |
C
| Open explanation | Plain meaning |
|---|---|
| @claude | A mention that can trigger a configured Claude Code GitHub workflow. |
| Cache boundary (also called a cache breakpoint) | A position in the request input: everything through the marked block is the prefix eligible for reuse. |
| cache_control (request marker — prompt caching) Not on CCAR-F | Request setting that marks a cache boundary: the end of an input prefix whose processing can be reused. |
| Calibration | Checking whether reported confidence matches observed correctness. |
| Capability bloat (tools the role never uses) | The accumulation of tools, permissions, or connected servers in an agent's configuration beyond what its role's real work requires. |
| Chain of thought — asking for an explanation of a solution | In prompting, this usually means asking Claude to explain steps that support its answer. |
| Checkpoint | A durable record of progress used to resume a stopped run. |
| Choosing a technique — zero-shot, few-shot, or chain-of-thought | A per-step design decision: start with instructions only (zero-shot), add worked examples when the golden set shows shape or pattern errors (few-shot), and ask for reasoning before the answer when it shows skipped steps (chain-of-thought). |
| Chunking strategy (split to the question's grain) | How ingestion code divides a document into retrievable pieces: on headings for structured prose, per record for tickets and messages, fixed size with overlap for unstructured narrative, per syntactic unit for code, per row with header for tables. |
| CI and team enforcement | Continuous integration runs automated checks on proposed code changes. |
| Claude Agent SDK | A library providing an agent runtime with more built-in loop and tool behavior than a basic API client. |
| Claude Code | Anthropic's coding-agent application and runtime. |
| Claude configuration files: separate jobs | CLAUDE.md is GUIDANCE (the model reads it; usually followed; no guarantee). |
| CLAUDE.md (memory file) | GUIDANCE, not enforcement: a Markdown instruction file that Claude Code loads as text (a user message after the system prompt), so the model reads it and usually follows it, but nothing guarantees compliance. |
| Closed schema | A JSON object schema that disallows keys not listed by that schema. |
| compaction (content block — received, beta) | Carries a shorter representation of earlier history generated by the compaction feature. |
| Compaction (who actually runs it?) | Replacing some conversation history with a shorter representation. |
| Confused deputy | A privileged component is tricked into using its authority for an unauthorized requester. |
| Constraints — exact text and examples | Constraints are written rules that limit the task. |
| content (message field — string or typed blocks) | Carries text or typed blocks such as tool requests or results. |
| Context budget — the ledger the harness enforces before each call | The arithmetic that keeps every call inside the selected model's window: window limit minus reserved output (max_tokens, plus any thinking budget) is the room for input; minus the stable prefix is the ceiling that history, tool results, and documents share; a soft threshold below that ceiling triggers compaction. |
| Context engineering | Choosing and organizing the information supplied to a model call. |
| Context isolation | Keeping one task's working context separate from another task's context. |
| Context window | The model's limit on the information and generation it can process in one call. |
| context_management — top-level request settings | A request object beside messages that enables supported context operations. |
| Control failure plan (what catches each layer when it fails) | A table with one row per control: how it fails, the signal that reveals the failure, the blast radius, the independent control that catches the miss, and the response. |
| Control type — removal, preventive, compensating, detective | The vocabulary the CCAR-P answer keys use to grade options. |
| CosmicKeys go-live — real deployment and permission flow | GitHub Actions deploys a zero-traffic backend revision; local gcloud commands promote it. |
| Cost-performance tuning — every lever has a guard metric | The set of optimization levers an architect can pull — prompt caching of the stable prefix, model tiering by category, the Batch API for offline work, output shaping with a schema and a tight max_tokens, streaming for perceived latency, context trimming or compaction, reasoning-effort budgets, and fewer tools per route — each named with the metric it improves, the metric it risks, where the setting lives, and the eval or ratio that proves the risk did not materialize. |
| create, parse, tool_runner — choose the job | Create gets a model turn; parse adds typed output handling; tool_runner manages repeated model and tool turns. |
| Criterion-referenced assessment (fixed standard, no curve) | A scoring model in which each candidate is measured against a fixed performance standard rather than against other candidates. |
| Currency minor units — read amount and currency together | Some payment APIs represent money as an integer in the currency’s minor unit. |
D–E
| Open explanation | Plain meaning |
|---|---|
| Data residency (where data may be stored and processed) | The requirement that certain data stays within a geographic or authorization boundary — an EU region for GDPR transfer simplicity, an agreement-covered region for PHI, an authorized environment for FedRAMP. |
| Decision as data | Representing a proposed next step as structured information that code can inspect. |
| Decomposition (finding the seams) | Breaking a goal into smaller tasks with clear responsibilities and dependencies. |
| Deployment permissions — Claude Code, GitHub, and GCP | Each system checks a different permission. |
| Deterministic | A computation gives the same result for the same complete inputs and state under the same rules. |
| document (content block — user only) | Sends a document, such as a PDF, as input to Claude. |
| Domain weighting (blueprint weights → item counts → study hours) | The approximate share of scored items each content domain contributes, as listed in the exam blueprint. |
| Edit — Claude Code tool | Replace matching text in an existing file. |
| Egress control (outbound network allowlist) | Outbound communication from an application or network. |
| Elicitation | An MCP server request for additional user input through a supporting client. |
| Enablement plan (the document a manager signs) | One markdown document that turns 'roll out Claude tooling' into a signed sequence: owner and sponsor, scope, goals with baselines and targets, staged deliverables with exit checks, the support channel and office hours, and a risk table with control types. |
| Enterprise managed policy (managed settings) | ENFORCEMENT, not guidance: configuration deployed by an organization (managed-settings.json, MDM, admin console) that Claude Code applies in code to impose product settings and restrictions, and that no user or project file can override. |
| Error taxonomy | A classification of failure types that helps choose the correct response. |
| Escalation | A defined route for handing unresolved or sensitive work to a person or another process. |
| Eval (evaluation) | A repeatable assessment of an AI system's behavior or output. |
| Evaluation dataset — slices, sources, and the sealed held-out | The versioned collection of test cases an evaluation runs on, designed as slices with a purpose each: representative cases sampled by category weight, curated edge cases, regression cases added at every incident close, adversarial cases from red-team work, and a held-out slice sealed against prompt tuning. |
| Evaluation metrics — accuracy, latency, cost, safety, security | The five numbers an architect defines for a Claude system, each as a scoring rule over a defined dataset: accuracy (output matches expectation, per category), latency (p50/p95 first-token and total), cost (per resolved unit of work from the response usage block), safety (pass rate on policy-edge and adversarial cases), and security (injection resistance and blocked unauthorized tool calls). |
| Evaluator–optimizer — draft, review, revise | One step creates a candidate answer. |
| Examples in a prompt — sample input, correct answer, then a new PDF | An example is a sample input and its correct answer that you supply to Claude. |
| Expectation alignment (will / will-not sheet + feedback cadence) | Two artifacts that keep stakeholders and the system honest with each other. |
| Extended thinking | A model feature that allocates additional reasoning effort to a task, according to supported settings. |
F–H
| Open explanation | Plain meaning |
|---|---|
| Failure diagnosis — prompt failure, hallucination, model mismatch, retrieval failure | The ordered procedure for finding which component produced a wrong answer: ask what changed (prompt version, tier, index version, tools), break failures out by category and input, read the exact request and response (retrieved chunks, stop_reason, usage), then assign the cause — prompt failure (unclear or conflicting instructions), hallucination (claims unsupported by supplied context), model mismatch (task exceeds the tier), or retrieval failure (wrong material supplied). |
| Failure-mode catalog (mechanisms of LLM systems) | An engineering reference listing the mechanisms that produce bad outcomes — hallucination, injection, over-permissioned tools, confused deputy, tool poisoning, data leak, silent model change, runaway loops, truncated output, stale retrieval, biased outcomes, approval fatigue — each with the layer that stops it and the signal that detects it. |
| Feedback loop (the fourth stage of an end-to-end architecture) | The designed data path by which a system’s outputs teach it: operator overrides, user ratings, and downstream outcomes are captured as events, promoted to an evaluation set, and used to gate prompt or routing changes. |
| Find and refactor — one payment story | Three situations. |
| Forced tool extraction — read the arguments as data | For extraction, Claude can return data as tool arguments. |
| Frontmatter — the config block machinery reads, above the content | A metadata block at the beginning of a Markdown file, between lines containing three hyphens. |
| Glob — Claude Code tool | Find file paths matching a filename pattern. |
| Golden set | A stable collection of representative test cases with expected outcomes or scoring rules. |
| Graceful degradation | A planned response when the preferred service or method fails. |
| Grep — Claude Code tool | Search patterns in file contents. |
| Guardrail | A check that helps keep the application within an allowed boundary. |
| Guardrail placement (which layer for which requirement) | The decision rule for choosing where a control lives: match the strength of the requirement (must never / reduce / prove) to a layer that can deliver it. |
| Guardrail prompt layer — the advisory block in system | A dedicated text block, usually the last in the system array, that states what the model must refuse, when to escalate, and the exact wording your code will detect (for example a single line beginning ESCALATE:). |
| Hallucination versus retrieval failure — obedience over wrong material | Two causes of confident wrong answers that look identical from the outside. |
| Handoff (the phase between approved design and first traffic) | The lifecycle phase in which an approved design becomes a running system owned by someone other than the architect. |
| Harness | The application code around the model call. |
| Headless mode (claude -p) | Running a program without a person interacting with its terminal during the run. |
| HITL validation strategy (routing, sampling, queue semantics) | The Professional-level design of human review: which outputs a person must see (risk tier plus calibrated confidence), how the rest are still checked (stratified sampling of auto-approvals), and how an approval binds to the exact action (hash, expiry, required approvers, recheck on resume). |
| Hook (Claude Code) | ENFORCEMENT, not guidance: a script that Claude Code (the program) runs on a configured event, whatever the model decided, registered in Claude Code configuration—usually the hooks object in .claude/settings.json. |
| How the model picks a tool — what it actually reads | The model uses the available tool definitions and context to choose a tool, within API selection controls. |
| Hub-and-spoke | A coordination design where workers communicate through a central coordinator. |
| Human-in-the-loop (HITL) | Human-in-the-loop: an application pauses an action for a person's decision. |
I–L
| Open explanation | Plain meaning |
|---|---|
| “I am admin” — when to reject, call Claude, or check a tool | A user message can describe a request, but it cannot grant permission. |
| id (response field) | Identifies one returned message. |
| Idempotency | Repeating the same logical operation does not create an additional effect. |
| Identity — exact text and examples | Identity tells Claude the job it should perform. |
| image (content block — user only) Not on CCAR-F | Supplies an image for the model to inspect. |
| Implementation guidance (the buildable handoff document) | The document the architect hands to the team that will build the system: a build order with versioned prompt, schema, and tool file names; the non-negotiables restated from requirements and ADRs (no write tools, region-pinned endpoint, eval thresholds); a definition of done per step (tests, recorded eval run, dashboards live); and contacts with escalation rules. |
| Incident triage flow (cause before symptom) | The ordered checks an on-call engineer runs when a Claude-powered service alarms: provider first, then our own last change, then input shift, then tool failures, and only then the model's behavior on the same input. |
| Indexing strategy (how a chunk can be found) | The choice of finders the index supports: dense vectors for meaning, sparse keyword for exact terms, hybrid fusion for mixed corpora, metadata filters for version, ACL, date, and section, and hierarchical parent–child for precise match with rich context. |
| Injection detector — a component called by your harness | You implement or integrate a screening component, then call it from the harness. |
| input_schema vs output_config — one word, two vantage points | input_schema describes what goes into a tool function, even though those arguments come out of the model. |
| Inspecting & editing the history — before every call | Your application's selection and transformation of conversation history before the next call. |
| Integration mechanism — MCP vs API/CLI vs agent-to-agent | The three ways to connect an agent to a capability: expose it as an MCP server the host discovers and calls through a standard protocol; call the API or CLI directly from your own tool executor; or delegate the whole subtask to another agent with its own loop and receive a typed result. |
| Interaction modes: automation · augmentation · agency | Different ways a person shares work with AI, from a fixed task to collaboration or more autonomous work. |
| Jitter | A random variation in retry timing that reduces synchronized retries. |
| JSON Schema | A machine-readable description of allowed JSON fields, types, and constraints. |
| JSON-RPC 2.0 | A message format for naming a remote method, supplying parameters, and correlating a response by ID. |
| Latency | The time taken to return a result or complete an operation. |
| Least privilege | Grant only the access a task needs. |
| Least-privilege tool configuration | Configuring each agent so it is offered only the tools, servers, and credential scopes its role's task requires, with per-server tokens that carry no more than that server needs. |
| Lifecycle phases (discovery → design → handoff → monitoring → iteration) | Five phases, each with entry criteria, the artifacts it produces, and exit criteria that must be met before the next may start. |
| LLM gateway (model router) | A service between your application and model providers for routing and shared controls. |
| LLM-as-judge | Using a model to assess an output against a defined rubric. |
| Long-context placement — where the document and question go | Context is the information sent with a model request. |
M–O
| Open explanation | Plain meaning |
|---|---|
| .mcp.json | A project configuration file describing MCP server connections. |
| Managed settings rollout (staged policy deployment) | The plan for getting the managed policy file onto every developer machine in stages — pilot, broad, enforce — with an exit check at each stage. |
| max_tokens (output ceiling) | The maximum output-token allowance for a single request. |
| max_tokens (request field) | The upper limit on generated tokens for this one request. |
| MCP — Model Context Protocol | Model Context Protocol: a standard for an application to discover and use capabilities exposed by a server. |
| MCP adapter — translate and route | The host connects the model API to an MCP client. |
| MCP client | The MCP communication component inside an assistant application. |
| MCP connection — command versus URL | The host needs a configured server location before it can discover tools. |
| MCP host | The assistant application that coordinates model calls and MCP connections. |
| MCP prompt | A reusable prompt template exposed by an MCP server. |
| MCP resource | URI-addressed context exposed by an MCP server. |
| MCP sampling | In this MCP lesson, read “sampling” as “request a model-generated response.” It does not mean read a small part of a document. |
| MCP server | A component exposing capabilities through MCP. |
| MCP server tools — externally supplied capabilities | Named operations exposed by a connected MCP server and made available by the host runtime. |
| MCP tool discovery — list does not execute | tools/list asks an already-connected MCP server to describe its tools. |
| messages (request field — the conversation) | The conversation content your code supplies, ordered from earlier to later. |
| messages.parse — request and read typed data | This SDK helper makes a model call with a schema and returns the answer as a Python object in parsed_output. |
| metadata (request field) | Optional metadata used according to the API's documented tracking contract. |
| Minimally qualified candidate (MQC) | The profile the exam is written against: an experienced practitioner who designs, implements, and governs Claude-powered solutions in production, translating business requirements into scalable, secure, reliable architectures. |
| Mixed-method evaluation — four graders, each with a job | An evaluation framework that never trusts one grader alone: deterministic checks (exact match, schema, gate fired) where the answer is crisp; LLM-as-judge with a written rubric where the output is prose; human review on a stratified sample to calibrate the judge and cover high-stakes cases; and adversarial runs for safety and security. |
| model (request field · echoed in the response) | The request identifies the model to use; the response identifies the model that answered. |
| Model mismatch — the task exceeds the tier you routed it to | A failure whose cause is the choice of model tier for a category of work, not the prompt or the data: after moving traffic to the faster tier, or for a category that needs deeper reasoning, accuracy falls only on the hard slice while simple cases stay correct. |
| Model pinning | Selecting a specific supported model identifier and managing changes deliberately. |
| Model selection matrix — tier per step, by trade-off | A table your architecture keeps that assigns a model tier (fastest, balanced, deepest) to each step of a pipeline based on measured accuracy, latency target, cost at volume, and required context. |
| Model tiering | Assigning different model configurations to different kinds of work based on evaluation. |
| Modular prompt — one shared module, assembled into many prompts | A reuse strategy where text shared by several prompts (a compliance preamble, a refusal contract, an output format) lives in one versioned module file, and a manifest says which prompts include which modules. |
| Multiple-response item ("Select TWO") | An exam item that asks for more than one correct option. |
| Native JSON outputs in a batch job (batch API vs output format) | Native JSON output means the Claude API controls the answer’s structure using output_config.format. |
| Negative control | A deliberately changed condition expected to make a test fail, used to check the test's sensitivity. |
| npx — run a package executable | npx runs an executable from an npm package, downloading the package if necessary. |
| Observability at scale (traces, spans, what to log) | Recording each agent run as a trace: one run ID at the root, one span per model call and per tool call with start, end, status, token counts from usage, stop_reason, tool name and arguments, and the parent that ties it to the run. |
| Observability tooling — logs, metrics, traces, alerts for a Claude system | The harness emits one structured event per model call and per tool call carrying trace and run ids, prompt version, model tier, index version, tools offered, retrieved chunk ids and scores, request hashes, the response's stop_reason and usage, the gate decision and rule, latency, and a PII-redacted flag. |
| Operational runbook (written before the incident) | A versioned document next to a Claude-powered service that tells the on-call engineer, under stress, what symptoms it covers, what to collect first, the triage order, the exact rollback commands, when to escalate, and what to do afterward. |
| Orchestrator–workers | A coordinator divides the current task into assignments and combines the results. |
| Output instructions (written in the prompt) — exact text and examples | Output instructions are optional sentences describing how to present an answer. |
| output_config (request field — effort · format) | Configures supported output behavior, including the schema for JSON answer text. |
P–R
| Open explanation | Plain meaning |
|---|---|
| Parallelization | Running independent work at the same time. |
| PDF to RAG — read, optionally interpret, then embed | Reading text, interpreting meaning, and creating an embedding are different jobs. |
| Pearson VUE | An examination delivery provider named in the guide's registration material. |
| Prefill — you write the beginning; Claude writes what follows | Prefill means supplying the beginning of Claude’s answer in the API request. |
| Progressive discovery vs monolithic context | Monolithic context sends every tool definition and reference document in the first request; progressive discovery sends a small starting set plus discovery tools (search_tools, search_docs, a resource index, a skill description) and adds what the model asks for to later requests. |
| Prompt caching | Reuse of processing for an eligible unchanged input prefix across requests. |
| Prompt chaining — several calls with checks between them | Your application divides a larger job into smaller model calls. |
| Prompt evaluation — measure a change with known examples | A golden set contains inputs and trusted expected answers. |
| Prompt injection — direct user attacks and hidden document instructions | Prompt injection tries to make the application follow instructions it should not trust. |
| Prompt reuse strategy — cache, module, or Skill | The three levels at which a production system reuses prompt work: prompt caching reuses the processing of a stable input prefix across requests; modular prompts reuse shared text across many prompts by assembling from one source; Agent Skills reuse a whole procedure across teams and hosts as a versioned folder. |
| Prompt rules versus output_config — why use both? | You do not need to copy the JSON schema into the system prompt. |
| Prompt template — the versioned source behind the request | Reusable instruction text with placeholders that your application fills before calling Claude. |
| Provenance | The record linking a claim or extracted value to its source. |
| Quarantine | Separating untrusted content from application instructions and authority. |
| RAG duplicates — hashes, versions, and retry-safe indexing | A hash identifies exact content. |
| RAG pipeline (ingest → chunk → embed → index → retrieve → generate) | The end-to-end system that turns documents into retrievable chunks and, at query time, supplies the few relevant chunks to the generation model as labeled evidence. |
| Rate limiting Not on CCAR-F | Restricting how quickly requests or tokens may be submitted or generated. |
| Read — Claude Code tool | Read existing file content without changing it. |
| redacted_thinking (content block — received) | An opaque reasoning block whose contents are not exposed as readable text. |
| Refund loop — order, payment, refund, answer | A multi-step tool loop returns each backend result to the model so the next requested action can use real data. |
| Regression | A previously working behavior gets worse after a change. |
| Regulatory mapping (GDPR · HIPAA · FedRAMP at the architect's level) | A table that takes each regulation a scenario names and writes the design demand it creates on data flow, residency, retention, and logging — plus the design move that answers it. |
| Requirement gathering (the capture sheet) | The discipline of writing every discovery answer as a numbered requirement row with a type (functional, constraint, SLA, data, compliance, out of scope), a named source with a date, a priority, and a design consequence. |
| REST API | A common HTTP interface exposing resources and operations through endpoints. |
| Retrieval | Finding relevant source material to supply to a model or user. |
| Retrieval strategy (matched to data shape and query pattern) | Per query, which finder to use, how many candidates to fetch, what to filter and re-rank, and whether one fetch suffices. |
| Risk register (LLM system) | A versioned document listing each named bad outcome with likelihood, impact, an owner (a role), the control, the control's class, residual risk after the control, and a review date. |
| role (message field — user | assistant) |
S
| Open explanation | Plain meaning |
|---|---|
| Safety stack (six control layers) | The ordered set of places a safety control can live around a model call: input controls, model-level instructions, tool allowlists, output validation, human approval, and audit. |
| Scaled score (100–1,000, cut score 720) | Your raw number of correct items converted onto a 100–1,000 range so that different forms of the exam, which can differ slightly in difficulty, report comparable results. |
| Scenario-based question | A question whose answer depends on the described situation and constraints. |
| Schema choices — missing, other, and unclear | These choices represent different situations. |
| Scratchpad | A working note or state artifact retained outside the immediate model context. |
| SDK compaction versus API compaction | The older notebook uses runner-side compaction_control; current Python v1 uses supported API context_management instead. |
| server_tool_use · web_search_tool_result … (content blocks — received) | Reports a request or result for a provider-hosted tool, which runs on provider infrastructure. |
| Settings precedence — a specificity cascade wrapped in a policy clamp | The rules used to combine settings from organization, command-line, project, and user sources. |
| Skill (Claude Code) | Reusable instructions that you can invoke with /name or Claude can select when relevant, unless invocation settings restrict one of those routes. |
| Skills as a reuse strategy — one procedure, many teams and hosts | Packaging a procedure that several teams were copy-pasting as an Agent Skill: a folder with a SKILL.md whose YAML frontmatter (name, description, allowed-tools, argument-hint, metadata) is parsed by the host and whose Markdown body the model reads, plus reference files for the long content. |
| Skills catalog (packaged procedures with owners) | A team index of its Claude Code skills — name, owner, trigger phrases, scope, last verified date — kept next to the skills themselves. |
| SLA design (metric · threshold · window · measurement · breach · protecting design) | Writing a performance promise as a contract: which metric, what threshold, over what window, measured from which timestamps, what happens on breach, and which architectural choice protects it. |
| SLA negotiation (SLI → SLO → SLA, each row with a design lever) | Turning 'fast and accurate' into a table of indicators (what is measured), objectives (the internal target with headroom), and contractual agreements (the number the business signs, monthly, with a consequence). |
| Slash command | The /name syntax used to invoke a command. |
| Stdio | Communication through a local process's standard input and output streams. |
| Stop sequence (stop_sequences field) | A custom output marker supplied in stop_sequences that stops generation when matched. |
| stop_details (response field — refusal details) | Additional structured stop information under the selected API's contract. |
| stop_reason (response field — the loop's switch) | Explains why this generation stopped. |
| stop_reason versus stop_sequence — deciding the next loop action | Read stop_reason to learn why an API call stopped. |
| stop_sequence (response field) | Reports the particular custom marker that matched, or null. |
| stop_sequences (request field) | A list of generated-text markers that should end generation. |
| stop_sequences in the request → stop_sequence in the response | stop_sequences is a request field listing text markers. |
| Stratified sampling | Selecting review examples from defined groups rather than only taking a random overall sample. |
| stream (request field) Not on CCAR-F | Selects event-by-event delivery instead of waiting for one completed response body. |
| Streamable HTTP | An HTTP-based MCP transport suitable for remote connections. |
| Streaming (SSE) Not on CCAR-F | Delivery of a response in events or fragments before the full response is complete. |
| Structured discovery (the question ladder) | A fixed sequence of discovery questions — outcome, current process and non-delegable decisions, volume and data shape, constraints, failure tolerance, success number — run by the architect with the business owner, ops lead, IT, and privacy before any design exists. |
| Structured output — how the API receives your format rules | ENFORCEMENT, not guidance: 'reply only in JSON' in a prompt is guidance, but output_config.format makes the API constrain the answer to your schema (exceptions: a refusal, or a reply cut off by max_tokens). |
| Structured output — three ways the JSON comes back | A tool can DO something (your harness runs it and the loop continues) or SHAPE the answer (the model fills a schema and tool_use.input is the record). |
| Structured output — which runtime? (API, Agent SDK, Claude Code, subagent, MCP) | "Structured output" means a different setting in each runtime. |
| Subagent | A worker assigned a scoped task with its own context and configured tools. |
| Subagent handoff — what the next agent actually receives | A fresh Claude Code subagent starts with only its own system prompt (the .md body), the task message the main Claude writes, CLAUDE.md, and a git status snapshot. |
| system (request field — NOT a message) | Instructions describing the task, behavior, and interpretation rules. |
| System prompt — the application’s standing instructions | GUIDANCE, not enforcement: the API-world twin of CLAUDE.md, so the model reads it and usually follows it, but no code checks it (a 'must never' needs a check in your harness code). |
T–X
| Open explanation | Plain meaning |
|---|---|
| Team environment configuration (who owns which layer) | The set of Claude Code files a team deploys together, each placed in the layer whose owner is allowed to change it: a managed policy from security, a committed project CLAUDE.md and settings.json from the team, and untouched user settings for personal preferences. |
| Temperature — how much generated choices can vary | On models that support it, temperature adjusts how strongly the model favors its most likely next pieces of text. |
| Temperature — how much generated choices can vary | On models that support it, temperature adjusts how strongly the model favors its most likely next pieces of text. |
| text (content block) | A block containing text. |
| The 4D Framework (AI Fluency) | Four responsibilities in working with AI: Delegation, Description, Discernment, and Diligence. |
| The Claude API (Anthropic's Messages endpoint) | The service interface your application calls to send a task to Claude and receive its response. |
| The Claude API response (what comes back) | The object returned by one API request, containing the result and metadata. |
| The messages array (conversation history) | The ordered conversation content you include in a Messages request. |
| The PII boundary — why instructions can't prevent, and what does | Controls on where personal information can be read, sent, or stored. |
| The tool-use handshake — who does what (model vs your code) | The sequence of tool definition, model request, application execution, and returned result. |
| thinking (content block — received) | A reasoning-related block returned according to the model and display settings. |
| thinking (request field) | Configures a supported reasoning mode for the selected model. |
| Throughput | The amount of work completed in a period of time. |
| Token optimization — reduce what enters the window | The ordered set of cuts that shrink a request's input: trim tool results to needed fields, compact history at a threshold with a state object, retrieve documents just in time instead of pre-loading, and isolate heavy steps in a subagent that returns a summary. |
| Tokens & counting them — what a token is, three ways to count, and when Not on CCAR-F | Measure request size using the provider's counting method rather than treating words as tokens. |
| Tokens in a loop — growing input, fresh output allowance | Before each API call, check the input you are about to send and leave room for the next answer. |
| Tokens versus money — two different measurements | Tokens measure model input and output. |
| Tone — exact text and examples | Tone describes the communication style. |
| Tool availability versus permission | Both are ENFORCEMENT, checked in code by Claude Code or your harness, not by the model: availability determines which tools can be requested, and permission determines whether a requested call may execute. |
| Tool poisoning | Malicious instructions placed in a tool description or related tool metadata. |
| Tool registry (where the tool list lives) | The place your application manages available tool definitions and implementations. |
| Tool runner — SDK code runs the loop | The Messages SDK runner receives model tool requests, executes your registered functions, and sends results back to Claude. |
| tool_choice (forcing tool use) | tool_choice is a request field controlling tool selection: auto lets Claude choose whether to use a tool; any requires a tool; tool selects a named tool; none forbids tool use. |
| tool_choice (request field) | Controls whether the model may choose a tool, must choose one, or must select a named tool. |
| tool_result (content block — user only) | Returns your application's result for a previous tool call. |
| tool_result (content block) | Data your application sends back to answer a tool_use request. |
| tool_use (content block — received) | A requested call containing a tool name, arguments, and correlation ID. |
| tool_use (stop reason & content block) | A response block describing a requested tool call: its name, arguments, and an ID. |
| tools (request field — what the model may request) | Definitions of operations the model may request. |
| tools[].description (tool definition field) | Explains when to use the tool, its inputs, outcomes, and side effects. |
| tools[].input_schema (tool definition field) | Describes the arguments expected by that tool. |
| tools[].name (tool definition field) | The identifier used to connect a declared tool with a requested call. |
| tools[].strict (tool definition field) | strict: true tells Claude’s API to generate this tool’s arguments only in the structure allowed by its schema. |
| Trade-off communication (ADR for engineers, memo for executives) | Communicating one architectural decision in two forms for two readers. |
| Trajectory evaluation | Assessing the steps an agent took, not only its final wording. |
| Trust boundary | A point where information or authority crosses between components with different trust levels. |
| type (response field) | Identifies the kind of object at that position. |
| usage (response field — token accounting) | Reports token accounting for the request under the provider's rules. |
| Validation and repair — format, fields, then facts | Validation is code checking a result before accepting it. |
| What to cache — the production decision | Arrange eligible repeated input to improve prompt-cache reuse. |
| When and how to compact — the production decision | Decide when to shorten history and which facts must survive. |
| Where agent names come from — built-ins, your files, plugins | The set of named agent definitions that a runtime can look up. |
| Workflow (vs agent) | A sequence or branching process whose structure is defined by application code. |
| Workflow improvement (before/after with a number) | A change to how a team works that is described as a before state with a measurement, a redesigned after state, and the same measurement taken again. |
| Workflow routing | Selecting a predefined path based on a classification or rule. |
| Workload shape (interactive vs offline · many small vs few large) | The traffic profile of a path: whether a person waits for the answer, how many calls arrive per unit time, how large each is, and how much of each request is identical to the last. |
| Worktree isolation | Using separate Git working directories so concurrent tasks edit different checkouts. |
| Write — Claude Code tool | Create a file or replace its complete contents. |
| XML tags — labels around parts of a prompt | XML-style tags are text labels such as <invoice> and </invoice>. |
| YAML — the 60-second anatomy (enough for every frontmatter) | A text format for configuration using keys, values, lists, and indentation. |