Stakeholder communication and lifecycle management

The premise of this domain: on AI projects, the expensive failures are communication failures wearing technical clothes. The pilot that “failed” had succeeded at its actual task; nobody had agreed what the task was. The model that “broke” had drifted because nobody defined who watches it after launch. The stakeholder who “had unrealistic expectations” had been handed a demo and a percentage that meant nothing. Every objective here is a discipline that prevents one of those.

01Structured discovery

Discovery is not a meeting; it is the extraction of a specification from people who describe outcomes, not requirements. The question set the exam expects you to run. What decision or action changes? — the test of whether this is a project at all. What does wrong cost? — which sets the review lanes and guardrails (Domain 5) before any design exists. Who owns the outcome once it ships? — because an ownerless system is unmonitored by construction. What exists today, and what is its baseline? — you cannot claim improvement without a before number, and “the humans do it in email” is a baseline. And what would make this not worth doing? — the reverse question that surfaces the political requirements nobody would otherwise state.

The output of discovery is not a summary; it is success criteria specific enough to be tested: “first-draft responses to tier-1 tickets, human-approved before sending, graded at 90%-plus factual accuracy on a 300-case sample from live traffic, p95 draft time under 20 seconds, €0.04 or less per draft”. That sentence is a specification, an evaluation plan (Domain 4) and a stakeholder agreement in one. The exam’s discovery scenarios are the failure to produce one — most often a scope defined by a demo the executives liked, which is the pilot trap: scope frozen around what the demo happened to do, rather than what the work needs.

02Communicating decisions and trade-offs

Architecture communication at this tier is translation: the same decision, told three ways, none of them dumbed down. To executives: the value and the risk in business terms — what it costs, what it saves, what could go wrong and what happens then. To engineers: the interfaces, the operational behaviour, the failure modes and the runbook implications. To legal, security and compliance: the data flows, the controls, the provider commitments (Domain 5). The instrument that works across all three is the trade-off table: options as rows, the criteria that matter as columns, the recommendation stated with its price. “We recommend the cached-reranker variant: +2 points accuracy on the golden set, +400ms p95, +€0.011 per task” is honest, comparable, and lets a non-modeller make a real decision.

The written form is the architecture decision record — context, options considered, decision, consequences — short enough to read, versioned, and durable past the people in the room. ADRs convert “why is it built this way” from folklore into a document the next team can read. Two communication habits the exam rewards: state uncertainty as ranges with evidence, never promises (a model upgrade is “evaluated at 91–93% on the sample”, not “will fix it”); and deliver bad news early with options attached — “the 95% target is not reachable on current data; here are the two things that move it and what they cost” is a professional answer, while quiet optimism is how projects die in Q4.

03Expectation alignment and honest SLAs

An SLA for an LLM system is a designed artifact, and its honesty is the test. What a professional one contains: a quality commitment expressed as a band on a defined measurement (“85–90% factual accuracy on the monthly human-graded sample” — bands, because probabilistic systems do not hold point targets); latency commitments at p95 with the conditions attached; a cost-per-task envelope; the review workflow the consumer participates in (what humans still approve, and turnaround); degradation behaviour — what happens when the system is unsure, when retrieval is thin, when a provider has an incident; and the change policy — how model or prompt updates are announced and gated. What it does not contain: “99% accuracy” promised at a sales meeting, and any metric nobody built the measurement for.

Feedback loops are the ongoing half of alignment: a named channel where issues land, a triage that feeds them into the evaluation set (Domain 4), a visible status of what was heard and what changed, and scheduled reviews where the SLA itself is re-negotiated against reality. Expectations are versioned like code: when the system’s scope or quality moves, the agreement moves with it, in writing, to the same people who signed the first one.

04Documentation and implementation guidance

The handover test: could a competent team operate and extend this system without you? The document set that passes it: the architecture description (components, data flows, and the ADRs explaining why this shape and not the obvious alternative); the operational runbook (what is monitored, what alerts mean, what to do — including the degradation behaviours and the rollback path); the evaluation report (golden set, methodology, current scores — the system’s specification of itself); the prompt and configuration registry (versioned prompts, model pins, feature flags — the assets, not screenshots of them); and the implementation guidance the exam guide names explicitly: sequenced, concrete next steps for the receiving team, with the risks called out where they will meet them. Documentation written after the fact from memory is a story; written alongside, it is the system’s biography — and only one of them survives an audit or an incident.

05The lifecycle: discovery → design → handoff → monitoring → iteration

The exam guide names the phases; the professional content is what each phase owes the next. Discovery owes design its testable criteria and its cost-of-wrongness. Design owes handoff an operable system — telemetry, runbooks, evals — not just working code. Handoff owes monitoring an owner, a rotation that knows the runbook, and thresholds worth alerting on. Monitoring owes iteration its evidence: drift caught, cases banked, incidents converted into regression tests. And iteration owes discovery a return trip — the next round of requirements comes from what production taught, not from the original deck warmed over. Two lifecycle facts the exam draws from this: model deprecations are scheduled events, and planning them (version pins, eval gates on upgrades — Domain 2) is lifecycle management, not incident response; and end-of-life is a phase too — data retention, export and deletion obligations from Domain 5 do not vanish because the project ended.

06The traps

• —“The demo set the expectations.” Demos are sales instruments; SLAs are management instruments. Letting one stand in for the other is the original sin of AI projects.
• —“We will document at the end.” There is no end at which documentation is cheaper; the handover test fails quietly until the day it is administered.
• —“Accuracy will improve with the next release.” Roadmap promises in place of measured bands are how 87% becomes a scandal.
• —“Handoff is done when the code is delivered.” Code without runbook, evals and owner is a liability with a git history.
• —“Feedback comes in the retrospective.” Unchannelled feedback is anecdote; the loop into the evaluation set is what makes it count.