What You Need to Know
A handover pack is the documents a team leaves for whoever runs a system next. It transfers judgement, not history: what was decided, on what evidence, which consequences were accepted, and how to tell whether something has broken. The next person does not need what the team tried in week three. The test for every page is whether it changes what a competent stranger would do.
Take a music shop whose Claude assistant answers customer questions about instruments and repairs. Its contractors are leaving, and the shop's small team will run it. Most handover packs carry the project narrative, which helps nobody changing a retrieval configuration on a Tuesday.
The Six Artefacts
Six artefacts carry a production Claude system:
- The architecture view: components, data flows, trust boundaries, and each external dependency with what it is trusted to do.
- Decision records: the context, options, criteria, choice, consequences accepted and the condition that should trigger revisiting it. Keep them append-only, marking superseded entries rather than deleting them. A deleted entry makes a settled question look open, so the next architect re-argues it without the evidence.
- Operational runbooks: the likely failure modes with a diagnostic path, the containment options and who to call, written from the on-call engineer's position at two in the morning.
- The evaluation baseline, treated below, because it carries more weight than the rest.
- Interface and integration contracts: what each boundary promises and requires.
- The risk and compliance register with owners: Domain 5's output, carried into the operating world, because the obligations outlive the project.
With the records kept, the shop's team need not reopen settled choices.
The Evaluation Baseline
One artefact answers "will I know if I broke it?", and it is not a diagram. The baseline is the suite, the datasets it runs on, the numbers at handover, and instructions that let somebody else re-run it for a comparable answer.
Anthropic's evaluation guidance sets the design standard. Mirror the real task distribution. Include edge cases such as irrelevant, overly long, poor or ambiguous input. Automate grading wherever the structure allows. Prefer volume with automated grading over a handful of hand-graded items. Anthropic's evaluation research sets the comparability standard: report the interval alongside each score. A re-run months later then reads as better, worse or indistinguishable, not merely different.
Without a baseline, an inheriting team cannot tell whether a change made things worse, so it cannot change the system safely. Competent teams respond by not changing it at all. The live system, the shop's assistant included, freezes while everyone congratulates it on being stable.
Two Questions Test a Handover Pack
First, can a competent engineer who was not there make a change safely? That needs the architecture view, the decision records with their revisit conditions, the interface contracts and the implementation guidance. Second, will they know when they have broken something? That needs the runbooks for the operational half and the baseline for the quality half.
Every artefact should answer one of them. Anything answering neither is there for the author, not the reader. Page count answers neither. A recorded walkthrough answers the first only while the system still resembles the recording.
More of the Same Artefact Is Not the Fix
When a handover has failed, the keyed option adds the missing artefact type. Richer diagrams, a longer limitations list and a second walkthrough deepen a capability the team already has. The one they lack stays missing. Ask which of the two questions currently has no answer.
Keeping Documentation Current and Findable
Drifted documentation is worse than none, because it is believed by exactly the person least able to detect the error. The fixes are structural, not motivational: keep it beside the code, version it with the code, and change it in the review that changes the behaviour. Location is part of correctness. A thorough wiki in a tool the inheriting team never opens is a private document.
Implementation guidance is the forward-looking half of the same discipline. Beyond the target architecture, it gives the sequence. It says which steps are risky, and so which order is not negotiable. It names the gates that must pass before the next step, and a definition of done for each. For the shop adding lesson bookings, the guidance says what comes first. Guidance that names the components and stops has handed over the part that was never in doubt.
In the exam
The exam tests which artefact is missing, not how many exist. Domain 4 designs the suite and produces the numbers. Packaging it as something transferable is this objective.
Architecture decision records and operational runbooks are long-established industry practice, not Anthropic products, and should be taught that way.
Exam Traps
A large pack of documents offered as evidence that handover is complete
Theatre. A pack has to answer two questions — safe change, and detecting breakage — and neither is answered by adding pages that answer neither.
A complete component and data-flow view with no record of why any of it was chosen
The what without the why. Every trade-off is re-argued from scratch by people who do not hold the evidence, and settled decisions get reversed by accident.
A recorded walkthrough, a prompt-draft archive or a list of features considered but not built, offered as the critical artefact
Each answers a question nobody asked. A recording decays as the system changes and cannot be re-run against the current build, and neither archive tells anyone whether today's change made things worse.
A thorough pack that lives in a tool the inheriting team does not use
Discoverability is part of the artefact, not a nicety. Documentation nobody opens has the same operational value as documentation nobody wrote, and it costs more to maintain.
Practice Scenario
A hardware manufacturer's platform team inherited a support-answer assistant nine weeks ago. One product line's documentation set has been replaced and the retrieval configuration needs adjusting, but the team has escalated the change back to the original architects rather than making it, saying they cannot tell what a change would do. They have no way to check, after a change, whether the answers got worse. They hold a component diagram, an interface reference and a runbook for restarting the service. What should be supplied?
Build Exercise
Assemble and Test One Handover Pack
What you'll learn
- How to judge every handover artefact against the two questions a pack must answer
- How to write a decision record that survives the departure of everyone who was there
- How to package an evaluation baseline so a re-run is comparable rather than merely different
- How to write a runbook entry from the on-call position rather than the design position
- How to make a pack discoverable in the place the inheriting team already works
- List the artefacts you would hand over for a system you know, and mark each against the two questions: does it let a stranger change the system safely, or does it let them tell when they have broken it
Why: An artefact that answers neither question is in the pack for its author, and it dilutes the ones that matter.
You should see: A table of artefacts, each marked with one question, both, or neither.
- Write one decision record for the hardest trade-off in the design, including the consequences accepted and the condition that would justify revisiting it, for a reader who was not there
Why: Records without a revisit condition get re-litigated by people who lack the evidence, and settled questions reopen by accident.
You should see: One record carrying context, options, criteria, choice, consequences and a falsifiable revisit condition.
- Package the evaluation baseline as a transferable artefact: the suite, the datasets, the numbers at handover with their intervals, and instructions to re-run it and get a comparable result
Why: This is the artefact that answers whether a change made things worse, and without it a competent team will simply stop changing the system.
You should see: A directory somebody else can run from a cold start, and a recorded set of numbers to compare against.
- Write one runbook entry from the on-call position: the symptom as it appears at two in the morning, the diagnostic path, the containment options, and who to call
Why: Runbooks written from the designer’s position describe a system nobody is looking at during an incident.
You should see: An entry that starts with an alert or a user symptom rather than a component name.
- Delete anything in the pack that answers neither question, then name where the pack will live and version it with the code it describes
Why: Drifted documentation is worse than none because it is believed, and a pack in an unopened tool is functionally private.
You should see: A shorter pack with a stated home, and a rule that behaviour changes and doc changes ship in the same review.