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, surfaces contradictions and names what nobody mentioned. That is documented territory: the Help Center lists summarising long documents and conversations among Claude's core uses. What Claude cannot do is know your organisation, so a theme is a hypothesis about the input, not a finding about the business, and the people who own the requirements confirm it before anything gets designed on top. 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 an expensive blank page. Weak shape: the work needs the authority to decide, depends on information Claude cannot access, or is relationship work.

• The checker test: 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.
• Blank-cheque use cases fail: "Claude will handle our X" commits to a category before the per-piece analysis; categories mix strong and weak candidates.
• On the exam: with fresh themes on the table, the keyed answer takes them back to their owners. Distractors adopt themes as findings, hand Claude the decision itself, or rule the work out as too important.

Research, planning and process optimisation share one shape: Claude produces the first pass, you own the judgement. 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. Which feature carries the work is Domain 3; checking everything load-bearing before repeating it is Domain 2, and citations do not switch that off.
• Plans: Claude plans confidently around constraints you never mentioned, and nothing in the output warns you. An unconstrained plan is fiction that reads like competence. Countermeasure: put the real constraints in the brief, then ask the plan to list the assumptions it rests on.
• The optimisation loop, in order: describe the process → ask for candidate bottlenecks and what evidence would confirm each → gather that evidence → change the step the evidence indicts. Evidence comes after the hypotheses are named and before anything changes.
• The wrong bottleneck is the objective's most expensive mistake: optimising a step no evidence has indicted because the most plausible-sounding hypothesis got treated as confirmed.

The professional tell: the keyed answer goes and looks at local data (timings, logs, records) before changing anything. Distractors rebuild the process on fluent reasoning, or reach for a bigger feature when the missing ingredient was local facts.

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 aims the revision. "Make this survive a wet day" is testable. AI Fluency calls the rhythm the Description-Discernment Loop.
• Stop when the remaining changes are preference rather than fitness. When a round reveals the requirement itself is wrong, the next stop is the requirement, not another draft.
• Artifacts are the workbench: substantial standalone content lives in its own window, revisions happen by asking for changes, and 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 wins.

On the exam: the keyed answer names one criterion and checks the revision against it. Distractors polish without a criterion, generate volume and pick by feel, 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 never means 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 where the judgement lives.
• Stem triggers for escalation: automatically, without anyone having to, straight from the system, overnight. Connectors do not cross the line: 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. On the exam, a request for work that runs by itself is still an escalation.
• 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 is Domain 5's territory.

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 board pack takes two hours instead of five, measured across three months" survives a sceptic; "Claude has transformed how we work" is not a claim at all.
• The number rule: 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 a keyed answer is one the stem says was measured.
• Name the untested category. Silence about it gets heard as a claim, and the eventual failure lands on the report that stayed quiet.
• 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 surfaced, get every other claim re-read as curated.
• Two postures, one truthful account: the enthusiast needs the limitations and the human gate without losing momentum; the sceptic needs the measured result, the named human step, and the caught error. The caveat avalanche fails with both, because under-claiming starves working results of support.

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.