Communicating architectural decisions and trade-offs

What you’ll be able to do

• Present architectural options with explicit trade-offs, evidence and a recommendation
• Tailor the same decision for executives, security and legal reviewers, and engineers
• Communicate probabilistic behavior and error rates honestly, in terms stakeholders can act on
• Record decisions in a durable form with their assumptions and revisit triggers

What you need to know

A decision is options, consequences and evidence

Stakeholders can only make or support a decision they understand, and they can only understand it if they see what was given up. A credible decision presentation has the same shape whatever the topic:

• The question, framed in the stakeholder's terms: "How do we keep answers current when policies change weekly?"
• Two or three real options, including the simplest viable one. Straw-man alternatives are recognized as such and cost you trust.
• Consequences of each on the dimensions people care about: quality on their task, latency, running cost, build effort, risk, and what's hard to reverse later.
• Evidence: evaluation results on their own data, a cost estimate from measured token usage, a latency measurement from a probe. "Option B scored better on 200 of your real tickets" beats any benchmark table.
• A recommendation and its conditions: what you'd choose, why, and what would make you change your mind.

Separate decisions that are cheap to reverse (switching prompt templates, changing model tier behind an interface) from those that aren't (where data is stored, which vendor or deployment platform, building a workflow the business reorganizes around). Spend stakeholder time on the irreversible ones.

Same decision, different audiences

Each audience decides something different, so each needs a different view:

• Executives decide on investment and risk appetite. Lead with outcome, cost range, timeline and the main risk with its mitigation. One page; detail available on request.
• Security and privacy decide whether the data handling is acceptable. Give them a data-flow diagram with trust boundaries: what data goes where, which components see it, what's logged and retained, who has access, which tools can act on what.
• Legal and compliance decide on regulatory fit. Map the design to their specific concerns: personal data minimization, retention, residency, required agreements, human oversight for consequential decisions, how a decision can be explained after the fact.
• Engineering teams decide how to build it. They need interfaces, contracts, patterns, non-negotiable guardrails and the reasons behind each.

The decision itself doesn't change between audiences. Tailoring is about emphasis and vocabulary, never about telling one group something that contradicts what another heard.

Explaining probabilistic behavior

Claude systems are probabilistic, and stakeholders used to deterministic software need that made concrete without alarming or reassuring them falsely. Practical habits:

• Express quality as frequencies on their workload: "on last quarter's claims, roughly 9 in 100 drafts needed a substantive edit; all go to an adjuster before sending." Frequencies are easier to reason about than percentages and scores.
• Pair every error rate with the control that handles it: human review, validation, escalation, or a rollback path.
• Never promise the absence of errors or hallucinations. Promise the measured rate, the controls, and how you'll detect drift.
• Be clear what isn't known yet: "we haven't tested on handwritten forms; that's next sprint's eval."

Record it: architecture decision records

Decisions made in meetings are forgotten or rewritten within months, and in AI systems the assumptions behind them move fast (new model versions, price changes, new regulatory guidance). Record significant decisions in a short architecture decision record (ADR) kept with the system's code or docs: context, options considered, decision, consequences, the evidence used, and revisit triggers ("revisit if the mid tier passes the adjudication eval" or "revisit if volume exceeds the batch window"). ADRs let new team members understand why the system is shaped this way, and let you reopen a decision on purpose rather than by accident.

When stakeholders disagree

Conflicts are normal: product wants fewer human reviews to save time, compliance wants more. The architect's job is not to win but to make the trade-off visible and decidable: lay out the options with their measured consequences, name who owns the decision under the organization's governance, and propose a way to collect the evidence that would settle it (a pilot on a subset, a shadow run). Escalating "they won't agree" without that framing just moves the argument up a level.

Key concept

Present real options with measured consequences on the stakeholder’s own task, tailor emphasis to what each audience decides, state error rates alongside the controls that handle them, and record the decision with its assumptions and revisit triggers.

Questions about communication reward the answer that makes a trade-off explicit and evidenced. Distractors either overpromise ("eliminates errors"), hide the downside, or bury a non-technical audience in detail they can't act on.

Practice scenario

Build exercise — Write a decision record and three audience briefs

Advanced · 45 min

What you’ll learn

• Structuring a decision as options, consequences and evidence
• Adapting one decision to different audiences without changing it
• Stating error rates with their controls and revisit triggers

1. Pick a real architectural choice (for example retrieval against long-context stuffing, or one model tier against a cascade) and write an ADR: context, at least two real options, consequences, evidence, decision and revisit triggers.

   • Why: A written record with assumptions is what lets the decision be revisited deliberately.
   • You should see: At least one consequence of your preferred option that you’d have left out of a slide.

2. Produce three one-page briefs from the ADR: one for an executive, one for security and privacy, one for the engineering team.

   • Why: Each audience decides something different and needs a different view of the same decision.
   • You should see: Three documents with different emphasis and no contradictions between them.

3. Rewrite every quality claim in the briefs as a frequency on real workload data, paired with the control that handles the errors.

   • Why: Frequencies plus controls are actionable; scores and adjectives aren’t.
   • You should see: No sentence promising zero errors, and every error rate followed by how it’s caught.

Exam traps

Presenting a single recommended design with no alternatives or downsides

Without visible trade-offs, stakeholders can’t evaluate the decision and will trust it less. Show real options and their costs.

Describing model quality with benchmark scores instead of results on the stakeholder’s task

Stakeholders need to know how it performs on their work. Use evaluation results on their data.

Promising that the system will not hallucinate or make mistakes

That promise will be broken. State the measured error rate and the controls that catch errors.

Giving every audience the same technical deck

Executives, security, legal and engineers decide different things. Tailor emphasis, keep the substance consistent.

Leaving decisions recorded only in meeting notes and chat threads

Assumptions change quickly in AI systems. Keep ADRs with evidence and revisit triggers next to the system.

Escalating a disagreement without framing the options and who owns the decision

Make the trade-off decidable: options, measured consequences, the decision owner and a way to gather missing evidence.

Sources

• Anthropic
• Claude Developer Platform Docs
• Anthropic, Claude Certified Architect – Professional Exam Guide v1.0 (July 2026)