CCAR-P - Stakeholder Communication & Lifecycle Management (14% of the exam) - Section 6.4

Document architectures and provide implementation guidance.

Producing documentation that lets another team build, operate and change the system: architecture diagrams, decision rationale, prompt and model versions, and operational runbooks.

architecture documentationdecision rationaleprompt and model versioningrunbooks

Practice question for this objective

Free sampleStakeholder Communication & Lifecycle Managementeasy

A payroll software company runs a service that summarises support tickets into a fixed JSON layout for its reporting pipeline. On Monday the downstream parser began rejecting 14 percent of summaries because a field arrived under a different name. The service loads its prompt only from files in the repository, and those files have the same content hash as last month. The parser's dependency lockfile is unchanged, and replaying last month's tickets, which all parsed cleanly at the time, now reproduces the failures. The architecture document records the model only as "the current Sonnet model". What is the most likely cause?

AThe configuration names a model alias that now resolves to a newer model, and nobody recorded the change Correct
BAn unrecorded edit to the summary prompt, made outside the repository and missed by the content hash
CA change in the mix of incoming tickets, with more long multi-issue threads that the summariser mishandles
DA parser library upgrade that tightened field-name matching and now rejects summaries it once accepted

Recording and pinning the exact model version alongside prompt versions lets a team attribute a behaviour change when inputs, prompts and code are unchanged. A replay of known-good inputs isolates the cause: if the same tickets, the same prompt and the same parser now fail, the component that moved is the model. A configuration that points at a moving alias, documented only as a family, changes the model without any commit or release. Pinning a specific model version and recording it in the architecture document and change log makes such upgrades deliberate, tested and traceable.

Why A is correct: Correct. Identical inputs, an identical prompt and an unchanged parser now give different output, which leaves the model as the variable, and documentation that names only a model family rather than a pinned version lets that switch happen without a record.

Why B is wrong: Tempting because unversioned prompt edits are a common source of silent regressions. It is wrong because the service loads its prompt only from the repository files, and their content hash is unchanged.

Why C is wrong: Tempting because input drift often explains a rise in failures. It is wrong because replaying last month's tickets, which parsed cleanly at the time, now fails too, so the inputs are held constant and still break.

Why D is wrong: Tempting because dependency upgrades do change validation behaviour. It is wrong because the parser's lockfile is unchanged, and the rejections are caused by a field arriving under a different name, which is a change in the output itself.

See more CCAR-P practice questions, answers explained.

Exam traps in Stakeholder Communication & Lifecycle Management

Answers that look right on this material and are not. Each one is a distractor from a different question in the CCAR-P bank for this domain.

Keep console editing but export a snapshot of the live prompt each night and store it in a shared folder for audit
Why it is wrong: Tempting because it creates an audit trail without changing how editors work. It is wrong because an edit made and reverted between snapshots is never captured, production still changes without approval, and the moving model alias is left untouched.
Sampling variation between runs, which setting the temperature to zero for the replay would have removed
Why it is wrong: This is tempting because run-to-run variation is a real property of generated text. It is wrong because sampling cannot make the model cite notes that were not in its context; the replay retrieved different source documents, which points to the retrieval input, not to sampling.
The model is inventing nulls for single applicants, so extraction accuracy has regressed since the guide was written
Why it is wrong: This is tempting because unexpected nulls often signal extraction errors. It is wrong because single applicants have no co-applicant, so null is the correct value for that field and matches the schema.

Examworthy is not affiliated with or endorsed by Anthropic. Original, blueprint-aligned practice material only.