The strong rivalContinuous delivery should remain continuous

Formal lifecycle gates can recreate slow project governance, separate build from run teams and make small safety improvements wait for a committee. Delay encourages workarounds and large bundled releases. A low-consequence copy correction should not follow the same path as a new autonomous action. The state machine must preserve frequent delivery where evidence is objective and effects are reversible.

Automate transitions inside a qualified envelope. Tests can verify schemas, access, latency, cost bounds, prohibited tool calls, rollback artefacts and sampled task behaviour. Progressive exposure can stop at a hard-gate breach. Human decisions should concentrate on service promise, affected population, action authority, material trade-offs, customer communication and irreversible change.

A state is therefore a set of permitted behaviours, not a meeting label. If controlled live and scaled service allow identical population, authority and recovery, the distinction is false. If a vendor update crosses tool, refusal or cost boundaries, the service must be able to constrain it even when the software delivery system reports no product change.

Original constructThe nine-state AI-Native Service State Machine

The state machine is this article's synthesis. Forward, backward and lateral movement is allowed. No state inherits evidence indefinitely, and production is not one destination.

Transition evidenceThe service-state receipt

Every transition issues a service-state receipt. Record current and requested state; service promise and eligible population; all material component versions; task, user, service, economic, risk and control evidence; change since the last qualified state; hard gates and uncertainty; decision owner; rollback or degraded route; customer, support and affected-record obligations; next observation; and expiry.

The receipt distinguishes a software release from a service-state change. A retrieval refresh may need requalification without new code. A code refactor may remain inside the current state if interfaces, behaviour, costs and controls are proven unchanged. Vendor labels such as stable or production-ready are inputs, never promotion authority.

Evidence expires by mechanism. A task evaluation may expire when prompts, tools or population change. Load evidence may expire with concurrency or routing. Support readiness may expire after staffing loss. Contract consent may expire at a notice date. The receipt names these conditions so a green decision cannot persist after its basis disappears.

Timing integritySynchronise three clocks

The product-learning clock governs experiments, feedback and version change. The operating-response clock governs detection, support, constraint, rollback and repair. The contractual and regulatory clock governs notice, consent, record, incident, remedy and transition obligations. A transition is valid only when all three can support it.

A team may be able to deploy hourly while customers require advance notice of material behaviour change. Monitoring may detect an unsafe tool action in seconds while record repair takes days. A delayed outcome may arrive after several learning cycles. Treating the fastest clock as the service cadence creates unmanaged debt in the other two.

For each gate, record the latest safe decision time. Shadow evidence must arrive before authority activates. A rollback decision must precede irreversible side effects. Customer communication must precede a change where required. Recovery cannot close before affected records and external messages are reconciled. The slowest necessary obligation constrains the transition, even when code is ready.

Promotion evidenceShadow, controlled live and scale are different services

Shadow mode tests real workflow inputs without consequential production authority. It is false shadow if generated content changes queue priority, alerts influence operators, retrieved records are written back or latency changes customer treatment. Map every side effect, including attention and ordering. If the service can affect an outcome, name the state honestly and apply controlled-live protections.

Controlled live admits a bounded cohort with explicit authority, support and rollback. Select the cohort for evidence, not only enthusiasm. Expert volunteers may compensate for weak interfaces, catch errors and tolerate friction that ordinary users cannot. Capture modifications, abstentions, appeals, support contacts and downstream effects. Keep cumulative exposure visible when each action seems small.

Scale is a discontinuity, not a multiplier. Novices, new languages, edge cases, peak concurrency, organisational incentives and customer support enter the population. Model routing may change to meet cost. Human review queues can saturate. Unit economics can reverse even when task scores hold. Requalify service performance, outcome, distribution, control capacity and margin across actual cohorts.

Promotion gates should remain non-compensable. Strong average quality cannot offset a prohibited action, absent recovery or unserved accessibility need. Good economics cannot offset an invalid privacy purpose. High customer satisfaction cannot offset affected people who cannot appeal. Report ranges and failed gates rather than one lifecycle score.

Requalification triggersWatch the service, not only the model

Track changes to model, data, prompt, retrieval, tool, interface, workflow, policy, population, vendor dependency and support. Classify each by potential effect on promise, authority, quality, risk, cost, recovery and obligations. The trigger determines the evidence needed, not the prestige of the changed component.

A vendor model change can alter refusals, tool choice, latency or price while the product version remains nominally unchanged. Pin versions where possible, test candidate routes and maintain the authority to constrain or substitute. A vendor's release note and benchmark are not evidence for the customer's task, integrations or affected population.

Data and retrieval changes can be more consequential than model changes. A source deletion can remove a safety rule. A freshness update can introduce an unreviewed jurisdiction. A permissions change can expose a record. Prompt, interface and workflow changes can alter reliance and override. Each needs a service-level impact hypothesis and bounded test.

Automate low-consequence changes when objective evidence shows they remain inside the envelope. If a copy edit changes no decision, authority, data, integration or obligation, targeted tests and version trace may suffice. This proportionality prevents gate bureaucracy from becoming a source of unsafe delay and shadow change.

Safe statesConstraint, incident and complete recovery

A constrained state preserves a useful core by reducing population, authority, feature set, model route or service level. A degraded state must be compatible with current tools, data and policy. Falling back to an older model that cannot honour the present tool contract is not safe degradation. Rehearse the route under realistic load and verify what customers see.

Incident containment stops continuing effects, preserves evidence and establishes current state. The team reconstructs which versions acted, which tools ran, which records changed and which external messages left. It identifies affected people and customers rather than using only error logs. Customer communication follows the applicable severity and obligations.

Repair spans the causal path. Correct decisions and records, reconcile queues, revoke or replace artefacts, contact recipients where appropriate and provide contest or remedy. Fixing code or rolling back a model does not reverse a sent message, transferred payment, denied service or corrupted customer record.

Requalification tests the corrected service against the incident mechanism, broader task population and current operating envelope. Restoration is controlled by cohort and authority. A successful root-cause test cannot compensate for missing customer repair, support readiness or compatible rollback. Preserve residual uncertainty and a next observation in the receipt.

Supported transitionRetirement is an operational state

A useful feature may still require retirement when it cannot meet current security, support, economic or contractual obligations. Indefinite exception is a hidden service state without controls. Transition begins by mapping users, integrations, stored data, active decisions, downstream records, open incidents and promises that depend on the feature.

Provide a supported destination, migration evidence, notice and assistance proportional to dependence. Freeze new adoption where appropriate while preserving a safe path for existing obligations. Retain or delete records under applicable purposes and schedules. Close remedies and disputes rather than deleting the interface and declaring completion.

Paper 080 addresses detailed feature-retirement mechanics. Here, retirement is the state selected when the current service cannot be supported and a transition can be governed. Its admission evidence includes reason, population, dependency map, customer plan, record plan, owner and exit criteria.

Interactive instrumentAI Service Lifecycle Controller

Set the current service conditions and requested transition. The Controller returns one of five routes with a transition receipt and next observation. It does not issue a lifecycle maturity score.

Five routesWhat the lifecycle decision permits

Advance or scale within the evidenced envelope

Promote only the population, authority and versions actually tested. Preserve progressive exposure, hard gates and a proven safe state. Set the next observation and expiry.

Remain in shadow or controlled live and collect evidence

Hold when pilot population, outcome, support or economics does not establish the requested state. Collect the missing evidence without allowing the nominal state to expand.

Constrain the service or enter a rehearsed degraded mode

Narrow scope when a vendor or component change crosses the envelope but a compatible useful core exists. Communicate the changed promise and requalify before restoration.

Enter incident containment, repair and requalification

Use when harmful effects, failed hard gates or incomplete customer and record repair make ordinary operation unsafe. Restore only after end-to-end evidence.

Transition users and retire the unsupported service

Use when the service cannot meet current obligations or economics and dependencies can be moved. Retirement is supported transition, not interface deletion.

Route testsNine cases the Controller distinguishes

Controlled advance: matched cohort, qualified versions, viable economics, ready support and end-to-end rollback permit promotion inside the envelope.

Pilot to scale: expert evidence and pilot support do not cover novice users or peak load. Remain controlled and collect scale evidence.

Vendor change: refusal and tool behaviour may have changed. Constrain to a qualified route while the candidate is tested.

False shadow: generated drafts already change queue order. Enter containment and reconstruct affected decisions rather than preserving a false label.

Economics reversal: quality holds, but review and retrieval make scale loss-making. Remain bounded while redesigning the service and price.

Unsafe degraded mode: the fallback cannot honour current tool and policy contracts. Constrain further or stop affected authority.

Active incident: harmful effects require containment, customer communication, record repair and requalification.

Repair incomplete: a technical fix exists but external messages and records remain wrong. Stay in recovery.

Retirement trigger: the feature cannot meet current security and support obligations, while dependencies are mapped. Transition users and retire it.

Operating proofKeep the state machine behavioural

Automate a state inventory that joins versions, cohorts, authority, support, evaluation, economics, incidents, contracts and expiry. Alerts should propose a transition when a hard gate fails or evidence expires; they should not silently change authority. The named service owner remains accountable for the state.

Test degraded mode before need. Exercise vendor loss, retrieval failure, tool denial, load saturation, support absence and record reconciliation. Verify both safety and usefulness. A fallback that never ran against current schemas and policy is an idea, not a safe state.

Measure transitions, not maturity. Track time in unqualified change, false-shadow side effects, scale-gate misses, expired evidence, unsupported cohorts, failed rollback drills, customer repair ageing, support load and retirement dependencies. Preserve results by state, version and population.

Review state labels with frontline staff and customers. Ask what the service may do now, what changed, how to contest, what happens during degradation and when evidence expires. If answers differ from the receipt, communication and interface are part of the failure.

Link commercial terms to states. A controlled-live cohort may have different service levels, support and price from scale. A constrained state may change availability without changing core obligations. Retirement notice and portability belong in the lifecycle design before the service becomes unsupported.

Close incidents with two proofs: the corrected mechanism passes the relevant challenge, and affected customers, records and downstream actions have been repaired or explicitly accounted for. Lessons update evaluation and recovery without converting every incident into permission for unrelated data reuse.

Transition-by-transition proofQualify the service that will exist next

From problem hypothesis to bounded design

The first gate asks whether the proposed service changes a consequential decision or task for an identifiable user and whether an acceptable non-AI alternative exists. Record who receives value, who bears errors and which uses are unacceptable. Test the problem with workflow and outcome evidence rather than enthusiasm for a model demonstration. If the value route depends on adoption, data remediation or authority redesign, those conditions become part of the hypothesis instead of invisible assumptions.

The design state admits only problems for which the team can define a task population and exclusions. It must identify frontstage experience, backstage work, support process, human decisions, tool authority and affected-party route. The design specifies what abstention, cancellation, contest and safe failure look like. A prototype that handles the happy path while leaving recovery to future operations is not a bounded service design.

From bounded design to evidence-ready build

The build gate converts every promise into inspectable evidence. The product needs stable identifiers for model, data, prompt, retrieval, tool schemas, interface, workflow and policy. Traces must show inputs, decisions, human changes, actions and downstream effects without collecting unnecessary content. Evaluation cases map to the intended and prohibited task populations. Security, privacy, accessibility, cost and support controls need owners and executable tests.

Evidence readiness includes deployment and recovery artefacts. The team should be able to recreate the qualified configuration, identify third-party dependencies, constrain tools, revoke access and reach the declared safe state. A dashboard is not readiness when it cannot connect an alert to a version, affected cohort and action. Before shadowing real work, operators should know which observation would stop the exercise and who has authority to do so.

From build to true shadow

Shadow admission requires a side-effect map. List writes, queue changes, notifications, cached suggestions, human attention shifts and customer-facing traces. Generated drafts may be stored in an isolated environment for comparison, but must not influence production priority or authority. Where operators can see shadow outputs, measure whether their choices change. If the study cannot prevent a material effect, classify it as controlled live and apply that state's communication, support and recovery.

Shadow evidence should compare service behaviour with the real alternative under the same workflow conditions. Capture cases the service abstains from, latency, tool attempts, operator disagreement, missing context, distributional differences, cost and required support. Do not promote from accuracy alone. The gate asks whether the complete service, including human roles and recovery, can perform its bounded promise without hidden effects.

From shadow to controlled live

Controlled-live admission names the first exposed cohort, cumulative action limit, authority, service window, support coverage and rollback trigger. The interface tells users what the service may do and how to challenge it. Affected-person routes exist where relevant. The customer and provider agree which versions and service terms apply. Monitoring distinguishes model output from executed action and joins later outcomes to the correct cohort.

Progressive exposure should be large enough to reveal the intended conditions but small enough to contain failure. Do not select only experts who can compensate for the service. Include realistic skill, accessibility and workload while keeping a deterministic escalation route. Review early cases in depth, then move towards representative sampling without letting a rising volume dilute hard gates. Each expansion is a transition recorded in the same receipt family.

From controlled live to scale

The scale gate reconstructs the service under changed population and load. Test novices, infrequent users, new customer configurations, language or regional variation and edge cases expected at scale. Run peak concurrency with real routing, retrieval and tool limits. Verify review queues, customer support, accessibility assistance, incident response and appeals at forecast volume. Evidence from an expert pilot cannot stand in for these conditions.

Recalculate service economics with all controls active. Deeper reasoning, retrieval calls, human review, support and incident work can make a technically successful service commercially unsustainable. A negative range does not justify silently weakening controls. Redesign the service, narrow the promise, change the commercial contract or remain bounded. Scale is permitted only when value capture and provider capacity survive the same quality and risk envelope.

Lateral movement into constraint

Constraint is not failure theatre. Define the useful core that remains valid, the cohort that may use it and the authority removed. A vendor change might force tool use off while preserving draft assistance. Retrieval uncertainty might restrict answers to cited records. A load event might queue non-urgent tasks while retaining essential service. The interface, support team and customer contract must recognise the changed state, not continue promising scaled behaviour.

Every degraded route needs compatibility proof. Test current tool schemas, policy, data permissions, record formats and customer integration against the fallback. Confirm that old components do not restore retired behaviour or lose current safeguards. Measure capacity and recovery objectives under the degraded route. If the supposed fallback cannot preserve a safe useful core, the proper route is containment, not optimistic degradation.

From incident to controlled restoration

Containment freezes the relevant authority and preserves enough evidence to reconstruct service state. Scope investigation by versions, cohorts, actions and effects rather than by one model identifier. The team should find dependent records, customer communications, external tool actions and people who may not know they were affected. A vendor correction can inform the investigation but does not close it.

Restoration requires mechanism and remedy evidence. The corrected configuration passes the incident challenge and the broader operating set; affected decisions and records are corrected; messages and transactions are reconciled; support is ready; and residual uncertainty has an owner. Restore by cohort or authority so monitoring can detect recurrence before full exposure. The new receipt links the incident, repair evidence, communication and next observation.

From constrained service to transition and retirement

Retirement admission asks whether the service can meet current security, support, economic and contractual obligations. If not, map every active user, integration, stored record, unfinished decision, open incident and dependent process. Identify a supported destination and the period required to move safely. Stop new adoption where continued growth would deepen unsupported dependence.

Retirement completion is evidenced by successful migration, reconciled records, fulfilled notices, resolved remedies, handled data and access, and a recoverable archive of decision and invoice evidence where required. Removing a feature flag or endpoint is only one technical event. The service remains in transition while customers or obligations still depend on it. Detailed feature-retirement mechanics belong to the next paper; this state sets their admission and completion boundary.

Evidence expiry and decision authority

Each evidence item should carry an expiry rule tied to mechanism. Task evidence expires when the task population or relevant components change. Service evidence expires when load, routing or support changes. Economic evidence expires when cost distribution or adoption shifts. Recovery evidence expires when dependencies, schemas or staff capacity change. Time alone may also expire a result, but an observed boundary change should not wait for the calendar.

The transition owner needs authority across product, engineering, operations, risk, support and customer commitments. Specialist approvals remain attributable, while one accountable service owner decides the state within defined governance. Record dissent and uncertainty rather than manufacturing unanimity. When a hard gate fails, commercial or delivery pressure cannot average it away. When a bounded change clearly remains inside the envelope, the owner should allow automated passage without summoning a general committee.

Run periodic state-reconstruction exercises with people who did not prepare the receipt. Give them a customer, timestamp and observed effect, then ask them to identify the service state, permitted authority, active versions, applicable promise, support route and safest available constraint. They should reach the answer from operational evidence rather than private team knowledge. Missing or conflicting answers reveal that the service cannot reconstruct its own behaviour during a real incident.

Test boundary accumulation as well as single actions. A service may remain within its per-action limit while volume, repeated exposure or linked decisions create a larger consequence. The state inventory should aggregate by person, customer, workflow and time window, then trigger review before the cumulative envelope is crossed. This protects against gradual expansion that never appears as one material release.

Preserve rejected transitions. Record why a promotion, restoration or retirement attempt failed, which evidence was missing and what would change the decision. This prevents the same unsupported proposal returning under a new release name and gives later owners a usable history. A non-transition is part of service learning when it sharpens the envelope rather than becoming an undocumented delay.

Evidence boundaryLifecycle research, service context and scoped duties

CRISP-ML(Q), AI lifecycle and operational ML studies support staged quality work, continual data and experiment work, deployment and monitoring. Production-readiness, model-card and datasheet sources support cross-component testing and versioned documentation. Service blueprinting contributes the customer, frontstage, backstage and support view. None defines the nine states used here.

NIST AI RMF 1.0 and its Core support lifecycle governance, measurement, monitoring, feedback, risk treatment and decommissioning; 1.0 remains the published framework while revision is in progress. The 2024 Generative AI Profile adds generative-risk context. NIST SP 800-61r3, final April 2025, integrates incident preparation, detection, response and recovery with cybersecurity risk management. It is cybersecurity guidance, not a complete AI-service recovery method.

ISO/IEC 42001 and ISO/IEC 20000-1 provide management-system context rather than proof of service quality. EU AI Act lifecycle duties depend on system classification, role, provision and application timing. FinOps informs allocation, unit economics and forecasting. Legal compliance, contractual performance, model lifecycle, software release and service state remain distinct.

The nine-state machine, service-state receipt, three-clock test and Controller are this article's synthesis. Their value must be established through bounded transitions, current evidence, real degraded-mode drills, customer and record repair, and supported exit under the service's actual conditions.