What You Need to Know
A handover pack is the set of documents that a team leaves for whoever runs the system next. The pack transfers judgement, not history. It records what the team decided, on what evidence, and which consequences the team accepted. It also says how to tell whether something has broken. The next person does not need to know what the team tried in week three. The test for every page is this: does the page change what a competent stranger would do?
This lesson uses one made-up example throughout: a hospital group whose Claude assistant answers staff questions about the group's policies. The engineers who built the assistant are leaving, and the group's own engineering team will run it. Most handover packs contain the project narrative. The narrative helps nobody who is changing a retrieval configuration on an ordinary Tuesday. A retrieval configuration is the settings that control which documents the assistant finds for a question.
The Six Artefacts
Six artefacts support a production Claude system:
- The architecture view: components, data flows, trust boundaries (the points where data passes between parts that are trusted differently), 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 cause someone to revisit the choice. Keep the records append-only: the team adds entries and removes none. Mark superseded entries instead of deleting them. A deleted entry makes a settled question look open. Then the next architect argues the question again without the evidence.
- Operational runbooks: the likely failure modes with a diagnostic path, the containment options and who to call. Write the runbooks from the on-call engineer's position at two in the morning.
- The evaluation baseline. The next section covers it, because it is more important than the other artefacts.
- Interface and integration contracts: what each boundary promises and requires.
- The risk and compliance register with owners: the output of Domain 5, moved into daily operations, because the obligations continue after the project ends.
For the hospital group, one record says why the assistant answers only from approved policy documents. With the records kept, the group's engineers need not reopen that choice.
The Evaluation Baseline
One artefact answers the question "will I know if I broke it?". That artefact is not a diagram. The baseline is the evaluation suite, the datasets that the suite runs on, the numbers at handover, and instructions. The instructions let somebody else re-run the suite and get a comparable answer.
Anthropic's evaluation guidance sets the design standard. Match the real task distribution. Include edge cases such as irrelevant, overly long, poor or ambiguous input. Automate grading wherever the structure allows it. Prefer many items with automated grading to a few hand-graded items. Anthropic's evaluation research sets the standard for comparability: report the interval with each score. Then you can read a re-run months later as better, worse or indistinguishable, not simply different.
Without a baseline, a team that inherits the system cannot tell whether a change made things worse. So the team cannot change the system safely. Competent teams respond by not changing the system at all. The live system stays the same. People at the hospital group praise the assistant as stable, although it is only unchanged.
Two Questions Test a Handover Pack
First, can a competent engineer who was not there make a change safely? This question needs the architecture view, the decision records with their revisit conditions, the interface contracts and the implementation guidance. Second, will that engineer know when they have broken something? This question needs the runbooks for the operational half and the baseline for the quality half.
Every artefact should answer one of the two questions. Anything that answers neither question is there for the author, not the reader. Page count answers neither question. A recorded walkthrough answers the first question only while the system still resembles the recording.
More of the Same Artefact Is Not the Fix
When a handover has failed, the right answer adds the missing artefact type. Richer diagrams, a longer limitations list and a second walkthrough improve a capability that the team already has. The capability that the team lacks stays missing. Ask which of the two questions currently has no answer.
Keeping Documentation Current and Findable
Drifted documentation, which no longer matches the system, is worse than none. The reason is that the person who is least able to detect the error is exactly the person who believes it. The fixes change how the documentation is kept, not how motivated people are. Keep the documentation 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 that the inheriting team never opens is a document that only its author reads.
Implementation guidance is the part of the same work that covers future changes. In addition to the target architecture, it gives the sequence of steps. It says which steps are risky, and so which order is not negotiable. It names the gates (the checks) that must pass before the next step, and a definition of done for each. For the hospital group, which is adding the policies of a new hospital, the guidance says which step comes first. Guidance that names the components and then stops delivers only the part that nobody was unsure about.
In the exam
The exam tests which artefact is missing, not how many exist. Domain 4 designs the suite and produces the numbers. This objective is to package the suite in a form that can be transferred.
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
This is activity for show. A pack has to answer two questions, how to change the system safely and how to detect breakage, and extra pages answer neither.
A complete component and data-flow view with no record of why any of it was chosen
Trade-offs get re-argued by people without the evidence, and settled decisions are reversed by accident. Supply decision records: the options weighed, the consequences accepted and the condition for revisiting each choice.
A recorded walkthrough, a prompt-draft archive or a list of features considered but not built, offered as the critical artefact
A recording helps with safe change only while the system matches it, and none of the three tells anyone whether a change made things worse. Supply the evaluation baseline: the suite, its datasets, the numbers at handover and the instructions to re-run it and compare.
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. Keep it beside the code, version it with the code, and change it in the review that changes the behaviour.
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 is still useful after everyone who was there has left
- 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 makes the useful ones harder to find.
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-argued 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 testable 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 with nothing already set up, 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 do not match what the engineer sees 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 a tool that nobody opens is in practice a private document.
You should see: A shorter pack with a stated home, and a rule that behaviour changes and doc changes ship in the same review.