D6 · Stakeholder Communication & Lifecycle Management

This domain is worth 14% – roughly 9 of 63 items. It is where Foundations-level candidates lose marks, because it tests the non-code half of an architect’s job: eliciting real requirements, communicating trade-offs to different audiences, documenting the system, and shepherding it through its full lifecycle — including treating model deprecations and migrations as planned lifecycle events. Correct answers favour structured, audience-appropriate, evidence-backed communication and phase gates with exit criteria over ad-hoc heroics.

Learning objectives

By the end of this page you should be able to:

Run structured discovery: interview frameworks, success metrics, constraint capture.
Communicate architectural decisions and trade-offs to technical and non-technical audiences using ADRs, decision matrices, cost models and risk registers.
Design feedback loops and align on expectations/SLAs.
Produce architecture documentation: C4 views, data-flow diagrams, runbooks.
Manage the lifecycle (discovery → design → build → handoff → monitoring → iteration) with deliverables and exit criteria per phase.
Lead change management and adoption.
Manage model deprecations and migrations as a lifecycle event; set a post-launch review cadence.

6.1 Structured discovery and requirements gathering

Discovery (introduced in D1) is also a communication discipline: extracting requirements from people who describe symptoms, not specs, and converting them into measurable, agreed criteria.

Framework	Use	Output
Stakeholder map	Identify who decides, who is affected, who operates it	RACI
Structured interview	Elicit goals, pains, constraints, success definition	Requirements list
Jobs-to-be-done	Frame the task the system must accomplish	Problem statement
Constraint capture	Budget, deadline, residency, IAM, skills, volume	Constraint register
Success-metric workshop	Turn “better” into numbers, per segment	Measurable acceptance criteria

Exam signal

When a stem shows a vague ask and disagreeing stakeholders, the correct answer is usually to run structured discovery and agree measurable success criteria before designing or building — not to start coding or pick a model.

6.2 Communicating decisions to different audiences

The same decision must be framed differently for different readers. This is a core competency the exam tests.

Audience	What they need	Vehicle
Executives / sponsors	Decision, options, cost, risk, business value; one page	Decision matrix + cost model + one-page brief
Technical peers	The trade-offs, rejected alternatives, consequences	ADR
Risk / compliance	Threats, controls, residual risk	Risk register
Operators	How to run, monitor, recover	Runbook
End users / adopters	What changes, why, how to use it	Enablement material

Communication artefact	What it captures
ADR	One decision: context, options, choice, consequences (D1)
Decision matrix	Options scored against weighted criteria
Cost model	Unit economics under realistic volume (routing, caching, batch)
Risk register	Risks with likelihood, impact, owner, mitigation

Wrong altitude

Handing executives a deep technical ADR, or handing engineers a value-only slide, are both failures. Match the artefact to the audience. Distractors that give every audience the same document are wrong.

6.3 Feedback loops and SLA alignment

Set expectations explicitly and measurably, then keep a loop open.

Agree SLAs as numbers (p95 latency, availability, accuracy per segment, cost per task) — the same criteria that drive evals (D4).
Distinguish SLA (external commitment), SLO (internal target), SLI (the measured indicator).
Establish a feedback channel (user thumbs, QA sampling, online metrics) that feeds the improvement loop, and report against the agreed numbers on a cadence.
Manage expectations about AI limitations up front (it is a fallible collaborator; there are human gates) to avoid over-promising.

6.4 Architecture documentation (C4 and runbooks)

Documentation is a deliverable, not an afterthought. The C4 model gives a shared language at four zoom levels.

C4 level	Shows	Audience
1 · Context	System in its environment, users, external systems	Everyone
2 · Container	Apps, data stores, model/RAG services, MCP servers	Technical
3 · Component	Internal components of a container	Engineers
4 · Code	Class/function detail (rarely needed)	Engineers

A runbook documents how to operate and recover: dashboards, alerts, on-call steps, rollback procedure, incident contacts, dependency map. A data-flow diagram shows how data (including PII/PHI) moves — essential for the DPIA (D5).

6.5 Lifecycle phases with exit criteria

An architect owns the system across its whole life, not just design. Each phase has deliverables and an exit criterion (a gate you must pass to proceed).

Phase	Key deliverables	Exit criterion
Discovery	Problem statement, constraints, measurable success criteria	Stakeholders sign off on criteria
Design	Reference architecture, ADRs, decision matrix, cost model, risk register	Design review passed; DPIA/BAA where needed
Build	Implementation, evals, guardrails, observability	Offline regression suite green per segment
Handoff	Runbook, C4 docs, training, ownership transfer	Operators can run and recover it
Monitoring	Dashboards, online metrics, alerts	SLAs met in production; canary healthy
Iteration	Backlog from feedback loop; prompt/model/retrieval improvements	Improvements pass regression + canary

Exam signal

“They want to jump straight to building” or “deploy without a runbook / without agreed criteria” → the correct answer inserts the missing phase gate (agreed criteria before design; runbook before handoff; canary before full rollout).

6.6 Change management and adoption

A technically excellent system that no one adopts has failed. Adoption is an architectural concern.

Lever	Purpose
Stakeholder communication plan	Keep sponsors and users informed
Training and enablement	Users know what the system does and its limits
Phased rollout	Reduce risk and build trust (mirrors canary)
Feedback capture	Surface issues early; show responsiveness
Success metrics reporting	Demonstrate value against the agreed criteria

6.7 Model deprecation and migration as a lifecycle event

Models are versioned and deprecated/retired (e.g. Opus 4.1 retired 2026-08-05). Migration is a planned lifecycle event, not a fire drill.

Inventory: which services pin which model IDs, prompts and eval baselines (from the model inventory in D5).
Assess: read the deprecation notice; identify breaking changes (e.g. budget_tokens removed, forced-tool-use behaviour, thinking-block rules — D2).
Re-validate: run the regression suite on the target model per segment; adjust prompts as needed (prompts are validated per model, D2/D4).
Canary migrate: roll the new model out via canary with rollback; ramp when healthy.
Communicate: tell stakeholders the timeline, expected differences, and any SLA impact.

Deprecation is not “swap the ID and hope”

Silently repinning to a new model without re-running evals can regress a segment or hit a breaking change. Treat it as a governed migration with re-validation and canary. And never let an availability-driven fallback silently downgrade a Fable 5.1 thinking session (D1/D2).

6.8 Post-launch review cadence

Set a recurring review (e.g. weekly early, then monthly) that examines: SLA adherence per segment, cost trend, incident/red-team findings, drift, and the iteration backlog. This is the operational form of the feedback loop and the place where deprecation timelines and re-architecture decisions surface.

6.9 A discovery interview guide (reusable artefact)

Discovery is repeatable. This guide converts a vague ask into a signed-off spec.

Interview anti-pattern	Better move
Accept “make support better” and start	Push to numeric, per-segment criteria
Ask only the loudest stakeholder	Map decider / affected / operator (RACI)
Capture goals but not constraints	Capture budget, deadline, residency, IAM up front

6.10 A weighted decision matrix (worked example)

For the sponsor, a decision matrix scores options against weighted criteria and produces a defensible choice.

Decision: pattern for a claims-triage assistant. Criteria weighted to the business (cost and reliability dominate here).

Criterion (weight)	Workflow	Agentic	Multi-agent
Meets p95 SLA (0.25)	5	3	2
Unit cost (0.25)	5	3	2
Reliability/debuggability (0.20)	5	3	2
Flexibility for future scope (0.15)	3	5	5
Build/ops effort (0.15)	4	3	2
Weighted total	4.60	3.30	2.45

The workflow wins decisively because the weighted criteria favour SLA, cost and reliability — exactly the ADR’s rationale, expressed for a non-technical audience. Change the weights (e.g. flexibility becomes dominant for an open-ended research tool) and the matrix can favour agentic — which is the point: the choice is traceable to weighted business priorities.

Exam signal

When a stem asks how to justify a design to a sponsor, the answer is a decision matrix / cost model / one-page brief, while engineers get the ADR. Giving both audiences the same artefact is the wrong-altitude trap.

6.11 A runbook template (handoff artefact)

The handoff gate’s exit criterion is “operators can run and recover it”. That requires a runbook:

A data-flow diagram accompanies it (PII/PHI paths for the DPIA, D5). Without dashboards, alerts and a rollback path, the handoff gate fails.

6.12 Scenario walkthrough: rescuing a stalled, mis-communicated rollout

Scenario. An engineering team built a strong support assistant but it’s stuck: the VP sponsor was shown a 40-page technical ADR and is unconvinced; ops refuses the handoff because there’s no runbook; the team wants to deploy to 100% next week; and no numeric success criteria were ever agreed. Adoption in the pilot team is low.

Expert reasoning trace.

Fix the communication altitude. The VP needs a one-page decision matrix + cost model + business value, not the ADR. Engineers keep the ADR. Same decision, different artefacts.
Close the discovery gate retroactively. Run a success-metric workshop; agree numeric, per-segment criteria (p95, deflection, cost/ticket) and get sign-off.
Produce the runbook. Dashboards, alerts, rollback, dependencies, on-call — the handoff exit criterion — plus C4 and data-flow docs.
Replace big-bang with canary. Reject 100%-next-week; canary → ramp with rollback and online metrics.
Address adoption. Enablement/training on capabilities and limits, phased rollout, feedback capture, value reporting against the agreed metrics.
Set a post-launch review cadence to watch SLAs per segment, cost, incidents and the deprecation calendar.

Why the tempting alternatives are wrong: “send the VP the ADR again” repeats the wrong-altitude error; “deploy to 100% to force adoption” is high blast radius and breeds resistance; “skip the runbook to hit the date” fails the handoff gate; “one aggregate metric” hides per-segment failure and can’t be reported credibly.

6.13 Common misconceptions

Misconception	Reality	Why it matters on the exam
“Everyone should get the full technical document.”	Match the artefact to the audience’s altitude.	Same-doc-for-all is the wrong-altitude trap.
“We can define success later.”	Measurable, per-segment criteria must be agreed at discovery.	Building before criteria is unanchored.
“‘Faster’ is a goal.”	SLAs must be numbers (p95, deflection, cost/task).	Vague promises can’t be verified/reported.
“A model swap is just changing the ID.”	Deprecation is a governed migration: assess, re-validate, canary, communicate.	Blind swaps hit breaking changes/regressions.
“Adoption follows automatically from good tech.”	Adoption needs enablement, phased rollout, value reporting.	Low-adoption stems test change management.
“SLA, SLO, SLI are synonyms.”	SLI (metric) → SLO (internal) → SLA (external commitment).	Definition items test this precisely.
“Compliance can wait until launch.”	DPIA/BAA belong at the design gate.	Compliance-late is a wrong answer.

Exam traps in this domain

Trap	Why it is wrong
Jumping to build before agreeing measurable success criteria	Skips the discovery exit gate; unanchored
Giving every audience the same document	Wrong altitude; executives need value/cost, engineers need ADRs
Setting “better” as a goal instead of numbers	Not measurable; can’t be verified or reported
Deploying without a runbook	Operators can’t run or recover the system
Full rollout with no canary or phased adoption	High blast radius; no trust-building
Treating a model deprecation as a same-ID swap	Breaking changes / segment regressions go undetected
Over-promising AI capability to sponsors	Misaligned expectations; erodes trust
No feedback loop / no post-launch review	System stagnates; drift and regressions go unnoticed
Confusing SLA, SLO, SLI	Commitments and internal targets get conflated
Skipping DPIA/BAA at the design gate	Compliance discovered too late (ties to D5)
Justifying a design to a sponsor with a raw ADR or eval logs	Sponsors need a decision matrix / cost model / one-page brief
Handing off with no runbook, dashboards, or rollback	Fails the handoff exit criterion; operators can’t recover it
Deploying to 100% to “force” adoption	High blast radius; adoption needs enablement + phased rollout
Scoring options without weighting criteria to business priorities	A decision matrix must reflect weighted priorities to be defensible
Omitting the data-flow diagram from documentation	The DPIA and PII/PHI review depend on it

Practice questions

Q1 · Two stakeholders disagree on what the assistant should do, and no success metric exists. The team wants to start building. What should the architect do FIRST? (Select one)

A. Start building the most likely interpretation. B. Run structured discovery to align stakeholders on measurable, per-segment success criteria and constraints, and get sign-off before design. C. Pick Opus 5 and begin. D. Escalate to the vendor.

Answer: B. With disagreement and no metric, the discovery gate is not passed; structured discovery and agreed criteria must precede design/build. Building on a guess (A), picking a model (C), or escalating to the vendor (D) all skip the anchoring step.

Q2 · The architect must present a workflow-vs-agentic decision to the executive sponsor AND to the engineering team. What is the BEST approach? (Select one)

A. Send both audiences the full technical ADR. B. Give the sponsor a one-page decision matrix with cost model, risk and business value; give engineers the ADR with rejected alternatives and consequences. C. Give both a value-only slide. D. Give both the raw eval logs.

Answer: B. Communication must match audience altitude: value/cost/risk for the sponsor, trade-offs and consequences for engineers. One document for both (A, C) or raw logs (D) mismatches at least one audience.

Q3 · A sponsor asks for 'faster support'. How should this become an SLA? (Select one)

A. Promise it will be ‘much faster’. B. Agree numeric targets — e.g. p95 latency under 6 s, ≥ 60% deflection, cost under $0.05/ticket — per segment, and report against them on a cadence. C. Track mean latency only. D. Leave it undefined and adjust later.

Answer: B. SLAs must be measurable and per-segment, mirroring the eval criteria, with regular reporting. Vague promises (A) can’t be verified; mean-only (C) hides the tail; undefined (D) invites disputes.

Q4 · Which C4 level is MOST appropriate to show executives and non-technical stakeholders how the system fits its environment? (Select one)

A. Level 4 (Code). B. Level 1 (Context) — the system, its users, and external systems. C. Level 3 (Component). D. Raw sequence diagrams of every API call.

Answer: B. The Context level shows the system in its environment for a broad audience. Code (A) and Component (C) are for engineers; exhaustive sequence diagrams (D) overwhelm non-technical readers.

Q5 · Opus 4.1 was retired and a service pinned to it. What is the correct migration approach? (Select two)

A. Read the deprecation notice, identify breaking changes, and re-run the regression suite per segment on the target model, adjusting prompts as needed. B. Canary the new model with rollback, then ramp, and communicate timeline/differences to stakeholders. C. Swap the model ID in production and hope for the best. D. Keep calling the retired model. E. Disable evals during the migration to move faster.

Answer: A and B. Deprecation is a governed lifecycle event: assess breaking changes, re-validate per segment, canary with rollback, and communicate. A blind ID swap (C) risks regressions/breaking changes; calling a retired model (D) fails; disabling evals (E) removes the safety net.

Q6 · The team wants to hand the system to operations. What deliverable is REQUIRED to pass the handoff gate? (Select one)

A. A marketing deck. B. A runbook covering dashboards, alerts, on-call steps, rollback, and dependencies, plus C4 docs, so operators can run and recover it. C. Nothing; operators will figure it out. D. Only the source code.

Answer: B. Handoff’s exit criterion is that operators can run and recover the system, which requires a runbook and architecture docs. A deck (A), nothing (C), or code alone (D) don’t enable safe operation.

Q7 · What is the correct distinction among SLA, SLO and SLI? (Select one)

A. They are synonyms. B. SLI is the measured indicator, SLO is the internal target, SLA is the external commitment (often with consequences). C. SLA is internal; SLO is external. D. SLI is a legal contract.

Answer: B. SLI (indicator) → SLO (internal objective) → SLA (external commitment). They are not synonyms (A), the internal/external roles are not swapped (C), and the SLI is a metric, not a contract (D).

Q8 · A technically strong system sees low adoption after launch. Which levers BEST address this? (Select two)

A. Training/enablement and clear communication of what the system does and its limits. B. A phased rollout with feedback capture and success-metric reporting to build trust. C. Forcing all teams to use it immediately with no support. D. Removing the human-in-the-loop gates to make it faster. E. Hiding the limitations from users.

Answer: A and B. Adoption is driven by enablement, phased rollout, feedback and demonstrated value. Forcing use without support (C) breeds resistance; removing safety gates (D) is unsafe; hiding limitations (E) erodes trust when they surface.

Q9 · When should a DPIA/BAA be addressed in the lifecycle? (Select one)

A. After launch if a regulator asks. B. At the design gate, so residency, retention and PHI/PII handling shape the architecture before build. C. Never, if the system is internal. D. Only during incident response.

Answer: B. Compliance obligations must shape the design, so DPIA/BAA belong to the design exit criterion. After launch (A) or during an incident (D) is too late; ‘internal’ (C) does not exempt regulated data.

Q10 · What is the purpose of a post-launch review cadence? (Select one)

A. To close the project permanently. B. To review SLA adherence per segment, cost trend, incidents/red-team findings, drift, and the iteration backlog — operationalising the feedback loop and surfacing deprecation/re-architecture needs. C. To replace monitoring dashboards. D. To avoid documentation.

Answer: B. The cadence is the operational feedback loop where the system’s health and future needs are reviewed. It does not end the project (A), replace dashboards (C), or excuse documentation (D).

Q11 · Which artefact best communicates residual risk to a compliance stakeholder? (Select one)

A. An ADR. B. A risk register listing risks with likelihood, impact, owner and mitigation. C. A cost model. D. A C4 code diagram.

Answer: B. A risk register is the vehicle for communicating risks and residual risk to compliance. An ADR (A) is a technical decision record; a cost model (C) is economics; a code diagram (D) is for engineers.

Q12 · A stem says the team plans to deploy straight to 100% of users with no runbook and no agreed metrics. What does the correct answer insert? (Select two)

A. Agreed, measurable success criteria (discovery/design gate) before proceeding. B. A runbook and a canary/phased rollout with rollback before full deployment. C. Immediate full deployment to gather data faster. D. Skipping monitoring to reduce overhead. E. Letting each engineer define their own metrics.

Answer: A and B. The missing phase gates are agreed criteria and a runbook plus canary with rollback. Full immediate deployment (C) is high blast radius; skipping monitoring (D) blinds operations; per-engineer metrics (E) destroy a shared definition of success.

Q13 · A VP sponsor was shown a 40-page technical ADR and remains unconvinced. What is the BEST corrective communication? (Select one)

A. Resend the ADR with a summary email. B. Present a one-page decision matrix with weighted criteria, a cost model, and business value/risk framed for an executive. C. Send the raw evaluation logs. D. Give the VP the runbook.

Answer: B. Sponsors need a decision matrix/cost model/one-page brief at their altitude, not an engineering ADR. Resending the ADR (A) repeats the error; raw eval logs (C) and the operator runbook (D) are the wrong artefacts for a sponsor.

Q14 · Using the weighted decision matrix (SLA 0.25, cost 0.25, reliability 0.20, flexibility 0.15, effort 0.15), Workflow scores 5,5,5,3,4 and Agentic scores 3,3,3,5,3. Which wins and why? (Select one)

A. Agentic, because it is more flexible. B. Workflow (weighted 4.60 vs 3.30), because the business weighted SLA, cost and reliability highest. C. They tie. D. The matrix cannot decide.

Answer: B. Workflow = 0.25·5+0.25·5+0.20·5+0.15·3+0.15·4 = 4.60; Agentic = 0.25·3+0.25·3+0.20·3+0.15·5+0.15·3 = 3.30. The weights favour SLA/cost/reliability, so workflow wins. Flexibility (A) is only 0.15; it isn’t a tie (C); the matrix decides transparently (D).

Q15 · Ops refuses a handoff. Which deliverable set satisfies the handoff exit criterion? (Select one)

A. A slide deck and a promise of support. B. A runbook (dashboards, alerts, on-call, rollback, dependencies) plus C4 and data-flow docs, so operators can run and recover the system. C. The source code repository only. D. A cost model.

Answer: B. Handoff’s exit criterion is operability and recoverability, which the runbook plus architecture/data-flow docs provide. A deck (A), code alone (C), or a cost model (D) don’t let operators run and recover it.

Q16 · A team wants to deploy to 100% next week with no agreed metrics and no runbook. Which TWO gates must be inserted FIRST? (Select two)

A. Agree measurable, per-segment success criteria (discovery/design gate). B. Produce a runbook and use a canary/phased rollout with rollback before full deployment. C. Deploy immediately to gather production data faster. D. Skip monitoring to reduce overhead. E. Let each engineer define personal metrics.

Answer: A and B. The missing gates are agreed criteria and a runbook plus canary with rollback. Immediate full deployment (C) is high blast radius; skipping monitoring (D) blinds ops; per-engineer metrics (E) destroy a shared success definition.

Q17 · During discovery, a stakeholder says 'make onboarding faster with AI' and offers no numbers. What is the FIRST step per the discovery guide? (Select one)

A. Choose Opus 5 and start building. B. Run the success-metric step to turn ‘faster’ into numeric, per-segment criteria and capture constraints, then get sign-off. C. Assume a 50% improvement target. D. Escalate to the vendor.

Answer: B. The discovery guide converts vague asks into numeric, per-segment criteria with constraints and sign-off before design. Building (A), assuming a target (C), or escalating (D) skip the anchoring step.

Q18 · A strong system has low pilot adoption. Which TWO change-management levers best address it? (Select two)

A. Enablement/training that covers capabilities and limits, and how to review AI output. B. A phased rollout with feedback capture and value reporting against agreed metrics. C. Mandating org-wide use immediately with no support. D. Removing human-in-the-loop gates to feel faster. E. Hiding known limitations from users.

Answer: A and B. Adoption is driven by enablement and phased rollout with feedback and demonstrated value. Forced use (C), removing safety gates (D), and hiding limits (E) backfire.

Key takeaways

Start with structured discovery; convert vague asks into measurable, per-segment, signed-off success criteria.
Communicate at the right altitude: decision matrix/cost model for sponsors, ADRs for engineers, risk registers for compliance, runbooks for operators.
Agree SLAs as numbers; distinguish SLI → SLO → SLA; keep a feedback loop and report on cadence.
Document with C4 views, data-flow diagrams and runbooks — deliverables, not afterthoughts.
Manage the lifecycle with exit criteria per phase; don’t skip the gate (criteria before design, runbook before handoff, canary before full rollout).
Treat model deprecation/migration as a governed lifecycle event: assess breaking changes, re-validate per segment, canary, communicate.
Drive adoption with enablement, phased rollout and value reporting; run a post-launch review cadence.
Use a reusable discovery interview guide to force numeric, per-segment criteria and constraint capture before the design gate.
Justify designs to sponsors with a weighted decision matrix (score × weight) that traces the choice to business priorities; engineers get the ADR.
The handoff gate requires a runbook (dashboards, alerts, rollback, dependencies) plus C4 and data-flow docs — not a deck or code alone.