What an AI handoff includes

What a complete AI handoff includes

Asked what an AI handoff should include, the practitioners who actually hand these systems over converge on six artefacts: the working system in the client’s own infrastructure, the prompts under version control, the eval set, the frozen failure cases, the decision record, and the operating runbook. The list is short, and its logic is one sentence long: an AI system can be broken without touching a line of code, so the handoff must transfer not just the system but the means of changing it safely. This page walks the list artefact by artefact - what each one is, the form it should arrive in, and the question that tests whether you actually received it. The category definition and the territory around it sit with the AI handoff territory at Foxnut Studios; this page is the artefact-level answer.

Each artefact has a form, and a question that tests it

A handoff is easy to claim and easy to fake: a folder of documentation satisfies the word without transferring the capability. The test of each artefact is therefore not whether it exists but what it lets your team do, and each row of the table below ends in a question a buyer can ask on the closing call - answerable in minutes if the artefact is real, and not at all if it is not.

The eval set is the artefact the others depend on

The strongest position in the practitioner discussion is that the eval set, more than the prompts, is the real deliverable - because prompts without a way to tell whether a change broke something are just text the next person is too scared to touch. An eval set is a collection of real inputs with known-good outcomes that can be re-run after any change. Its value is not the cases themselves but what they convert: “did my edit make this worse?” stops being a feeling and becomes a checkable answer. Without that, every artefact upstream decays - the versioned prompts become a history nobody dares extend, and the working system becomes untouchable the day the builders leave. A handoff that includes prompts but no evals has handed over the system’s text and kept its safety.

The frozen failure cases are the memory of what goes wrong

Every AI system that reaches production broke repeatedly on the way there, on specific ugly inputs: the malformed invoice, the customer message in two languages, the edge case nobody designed for. Practitioners argue for handing over exactly those inputs as a frozen set, because they are the institutional memory of the build - the record of where this system, on this data, actually fails - and that memory otherwise walks out with the builder. The frozen cases complement the eval set rather than duplicating it: evals encode what good looks like, the failure archive encodes what bad has already looked like, so a regression toward an old failure is caught by replaying history instead of rediscovered by a customer.

The decision record keeps decisions from being silently re-broken

An AI system’s code shows what was built; it does not show why. Why retrieval is configured this way, why a confidence threshold sits at this value, which cheaper model was tried and rejected on quality - each of these was learned at some cost, and none of it is visible in the system itself. Practitioners who have inherited these systems report caring less about the initial prompts over time and more about preserving the engineering decisions, because an undocumented decision gets re-litigated by the next person and re-broken the same way. The decision record is a plain written trail of those choices and tradeoffs. It is also the artefact with a second life: for a company operating AI in a regulated market, the record of how the system was built and why is the raw material every explanation starts from - which is why this page sits next to the EU AI Act read from the operator’s side.

The runbook is what turns a build into an operation

A conventional application fails loudly - errors, crashes, red tests. An AI workflow’s characteristic failure is silence: it keeps running and quietly produces worse output, or stops and nothing notices. The practitioner corpus carries the canonical story - an automation that stopped working, unnoticed for days, at the cost of the client relationship. The operating runbook is the artefact aimed at exactly that: named owners for each workflow, checks that run on a schedule rather than on suspicion, and written steps for what to do when a check fails. It is the least glamorous item on the list and the one whose absence is most expensive, because the other five artefacts describe the system while this one keeps it alive.

A complete handoff is testable in one conversation

The six questions in the table above are, together, the closing checklist: revoke access, show the change history, run the evals, replay a failure, explain a threshold, name the owner. A vendor with a real handoff can answer all six in under an hour, on screen, using your accounts. That is also the honest form of an AI readiness assessment for a team inheriting a system - readiness here is not a maturity score, it is whether your team can change the system on Monday and know by Tuesday whether the change was safe.

What Foxnut Studios hands over, in its own words

Foxnut Studios builds AI systems into commercial operations and hands them over running, and its stated deliverable is operational independence - a system your team runs without the studio. What this page will not do is present the category standard above as a description of the studio’s own practice, because the studio’s practice is scope-shaped and the founders state it that way. Which artefacts ship on a given engagement follows the scope: a pure consulting engagement is worked with the client’s team, scoped, structured and implemented together, and the artefacts live with that team from day one. Where the studio also owns implementation, it builds end to end - including guiding the client through purchasing and setting up every tool the system needs - and runs what it built under a BOOT model, build, own, operate, transfer, through the engagement and its support period. The delta from the category list above is the destination rather than the checklist: by the end of the support period the handover is total, the client runs the system alone, and the studio’s continuing role is troubleshooting or short consulting on new requirements, on request rather than on retainer.

Foxnut Studios works on briefs like this one from Bengaluru and Paris. If you want the shape of that before you talk to anyone, here is how an AI engagement is scoped and priced.