AnthropicClaude Certified Architect – Professional2026-106.2 Communicate architectural decisions and trade-offs
Brief each audience for its decision
Completed by the knowledge check
Learning objective
Tailor technical depth to executive, security, legal, and engineering audiences in terms of cost, risk, time to value, and quality.
Core idea
Tailoring changes the question you answer first and the detail needed to assess it. It preserves the facts, scope, and uncertainties. If executives approve “automated processing” while engineers build a draft assistant requiring review, the communication has created incompatible commitments.
For an architect, the artifact is a set of audience briefings derived from one decision brief. NIST AI RMF MAP 2.2 calls for documenting knowledge limits and human oversight with enough information for relevant actors to make decisions. GOVERN 4.2 addresses communication of risks and impacts. Apply those practices by giving each audience the information necessary to exercise its authority, including a specific request for a decision.
How it works
Preserve one factual basis
Prepare a shared fact sheet with the deployment scope, proposed autonomy, observed quality, expected cost, delivery assumptions, failure handling, and unresolved issues. Give the briefings the same version identifier. Every view should distinguish an observation, a forecast, a requirement, and an unanswered question. A forecast does not become a commitment because it appears on an executive slide.
Anthropic’s evaluation guidance treats task fidelity, consistency, privacy preservation, latency, and price as separate success criteria. Keep those dimensions separate in the fact sheet. “Quality passed” should identify which rubric and population passed; it must not imply that privacy, security, or operating cost also passed.
Start from each audience’s authority
The following briefing structure is an architectural practice built around the NIST communication and role-definition outcomes, rather than a prescribed framework template:
| Audience | Lead with the decision needed | Supply the detail that supports it |
|---|---|---|
| Executives | Fund which scope, for what expected value, by when? | Total operating forecast, delivery dependencies, quality floor, downside, and assumptions |
| Security | Are the proposed data and action paths acceptable? | Trust boundaries, credentials, execution authority, tested controls, and remaining attack paths |
| Legal | Can this intended use proceed under the organization’s obligations and agreements? | Data categories, purpose, recipients, retention arrangements, user-facing claims, and unresolved terms |
| Engineering | What exactly must the team implement and operate? | Interfaces, identifiers, constraints, acceptance criteria, failure behavior, ownership, and dependencies |
Each view still addresses cost, risk, time to value, and quality. Security may need the engineering effort and latency cost of an approval step; legal may need to know that unresolved contract review blocks the delivery date. Executives need the cost and quality consequence of retaining human review. Engineers need to know which desired capability is excluded because the organization has not authorized it.
Avoid assuming the legal and security reviewers are interchangeable. Technical isolation can reduce exposure without establishing permission to process the data. Legal review of an agreement does not prove the implemented tool permissions match the agreement. Route each unresolved question to the accountable function rather than summarizing both as “compliance approved.”
Translate a mechanism without losing its boundary
For a user-defined client tool, Anthropic documents a tool_use block that the application executes, followed by a tool_result. That gives the security briefing a precise place to ask who can authorize the action and which service credential executes it. Explain this boundary in business terms to executives: the model proposes an action, and the application controls whether this client operation proceeds.
Keep that statement scoped to client tools. Anthropic also documents server tools that execute on Anthropic’s infrastructure. A data-flow briefing must distinguish the two; a blanket statement that all tools execute inside your application would misdescribe the architecture. Keep the briefing focused on who executes and authorizes each operation; the integration sequence is supporting detail.
For engineers, preserve the actual identifier and the required behavior at that boundary. For legal, describe the data leaving the organization and the relevant processing arrangements. A technical statement about where code runs does not settle retention, contractual permission, or the acceptability of the use case. Verify those matters against the selected deployment and agreements before presenting them as settled.
Make unresolved dependencies visible
Close each view with the decision requested, its owner, and the missing information that prevents approval. Use a responsibility matrix to separate implementation ownership, review responsibility, and risk acceptance. This implements the role-definition emphasis of GOVERN 2.1 and GOVERN 3.2; it need not assign every decision to the architect.
A favorable executive funding decision does not resolve a legal dependency. State which work can proceed under the approved scope and which must wait. That makes time to value a conditional plan that teams can act on, rather than a date that quietly assumes every reviewer has agreed.
Key distinctions and trade-offs
Abstraction versus omission: Removing API syntax from an executive brief can improve comprehension. Removing the human-review requirement changes the represented product. Preserve every qualification that affects cost, authority, or expected benefit.
Approval versus awareness: A reviewer receiving a document has not accepted a risk. Record what decision was made and its scope. NIST GOVERN 2.3 assigns executive responsibility for AI risk decisions; your organization’s delegated authorities determine the specific approver.
Value date versus build date: Completion of code is one dependency. Review, integration, staffing, and acceptance can determine when value begins. Present those dependencies alongside the implementation estimate so sponsors understand what funding can accelerate.
Tailored views cost preparation time and can diverge. A shared versioned fact sheet reduces that risk while allowing short briefings. Do not solve divergence by sending everyone the full engineering specification and expecting each function to find its concerns.
Architecture / decision scenario
A healthcare provider wants a Claude assistant to draft administrative appointment letters. Its hypothetical pilot measures 92% of drafts as usable after review, with 8% requiring substantial edits. Its planning forecast is $0.80 per usable reviewed draft, including reviewer labor; this is an illustrative estimate, not a vendor price. The sponsor wants value within six weeks; the clinical operations manager can allocate two reviewers. Legal has not completed review of the intended data processing arrangement.
The tempting proposal is one executive presentation promising six-week automation, with the technical specification sent to everyone else. Reject it: the product still requires review, and the unresolved processing question affects the date and allowable pilot data.
Give executives a funding request for a reviewed-draft pilot, its staffing cost, the 92% observation, and the delivery dependency. Give security the client-tool execution boundary, data movements, and service privileges. Give legal the proposed data categories, processing purpose, recipients, and actual contractual questions; make no vendor eligibility claim without supporting vendor documentation. Give engineering the draft-only scope, client tool_use handling requirements, review interface, and acceptance rubric.
Recommend beginning an approved synthetic-data integration while the legal owner resolves the real-data question. The sponsor decides funding, legal owns the unresolved processing determination, security owns its technical review, and engineering owns implementation. All four briefings state that live-data value depends on those reviews and reviewer capacity. They differ in depth while preserving the same scope, cost assumptions, quality limitation, and timeline dependency.
Common exam traps
- Replacing a qualified quality result with “production ready” in the executive view.
- Combining security and legal approval into an undefined sign-off.
- Treating client-tool execution control as a claim about every tool or data processor.
- Giving engineers an optimistic roadmap without the approval dependencies.
- Changing the automation claim between stakeholder groups.
What to remember
Begin each briefing with the audience’s decision and supply the depth needed to assess it. Keep cost, risk, time to value, and quality consistent across views. Preserve technical boundaries where they change authority, and record unresolved dependencies with the function that can resolve them.
Knowledge check
An executive slide for a claims-letter assistant promises “automated processing,” while engineering is building a draft assistant whose every letter a reviewer approves. Which change best keeps the briefings consistent?
The security team has accepted the isolated data path for a pilot that processes patient correspondence. Legal has not yet determined whether the intended processing is permitted under the organization’s agreements. The sponsor asks for one status line that identifies the completed review and the unresolved decision. Which should the architect use?
A support assistant uses a user-defined update_ticket tool and Anthropic’s web_search server tool. A security briefing draft says: “Every tool operation executes inside our application under our service credential.” How should the architect correct it?
update_ticket runs in our application and web_search on Anthropic’s serverstool_use block that the application executes and answers with a tool_result , so the service credential and the authorization check sit there. Server tools such as web_search run on Anthropic’s infrastructure without handler code in the application. A data-flow briefing that does not separate the two misdescribes who executes each operation.