Claude Certification Blog
Retry, batch and review: one idea at three scales on CCAR-F
Three objectives inside the largest prompt-and-output domain on CCAR-F share one idea: whether the second attempt knows anything the first one did not.
Prompt Engineering and Structured Output is 20% of CCAR-F — about 12 of 60 items — and three of its objectives get less attention than the rest: validation and retry loops, batch processing strategies, and multi-instance review architectures. They look unrelated and they are the same question asked at three scales.
What the second attempt knows
| The second attempt | What it must know that the first did not |
|---|---|
| A retry | What was wrong with the first attempt |
| A batch run | Which items failed, so the rest still count |
| A review pass | A different question from the one already asked |
Read that column and the distractors write themselves. An option that repeats an attempt without adding anything is offering a lottery ticket, and it appears in this domain in three costumes. The other three objectives in the same domain — explicit criteria, few-shot examples and structured output — are covered in prompt engineering on the exams and tool use and structured output.
Retry loops that learn nothing
A transient failure is the easy case — nothing was wrong with the request, so repeating it unchanged is correct. A rejected output is different: a validator has told you something specific, and a second attempt that does not carry that information is drawing again from the same distribution and hoping.
This is why the objective pairs validation with feedback rather than with retry alone. The loop that works is produce, check, and on failure say what failed — which is the same structure as error propagation between components, covered in troubleshooting on the Claude exams.
When a retry is not safe
The third rung is the one people miss because it is not about quality at all. Where an operation has an effect in the world — a message sent, a record written, a payment made — a timeout tells you no answer came back, not that nothing happened.
So repeating it safely is a property you build in, not an assumption you make. An option that lengthens a timeout has narrowed the window in which the ambiguity arises without removing it, which is a smaller version of the same distractor: doing something plausible that leaves the actual problem in place.
Ask what the retry was told
One question resolves most of these items. Between the first attempt and the second, what changed? If the answer is nothing, the option is a repeat rather than a retry, however many times it is allowed to run.
Batch: the deadline decides
Deferred processing trades immediacy for cost. Volume makes the saving larger and similarity makes it easier, but neither of those is the deciding factor in an exam item. The disqualifier is a commitment to answer an individual case within a set time, and no amount of price pressure relaxes it.
That asymmetry is what makes these items answerable quickly. Scan the scenario for a per-case commitment; if one exists, batch is eliminated whatever else the paragraph says about cost. The same realtime-or-deferred judgment appears on the developer track inside API mechanics, in applications and integration.
One item failing is one item
The second half of the batch objective is failure handling, and it follows from what a batch is. Independent items processed together stay independent when something goes wrong, so one malformed input is not the other eleven thousand’s problem.
Two wrong answers bracket the right one. Abandoning the run throws away work that succeeded and costs it again. Skipping the failure silently produces a result set that looks complete and is not, which is the more expensive error because nothing downstream can detect it. Record it, keep the rest, and make the gap visible.
Multi-pass review needs different passes
The last objective covers multi-instance and multi-pass review, and its central point is counterintuitive: running the same review twice does not double the scrutiny. It applies one standard twice, and identical reviewers agree about everything, including what they are all wrong about.
Two design rules follow. Give each pass a distinct job — one checking evidence, one checking scope, one checking whether the conclusion follows — because that is what makes a second look a different look. And hand a reviewing pass the artefact rather than the reasoning that produced it: an argument that reached a conclusion is persuasive about that conclusion, and a reviewer who reads it is being asked to agree rather than to check. The measurement version of the same discipline is in writing evals for Claude prompts, and the delegation version in subagents and coordinator patterns.
Key takeaways
- One idea at three scales. Retry, batch and review all turn on what the second attempt knows that the first did not.
- A rejection is information. Resending unchanged discards the only thing the first attempt produced.
- Effects change the question. A timeout says no answer came back, not that nothing happened.
- A per-case deadline eliminates batch. Volume and cost pressure never override it, however the scenario is framed.
- Record the failure, keep the rest. A silently short result set is worse than an abandoned run, because nothing detects it.
- Identical passes measure consistency. Give each a different job, and give it the artefact rather than the argument.
Twelve items in one domain, and three of them here
These three objectives are the quiet part of a 20% domain, and they are decided by a single question you can ask in five seconds once it is habitual. Timed papers on the published 60-item allocation are where it becomes habitual. Our claude certification study guide covers how to sequence them.
See the CCAR-F blueprintQuestions
Frequently asked
The follow-up questions people search next.
What makes a retry loop wrong on the Claude exams?
Sending the same request again after a rejection. The component that produced the wrong answer has nothing new to work from, so the second attempt is a fresh draw rather than a correction. What turns a retry loop into a correction loop is telling the second attempt what was wrong with the first.
When is batch processing the right answer?
When no individual result is being waited on. High volume and similar items make the saving larger, but the disqualifier is a commitment to answer any single case within a set time — that rules batch out regardless of how attractive the economics are.
What should happen when one item in a batch fails?
Record it and keep the rest. The items are independent, which is the whole basis of the arrangement, so one bad input is not the other items’ problem. Abandoning the run discards good work; skipping it silently leaves a gap nobody can trace.
Does running the same review twice improve quality?
No — it applies the same standard twice and measures consistency rather than correctness. Multi-pass review works when each pass has a different job, and identical reviewers agree about the same things, including the things they are all wrong about.
Should a reviewing pass see the original reasoning?
Usually not. A reader who has just been walked through why something is right tends to agree that it is right, and a well-made case reads well whether or not it lands anywhere true. Passing on the artefact by itself is what keeps the second look independent of the first.
Keep reading
Related posts
Not affiliated with, or endorsed by, Anthropic or Pearson VUE. Details are summarised from publicly published program information and can change — always confirm against the official exam guide before booking.