The Four Failure Postures
Our name for the four forms that every wrong option in Domain 6 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 a first step. Theatre gives more information when the problem is that the information is not relevant. The taxonomy is ours rather than Anthropic's, and no exam question will use the words.
Exam context: Learn the four and roughly nine questions become a matter of applying a rule, because the right answer is nearly always a fifth approach: measure, frame, 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.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Request Versus Requirement
The difference between the solution that a stakeholder asks for and the problem that the solution is meant to solve. The stated solution is evidence about the requirement and never a substitute for it. For this reason, the architect's first act is neither a prototype nor a price.
Exam context: Questions open with a proposed solution and offer the four postures as options. Building ties every later conversation to a design that nobody justified; pricing quotes work nobody has scoped. The right 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 measured as a difference from it, and it cannot be reconstructed once the system has changed the process it measured.
Exam context: In a question where nobody captured the old numbers, 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 many later steps the error reaches before somebody finds it, and what it costs. The accuracy threshold for a wrong suggestion that a human reviews differs from the threshold for a wrong figure that goes unchecked into a payment or a filing.
Exam context: The discovery answer that the most later decisions depend on. It sets the accuracy threshold, decides whether a human checkpoint must be part of the design, and decides the latency and cost that the design will have. 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 example compares a weak criterion with a strong one, and the strong one shows the form to aim for. It replaces "the model should classify sentiments well" with a named held-out set of stated size, a quality floor, a safety rate, an error-severity split and a response-time bound. Directional criteria, which state a direction of change but no threshold, 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 its current form: 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 treat the honest no as the right answer. "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 start to cause problems.
Exam context: This term connects 6.1 and 6.2. Discovery names the owner; the steps for handling a disagreement leave the decision with them. A ranked wish list from a workshop has no owner, which is precisely why nothing in it can be given a threshold.
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: Questions 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, even when an architect presents it.
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 change the recommendation. It makes the recommendation into a decision that can be reopened without arguing the whole question again.
Exam context: The part that an architect includes and an advocate omits, and the same content a decision record carries in 6.4. Write it once and use it in both the communication and the decision record. Anything phrased as "if circumstances change" is not a condition.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Audience Translation
Changing what comes first and how much mechanism you give for each audience, while the facts stay identical. For executives, start with business consequence and risk. For engineers, start with mechanism and constraint. For legal and compliance, start with obligation and residual risk. For the sponsor, start with cost, date and what they are accepting.
Exam context: Giving an executive too much mechanism and giving a specialist generalities are opposite wrong options. Simplifying until the statement is no longer true is the third and worst: an option that gives two audiences different facts is always wrong.
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. It also means reporting uncertainty as an interval rather than a point. Anthropic's evaluation research shows the reporting method: 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 wrong option even when plausible; the right 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 shows one of the system's best results and suggests that the system always behaves the same way, which it does not.
See also: 6.2 Communicating Architectural Decisions and Trade-offs
Disagreement Pattern
The right sequence when an accountable stakeholder wants what the evidence contradicts: the quality difference as a number, the downstream cost, stated in the resource that the owner controls, the exposure it creates, the saving it delivers, a clear recommendation, and then their decision.
Exam context: The most frequent type of question in the objective, with the four postures as its wrong options. 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 answer that lets the owner decide 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 nobody has the right to accept.
Exam context: The question text tells you which case it is by the actual result of being wrong. If the consequence is a margin, a date or a quality level, the owner decides. If it is an unlawful data path or an unsupervised action with a safety consequence, it is an 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 (the documents and data the system uses) under realistic concurrency, then write down what may be committed to, with 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.
Exam context: The clue in a question is where the figure came from. A demonstration, a best case and a competitor's marketing claim are the same failure in different forms, and accepting any of them is capitulation.
See also: 6.3 Expectation Alignment and Service-Level Commitments
Six-Element Commitment
Our list of the parts 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 uses the same kind of detail for quality.
Exam context: Any option offering a bare number is wrong. "Two seconds" states a goal but does not say how it is measured; 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 opposite is silent redefinition. This means narrowing the population until the main number becomes true. The excluded cases stay in production with no threshold, no review path and nobody accountable. It looks like rigour, which is why it is the most convincing wrong option in the objective. A correct 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 method for closing a latency gap you cannot close in the pipeline: streaming, progressive disclosure (showing information in stages), 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: The right answer where a human is waiting at the screen and a wrong answer where the consumer is a parser or a batch job, because total completion time is unchanged either way. Never confuse it with meeting the target 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. Reports are triaged on a regular schedule, and the outcome of each report is visible. There is a route from confirmed failure into Domain 4's regression set. "It gets things wrong sometimes" cannot be investigated; a trace can.
Exam context: A channel where reports get no visible outcome teaches everyone to stop using it, after which the absence of complaints gets mistaken for quality. Reporting follows the same discipline. Start with the criteria that discovery agreed, and put the engineering measurements below them. This is because a disengaged sponsor needs relevance rather than frequency. More reports, more metrics and a longer deck are all examples of 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. Before anyone commits, the sponsor sees its cost, date and risk. Once what has been accepted no longer fits the plan, the plan is reset and the sponsor signs it.
Exam context: 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, 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 offers the reduced one as a wrong option. A record carrying only the decision leaves the next architect to argue again about 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 for an on-call engineer at two in the morning rather than from the designer's point of view. Established practice rather than documented Anthropic behaviour.
Exam context: Entries starting from a component name do not match what the engineer sees 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 question of how to detect that something is broken.
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 most important artefact and the usual right answer in handover questions, 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 justified by one of them; anything answering neither exists for the author's benefit.
Exam context: When a handover has failed, the right 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 add to 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. The mitigations are structural: keep it beside the code, version it with the code, and 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 wrong option that looks thorough.
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 must produce a measured problem and agreed criteria; design must produce the architecture, decision records, evaluation plan and service-level envelope (the range of service levels that the engineering can support); build must produce a measurement rather than a demonstration.
Exam context: Our framing, and nothing depends 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 show whether the project was finished.
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 the system 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 an inability to change the system. Domain 7 does the enabling with tooling and workflows; deciding what must be true and verifying it happened belongs to this domain.
See also: 6.5 Supporting the Lifecycle Phases
Evidence-Gated Iteration
Change that a monitoring signal justifies. The change is specified and must pass the evaluation suite. If the change legitimately moved the measured baseline, the baseline is measured again. Domain 4's discipline applied as a lifecycle rule, with iteration returning to design rather than bypassing it.
Exam context: The plausible failure is the one the exam offers as a tempting wrong answer: prompt edits shipped in response to last week's complaints with no regression suite, described as continuous improvement. Each edit fixes the reported case and silently changes 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 a refusal of the work, presented 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 changed. Having no complaints is not a measurement.
Exam context: Questions offer stability as the reason to skip re-validation and new work as the reason to hurry. Waiting for complaints is the evasion posture, presented as 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 wrong options treat the phase order as one-way, or reframe the contradiction as a scope item for later.
See also: 6.5 Supporting the Lifecycle Phases