Acceptance criteria and sign-off

"Working" is a claim, and customers sign claims only when they are written down and measurable. Before you build, agree a short acceptance-criteria document with the customer: what is in and out of scope; behavioural criteria written as Given/When/Then scenarios for things that must always or never happen (escalate above a limit, never act without approval); quality criteria as thresholds on named, versioned eval sets, with baselines and minimum sample sizes; and non-functional criteria for latency, cost, availability, security and privacy. State quality thresholds as confidence bounds, so "96% on 320 cases" is not mistaken for "at least 95%". Plan UAT with the customer's real users and a defect scheme agreed in advance. At each phase gate (pilot, limited release, general availability), bring a sign-off pack: results per criterion with evidence links, known limitations, a residual risk register with named owners, and the release identifiers of what was tested. When the customer changes their mind, run it through change control: a new criterion needs new eval cases, a new baseline and possibly a new date. When someone says "it feels wrong", ask for examples and turn them into cases. Name who signs (business owner, risk, security, privacy, operations) before you need their signatures.

• Write it down first. Criteria agreed after results are seen are negotiated, not measured.
• Every criterion has a measurement method, a data set, a threshold and an owner.
• Thresholds are lower bounds, not point estimates. Small eval sets cannot prove high thresholds.
• Sign-off is per release and per gate. It covers a specific prompt, model and configuration, not "the assistant".
• Change is normal; unrecorded change is the problem.