PoC handover template: acceptance criteria, guardrails, and delivery checklist (downloadable)

When a PoC works, teams often confuse "the model produces correct answers" with "the project is ready to ship." These are separate states. Most PoCs end up unused not because the technology failed, but because no one documented the acceptance criteria, guardrails, and ownership in writing.

The PoC handover template converts this overlooked phase into a document you can complete and sign off on. It covers three basic areas: Under what conditions does the system pass acceptance? What is it allowed to do, and what must it refuse? After launch, who owns monitoring and who owns fixes?

Why handover is the weakest link in any PoC

We worked with a manufacturing client. Their RAG knowledge system showed strong accuracy during the PoC phase. The client was satisfied, and we delivered a 30-page technical report. When we returned three months later, the system was barely being used.

The handover had failed. That report covered model metrics but did not specify who rebuilds the index when documents change, whether the system should block responses citing outdated regulations or allow them, or who field engineers report errors to. After the first wrong answer, no one knew who to contact. Trust collapsed. People quietly went back to using paper.

A demonstration matters less than adoption. The handover document must put all the requirements for real usage into written form instead of keeping them in an engineer's head.

Acceptance criteria: measurable thresholds, not adjectives

Accuracy needs to be high is not an acceptance criterion. It is a hope. A real criterion looks like this: On a 200-question golden test set, answer accuracy >= 85%, citation accuracy >= 95%, P95 latency <= 4 seconds per response, hallucination rate (unsourced fabrication) <= 2%.

Both sides must sign off on these numbers before handover, and the test set should come from the customer's business experts, not from your engineering team. Acceptance works in two layers: functional (are the answers correct) and operational (can you see when it fails). Operational acceptance is often skipped, but it determines whether your system survives its first month.

Guardrails: define what the system cannot do

Guardrails matter more than features for launch confidence. An agentic workflow without guardrails becomes riskier as capability increases. At handover, you must clearly specify at least these categories of boundaries.

Guardrail Type	What to Configure	Failure Mode
Input	Sensitive data masking, authorization checks	Data breach, compliance violation
Output	No-answer-without-source, escalation rules	Hallucinations passed as official guidance
Action	Agent-executable vs. human-review action lists	Automated wrong commands
Cost	Daily token cap, anomaly alerts	Bill shock, abuse

Each guardrail needs a response protocol for when it triggers and an assigned owner. A guardrail without an owner is not a guardrail.

Delivery checklist: what gets handed over on day one

Handover is not a meeting with verbal explanations. It is delivering an auditable checklist. Here is what must be complete before any FDE project launches.

Deliverable	What It Contains	How It's Accepted
Acceptance Report	Golden test set results vs. thresholds	Both parties sign
Guardrail Config	All four types + triggers + owners	Walk through each one
Monitoring Dashboard	Accuracy, latency, cost, report volume	On-site login confirmation
Bug Report & Fix Process	Who reports, who triages, SLA	Run a test ticket
Data Update Workflow	Rebuild steps after source changes	Do one update live
Rollback Plan	How to downgrade or revert if needed	Practice the switch
RACI Matrix	Who owns what post-launch	Sign-off from all parties

The principle behind this checklist is that every item gets tested on-site, not just documented. Having it in a document and having it actually work in the field are different outcomes. This distinction separates successful PoCs from failed ones.

Handover done, adoption begins

A good handover template will not make launch day easier. It surfaces the problems you would encounter over the next three months before they occur. Real adoption starts after handover. It begins at the first wrong answer, the first data update, the first user report.

We place engineers on-site for FDE work at Tenten. Much of the job involves working through this checklist item by item, then transferring the system to the people who will use it. The template is downloadable and copyable, but the principle stays the same: a system only counts when it is live and in use.