Quick Reference: Domain 6 — Stakeholder Communication & Lifecycle Management

Wrong options in Domain 6 come from four recurring postures. Name them and roughly nine questions become a matter of applying a rule. No Anthropic document describes this taxonomy and no question will use the words.

The right answer is almost always the fifth option: measure it, frame it, recommend, and leave the decision with the person who is accountable. When your wrong answers group by posture rather than by objective, practise the postures directly.

The request is not the requirement. The stated solution is evidence about the problem, never a substitute. Building first produces a demo on favourable data, and every later conversation starts from that demo; pricing first quotes work nobody has scoped.

Discovery is judged by its outputs, not by how many people were consulted:

• Anthropic's criteria standard (define-success): specific, measurable, achievable, relevant, with targets from benchmarks, prior experiments or expert knowledge. Its worked example replaces "the model should classify sentiments well" with a named held-out set of stated size, a quality floor, a safety rate, an inconvenient-versus-serious error split, and a response-time bound. Most use cases need several criteria, not one main number.
• Feasibility triage is discovery, not a later surprise: a decidable task with a verifiable output; data that exists, is good enough and may lawfully be used; a cost of error tolerable at an achievable accuracy. Saying no honestly, with the evidence, is a valid discovery outcome and can be the right answer to a scenario. Anthropic's agent guidance gives similar advice: find the simplest solution possible, adding complexity only when it demonstrably improves outcomes.
• Wrong options: the clickable demo, the fixed price, the ranked wish list from a workshop, and deferring data quality or lawful basis to design.

This objective is almost entirely professional craft rather than documented product behaviour. Its authority is the guide's description of the role: collaborating with cross-functional stakeholders and communicating architectural decisions effectively, in meetings with security, legal and executive participants.

The seven-part communication (ours): the decision · the options genuinely considered, including the one the audience expected · the criteria they were judged on · the evidence, which for a Claude system means measurements rather than assertions · what each option costs and exposes · the recommendation, because declining to recommend is a failure to do the job rather than neutrality · what would change the recommendation. The last part is what an architect includes and an advocate omits, and it is the content a decision record carries in 6.4.

• Translation changes what comes first, never the facts. For executives, start with consequence and risk. For engineers, start with mechanism and constraint. For legal, start with obligation and residual risk. For the sponsor, start with cost, date and what they are accepting. Giving an executive too much mechanism and giving a specialist generalities are opposite wrong options. Simplifying until the statement is no longer true is worse than either, because whoever trusted it finds out later.
• Probabilistic honesty is an obligation. State the error rate, the population it was measured on, and the handling path for the residual errors. A demonstration is a communication risk rather than a tool: it shows one of the system's best results and suggests that the system always behaves the same way, which it does not.
• Report uncertainty as an interval. Anthropic's evaluation research shows the reporting method: report the standard error and a confidence interval with each score, and give pairwise differences their own intervals, because a comparison without them may be presenting noise as a finding. A single confident number offered as the accuracy answer is a wrong option even when plausible.

The most frequently tested situation in the domain: an accountable stakeholder wants what the evidence contradicts. Measure, frame, recommend, and leave the decision with the person who is accountable — the quality difference as a number, the downstream cost, stated in the resource that the owner controls, the exposure, the saving, a clear recommendation, then their decision.

Read the question for the consequence, not for how loud the stakeholder is. Escalation is the last move, and only where the owner's authority does not cover the consequence.

Service levels are engineered, then promised. Never the reverse. The commitment comes from a measured envelope, which is the range of performance measured on the real pipeline with the real corpus under realistic concurrency. The commitment also leaves spare capacity for load that the measurement did not cover. A number that was promised before it was measured is a risk that is tied to a date.

Six elements. A question that offers a bare figure is offering a wrong option:

Anthropic's success-criteria example uses the same kind of detail for quality — a named held-out set (test data that is kept apart during development) of stated size, a quality floor, a safety rate, a response-time bound. The six-element framing is ours, drawn from established service-level practice.

Negotiating the impossible ask is the most commonly tested situation here. Show the decomposition so the figure stops being arbitrary, state the envelope the pipeline does hold, then reduce the gap where it can honestly be reduced: perceived responsiveness. Anthropic's latency guidance separates baseline latency from time to first token and recommends streaming because it improves how responsive an application feels. Progressive disclosure (showing information in stages), partial results and an asynchronous path with notification are the same method on other surfaces.

• None of those levers moves total completion time. Where the consumer is a parser or a batch job rather than a waiting person, they are a wrong option.
• Two moves are always wrong. Accepting a number the pipeline cannot hold is capitulation. Meeting it by deleting the retrieval or verification steps the answer depended on is worse: it trades a measured problem for an unmeasured one, and the promise met is no longer the promise made.
• Quality gets identical treatment. "It will be very accurate" fails as a bare duration fails. Where the shortfall concentrates in a segment, say so, commit on the population genuinely measured, and give that segment its own improvement plan, evidence and owner.
• The trap that looks like rigour: quietly narrowing the population until the main number becomes true. The excluded cases stay in production with no threshold, no review path and nobody accountable. A correct option may narrow a population, but only where the exclusion is visible and nobody is left uncovered by accident.

Dated. Re-verify against Anthropic's service-tier documentation before writing any availability clause; the tiers, the target and the commercial terms have all moved before. The point stays true when they change: a promise that is higher than the envelope the platform supports depends on somebody else's best effort.

• The commercial caveat is easy to miss: Priority Tier depends on an existing capacity commitment, and as of mid-2026 capacity commitments are documented as no longer available for purchase to organisations that do not already hold one. Do not assume the tier is available to a new client.
• Traffic beyond a committed capacity falls back to standard tier automatically — the promise degrades exactly when volume is highest. It is also a worked example of a planned response to a breach.
• In a negotiation: check the tier the system actually runs on, and mark anywhere the promise exceeds the envelope that the platform supports.

A feedback loop is instrumentation, not sentiment. It deserves that name because it produces evidence and disposition.

• Evidence: the channel converts a report into something workable — the trace, the case identifier, the reproducible input. "It gets things wrong sometimes" cannot be investigated; a trace can.
• Disposition: triage has a visible outcome, or the channel trains everyone to stop reporting and silence gets mistaken for quality.
• Permanence: confirmed failures route into Domain 4's regression set. Routing anecdotes straight into prompt edits makes a system worse over time. Each edit fixes the reported case and changes one that nobody mentioned.
• Relevance matters more than frequency. Reporting is led by the criteria discovery agreed, with engineering measurements underneath as support. A sponsor who agreed to a business outcome and receives infrastructure telemetry is no longer getting information that matters to them, and the fix is relevance, not a shorter interval or a longer deck.
• Scope change is the same discipline pointed at the plan: weigh each request against the agreed criteria and baseline, put cost, date and risk to the sponsor before anyone commits, and reset the plan under their signature. Accepting extra scope without telling anyone and refusing every scope request both fail; accepting extra scope by cutting testing that nobody agreed to cut is the worst option available, and the exam offers it.

Documentation transfers judgement, not history. The next person needs what was decided, on what evidence, what consequences were accepted, and how to tell whether they have broken something. The test for every page is whether it changes what a competent stranger would do.

The artefact set is established practice, described in our own words. Decision records and runbooks are long-standing industry artefacts, not Anthropic products.

• Two questions test a pack (ours): can a competent engineer who was not there change the system safely, and will they know when they have broken something. Anything answering neither exists for the author's benefit. Page count answers neither; a recorded walkthrough answers the first only while the system still resembles the recording.
• The baseline is the most important artefact, the only artefact answering the second question. Anthropic's evaluation guidance gives its design standard: task-specific, edge cases included, automated where possible, volume prioritised over hand-grading. Anthropic's research gives the comparability standard: report the interval with each score, so a re-run reads as better, worse or indistinguishable rather than merely different. Domain 4 designs the suite; packaging it as transferable belongs to this domain.
• Discoverability is part of correctness. Documentation that no longer matches the running system is worse than none because it is believed. Keep it beside the code, version it with the code, change it in the review that changes the behaviour. A thorough wiki in a tool the team never opens is a document that only its author reads.
• Implementation guidance is more than a diagram: the sequence, the risky steps and therefore the order that is not negotiable, the gates, a definition of done for each. Guidance that names the components and stops has delivered the part that nobody was unsure about.

Phases are gated by what they produce, not by dates. Output gating is our framing; nothing depends on reciting phase names, and no question may reward project-management vocabulary.

• Ownership transfer is capability transfer. Four abilities decide whether handover happened: run the evaluations and get a comparable answer, read a trace well enough to localise a failure, roll a change back, and know who to reach when none of that is enough. A team missing any of them will operate the system and refuse to change it, which looks like stability and is an inability to change the system. Domain 7 does the enabling; Domain 6 decides what must be true and verifies it.
• Iteration is evidence-gated. Prompt edits shipped in response to last week's complaints with no regression suite is uncontrolled change that the team hopes is an improvement.
• Moving backwards is professional. Production evidence contradicting a discovery assumption sends the work back to discovery. Treating the phase order as one-way is the wrong option.
• A lack of complaints is not evidence. A system nobody has complained about, whose baseline has not been re-run and whose corpus has changed, is not proven to be healthy.

Dated. Re-verify the states, the notice period and the checklist against Anthropic's model-deprecation and migration documentation before planning against them. The architectural meaning does not change: a deprecation is a scheduled re-validation, not an incident.

• Notice: Anthropic commits to notifying customers with active deployments at least 60 days before retiring a publicly released model. Treat that as the planning horizon, not the working window.
• The documented moves: test with the replacement well before the retirement date, and audit usage by API key and model to find where the old version is still called. A pinned version in a forgotten job is the usual surprise.
• Re-benchmarking cost and latency is on every migration path: a documented checklist item in its own right, alongside the behaviour changes each path calls out for explicit re-testing. It is neither the last step nor an optional extra, and it is what makes the next comparison mean anything.
• The same treatment applies to events with no notice period: corpus migrations, connector and dependency changes, regulatory change, and the redesign of the business process the system serves. Each forces re-validation, and each is cheaper planned for in design.
• Wrong option: handing a deprecation to the commercial or vendor-relationship owner. The date and the replacement are commercial facts; re-validating against the baseline is architectural and cannot be passed on.

Half the wrong answers here are right answers to a neighbouring domain's question.

Question formats and our conventions. The guide names multiple-choice and multiple-response, and states that every multiple-response question says how many responses to select; it states no partial-credit policy. We additionally drill scenario-matching, several short scenarios classified against one shared reusable option set, because it tests the same judgement under tighter conditions. That format, all-or-nothing scoring, and the positional scoring we apply to matching drills are our practice conventions rather than stated exam rules.