What You Need to Know
Solution iteration means improving a deliverable over several rounds, with Claude as the drafting partner. In this certification a solution is a process, a template, a piece of guidance, a scheme, a service design, a form or a plan. It is never software. Each round is checked against a criterion: a test drawn from the requirement established in 4.1.
Take a coffee shop whose owner wants a Saturday opening checklist for one barista working alone. The requirement says who it is for and what it must survive, such as a late milk delivery. Claude's first draft is workable.
Why the Loop Is Worth Running
Iteration used to be expensive, so people defended their first draft. The cost of an alternative was the argument against seeing one. Claude changes the economics. A second and third version cost minutes, so you can afford to look at them. Comparing three concrete options is a better way to design than arguing about one. The owner's question shifts from whether the checklist is good to which version survives the requirement. That shift is the point of this objective. It only works while the versions stay disposable. A cheap draft can be discarded without ceremony, and a version nobody is attached to can be tested honestly.
One Named Criterion per Round
Every round needs a named criterion from the requirement. That separates iteration from fiddling. "Make it better" produces something different, not something better. Without new information, nothing aims the revision. The Help Center's remedy for an unhelpful answer is specific feedback rather than a bare retry, for the same reason. "Make this survive a wet day" is a testable change.
Run each round against one criterion, check the result against that criterion alone, and keep the version that passes. The owner asks for a checklist that survives a late milk delivery, then checks only that. Two versions judged against the same test can be ranked. Two versions judged on overall feel just get argued about. Anthropic's AI Fluency course names this rhythm the Description-Discernment Loop: describe what you need, evaluate what came back, refine, and repeat.
Knowing When to Stop
Stop when the remaining changes are matters of preference rather than fitness. Polishing a deliverable that already meets the requirement uses time the next problem needed. It also invites a subtler failure: a fluent, confident version can displace the one your actual users needed. So check against the requirement and the users, never against how the prose reads.
If a round shows the requirement itself was wrong, the next stop is the requirement, not another draft. No amount of revision fixes a deliverable aimed at the wrong target. Suppose the owner learns that two staff open on Saturdays. The requirement needs rewriting before any further draft. Whichever way the loop ends, state the stopping reason in one line. Naming it keeps the loop honest the next time it runs.
Artifacts and Branches
The product mechanics for this loop live in artifacts. Substantial, standalone content goes into its own dedicated window. You revise it by asking Claude to change the artifact. To compare two concrete options, edit the message that produced the draft. That creates a different version of the chat, with its own artifacts, while the original branch keeps the first draft intact. The owner gets a second checklist without losing the first. Comparing two branches beats trusting your memory of the round before, because memory flatters whichever version came last. Keep the requirement visible while you compare. The branches show the versions, but only the requirement says which one wins.
In the exam
Candidates most often collapse this objective into Domain 1. Iterating the prompt to get a better response is Domain 1.3. Iterating the solution, with Claude as the drafting partner, is 4.3: the same loop, run on a different object.
Key Concept
When a 4.3 stem shows a workable first draft, the keyed answer names one criterion drawn from the requirement and checks the revision against it. Distractors polish without a criterion, generate volume and pick by feel, or push an untested draft into live use. When the stem signals the requirement itself is wrong, the keyed answer revisits the requirement.
Exam Traps
Round after round of make-it-better with no named criterion
Each round produces a different version, none of them checkably better, because nothing aims the revision. The keyed answer names one criterion drawn from the requirement and tests the result against it; regenerate-until-it-feels-right is activity, not progress.
Redrafting a deliverable whose requirement was wrong
No amount of revision fixes a deliverable aimed at the wrong target. When the stem shows the requirement itself has failed, the professional move is a trip back to the 4.1 work, and every further round of redrafting is the distractor.
Letting the best-written version beat the one that fits
Fluency is not fitness. Versions are checked against the requirement and the users, not against each other's prose, and the warm, confident draft that misses a hard constraint is precisely the version the exam expects you to reject.
Practice Scenario
The party coordinator at a laser-tag arena is designing the running order for a new birthday-party package. The requirement is fixed: ages seven to eleven, a safety briefing before anyone plays, food in the party room, all inside a ninety-minute slot. Claude's first draft is workable. She wants round two to give her a version she can plainly pass or fail, before any real party relies on it. What should round two look like?
Build Exercise
Three Rounds, Three Criteria
What you'll learn
- How to write the requirement before the first draft
- How to run a revision round against exactly one named criterion
- How to compare versions by branching the chat
- How to recognise the stopping point and the requirement problem
- Pick a real deliverable you own: a template, a checklist, a guidance page or a plan
Why: The stopping judgement only works on work whose users and constraints you genuinely know.
You should see: One named deliverable with a real audience waiting for it.
- Write the requirement first, in three to five lines: who it is for, what it must survive, and any hard constraints
Why: Criteria come from the requirement; without it, every later round degenerates into make-it-better.
You should see: A short requirement note that a colleague could test a draft against.
- Get a first draft from Claude, then run round two against exactly one named criterion from the requirement and record pass or fail
Why: One criterion per round keeps the change testable; three at once and you cannot tell what fixed what.
You should see: A revised version and a one-word verdict against the named criterion.
- Run round three against a second criterion, branching the chat from the round-two message (or keeping side-by-side copies) to compare versions rather than trusting memory
Why: Comparing concrete versions is the design method; memory flatters whichever version came last.
You should see: Two or three versions compared directly, with the surviving one identified.
- Stop, and write one line on why: either the remaining changes are preference, which means you are done, or a requirement problem surfaced, which means the next stop is the requirement, not another draft
Why: Naming the stopping reason builds the judgement the objective actually tests.
You should see: A single sentence: done because fitness is met, or paused because the requirement needs rework.
Sources
- What are artifacts and how do I use them? — Anthropic
- My prompt isn't giving me a helpful answer — Anthropic
- AI Fluency: Framework and Foundations — Anthropic (the element names are the course's module titles; the one-clause glosses of each element are our paraphrase of the course content)
- Claude Certified Associate – Foundations Exam Guide — Anthropic. No Anthropic document covers design and iteration for business deliverables. This lesson draws on the exam guide's objective and standard design practice; the artifacts article covers the product mechanics.