A common delivery model treats UAT as the last checkbox before release: implementation ends, users verify it, bugs are fixed, software ships.
That model is too shallow for operational systems.
In a manufacturing platform, UAT is often the first moment when a technically coherent workflow collides with the real sequence of decisions made on the shop floor. The useful question is not only “does it work?”. It is “does the system encode the operation the way people actually run it?”
112 issues were not 112 bugs
Across one MES/APS engagement I resolved 112 client-reported UAT issues, including 17 marked critical. Some were straightforward defects. Others exposed mismatches in assumptions, role boundaries, state transitions, visibility or the order in which information becomes available.
Treating every report as an isolated ticket would have fixed symptoms while preserving the wrong model.
Instead, each finding is more useful when classified into one of four buckets:
- implementation defect;
- missing domain rule;
- workflow mismatch;
- acceptance ambiguity.
The distinction changes the fix. A defect gets a patch. A domain-rule gap may require a model change. A workflow mismatch can invalidate several screens at once. An ambiguous acceptance criterion should become a testable statement before more code is written.
Acceptance should leave evidence
For business-critical flows, “tested” is weak documentation. I prefer an acceptance matrix that ties a scenario to preconditions, actor, steps, expected state and evidence.
That does two things at once: it gives the client a precise surface for disagreement, and it turns the final handover into something reproducible.
The practical rule
Use UAT as a domain-model review performed with working software.
When a report arrives, ask whether it points to a local implementation problem or to a wrong assumption upstream. The second category is where the expensive bugs hide, and where UAT produces the most value.