Stakeholder Communication & Lifecycle Management

This domain carries 14% of the blueprint – the same weight as governance – and unlike most of the pack it has no Foundations counterpart at all. Nothing here was warmed up in CCAR-F, which is precisely why technical candidates skim it and lose points they had assumed were free.

What it tests is not soft skill. It is whether you can turn a vague sponsor request into an architecture with stated constraints, record the decision so a successor can reverse it knowingly, and move a pilot into production on evidence rather than enthusiasm. Items are scenario-shaped: a sponsor demands a deterministic guarantee, scope has crept from summarization to autonomous action, a pilot demos beautifully and has no eval baseline, a business owner wants a number you cannot honestly promise. The strongest option is usually the one that names the constraint, writes it down, and attaches a measurement to it.

The idea that unlocks the domain: discovery exists to find the one binding constraint – regulatory, latency, cost, data access or trust – and every later decision, including the decision not to use an LLM at all, follows from it.

• Discovery ends when you can name the decision or action the output changes, who acts on it, and what it costs when the model is wrong. A feature list is not requirements.

• Find the binding constraint first – regulation, latency, unit cost, data access, or trust. Sequence your questions to eliminate the other four; the survivor decides the architecture.

• Ask "what happens if this is wrong?" before "what should it do?" Blast radius sets autonomy level, the human-review boundary, and the entire downstream design.

• Convert every sponsor adjective into a number. Accurate becomes a target score on a labeled eval set; fast becomes a p95 in milliseconds; cheap becomes cost per resolved task.

• Set the non-determinism expectation at kickoff, not at the first incident. Promise bounded ranges measured by evals, never identical outputs for identical inputs.

• Write an ADR when the choice is expensive to reverse – model tier, retrieval strategy, autonomy boundary, vendor commitment. Cheap reversible choices belong in code, not in a decision record.

• An ADR carries context, options considered, decision, and consequences. The rejected options are the valuable part – they stop a settled question being relitigated.

• Baseline the existing human or rule-based process before you build. No baseline, no proof of value, no budget at renewal.

• Promote a pilot on thresholds agreed before it started: eval score, human-override rate, cost per resolved task, incidents over a fixed window.

• Treat every scope expansion as a new decision – new ADR, new evals, new approval – not a backlog ticket. Adding a tool or an autonomy level changes the risk class.

• Name one accountable owner and a review date per system. Undated ownership is how a pilot becomes unmonitored production.

• Report in the sponsor's currency – hours returned, cases deflected, cost per outcome – and keep token counts in the engineering channel.

• Demo-to-production gap. A flawless happy-path demo with no eval set and no error budget. The tell in a scenario is a sponsor citing demo success as evidence of readiness.

• Solution-first discovery. The stakeholder arrives asking for "a chatbot". The correct move is to reopen the problem, not to scope the chatbot.

• The determinism promise. Never commit to byte-identical outputs. Where exactness is contractual, wrap the model in a deterministic layer – templates, calculators, validators, approved cached responses – or remove it from that path.

• Scope creep by autonomy. "Can it just do it for them?" moves the system from advisory to acting. New risk class, new approval, new rollback path.

• Silent pilot promotion. Pilot traffic quietly becomes production traffic with no exit review. Freeze expansion and apply the gate retroactively.

• ADR as diary. Records what was built but not what was rejected or why. Worthless within two quarters.

• Verbal decisions from a steering meeting. If it is not written down it will be relitigated, and the architect wears the drift.

• Feedback theater. A thumbs-up widget nobody triages, with no route into the eval set. Collect a signal only where it will change the system.

• Model upgrade treated as a non-event. Behavior shifts. Re-run the evals, tell the sponsor what moved, keep a rollback path and a pinned fallback.

• No deprecation plan. Retiring a system raises questions about log and prompt retention, retrieved data, dependent teams, and the human process that atrophied.

• Say "don't use an LLM" when: the rules are deterministic and enumerable; outputs must be exactly reproducible for audit; a cheaper classifier or plain search meets the bar; the required accuracy exceeds anything the evals reach; or the necessary data does not exist or cannot be lawfully accessed.

• Escalation is an architectural act. When a stakeholder demands a guarantee the technology cannot give, the answer is a written constraint and an alternative design – not a softer promise.

PILOTS – the sequence from first stakeholder conversation to a production system somebody owns.

• P – Problem, not product. Discovery ends when you can name the decision the output changes.

• I – Identify the binding constraint. Regulation, latency, cost, data access or trust: one of them decides the architecture.

• L – Limits declared up front. Non-determinism, refusal and error rates, cost envelope, and what the system will never be allowed to do.

• O – Options on the record. An ADR with alternatives considered and consequences – including the option of not using an LLM.

• T – Thresholds to promote. The pilot exits on agreed numbers: eval score, override rate, cost per task, incident count.

• S – Steward and sunset. A named owner, a feedback loop that reaches the eval set, a review date, and a retirement plan.

Use it when a scenario opens with a stakeholder request and asks for the architect's next move – the answer is almost always the earliest unfinished letter.