What you will learn
Representative samples, Acceptance tests, Reviewer agreement, Failure triage, Sign-off evidence.
Engineering the capability
User acceptance testing asks whether the system supports the agreed workflow. It includes answer quality, permissions, usability, fallback behavior, and operational recovery. Technical evaluation feeds into UAT but cannot replace the customer’s task-level judgment.
Build cases with actual user roles and representative complexity. Keep a record of how cases were selected; easy examples can make a pilot look better than everyday work. Define expected outcomes and severity before testing. Review disagreements explicitly so ambiguous requirements do not masquerade as model failures.
Separate blocking defects from improvements and document the owner and next action for each. Preserve failed cases in the report. An acceptance record should state the version tested, scope, known limitations, and decision, rather than simply saying the demo worked.
Worked case
A draft is factually correct but requires an operator to open five screens to verify it. A model-quality score can pass while the workflow fails UAT. Add a task measuring whether the user can review evidence and complete the action within the agreed process, including a fallback when evidence is missing.
Put it into practice
Continue with the next lab: run a structured acceptance session. Build the artifact, record the failure cases, and explain the tradeoff before moving on.