The Four-Stage Architecture Shape for the CCAR-P Exam

One shape underneath every architecture

Beneath the variety of agents, workflows, and retrieval pipelines sits a single recurring shape. Every Claude-based solution can be described as four stages: input, processing, output, and a feedback loop. The Claude Certified Architect - Professional (CCAR-P) exam treats knowing this shape as a remember-level skill because it is the mental scaffold that every later analysis hangs on. When you review an architecture, walking these four stages is how you check that nothing structural is missing, and the stage most often missing is the fourth.

Input is how data and instructions enter the system: a user message, a retrieved chunk, a tool result. Processing is what Claude and the surrounding code do with that input, the reasoning, the tool calls, the transformations. Output is the delivered result. The feedback loop is what closes the system: an evaluator pass, a human review, or a logged signal that improves or corrects the next run. The first three stages are obvious in any design. The fourth is the one that distinguishes a system that can catch its own errors from one that cannot.

Input and processing: where the work is visible

Input and processing are where most design attention naturally goes. Input decisions include whether data arrives as a user message, a retrieved passage, or the result of a tool call, and this stage is where the live-versus-static data classification lands. Processing is the model's reasoning plus everything the surrounding code does around it: the tool calls it makes, the intermediate steps, the transformations applied before the output is composed. These two stages carry the obvious complexity of a system, and they are rarely forgotten because without them there is no product at all.

Output is not the finish line

The quiet failure is treating output as the end of the architecture. A design that produces a correct-looking result feels complete, so the feedback loop gets omitted. But output without a feedback loop is a system that cannot tell when it is wrong. There is no evaluator checking the result against a rubric, no human catching a bad answer before it lands, no logged signal revealing that quality has drifted since launch. The system ships, works in the demo, and then degrades silently because nothing is watching. The deeper reason the loop is not optional is that Claude is non-deterministic: the same input can produce different outputs across runs, so behaviour you saw work once in a demo is not certified for production. You cannot certify behaviour you only observed once, which is precisely why evaluation and the feedback loop exist as architectural stages rather than afterthoughts. Closing the loop is what turns a one-shot generator into a system that can catch and correct systematic error.

The feedback loop is broader than a thumbs-up

A second, subtler error is assuming the feedback loop can only mean a human clicking thumbs up or down. That is one form, but the loop is any mechanism that closes the system. An automated evaluator pass that checks output against a rubric and triggers a refinement is a feedback loop. A logged signal that surfaces low-confidence outputs for later review is a feedback loop. A human escalation path for high-stakes cases is a feedback loop. Reducing "feedback loop" to explicit user ratings misses the automated and logged forms that carry most of the work in production systems.

What the CCAR-P exam trips candidates on

The exam tests two traps. The first is treating output as the end of the architecture and omitting a feedback loop entirely. A scenario will present a clean input-to-processing-to-output diagram that looks complete, and the credited answer notices there is no evaluator, no escalation, and no logged signal, so the system has no way to catch systematic error after launch.

The second is assuming a feedback loop only means a human clicking thumbs up or down, ignoring automated evaluator passes. A scenario may claim a system "has no feedback because users don't rate responses," when an automated rubric check or a logged confidence signal would close the loop just as well. The reliable reading recognises the loop in all its forms.

Common misreadings to avoid

How this shows up on the exam

Domain 1 questions on this knowledge point present an architecture and ask what is structurally missing, or ask you to describe the shape of a proposed solution. The reliable reading names all four stages, input, processing, output, and feedback loop, and checks specifically that the feedback loop exists in some form, automated evaluator, human review, or logged signal, rather than assuming output is the end.

This shape is the scaffold for the rest of Domain 1. It feeds designing the feedback loop, which chooses between evaluator and escalation paths, and end-to-end trade-off analysis, which walks all four stages naming the trade-off at each. It also frames the five reference architectures, each of which is a particular way of filling these stages.