Enterprise AI Project Wiki

The environment, version, deployment, and release concepts a team must distinguish as a system moves into live operation.

1. 01DeploymentDeployment is the controlled process of installing, configuring, or updating an identifiable software or system version in a specified target environment and checking dependencies, database state, permissions, startup, health, and records until the environment reaches its intended running state. A complete deployment identifies the input artifact, target, execution, resulting change, verification evidence, and stop or recovery path—not merely that files were uploaded.View entry→
2. 02Environment isolationEnvironment isolation is the set of boundaries and controls that prevents people, programs, data, credentials, changes, and failures in one lifecycle environment from accessing, altering, or affecting another without an explicit, controlled authorization path. Effective isolation covers identity, connectivity, data flow, secrets, deployment targets, shared services, and logs as well as compute resources, and can be demonstrated through tests and audit evidence.View entry→
3. 03Production environmentA production environment is the complete operating context formally used for real users, business data, and business operations. It is neither a server nor deployed code alone. It includes entry points, compute and runtime, networking, data stores, identities and permissions, configuration and secrets, external dependencies, monitoring and alerting, backup and recovery, and the people and procedures responsible for keeping the system running.View entry→
4. 04ReleaseA release is the controlled process by which an organization authorizes an identifiable software version, feature, or configuration to become obtainable, accessible, or active for a defined audience, through a specified channel and at an intended time, while observing its effects. Release changes availability and exposure. It can be performed through traffic routing, feature flags, entitlements, download channels, or store distribution, and it need not occur at the same time as deployment.View entry→
5. 05RollbackRollback is a new controlled change performed after an earlier change produces an unacceptable result. It follows a defined sequence to restore affected components to a known-operable, verified, and compatible baseline, then reconciles data and external effects produced during the change window. Rollback is complete not when old processes start, but when service, data, authorization, business journeys, and observations meet the predefined recovery state.View entry→
6. 06Runtime environmentA runtime environment is the actual set of technical conditions that allows a specified software artifact to start, execute, and interact with required resources. It commonly includes processor and operating system, language or application runtime, system and application dependencies, startup command, configuration and secrets, identity and permissions, network and storage, resource limits, and external services used while running. Material differences in these conditions can change behavior, performance, and security even when the code is identical.View entry→
7. 07Staging environmentA staging environment is a controlled non-production environment used to make the final validation of a production-candidate artifact, its configuration, and the formal deployment path before production. It reproduces production conditions relevant to release risk while remaining isolated from real users, live data, and irreversible actions, allowing configuration, access, networking, dependency, migration, startup, and observability failures to be found before go-live.View entry→
8. 08Test environmentA test environment is a controlled non-production environment where testers, developers, or automated systems run an identified version and verify expected outcomes. It needs explicit configuration, data, dependencies, access, and reset procedures so defects can be found, recorded, reproduced, and retested without affecting real users or production data.View entry→
9. 09User acceptance testing environment (UAT 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.View entry→
10. 10Version numberA version number is an identifier assigned under an agreed rule to a particular state of a changing object so that the state can be distinguished, referenced, ordered, or related to other states. A useful project version number resolves to a defined object and change record. If the same number can point to different content, or a changed number cannot be tied to an object, it is display text rather than reliable support for deployment, acceptance, rollback, and incident diagnosis.View entry→

How project requirements become testable, evidenced, and authorized acceptance conditions.

1. 01Acceptance criteriaAcceptance criteria are pre-agreed, verifiable conditions used by project stakeholders to decide whether a specified deliverable or version can be accepted. They identify the object, applicable conditions, expected result, tolerance, verification method, evidence, and decision authority so that pass or fail follows recorded results rather than an improvised judgment.View entry→
2. 02Acceptance versionAn 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.View entry→

How a project defines what it will and will not deliver, forming a shared boundary for estimates, schedules, acceptance, and controlled change.

1. 01Project scopeProject scope is the delivery boundary stakeholders approve in an identified version: which outcomes will be delivered to which users and business scenarios in the current phase; what necessary work, systems, data, and environments are included; who owns each responsibility; how completion will be decided; and what is explicitly excluded. It is the common baseline for estimates, schedule, resources, acceptance, and change decisions.View entry→