The Four Failure Postures
Our name for the four shapes every Domain 6 distractor takes: capitulation agrees to what no measurement supports, evasion complies silently or builds it your way quietly, obstruction refuses or escalates over the accountable owner as an opening move, and theatre answers a problem of relevance with more volume. The taxonomy is ours rather than Anthropic's, and no exam item will use the words.
Exam context: Learn the four and roughly nine items become mechanical, because the keyed option is nearly always the fifth thing: measure, frame, recommend, and leave the decision where the accountability sits. When misses cluster by posture rather than by objective, drill the postures.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Request Versus Requirement
The gap between the solution a stakeholder arrives carrying and the problem underneath it. The stated solution is evidence about the requirement and never a substitute for it, which is why the architect's first act is neither a prototype nor a price.
Exam context: Stems open with a proposed solution and offer the four postures as options. Building anchors every later conversation to a shape nobody justified; pricing quotes work nobody has scoped. The keyed option produces answers that change the architecture.
See also: 6.1 Structured Discovery and Requirement Gathering
Measured Baseline
The current cost of the problem, established before anything is built: hours, error rates, backlog, revenue at risk, with a stated method and source. Every later benefit claim is a delta against it, and it cannot be reconstructed once the system has changed the process it measured.
Exam context: A stem where nobody captured the old numbers is a stem where success can never be demonstrated. "Days lost every month" quoted by a stakeholder is an assertion until somebody measures it.
See also: 6.1 Structured Discovery and Requirement Gathering
Consequence of Error
What happens when the system's output is wrong: who is harmed, how far the error travels before somebody catches it, and what it costs. A wrong suggestion a human reviews sets one bar; a wrong figure flowing unchecked into a payment or a filing sets another.
Exam context: The single most load-bearing discovery answer. It sets the accuracy threshold, decides whether a human checkpoint is structural, and prices the latency and cost envelope. Discovery that captured a feature list but never asked it produced a scope, not a requirement.
See also: 6.1 Structured Discovery and Requirement Gathering
Measurable Success Criteria
Criteria that can be passed or failed: a metric, a threshold, the population it applies to, and a named owner. Anthropic's standard is that they be specific, measurable, achievable and relevant, with targets drawn from benchmarks, prior experiments or expert knowledge rather than optimism.
Exam context: Anthropic's worked contrast is the shape to reach — a named held-out set of stated size, a quality floor, a safety rate, an error-severity split and a response-time bound, replacing "the model should classify sentiments well". Directional criteria appear inside otherwise sensible options.
See also: 6.1 Structured Discovery and Requirement Gathering
Feasibility Triage
The three questions that decide whether an engagement proceeds in this shape: is the task decidable with a verifiable output, does the data exist and may it lawfully be used, and is the cost of being wrong tolerable at an accuracy that is actually achievable.
Exam context: A no to any of them is a finding rather than a failure, and the exam does key the honest no. "This is a data-quality problem no model fixes" is a professional output; scoping a smaller version of the same mistake is not.
See also: 6.1 Structured Discovery and Requirement Gathering
Accountable Decision-Maker
The named person with the authority to accept a consequence, as distinct from the loudest stakeholder or the largest user group. Discovery identifies them because a requirement with no owner cannot be traded off later when the constraints bite.
Exam context: This term is the hinge between 6.1 and 6.2. Discovery names the owner; the disagreement pattern leaves the decision with them. A ranked wish list from a workshop has no owner, which is precisely why nothing in it can be thresholded.
See also: 6.1 Structured Discovery and Requirement Gathering
Complete Architectural Communication
Our seven-part structure for presenting a decision: the decision, the options genuinely considered, the criteria they were judged on, the evidence, what each option costs and exposes, the recommendation, and what would change the recommendation. Professional practice rather than anything Anthropic publishes.
Exam context: Items reward completeness of reasoning rather than eloquence, because completeness is what lets somebody else evaluate a decision instead of merely accepting it. A recommendation with no alternatives, criteria or evidence is an opinion in an architect's font.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Revisit Condition
The last clause of a complete communication: the measurement, volume, price change or regulatory event that would flip the recommendation. It converts a position into a piece of engineering that can be reopened without re-arguing the whole question.
Exam context: The part that separates an architect from an advocate, and the same content a decision record carries in 6.4. Write it once and use it twice. Anything phrased as "if circumstances change" is not a condition.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Audience Translation
Changing the lead and the level of mechanism for each room while the facts stay identical. Executives lead on business consequence and risk, engineers on mechanism and constraint, legal and compliance on obligation and residual risk, the sponsor on cost, date and what they are accepting.
Exam context: Burying an executive in mechanism and handing a specialist generalities are symmetrical distractors. Simplifying past the point of truth is the third and worst: an option that gives two rooms different facts is keyed wrong every time.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Probabilistic Honesty
Stating the error rate, the population it was measured on, and the handling path for the residual errors before anybody signs, plus reporting uncertainty as an interval rather than a point. Anthropic's evaluation research supplies the register: the standard error and a confidence interval alongside each score, and pairwise differences with their own intervals.
Exam context: A single confident accuracy number is a distractor even when plausible; the keyed option gives a range on a defined population plus the measurement that would narrow it. The related trap is the demo offered as evidence of expected behaviour: it is a sample from the favourable tail, implying a determinism the system does not have.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Disagreement Pattern
The keyed sequence when an accountable stakeholder wants what the evidence contradicts: the quality difference as a number, the downstream cost in the currency the owner controls, the exposure it creates, the saving it delivers, a clear recommendation, and then their decision.
Exam context: The most frequent stem shape in the objective, with the four postures as its distractors. Escalation is the last move, not the first, and only where the owner's authority does not cover the consequence.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Obligation Exception
The case where the owner-decides answer is wrong. An owner's authority covers cost against quality and scope against date, because they can accept the consequence. It does not cover a legal, regulatory or safety obligation, which is nobody's preference to accept.
Exam context: The stem tells you which case it is by what being wrong actually does. A margin, a date or a quality level says the owner decides; an unlawful data path or an unsupervised action with a safety consequence says obligation, and Domain 5 owns what happens next.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Engineered, Then Promised
The order that defines the objective: measure the real pipeline on the real corpus under realistic concurrency, then write down what may be committed to, with headroom for load the measurement never saw. A number that travelled the other way is a liability with a date on it.
Exam context: The tell in a stem is where the figure came from. A demonstration, a best case and a competitor's marketing claim are the same failure wearing different clothes, and accepting any of them is capitulation.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Six-Element Commitment
Our anatomy of a defensible service level: the metric, the percentile or threshold, the measurement point, the window, the population and the breach behaviour. Established service-level practice rather than Anthropic guidance, though Anthropic's own success-criteria example reaches the same register from the quality side.
Exam context: Any option offering a bare number is a distractor. "Two seconds" is a wish; the same figure with a percentile, a measurement point, a window, a population and a stated breach path is something an engineer can alert on and a lawyer can put in a schedule.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Covered Population
Who and what a commitment applies to, defined honestly before the measurement rather than after it. Where a shortfall concentrates in an identifiable segment, the professional response names the segment, commits on the population genuinely measured, and gives the segment its own improvement plan and owner.
Exam context: Its dangerous inverse is silent redefinition — narrowing the population until the headline number becomes true, leaving the excluded cases in production with no threshold, no review path and nobody accountable. It reads as rigour, which is why it is the most respectable distractor in the objective. A keyed option may narrow a population, but only where the exclusion is visible and nobody is left uncovered by accident.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Perceived Responsiveness
The honest lever for closing a latency gap you cannot close in the pipeline: streaming, progressive disclosure, partial results, or an asynchronous path with notification. Anthropic's latency guidance separates baseline latency from time to first token and recommends streaming because it improves how responsive an application feels.
Exam context: Keyed where a human is waiting at the screen and a distractor where the consumer is a parser or a batch job, because total completion time is unchanged either way. Never confuse it with hitting the number by deleting a retrieval or verification stage.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Feedback Instrumentation
A channel that converts a user report into evidence — the trace, the case identifier, the reproducible input — with a triage rhythm whose disposition is visible, and a route from confirmed failure into Domain 4's regression set. "It gets things wrong sometimes" cannot be worked; a trace can.
Exam context: A channel that swallows reports trains everyone to stop using it, after which the absence of complaints gets mistaken for quality. The reporting half is the same discipline: lead with the criteria discovery agreed and carry the engineering measurements underneath, because a disengaged sponsor needs relevance rather than frequency, and more reports, more metrics and a longer deck are all the theatre posture.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Scope-Change Discipline
Weighing each new request against the agreed criteria and baseline, putting its cost, date and risk in front of the sponsor before anyone commits, and resetting the plan under their signature once what has been accepted no longer fits inside it.
Exam context: Silent absorption and blanket refusal both fail. Absorbing scope by cutting testing that nobody agreed to cut is the worst option available and the exam plants it, because it converts a visible schedule problem into an invisible quality one.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Judgement Transfer
The purpose of documentation, as against narrating history. The next person does not need what the team tried in week three; they need what was decided, on what evidence, what consequences were accepted, and how to tell whether they have broken something.
Exam context: The test for every page is whether it changes what a competent stranger would do. Most handover packs contain the project narrative instead, which helps nobody adjusting a retrieval configuration on a Tuesday.
See also: 6.4 Documentation and Implementation Guidance
Architecture Decision Record
A record of one significant decision: the context, the options, the criteria, the choice, the consequences accepted, and the condition that should trigger revisiting it. Kept append-only, with superseded entries marked rather than deleted. A long-established industry practice, not an Anthropic product feature.
Exam context: The exam rewards the full version and plants the reduced one. A record carrying only the decision leaves the next architect to re-litigate a settled question with none of the evidence, so settled questions reopen by accident.
See also: 6.4 Documentation and Implementation Guidance
Operational Runbook
The likely failure modes with a diagnostic path, the containment options and who to call, written from the position of an on-call engineer at two in the morning rather than the designer's position at the whiteboard. Established practice rather than documented Anthropic behaviour.
Exam context: Entries starting from a component name describe a system nobody is looking at during an incident; entries starting from the alert or the user symptom are usable. A restart procedure is operations, not evaluation, and does not cover the detecting-breakage question.
See also: 6.4 Documentation and Implementation Guidance
Evaluation Baseline Handover
Packaging the evaluation suite as a transferable artefact: the suite itself, the datasets it runs on, the numbers as they stood at handover with their intervals, and instructions that let somebody else re-run it and get a comparable answer.
Exam context: The keystone artefact and the usual keyed answer in handover stems, because it is the only one answering "will I know if I broke it". Domain 4 designs the suite and produces the numbers; packaging and transferring it is Domain 6's half.
See also: 6.4 Documentation and Implementation Guidance
Handover Test
Our two-question test for a pack: can a competent engineer who was not there change the system safely, and will they know when they have broken something. Every artefact should be defensible against one of them; anything answering neither is there for the author.
Exam context: When a handover has failed, the keyed option adds the missing artefact type rather than more of the type that already exists. Richer diagrams, a longer limitations list and a second walkthrough all deepen a capability the team already has.
See also: 6.4 Documentation and Implementation Guidance
Documentation Drift
Documentation that no longer describes the running system. It is worse than no documentation, because it is believed by exactly the person least able to detect the error, and the mitigations are structural: keep it beside the code, version it with the code, change it in the review that changes the behaviour.
Exam context: Discoverability is part of the artefact rather than a nicety. A thorough wiki in a tool the inheriting team never opens is functionally a private document, and a distractor dressed as thoroughness.
See also: 6.4 Documentation and Implementation Guidance
Output-Gated Phase
A phase defined by what it must produce before the next one can honestly begin, rather than by the date it is due. Discovery owes a measured problem and agreed criteria; design owes the architecture, decision records, evaluation plan and service-level envelope; build owes a measurement rather than a demonstration.
Exam context: Our framing, and nothing turns on reciting the phase names. Date-gated delivery produces a project that can be delivered exactly on schedule and still be impossible to declare finished, because nothing was produced that could settle the question.
See also: 6.5 Supporting the Lifecycle Phases
Capability Transfer
What handover actually transfers, tested by four abilities: can the receiving team run the evaluations and get a comparable answer, read a trace well enough to localise a failure, roll a change back, and reach the people who know when none of that is enough.
Exam context: A team missing any of the four will operate the system and refuse to change it, which looks like stability and is paralysis. Domain 7 does the enabling with tooling and workflows; deciding what must be true and verifying it happened is here.
See also: 6.5 Supporting the Lifecycle Phases
Evidence-Gated Iteration
Change licensed by a monitoring signal, specified, gated by the evaluation suite, and re-baselined if the floor legitimately moved. Domain 4's discipline arriving as a lifecycle rule, with iteration re-entering design rather than bypassing it.
Exam context: The plausible failure is the planted one: prompt edits shipped against last week's complaints with no regression suite, described as continuous improvement. Each edit fixes the reported case and silently moves one that was not, and with no baseline nobody can tell.
See also: 6.5 Supporting the Lifecycle Phases
Scheduled Re-validation
Treating a foreseeable lifecycle event as planned work with a known date rather than as an incident. Model deprecation is the documented example; corpus migrations, connector and dependency changes, regulatory change and business-process redesign force the same re-measurement with no notice period attached.
Exam context: Handing a deprecation to a commercial or vendor-relationship owner is obstruction as delegation. The retirement date and the replacement are commercial facts; re-validating the system against its baseline on the new version is architectural and cannot be passed on.
See also: 6.5 Supporting the Lifecycle Phases
Unevidenced Stability
A system that is quiet rather than demonstrably healthy: no complaints, no re-run baseline, and a corpus or model version that has moved underneath it. Quiet is a measurement nobody took.
Exam context: Stems offer stability as the reason to skip re-validation and new work as the reason to hurry. Waiting for complaints is the evasion posture wearing patience, because complaints are the most lagging and most expensive signal available.
See also: 6.5 Supporting the Lifecycle Phases
Backward Phase Move
Returning to an earlier phase when production evidence contradicts an assumption the later phases were built on: the real users are not who discovery described, the consequence of error is worse than stated, or the corpus does not hold what the criteria assumed.
Exam context: Professional rather than a failure, and far cheaper than continuing to build against something already known to be false. The distractors treat the phase order as a one-way ratchet, or reframe the contradiction as a scope item for later.
See also: 6.5 Supporting the Lifecycle Phases