Enterprise AI Project Wiki · Testing and acceptance
Acceptance version
Also calledAcceptance build · Acceptance baseline · UAT candidate · Version under acceptance
An acceptance version is a solution configuration baseline formally designated by the project's authorized party before an acceptance cycle and linked to its acceptance scope, environment, criteria, and evidence. It identifies application artifacts, configuration, database changes, interfaces and dependencies, required data state, documentation, and—where applicable—AI models, prompts, knowledge, and tools so every participant tests the same object. A material change creates a new baseline and triggers an impact-based decision on retesting.
Why formal acceptance needs a designated version
An acceptance decision is valid only for a determinate object. If testers see different code, configuration, data, or knowledge in the morning and afternoon but combine the results, no one can state which object passed.
Designation creates a boundary between continuing development and formal judgment. Development may continue, but the object in this cycle has its own baseline. A defect fix cannot silently overwrite it; the fix becomes a new identifiable baseline.
A frozen acceptance version does not mean content can never change. It means that change is visible, approved, and traceable so failure, correction, retest, exception, and final sign-off all attach to a concrete object.
What a complete acceptance version normally includes
A project may tailor this list, but every object capable of changing the acceptance outcome belongs in the baseline or as a controlled external condition.
Application and service artifacts
List frontend, backend, mobile, job, plugin, and middleware artifact version, build, repository location, and content digest. Do not substitute a branch or `latest` tag.
Configuration and feature flags
Capture environment variables, business rules, role mapping, templates, feature flags, schedules, and material parameters. Record secret reference and version, never plaintext in the acceptance file.
Database and migration
Identify schema, migration scripts, initialization or master-data batch, migration result, and compatibility conditions. The same application against a different schema is not the same object.
Interfaces and external dependencies
State API contract, customer and third-party version, endpoint type, test double, certificate, and known limitation. Register an unpinnable dependency as an environment difference.
Acceptance data state
Associate business samples, migrated data, accounts, roles, and initial state with the cycle and distinguish whether each is a version component, test baseline, or external input.
Operational and user documentation
When acceptance covers use, administration, deployment, or handover, version the relevant guide, interface document, runbook, and known-issue list.
Build and configuration manifest
A machine-readable or auditable manifest maps the product version to components, commits, builds, digests, and approval records.
How to designate and freeze an acceptance cycle
Confirm cycle scope
Set requirements, criteria, business flows, roles, non-functional items, explicit exclusions, and permitted exceptions.
Assemble the candidate baseline
Build the manifest, artifacts, and deployment instructions from components that passed prerequisite testing rather than assembling them ad hoc inside UAT.
Deploy and verify identity
Deploy immutable artifacts to the agreed environment and reconcile version, digest, configuration, and database state reported by the UI or API.
Pass entry readiness
Verify environment, accounts, data, dependencies, logs, issue workflow, and hard-stop conditions, with no known difference that invalidates planned conclusions.
Obtain authorized designation
Record acceptance-version ID, manifest digest, scope, environment, window, approver, and timestamp and tell participants to capture evidence from this baseline.
Protect the baseline
Prevent artifact overwrite, direct database edits, silent configuration changes, model-alias movement, and unrecorded knowledge reindexing; route necessary changes through control.
How a defect fix creates the next acceptance version
- Preserve original failure evidence
Keep original baseline, scenario, input, observed result, logs, and issue ID. Never rewrite the failed record as passed after a fix.
Evidence: failed case, defect, and original manifest.
- Identify every changed configuration item
Link the correction to source, configuration, script, data, prompt, or knowledge changes and assess direct and indirect effects.
Evidence: change request, review, component diff, and risk assessment.
- Create a new baseline
Any behavior-changing update receives a new acceptance ID or revision and a regenerated manifest and digest.
Evidence: new manifest, build, deployment, and approval.
- Decide retest and regression scope
Retest the failure and add affected function and end-to-end regression based on shared components, migration, access, integrations, and nondeterminism.
Evidence: impact analysis and approved retest scope.
- Separate conditional acceptance from correction
If an issue remains, record impact, workaround, due date, owner, and risk authority; do not conceal it by changing a number.
Evidence: exception, residual risk, and signature.
- Aggregate conclusions by baseline
The final report shows the version on which each item passed. Reused evidence explains why later changes do not affect it.
Evidence: criterion-case-version-result traceability matrix.
Questions the acceptance-version record must answer
- What exactly was accepted?
Product version, component list, artifact digests, configuration, database, documentation, and dependencies are retrievable.
- Who designated it and when?
Authority, timestamp, window, environment, and manifest digest are recorded in a durable way.
- Where was it built and how deployed?
Source, dependencies, build pipeline, repository, deployment run, and environment reconciliation form one trace.
- Which criteria and cases apply?
Scope, criteria, samples, cases, non-functional checks, and exclusions map to the baseline.
- What changed during the cycle?
Every revision contains reason, content, approval, impact, retest, regression, and closure state.
- Which version does the final decision cover?
Sign-off names the ID and digest, decision, conditions, open issues, residual risks, and owners.
What enterprise AI must additionally pin
Model and hosted deployment
Record provider, model ID, fixed snapshot or registry version, deployment name, region, safety policy, and material parameters. For a mutable alias, store its resolved version and revalidation trigger.
Prompts and orchestration
Include system prompts, templates, output schema, agent workflow, routing, memory policy, tool definitions, and human-approval steps in the manifest.
Knowledge state
Pin source batch, permission snapshot, cleaning, chunking, embedding model, index build, retrieval, reranking, and cache. An unrecorded reindex during acceptance is a version change.
Tools and external actions
List API contract, credential scope, test endpoint, allowlist, idempotency, and confirmation policy. A tool-logic change changes the accepted object even if answer text does not.
Evaluation baseline
Version samples, normal and abnormal categories, reference facts, rubric, reviewer calibration, automated judge, and repetition count alongside the system.
Nondeterministic change decision
Output variation alone is not necessarily a version change, but moved model aliases, knowledge updates, prompt or parameter changes, and provider behavior changes can invalidate evidence and require impact-based reacceptance.
Concepts commonly confused with acceptance version
| Related concept | Difference |
|---|---|
| Version number | The number is an identifier. The acceptance version is a formally designated configuration baseline with identifiers, components, conditions, and control records. |
| Latest version | Latest only means current by time or order and might not have passed prerequisite tests or might continue changing during acceptance. |
| Release candidate | A release candidate is intended for the release path. It becomes this cycle's acceptance version only when designated and bound to scope and evidence; the two may coincide. |
| UAT environment | The environment is the technical and data context in which acceptance runs. The acceptance version is the object deployed there for judgment. |
| Acceptance criteria | Criteria define how to decide; the acceptance version defines what is being judged. The same criteria may apply to successive revisions. |
| Accepted version | At cycle entry it is only the version under test. It becomes accepted only after completion and authorized sign-off. |
| Production version | The production version is actually deployed and running. Release and deployment records prove whether the accepted baseline entered production unchanged. |
Sources and scope
Acceptance version is not a universal term used identically by every software standard. This entry uses it for the complete, identifiable, controlled solution baseline formally designated for an acceptance cycle—not merely a version number followed by an acceptance label. It is not the same as a version number, newest build, release candidate, UAT environment, acceptance criteria, acceptance result, or production version. A project may call it an acceptance baseline or UAT candidate if the object and controls are equivalent.
- Microsoft Dynamics 365: Aligning test cycles with solution versions of code, configuration, master data, and migrated data
- NASA: Versioned acceptance configuration, baselines, reports, and retest evidence
- NASA: Configuration items, unique versions, baseline composition, and change authority
- NASA: Software version descriptions and release-baseline records
- NASA: Acceptance criteria, code version, discrepancies, and release readiness
- ISO/IEC/IEEE 24765: Product baseline and acceptance-testing terminology
- ISTQB: Acceptance test objects, criteria, and measurable decisions