The numbers we check before an AI feature ships

“Is the AI good enough to ship?” is not a yes or no. It is a handful of numbers, each with a target agreed before launch, and a decision about what to do when one of them misses. A reading taken after launch is a post-mortem; a target set before it is a gate.

Here is the set we check, and what each one is actually for.

Answer accuracy

The headline number: of a fixed set of real questions, what fraction does the system answer correctly? This only means something against an eval set you trust: real questions, with what a right answer looks like, held steady so the number is comparable across changes.

A target (“90% correct on 240 questions from your contracts”) turns every later change into a measurable event. Swap the model, adjust a prompt, change how documents are chunked, and the number moves so you can see which direction.

Grounding and citation match

Accuracy alone can be bluffed by a model that happens to know the answer without reading your documents. Grounding asks a stricter question: is the answer actually supported by a retrieved source, and does the citation point to the right one?

This is the measurement that separates a system answering from your data from one answering near it. In a contracts or support setting, an answer a user cannot trace back to its source is not an answer they can rely on.

Refusal when unsure

A system that always answers will confidently answer the questions your documents do not cover. Refusal is the counter-measure: when the retrieved passages do not support an answer, the right move is to say so.

It is measured in both directions: refusing when it should, and not refusing when the answer is right there. A model that refuses too often is as useless as one that never does; the target has to pin both ends.

Cost per answer

At demo scale nobody counts tokens. At production scale, cost per answer is a line item that scales with every user. A target (“under $0.02 per answer”) makes the trade-offs explicit: a reranking pass or a larger context might lift accuracy, but if it doubles the cost, that is a decision to make on purpose, not discover on the invoice.

Latency

A correct answer that takes eight seconds is a feature people stop using. We measure latency at the 95th percentile, not the average, because the average hides the slow tail that users actually feel. The budget (“under 2.5 seconds at p95”) is as much a part of the spec as accuracy.

Why targets come first

The point of fixing these before launch is that they turn “good enough” from an opinion into a gate. Some will pass and some will be open, a latency over budget or a refusal rate a few points low, and that is the useful outcome. An open number is not a failure; it is a known piece of work with a name, visible before launch instead of discovered after it.

That is the whole idea behind a go/no-go report: not a green light that hides the problems, but an honest ledger of what passed, what is open, and what has to be fixed before real users arrive.