This domain is about 20% of the exam, roughly 12 of its 60 questions.

Every point below comes from Anthropic's official documentation; each section lists its sources.

Think first Why do instructions like "be careful" fail to cut false positives in a review prompt, and what works instead?

Why it matters: Questions show a noisy review or classification prompt and ask which change improves precision and restores trust.

Precision comes from saying exactly what counts, not from asking for caution. Name the issues to report and the ones to skip, and define each severity level with examples. Noisy categories cost trust in the accurate ones too.

Term	Meaning
False positive	A flagged finding that turns out not to be a real problem.
Explicit criterion	A concrete rule for when to flag, such as a comment contradicting the code.
Confidence-based filtering	Reporting only what the model feels sure about, instead of naming categories.
REVIEW.md	A file of review-only instructions: what to flag, at what severity, what to skip.

Replace vague checks with concrete, testable conditions. "Check that comments are accurate" leaves the model guessing. A rule to flag a comment only when its claim differs from what the code does tells it precisely when to report.

"Be conservative" does not raise precision; categories do. General advice such as "only report high-confidence findings" falls short of specific categorical criteria. A model's own sense of confidence is also poorly calibrated on hard cases.

Exam trap Asking the model to report only findings it is confident about seems safe. It does not improve precision the way specific categorical criteria do.

Report bugs and security issues; skip minor style and local patterns. Write the categories down instead of filtering on confidence. Lists of paths to skip, such as generated code, lockfiles and vendored dependencies, remove more noise.

Vague instructions versus explicit criteria

Feature	Vague instruction	Explicit criterion
Comment accuracy	Check that comments are accurate	Flag only when claimed behavior contradicts the code
Which findings to post	Only report high-confidence findings	Report bugs and security; skip minor style
Behavior claims	Infer the behavior from naming	Require a file:line citation as evidence

Give each severity level explicit criteria and a code example. That keeps classification consistent. For example, reserve Important for findings that break behavior, leak data or block a rollback. Style, naming and refactoring are Nit at most.

A noisy category undermines trust in the accurate ones too. When one category produces many false positives, developers doubt the accurate findings as well. Disable that category for a while to restore trust, and improve its prompt in the meantime.

Exam trap Leaving a high false-positive category running does not just waste time on that category. It erodes confidence in accurate findings too.

Demand evidence or near-certainty for risky finding classes. Behavior claims can require a file:line citation rather than a guess from naming. Paths that need only light review can carry a rule such as reporting only near-certain, severe issues.

• Explicit criteria beat vague instructions like "check that comments are accurate".
• "Be conservative" and confidence-based filtering do not improve precision; categorical criteria do.
• High false-positive categories undermine trust in accurate ones, so pause them while fixing their prompts.
• Consistent severity needs explicit criteria with concrete code examples for each level.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Customize Code Review - Claude Code Docs

Think first When detailed instructions still give uneven results, when are examples the right fix and when are they not?

Why it matters: Questions describe inconsistent or inaccurate output and ask whether few-shot examples, clearer criteria or something else fixes it.

Examples show Claude what good output looks like, which beats describing it in the abstract. Well-chosen examples also teach judgment that carries over to new cases. They do not fix a missing tool description or guarantee a required step.

Term	Meaning
Few-shot example	An example of the output you want, given to Claude instead of abstract instructions.
Ambiguous scenario	A case where several actions look plausible and the right one needs judgment.
False positive	A reported issue that is really an acceptable pattern, not a genuine problem.
Categorical criteria	Specific, named rules for what counts, instead of general advice like being conservative.

Show the output you want when instructions alone stay inconsistent. Few-shot examples are the most effective way to get consistently formatted, actionable output. For a code review, show each finding with its location, issue, severity and suggested fix.

Use 2-4 targeted examples for ambiguous scenarios. Each example should show why one action was chosen over the plausible alternatives. Separately, few-shot examples let the model generalize judgment to novel patterns, rather than matching only the cases you listed.

Exam trap Do not assume examples only teach the model to match the cases they show. Few-shot examples let it generalize judgment to novel patterns as well.

Contrast acceptable code patterns with genuine issues. Paired examples reduce false positives and still let the model generalize. Vague advice such as "only report high-confidence findings" does not improve precision the way specific categorical criteria do.

Exam trap Telling a reviewer to "be conservative" does not improve precision; specific categorical criteria do. Separately, examples that contrast acceptable patterns with genuine issues reduce false positives.

Define each severity level with concrete code examples. Explicit criteria plus an example per level give consistent classification across reviews.

Show correct extraction from documents with varied structures. Examples can cover inline citations versus bibliographies, or narrative text versus tables. They help with informal measurements too, reducing hallucination. They also address required fields that come back empty or null.

Examples do not replace good tool descriptions or code checks. If tool selection fails because descriptions are thin, examples add tokens without fixing the cause. If a step must always happen first, examples still rely on probabilistic compliance.

Matching the fix to the cause

Problem	Root cause	Better first fix
Inconsistent output format	Relying on detailed instructions alone	Few-shot examples of the desired format
Wrong tool picked	Minimal tool descriptions	Expand the tool descriptions
Poor escalation calibration	Unclear decision boundaries	Explicit escalation criteria with examples
Required step skipped	Prompts give only probabilistic compliance	Programmatic enforcement

• Few-shot examples are the most effective fix when detailed instructions give inconsistent output.
• For ambiguous cases, use 2-4 examples that explain why one action beat the alternatives.
• Examples of acceptable code versus genuine issues reduce false positives.
• When tool descriptions are minimal, expand them first; examples only add token overhead.

Sources: Increase output consistency - Claude Platform Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i

Think first How do you guarantee an extraction always comes back as valid structured data, and what can still go wrong?

Why it matters: Questions describe an extraction task and ask which tool_choice setting or schema design gives reliable, honest output.

Defining the extraction as a tool with a JSON schema is the most reliable way to get well-formed output. tool_choice decides whether a tool call happens at all. Schema design decides whether the values are honest.

Term	Meaning
Extraction tool	A tool whose input schema is the data shape you want; you read the data from the tool_use block.
tool_choice	The setting that controls whether Claude must call a tool, and which one.
strict: true	A tool setting that constrains sampling so tool inputs always match the schema.
Nullable field	A field that may be null, so the model can admit the value is not there.

Put the schema in the tool's input and read the data from tool_use. Tool use with a JSON schema is the most reliable route to schema-compliant output. With strict: true, the input always follows the schema and the tool name is always valid.

auto allows text, any forces a tool, forced selection names one. The setting decides how much freedom Claude has to skip the tool or pick among several.

The three tool_choice settings compared

Setting	Must call a tool?	Typical use
"auto"	No, it may return text instead	Claude decides whether a tool is needed
"any"	Yes, but Claude chooses which tool	Several extraction schemas, unknown document type
{"type": "tool", "name": "..."}	Yes, the named tool	Make extract_metadata run before enrichment

Exam trap auto does not guarantee structured output, because Claude may answer in text. Use any when you have several schemas and do not know the document type.

Forced selection makes one named tool run before the others. For example, force extract_metadata before any enrichment tools. Handle the later steps in follow-up turns.

Tool use removes syntax errors, not semantic errors. Line items may still fail to add up to the total, or values may land in the wrong field. Checks such as a calculated total beside the stated total catch these gaps.

Exam trap A strict schema does not prove the numbers are right. It guarantees the shape, so semantic checks are still your job.

Use nullable fields for values a document may not contain. Some documents simply lack a value. A nullable field lets the model return null there, instead of fabricating something to fill the gap.

Exam trap Do not let the schema force a guess. When a field may be absent from the document, make it nullable so the model can return null.

Add "unclear" and an "other" value with a detail field. The unclear value covers ambiguous cases. The other value plus a detail string lets categories grow without breaking the schema. Add format normalization rules to the prompt for messy inputs.

Strict schemas allow at most 24 optional parameters per request. Every parameter not listed in required counts toward that total. Programmatic tool calling does not support tools that set strict: true.

• Tool use with a JSON schema is the most reliable way to get schema-compliant output.
• Use tool_choice: "any" when there are several schemas and the document type is unknown.
• Strict schemas stop syntax errors but not sums that fail or values in the wrong field.
• Make fields nullable when the document may lack them, so the model returns null.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Strict tool use - Claude Platform Docs · Get structured output from agents - Claude Code Docs · Structured outputs - Claude Platform Docs · Programmatic tool calling - Claude Platform Docs

Think first When will sending a failed extraction back to the model fix it, and when is another try wasted effort?

Why it matters: Questions show a failed extraction and ask whether a retry can fix it, or how to design the check that catches it.

Schemas stop malformed output, but not wrong values. Validation catches the wrong values, and a retry that carries the exact error lets the model fix them. A retry only helps when the answer is actually in the document.

Term	Meaning
Syntax error	Output that breaks the JSON schema itself, such as a bad field type or invalid JSON.
Semantic error	Output that fits the schema but is wrong, such as totals that do not add up.
Retry-with-error-feedback	A retry that adds the specific validation errors to the prompt to steer the fix.
detected_pattern	A field on each finding that records which code construct triggered it.

Tool use removes syntax errors, not semantic ones. A strict JSON schema through tool use keeps the output well formed. It cannot check that line items match the total, or that each value sits in the right field.

Syntax errors and semantic errors compared

Feature	Syntax error	Semantic error
Example	Invalid JSON or a wrong field type	Line items that do not add up to the total
Stopped by strict schemas	Yes, through tool use or constrained decoding	No, the output still fits the schema
How you catch it	The schema enforces it	A check such as a calculated total beside the stated total

Exam trap A strict schema does not prove the data is right. Values can be in the wrong field or fail to sum and still pass the schema.

Send the document, the failed extraction and the exact error. The follow-up carries all three pieces in one request. Adding the specific validation error tells the model what to fix, so it can correct itself.

Retries fix format and structure, not missing information. A format mismatch or a structural slip is fixable on the next try. If the needed fact lives only in an outside document you never provided, no retry will find it. Track which errors are which.

Exam trap Retrying more times does not help when the value is absent from the document. If the task might lack that information, make the field optional.

Extract a calculated total next to the stated total. When the two differ, the gap flags a likely error for review. A conflict_detected boolean does the same job when the document itself disagrees with itself.

A detected_pattern field shows which constructs cause findings. When developers dismiss findings, you can group them by pattern. That shows which patterns produce false positives, so you can tune the checks instead of guessing.

The SDK re-prompts on a schema mismatch, but only up to a limit. Past that limit, you get an error instead of structured data. Its subtype is error_max_structured_output_retries. Common causes are an overly complex schema or an ambiguous task.

MCP tool execution errors are meant for self-correction. A bad date format comes back in the tool result with isError: true, and the model can retry with new parameters. Protocol errors, like an unknown tool, are less likely to be fixable by the model.

• Strict schemas stop syntax errors, but not semantic errors such as totals that do not add up.
• A useful retry resends the source document and the failed output, plus the exact validation error.
• Retries fix format and structure problems, never information that is missing from the document.
• A detected_pattern field turns dismissed findings into data about false positives.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · Structured outputs - Claude Platform Docs · Get structured output from agents - Claude Code Docs · Tools - Model Context Protocol

Think first How do you decide whether a workload belongs in the Message Batches API, and how do you run it reliably?

Why it matters: Questions describe a workload's latency needs and ask whether to batch it, how often to submit, or how to handle failures.

The Message Batches API trades speed for cost: a 50% discount, but up to 24 hours to process and no latency SLA. Use it for work nobody is waiting on. Track every request by custom_id, so you can match results and resubmit only the failures.

Term	Meaning
Message Batches API	An asynchronous API that processes many requests at a 50% discount, with no guaranteed latency.
custom_id	A unique ID on each batch request, used to match each result to its request.
Blocking workflow	Work that cannot move on until the answer arrives, such as a pre-merge check.
Latency SLA	A commitment on how quickly results arrive; the Message Batches API offers none.

Half the price, with no promise on speed. All batch usage, including input, output and special tokens, gets a 50% discount. Most batches finish within 1 hour, but processing can take up to 24 hours, and there is no guaranteed latency SLA.

Exam trap A batch is not certain to finish in 24 hours. If processing does not complete in that time, the batch expires.

Blocking work goes synchronous; latency-tolerant work goes to batches. Ask whether anything waits for the answer. A pre-merge check blocks the merge, so it needs the synchronous API. Overnight and weekly analysis can wait, so batching fits.

Which API fits which workload

Workload	API	Reason
Pre-merge check	Synchronous API	Blocking: the merge waits for the result
Overnight report	Message Batches API	Non-blocking and latency-tolerant
Weekly audit	Message Batches API	Non-blocking and latency-tolerant
Nightly test generation	Message Batches API	Non-blocking and latency-tolerant

Exam trap Moving pre-merge checks to batches to save money is the wrong answer. With no latency SLA, a blocking check could wait for hours.

A batch request cannot run multi-turn tool calling. Inside a single batch request, tools cannot run mid-request and have their results returned. A task where Claude must call a tool, read its result and continue does not fit one batch request.

Results can come back in any order. Give each request a meaningful, unique custom_id to match results to requests. It must be 1 to 64 characters of letters, digits, hyphens and underscores. Results are available once all messages complete, or after 24 hours if that comes first.

Fit the submission schedule to the SLA you must meet. With up to 24 hours of batch processing, the exam guide's example submits in 4-hour windows to guarantee a 30-hour SLA. Work out total processing time against the SLA before choosing how often to submit.

Resubmit only the failed requests, after fixing them. One failed request does not affect the others in its batch. Errored requests, such as invalid requests or internal server errors, create no message and are not billed. Find failures by custom_id, then fix them, for example by chunking documents that exceeded context limits.

Exam trap Resubmitting the whole batch is unnecessary when a few requests fail, because the others were processed normally. Send only the failed documents again.

Test the prompt on a sample before sending large volumes. Refining the prompt on a sample set raises first-pass success and cuts the cost of repeated resubmissions. Also test one request shape first with the Messages API, so validation errors appear before the batch.

The Message Batches API can process many PDFs at once. Split large PDFs into chunks when needed. Size and page limits cover the whole request payload. Upload large PDFs with the Files API and reference them by file_id to keep payloads small.

• Batches cost 50% less but can take up to 24 hours, with no latency SLA.
• Use the synchronous API for blocking pre-merge checks and batches for overnight or weekly analysis.
• A batch request cannot execute tools mid-request and continue with their results.
• Match results by custom_id, and resubmit only the failed requests after fixing them.
• Refine the prompt on a sample set before batch-processing large volumes.

Sources: Batch processing - Claude Platform Docs · Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · PDF support - Claude Platform Docs

Think first Why does a second, independent Claude instance catch problems that self-review misses?

Why it matters: Questions describe a review setup that misses subtle bugs or contradicts itself, and ask how to restructure the review.

A model that wrote the code keeps its own reasoning in context, so it rarely questions it. Review works better with a fresh, independent instance, with large reviews split into focused passes, and with confidence attached to each finding for routing.

Term	Meaning
Self-review	Asking the same session that generated code to review it, with its reasoning still in context.
Independent review instance	A separate Claude instance that reviews the output without the generator's reasoning context.
Integration pass	A review pass that analyzes data flow across files, run after the per-file passes.
Attention dilution	The loss of focus one pass suffers when it reviews a large multi-file change at once.

A model rarely questions its own reasoning in the same session. It keeps the reasoning context from generation, so its earlier choices look sound to it. That is why the same session reviews its own changes less effectively than an independent instance does.

Exam trap Telling the generating session to review itself harder, or giving it extended thinking, is not the fix. An independent instance without that context catches more.

Review with an instance that lacks the generator's context. A new Claude Code session starts with a fresh context window and none of the earlier history. A non-fork subagent also starts fresh. Either can review the generated code without inheriting the reasoning that produced it.

Exam trap A forked session or forked subagent is not independent. It copies the conversation so far, including the generator's reasoning.

Run per-file passes, then a cross-file integration pass. One pass over many files dilutes attention and can produce contradictory findings. Focused passes catch local issues, and a separate pass traces data flow across files. Prompt chaining can run these steps in sequence.

The two kinds of review pass compared

Feature	Per-file pass	Integration pass
Scope	One file at a time	Across files
Looks for	Local issues	Cross-file data flow problems
Order	First, for each file	After the per-file passes

Have the verification pass report confidence per finding. Each finding then carries a confidence level, so review routing can be calibrated. Self-reported confidence is poorly calibrated on its own, so tune routing thresholds with labeled validation sets.

Exam trap A high self-reported confidence does not prove a finding is right. The agent can be confidently wrong on hard cases.

Tell reviewers what to report, not just to be careful. Instructions like "be conservative" improve precision less than specific categorical criteria. Requiring evidence, such as a file:line citation, before a class of finding is posted also cuts false positives.

Claude's managed Code Review chains independent passes. Several agents find issues in parallel, and a verification step filters out false positives. The remaining findings are deduplicated and ranked by severity, then posted. Ultrareview goes further and independently reproduces every finding.

• Self-review in the same session is weak because the model keeps its generation reasoning.
• Use an independent instance, not a fork, to review generated code.
• Split large reviews into per-file local passes plus a cross-file integration pass.
• Attach self-reported confidence to findings, but calibrate it before routing on it.

Sources: Claude Certified Architect – Foundations Exam Guide Version 1.0 · Effective July 2026 · Exam code: CCAR-F · This guide i · How Claude Code works - Claude Code Docs · Customize Code Review - Claude Code Docs · Code Review - Claude Code Docs · Find bugs with ultrareview - Claude Code Docs