Theme (Clustered Requirements)
A pattern Claude names when it structures messy input. Claude clusters complaint threads, survey comments or meeting notes into groups. It flags contradictions and shows gaps. 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 right answer takes new themes back to the people who own the requirements; a wrong option 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 (drafting, summarising, reformatting, comparing), use material you can provide, produce output someone competent can check, and involve high volume or work where starting from nothing is the expensive part. 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. In questions, the right answer is 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 most decisive use-case check: 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 refusal of a whole category as a wrong answer just as it treats adoption of a whole category.
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 decided its scope. Categories contain strong and weak candidates mixed together, so the commitment to the whole category is wrong for some of the work from the day it is made.
Exam context: The fix the wrong options 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 this domain is built on. 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. Starting from it is better than starting from nothing. It is unusually complete on dependencies and sequencing, but it confidently makes plans that ignore any constraint the brief never mentioned, and nothing in the output warns you.
Exam context: An unconstrained plan sounds competent but is not based on the real constraints, which is more dangerous than an obviously bad plan because people are more likely to trust it. The right answer states the real constraints at the start 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 respect: 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: How plausible a plan sounds depends on how it is written. Whether it is valid depends on the constraints the planner supplied. When the plan states an assumption, you can read it and correct it.
See also: 4.2 Using Claude for Research, Planning and Process Optimisation
Optimisation Loop
The four-step working method 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 identifies. The order is what matters: 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 right 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 people's willingness to change on something that was fine.
Exam context: A plausible cause is the real cause often enough to tempt you to trust it. But it is the real cause rarely enough that trusting it is 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 through cheap revision rounds. A deliverable is a process, template, guidance page, form or plan. Claude is the drafting partner. Distinct from prompt iteration, which improves the response to one prompt and belongs to Domain 1.3. The method is the same, but the thing being improved is different.
Exam context: The boundary is tested directly. For this certification a solution is never software, and the object being improved in a 4.3 question 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 says what the revision should achieve. The right answer names the criterion, checks the result against it, and checks that the criteria from earlier rounds still pass.
See also: 4.3 Supporting Solution Design, Development and Iteration
Disposable Draft
A version cheap enough to discard without hesitation. Claude greatly reduces the cost of producing alternatives. So design changes from defending one draft to comparing concrete options. This change only works while nobody insists on keeping any single version.
Exam context: Volume without criteria is the opposite mistake: choosing between five alternatives by instinct produces 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 (how well the deliverable meets the requirement). Continued small improvements consume time the next problem needed, and a fluent, confident version can replace, without anyone noticing, the one the actual users needed. When a round reveals the requirement itself is wrong, the next thing to revise 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 makes sure the loop stops for a real reason.
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. That version has artifacts of its own, and the original stays intact. It is the product feature for comparing concrete options: switching directly between two branches is better than trusting your memory of the round before, because memory makes whichever version came last seem better.
Exam context: The branches show you the versions; only the requirement decides which one is better. 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 stays the same: 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 (the step where a person makes the decision) intact.
See also: 4.4 Integrating Claude into Existing Workflows
Redesign
Changing the process itself because the constraint that the process was designed around 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 needs a pilot before it gets a rollout.
Exam context: The all-at-once redesign is the wrong option: if it fails, everything fails together and nothing was learned. Pilot one part, 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 clue in over-ambitious 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. This makes it look like waste to anyone redesigning from a diagram. But checking is where the process makes its judgements, 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 exchanging data with 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 specialist decides how to build it.
Exam context: Escalate when the request needs something built, such as a connection to a system that has no connector. Also escalate when the work would run with nobody checking the results. Single words such as automatically or overnight do not decide it. Escalating is knowing the limits 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 structure of a value statement that you can defend: the task, the before, the after, and how you know. "The monthly sales report 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 trusts everything that follows less.
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 is understood as a claim: the stakeholder who was never told a category went untrialled will reasonably assume it was covered, and the eventual failure is blamed on the report that said nothing.
Exam context: Naming the category costs one sentence; leaving it unnamed costs the report its credibility when the gap becomes known. The typical question 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 become known later, and every other claim in the report gets read again as if selected to look good. 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 takes away the support that the work earned.
Exam context: The exam tests both directions. Over-promising gets approval for results the work cannot deliver. The caveat avalanche loses the approval that the work deserved. The right answer claims accurately and stops.
See also: 4.5 Communicating Value and Limitations to Stakeholders