6.4 — Documentation and Implementation Guidance

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