Enterprise AI Project Wiki · Environments, versions, and release

Release

Also calledSoftware release · Version release · Feature release · Product release

Definition

A 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.

A release changes who can use what

A version may be built, tested, and deployed onto production resources without being released to users. The new code can remain at zero traffic, its feature can be disabled by default, a download can remain a draft, or accounts may not yet have the entitlement. Release state changes only when the intended audience can obtain or use the change through the agreed channel.

Conversely, releasing does not always require a code deployment at that moment. A team may deploy a hidden capability earlier and later change a flag or route after approval. A client application can be packaged and pass store review before becoming downloadable on a scheduled date. An API capability may be enabled only for approved customers.

A release record must therefore identify both the object and the exposure state. ‘v2.3.0 released’ is insufficient if it does not say whether that means a source tag, installer, production feature, one tenant, or every user. The ambiguity prevents reliable support, incident analysis, and withdrawal.

Define the unit, audience, channel, and state first

Release unit

State whether this release exposes a whole product version, one feature, an API version, configuration, a model capability, a knowledge batch, or a client package. Bind it to an immutable version, artifact digest, or configuration snapshot.

Intended audience

Identify employees, pilot users, named tenants, a region, device class, opt-in users, a traffic percentage, or everyone. Audience rules must be executable and reproducible.

Release channel

Specify whether availability is controlled through web traffic, feature flags, entitlements, an API gateway, package repository, download page, app store, device update service, or manual provisioning.

Timing and cadence

Set the start time, duration of each stage, observation windows, pause points, conditions for general availability, and staffed support period. Technical exposure and communication windows must align.

Availability state

Distinguish draft, candidate, approved, internal, limited, expanding, generally available, paused, withdrawn, and end-of-support. A successful pipeline run is not the only release state.

Ownership and authority

Record who prepares, approves business and risk conditions, changes exposure, observes results, and can pause or withdraw, including final emergency authority.

Entry conditions before exposure

The object is traceable
The release version, component artifacts, configuration, and dependencies are frozen and retrievable.
Version manifest, artifact digests, signatures, or provenance records
Required verification is complete
Agreed tests, acceptance, defect disposition, security checks, and target-environment verification are complete; accepted open issues have an owner and impact statement.
Test and acceptance results, risk acceptance
The exposure mechanism is proven
Traffic, flags, entitlements, channels, or store settings select the intended audience, with cache, session, regional-propagation, and failure behavior understood.
Target-account checks, configuration preview, rehearsal evidence
Metrics and thresholds are defined
Technical, business, security, and user-impact baselines, success bands, observation duration, and hard-stop conditions are agreed before exposure.
Release dashboard, alerts, and decision rules
Recovery is executable
The team can stop expansion, disable a feature, restore old routing, remove a package, or initiate technical rollback. Irreversible data or external actions are separately addressed.
Withdrawal and rollback plan, recovery exercise
Support and communication are ready
Operations, support, business owners, and affected users have the change, known limits, issue route, and emergency contacts they need. Release notes are prepared where appropriate.
Release notes, staffing roster, communication record

What common release methods control

Release method	Controlled scope and principal concern
All-at-once release	Makes the change available to the entire intended audience at one time. It is simple, but unknown defects immediately reach the largest population; use it only when impact is contained, evidence is strong, and recovery is fast.
Internal or pilot release	Exposes the change to staff, test tenants, or a real-business pilot first. The pilot population, data rights, and feedback responsibilities must be explicit, and a successful pilot is not automatic approval for everyone.
Ring or wave release	Expands by risk tier, organization, region, device, or scheduled cohort. Every ring needs an observation period and explicit continue, pause, and withdraw criteria.
Percentage or canary release	Routes a small, representative population to the new version before expansion. Assignment should remain consistent for the user, and metrics must be attributable to treatment and control.
Feature-flag release	Code is deployed but hidden by default, then enabled for selected users. The flag itself needs access control, audit, a safe default and failure mode, plus a retirement date to prevent unmanageable combinations.
User opt-in	Users choose a preview or new experience, accommodating different risk tolerances. The release must explain opt-out, compatibility and data effects, and the available level of support.
Channel or store release	Distributes through a package registry, download page, or app store. Review approval, listing, download availability, automatic update, and actual adoption are separate states affected by caching, region, and client update policy.

How to run a controlled release

Confirm current state
Check the live version, enabled features, present audience, other active releases, service health, and usable risk budget so overlapping changes do not contaminate signals.
Approve the release contract
Authorized owners confirm the unit, audience, channel, stages, metrics, hard stops, withdrawal path, communications, and named responsibilities.
Capture a comparison baseline
Save pre-release technical, business, quality, security, and human-handling measures, and ensure treatment, control, and unexposed groups can be distinguished.
Expose the first cohort
Change routing, flags, entitlements, or channel state for the smallest population that can still reveal principal risks. Record the exact time and configuration version.
Verify assignment and behavior
Confirm only the intended audience receives the capability while others retain the prior behavior. Test identity, permissions, critical journeys, data writes, and degradation paths.
Observe and decide
Compare groups and absolute thresholds for the planned duration, investigating alerts and feedback. If the sample is insufficient or signals conflict, hold the current scope; absence of alarms is not proof of success.
Expand, pause, or withdraw
Record each decision and rationale. Expand only when continuation conditions pass. On a hard stop, prevent new exposure immediately and run the predefined recovery action.
Close the release
Confirm the final audience and feature state, residual issues, support information, and long-term monitoring. Archive the object, notes, evidence, and decisions, and schedule stale-flag removal.

Observation, stopping, withdrawal, and evidence

Observe user outcomes, not servers alone

Track availability, errors, latency, and capacity together with task completion, abandonment, support contacts, authorization anomalies, data correctness, and business guardrails.

Hard stops take precedence

Data disclosure, unauthorized access, irreversible erroneous actions, incorrect charging, critical data corruption, disabled security controls, or loss of traceability should stop expansion immediately without waiting for statistical significance.

A pause is not a closed failure

A pause holds the exposure level while the team collects a sufficient sample, excludes an external incident, or investigates. Monitoring continues and the pause needs a maximum duration.

Withdrawal is not always deployment rollback

Disabling a flag or restoring old routing can remove user exposure quickly while new code remains deployed. Decide separately whether artifacts, configuration, databases, or models also need rollback.

Preserve the actual exposure history

Keep the release ID, object version, each audience rule and configuration snapshot, times, approvers, metrics, alerts, feedback, pauses, withdrawals, and final state for incident reconstruction.

Archive release material and provenance

Retain official artifacts, integrity and provenance data, release notes, known limitations, and security advisories so later vulnerability analysis and customer communication do not depend on a movable tag.

Additional controls for enterprise AI releases

Release composite behavior

Application code, model snapshot or endpoint routing, system prompts, guardrails, knowledge indexes, retrieval settings, tool permissions, and external policy jointly produce the experience. The release record needs the complete combination, not a model name alone.

Deploy a model before routing traffic

A new model may be deployed and validated with directed or shadow requests before real traffic is released. Routing weights, session affinity, region, and fallback models belong in the audience contract.

Use task-specific quality gates

Alongside latency, errors, and cost, observe grounded answers, correct refusal, retrieval success, format adherence, tool execution, human escalation, and critical business outcomes against fixed evaluations and the current production baseline.

Constrain high-risk capabilities first

For agents that message people, edit records, create orders, approve work, or execute code, begin with limited users, tools, amounts, objects, and rates. Retain human approval and idempotency controls before expanding.

Treat knowledge permissions as a release gate

Before a knowledge batch becomes searchable, verify additions and removals, tenant and role access, index completion, citations, and cache propagation. A permission defect is a hard stop, not an ordinary relevance fluctuation.

Allow longer observation for nondeterminism

The same input may produce different outputs and rare failures may appear only in long conversations. Use sufficient samples, stratified scenarios, and repeated runs; a few successful demos cannot replace production observation.

Treat provider changes as release events

A hosted model alias, safety policy, or API can change without a deployment by your team. Monitor observed versions and quality drift, then pin, reroute, disable, or repeat release review when necessary.

Concepts commonly confused with release

Related concept	Difference from release
Deployment	Deployment applies artifacts and configuration to a target and establishes a verified running state. Release changes availability or exposure for an intended audience. They can be coupled or separated.
Build	A build produces artifacts from source and dependencies. A release selects and authorizes an identifiable artifact or capability for an audience.
Version number	A version number identifies an object; it does not prove that the object is released. One version can move through draft, candidate, limited, general, and end-of-support states.
Go-live	Go-live is the broader business transition into formal use and can include deployment, release, data cutover, training, communications, and operating handoff. A release can target only a subset.
Release announcement	An announcement communicates a change but does not prove that a feature, package, or entitlement is actually available. An internal release may have no public announcement.
Delivery	Delivery transfers agreed deliverables, documentation, access, and responsibility to a recipient. Release changes availability for users and need not transfer ownership or maintenance.
Rollback	Rollback restores a prior technical baseline. When a release fails, the team can first withdraw user exposure without immediately rolling back the entire deployment.

Sources and scope

This entry explains the controlled release of a prepared software or AI version or capability to an intended audience. Release is not used consistently across organizations and tools: it can mean a tested collection of configuration items, a downloadable package and its record, or the process of progressively exposing a feature. A project therefore needs to define the release object, audience, channel, and completion state instead of recording only ‘released.’ This entry does not replace the separate definitions of deployment, go-live, app-store review, announcement, delivery, or rollback.