Outcomes acceptance testing

Software testing asks whether the workflow sent the email. Outcomes acceptance testing asks whether the customer received the information, understood the requested next action, and either completed it or entered an observable exception path.

Not: was an appointment created. Instead: did the person obtain the appropriate appointment and receive everything necessary to attend it.

The first question can pass while the business fails. That is why passing test suites and unhappy customers coexist so comfortably.

An outcomes test names the outcome, the evidence that would demonstrate it, the window in which it should occur, and the exception path that counts as an acceptable alternative. If the evidence cannot be described, the outcome has not been defined well enough to build against.

Outcomes tests are continuous rather than pre-release, because business operations do not have releases. They run against live work, sample it, and report the rate at which the intended result actually occurred.

AI is well suited to reading unstructured evidence, applying a rubric consistently, and flagging drift long before a monthly report would show it.

It is badly suited to being the only judge of work it also performed. The evaluating path should be separable from the executing path, and the rubric should be inspectable by a person who was not involved in building either.