Theme (Clustered Requirements)
A pattern Claude names when it structures messy input: complaint threads, survey comments or meeting notes clustered into groups, with contradictions flagged and gaps surfaced. A theme describes the input it was given, nothing more.
Exam context: A theme is a hypothesis about the input, not a finding about the business. The keyed answer takes fresh themes back to the people who own the requirements; the distractor adopts them as validated findings because they arrived quickly and read plausibly.
See also: 4.1 Analysing Requirements and Use Cases
Use-Case Analysis
Judging whether a piece of work is a good candidate for Claude before any effort goes into it. Strong candidates are language-shaped, use material you can provide, produce output someone competent can check, and involve high volume or an expensive blank page. The analysis happens per piece of work, never per category.
Exam context: Weak candidates need the authority to decide, information Claude cannot access, or relationship work rather than document work. Items reward sorting the specific piece of work, not accepting or refusing a whole category.
See also: 4.1 Analysing Requirements and Use Cases
Checker Test
The sharpest use-case filter: if you couldn't tell whether the answer was wrong, you're not ready to use Claude on that task. The remedy for a missing checker is to find the person who could tell a good output from a bad one and put them in the process.
Exam context: High stakes are not a reason to abandon the work, and neither is a missing checker; both are reasons to recruit one. The exam treats blanket refusal as a wrong answer just as it treats blanket adoption.
See also: 4.1 Analysing Requirements and Use Cases
Blank-Cheque Use Case
The announcement that Claude will handle a whole category of work, made before the analysis that should have shaped it. Categories contain strong and weak candidates mixed together, so the blanket commitment is wrong somewhere from the day it is made.
Exam context: The fix distractors miss: break the category into pieces of work and run the use-case analysis on each. A one-line proposal ("Claude will handle our customer enquiries") fails on scope, not on enthusiasm.
See also: 4.1 Analysing Requirements and Use Cases
Delegation, Discernment and Diligence
Three elements of Anthropic's AI Fluency framework that carry this domain. Delegation is deciding what work to hand to the AI, a skill that comes before any prompt is written. Discernment is evaluating what the AI produced. Diligence is staying accountable for the result.
Exam context: Together they give the domain its division of labour: Claude structures and drafts; the human decides, evaluates and owns. Options that move any of the three onto Claude are wrong however efficient they sound.
See also: 4.1 Analysing Requirements and Use Cases
First-Pass Plan
Claude's initial draft of a plan, built only from what the brief supplied. It beats a blank page and is unusually complete on dependencies and sequencing, but it plans confidently around any constraint the brief never mentioned, and nothing in the output warns you.
Exam context: An unconstrained plan is fiction that reads like competence, which is more dangerous than an obviously bad plan because it invites trust. The keyed answer states the real constraints up front or checks the draft against them before relying on it.
See also: 4.2 Using Claude for Research, Planning and Process Optimisation
Stated Constraints
The real-world facts a plan must survive: the room that is double-booked, the volunteer who cannot work Sundays, the one accessible entrance. They enter the plan only if the brief states them, and the cheap countermeasure is asking the finished plan to list the assumptions it rests on.
Exam context: Plausibility is a property of the prose; validity comes from the constraints the planner supplied. An assumption you can read is one you can correct.
See also: 4.2 Using Claude for Research, Planning and Process Optimisation
Optimisation Loop
The four-step working rhythm for process improvement: describe the process and its constraints, ask Claude for candidate bottlenecks and what evidence would confirm each one, gather that evidence, then change the step the evidence indicts. The order is the point: evidence is collected after the hypotheses are named and before anything changes.
Exam context: Claude generates hypotheses about where a process is slow; it has never watched the process run, so data decides. The keyed answer pulls the local records before changing anything.
See also: 4.2 Using Claude for Research, Planning and Process Optimisation
Wrong Bottleneck
The most expensive mistake in process optimisation: changing the step that was never the constraint, usually because the most plausible-sounding hypothesis got treated as the confirmed one. It spends the budget and the appetite for change on something that was fine.
Exam context: Plausible causes and real causes coincide often enough to be tempting and rarely enough to be expensive. External research cannot say which cause is true in your process; only local evidence can.
See also: 4.2 Using Claude for Research, Planning and Process Optimisation
Solution Iteration
Improving a deliverable (a process, template, guidance page, form or plan) through cheap revision rounds with Claude as the drafting partner. Distinct from prompt iteration, which improves the response to one prompt and belongs to Domain 1.3. Same loop, different object.
Exam context: The boundary is tested directly. For this certification a solution is never software, and the object being improved in a 4.3 stem is the deliverable itself.
See also: 4.3 Supporting Solution Design, Development and Iteration
Named Criterion
The test a revision round is run against, drawn from the requirement: "survive a party that arrives fifteen minutes late" rather than "make it better". One criterion per round keeps the change testable, and two versions judged against the same test can be ranked instead of argued about.
Exam context: "Make it better" produces something different, not something better, because no new information aims the revision. The keyed answer names the criterion and checks the result against that criterion alone.
See also: 4.3 Supporting Solution Design, Development and Iteration
Disposable Draft
A version cheap enough to discard without ceremony. Claude collapses the cost of producing alternatives, which shifts design from defending one draft to comparing concrete options; the shift only works while nobody is attached to any single version.
Exam context: Volume without criteria is the trap on the other side: five alternatives chosen between by feel is activity, not iteration. The versions are compared against the requirement, not against each other's prose.
See also: 4.3 Supporting Solution Design, Development and Iteration
Stopping Point
The moment the remaining changes are matters of preference rather than fitness. Continued polish consumes time the next problem needed, and a fluent, confident version can quietly displace the one the actual users needed. When a round reveals the requirement itself is wrong, the next stop is the requirement, not another draft.
Exam context: The check is always against the requirement and the users, never against how the prose reads. Naming the stopping reason in one line is what keeps the loop honest.
See also: 4.3 Supporting Solution Design, Development and Iteration
Versions of a Chat
Editing an earlier message creates a different version of the chat, with artifacts of its own, while the original stays intact. It is the product home of the compare-concrete-options move: switching directly between two branches beats trusting your memory of the round before, because memory flatters whichever version came last.
Exam context: The branches show you the versions; only the requirement says which one wins. Keep the requirement visible while comparing.
See also: 4.3 Supporting Solution Design, Development and Iteration
Augmentation
Bringing Claude into one step of an existing process while everything else keeps its shape: the person who compiled the summary still owns it, it just takes ten minutes instead of an hour. Cheap, reversible, easy to explain, and the right answer far more often than the ambitious alternative.
Exam context: Most successful integrations at Associate level are exactly this: one step, done better, with the human gate intact.
See also: 4.4 Integrating Claude into Existing Workflows
Redesign
Changing the process itself because the constraint that gave it its shape has gone: when personalising a letter cost twenty minutes you sent one generic letter; at two minutes, a tiered approach becomes possible. Rarer and bigger than augmentation, and it earns a pilot before it earns a rollout.
Exam context: The all-at-once redesign is the distractor: if it fails, everything fails together and nothing was learned. Pilot one strand, measure it, then expand.
See also: 4.4 Integrating Claude into Existing Workflows
Pilot
A limited first run of a redesigned process, monitored for feedback before wider expansion. Anthropic's enterprise deployment guidance stages adoption this way: a pilot group watched over a period of weeks, with champions identified per team.
Exam context: The pilot is what makes redesign safe to attempt. Its absence is the tell in boil-the-ocean options that launch everything everywhere at once.
See also: 4.4 Integrating Claude into Existing Workflows
Human Gate
The step in a process where the decision actually happens, kept with a person. Checking has no visible output, which makes it look like waste to anyone redesigning from a diagram; it is where the process's judgement lives, and it is what makes augmentation safe to adopt quickly.
Exam context: Integrations fail when the checking step is the one that gets removed. A gate that has caught little for months is still the safeguard; the exam expects you to keep it.
See also: 4.4 Integrating Claude into Existing Workflows
Escalation Brief
The written description an Associate hands a Claude Developer or Architect when a request needs a technical implementation: systems talking to each other, data moving on its own, or a process built to run with nobody present. It states what the process needs and what must stay human; the how belongs to the specialist.
Exam context: Stem triggers: automatically, without anyone having to, straight from the system, overnight. Escalating is knowing the shape of your own job, not a failure, and describing the need well is the Associate's contribution.
See also: 4.4 Integrating Claude into Existing Workflows
Four-Part Value Claim
The defensible shape of a value statement: the task, the before, the after, and how you know. "The monthly board pack takes two hours instead of five, measured across three months" can be checked; "Claude has transformed how we work" cannot, and an audience that has heard it before discounts everything that follows.
Exam context: Every number in a report appears because somebody measured it over a stated period. A measured saving on one task is never projected onto work the trial did not touch.
See also: 4.5 Communicating Value and Limitations to Stakeholders
Untested Category
The work a trial never touched, named explicitly in the report. Silence about it gets heard as a claim: the stakeholder who was never told a category went untrialled will reasonably assume it was covered, and the eventual failure lands on the report that stayed quiet.
Exam context: Naming the category costs one sentence; leaving it unnamed costs the report its credibility when the gap surfaces. The classic stem has a committee member congratulating the team on work the trial never did.
See also: 4.5 Communicating Value and Limitations to Stakeholders
Caught Error
A mistake in Claude's output that the human checking step found before it did harm, reported as evidence for the process rather than against it. "The draft used the wrong date and the read-through caught it" tells a sceptic the checking step works, which is precisely what they doubted.
Exam context: Hide the error and let it surface later, and every other claim in the report gets re-read as curated. This is AI Fluency's Diligence element in reporting form: staying accountable for what the AI produced.
See also: 4.5 Communicating Value and Limitations to Stakeholders
Caveat Avalanche
The overcorrection in stakeholder reporting: so many warnings and qualifications that a process that works sounds like one that failed. Under-claiming is not honesty; it hands the sceptic a conclusion the data does not support and starves the work of the support it earned.
Exam context: The exam tests both directions. Over-promising wins a mandate the work cannot deliver; the caveat avalanche loses the mandate the work deserved. The keyed answer claims accurately and stops.
See also: 4.5 Communicating Value and Limitations to Stakeholders