What You Need to Know
A requirement is a statement of what a piece of work must achieve. Use-case analysis is judging whether a task is a good candidate for Claude before you put any effort into it. A theme is a named group of related comments. The objective tests two related skills: using Claude to turn messy input into structured requirements, and use-case analysis. Every workflow decision in this domain starts with two questions: what does this work require, and does Claude belong in it at all? Both skills follow one rule: Claude structures, and the human validates and owns the result.
This lesson uses one made-up example throughout: a logistics company that delivers goods to shops. The operations manager wants to rework the delivery routes. Her material is customer emails, team meeting notes, comments in the order system and remarks that customers made by phone.
Structure from Mess
Real requirements arrive as complaint threads, meeting notes, survey comments and half-remembered conversations, never as a tidy list. The Help Center lists summarising long documents and conversations among Claude's core uses, alongside generating viewpoints and providing recommendations. Given the raw material, Claude clusters it, which means it groups related comments into themes. It separates what people asked for from what they appear to need. It also shows where two groups want incompatible things, and names what nobody mentioned.
For the logistics company, Claude might return themes like late deliveries and wrong goods. It might flag that shops in one city want deliveries before seven, while drivers want later starts. The reading takes minutes instead of an afternoon, and the people involved get an outline of the problem that they can question.
A Theme Is a Hypothesis
Claude organises what you gave it. It has no way of knowing what your organisation needs. A theme that Claude names is a hypothesis about your input, not a finding about your business. The people whose requirements the theme describes must confirm it before anyone bases any design on it. AI Fluency is the framework that Anthropic's course on working with AI teaches. It divides the work in the same way. Discernment means evaluating what the AI produced. Diligence means staying accountable for the result. Both stay with the human.
So the manager checks the early-delivery conflict with those shops and her drivers before she redraws any route. If she designed straight from Claude's themes, she would mistake tidy output for validated requirements. Confirming the themes is the cheap part.
The Shape of a Strong Candidate
Good Claude use cases share some recognisable features:
- The work is mainly about language: drafting, summarising, reformatting, explaining, comparing. These are the tasks that the Help Center's use-case article documents.
- The material needed is material you can provide.
- The output can be checked by someone competent to check it.
- Either the volume is high or starting from nothing is the expensive part.
AI Fluency calls this judgement Delegation: deciding what work to hand to the AI. It treats Delegation as a separate skill, and that skill comes before anyone writes any prompt. Weak candidates have the opposite features. The work needs the authority to decide rather than the ability to draft. Or it depends on information Claude has no access to. Or it is relationship work rather than document work.
At the logistics company, an email announcing new delivery times is a strong candidate: the manager can check it. Choosing which driver takes which route needs authority. Knowing whether a delivery reached the shop needs information Claude lacks. Calling the long-standing customer who cancelled is relationship work.
The Checker Test
People skip one test in particular. It says: if you could not tell whether the answer was wrong, you are not ready to use Claude on that task. Without a checker, a wrong output passes as easily as a right one. High stakes are not a reason to abandon the work, and neither is a missing checker. Both mean that you find the person who can tell good output from bad output, and you put that person in the process.
The test also applies when someone announces that Claude will handle a whole category of work. The glossary names this a blank-cheque use case. A category mixes strong and weak candidates, and the test separates them. The commitment to the whole category comes before the analysis that should have decided its scope. Handing Claude all the delivery administration would group the email with the choice of which driver takes which route.
In the exam
The failure that the exam tests most often here is the skipped confirmation step. Whether and where the work suits Claude is this objective's question. How you then phrase the request is Domain 1's skill, and which product feature runs the work is Domain 3's skill.
Key Concept
When a 4.1 question ends with themes that Claude has just clustered, the right answer acts before design begins. It returns the themes to the people who own the requirements. The wrong options adopt the themes as findings, hand Claude the decision itself, or abandon the work because the stakes feel high.
Exam Traps
Adopting Claude's themes as validated findings because they arrived quickly and read plausibly
A theme is a hypothesis about the input, not a finding about the business. Basing a design on unconfirmed structure builds the wrong thing. Take the themes back to the people whose requirements they are, and confirm them before design begins.
Handing Claude the decision along with the analysis
Decisions that belong to an accountable person or group stay with them. Claude structures the material and drafts what supports the decision, but choosing the policy, picking the winner or resolving the dispute is theirs.
Excluding work from Claude as too important
Refusing to use Claude treats high stakes as if they were high risk. High stakes call for a competent checker in the process, not abandoning the drafting help. Without a checker, a wrong output passes as easily as a right one.
Practice Scenario
The production manager of a publishing company has a folder of complaint emails and comments from editors about how publication dates are allocated. She wants to establish what a fairer allocation approach must do before anyone designs one. Claude clusters the material into six themes, including a contradiction: fiction editors believe non-fiction books get the best autumn dates, while non-fiction editors describe those same dates as reserved for fiction. She has no time to work through the folder again herself. What should she do next?
Build Exercise
Cluster, Confirm, Then Classify
What you'll learn
- How to get Claude to structure genuinely messy input
- How to treat themes as hypotheses and confirm them with their owners
- How to sort candidate work into work that suits Claude and work that does not
- How to apply the test of whether someone can check the output before committing to a use case
- Collect a genuinely messy input you own: a feedback thread, the notes from your last three team meetings, or the complaints folder for one process
Why: The skill only becomes visible with genuinely messy input; a tidy input hides exactly the structuring work this objective tests.
You should see: A single pile of raw material, unedited, in one document or conversation.
- Ask Claude to cluster the material into themes, flag where two people want incompatible things, and name what nobody mentioned
Why: These three requests cover what is hardest to see in the material: patterns, contradictions and absences.
You should see: A set of named themes, at least one flagged tension, and one or two gaps.
- Mark each theme confirmed or hypothesis, then take the two hypotheses that the most work depends on back to the people who own them and record what changes
Why: This is the rule the exam tests: a theme is a hypothesis about your input until its owners confirm it.
You should see: At least one theme revised or reframed after a real conversation.
- List the pieces of work the confirmed requirements imply, and sort them: mainly about language, with material you can provide, or dependent on authority, access or relationships
Why: Use-case analysis happens per piece of work, never per category; sorting makes the strong and weak candidates visible.
You should see: Two lists, with each piece of work in exactly one of them.
- For every piece you would hand to Claude, name the person who could tell a wrong output from a right one; if there is no name, the use case is not ready
Why: The test of whether someone can check the output is the most effective test in the objective. Naming a real person is what makes the test genuine.
You should see: A named checker beside every piece of work for Claude, or a note on who to recruit.
Sources
- What are some things I can use Claude for? — 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 (exam guide; claims about professional practice are our judgement, not Anthropic guidance)