Claude Certified Architect Foundations (CCAR-F)

Worked example: design a supplier review assistant

The diagnostic above asks how a procurement team could use Claude to read supplier documents, answer policy questions and draft a structured review. Here is one way to turn that request into a design a colleague can inspect. The scenario and sample values are illustrative; they are not customer results or official exam material.

The team needs a draft, not an automated supplier decision. Its analyst selects an approved supplier case, the assistant gathers the allowed evidence and prepares a review, and a procurement manager decides whether to accept it. That single sentence establishes the system's purpose and the point where a person remains responsible.

Start with the evidence the review must contain

Suppose the sample case contains a supplier proposal, the company's current procurement policy and an approved internal record. The draft must identify the supplier, list the requirements being checked, show the source behind each finding and flag missing or conflicting evidence. It must not turn a missing document into a favorable result.

Before choosing an agent pattern, define what a usable review looks like. For a requirement such as “payment term is within the permitted range,” the result needs the proposed payment term, the relevant policy rule and references to both passages. If the policy is unavailable, the result should say that the requirement cannot yet be assessed. A fluent paragraph without those references is insufficient for the manager's decision.

This changes the architecture. The system must preserve evidence references as it processes documents; it cannot discard them and expect the final writing step to reconstruct them reliably.

Use a fixed workflow for the predictable steps

This first version can use a fixed sequence because the required activities are known: authorize the case, retrieve the permitted records, extract findings, validate the draft and send it for review. An agent that chooses arbitrary new tools is not required merely because the application uses Claude.

The access check limits which documents the service can return. Source references let the manager trace a finding to the original evidence. Application checks catch incomplete results and flag findings that still need correction or review.

If a later version must discover which of several information sources to query, an agentic step may become useful inside that boundary. Give it a bounded task and a limited set of permitted actions. The need for a more flexible search step does not give it authority to approve a supplier.

Put permission checks where a prompt cannot remove them

The application could expose a read-only tool called get_supplier_documents that accepts a supplier-case identifier. The server obtains the signed-in analyst's identity from the trusted application session and checks that the analyst may access that case. Claude should not supply a user identifier and decide whether it is authorized.

If the same document service is reached through an MCP server, the responsibility stays the same. MCP provides a standard way for an AI client to discover and use tools and resources. It does not decide which supplier cases a particular analyst is entitled to read. The service still needs an enforced access rule for each request.

Give the tool a result that distinguishes successful retrieval from a permission failure or unavailable source. For example, ACCESS_DENIED means the request is outside the user's permitted scope; SOURCE_UNAVAILABLE means the service did not obtain the document. Neither means the supplier failed the policy check. Preserving those states prevents the final draft from inventing a business conclusion from a technical error.

Define a draft that makes uncertainty visible

A useful output contract identifies the information the receiving application requires. Here is an illustrative record for one finding:

{
  "case_id": "SUP-104",
  "requirement": "Payment term is within the permitted range",
  "status": "needs_review",
  "proposed_term_days": 45,
  "policy_limit_days": null,
  "evidence": [
    {"document_id": "proposal-v2", "page": 4}
  ],
  "open_question": "The current payment-policy document was not available."
}

The null value records that the policy limit is unknown. It does not mean zero days, and it must not be silently replaced with a typical term. The manager can see what the assistant found, what it could not establish and which source supports the known value.

The application needs several checks. It checks that the result has the expected fields and value types. It verifies that referenced document identifiers belong to the authorized case and that the references exist. It also needs an appropriate content review to determine whether a cited passage actually supports the finding. Valid JSON and a real page number do not, by themselves, prove that a conclusion is correct.

Design the recovery path before adding retries

Not every failure calls for another model response. If a required field is missing from an otherwise usable draft, a bounded correction attempt may help. If the source document was unavailable, repeating the same prompt does not create that evidence. If two authorized documents disagree, the system needs a review rule rather than a confident choice between them.

The state should remain visible from the first failed component to the final message. A retrieval timeout must not become “no policy restrictions found.” That would convert an unknown result into a business assertion.

Test normal behaviour and failure handling

Create controlled test cases before asking whether the assistant is ready for normal use. The expected result should be known in advance so a reviewer can tell whether a change improved or weakened the design.

These are proposed evaluation cases for your own implementation, not reported Timo test results. Passing them would demonstrate particular behaviors under the tested conditions. It would not establish that every possible failure has been covered.

Map the design back to your CCAR-F study

The example brings the existing study domains together. Architecture and orchestration determine the fixed sequence and the boundary of any agentic step. Tools and MCP determine how authorized evidence is requested. Structured output and errors determine what the application accepts and how it represents failure. Context and evaluation determine which information reaches Claude and how you check its use. Claude Code configuration concerns the engineering environment used to build and review these components.

For your own preparation, change one condition and explain what changes in the design. What if the system must compare a hundred independent suppliers overnight? What if a policy changes while a review is underway? What if the draft can create a purchase request after approval? Each change introduces a specific decision about processing, source versions or action authorization. State that decision before adding another component.

Then try the free practice exam. They ask you to reason about related document workflows, tool boundaries and component interactions. Explain why the selected answer fits the scenario and why the alternatives fail.

Keep a small record of what you can explain

Use the supplier example as a model for your own study record. By the end of the sequence, you should have a diagram showing the request and evidence path, two tool contracts showing permitted inputs and distinct errors, a table of failure conditions and recovery behavior, and a few controlled tests with expected results. These are preparation artifacts you create; they are not documents you must submit to Anthropic as an exam requirement.

Ask a colleague to follow one request through the diagram. They should be able to identify where access is checked, which evidence supports the output and who resolves an uncertainty. If they have to infer a missing connection, revise the design note before adding more detail. This review gives you a more useful study priority than rereading every topic with equal attention.

Study the implementation decision behind each topic

Use these focused lessons when the worked example exposes a specific gap:

• How CLAUDE.md files work across a repository explains where project guidance is loaded and why written instructions are different from enforced permissions.
• Claude Agent SDK hooks explains where a tool request can be checked in an agent workflow and why a check after an action cannot undo that action.
• Claude Batch API explains how to process independent requests asynchronously and match each result to its original input.
• Reviewing a CCAR-F mock exam helps turn a wrong answer or uncertain explanation into a concrete preparation task.

Read the lesson that resolves your current uncertainty, then return to your design and make the corresponding change. These are independent Timo teaching resources; use the official exam guide to determine assessment scope.