Domain 6 — Stakeholder Communication and Lifecycle (14%)

14% of the exam, roughly 9 questions. No Foundations equivalent, and the domain technical candidates most often under-prepare because it does not feel like architecture.

6.1 Discovery and requirements

The examinable behaviour is refusing to design before the constraints are known, and asking the questions that surface them: what decision does this output feed; what happens when it is wrong; what must never leave which jurisdiction; what latency does the business process actually tolerate; who will own this in a year; what does success look like numerically.

A stakeholder request arrives as a solution — "we want a chatbot for policy questions" — and the professional response converts it back into a problem before evaluating it. An option that begins building from the stated solution without testing the underlying need is usually wrong.

6.2 Communicating trade-offs

Architecture at this level is largely the business of explaining what you gave up. Useful framings the exam rewards:

• Present options, not a verdict. Two or three viable designs with their cost, latency, accuracy and risk profiles, and a recommendation with reasons — so the decision-maker owns a decision rather than ratifying yours.
• Quantify where you can. "Roughly 40% cheaper per transaction, about 300ms slower, with an estimated two-point accuracy cost on the holdout set" beats "a good balance".
• State limitations plainly and early. Accuracy cannot be guaranteed; the system cannot reach data it is not connected to; certain decisions require a human by regulation. Discovering these at go-live destroys credibility that the design deserved to keep.
• Do not promise determinism you cannot deliver. Convert a request for a guarantee into a measurable target plus a review path for the residual.

6.3 SLAs and service targets

Committing to a service level for a probabilistic system requires care, and the exam tests whether you know what can honestly be committed to:

Two further points: upstream dependencies bound what you can promise — your availability cannot exceed the model provider's, plus your retrieval layer, plus your own infrastructure. And a target with no measurement behind it is not an SLA, it is a hope.

6.4 Documenting an architecture

The documents that matter, and that questions ask you to identify:

• Decision records — what was chosen, what was rejected, and why. The rationale is the part that has value in two years, when someone asks why the system is not agentic.
• The eval suite — the operational definition of correct, versioned with the prompts.
• A runbook — known failure modes, alerts and what to do about them, escalation contacts, how to roll back a prompt or model change.
• Data flow and compliance mapping — what data goes where, under what basis, retained how long.
• A capability and limitation statement for the business, in their language.

6.5 Lifecycle

Systems built on models age in a way conventional software does not: the model changes, the data distribution shifts, the regulation moves and the prompt accumulates undocumented patches. A lifecycle plan therefore includes a scheduled review of model version against the eval suite, periodic refresh of the eval set from real traffic, a re-examination of whether the original constraints still hold, and an explicit decision point to keep, rework or retire.

The professional habit the exam rewards: plan for the handover from the start. If the system cannot be operated by a team that did not build it, it is not finished.

← Previous: Domain 5 — Governance, Safety and Risk  |  Next: Domain 7 — Developer Productivity and Operational Enablement →