Domain 2 – Claude Models, Prompting & Context Engineering (13%)

• Model selection on capability / cost / latency / context-window trade-offs
• System prompt design, templates, and guardrails
• Zero-shot, few-shot, chain-of-thought (and when each helps)
• Context-window optimisation and token budgeting
• Prompt reuse: caching, modular prompts, Skills

CCAR-P Domain 2 · Task 2.1

What You Need to Know

Model selection = which model clears this task’s quality bar at the lowest cost that meets the latency budget. Never “which model is best”.

Five Constraint Axes

1. Capability (measured quality bar)
2. Latency (TTFT + throughput; compounds in chains)
3. Cost (price × tokens × volume → per-task unit economics)
4. Context window / output limits
5. Lifecycle & platform availability

Model Tiers (as of Oct 2026)

• Frontier — hardest reasoning / long-running agents (Fable 5.1)
• Heavyweight — complex agentic / enterprise (Opus 5.5)
• Balanced — everyday speed + capability (Sonnet 5.5)
• Fast/low-cost — high-volume classification, extraction, routing (Haiku 5.5)

Right-Sizing Per Stage

Efficiency-first (start Haiku, upgrade where measured gap) or capability-first (start Opus, optimise down). Right-size per stage, not per application. Try the effort parameter before switching tiers.

Escalation Cascades

Default to small model; escalate on low confidence / failed validation / explicit trigger. Near-big-model quality at near-small-model average cost.

Lifecycle Discipline

Pin model versions. Monitor deprecation (≥60 days notice). Re-run evals before migrating. Never let an alias silently move production.

Exam Traps

• Running everything on the biggest model “to be safe”
• Switching to smallest model without re-running quality evals
• Letting production run on an alias or soon-to-retire model
• Upgrading model because outputs are inconsistent (fix instructions first)

Practice Scenario

Document pipeline: classify (high volume), extract, write executive summary (quality-sensitive, low volume). Everything on largest model; unit cost 8× budget. Must not lower summary quality. What first?

Build Exercise: Write a Model Selection Dossier (45 min)

CCAR-P Domain 2 · Task 2.2

What You Need to Know

System prompt = standing contract (role, audience, policy, output format). User turns carry per-request data. Template = prompt with named slots. Guardrail = limit on what the model receives or returns.

System Prompt as Architectural Contract

Stable authority; cacheable prefix. Altitude rule: specific enough to guide, flexible enough for heuristics. Avoid both brittle hardcoded logic and vague high-level guidance.

Explicit Instructions + Escape Hatch

State role, audience, rules, conflict resolution, output format. Give motivation where helpful. Escape hatch = what to do when the task cannot be done honestly (null, “not enough information”). Without one, the contract forces invention.

Templates as Engineering Artefacts

Named slots → testable, versionable, reviewable. Use consistent XML tags for content types. Prompts in production are code.

Guardrails in Layers

1. Instruction-level — scope, refusal rules, tone, escape hatch
2. Input-side — validate/sanitise; delimit untrusted content as data (not instructions)
3. Output-side — schema + business-rule validation before downstream consumption

Every refusal needs a route (human queue, structured error). Instructions shape behaviour probabilistically; only programmatic validation guarantees it.

Exam Traps

• Restating standing policy in every user turn instead of system prompt
• Responding to invented-fact incidents with larger model / lower temperature
• Relying on system-prompt instructions as sole guardrail
• Keeping every schema field mandatory + “never invent” rule

Practice Scenario

Financial chatbot must answer strictly from internal policy library. Launch prompt: “You are a helpful assistant. Answer questions about company policy.” Invents clauses and answers about competitors. Single redesign that most reduces invented-clause risk?

Build Exercise: Redesign a One-Paragraph Prompt into a Layered Contract (45 min)

CCAR-P Domain 2 · Task 2.3

What You Need to Know

Escalation Ladder (cheapest first)

1. Zero-shot with clear instructions — baseline; covers most production tasks
2. Few-shot examples — 3–5 relevant, diverse, structured (XML tags)
3. Chain-of-thought / built-in thinking — multi-step reasoning only

Diagnose before adding anything. Instruction quality is the first, free fix.

Matching Technique to Failure

Failure symptom	Cheapest effective fix
Output format wrong/drifting	Few-shot with exact-format example
Inconsistent classification at boundaries	Few-shot with boundary examples
Wrong answers on multi-step reasoning	CoT or built-in thinking
Stated rules ignored	Instruction clarity & structure first
Any of the above	Never a model upgrade first

Few-Shot Properties

Relevant, diverse (edge/boundary cases), structured. Inflate every request unless in cached static prefix.

CoT / Built-in Thinking

CoT buys accuracy on multi-step reasoning; adds latency/tokens. Separate reasoning from final answer with tags. Current models have adaptive thinking (always on for Fable/Opus; default on for Sonnet/Haiku). Prompted CoT remains portable and auditable where needed.

Exam Traps

• Responding to prompt-shaped failures by moving to a larger model
• Offering CoT for a format-compliance failure
• Offering few-shot for a multi-step reasoning failure
• Enabling CoT without separating reasoning from the final answer

Practice Scenario

Support-ticket triage misroutes tickets that mention two products; JSON intermittently gains prose preamble that breaks parser. Finance will not fund larger model. Best fix?

Build Exercise: Build a Technique-to-Failure Decision Table (45 min)

CCAR-P Domain 2 · Task 2.4

What You Need to Know

Context window = everything Claude sees in one request (system, history + tool results, tool definitions, output + thinking). Every token is billed every time it appears.

Context Rot

As token count grows, accuracy and recall degrade. Capacity is not a strategy. Goal = smallest set of high-signal tokens that maximises desired outcome.

The Replay Bill

Each turn resends the whole history. At volume, careless context becomes the dominant cost line.

Management Toolkit

Strategy	What it does
Curate first	Send fields not files; summarise history; put long docs above the query
Retrieve instead of stuffing	RAG when corpus exceeds sensible context
Compact	Server-side summary of earlier turns (primary for long conversations)
Context editing	Clear oldest tool results / thinking blocks, replace with placeholders
Structure	Tight output contracts; lean deferred tool definitions

Truncation (cut to fixed token count) is not optimisation — it silently loses task-required information.

Key Concept: Caching changes what you pay, not whether tokens count toward the window. Window relief comes from curation, compaction and editing.

Exam Traps

• Moving to bigger window and loading more
• Enabling caching to relieve window pressure
• Blind truncation to a fixed token count
• Letting agentic sessions carry every stale tool result indefinitely

Practice Scenario

Contract-analysis assistant: by hour two, requests carry 150k tokens including dozens of large stale tool results; costs 6× projection; late-conversation quality degrades. What should the architect do?

Build Exercise: Write a Context Budget for a Long-Running Workflow (45 min)

CCAR-P Domain 2 · Task 2.5

What You Need to Know

Three mechanisms for three reuse questions:

Mechanism	Question it answers
Prompt caching	Stop a repeated prefix costing full price each time
Modular prompts	Stop ten features each keeping a drifting copy of the same policy
Skills	Occasional deep procedure without paying for it on every request

Prefix Mechanics

Order: tools → system → messages. Front-load stability: static system/policy/examples first, dynamic content last. A timestamp early in the prompt defeats the entire cache.

Cache Economics

• Writes carry a premium; longer TTL costs more
• Reads earn a steep discount
• Break-even within first read or two at volume
• “Cache everything” is not always correct (sporadic traffic can make write premium exceed savings)

Caching is not persistence, window relief, or a quality lever.

Modular Prompts

Versioned sections assembled from a shared library. One change propagates. Shared stable sections form common cacheable prefixes across features.

Skills & Progressive Disclosure

1. Metadata only (tiny fixed footprint) at startup
2. SKILL.md body loads only when triggered
3. Bundled resources cost nothing until read

Standing policy → cached system prompt. On-demand expertise → Skills. Per-request data → messages (after the cached prefix).

Exam Traps

• Marking content that changes every request as cached
• Offering “enable caching” for window overflow or quality problems
• Trimming few-shot or downsizing model to cut spend on a repeated static prefix
• Stuffing entire procedure library into every system prompt

Practice Scenario

Claims API: 40k requests/day. Every request sends 12k-token system prompt that opens with claim record + timestamp, then unchanging policy + few-shots. Input spend flagged; p95 misses SLA. Quality must stay. What should the architect do?

Build Exercise: Design the Reuse Layer for a High-Volume Endpoint (45 min)