- In short
- A usable architecture brief states four things before any pattern is chosen: the capability gap, the data involved (live vs static), the acceptable error cost, and the target user of the output. Missing any one forces the architect to guess, and guesses compound into rework. A good brief is falsifiable, another architect reading it can predict roughly what system will be proposed.
The document that comes before the pattern
The discovery steps, is it AI-shaped, is the data live or static, what capability is missing, automate or augment, each produce a fact. The architecture brief is where those facts are assembled into a single, falsifiable statement of the problem. The Claude Certified Architect - Professional (CCAR-P) exam treats compiling this brief as an apply-level skill because it is the last thing that happens before pattern selection, and its completeness determines whether every downstream decision rests on facts or on guesses. Name a pattern before the brief exists and you have committed to a shape without knowing what data it handles, how wrong it is allowed to be, or who reads its output.
A usable brief states four things: the capability gap (what the solution must do), the data involved and whether it is live or static, the acceptable error cost, and the target user of the output. These four are not a checklist for its own sake, they are precisely the inputs that later pattern and reference-architecture choices consume. Data ownership decides retrieval versus tool call; error cost and user decide automation versus augmentation and model tier; the capability gap decides which shape fits at all.
- Architecture brief
- A falsifiable statement of a business problem, written before any pattern is chosen, that captures four elements: the capability gap the solution fills, the data involved and whether it is live or static, the acceptable error cost, and the target user of the output. Missing any element forces the architect to guess, and guesses compound into rework.
Why all four elements are load-bearing
Each of the four elements removes a specific class of downstream error. Omit the capability gap and you cannot choose a shape, because you do not know what the system is for. Omit the data classification and you risk the live-state trap, retrieving what should be fetched with a tool call. Omit the acceptable error cost and you cannot decide the human-in-the-loop posture or the model tier, so you default, expensively, to the safest or the most capable option. Omit the target user and you cannot judge the output contract, tone, or entry point, because "correct for an internal analyst" and "correct for a customer" are different bars.
Missing any one of these forces a guess, and the guesses do not stay small. A guessed data classification becomes a retrieval pipeline that has to be torn out when the data turns out to be live. A guessed error cost becomes an automation posture that a compliance review rejects. The brief is cheap to get right and expensive to get wrong, which is exactly why it precedes the pattern.
Binding constraints belong in the brief
The four elements assume a design space in which cost, ergonomics, and build effort are free to compete on their merits. In regulated settings they are not. When a partner is bound by attorney-client privilege, HIPAA, GDPR, data residency, or an internal cloud policy, that constraint eliminates entry points and delivery routes before any other tradeoff is weighed, so a brief that leaves it unstated invites a design a compliance review will later reject. A usable brief in these settings names the binding governance constraint alongside the four elements, and names it precisely enough to rule options out early: the consumer product excluded, the delivery route pinned to a covered region, the surface the firm can audit end to end. The discipline is to let the constraint eliminate choices before preferences do, rather than discovering three months into a build that the chosen surface was never eligible.
Falsifiability is the quality bar
A brief is good when it is falsifiable: a second competent architect reading it should be able to predict, roughly, what system you will propose. If two architects would design wildly different systems from the same brief, the brief is still too vague and has deferred the real decisions to the design phase. Falsifiability is the test that separates a brief that constrains the design from a mission statement that does not. "Make support better" fails the test; "draft first-pass replies to reversible, low-stakes tickets over a static policy corpus, reviewed by a support agent" passes it, because the shape it implies is legible.
The brief is revisited, not carved in stone
A brief is written from discovery, and discovery is imperfect. Downstream design frequently reveals that an assumption in the brief was wrong, most often that a piece of "static knowledge" is actually live state. When that happens, the correct move is to revise the brief and let the corrected fact flow forward, not to patch around it inside a design built on the old assumption. Treating the brief as a one-time document rather than a living one is how a discovered mismatch turns into rework instead of a quick correction.
What the CCAR-P exam trips candidates on
The exam tests two traps. The first is jumping straight to naming a pattern, "let's build an agent," before the brief captures data ownership and error cost. The trap is that naming a pattern feels like progress, but a pattern chosen without the brief is a guess dressed as a decision. The credited answer insists the four elements be captured first, because the pattern is a consequence of them.
The second is treating the brief as a one-time document instead of revisiting it when downstream design reveals a mismatch, such as discovering data is live, not static. A scenario will show a late discovery that contradicts an early assumption and offer a local patch as the fix. The reliable reading returns to the brief, corrects the fact, and lets the correction propagate, because the alternative is building further on a false premise.
Worked example
An architect is handed: 'Build an agent that answers employee questions about benefits.' They begin sketching an agentic loop. A colleague asks to see the brief first. What should the brief capture, and what might it change?
Pause the pattern choice. "Build an agent" names a shape before any of the four brief elements are established, which is the jump-to-pattern trap. The right first move is to write the brief. The capability gap is answering employee benefits questions, likely a synthesis-and-retrieval need over reference material. The data must be classified: benefits policy text is static and safe to retrieve, but "how many vacation days do I have left" is live state owned by an HR system and needs a tool call. The acceptable error cost is moderate to high, a wrong benefits answer can mislead an employee about pay or leave, and the target user is an internal employee, which sets the tone and entry point.
Writing those four elements immediately changes the design. The presence of live-state questions means the "agent" is not a pure retrieval system; it needs a tool call to the HR system for personal balances, alongside retrieval for static policy. The moderate-to-high error cost argues for showing sources and possibly flagging low-confidence answers rather than fully automating. None of this was visible from "build an agent," and all of it falls out of the brief.
Had the architect proceeded straight to an agentic loop, the live-state questions would have been answered from stale retrieved snapshots, exactly the failure the brief's data classification prevents. And if that mismatch had surfaced only during testing, the fix would be to revise the brief, not to bolt a tool call onto a design premised on everything being retrievable.
Common misreadings to avoid
Misconception
Naming the pattern first, then filling in the details, is a reasonable way to start.
What's actually true
Misconception
Once the brief is written, it is fixed and the design proceeds from it unchanged.
What's actually true
How this shows up on the exam
Domain 1 questions on this knowledge point present a hastily named pattern or an incomplete problem statement and ask what is missing before design can proceed. The reliable reading names the four brief elements, capability gap, data (live vs static), acceptable error cost, and target user, insists they precede pattern selection, and revisits the brief when a later discovery contradicts an early assumption.
The brief consumes live state vs static knowledge and automation vs augmentation, and it draws its capability gap from pain point to capability mapping. It feeds forward into the four-stage architecture shape and the three-bucket decomposition, and its error-cost element ties to gating value claims with evaluation.
A stakeholder says: 'Let's build a RAG system to answer sales reps' questions about deals.' Before agreeing, which set of facts must the brief capture to make the design decision defensible?
People also ask
What belongs in an AI architecture brief?
Why write the brief before choosing a pattern?
What makes an architecture brief falsifiable?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.