CCAR-P Domain 1 Study Guide

Design End-to-End Architectures: Input → Processing → Output → Feedback Loops

Domain: Solution Design & Architecture Domain Weight: 17% Target Objective: Design end-to-end architectures (input → processing → output → feedback loops)

1. What You Need to Know for the Exam

For CCAR-P, do not think of an end-to-end Claude architecture as:

User → Claude → Answer

That is usually incomplete.

Think instead:

                    BUSINESS GOAL + CONSTRAINTS
                              │
                              ▼
┌──────────────────────────────────────────────────────────┐
│ 1. INPUT                                                 │
│ User request • documents • events • enterprise data      │
│ validation • identity • permissions • classification     │
└──────────────────────┬───────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────────┐
│ 2. PROCESSING                                            │
│ Orchestration → Context → Claude → Retrieval/Tools       │
│ Rules → Validation → State → Safety controls             │
└──────────────────────┬───────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────────┐
│ 3. OUTPUT                                                │
│ Structured answer • recommendation • action • document   │
│ citations • confidence/limitations • user experience     │
└──────────────────────┬───────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────────┐
│ 4. FEEDBACK / EVALUATION                                 │
│ Validate quality • human review • user feedback          │
│ business KPI • monitoring • errors • incidents           │
└──────────────────────┬───────────────────────────────────┘
                       │
             ┌─────────┼──────────┐
             ▼         ▼          ▼
          Correct    Escalate   Improve
          / Retry    to Human   System
             │                     │
             └──────────┬──────────┘
                        ▼
              Processing / Design

The exam-level idea

A production architecture is incomplete if it produces an output but has no mechanism to determine whether that output was good enough and what happens when it was not.

That exact principle appears in both provided practice exams.

2. The Four Core Stages

2.1 INPUT — What Enters the System?

Input is much broader than the user’s prompt.

A professional architecture determines:

What initiated the request?
Who initiated it?
What data accompanies it?
Is the input valid?
Is the user authorized to use that data/function?
Is additional enterprise context needed?
Does sensitive data need to be removed or minimized?

Typical input sources

Input type	Example
User instruction	”Summarize this claim and recommend next action.”
Uploaded document	Contract, invoice, medical note
Application event	New support ticket received
API payload	Order ID and customer details
Enterprise database	Customer/account information
RAG corpus	Policies, manuals, knowledge articles
Tool result	CRM lookup, order status
Previous state	Earlier agent/workflow results

Example

Suppose a company asks:

“Build a Claude assistant to recommend whether customer returns should be approved.”

A weak interpretation is:

Return request → Claude

A professional architect asks:

What exactly is the input?

Customer request
+ Order information
+ Product category
+ Purchase date
+ Existing return history
+ Current returns policy
+ User/customer identity

You may discover that Claude should never receive every field from the customer’s complete CRM profile.

That leads to data minimization.

3. Validate Before Claude Processes Anything

A frequent architectural mistake is treating Claude as the first component.

Often it should not be.

Raw Input
   │
   ▼
Authentication
   │
   ▼
Authorization
   │
   ▼
Schema / Input Validation
   │
   ▼
Data Classification / Minimization
   │
   ▼
Claude Processing

Why?

Some constraints are deterministic and should therefore be enforced deterministically.

For example:

“Employees from Department A must never retrieve Department B’s confidential records.”

Do not implement this as:

System prompt:
"Claude, please don't show information from another department."

The retrieval or authorization layer should simply prevent unauthorized information from reaching Claude.

This aligns with the broader CCAR-P architecture principle in the workbook: requirements expressed as “must never” belong in an enforced layer rather than being left solely to model instructions.

4. PROCESSING — Where Most Architecture Decisions Live

Processing is not equivalent to:

“Call Claude.”

A realistic processing architecture can include several components.

                        ┌───────────────┐
Input ──► Orchestrator ─► Context Builder│
                        └───────┬───────┘
                                │
              ┌─────────────────┼────────────────┐
              ▼                 ▼                ▼
          System Prompt      RAG Search        Memory
              │                 │                │
              └─────────────────┼────────────────┘
                                ▼
                              Claude
                                │
                   ┌────────────┼─────────────┐
                   ▼            ▼             ▼
                 Tool A       Tool B       Rules Engine
                   │            │             │
                   └────────────┼─────────────┘
                                ▼
                         Output Validation

The main design questions are:

A. Which architecture pattern?

Single Claude call
Augmented LLM
Workflow
Agent
Multi-agent
Hybrid combination

B. What context does Claude require?

system instructions
user input
retrieved information
tool results
conversation state
memory
examples

C. Which decisions should Claude make?

And equally important:

D. Which decisions should code make?

5. Don’t Put Every Decision Inside Claude

This distinction is extremely important for CCAR-P.

Suppose loan eligibility depends on:

Applicant age >= 18
Debt ratio <= approved threshold
Loan amount <= policy maximum
Risk category != prohibited

If these rules are explicit and deterministic:

Claude → decide whether policy passes

may be inferior to:

Claude
   │
   ├── Extract required information
   │
   ▼
Deterministic Rules Engine
   │
   ▼
Claude
   │
   └── Explain / summarize the result

Why?

Because deterministic rules are:

reproducible
testable
auditable
easier to govern

The workbook explicitly highlights scenarios where reproducibility or auditability should push decision logic into code while Claude handles language understanding or evidence generation.

Exam heuristic

Use Claude for judgment where judgment is needed. Use deterministic code for deterministic rules.

6. Choosing the Processing Pattern

This objective overlaps heavily with the next Domain 1 objective: architecture pattern selection.

Anthropic distinguishes workflows, where LLMs/tools follow predefined code paths, from agents, where the model dynamically controls its process and tool usage. Anthropic also recommends beginning with the simplest architecture that meets the requirement because increased agentic complexity typically increases latency and cost.

Decision table

Situation	Best starting pattern
One simple transformation	Single Claude call
Need grounding from external knowledge	Augmented LLM / RAG
Steps known beforehand	Workflow
Next step depends upon what is discovered	Agent
Independent work can happen simultaneously	Parallel workflow
Complex task must be dynamically decomposed	Orchestrator-worker
Output needs repeated critique/improvement	Evaluator-optimizer
Truly separate specialists/context needed	Multi-agent

Memorize this distinction

Can the processing path be defined beforehand?

YES
 │
 ├── One step → Single / Augmented LLM
 │
 └── Multiple steps → Workflow

NO
 │
 └── Claude must determine next steps
       → Agent / Orchestrator-worker

7. Example: Workflow Architecture

Business problem

An insurance company receives claim documents and needs:

information extracted,
policy rules checked,
claim summary generated,
questionable cases sent to an adjuster.

The procedure is known.

Good architecture

Claim Documents
       │
       ▼
Document Validation
       │
       ▼
Claude: Extract Claim Fields
       │
       ▼
Schema Validation
       │
       ▼
Policy / Rules Engine
       │
       ▼
Claude: Generate Case Summary
       │
       ▼
Quality / Confidence Validation
       │
      ┌┴──────────────┐
      │               │
   Accept          Exception
      │               │
      ▼               ▼
Case System      Human Adjuster
      │               │
      └──────┬────────┘
             ▼
        Outcome Data
             │
             ▼
 Evaluation / Improvement

Why workflow rather than agent?

Because the main sequence is already known.

Making Claude decide:

“What should I do next?”

provides little value while adding nondeterminism, latency, cost and operational complexity.

8. Example: Agentic Processing

Consider a technical-support assistant.

A request says:

“Our deployment fails intermittently after yesterday’s configuration change.”

The correct next action is unknown.

Claude may need to:

Understand issue
       │
       ▼
Inspect deployment status
       │
       ▼
Read logs
       │
       ▼
Hypothesis
       │
       ├── Need configuration? → inspect config
       │
       ├── Need metrics? → query monitoring
       │
       ├── Need documentation? → retrieve KB
       │
       └── Enough evidence? → generate diagnosis

The processing path depends upon intermediate findings.

That is an honest agent case.

Anthropic describes agents as operating over multiple turns, using tools, modifying state, and adapting based on intermediate results.

9. OUTPUT — More Than Claude’s Text

Another common exam mistake is treating the raw model response as the final application output.

Production architecture often needs:

Claude Response
      │
      ▼
Parse / Validate
      │
      ▼
Grounding / Policy Check
      │
      ▼
Business Formatting
      │
      ▼
Application Output

Output could be

natural-language answer
JSON structure
classification
recommendation
generated report
API request
CRM update
workflow decision
tool action
escalation packet

Ask four questions

1. Is the output structurally valid?

Example: Does returned JSON conform to the schema?

2. Is it grounded?

If the answer must come from policy documentation, can the claims be traced to the relevant policy?

3. Is the output safe and authorized?

Claude recommending something does not automatically mean the application should execute it.

4. Does a human need to review it?

Especially when output affects:

financial transactions
medical decisions
employment
credit
regulated processes
irreversible actions

10. FEEDBACK LOOPS — The Highest-Yield Part of This Objective

This is where I would put extra study attention.

Both provided practice exams deliberately present:

Input ✓
Processing ✓
Output ✓
Feedback ✗

and ask what architectural component is missing.

The correct concept is:

A feedback mechanism that evaluates output quality and routes failures for correction, retry, escalation or human review.

11. What Is a Feedback Loop?

A feedback loop answers:

Did the system produce an acceptable result, and if not, what happens next?

Basic pattern:

Input
  ↓
Processing
  ↓
Output
  ↓
Evaluate
  ↓
Pass? ─── YES ──► Deliver
  │
  NO
  ↓
Correct / Retry / Escalate
  │
  └──────────────► Processing

But CCAR-P candidates should understand several types of feedback.

12. Four Useful Feedback Loops

A. Immediate Quality Feedback

Occurs within one transaction.

Claude generates report
        │
        ▼
Validator / Evaluator
        │
   ┌────┴────┐
   │         │
 Pass       Fail
   │         │
Deliver   Revise
             │
             └──► Claude

Good for:

report generation
structured extraction
translation
code generation
document drafting

Anthropic calls one variant the evaluator-optimizer workflow: one LLM produces an answer while another evaluates it and provides feedback for iterative improvement. It is most useful where evaluation criteria are clear and iterative refinement creates measurable value.

B. Human Feedback Loop

Claude Recommendation
       │
       ▼
Human Reviewer
       │
 ┌─────┼──────┐
 │     │      │
Accept Edit  Reject
 │     │      │
 └─────┴──────┘
       │
       ▼
Capture Result
       │
       ▼
Evaluation Dataset

Useful for consequential or ambiguous cases.

Key distinction

Human review is not simply:

“Someone looked at it.”

Useful feedback should be captured and turned into:

evaluation cases
failure categories
prompt/context improvements
workflow improvements
product changes

C. Production Monitoring Feedback

Production Requests
        │
        ▼
    AI System
        │
        ▼
     Outputs
        │
        ▼
Observability
 ├── Quality
 ├── Latency
 ├── Cost
 ├── Failures
 ├── Tool errors
 └── Safety signals
        │
        ▼
Threshold breached?
        │
       YES
        ▼
Investigate → Correct → Redeploy

This connects Domain 1 with Domain 4.

The official blueprint separately expects candidates to define evaluation measures such as accuracy, latency, cost, safety and security and to monitor systems using logging and observability.

D. Business-Outcome Feedback

This is the most architect-level loop.

Imagine the original business goal was:

Reduce average customer-support resolution time by 30%.

A technically impressive system isn’t necessarily successful.

Measure:

AI Architecture
      │
      ▼
Operational Result
      │
      ▼
Business KPI
      │
      ▼
Did resolution time drop 30%?
      │
    ┌─┴─┐
   Yes  No
    │    │
 Scale  Diagnose
         │
         ▼
 Architecture / Process changes

Exam principle

Feedback should eventually connect technical system behavior back to the original business outcome.

One of your provided practice exams asks essentially this: when a business goal is “reduce manual review time by 40%,” the architecture should explicitly connect its choices to that measurable outcome and make the result evaluable.

13. Feedback Does NOT Automatically Mean “Ask Claude Again”

This is an important trap.

Suppose the output fails validation.

You have several choices:

Failure
  │
  ├── Retry Claude
  ├── Give Claude evaluator feedback
  ├── Try a different processing path
  ├── Retrieve missing context
  ├── Invoke a different tool
  ├── Escalate to a more capable model
  ├── Escalate to human
  └── Stop safely

The right response depends on why the output failed.

Example

Claude cannot answer because no policy document contains the requested information.

Bad feedback loop:

Claude doesn't know
     ↓
Ask Claude again
     ↓
Ask again
     ↓
Ask again...

Better:

Retrieval → No authoritative evidence
                  ↓
            Stop / Escalate

A feedback loop needs a termination condition.

14. Feedback Loops Need Boundaries

Especially in agent systems.

Every iterative architecture should consider:

maximum iterations
time budget
cost/token budget
completion condition
failed-tool condition
repeated-action detection
human escalation condition
cancellation
irreversible-action protection

Conceptually:

while task_not_complete:

    evaluate current state

    if success:
        return result

    if unsafe:
        stop

    if budget_exceeded:
        escalate

    choose next action
    execute

This is not about memorizing code.

The architectural point is:

Adaptivity must still operate inside controlled boundaries.

Anthropic’s more recent engineering work on agent containment similarly emphasizes limiting what autonomous systems can actually reach or affect, rather than relying only on repeated human approvals.

15. Two Different Feedback Timescales

This distinction can help eliminate exam distractors.

Runtime feedback

Happens while an individual request is executing.

Generate
   ↓
Evaluate
   ↓
Improve
   ↓
Return

Example:

evaluator critiques draft
schema validation fails
tool call fails
retrieval lacks sufficient evidence

Lifecycle feedback

Occurs across many production requests.

Production
   ↓
Logs + Evaluations + User Feedback
   ↓
Identify Failure Patterns
   ↓
Prompt / Tool / Model / Workflow Change
   ↓
Regression Evaluation
   ↓
Controlled Deployment

Professional architects usually need both.

16. The Complete Architecture Mental Model

For the exam, I recommend remembering this enhanced architecture:

                ┌─────────────────────────────┐
                │ BUSINESS OBJECTIVE          │
                │ KPI + SLA + Risk + Cost     │
                └──────────────┬──────────────┘
                               │
                               ▼
═══════════════════════════════════════════════════════════
 INPUT
═══════════════════════════════════════════════════════════

User / Event / Document / API
             │
             ▼
Identity → Authorization → Validation → Data Minimization
             │
             ▼

═══════════════════════════════════════════════════════════
 PROCESSING
═══════════════════════════════════════════════════════════

                    Orchestration
                         │
           ┌─────────────┼──────────────┐
           ▼             ▼              ▼
       Prompt &       Knowledge      State /
       Context          / RAG        Memory
           │             │              │
           └─────────────┼──────────────┘
                         ▼
                       Claude
                         │
                ┌────────┼─────────┐
                ▼        ▼         ▼
              Tools    APIs      Rules
                │        │         │
                └────────┼─────────┘
                         ▼
                  Validation / Policy

═══════════════════════════════════════════════════════════
 OUTPUT
═══════════════════════════════════════════════════════════

Structured Result / Answer / Recommendation / Action
                         │
                         ▼

═══════════════════════════════════════════════════════════
 FEEDBACK
═══════════════════════════════════════════════════════════

Evaluation
   │
   ├── Quality
   ├── Grounding
   ├── Safety
   ├── Cost
   ├── Latency
   └── Business KPI
          │
     ┌────┴────────────┐
     ▼                 ▼
   Accept          Correct/Escalate
                       │
        ┌──────────────┼────────────┐
        ▼              ▼            ▼
      Retry        Human Review   Improve System
                                     │
                                     ▼
                       Prompt / Context / Tools /
                         Workflow / Model / Data

If an exam option ignores one of these major responsibilities, ask why.

17. The Seven-Layer Production View

The Practitioner Workbook provides another useful way to inspect architecture completeness:

Layer	Main responsibility
Experience	User interaction, streaming, degraded state
Orchestration	Control flow, budgets, checkpoints
Prompt & Context	Instructions and assembled context
Knowledge	Retrieval, indexing, freshness, citations
Tools & Integration	Enterprise actions and capabilities
Governance	Policy, approvals, audit
Evaluation & Observability	Quality metrics, alarms, cost tracking

Why this matters

A question may present an architecture that seems perfectly sensible:

UI
↓
Claude
↓
RAG
↓
CRM

but omit:

authorization,
evaluation,
observability,
human review,
failure handling.

The exam may ask:

What should the architect add before production?

Look for the missing responsibility, rather than automatically adding another model or agent.

18. Architecture Should Trace Back to Business Value

The official blueprint does not isolate technical architecture from business architecture. Domain 1 also expects solutions to align with business-value pillars including efficiency, transformation, productivity, cost and performance SLAs.

Use this chain:

BUSINESS PROBLEM
      ↓
MEASURABLE OUTCOME
      ↓
FUNCTIONAL REQUIREMENTS
      ↓
NON-FUNCTIONAL CONSTRAINTS
      ↓
ARCHITECTURE
      ↓
MEASUREMENT
      ↓
BUSINESS OUTCOME

Example

Business asks:

Reduce manual contract-review effort by 50%.

Poor architecture reasoning:

“Let’s use a multi-agent architecture.”

Better:

Business KPI

Manual review time ↓ 50%

Architecture implications

Contract
   ↓
Document preprocessing
   ↓
RAG against policy clauses
   ↓
Claude extracts risks + citations
   ↓
Structured validation
   ↓
Human reviews exceptions

Feedback metrics

Time saved per contract
Error rate
Human correction rate
Escalation rate
Cost per reviewed contract

Now architecture and value are traceable.

19. Business Requirement → Architecture Translation

Use the following exam technique.

Step 1 — Identify the actual business objective

Examples:

reduce handling time
improve answer quality
automate document processing
increase throughput
reduce cost
improve employee productivity

Step 2 — Identify the binding constraints

Look for wording such as:

Requirement wording	Architecture consequence
”Must be reproducible”	More deterministic control
”Must be auditable”	Traceability + deterministic decisions
”Under 500 ms”	Avoid unnecessary serial model/tool calls
”Millions of transactions”	Unit cost and throughput matter
”Depends on what it discovers”	Agentic behavior may be justified
”Policy changes weekly”	Retrieval/fresh knowledge
”Must never expose…”	Enforce outside prompt
”Human must approve…”	Explicit human gate
”No wrong answer may reach customers”	Output validation/feedback
”Reduce review time 40%“	Measure business KPI

The Workbook explicitly presents this requirement-to-architecture reasoning as a core professional-level skill.

20. Step 3 — Select the Simplest Suitable Pattern

Anthropic’s engineering guidance says to begin with the simplest solution and add complexity only when needed. Workflows offer predictability for well-defined tasks; agents are useful where flexibility and model-directed decisions are genuinely required.

Think:

Single Call
    ↓ if insufficient
Augmented LLM
    ↓ if insufficient
Workflow
    ↓ if path cannot be predetermined
Agent
    ↓ if genuine decomposition/isolation/parallel specialists required
Multi-Agent

This is not an absolute product ladder.

It is an exam-thinking ladder:

Don’t pay for architectural complexity unless the requirement demands it.

21. Step 4 — Design Failure Paths Before Declaring the Architecture Complete

For each component, ask:

What if it fails?

Retrieval fails

No relevant evidence
→ "not found"
→ clarify or escalate

Claude returns malformed output

Schema validation fails
→ controlled retry
→ escalate after threshold

Tool unavailable

Tool error
→ retry/backoff
→ degraded mode

Human rejects answer

Capture reason
→ correction
→ evaluation case

Quality decreases in production

Monitoring detects regression
→ alert
→ investigate
→ evaluate
→ rollback/improve

This transforms a demo into a production architecture.

22. Three Feedback Loops Candidates Often Confuse

Loop 1 — Agent execution loop

Claude
 ↓
Tool
 ↓
Observation
 ↓
Claude

Purpose: finish a task.

Loop 2 — Evaluator/optimizer loop

Generate
 ↓
Evaluate
 ↓
Critique
 ↓
Regenerate

Purpose: improve an output.

Anthropic explicitly documents this pattern.

Loop 3 — Production improvement loop

Production
 ↓
Measure
 ↓
Analyze failures
 ↓
Improve system
 ↓
Evaluate
 ↓
Redeploy

Purpose: improve the system over time.

Exam warning

Do not assume the word “feedback” always means an agent tool loop.

Read what is being fed back, why, and at which lifecycle stage.

23. Example 1 — Customer Returns Assistant

Requirement

An e-commerce company wants to reduce manual return-processing time by 60%.

Architecture

Customer Return Request
          │
          ▼
Identity + Request Validation
          │
          ▼
Retrieve Order Details
          │
          ▼
Retrieve Current Return Policy
          │
          ▼
Claude
 ├─ Understand reason
 ├─ Match policy evidence
 └─ Produce recommendation
          │
          ▼
Deterministic Policy Checks
          │
     ┌────┴─────┐
     │          │
Clear case   Ambiguous/high-value
     │          │
     ▼          ▼
Auto flow   Human Review
     │          │
     └────┬─────┘
          ▼
Return Outcome
          │
          ▼
Feedback
 ├─ Human override rate
 ├─ Policy-grounding accuracy
 ├─ Resolution time
 ├─ Customer escalation rate
 └─ Cost per resolved return

Why this design is stronger

It separates:

language understanding → Claude
policy enforcement → deterministic layer where appropriate
ambiguity → human
quality → feedback
success → business KPI

24. Example 2 — Executive Report Generation

Requirement

Generate weekly executive reports from changing enterprise data.

Scheduled Event
      │
      ▼
Authorized Data Collection
      │
      ├─ Sales
      ├─ Operations
      └─ Support
      │
      ▼
Normalize Data
      │
      ▼
Claude Generates Report
      │
      ▼
Evaluator
 ├─ Completeness
 ├─ Unsupported claims
 ├─ Required sections
 └─ Data reconciliation
      │
  ┌───┴────┐
 Pass     Fail
  │         │
  │      Feedback
  │         │
  │      Regenerate
  │
  ▼
Executive Report
      │
      ▼
Human Corrections
      │
      ▼
Evaluation Dataset

This scenario is particularly relevant because your practice exam uses almost this exact architecture and asks what is missing when input, processing and output exist but output quality isn’t checked.

25. Architectural Pattern + Feedback Matrix

Pattern	Typical feedback
Single call	schema/quality validation
Augmented LLM	grounding/citation verification
Workflow	step validation + exception handling
Agent	observations + termination/budget controls
Multi-agent	worker validation + aggregation evaluation
Evaluator-optimizer	explicit critique/revision loop
Human-in-loop	approval/rejection/correction
Production system	metrics + incidents + business KPI

This is a useful way to avoid thinking that feedback is one universal component.

26. Architecture Anti-Patterns Likely to Appear as Distractors

Anti-pattern 1 — Bigger model fixes architecture

Scenario:

Outputs are not being validated.

Distractor:

Upgrade to the most capable Claude model.

Wrong.

The problem is the missing feedback/validation mechanism, not necessarily model capability.

This is exactly how the supplied practice questions structure distractors.

Anti-pattern 2 — More tokens fix architecture

Scenario:

No mechanism detects low-quality outputs.

Distractor:

Increase context length.

Wrong.

Context does not replace evaluation.

Anti-pattern 3 — Multi-agent by default

Simple business task
    ↓
5 agents
    ↓
Coordinator
    ↓
Reviewer
    ↓
More cost + latency

Sophistication ≠ correctness.

Anthropic recommends adding complexity only where it creates measurable value.

Anti-pattern 4 — Human review without feedback capture

AI → Human → Done

Better:

AI
 ↓
Human
 ↓
Correction / Rejection Reason
 ↓
Evaluation Dataset
 ↓
System Improvement

Anti-pattern 5 — Retry forever

Fail → Retry → Fail → Retry → ...

Every feedback loop needs:

success criteria
retry limit
cost/time boundary
escalation path

Anti-pattern 6 — Let Claude enforce hard business policy

For:

Must never refund more than $500 automatically.

Weak:

System prompt:
"Never refund > $500."

Better:

Claude proposes refund
       ↓
Authorization / Policy Gate
       ↓
amount <= $500?
   │          │
  yes         no
   │          │
execute     human approval

27. How the Practice Exams Suggest This Will Be Tested

Across the two supplied practice exams:

each exam contains 63 questions
each contains 11 Domain 1 questions
11/63 ≈ 17.5%, closely matching the official 17% Domain 1 weighting
both test the same underlying architecture concepts with different industries and option ordering

The repeating Domain 1 themes are:

workflow vs. agent
augmented LLM vs. unnecessary multi-agent
input → processing → output → feedback
decomposition
business-value alignment
NFRs such as latency
avoiding over-engineering
orchestration based on actual dependencies

This strongly suggests the exam preparation strategy should emphasize scenario diagnosis, not memorized definitions.

28. How to Read a CCAR-P Architecture Question

Use this sequence.

Step 1 — Read the business constraint

Ignore the industry’s decorative details initially.

Ask:

What’s the requirement that actually decides the architecture?

Step 2 — Identify what exists

Input?
Processing?
Output?
Feedback?

Step 3 — Identify what is missing

Possibilities:

authorization
retrieval
orchestration
validation
human review
feedback
monitoring
business measurement
failure handling

Step 4 — Find the simplest option fixing that exact gap

Don’t select a technically impressive option addressing a different problem.

29. Exam Decision Tree

START
 │
 ▼
What business outcome is required?
 │
 ▼
What constraints bind the design?
 │
 ├─ latency
 ├─ accuracy
 ├─ cost
 ├─ compliance
 ├─ reproducibility
 └─ adaptability
 │
 ▼
Is one model call enough?
 │
 ├─ YES → Single/Augmented LLM
 │
 └─ NO
      │
      ▼
Can steps be predefined?
      │
   ┌──┴──┐
  YES    NO
   │      │
Workflow Agent
          │
          ▼
Need genuine decomposition /
isolation / parallel specialists?
          │
       ┌──┴──┐
      NO     YES
      │       │
 Single    Multi-agent /
 Agent     Orchestrator-worker
          │
          ▼
Define output validation
          │
          ▼
Define feedback mechanism
          │
          ▼
Define failure/escalation path
          │
          ▼
Measure business outcome

30. Exercise 1 — Complete the Missing Architecture

This is more directly aligned to the CCAR-P Professional objective than the Foundations site’s implementation-heavy “Build Exercise.”

Scenario

A healthcare organization wants Claude to create a clinical visit summary.

Current design:

Doctor Notes
     ↓
Claude
     ↓
Clinical Summary
     ↓
Electronic Health Record

Your task

Identify at least six missing architectural concerns before production.

What this exercise teaches

You are practicing the architect’s question:

“What responsibilities are missing?”

rather than:

“Which Claude API should I call?”

That is much closer to the CCAR-P cognitive level.

31. Exercise 2 — Architecture Pattern Challenge

For each business problem, choose:

pattern,
input,
processing,
output,
feedback,
primary NFR,
reason alternatives are worse.

Scenario A

Classify 100,000 support messages overnight.

Likely:

Pattern: batch + single Claude call/classification workflow.

Primary concern:

Throughput + cost

Not an autonomous agent.

Scenario B

Investigate unexplained application failures where required diagnostic steps depend on evidence discovered during troubleshooting.

Likely:

Pattern: agent.

Reason:

Next action depends on intermediate findings.

Scenario C

Generate legally reviewed customer notices using a known four-stage procedure.

Likely:

Pattern: workflow.

Add:

Claude Draft
   ↓
Validation
   ↓
Legal/Policy Check
   ↓
Human Approval

Scenario D

Produce a high-quality executive proposal that can be iteratively improved against a well-defined rubric.

Likely:

Pattern: evaluator-optimizer.

Anthropic identifies evaluator-optimizer as suitable when explicit evaluation criteria exist and iterative critique reliably improves the result.

32. Five CCAR-P-Style Practice Questions

These are new practice questions created for study, not real certification questions.

Question 1 — Missing Component

A financial-services team designs a Claude assistant as follows:

Customer request
→ Retrieve account data
→ Claude generates recommendation
→ Recommendation displayed to analyst

Testing shows that unsupported recommendations occasionally reach analysts because nothing checks whether the recommendation is grounded in retrieved evidence.

Which architectural change most directly addresses the problem?

A. Upgrade to the most capable Claude model. B. Increase the amount of retrieved context. C. Add an output evaluation/verification feedback stage that checks grounding and routes failed outputs for correction or review. D. Replace the system with a multi-agent architecture.

Correct answer: C

Why

The architecture already has:

Input ✓
Processing ✓
Output ✓
Feedback/validation ✗

The stated failure is unchecked output quality.

Therefore solve that exact gap.

A larger model may improve results but doesn’t create verification. More context may help or hurt and still doesn’t guarantee grounding. Multi-agent architecture adds complexity without directly addressing the missing control.

Exam clue

When the stem says:

“nothing detects incorrect output”

think:

feedback / validation, not “better model.”

Question 2 — Runtime vs. Business Feedback

A retailer implements a returns assistant and reports 96% model accuracy. Six months later, management says the project has not reduced manual processing effort, which was the original business objective.

What was most clearly missing from the end-to-end architecture?

A. A larger context window. B. A feedback mechanism connecting system performance to measurable business outcomes such as manual processing time. C. Additional specialized agents. D. A more detailed system prompt.

Correct answer: B

Why

Technical accuracy is only one measurement.

Original goal:

Reduce manual effort

Therefore the end-to-end success loop needs:

Architecture
→ Production
→ Manual effort measurement
→ Compare against baseline
→ Improve architecture/process

A technically good model can still deliver poor business value.

Remember

Architecture metrics should trace back to business outcomes.

Question 3 — Deterministic Rule vs. Claude Decision

An insurance workflow requires that refunds above $5,000 must always receive manager approval. The current design tells Claude in the system prompt never to approve such refunds automatically.

Which design is strongest?

A. Make the instruction more explicit and repeat it several times. B. Use a larger model that follows instructions more reliably. C. Enforce the $5,000 threshold programmatically before the refund tool can execute, while Claude can recommend or explain the action. D. Let Claude execute the refund and alert a manager afterward.

Correct answer: C

Why

“Must always” represents a hard policy requirement.

Architecture:

Claude recommendation
       ↓
Programmatic policy gate
       ↓
amount > $5,000?
   │             │
  YES            NO
   │             │
Manager        Continue
Approval

The Workbook’s professional-level framing likewise places absolute constraints in enforced layers rather than treating model instructions as equivalent to hard controls.

Exam trap

Prompt guardrail ≠ deterministic enforcement.

Question 4 — Choosing the Processing Architecture

A software operations team is building a troubleshooting assistant. Depending on the evidence it discovers, the assistant may inspect logs, query metrics, review configuration, retrieve documentation, ask a user for clarification, or stop.

Which end-to-end processing architecture is most appropriate?

A. Fixed workflow with exactly the same tool sequence every time. B. Agentic architecture where Claude determines subsequent actions from intermediate observations, operating within defined tool, time and iteration boundaries. C. One very large prompt containing every possible troubleshooting procedure. D. Multi-agent architecture because multi-agent designs are inherently more reliable.

Correct answer: B

Why

The key phrase is:

“Depending on the evidence it discovers…”

The next processing step cannot be fully predetermined.

That is the strongest signal for an agent.

Anthropic distinguishes agents from predefined workflows precisely by whether the model dynamically controls its process and tool usage.

But notice the answer also contains:

defined tool, time and iteration boundaries.

Agentic does not mean unbounded.

Question 5 — Best Feedback Response

A Claude-based report generator retrieves reliable source material and generates an executive report. An evaluator finds that the report is missing two required sections but otherwise meets the quality rubric.

What is the most appropriate feedback-loop behavior?

A. Discard the entire architecture and use a multi-agent system. B. Deliver the report because most sections are correct. C. Return the evaluator’s specific feedback to the generation stage for targeted revision, then re-evaluate against the completion criteria. D. Re-run exactly the same request repeatedly until a different response appears.

Correct answer: C

Why

This is an excellent evaluator-optimizer use case:

Generate
   ↓
Evaluate against explicit rubric
   ↓
Missing sections
   ↓
Provide targeted feedback
   ↓
Revise
   ↓
Re-evaluate

Anthropic describes evaluator-optimizer as one model producing a response and another providing evaluation and feedback through an iterative loop, particularly where clear evaluation criteria exist.

D is merely blind retry.

Key distinction

Retry:
"Try again."

Feedback:
"These specific criteria failed; correct them."

33. Most Important Exam Traps

Trap 1

Problem: Missing validation Distractor: Bigger model

Architecture problem → architectural fix.

Trap 2

Problem: Fixed process Distractor: Agent

Known sequence → workflow.

Trap 3

Problem: Variable next step Distractor: Massive fixed workflow

Discovery determines next action → agent.

Trap 4

Problem: Hard safety/security/business constraint Distractor: Put it in the system prompt

“Must never” → deterministic/enforced control.

Trap 5

Problem: Bad output reaches user Distractor: Add more input/context

Missing feedback → add evaluation/validation.

Trap 6

Problem: Technical metric looks good, business value doesn’t Distractor: Optimize model further

Measure original business KPI.

Trap 7

Problem: Simple requirement Distractor: Multi-agent

Complexity must be justified by actual coordination/decomposition needs.

Anthropic’s own guidance emphasizes matching complexity to the problem rather than defaulting to agents or multi-agent systems.

34. What to Memorize vs. What to Understand

Memorize

Core chain

Input → Processing → Output → Feedback

Architecture rule

A system that produces output but cannot determine whether the output is acceptable is incomplete.

Pattern rule

Known path → workflow. Unknown/data-dependent path → agent.

Enforcement rule

Hard requirement → code/policy/authorization, not prompt alone.

Feedback rule

Evaluate → correct/retry/escalate → learn.

Understand rather than memorize

You should be able to look at any scenario and identify:

What is the business outcome?
What are the binding NFRs?
What enters the system?
What should Claude do?
What should deterministic code do?
What tools/data are required?
What is the resulting output?
How is that output validated?
What happens when validation fails?
When is a human required?
How does production feedback improve the system?
How do we know the original business goal was achieved?

If you can answer those twelve questions comfortably, you understand this CCAR-P objective at the level the practice material is targeting.

35. One-Minute Revision Card

END-TO-END CLAUDE ARCHITECTURE

1. INPUT
   User/event/document/API
   + identity
   + authorization
   + validation
   + minimum required data

2. PROCESSING
   Choose simplest suitable pattern
   + prompt/context
   + RAG
   + Claude
   + tools
   + deterministic rules
   + state

3. OUTPUT
   Answer / JSON / recommendation / action
   + schema validation
   + grounding
   + policy checks
   + human review where required

4. FEEDBACK
   Evaluate quality
   → accept
   → retry/revise
   → escalate
   → human review
   → capture failures
   → improve system

5. BUSINESS LOOP
   Measure technical metrics
   + business KPI
   + SLA
   + cost
   + risk

EXAM RULE:
Do not choose a more sophisticated architecture
when a simpler one satisfies the requirement.

Design End-to-End Claude AI Architectures: CCAR-P Exam Guide

CCAR-P Domain 1 Study Guide

Design End-to-End Architectures: Input → Processing → Output → Feedback Loops

1. What You Need to Know for the Exam

The exam-level idea

2. The Four Core Stages

2.1 INPUT — What Enters the System?

Typical input sources

Example

3. Validate Before Claude Processes Anything

Why?

4. PROCESSING — Where Most Architecture Decisions Live

A. Which architecture pattern?

B. What context does Claude require?

C. Which decisions should Claude make?

D. Which decisions should code make?

5. Don’t Put Every Decision Inside Claude

Exam heuristic

6. Choosing the Processing Pattern

Decision table

Memorize this distinction

7. Example: Workflow Architecture

Business problem

Good architecture

Why workflow rather than agent?

8. Example: Agentic Processing

9. OUTPUT — More Than Claude’s Text

Output could be

Ask four questions

10. FEEDBACK LOOPS — The Highest-Yield Part of This Objective

11. What Is a Feedback Loop?

12. Four Useful Feedback Loops

A. Immediate Quality Feedback

B. Human Feedback Loop

Key distinction

C. Production Monitoring Feedback

D. Business-Outcome Feedback

Exam principle

13. Feedback Does NOT Automatically Mean “Ask Claude Again”

Example

14. Feedback Loops Need Boundaries

15. Two Different Feedback Timescales

Runtime feedback

Lifecycle feedback

16. The Complete Architecture Mental Model

17. The Seven-Layer Production View

Why this matters

18. Architecture Should Trace Back to Business Value

Example

19. Business Requirement → Architecture Translation

Step 1 — Identify the actual business objective

Step 2 — Identify the binding constraints

20. Step 3 — Select the Simplest Suitable Pattern

21. Step 4 — Design Failure Paths Before Declaring the Architecture Complete

Retrieval fails

Claude returns malformed output

Tool unavailable

Human rejects answer

Quality decreases in production

22. Three Feedback Loops Candidates Often Confuse

Loop 1 — Agent execution loop

Loop 2 — Evaluator/optimizer loop

Loop 3 — Production improvement loop

Exam warning

23. Example 1 — Customer Returns Assistant

Requirement

Architecture

Why this design is stronger

24. Example 2 — Executive Report Generation

Requirement

25. Architectural Pattern + Feedback Matrix

26. Architecture Anti-Patterns Likely to Appear as Distractors

Anti-pattern 1 — Bigger model fixes architecture

Anti-pattern 2 — More tokens fix architecture

Anti-pattern 3 — Multi-agent by default

Anti-pattern 4 — Human review without feedback capture

Anti-pattern 5 — Retry forever

Anti-pattern 6 — Let Claude enforce hard business policy

27. How the Practice Exams Suggest This Will Be Tested

28. How to Read a CCAR-P Architecture Question