Domain 6 – Stakeholder Communication & Lifecycle Management (14%)

• Structured discovery and requirements gathering
• Communicating architectural decisions and trade-offs to non-technical stakeholders
• Managing feedback loops and SLA expectations
• Architecture documentation and implementation guidance
• Full lifecycle support: discovery → design → handoff → monitoring → iteration

CCAR-P Domain 6 · Task 6.1

What You Need to Know

The request is not the requirement. Discovery finds the problem behind the request.

Six Outputs Discovery Must Produce

1. Business problem with measured baseline — hours, error rates, backlog, revenue at risk
2. Real workflow (including workarounds)
3. Output the system must produce (fixes task shape)
4. Consequence when that output is wrong + thresholded, owned success criteria
5. Data — what exists, quality, ownership, lawful basis
6. Constraints and accountable decision-maker

Consequence of Error Sets the Bar

Wrong suggestion reviewed by a human vs wrong figure flowing into a payment sets different accuracy thresholds, human-checkpoint needs, and cost/latency envelopes.

Success Criteria

Specific, measurable, achievable, relevant. Targets from benchmarks/prior experiments/expert knowledge. Most use cases need several at once. Directional criteria (“improve the customer experience”) cannot end a project.

Feasibility Triage

1. Decidable task with verifiable output?
2. Data exists, good enough, lawfully usable?
3. Cost of being wrong tolerable at achievable accuracy?

A “no” is a finding, not a failure. The honest no is a professional output.

Exam Traps (Four Failure Postures)

• Capitulation — agrees to the impossible (early price, demo before characterisation)
• Evasion — complies silently or builds it your own way without saying so
• Obstruction — escalates over the accountable owner
• Theatre — more meetings, more metrics, more documents

Practice Scenario

Procurement director: “We want an assistant that reads our supplier contracts. My team loses days to it every month.” Budget holder will fund only a proposal built on measured figures and an agreed pass mark; nothing built before that proposal is funded. What should the architect do first?

Build Exercise: Write the Discovery Record for One Engagement (45 min)

CCAR-P Domain 6 · Task 6.2

What You Need to Know

Complete Communication Has Seven Parts

1. The decision
2. Options genuinely considered (including the one the audience expected)
3. Criteria they were judged on
4. Evidence (Domain 4 measurements, not assertions)
5. What each option costs and exposes
6. A recommendation (declining to recommend is abdication)
7. What would change the recommendation (the revisit condition)

Translation Changes the Lead, Never the Facts

• Executives → business consequence and risk
• Engineers → mechanism and constraint
• Legal/compliance → obligation and residual risk
• Sponsor → cost, date, and what they are being asked to accept

Simplifying past the point of truth is not translation.

Say the Error Rate Out Loud

State the rate, the population, and the handling path for residual errors. A demo is a sample from the favourable tail — never a substitute for the measured rate.

Disagreement Pattern

Measure → frame → recommend → leave the decision where accountability sits. Owner’s authority covers cost vs quality and scope vs date. It does not cover a legal/regulatory/safety obligation — there, say so and bring in the owning function.

Exam Traps

• Implementing a decision you hold measured evidence against, without comment
• Building it your way quietly after the argument went the other way
• Taking the disagreement to the owner’s superior before the trade-off has been put to the owner
• Answering “how accurate will it be?” with a single confident number

Practice Scenario

Operations director has decided the route-exception assistant will ship without confidence-banding and human-review, because the review queue needs headcount she does not have. Eval on real exceptions puts most errors inside the band that step would have caught; each undetected error costs more than the saved headcount. She has not seen these results. Policy requires a risk owner to see the evidence before accepting a risk; staffing stays with her. What should the architect do?

Build Exercise: Write One Architectural Decision as It Would Be Communicated (40 min)

CCAR-P Domain 6 · Task 6.3

What You Need to Know

Engineer first, then promise. Never the reverse.

Anatomy of a Defensible Commitment (Six Elements)

1. Metric — what is measured and how
2. Percentile or threshold — means conceal the tail
3. Measurement point — where the clock starts and stops
4. Window — over what period compliance is assessed
5. Population — who and what it covers (defined before measurement)
6. Breach behaviour — what happens when it is missed

You Cannot Promise Above Your Dependencies

Check what the platform underneath commits to. A promise above that envelope is written against somebody else’s best effort.

Negotiating the Impossible Ask

Show the decomposition so the figure stops being arbitrary. Close perceived gaps with streaming, progressive disclosure, partial results, or async + notification — none of which move total completion time. Accepting the number is capitulation; deleting a control to hit it is worse.

Quality Is a Measured Claim

Same six elements. Where shortfall concentrates in a segment, say so and give that segment its own plan and owner. Hidden population narrowing is the most dangerous option.

Feedback Is Instrumentation

A feedback channel must produce evidence and a disposition. Confirmed failures route into the regression set. Anecdotes routed into prompt edits make a system rot.

Exam Traps

• Writing a bare number into a schedule as the service level
• Meeting a latency target by dropping a retrieval or verification stage
• Offering streaming/partial results where the consumer is a pipeline, not a person
• Quietly narrowing the covered population until the headline figure becomes true

Practice Scenario

Insurer sponsor wants a flat maximum response time for a correspondence-drafting assistant: every draft back inside the same short window, no exceptions. Measurement holds that window for routine cases but runs well past it on multi-policy customers (small permanent share). Agents wait at the screen. Any promise must rest on what the pipeline has been shown to do, cover the whole queue, and leave draft quality as it is. What should the architect commit to?

Build Exercise: Write the Service-Level Schedule and the Sponsor Page (45 min)

CCAR-P Domain 6 · Task 6.4

What You Need to Know

A handover pack transfers judgement, not history. Test for every page: does it change what a competent stranger would do?

Six Artefacts

1. Architecture view — components, data flows, trust boundaries, external dependencies
2. Decision records — context, options, criteria, choice, consequences accepted, revisit condition (append-only)
3. Operational runbooks — failure modes, diagnostic path, containment, who to call (written from 2am position)
4. Evaluation baseline — suite, datasets, numbers at handover with intervals, instructions to re-run and compare
5. Interface and integration contracts
6. Risk and compliance register with owners

Two Questions Test a Handover Pack

1. Can a competent engineer who was not there make a change safely?
2. Will they know when they have broken something?

Anything answering neither is for the author, not the reader. Page count answers neither.

Keeping Documentation Current

Keep it beside the code, version it with the code, change it in the review that changes the behaviour. Drifted documentation is worse than none. Location is part of correctness.

Key Concept: The evaluation baseline is the artefact that answers “will I know if I broke it?” Without it, competent teams simply stop changing the system.

Exam Traps

• A large pack of documents offered as evidence that handover is complete
• A complete component/data-flow view with no record of why any of it was chosen
• A recorded walkthrough / prompt archive / list of features not built as the critical artefact
• A thorough pack that lives in a tool the inheriting team does not use

Practice Scenario

Platform team inherited a support-answer assistant nine weeks ago. One product line’s docs replaced; retrieval config needs adjusting. Team has escalated the change back rather than making it — cannot tell what a change would do, no way to check whether answers got worse. They hold a component diagram, interface reference, and restart runbook. What should be supplied?

Build Exercise: Assemble and Test One Handover Pack (45 min)

CCAR-P Domain 6 · Task 6.5

What You Need to Know

Phases are gated by outputs, not dates. The architect’s job does not end at deployment.

Phase Outputs

Phase	Must produce
Discovery	Measured baseline, agreed success criteria, data/compliance assessment, named owner
Design	Architecture + decision records, evaluation plan, oversight/control design, service-level envelope
Build & validate	System + measured performance against agreed criteria (demo ≠ measurement)
Handoff	Transferred ownership (more than transferred code)
Operate & monitor	Trend against criteria; working incident loop
Iterate	Evidence-gated changes that re-enter design

Ownership Transfer = Capability Transfer

Receiving team must be able to:

1. Run evaluations and get a comparable answer
2. Read a trace well enough to localise a failure
3. Roll a change back
4. Know who to reach when none of that is enough

Missing any → operate but refuse to change (paralysis mistaken for stability).

Iteration Is Evidence-Gated

Prompt edits against last week’s complaints without a regression suite = each edit fixes the reported case and silently moves an unreported one.

Certain Events

Model deprecation, corpus migrations, connector/dependency changes, regulatory change, business-process redesign. Plan for them in design. On deprecation notice: test replacement early, audit usage by API key/model, re-benchmark cost and latency.

Quiet is not evidence. A system with no complaints, a baseline nobody has re-run, and a moved corpus is unevidenced, not healthy.

Going Backwards Is Professional

When production evidence contradicts a discovery assumption, return to discovery. Carrying on because the plan says so buys a delivery date and loses the outcome.

Exam Traps

• Reading a quiet, complaint-free system as healthy and waiting for drift to be reported
• Handing a model deprecation to the commercial/vendor-relationship owner
• Shipping prompt edits against last week’s complaints and calling it iteration
• Continuing to build against a discovery assumption that production evidence has already contradicted

Practice Scenario

Pricing-support assistant has run quietly for five months. Sponsor asks for extension to a second product line. Nobody has re-run the evaluation baseline since handover; reference corpus refreshed twice; model version the baseline was measured on has entered its deprecation window. What should the architect do?

Build Exercise: Write the Lifecycle Plan for One System (40 min)