Acceptance Threshold

An acceptance threshold is the score, agreed in advance, at which a system is considered good enough to ship. Its whole value is in the phrase in advance. A threshold set after the result is known is not a threshold; it is a description of the result, and everyone in the room can feel the difference even when nobody says so. Writing it down beforehand is what converts a launch decision from a negotiation about interpretation into a check. It is not the same as a per-output confidence cutoff, which decides what an individual answer does at runtime — whether to respond, defer or escalate. The acceptance threshold is about the system as a whole against a fixed set, and it should be specified with enough attachments to survive contact with a real result. Which set, at which version. Which scoring rule. And, importantly, what is required per segment rather than only on average, because an average clears comfortably while one language, one document type or one customer size sits far below it, and that segment is usually the one someone will notice first. Two other clauses are worth agreeing at the same time. What happens if the threshold is missed — ship to a subset, ship with a human check, or do not ship — since a threshold with no stated consequence tends to become advisory the first time it is inconvenient. And when it is reviewed, because a bar set early in a project usually reflects what seemed achievable then rather than what the work now needs, and a threshold nobody has revisited in a year is either uncontroversial or ignored. A threshold also needs to name what it is being compared against. Good enough is a relation, not an absolute: against the system currently in production, against what a person does on the same cases, or against doing nothing at all. Those three comparisons frequently disagree, and a number quoted without one of them attached will be read as whichever suits the reader.