CCDV-F Glossary - Prompt & Context Engineering

Quick-lookup definitions for every domain, with exam context and links back to the lesson that covers each term.

Explicit Criteria: Concrete, checkable decision rules stated in a system prompt (what counts, what doesn't, how to handle borderline cases) rather than a vague goal like "be conservative" or "flag inappropriate content." Explicit criteria remove the need for Claude to infer a threshold on every call, which is what causes classification drift between similar cases.; Exam context: The exam frequently offers a longer, more elaborately-worded but still vague prompt as a distractor fix for inconsistent classification - length isn't the lever, specificity is. A related trap is filtering findings by the model's self-reported confidence instead of writing down the actual decision rule; confidence-based routing is only a valid secondary technique once explicit criteria already exist.; See also: 4.1 - System Prompts with Explicit Criteria
Precision/Recall Trade-off: The deliberate choice, in any classification-shaped prompt (flagging, extraction, routing, moderation), of which way to err on borderline cases - "when in doubt, don't flag" favors precision (fewer false positives), "when in doubt, flag" favors recall (fewer missed cases). Leaving this implicit means the model picks inconsistently case by case; naming the trade-off and stating the rule for at least one concrete borderline case makes it a deliberate design decision instead of an accident.; Exam context: Expect scenarios testing that there's no universally correct default - a spam filter and a fraud-detection trigger want opposite defaults - and that the fix for inconsistency is naming the trade-off explicitly on a named borderline case, not adding general language about being "careful" or "thoughtful."; See also: 4.1 - System Prompts with Explicit Criteria
False-Positive Trust Problem: In a multi-category system prompt (e.g. flagging "security", "correctness", and "documentation" issues), a high false-positive rate in one category damages a reviewer's trust in every category the same prompt produces, even categories running at high precision - trust is scoped to the source, not the individual category. The fix is to temporarily disable the noisy category while reworking its criteria with concrete examples, rather than leaving it active alongside categories that already work.; Exam context: Tests recognition of this as a system-prompt maintenance pattern: the exam favors "disable and rework the noisy category" over "leave it running while iterating on wording," since a half-broken category actively degrades trust in categories that are already reliable.; See also: 4.1 - System Prompts with Explicit Criteria
Tool-Constrained Output: The reliable pattern for structured output - defining a tool with a JSON Schema input_schema, forcing the model to call it, and reading the already-parsed object off the tool_use content block, instead of asking for JSON in free text and parsing the response. This eliminates syntax errors (stray preamble, trailing commas, unquoted keys) that a prompt-based "respond with JSON" approach is prone to, and the failure rate of the free-text approach worsens as schema complexity grows.; Exam context: A classic distractor patches free-text JSON parsing with a regex to strip preamble, a lower max_tokens, or a second attempt-and-compare call instead of switching to a tool schema - the tool-constrained approach is the structurally reliable fix, not a workaround.; See also: 4.2 - Structured Output and Validation Loops
tool_choice Modes: The parameter controlling how a tool call is forced, with three distinct modes: {"type": "auto"} (default) lets the model decide whether to call a tool or return plain text; {"type": "any"} forces some tool call but lets the model pick which tool, useful when the input type is unknown ahead of time; {"type": "tool", "name": "..."} forces one specific named tool call with zero flexibility.; Exam context: The exam tests this distinction directly - "auto" is wrong whenever guaranteed structured output is required, because the model may still return plain text (stop_reason: "end_turn"); "any" is correct when structured output must be guaranteed but tool selection should stay flexible across multiple candidate schemas.; See also: 4.2 - Structured Output and Validation Loops
Nullable/Optional Field (Anti-Fabrication Design): A schema-design defense against fabrication - making a field optional or nullable (e.g. "type": ["string", "null"]) whenever the source material may legitimately lack that information, and adding an escape-valve enum value like "unclear" alongside real options, so the model has an honest way to express genuine ambiguity instead of inventing a plausible-looking value to satisfy a required field.; Exam context: The exam presents "make every field required to maximize completeness" as a distractor - required fields structurally pressure the model to fabricate rather than fail the call. Remember a schema guarantees shape, not correctness; nullable fields are the mitigation specifically at the schema level.; See also: 4.2 - Structured Output and Validation Loops
Bounded Validation-Retry Loop: Code-level semantic validation (checking things a schema can't, like whether line items sum to a stated total) that, on failure, sends a corrective follow-up turn naming the specific problem - appending the original tool_use block plus a tool_result with is_error: true carrying the concrete correction - and caps retries at two or three attempts before routing to human review, rather than retrying indefinitely or silently accepting a bad value.; Exam context: The exam distinguishes a specific corrective message (which gives the model new information to act on) from a generic "try again" retry (which doesn't, and typically reproduces the same mistake), and expects a retry cap - unbounded retries against a task the model genuinely can't do are just a slower, more expensive failure.; See also: 4.2 - Structured Output and Validation Loops
Few-Shot Prompting: Locking in a format, tone, or edge-case handling by showing three to five concrete input/output examples rather than describing the pattern in prose - most valuable exactly where prose is weakest (a specific tone, a formatting convention with edge cases), because demonstration is a shorter inferential leap than description and produces less variance across calls.; Exam context: The exam pairs this with explicit criteria (4.1) as complementary, stacking techniques - criteria state the rule in words, examples show what applying it looks like on real input; neither fully substitutes for the other.; See also: 4.3 - Few-Shot Prompting for Output Consistency
Example Delimiting: Wrapping each few-shot example (and the live input) in clear tags - XML-style tags are the convention Claude is tuned to recognize - so the model doesn't confuse a demonstration example with the actual current input, which matters most when a real query happens to closely resemble one of the examples.; Exam context: A frequent distractor is "add more examples" or "remove the examples entirely" when the actual problem is unmarked examples bleeding into the live input - the fix is delimiting, not quantity. An undelimited example sitting in the same text block as the real task can get treated as more input to act on rather than a demonstration.; See also: 4.3 - Few-Shot Prompting for Output Consistency
Recency Effect (Example Order): Examples nearer the end of a few-shot block tend to weigh more heavily on the model's output than earlier examples, particularly when examples send conflicting signals. Practical implication: place the example you most need honored - often the trickiest edge case - last rather than first, and be aware that randomly rotating which example lands last will shift observed behavior even with an unchanged overall example set.; Exam context: Tests whether you recognize example order as a meaningful variable rather than an arbitrary detail - a common trap treats ordering within a few-shot set as irrelevant to the output.; See also: 4.3 - Few-Shot Prompting for Output Consistency
Progressive Summarization Trap: The compounding information loss that results from repeatedly re-summarizing an already-summarized conversation history (summary-of-summary-of-summary) as a general context-management strategy. Each pass only has access to what the previous summary chose to keep, not the original source, so anything compressed away on an earlier pass can never be recovered - and there's no visible failure signal until the agent contradicts or forgets something it had correctly established earlier.; Exam context: The exam's signature scenario is a long-running agent that starts contradicting an early, correctly-identified finding after many summarization cycles - the correct diagnosis is compounding summarization loss, not a shrinking context window, a stale cache, or a tool_choice misconfiguration.; See also: 4.4 - Context Window Management
Lost-in-the-Middle Effect: The pattern where content placed near the beginning or end of a very long context is attended to more reliably than content buried in the middle. The practical mitigation is restating a genuinely important late-session fact (a hard constraint, a corrected fact, a user preference) near the end of the context - e.g. in a reminder message just before the final turn - rather than trusting it to carry equal weight from wherever it first appeared many turns earlier.; Exam context: Expect a scenario testing whether you assume a fact stated once early in a long session automatically retains full weight later - that assumption is the trap. The fix is restating it near the end, not simply lengthening or reordering the whole context.; See also: 4.4 - Context Window Management
Stale Tool Result Trimming: The highest-leverage context-management technique in an agentic loop - replacing a large, no-longer-needed tool result (a big file read, a verbose API response) with a short placeholder once the agent has moved past needing its full content, rather than resending it unchanged on every subsequent call or repeatedly summarizing the whole conversation. Keeping a minimal placeholder (not deleting the turn outright) preserves the model's awareness that the step happened.; Exam context: The exam favors this targeted technique over a naive sliding-window trim of the oldest messages, which can discard a short, still-relevant early instruction while leaving a huge stale tool result untouched several turns later - tool results, not conversational text, are usually the actual driver of context growth.; See also: 4.4 - Context Window Management
Prompt Caching Prefix Invalidation: The cost interaction between context trimming and prompt caching - since a cache hit requires an exact byte-for-byte match up to the cache_control breakpoint, trimming or rewriting a tool result earlier in the message list invalidates the cache for every turn from that edit point onward, forcing the next call to re-process and re-pay for everything after the edit as an uncached prefix.; Exam context: Tests whether you treat trimming as a free lunch - the exam expects recognition that per-turn trimming can save input tokens on one call while destroying cache savings on the next; the practical fix is trimming in batches at natural checkpoints, with the cache breakpoint placed after the stable system prompt/tool-definitions block.; See also: 4.4 - Context Window Management