Prep for the Claude Certified Architect – Professional exam (CCAR-P): designing, integrating, evaluating, and governing production Claude systems — solution architecture, RAG, evaluation frameworks, cost and latency optimization, governance and compliance, and the stakeholder lifecycle — run-verified where it is code (RAG and eval on a real pipeline), grounded design guidance where it is architecture.
An orientation to the Claude Certified Architect – Professional exam (CCAR-P): what the credential asks of an architect, how it differs from the Foundations tier, the enterprise system this series designs end to end, and the run-verified-where-it-is-code convention behind every chapter.
How an architect turns a vague business request into a system worth building — surfacing the real problem behind the stated one, deciding honestly whether Claude is even the right tool, and aligning the design to the business value it is supposed to create.
The architectural patterns for a Claude system — the augmented LLM, the code-orchestrated workflow, and the model-controlled agent — their reliability, cost, and latency profiles, how to choose among them, and the end-to-end shape (input, processing, output, and the feedback loop newcomers omit).
Decomposing a complex Claude system into multiple agents and services at architecture scale — when a problem warrants splitting versus one agent, the orchestration strategies (supervisor, hierarchical, pipeline, parallel), complete-and-disjoint decomposition as a design property, and the real cost of over-decomposition.
Model selection as an architect's decision across a whole platform — the tiers and the quality-latency-cost triangle, routing by task so the easy majority runs cheap, how a model choice constrains which features you can use, and the operational cost of a floating alias in production.
What a system prompt actually does — role, rules, output contract, and the trusted instruction layer — the prompt techniques an architect leans on and when each earns its place, templating a prompt for reuse across a system, and the line between a prompt-level 'don't' and an enforceable guardrail.
Managing the context budget and reusing prompts economically — why the window fills, token optimization by trimming and structured tool output, and the three reuse levers (prompt caching run live at a tenth of the price, modular prompts, and Skills) applied to the bookshop platform's large stable prefix.
The mechanisms a Claude system uses to connect to everything around it — MCP servers, direct API and CLI integration, and agent-to-agent connection — what each is, when each fits, and the least-privilege discipline that decides the bookshop platform's integration mesh.
Retrieval-Augmented Generation from first principles — why an architect grounds answers in a private corpus instead of stuffing everything into context, then the full pipeline (chunking, embeddings, indexing, retrieval, grounded generation) run against the bookshop platform's real policy, catalog, and help corpus with the actual chunk counts and answers shown.
Retrieval is where RAG quality is won or lost — this chapter runs k-tuning, metadata filtering, and a real case where naive retrieval misses the answer and a wrong chunk sneaks in, then a doc_type filter fixes both, over the bookshop platform's mixed corpus, with hybrid search and reranking placed as landscape and progressive discovery weighed against monolithic context.
Securing the integrations of a tool-using Claude system — what its attack surface actually is, authentication versus authorization for tools and data, and the design discipline of least privilege: removing capabilities a role never needs rather than guarding them, enforced in code, with the accuracy-versus-latency trade made deliberately.
Why a production Claude system is harder to observe than an ordinary service — non-determinism, per-call cost, silent quality regressions, RAG retrieval quality — and the four-layer answer: structured logging, tracing the multi-step path, metrics for latency and cost and errors, and monitoring for drift, with the usage object as your cost-and-latency meter.
Evaluation from the ground up — what an eval actually is, why no serious Claude system ships or improves without one, the landscape of metrics (quality, latency, cost, safety, security) and methodologies (programmatic, LLM-as-judge, human), and how to build a dataset and run a real judge over the bookshop platform's support answers.
Two things an eval lets you do once you have one — pick between designs and debug them. A/B two system prompts on the same eval set and let the scores choose (run for real), then diagnose a bad answer to its true cause: prompt failure, hallucination, model mismatch, or the RAG-specific one everyone misses, retrieval failure — worked against the exam's stale-document scenario.
Optimization comes last — after the system is correct and measured. The levers an architect pulls for tokens, latency, and cost: output-length limits, prompt caching, batching, model routing, and trimming context. The exam's 8,000-token-prompt scenario worked, and a real prompt-caching measurement showing ~8,000 tokens served from cache on the second request.
What a guardrail actually is (a deterministic check outside the model's control) and why a production Claude system needs them, the landscape of LLM failure modes, layered guardrails at input/tool/output/monitoring, and where human-in-the-loop approval earns its cost — then the exam's focus on structural enforcement.
Compliance as an architecture problem, not a legal text — the data-handling properties a Claude system must provide (residency, retention limits, encryption, audit trails), PII minimization as a design discipline, access control and least privilege, and how GDPR, HIPAA, and FedRAMP map to classes of requirement you design for.
Bias, fairness, and transparency treated as concrete engineering decisions rather than slogans — where bias enters a Claude system, what fairness means for who the system serves, what transparency owes a user, why these matter for trust and risk, and the honest limit that you design to detect and mitigate rather than eliminate.
The architect's stakeholder work before any box is drawn — structured discovery that turns a stated want into real functional and non-functional requirements, and communicating a quality-versus-cost-versus-latency tradeoff so a business owner can actually choose.
Architecture documentation as the handoff and the memory of why — what to write down beyond the diagram, the lifecycle phases from discovery to iteration and the architect's role in each, and why a Claude system's model drift and data drift make monitoring and iteration first-class rather than afterthoughts.
Why an architect designs the team's build environment, not just the system — shared CLAUDE.md and settings for a team, slash commands and skills as encoded conventions, AI-assisted review and test and debug workflows in the pipeline, and supporting operational issue resolution.
The whole series in one system — designing, integrating, evaluating, and governing the bookshop's enterprise support platform end to end, domain by domain, followed by the exam's three sample questions worked with their rationale.