CCA Professional M1: Platform & Solution Design

Three Deployment Layers — Exam-Exact Names

Three separate conversations, three different stakeholders. A decision in one layer rarely dictates the others.

Name the user before the entry point, then the entry point before the shaping/governing layers.

All Seven Primitives

Use the minimum primitives needed. A single tool call beats a team of agents when a tool call would suffice — cost scales with how heavy the primitive is, on every request.

The exam tests whether you match the right primitive to the requirement:

• "Guarantee a notification fires every time" → Hook
• "Run five sub-tasks in parallel" → Subagent
• "Distribute a standard document-review procedure to all teams" → Skill
• "Multiple AI apps need standardised access to one system" → MCP

Ownership Decomposition — The Three-Question Delegation Test

Every capability in a system lands in exactly one of three buckets:

1. What Claude does — language understanding, summarisation, planning, drafting, tool-mediated action
2. What existing systems do — anything already paid to be reliable (the order-status service, the policy engine, the rules table)
3. What humans do — judgment calls, exceptions, approvals — where being right matters more than being fast

For each capability, apply the three-question test before assigning it:

The over-assignment trap: Collapsing all three buckets into "what Claude does" makes the process more expensive, slower, and harder to debug. A deterministic rule that must be correct every time belongs to the rule engine, not a probabilistic model.

Worked example — claims triage:

• "Read the claim" → Claude (pattern-rich language work, constrained output schema)
• "Decide priority" → existing system (a deterministic rule the partner already defines)
• "Look up policy coverage" → existing system via tool use (coverage tables update; model training data goes stale)
• "Email the adjuster" → Claude drafts, email system sends, human reviews anything above a value threshold

The Four-Part Architecture

A complete architecture has exactly four parts. An answer that stops at output describes an incomplete system.

The feedback loop is the part most often omitted from answer choices that describe "a complete architecture." An architecture without it has no mechanism for detecting when it's degrading.

Feasibility Verdicts

When you run a use case through the four AI properties, you arrive at exactly one of three verdicts:

1. Feasible as scoped — the use case can be built as described
2. Feasible with constraints — buildable, but only under specific conditions (retrieval required, HITL required, scope must narrow, expectations must be set)
3. Not feasible — the use case cannot be built reliably

The exam presents ambiguous use cases and asks which verdict applies. The key is applying all four properties, not stopping at the first one that looks fine:

• A task might be deterministic-looking but require post-cutoff data → knowledge boundary → verdict shifts to "feasible with constraints (retrieval required)"
• A task might be well-defined but expect 100% accuracy → confidence ≠ correctness → verdict shifts to "feasible with constraints (HITL required)"

"Not feasible" is a correct outcome — it's the assessment doing its job, catching in design what would otherwise surface as a much costlier failure later.

The Scoping-Call Trap

"We can do that" (capability confirmed) ≠ "this is feasible" (feasibility verdict). A verdict requires volume, latency, and input-size constraints gathered first. The commitment to a build timeline must wait for the constraints — a confident capability answer is not a completed feasibility check.

Counter-intuitive arithmetic: A scary-sounding latency number (e.g. "under 30 seconds") can be trivially met at low volume. Meanwhile, a quiet detail like corpus scale or per-request cost at volume is often the actual binding constraint. Always run the numbers rather than trusting which constraint sounds scariest.

Prompt Caching Mechanics

How It Works

Caching matches on the prompt prefix — the beginning of the prompt, character for character. If the prefix matches a cached version, you get the cached result.

Cache TTL: 5 minutes by default. Prompt caching only pays off if your request frequency clears the TTL.

First-write cost: Writing a new prefix to cache costs more than a standard input token on first use. The saving only comes on subsequent hits. High-volume applications with stable prefixes benefit most.

The Placement Rule

Dynamic values must come after the static prefix. If you place a timestamp or request ID at position zero, every prefix is unique — zero cache hits guaranteed.

Wrong pattern:

[timestamp] [request-id] → [9,000 tokens of static policy] → [user message]

Correct pattern:

[9,000 tokens of static policy] → [timestamp] [request-id] → [user message]

When Caching Doesn't Help

• Request frequency is too low to clear the 5-minute TTL
• The "static" prefix actually changes per request (user names, context IDs embedded in it)
• The prompt is short enough that caching saves negligible tokens

Context Window Strategy

Positional Attention

Critical rules buried mid-context suffer from positional attention effects — the model attends most strongly to the start and end of the prompt. The fix:

• Place the most critical rules at the beginning or end of the system prompt
• Use clear structural separation between rules and reference content
• Never bury a hard constraint in the middle of 12,000 tokens of product context

What doesn't work: Repeating the rule after every paragraph, switching to uppercase, or lowering temperature. These don't change positional attention — they add noise or affect sampling randomness, not rule salience.

The Long-Document Problem

Placing a 150,000-token collection in the context window on every request causes two problems:

1. Mid-context recall degradation (content in the middle is less reliably used)
2. High cost per request

The fix is retrieval — serve only the sections relevant to each request, not the full corpus. This fixes both problems simultaneously, unlike reordering the prompt or asking the model to "read twice."

Technique Selection — When Each Earns Its Tokens

Uniform CoT application is a trap. Adding chain-of-thought to a simple field-extraction endpoint adds cost and latency with no accuracy improvement. Apply techniques per-task based on measured benefit, not as a default.

Model-Tier Discipline

The disciplined approach to model selection:

1. Test accuracy on a representative evaluation set across the model family
2. Select the smallest model that meets the accuracy target
3. Validate with ongoing evaluation to confirm it keeps meeting it

"Use the most capable model for everything" is never the correct answer. At 400,000 requests per day, the cost difference between model tiers is enormous — and if accuracy is comparable, the smallest model is the right choice.

Start with Sonnet class. Upgrade when evals show reasoning failures; downgrade when evals show the cheaper tier holds accuracy. "Best available model" is not a strategy — it's the absence of one.

Model-Tier API Patterns

"Every model swap is a release" — treat a model version change like a code release. Run the full evaluation suite against the new version before shifting traffic. Spot checks are insufficient.

Fine-Tuning — Last Resort, Not First Fix

Fine-tuning is the last step, not the first fix. The correct order:

1. Optimise the prompt — most reliability problems are prompt problems
2. Add tool use or retrieval — for knowledge boundary issues
3. Move to a stronger pattern — evaluator-optimizer, fixed workflow decomposition
4. Only then consider fine-tuning

Fine-tuning has a place at very high volume where inference cost is the real constraint, or for a consistent output format that prompting hasn't reliably solved. Fine-tuning Claude is not broadly available — confirm current options with the Anthropic account team before planning a fine-tuning approach.

Reference Architectures — Where Each Fails

Retrieval vs Live-State Principle

Retrieval is for stable knowledge — true yesterday, true tomorrow (documentation, policy text, manuals, training material).

Tool use is for live state — values a system owns and changes independently (order status, inventory levels, account balances, real-time prices).

Symptoms of the wrong choice:

• Stale chunks that contradict the database
• Results that shift with each index refresh
• Answers that don't match what the system-of-record actually holds

A better embedding model or a shorter refresh interval will not fix this — only calling the system that owns the live state directly does.

The exam trap: A retailer's assistant retrieved two chunks about the same order from different points in time. The order had shipped, been returned, and was awaiting re-dispatch — a state in neither chunk. A live order-status API existed and wasn't called. Similarity score measures semantic closeness to the query, not truth or freshness.

Module 1 Trap Patterns

Trap 3 — Platform name ≠ config: Selecting Claude Code, MCP, or Bedrock doesn't answer "how is it configured, what permissions does it have, and what integrations are wired." Naming the entry point and specifying its configuration are different claims.

Trap 11 — Architectural complexity justified by the wrong reason: Multi-agent selected because of volume, budget, or executive enthusiasm. The architecture should be driven by task structure, not any of those.

Over-assignment trap: Collapsing all three capability buckets into "what Claude does" makes the system more expensive, slower, and harder to debug. Deterministic rules that must be correct every time belong to the rule engine.

Scoping-call trap: "We can do that" is not a feasibility verdict. A verdict requires constraints gathered first — volume, latency, input size. Don't commit to a timeline before the constraints are known.

RAG-for-live-state trap: Using a retrieval index for data that changes frequently (order status, inventory) produces wrong answers that look right. The fix is tool use calling the system that owns the live state.

Key Rules to Memorise

• Four AI properties → four design consequences (non-determinism → evals, knowledge boundary → retrieval, finite context → strategy, confidence ≠ correctness → HITL)
• Three feasibility verdicts: feasible as scoped / feasible with constraints / not feasible
• Claude Code is disqualified the instant "multi-user" or "customer-facing" appears
• All seven primitives: Tool (act) / Subagent (isolate-parallelize) / Hook (guarantee) / Skill (package-a-procedure) / MCP (connect) / Agent Teams (coordinate peers) / Dynamic Workflows (compose at runtime)
• Prompt caching: dynamic values go after static prefix, not before; TTL is 5 min default
• CoT adds value on multi-step reasoning; adds cost only on simple extraction
• Model tier: smallest model that clears the accuracy bar, validated by eval; start with Sonnet class; every model swap is a release
• Ownership decomposition: Claude (language work) / existing systems (deterministic rules) / humans (judgment, exceptions)
• Four-part architecture: Input → Processing → Output → Feedback loop (the feedback loop is most often omitted)
• Three deployment layers: Entry Points / Build-time Interfaces / Delivery Routes
• Retrieval = stable knowledge; tool use = live state
• Fine-tuning is the last resort: prompt → tools/retrieval → stronger pattern → fine-tune
• GDPR compliance ≠ EU data residency requirement
• Compliance precondition override: existing signed agreement wins before any other tradeoff