Dominant Signal
The one characteristic of a task that picks its product feature: recurring shared context, multi-source cited synthesis, an iterative shareable deliverable, or a simple one-off. Real work mixes features; exam items carry one signal each.
Exam context: Find the signal before reading the options. The distractors are always real features aimed at the wrong shape, so matching by feature prestige instead of by signal is the planted mistake.
See also: 3.1 Selecting the Right Claude Product Feature
Ordinary Chat
The default way to work with Claude: a single conversation with material attached in the moment. It handles one-off questions, single drafts and self-contained analyses immediately, with no setup.
Exam context: A legitimate keyed answer, not a consolation option. When the stem's dominant signal is a simple one-off, the plainest choice wins over every more capable feature.
See also: 3.1 Selecting the Right Claude Product Feature
Project (claude.ai)
A self-contained workspace with its own chat history and knowledge base. A Project carries two standing assets: instructions that shape every chat inside the workspace, and uploaded knowledge Claude uses as background for those chats.
Exam context: The signature is recurrence: the same documents and preferences needed across many conversations. Re-pasting that context chat after chat is the manual workaround a Project exists to end. Configuring instructions and knowledge well is Domain 5's business.
See also: 3.1 Selecting the Right Claude Product Feature
Research Mode
The feature for questions whose answer must be assembled from several outside sources. Claude searches agentically, with each search building on the last, and returns a synthesised report with citations the audience can check.
Exam context: Not a quality upgrade for ordinary questions. A task answerable from material the user already holds gains nothing from it; that distractor is a wrong-tool detour, and checking the citations is Domain 2's discipline.
See also: 3.1 Selecting the Right Claude Product Feature
Artifact
Standalone content displayed in its own window, created when an output is significant, self-contained and likely to be edited, iterated on or reused. You iterate it by asking Claude to change it or by editing an earlier message to branch the chat with artifacts of its own, and a finished artifact can be shared.
Exam context: The dominant signal is a life beyond the chat: a sheet revised every quarter, a plan shared and updated. An answer consumed once has no such life, and offering it an artifact is over-engineering.
See also: 3.1 Selecting the Right Claude Product Feature
Manual Workaround
The anti-pattern of doing a feature's job by hand: re-pasting the same standing context into every chat, or keeping a living document as loose text hunted down in an old conversation.
Exam context: Often dressed as diligence in distractors. The keyed answer moves recurring context into a Project and an evolving document into an artifact, paying the setup cost once instead of every time.
See also: 3.1 Selecting the Right Claude Product Feature
Model Family
One of the three tiers the exam guide names: Haiku, Sonnet and Opus. The Haiku class is the fastest, lowest-cost tier; the Sonnet class is the balanced middle, the best combination of speed and intelligence; the Opus class is the most capable reasoning tier. Specific model names change over time and live on the quick reference.
Exam context: No tier is "the good one". Items key the tier whose strengths match the task in front of you, and the guide's own sample item keys high-volume routine drafting to the faster, lower-cost model.
See also: 3.2 Differentiating Between Claude Model Types
Capability
Depth on demanding work: untangling ambiguity and contradiction, multi-step reasoning, synthesis across partly disagreeing sources, and drafting where a subtle wrong note carries consequences. Not "better at everything".
Exam context: The documentation never claims a lighter tier matches a heavier one on demanding work, and no keyed answer relies on that equivalence. The lighter tier's warrant is fitness for the task plus review.
See also: 3.2 Differentiating Between Claude Model Types
Model Picker
The control in the chat interface for choosing which model responds: click the model name and pick another available model. The change applies from Claude's next response, and the picker shows what the account has access to, which varies by plan and organisation settings.
Exam context: Mid-conversation switching means the tier decision is never a one-off commitment; routine ground-clearing and the hard synthesis step can run on different tiers inside one piece of work. A never-opened picker is a habit, not a decision.
See also: 3.2 Differentiating Between Claude Model Types
Prestige Selection
Assigning the most capable model by the project's importance rather than the task's demands. Importance belongs to projects; demands belong to tasks, and a routine reformat inside a flagship project is still a routine reformat.
Exam context: The guide's sample rationale calls always-using-the-top-model a waste of the cost and latency budget. Watch for "because this work matters" doing the arguing in a distractor.
See also: 3.2 Differentiating Between Claude Model Types
Usage Allowance
What "cost" means in this certification's register: the plan's finite usage budget, not a per-use invoice. Model choice, effort level, current conversation length and file attachment size are among the factors that determine how quickly it is consumed.
Exam context: Treating the allowance as a budget makes cost a real currency: every task overpaid for is drawn against the tasks still to come. Distractors invent factors such as time of day; among the factors actually named are the model, the conversation's length and the attachments.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Volume and Stakes
The two multipliers that price a task. Volume multiplies cost and speed: across hundreds of runs, tier differences decide whether the job finishes and the allowance survives. Stakes multiply quality: one output feeding a consequential decision needs depth, however short it is.
Exam context: The planted trap lets volume language leak into stakes decisions: "it is only one letter" is true and irrelevant, because one letter with consequences out-demands five hundred without.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Split Workload
The working pattern for mixed work: routine bulk on the fast tier with a sampled spot-check, the consequential core on the capable tier with qualified human review. The picker makes the split cheap mid-conversation.
Exam context: When a stem mixes both shapes, the keyed answer almost always splits. The two uniform settings, maximum quality everywhere and minimum cost everywhere, are the recurring distractors on either side of it.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Escalation Loop
Re-running a disappointing output on ever-heavier models without changing the prompt. A vague brief fails at every tier, so the loop spends time and usage relearning that.
Exam context: When the stem shows a prompt missing audience, constraints or source material, the keyed move is fixing the brief, which is Domain 1 territory; no tier upgrade substitutes for it.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Spot-Check
The sampled review that makes lighter-tier volume work professional rather than merely cheap: fix a sample size before looking at any output, then check the sample against the quality bar.
Exam context: Domain 2's verification duty never switches off; it scales sensibly. A keyed answer that sends bulk work to the fast tier almost always pairs it with a sampled check, and a failed sample means the task was less routine than its label claimed.
See also: 3.3 Aligning Model Choice with Cost, Speed and Quality
Restart
Deliberately opening a fresh conversation: when a piece of work is done, when the chat has accumulated dead ends and superseded drafts, or when a long conversation approaches the platform's length and usage limits.
Exam context: The official options at the limit are practical: start a new conversation, or use a Project for larger amounts of information. Nothing official claims long chats degrade, and no keyed answer relies on that claim.
See also: 3.4 Managing Context Limits and Memory
Verified Summary
The handover document a long conversation produces before a restart: decisions made, current state and open questions, checked against source records before it is trusted. The verified version opens the fresh conversation.
Exam context: The summary inherits every uncorrected error in the chat it summarises, so the unverified version pasted straight into a new chat is the near-miss distractor. Verification is the step the keyed answer always includes.
See also: 3.4 Managing Context Limits and Memory
Explicit Persistence
The dependable way to give a new conversation a specific working output: paste it in, re-attach the file, or store it in Project knowledge. A standing document that keeps being revised and shared lives as an artifact instead.
Exam context: The routing follows lifespan: consumed once means paste it forward, revised and shared means artifact, needed by every future chat means Project knowledge. Neither memory nor chat search substitutes for it.
See also: 3.4 Managing Context Limits and Memory
Memory Boundary
The line between what claude.ai's memory carries and what it does not. Memory holds a set of individual topics covering your role, projects, preferences and ongoing work context: context about you, not transcripts, drafts or attached documents. Each Project has its own memory, used alongside your memory from chats outside Projects but never another Project's; chat search is prompted retrieval on paid plans. Rollout dates live on this domain's quick reference.
Exam context: Two stale claims fail in opposite directions: that Claude cannot remember anything across chats, and that memory can be trusted to carry a working document. Items key on the boundary, never on either stale claim.
See also: 3.4 Managing Context Limits and Memory
Continuity Illusion
The marathon chat's best argument: "a new conversation would lose all our context". False, because the context worth keeping is exactly what a verified summary and persisted documents carry forward, at a fraction of the length and the usage.
Exam context: The keep-everything-in-one-chat option is the posture distractor for 3.4 stems. Its cousin lives one domain over: diagnosing a chat already producing poor output is Domain 7, not a selection decision.
See also: 3.4 Managing Context Limits and Memory