The FDE handover pack: what to leave behind
I have watched good AI systems get switched off for a reason that had nothing to do with the model. The team that built them left, and nobody else knew what to do when an answer looked wrong.
That is why the last thing a forward deployed engineer builds decides whether the first thing ever mattered. I now ask for the handover pack before I ask for a demo.
This article sets out what goes in it, and why I plan it in week one rather than in the last week.
Hand-written diagram of the FDE handover pack: runbook, eval set, named owner, escalation path and a two week overlap
Why handover fails
Most handovers fail in the same three ways.
The documentation is written for architects, not for the person on call. It explains the design and says nothing about the morning a finance analyst raises a ticket saying the numbers are wrong.
The evals stay with the build team. The new owner inherits a system they can not test, so every change becomes a risk and nobody makes changes.
Ownership is a team alias. When something breaks, the platform team says it is an application issue and the application team says they never owned the prompt.
None of these are technical problems. All of them are engineering problems, because they decide whether the system survives contact with real operations.
The four parts of the pack
1. A runbook for the person on call
The runbook answers one question: the output looks wrong, slow or missing, what do I check first?
I write it as a short decision list. Check whether the source documents changed. Check whether a tool returned errors in the logs. Check whether the input is a new type the system has not seen. Then the steps for each case, including how to switch the feature off safely and what users see when it is off.
It also lists where the logs are, what a normal day looks like in numbers the team can see on a dashboard, and which changes need approval.
2. The eval set, and how to extend it
The eval set is the contract between the system and the business. It holds real cases with what a good answer must contain.
Handing over the file is not enough. The new owner needs a short guide: how to add a case from a ticket, how to run the evals, and what score means "do not ship". If the owner can not add a case in ten minutes, the eval set will stop growing and the system will drift away from reality.
3. One named owner
A person, with a name, who can approve a prompt change, a model change or switching the system off. They do not have to be an engineer. They have to be accountable and reachable.
If nobody will sign as owner, I take that as information. It usually means the business does not want the system enough yet, and it is better to learn that in week one than in week twelve.
4. An escalation path
Who to call, in what order, and what information to bring. The owner first, then the platform contact, then the vendor or model provider support if relevant. It sounds bureaucratic. It saves days.
Plan it in week one
The pack is not a document written in the final week. It grows during the build:
- Week one: owner named, success metric agreed, first twenty eval cases collected.
- During the build: every incident in testing becomes a runbook entry and an eval case.
- Before go live: the owner runs the evals themselves once, without help.
- After go live: about two weeks of overlap where the new owner handles tickets and the build team only advises.
This also changes how the engagement is scoped. When the exit is defined at the start, the work has a natural end, which I wrote about in pricing an FDE engagement.
A test you can run
Ask the person who will own the system three questions:
- What do you do if the answers look wrong tomorrow morning?
- How do you add a new test case?
- Who do you call if you can not fix it?
If they can answer all three without looking at the build team, the handover is done. If not, it is not, however good the demo was.
What this means for engineers
Handover is a skill, and most engineers are never asked to practise it. It means writing for a reader who is not you, building tests someone else can extend, and being comfortable making yourself unnecessary.
It is also one of the clearest signals of seniority I know. Junior engineers show what they built. Senior engineers show who runs it now.
We practise the handover as a graded part of the work in the AIXL Academy Forward-Deployed AI Engineering cohort. Details are on the AIXL Academy page.
Common questions
What is an FDE handover pack?
The set of documents a forward deployed engineer leaves so the customer can run the AI system alone: a runbook, the eval set with instructions to extend it, a named owner and an escalation path.
When should the handover be planned?
In week one. The owner is named in the same document as the success metric, and the runbook grows during the build.
Who should own an AI system after launch?
One named person in the business or the platform team who can approve changes, not a team alias or the vendor.
How long should the overlap be?
Long enough for the new owner to handle real tickets with the build team only advising. I use about two weeks.