Main idea

A deterministic feature is tested by comparison with an expected result: the output conforms or it does not. An answer produced by a model offers no such grip. Two correct phrasings do not carry the same value for the user, a wrong answer can be perfectly plausible, and the experience of failure — what the product does when it does not know — becomes part of the product just as much as success does.

Evaluating that kind of output therefore bears on questions no conformity test suite covers: robustness in the face of awkward cases, coherence with the product intent, the trust a user can reasonably place in it, and the margin of error they are prepared to accept in their own work.

That is why reducing this evaluation to classic quality assurance empties it of its substance: the question is not only "is the output correct?" but "is this output acceptable, here, for this use?" — a product question, not a verification one.

Why it matters

It says whose job the evaluation is: it cannot be wholly delegated to a control function at the end of the chain, since it requires settling questions of intent and of what the user tolerates.

And it makes testable what many teams give up measuring: trust and acceptability are worked on with business cases, failure scenarios and written criteria, not with a general impression of quality.

Nuances and limits

Acceptability does not excuse conformity: on verifiable rules — a calculation, an access right, a format — the requirement stays binary and the probabilistic argument must not serve as an excuse.

And the acceptability threshold does not belong to the team that produces: it is established with the people who use the thing, and it varies with the line of work, the stakes and the reversibility of what the output triggers.

Open questions

• How do you set an acceptability threshold in writing, when what is at stake is a user's trust rather than an observable error rate?