Stakeholder Communication & Lifecycle Management · Lesson 2 of 5

5.2 - Communicating Architectural Decisions and Trade-offs

Communicate a Claude architecture decision to executives, engineers and risk teams by framing options with trade-offs, stating limitations with evidence, and capturing the rationale in a decision record that outlives the meeting.

An architecture decision is only as good as the group's ability to understand it, challenge it and remember why it was made. On Claude projects that is harder than usual: the system is probabilistic, its quality is an evidence question rather than a yes/no, and the audience ranges from a sponsor who wants a budget answer to a security reviewer who wants a data-flow diagram. Four skills recur: tailoring the message to the audience, framing options with trade-offs instead of announcing a verdict, stating limitations honestly, and recording the decision so the reasoning survives.

Tailor to the decision the audience owns

Do not vary the truth for different audiences; vary the question you answer. Each group is deciding something different, so lead with the information that decision needs.

Audience	Decision they own	Lead with	Avoid
Executives and sponsors	Fund, proceed, accept risk	Business outcome, cost and timeline in ranges, risk in business terms, the decision needed and by when	Prompt and token mechanics; framework names
Engineers and build teams	How to build and operate it	Mechanism, interfaces, failure modes, alternatives rejected and why, operational load	Pitch language; unqualified claims
Risk, compliance, security	Whether controls are adequate	Data flow, what crosses which boundary, human review points, audit trail, residual risk with evidence	Assurances without evidence; claims about a vendor's compliance you have not verified
Affected staff and end users	How their work changes	What it does, when to trust versus check, how to report a problem	Jargon; implying it replaces judgement

A useful test: could each audience state, after your briefing, what they are being asked to decide and what they would be accepting if they said yes?

Present options with trade-offs, not a fait accompli

A recommendation presented as the only option invites either blind acceptance or suspicion, and hides the trade-offs the audience is entitled to weigh. The standard shape is: the decision to be made; two or three genuinely viable options, including a simpler baseline (a deterministic workflow, or a single call instead of an agent); the criteria that matter to this audience, taken from discovery (lesson 5.1); how each option scores and on what evidence; your recommendation and why; and what would change your mind.

Claude-specific options are usually differences of degree along a few axes: human-reviewed versus autonomous output; synchronous versus asynchronous processing (Anthropic documents a batch interface for work that can wait, trading immediacy for cost and throughput); a more capable model versus a faster, cheaper one with an effort setting tuned; a managed platform versus a partner cloud with different lifecycle and data-handling terms. Express cost in relative terms or link the current pricing page; a pasted number goes stale. Anthropic's guidance to prefer the simplest solution that works is a good default, since each added layer of autonomy trades latency, money and auditability for performance.

Key concept

Every claim about a Claude system should carry three parts: what it reliably does in this specific use case, what still needs human review and why, and the evidence behind both (results over many real cases, not one demo). This structure avoids over-promising, where output is implied to need no review, and under-selling, where generic caveats leave a sound use case unadopted. It is also checkable: a stakeholder can ask “show me the cases” or “who is the reviewer” and get a concrete answer.

Stating limitations honestly

Honest limitations are specific and scoped, not a blanket disclaimer. Because output is probabilistic, quality claims should be rates measured on a defined test set, with sample size and date, for example “correct on N of M reviewed cases in the March sample, with the errors concentrated in scanned documents”. Three Claude-specific points belong in the limitations you communicate:

Errors are reduced, not eliminated. Anthropic's guidance on hallucinations describes techniques such as allowing the model to say it does not know, grounding in quotes and requiring citations, and states that they reduce hallucinations significantly but do not eliminate them, so critical outputs need validation. This is why the review step is part of the design, not an apology.
Claims are tied to a configuration. A model ID identifies a pinned version whose weights do not change, but Anthropic notes that the serving infrastructure around it (routing, safety classifiers, sampling logic) can change and occasionally cause minor behavioural differences. And when you move to a new model ID, behaviour can differ. So a quality statement should name the model ID and prompt version it was measured on and say it will be re-tested on change (see lesson 5.5).
Vendor benchmarks are not your evidence. They measure someone else's tasks, not your cases.

Avoid the opposite failure too. “AI can make mistakes, so use with caution” gives a decision-maker nothing to weigh. Compare “Claude drafts; the duty analyst reviews every draft before release; in the sample so far it saved a large share of drafting time and the reviewer caught the errors”, which states value, limitation and safeguard together.

Decision records make the reasoning durable

A meeting is ephemeral; the reasons behind a decision are what a future team needs when circumstances change. The architecture decision record (ADR) practice, popularised by Michael Nygard, captures one architecturally significant decision with its rationale. His format has a short title, a status (proposed, accepted, deprecated or superseded), the context (the forces at play, described neutrally), the decision in full sentences (“We will...”), and the consequences, all of them, not only the positive ones. Records are kept short, numbered sequentially, and never edited to hide history: when a decision is reversed, the old record stays and is marked superseded by the new one.

For a Claude system, extend the template with the items that will otherwise be lost: the options considered and why each was rejected; a link to the eval results that supported the choice; the model ID, prompt version and key settings at decision time; the owner; and explicit revisit triggers, such as a deprecation notice, a material cost change or an eval regression.

Common exam distractor

Options that describe Claude output as “fully automated” or “no review needed” for a consequential task are the classic over-promise, and a single successful demo is not evidence. Equally wrong are the mirror images: a vague blanket warning with no specific value claim, and a single-option recommendation delivered as a done deal. Also watch for briefings that hand every audience the same technical deck, and for decision records that log the outcome but not the alternatives, consequences or revisit conditions. The best answer names the audience's decision, offers options with trade-offs, pairs value with a specific limitation and evidence, and records it.

When the room pushes back

Answer challenges with evidence, not reassurance: the cases, the measured rate, the review process. When you do not know, say how and when you will find out. If a stakeholder wants a guarantee the technology cannot give, such as identical outputs on every run or zero factual errors, do not concede it to close the meeting. Reframe to what you can commit to: a measured error rate, a review step, an escalation path, and a monitored target (lesson 5.3).

Exam traps

Presenting the same detailed technical deck to executives, engineers and the compliance team.

Each audience owns a different decision. Executives need outcome, cost, risk and the decision required; engineers need mechanism and failure modes; risk teams need data flow, controls and evidence. One deck serves none of them well.
Announcing a single recommended architecture without alternatives, to save time and avoid debate.

Without options and trade-offs, stakeholders cannot judge the recommendation or see what they are accepting. The strong pattern is two or three viable options, including a simpler baseline, criteria, evidence, a recommendation and what would change it.
Telling leadership that Claude's output is fully automated and needs no review, backed by a successful demo.

This over-promises. One demo does not represent real-world variation, and the first plausible error will damage trust in the whole solution. Name the review step and back claims with results across many real cases.
Recording only the final decision in the ADR and later editing it when the plan changes.

A useful record captures context, options, consequences and revisit triggers. Records are not rewritten; a reversed decision is marked superseded by a new record, preserving the history and reasoning.

Practice question

You have chosen a design in which Claude drafts responses to regulatory enquiries and a compliance analyst reviews each one before it is sent. You must brief the executive steering committee to obtain approval and also record the decision. Which approach is best?

A Walk the committee through the prompt structure, token usage and model configuration so they can see exactly how it works, and file the slides afterwards as the permanent record of the decision, its rationale and the alternatives considered.
This answers an engineer's question, not the committee's decision. Implementation detail buries the choice they must make, and slides are not a decision record with context, alternatives and consequences.
B Offer two or three options (including the manual process) scored on cost, risk and time to value; recommend one, with what it reliably does, what the analyst still reviews and evidence from real cases; state what would change it; record it in an ADR. Correct
It tailors to the audience's decision, exposes trade-offs, pairs value with a specific limitation and evidence, and captures durable rationale in a decision record.
C Present only the recommended design with detailed accuracy charts from a public model benchmark to show the approach is safe, and keep the limitations in an appendix so that the discussion stays on the benefits and a decision comes quickly.
A single option hides trade-offs, and a public benchmark is not evidence about your regulatory enquiries. Relegating limitations to an appendix undermines the honesty the audience needs to accept risk knowingly.
D Tell the committee that Claude will handle enquiries automatically and that analyst review is only a temporary precaution, so they approve on the expectation of full automation and lower headcount later, with no plan to revisit the design.
This is over-promising. It misstates the design (review is part of it) and sets an expectation that will break at the first error, damaging trust in the whole solution.

Build exercise: One decision, three audiences, one decision record

Intermediate · 50 minutes

You'll practice:

Reframe a single architectural decision for executive, engineering and risk audiences
Present options with criteria, evidence and a what-would-change-my-mind statement
Write specific, evidence-backed statements of value and limitation for a probabilistic system
Author a decision record that includes alternatives, consequences and revisit triggers

Choose a decision from a Claude scenario you know (for example: synchronous human-reviewed drafting versus overnight batch processing for document summaries, or a larger model versus a smaller one with tuned settings). Write it as a single sentence in the form 'We must decide whether to ... given ...'. List three options, including a simpler non-LLM or lower-autonomy baseline.

The decision statement fixes what the audience is being asked. Including a simple baseline prevents a one-sided recommendation.

You should see: A one-sentence decision statement and three options, one of which is deliberately simple or conservative.
Hints
1. ```
What would the team do if Claude were not available at all? That is usually a legitimate baseline option.
```
2. ```
Vary the options along one or two axes (autonomy, latency, model capability, platform) so the trade-offs are visible.
```
3. ```
Example: 'We must decide how Claude-generated summaries reach customers, given review capacity of two analysts. Option 1: analyst reviews every summary before release. Option 2: auto-release low-risk categories, review the rest. Option 3: keep the manual process and use Claude only for internal search.'
```
Build a comparison table scoring the three options against four to five criteria drawn from a plausible discovery output (for example error impact, time to value, review workload, cost range, auditability). For each score, state the evidence or the assumption behind it, and mark assumptions clearly.

Criteria plus evidence let each audience weigh the options themselves, and marking assumptions shows where the recommendation is soft.

You should see: A table in which every cell has a rating and a 'because' with either evidence (a measured sample, a docs link) or an explicit 'assumed' tag.
Hints
1. ```
For each rating, could a sceptical colleague ask 'how do you know?' and get an answer?
```
2. ```
Use relative terms (lower, similar, higher) for cost and link to the current pricing page instead of quoting numbers.
```
3. ```
Example cell: 'Error impact: medium for Option 2 because a wrong auto-release reaches a customer; assumed 5 percent of cases are misclassified as low-risk; to be measured on the labelled sample before launch.'
```
Write three briefings of at most 150 words each for the same recommended option: one for the executive sponsor, one for the build team, one for the security and compliance reviewer. Each must start with what that audience decides and include one specific limitation with its safeguard.

This is the tailoring skill in practice. The facts stay the same; the lead, the level of detail and the questions answered change.

You should see: Three short briefings whose first sentences are clearly different, with the same underlying facts and no contradictions between them.
Hints
1. ```
What is the first question each reader will have, and does your opening sentence answer it?
```
2. ```
Executive: outcome, cost range, risk, decision needed. Engineer: mechanism, failure modes, interfaces. Risk reviewer: data flow, review point, audit trail, residual risk.
```
3. ```
Example risk-reviewer opening: 'Customer text is sent to the model API for summarisation; no output is released without analyst approval; inputs, outputs, model ID and prompt version are logged for audit; residual risk is an analyst approving an incorrect summary, mitigated by sampling reviews.'
```
Rewrite this claim so that it names the value, the review step and the evidence, and no longer over-promises or under-sells: 'Claude now handles all our tier-1 tickets, so no one needs to check them.' Then write its under-selling opposite, and explain in one sentence what makes each wrong.

Recognising both failure modes is what lets you choose the accurate option in a scenario question.

You should see: An over-promise, an under-sell and a corrected statement, plus one-line diagnoses, such as 'implies zero review' and 'no specific value or evidence'.
Hints
1. ```
Which phrase in the original would break first if Claude made one confident error?
```
2. ```
Use the three-part structure: reliable value, human review and who does it, evidence from many real cases.
```
3. ```
Example fix: 'Claude drafts replies for password-reset and billing tickets; a support agent reviews each before sending. Across the last 300 tickets it cut handling time and agents corrected roughly one draft in twenty (figures to be replaced with your measured results).'
```
Write the decision record (one to two pages) using the Nygard sections plus these Claude-specific additions: options considered, link to eval evidence, model ID and prompt version at decision time, owner and revisit triggers. Then mark a second record as 'superseded' by imagining that a model deprecation notice forces a change, and write the two-line status update.

Practising the supersede workflow shows why records are immutable and how history is preserved.

You should see: A completed record with status 'accepted' and a second stub whose status reads 'superseded by ADR-NNN' with the original left unedited.
Hints
1. ```
If someone read only this record two years from now, could they tell what you knew and why you chose this?
```
2. ```
List all consequences, including the negative ones (review workload, dependency on a vendor's model lifecycle, cost exposure), and set at least two concrete revisit triggers.
```
3. ```
Example triggers: 'Revisit if the pinned model receives a deprecation notice; if the reviewed error rate exceeds the agreed threshold two weeks running; if monthly cost exceeds the approved range.'
```

Sources

Documenting Architecture Decisions (Michael Nygard) - Cognitect (Michael Nygard)
Architectural Decision Records (ADR GitHub organization) - ADR GitHub organization
Anthropic - Building effective agents - Anthropic
Anthropic - Reduce hallucinations - Anthropic
Anthropic - Model IDs and versioning - Anthropic
Anthropic - Batch processing - Anthropic