- In short
- Code execution for verified planning figures means uploading the source dataset and directing Claude to use code execution to compute any figure the plan depends on, such as a trend or a per-unit rate, rather than asking it to estimate the figure in prose. A plan built on a code-executed calculation is defensible line by line; a plan built on a guessed rate is a guess.
From knowing numbers matter to producing them safely
The synthesis-versus-calculation distinction says a plan's numbers must be verified rather than trusted as prose. This knowledge point is the practical answer to how. The Claude Certified Associate - Foundations (CCAO-F) exam treats it as an apply-level skill: given a plan that rests on figures, produce those figures by uploading the data and running code execution on it, rather than accepting an estimate written in the flow of a response.
The move rests on a simple contrast. A figure asked for in prose is generated to sound plausible; a figure produced by code execution is computed from the actual data and can be checked. Those are not two grades of the same thing, they are different in kind. This builds directly on synthesis versus calculation in planning work, which told you numbers need a verifiable method; code execution is that method.
- Code execution for verified figures
- Uploading the source dataset and directing Claude to use code execution to compute any figure a plan depends on, for example a trend, a per-unit rate, or a total, rather than asking for the figure as a prose estimate. The result is a calculation run on the actual data, making the plan defensible line by line instead of resting on a guess.
Upload the data and name the mechanism
Two things make this work, and both are deliberate. First, the source data has to be present: you upload the dataset the figures should come from, so the computation runs on the real numbers rather than on the model's impression of them. Second, and this is the part people skip, you direct Claude to use code execution explicitly. Simply asking Claude to "calculate" a figure leaves the door open for it to produce a plausible prose estimate instead of running code, which defeats the purpose.
Naming the mechanism is what closes that door. When you say "use code execution on the attached data to compute the quarterly growth rate and average throughput", Claude runs an actual calculation over the uploaded figures and returns a result you can trace to the data. The instruction does two jobs at once: it points at the right source and it forces the right method. Both are needed, because the right source computed by the wrong method is still a guess, and the right method on absent data has nothing real to compute.
What code execution buys the plan
Code execution can produce the derived figures plans actually depend on: trends over time, per-unit rates like throughput per person, totals, and other calculations run straight from the data. These are exactly the numbers that, if wrong, break a recommendation. Computing them rather than estimating them changes the character of the whole plan.
The payoff is defensibility. A plan built on a guessed utilisation rate is a guess with a recommendation attached; a plan built on a code-executed calculation of the actual data can be defended line by line, because every figure traces back to a computation someone can re-run. That line-by-line defensibility is what lets verified figures become a defensible recommendation that stands up to scrutiny. The synthesis around the numbers stays Claude's strength; code execution is what makes the numbers underneath it trustworthy.
What the CCAO-F exam trips candidates on
The exam tests two traps. The first is asking Claude to "calculate" a figure without directing it to use code execution, which can still yield a plausible-sounding but ungrounded estimate. A scenario may show a planner requesting a number in prose and treating the answer as computed; the credited move is to require code execution on the uploaded data so the figure is actually calculated. The second trap is accepting a headline number without checking whether it came from computation on the real data or from prose estimation. The exam wants you to interrogate the provenance of the figure, not just its value.
Both traps reward the same instinct: a number is only as trustworthy as the method that produced it. Direct the calculation to code execution over the actual dataset, and confirm that is where any decision-driving figure came from.
Worked example
An operations lead is planning next quarter's headcount and has four quarters of ticket-volume data in a spreadsheet. They ask Claude, 'Based on this data, roughly how many tickets does each analyst handle per quarter, and what's our growth rate?' Claude replies with confident figures. Should the lead build the plan on them, and how should the request have been framed?
The lead should not build on those figures as they stand, because the way the request was framed does not guarantee they were computed. "Roughly how many... based on this data" invites a prose estimate: Claude can produce plausible-looking numbers that read as if they came from the spreadsheet without actually running a calculation over it. That is the first trap, asking for a figure without directing the method, and it leaves the plan resting on a possible guess.
The better framing names the mechanism and the source: "Using code execution on the attached ticket data, compute the average tickets resolved per analyst per quarter and the quarter-over-quarter volume growth rate, and show the calculation." Now Claude runs an actual computation over the uploaded data, and the results trace back to the real figures. If the growth rate comes out at 12%, that 12% is checkable, not asserted.
The lead should also confirm the provenance rather than accept the headline number on faith, which addresses the second trap: a figure is trustworthy because of how it was produced, not because it sounds right. With the throughput and growth rate code-executed on the actual data, the headcount plan built on them is defensible line by line. Claude's synthesis then turns those verified figures into the recommendation, but the numbers underneath it are computed, not guessed.
Common misreadings to avoid
Misconception
Uploading the data and asking Claude to 'calculate the figures based on it' guarantees the numbers are computed.
What's actually true
Misconception
If a headline figure looks reasonable and the data was attached, it is safe to build on.
What's actually true
How this shows up on the exam
Domain 4 questions on this knowledge point describe a plan that depends on figures from an uploaded dataset and ask how those figures should be produced, or they show a prose-estimated number and ask what is wrong with relying on it. The reliable reading is to upload the data and direct Claude to use code execution, and to check that any decision-driving figure was computed rather than estimated.
This knowledge point builds on synthesis versus calculation in planning work, which establishes why numbers need a verifiable method, and it feeds into building a defensible recommendation from verified figures and separating synthesis steps from judgment steps in a plan, which together turn computed figures into a recommendation while keeping the final call human.
A capacity plan depends on the growth rate and per-analyst throughput drawn from an uploaded ticket dataset. Which approach produces figures the plan can be defended on?
People also ask
How do you get verified numbers for a plan from Claude?
Why direct Claude to use code execution explicitly?
What can code execution compute from a dataset?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
Official prep for this domain
Anthropic's own free prep module for this part of the syllabus, on the official prep course. Free with an Anthropic Academy sign-in.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.