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. 01Change requestA change request is a formal record proposing a modification to an identified document, deliverable, or baseline. It connects the current state and proposed state with the reason, impact, options, decision authority, implementation, and verification requirements, so that a team can determine whether a change is necessary, worthwhile, and safe before it alters a commitment or controlled system, and can update all affected baselines after the decision.View entry→
2. 02Phase-one scopePhase-one scope is the authorised set of objectives, users and business scenarios, deliverable results, necessary work, technical and data boundaries, responsibilities, cost, and completion conditions to be delivered in the first agreed stage of a wider project. It also identifies what is excluded, deferred, or dependent on outside work. As its own baseline, it can be estimated, scheduled, delivered, and accepted separately, and can support a decision to proceed, adjust, repeat, or stop at the phase gate.View entry→
3. 03Project 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→

How real roles complete work in a defined context, and how those scenarios become inputs to scope, requirements, design, and acceptance.

1. 01Business requirementA business requirement is a manageable statement of the capability, business outcome, or high-level constraint an organisation must obtain to achieve an established business purpose. It connects a problem or opportunity to scope, stakeholder and user requirements, business rules, solution requirements, verification, and benefit measurement while remaining appropriately independent of a particular product, supplier, interface, or algorithm.View entry→
2. 02Business ruleA business rule is a manageable statement adopted or enforced by an organisation to define business concepts, constrain acceptable states and conduct, or derive a business conclusion from known facts. It needs an authoritative source, scope, input facts, result, exceptions, precedence, and version so people and systems can decide, execute, explain, and review consistently.View entry→
3. 03Business scenarioA business scenario is a bounded narrative of one or more roles performing work in a defined business context to reach an identifiable outcome. It starts from a trigger and preconditions, explains how people, systems, and third parties use information, make decisions, hand work over, and handle exceptions, and ends in a confirmable state. It also records its applicability, frequency, scale, risks, and constraints.View entry→
4. 04Functional requirementA functional requirement is a normative statement allocated to a named system level that specifies what the system must receive, validate, transform, store, retrieve, calculate, decide, control, present, transmit, record, prevent, or recover under explicit conditions, with a result observable or verifiable at its boundary. It should be necessary, atomic, unambiguous, feasible, verifiable, and bidirectionally traceable.View entry→
5. 05Non-functional requirementA non-functional requirement is a normative statement about a quality characteristic, required quality level, or sourced implementation or operational constraint on a system, product, service, or environment. It states the object, context, load, time window, risk condition, measurable response, or justified boundary under which functions must operate, and it must be verifiable, traceable, allocatable, and change-controlled.View entry→
6. 06Performance requirementA performance requirement is a normative quantitative statement of the speed, latency, deadline, throughput, concurrency, processing scale, capacity, or resource-use level with which a named system object must perform a named function. It also defines workload, data, environment, measurement boundary, statistic, threshold, and allowed failure so that the result is reproducible, verifiable, allocatable, traceable, and change-controlled.View entry→
7. 07Stakeholder requirementA stakeholder requirement is an authorised, reconciled, traceable, and verifiable normative statement that translates the service, interaction, quality, information, control, or constraint needed by an identified stakeholder or stakeholder class in a defined lifecycle and operational context. It connects upstream needs and expectations to system requirements and provides a basis for solution validation.View entry→
8. 08System requirementA system requirement is a necessary, unambiguous, feasible, verifiable, and traceable normative statement allocated to a clearly bounded system of interest, defining a behaviour, performance level, interface, information need, quality, or constraint that the system must satisfy under stated conditions. The approved set forms the baseline used for design allocation, implementation verification, change control, and delivery evidence.View entry→
9. 09User needA user need is a solution-independent prerequisite that a user or group of users requires in a defined context of use to achieve an intended outcome. It explains who must accomplish or understand what, under which conditions, why the outcome matters, and which barrier exists today, providing a basis for scope, user requirements, design, content, support, and validation.View entry→
10. 10User requirementUser requirements are a set of specifiable and verifiable requirements for system use and the quality of use outcomes, derived from user needs, capabilities, and context of use. They state how users must be able to exchange information with a system to achieve goals and how effective, efficient, safe, accessible, or satisfactory the result must be for specified users, tasks, and environments.View entry→
11. 11User roleA user role is a stable abstraction that groups people who share goals, responsibilities, tasks, and a context of use while directly using a service or participating in its business outcome. It explains why those participants enter a scenario, what they need to know and accomplish, which business decisions they may make, where they hand work over, and which conditions constrain them instead of substituting a person's name or system account for a requirement.View entry→