Quick Reference: Domain 4 — Workflow Integration and Solution Design

The division of labour: given messy input (complaint threads, meeting notes, survey comments), Claude clusters it into themes, shows contradictions and names what nobody mentioned. That use is documented: the Help Center lists summarising long documents and conversations among Claude's core uses. Claude cannot know your organisation. So a theme is a hypothesis about the input, not a finding about the business. The people who own the requirements confirm it before anything is designed from it. AI Fluency puts the evaluating (Discernment) and the accountability (Diligence) with the human.

Strong use-case shape: language-shaped work (drafting, summarising, reformatting, comparing), material you can actually provide, an output someone competent can check, and either high volume or work where starting from nothing is the expensive part. Weak shape: the work needs the authority to decide, depends on information Claude cannot access, or is relationship work.

• Someone must be able to check the answer: if you couldn't tell whether the answer was wrong, you're not ready to use Claude on that task. High stakes or a missing checker mean find the checker, never abandon the work.
• Commitments to a whole category of work fail: "Claude will handle our X" commits to a category before the per-piece analysis; categories mix strong and weak candidates.
• On the exam: when new themes are ready, the right answer takes them back to their owners. Wrong options adopt themes as findings, hand Claude the decision itself, or reject the work as too important.

Research, planning and process optimisation work the same way: Claude makes the first draft, and you make the judgements about it. The exam tests the judgement.

• Research: web search for factual queries one or two lookups can answer; Research mode for multi-source jobs, returning cited findings. Extended thinking is for complex reasoning over material you already have, with no web search. Which feature to use for the work is Domain 3; checking everything important before repeating it is Domain 2, and this applies to findings with citations too.
• Plans: Claude confidently makes plans that ignore constraints you never mentioned, and nothing in the output warns you. An unconstrained plan looks correct but is wrong. Countermeasure: put the real constraints in the brief, then ask the plan to list the assumptions it is based on. Check first the assumptions that much of the plan depends on and that nobody has confirmed. Skip settled facts and details that would not change the plan.
• The optimisation loop, in order: describe the process as staff really run it, including the informal steps → ask for candidate bottlenecks and what evidence would confirm each → gather that evidence → change the step the evidence identifies. Evidence comes after the hypotheses are named and before anything changes.
• The wrong bottleneck is the objective's most expensive mistake: optimising a step that no evidence has identified because the most plausible-sounding hypothesis got treated as confirmed.

How to spot the right answer: it gives Claude the facts that Claude could not know, such as how staff really run the process. Or it checks something before anyone acts. Evidence comes after Claude names the possible bottlenecks. The wrong options act on reasoning that sounds convincing. Or they collect evidence before anyone knows which evidence matters, or choose a bigger feature when local facts were missing.

Draw the boundary first: iterating the prompt for a better response is Domain 1.3; iterating the solution, with Claude drafting, is this objective. A solution here is a process, template, guidance page, form or plan. Never software.

• Cheap versions change the method: a second and third draft cost minutes, so comparing concrete options replaces defending one draft. It works while versions stay disposable.
• One named criterion per round, drawn from the requirement established in 4.1. "Make it better" produces something different, not something better, because nothing says what the revision should achieve. "Make this survive a wet day" is testable. AI Fluency calls this cycle the Description-Discernment Loop.
• Check earlier criteria too: a revision can undo an earlier fix, so a version passes only when the earlier criteria still pass. To use better wording from a failing version, copy it into the passing version and check the requirement again.
• Stop when the remaining changes are preference rather than fitness (how well the deliverable meets the requirement). When a round reveals the requirement itself is wrong, the next thing to revise is the requirement, not another draft.
• Artifacts are where you revise the deliverable: substantial standalone content appears in its own window. Revisions happen by asking for changes. Editing an earlier message branches the chat, so two versions can be compared directly instead of from memory. The requirement, not the prose, decides which version is better.

On the exam: the right answer names one criterion and checks the revision against it, and against the criteria that earlier rounds fixed. Wrong options make small improvements without a criterion, generate many versions and pick by instinct, or push an untested draft into live use.

Integration means one thing here: where in an existing process a person brings work to Claude. It does not mean building a technical connection between systems.

• The human gate: keep a person on the step where the decision happens. Checking has no visible output, so it looks like waste on a process diagram. It is the step where a person makes the judgement.
• When to 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. Connectors do not make a request an escalation: they act inside a conversation, and the Google Workspace documentation states Claude only accesses your data when you explicitly ask. Within the features this exam covers, work moves when a person asks for it.
• Current state (checked 14 October 2026): Claude Cowork, which the exam guide does not name, can run a scheduled task that only uses connectors at its set time. Setting Claude to run with nobody present is rarely the right answer. It fits only when two conditions are both true. First, a feature that the business already has, such as a scheduled task, can do the task, so nothing has to be built. Second, a person checks the results before anyone relies on them.
• Pilot discipline: Anthropic's enterprise guidance stages adoption through a pilot group monitored for feedback over weeks, with champions per team. The all-at-once rollout measures nothing and risks everything at once.
• Recurring integrated work lives in a Project, not one ever-lengthening chat; configuring and maintaining the Project belongs to Domain 5.

One rule, two audiences: say what is true, including the parts that are not impressive.

• A claim has four parts: the task, the before, the after, and how you know. "The monthly sales report takes two hours instead of five, measured across three months" passes a sceptic's check; "Claude has transformed how we work" is not a claim at all.
• Use only measured numbers: a figure appears because somebody measured it over a stated period. A measured saving is never projected onto work the trial did not touch; the only number that can support the right answer is one the question says was measured.
• Name the untested category. Silence about it is understood as a claim, and the eventual failure is blamed on the report that said nothing.
• A caught error is evidence for the process: "the draft used the wrong date and the read-through caught it" proves the checking step works. Hidden errors, once found, get every other claim read again as if selected to look good.
• Two attitudes, one truthful account: the enthusiast needs the limitations and the human gate without slowing the work; the sceptic needs the measured result, the named human step, and the caught error. Too many warnings and qualifications fail with both, because under-claiming takes support away from results that work.

Boundary: whether a use is permitted, and who approves it, is Domain 6. This objective is the honest account of results, never a governance sign-off.