Enterprise AI Project Wiki · Environments, versions, and release
User acceptance testing environment (UAT environment)
Also calledUAT environment · User acceptance environment · Business acceptance environment
A user acceptance testing environment, or UAT environment, is a controlled non-production environment in which authorized business users, customer representatives, or other acceptance authorities use agreed business scenarios and acceptance criteria to make a formal business assessment of a uniquely identifiable candidate version. It supplies representative configuration, access, data, and dependencies, prevents unauthorized live-business side effects, and preserves traceable records from test input and observed outcome through defect handling and the final decision.
What a UAT environment is meant to confirm
Development and QA teams can show that functions behave as designed, but they cannot substitute for the business judgment that real job roles can complete their work. UAT brings people who understand business rules, exceptions, and daily operations into formal acceptance and lets them assess end-to-end business processes rather than isolated code modules.
The object under acceptance is not a vague system. It is an identified version, under identified environment conditions, producing outcomes for an agreed business scope. A material change to the version, configuration, data, identity model, dependency, or knowledge base can make earlier evidence insufficient for the same decision.
The environment enables an acceptance decision; it does not manufacture one. Before sign-off, the business authority still evaluates criteria, open defects, known differences, and residual risk. A working UAT environment is not evidence that the business has accepted the release.
What makes a UAT environment fit for formal use
It is more than a URL and a set of accounts. These conditions make a result explainable, repeatable, and suitable for sign-off.
Uniquely identifiable acceptance object
Record the application build, configuration, database schema and migration, interface contracts, and included and excluded scope. Expose or make the version queryable so the package cannot be replaced silently during a cycle.
Representative business configuration and flows
Organizations, roles, approvals, rules, time zones, currencies, templates, and state transitions must cover the in-scope business without bypassing important controls for convenience.
Controlled, recoverable data baseline
Prepare normal, boundary, exception, and historical-state samples with known provenance and authorization. Restore each cycle to a known state so earlier actions do not contaminate later conclusions.
Access modeled on real job roles
Give participants roles that represent their intended duties and keep administrative support access separate and controlled. Test both permitted work and information or actions that must remain unavailable.
Explicit dependency and side-effect boundary
Identify whether each integration points to a mock, sandbox, test instance, or restricted live service. Email, messaging, payment, ordering, approval, and business-system writes must not reach unintended real recipients or records.
Observable and evidentiary records
Retain case ID, input, time, executor, actual result, screenshot or output, application logs, integration records, and version context without leaking sensitive content into evidence stores.
Defect workflow and participant support
Define the issue channel, severity, response owner, blocking rules, fix version, retest owner, closure authority, and a support route that business participants can actually use.
Readiness checks before business users enter
- Are scope and acceptance criteria approved?
Map in-scope processes, roles, data changes, integrations, non-functional needs, and exclusions to executable scenarios.
Record: approved plan, criteria, scenarios, and scope baseline.
- Is the cycle version frozen?
Lock code, configuration, database changes, and dependencies. An urgent change creates a new candidate and an explicit retest impact assessment.
Record: version, artifact digest, configuration inventory, and deployment time.
- Are people, accounts, and roles ready?
Participants have the necessary process training, can sign in, hold representative roles, and know the signing authority and delegate.
Record: participant list, role matrix, access check, and decision authority.
- Are business samples usable and authorized?
Samples cover critical flows, exceptions, and access boundaries, with provenance, de-identification, retention, deletion, and transfer conditions handled under organizational policy.
Record: data inventory, authorization, baseline batch, and cleanup date.
- Are live side effects blocked?
Confirm endpoints, recipient allowlists, limits, and reversal methods for payments, messages, orders, tickets, approvals, and external writes.
Record: endpoint inventory, interception controls, and controlled test result.
- Are production differences understood?
Register differences in capacity, data, domain, identity, network, dependency, and observability, stating which conclusion each difference prevents.
Record: difference, risk, compensating test, owner, and accepting authority.
- Do evidence and defect workflows work?
Rehearse one case through execution, evidence capture, issue creation, correction, retest, and closure before the formal window.
Record: rehearsal case, issue, workflow state, and approval log.
How one UAT cycle produces a decision
Establish the cycle baseline
Record the window, environment, candidate, data batch, participants, criteria, and known limitations, and pass readiness before opening access.
Run scenarios through business roles
Business users perform end-to-end work as their intended roles, evaluating outcome, steps, permissions, handoffs, exceptions, and necessary human judgment.
Capture observed evidence immediately
Bind inputs, actions, outputs, time, identity, and relevant logs to the case and mark it passed, failed, blocked, or not run instead of relying on meeting recollection.
Triage without rewriting the baseline
Separate product defect, data issue, configuration issue, environment failure, training question, and new request. Unrecorded live repair destroys version and evidence integrity.
Retest on an identified new version
Package a fix as a new identifiable candidate, verify the issue, and regress the affected scope. Never edit an old failure record into a pass.
Summarize exceptions and residual risk
Show each criterion, execution status, blocker, approved deferral, production difference, and corrective action so the decision maker sees the complete position.
Obtain the authorized decision
Record pass, conditional pass, return for correction, or fail with decision maker, date, applicable version, conditions, and follow-up owners.
Archive and clean up
Preserve required reports and evidence, remove temporary access, keys, and allowlists, and dispose of data under policy so UAT does not become an unmanaged shadow production system.
What enterprise AI adds to the UAT baseline
Freeze the complete AI system
Beyond the application version, record model and service version or alias, system prompts, parameters, safety policy, embedding model, knowledge files, chunking, index, retrieval, reranking, and tool definitions. A vendor model name alone does not identify the accepted object.
Structure samples by business risk
Separate common cases, critical boundaries, insufficient or conflicting information, malicious input, sensitive content, and high-impact actions. Samples should represent deployment conditions and retain provenance, expected behavior, and scoring method.
Permit output variation, not decision ambiguity
Generative wording may vary, but criteria still define factuality, citation, completeness, tone, refusal, human escalation, and tolerance. Calibrated domain reviewers apply the same rubric.
Test knowledge and authorization boundaries
Ask equivalent questions through different roles to verify retrieval, citation, and answer access. Test stale, deleted, unauthorized, and absent material so the system does not invent or disclose beyond permission.
Isolate real actions from tool use
Agent tools for orders, messages, tickets, and approvals use test endpoints, allowlists, and least privilege while confirmation, idempotency, duplicate prevention, timeout, recovery, audit, and human handoff are checked.
Define hard-stop outcomes
Unauthorized disclosure, irreversible wrong action, unsupported critical fact, action where refusal is required, bypass of human approval, or loss of auditability should block acceptance and cannot be averaged away by a high aggregate score.
Account for variability and reproducibility
Record input, context, retrieved content, model settings, output, and time for every run. Repeat critical samples and report variance. Reassess evidence when an external model changes without a fixed version.
Records that should remain at the end
- Environment and version baseline
Environment identity, deployment time, artifact digest, configuration, data and dependency versions, and production differences.
- People and authority record
Testers, business roles, support staff, closure authority, and final decision maker with their authorization basis.
- Cases and execution results
Preconditions, samples, steps, expected and actual outcomes, evidence, execution time, and status for every scenario.
- Defect and retest trail
Severity, impact, owner, fix version, retest evidence, closure decision, and treatment of open items.
- Acceptance decision
Applicable version, decision status, conditions, accepted risks, follow-up action, owner, and date.
- Environment closure
Evidence archive, data retention or deletion, temporary-account removal, key rotation, and the environment's next authorized use.
Concepts commonly confused with a UAT environment
| Related concept | Difference from a UAT environment |
|---|---|
| User acceptance testing | UAT is the activity in which business users test against criteria and make an acceptance judgment. The UAT environment is the technical and data context that hosts it. |
| General test environment | General test supports development, QA, automation, integration, or failure testing. UAT specifically serves authorized business roles, formal business scenarios, and evidence suitable for sign-off. |
| Staging environment | Staging asks whether a candidate can run through the release path under production-like technical conditions; UAT asks whether the business accepts its outcomes. They may share infrastructure, but goals, access, windows, and evidence remain distinct. |
| Production environment | Production carries live business and operating responsibility. UAT may touch live samples or services only under explicit controlled authorization, not by default for realism. |
| Training environment | Training supports repeatable practice and does not produce an acceptance decision. UAT runs approved scenarios and preserves formal results; inadequate training can distort UAT findings. |
| Demo or pilot | A demo presents capability, while a pilot may expose a limited real user group within controlled production. UAT remains a non-production acceptance context whose conclusion covers only the defined version and scope. |
Sources and scope
This entry defines the controlled non-production environment that hosts user acceptance testing. It does not define the UAT activity, acceptance plan, or acceptance decision itself. UAT may use a dedicated environment or qualified test or staging infrastructure. A separate name or resource boundary is less important than controlling the accepted object, business data, participant access, external side effects, environment differences, and evidence. Entry into UAT does not mean that a version has passed acceptance.
- Microsoft Learn: UAT lets end users or clients verify and accept a system before production
- Microsoft Dynamics 365: UAT participants, dedicated integrated environment, data, and sign-off
- Microsoft Dynamics 365: Test scope, versions, environments, accountability, and results
- NASA Software Engineering Handbook: Acceptance criteria and acceptance data packages
- ISO/IEC/IEEE 24765: Acceptance testing and acceptance criteria terminology
- NIST AI RMF: AI tests representative of deployment, human input, safe failure, and documentation
- NIST AI 600-1: Generative AI risk testing and management