# D6 · Stakeholder Communication & Lifecycle Management
Structured discovery and requirements gathering, communicating architectural decisions to technical and non-technical audiences, feedback loops and SLA alignment, C4 documentation, lifecycle phases with exit criteria, change management, and model deprecation as a lifecycle event.
import { Accordions, AccordionItem, Tabs, TabItem, Steps } from '@prosefly/astro-components';
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:
1. Run **structured discovery**: interview frameworks, success metrics, constraint capture.
2. Communicate **architectural decisions and trade-offs** to technical and non-technical audiences using ADRs, decision matrices, cost models and risk registers.
3. Design **feedback loops** and align on **expectations/SLAs**.
4. Produce **architecture documentation**: C4 views, data-flow diagrams, runbooks.
5. Manage the **lifecycle** (discovery → design → build → handoff → monitoring → iteration) with deliverables and **exit criteria** per phase.
6. Lead **change management and adoption**.
7. 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 |
:::tip[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 |
:::caution[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 |
```text
C4 L1 (Context) C4 L2 (Container)
┌──────────┐ ┌───────────────┐ ┌───────────────────────────────┐
│ user │──▶│ Support │ │ [web app] ─▶ [orchestrator] ─▶│
└──────────┘ │ Assistant │ │ ─▶ [RAG service] │
┌──────────┐ │ (this system) │ │ ─▶ [Claude/Bedrock]│
│ CRM (ext)│◀─▶│ │ │ ─▶ [MCP tools] │
└──────────┘ └───────────────┘ └───────────────────────────────┘
```
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 |
```text
Discovery ─▶ Design ─▶ Build ─▶ Handoff ─▶ Monitoring ─▶ Iteration ─┐
▲ │
└───────────────── feedback loop (D1/D4) ───────────────────────┘
```
:::tip[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.
1. **Inventory**: which services pin which model IDs, prompts and eval baselines (from the model inventory in D5).
2. **Assess**: read the deprecation notice; identify breaking changes (e.g. `budget_tokens` removed, forced-tool-use behaviour, thinking-block rules — D2).
3. **Re-validate**: run the **regression suite** on the target model per segment; adjust prompts as needed (prompts are validated per model, D2/D4).
4. **Canary migrate**: roll the new model out via canary with rollback; ramp when healthy.
5. **Communicate**: tell stakeholders the timeline, expected differences, and any SLA impact.
:::caution[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.
```text
DISCOVERY GUIDE — Claude solution
1. Problem & value
- What decision/task are we automating? What breaks today?
- Which value pillar dominates: efficiency, cost, or an SLA?
2. Success criteria (make it numeric, per segment)
- "Good enough" as numbers: accuracy, p95 latency, deflection, cost/task
- Which segments must not regress? (tiers, languages, doc types)
3. Volume & shape
- Requests/sec avg & peak; sync vs async; payload sizes
4. Data & compliance
- Sensitivity class; residency; retention; sources; freshness
- Regulations: GDPR / HIPAA / FedRAMP / EU AI Act?
5. Constraints
- Budget ceiling; deadline; existing cloud/IAM; team skills
6. Risk & reversibility
- Blast radius of a wrong answer; which actions are irreversible?
7. Integration & identity
- Systems to read/write; identity model; MCP vs API
8. Sign-off
- Stakeholders agree criteria & constraints → DESIGN gate passed
```
| 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** |
```text
Workflow = 0.25·5 + 0.25·5 + 0.20·5 + 0.15·3 + 0.15·4 = 1.25+1.25+1.00+0.45+0.60 = 4.60
```
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**.
:::tip[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:
```text
RUNBOOK —
1. Overview: purpose, owners, on-call rotation, C4 context link
2. Dependencies: models (IDs/versions), MCP servers, vector store, downstream APIs
3. Dashboards: p95 latency, cost/task, error rate, per-segment accuracy, cache hit
4. Alerts & thresholds: 429/5xx spike, cost anomaly, faithfulness drop, injection detector
5. Common incidents → actions:
- 529/overload → confirm backoff + fallback; check provider status
- stale answers → inspect retrieval; trigger re-index (freshness pipeline)
- injection detected → disable tool via hook; roll back prompt/model version
- cost spike → check loop/iteration backstop; verify cache prefix stable
6. Rollback: how to flip prompt/model version; prior version is kept hot
7. Escalation: who to page; compliance contact (GDPR breach → 72 h)
8. Change log: prompt/model versions, dates, eval scores
```
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.**
1. **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.
2. **Close the discovery gate retroactively.** Run a success-metric workshop; agree **numeric, per-segment** criteria (p95, deflection, cost/ticket) and get sign-off.
3. **Produce the runbook.** Dashboards, alerts, rollback, dependencies, on-call — the handoff exit criterion — plus C4 and data-flow docs.
4. **Replace big-bang with canary.** Reject 100%-next-week; **canary → ramp** with rollback and online metrics.
5. **Address adoption.** Enablement/training on capabilities *and limits*, phased rollout, feedback capture, value reporting against the agreed metrics.
6. **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
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.
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.
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.
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.
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.
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.
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).
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.