Every infrastructure indicator was green. Latency had improved. Error rate was flat. Yet the lending preparation service was omitting income evidence after a policy and retrieval-corpus change, and customers were receiving different decisions.

The endpoint had not failed. The decision service had. Its behaviour depended on model, prompt, data, retrieval, tools, policy, user population, workflow and vendor versions. Monitoring only the endpoint made the operational unit too small to see the consequence.

Running AI is not ordinary application support with an extra model dashboard. Probabilistic behaviour, changing context, human adaptation and downstream effects create failure paths that conventional service health may miss. Existing SRE, incident and operational-resilience processes should remain the enterprise spine, but they need decision context, representative evaluation and affected-case remediation.

Incidents, drift, change and retirement form one control system. Drift without a decision boundary produces noisy alerts. Change without incident evidence repeats failure. Recovery without affected-case review leaves harm in place. Retirement without dependency removal creates shadow use and missing records.

This article’s AI run-state control plane has six explicit states, four evidence streams and guarded transitions. A change passport carries intended effects and representative proof through release. Every transition records population, signal, authority, safe mode, cases, preservation, notification, recovery evidence and expiry.

The strong rival is complete integration into current ITIL, SRE and resilience practice. Accept that spine. Reject the assumption that service telemetry alone represents an AI-enabled decision. The control plane adds only the evidence needed to connect technical state with business consequence.

Original synthesisControl six run states with guarded transitions

Normal is an evidenced state, not the absence of alerts. The service version, configuration, decision population and applicable tolerances are known. Service objectives, representative evaluation, workflow behaviour and outcome indicators establish the operating envelope.

Observed prevents weak signals from becoming either noise or panic. A statistical shift, complaint cluster or vendor notice can trigger bounded investigation without changing decision authority. The record names the question, owner, evidence to collect and expiry. If uncertainty remains after expiry, the state cannot persist silently.

Degraded is an intentional product mode. The system may return evidence without a recommendation, narrow to a tested population, require human confirmation, use a previous source or reduce tool access. A fallback has its own capacity, evidence and risk limits. “Manual review” is not a safe mode when the queue exceeds the decision window.

Suspended stops the relevant contribution at the smallest safe scope. A workflow may continue without AI, one population may stop, or the complete business action may pause. Incident command preserves evidence, contains further exposure and identifies cases already affected.

Recovered is separate from normal because offline proof is incomplete. A corrected version returns to a bounded population under heightened observation. Exit criteria cover service, behaviour, workflow, cases and outcome. Failure returns the service to degraded or suspended without improvisation.

Retired is an operating state because end-of-life work continues after the interface closes. Scheduled jobs, copied prompts, service credentials, cached outputs, dashboards, user workarounds and dependent workflows must be removed or redirected. Required records remain accessible under a named custodian and retention rule.

NIST’s AI RMF Core links measurement and management to prioritisation, response, recovery and risk treatment.[1] Its Playbook provides voluntary actions for incident, change and decommissioning work.[2] The six states convert those lifecycle concerns into explicit production authority.

Every transition carries a receipt: decision service and version, affected population, signal, severity, confidence, spread, owner, transition authority, action, fallback, affected cases, evidence preservation, notification, recovery test and expiry. Without a complete receipt, a colour change on a dashboard is not an operating decision.

Guard transitions with materiality, authority and time

A transition guard answers three questions. Is the signal material to a decision or affected outcome? Does the proposed owner have authority over the operating mode and population? What evidence or time condition will force the next decision? A state without guards becomes a label that allows responsibility to drift.

Materiality combines consequence, exposure, confidence, spread and reversibility. Low confidence does not always mean low severity: an uncertain signal can justify suspension when plausible consequence is extreme and the path is hard to reverse. Conversely, a high-confidence distribution shift can remain observed when representative decisions and outcomes have not moved and a bounded investigation is safe.

Authority is typed by object. The platform owner may degrade a shared model or retrieval service. The domain owner may remove the AI contribution from its workflow or stop an affected population. Risk or compliance may invoke a binding constraint within delegation. Incident command coordinates these acts but does not silently acquire every underlying right.

Expiry prevents observed and recovered states from becoming permanent ambiguity. The receipt names a clock and the evidence due before it ends. At expiry, the owner returns to normal with a reason, moves to a safer state, expands the investigation under new authority or retires. Simply renewing the clock requires new information and a recorded decision.

Aggregate state is not always the most severe local state. One domain can suspend while others continue on a compatible version; a platform can degrade globally while one critical workflow stops completely. The control plane records both service and consumer state so shared containment does not erase domain consequence.

Consequence-led monitoringBraid four evidence streams into one incident view

The first stream is service health: availability, latency, capacity, freshness, errors, recovery and dependency status. It preserves SRE discipline, but it does not claim to represent the full decision outcome.

The second is input, context and model behaviour: schema, missingness, provenance, distribution, retrieval composition, model and prompt version, evaluation, uncertainty, tool calls and vendor notices. Signals are interpreted against a declared decision population.

The third is human and workflow behaviour: adoption, override, disagreement, escalation, queue, fallback, bypass, review time and operator feedback. Humans can absorb system failure for a while, making technical indicators look healthy as workload and error migrate into the workflow.

The fourth is downstream outcome and harm: completed action, correction, complaint, appeal, rework, loss, exclusion, benefit and remediation. These signals may arrive slowly or live in separate systems. Stable decision identifiers and controlled linkage connect them to versioned context.

Severity follows consequence rather than the most dramatic model metric. A large distribution shift with no observable decision effect may stay observed while its materiality is investigated. One provenance failure affecting a consequential decision can justify degradation or suspension even when aggregate metrics barely move.

Drift is therefore a hypothesis, not an automatic incident or retraining order. The operator asks what moved, which population is affected, whether the decision or outcome changed, how reversible the effect is and what evidence would disconfirm concern. Retraining can introduce a second uncontrolled change before the first is understood.

Google SRE incident guidance emphasises command, defined roles, communication, control and a live record.[4] The SRE Workbook develops incident response practices around preparedness and coordinated action.[5] AI-specific evidence joins those structures rather than creating another command hierarchy.

Service level objectives should represent behaviour users care about.[6] Monitoring and emergency response remain core SRE capabilities.[7] The braid connects service indicators to decision and outcome indicators so an incident commander can choose an operating state with business authority.

Release disciplineIssue a change passport for every behaviour-bearing component

AI change is broader than a model release. Prompt, data, retrieval corpus, tool, policy, workflow, user interface, vendor or human instruction can alter the decision service. The passport identifies the component, old and new versions, intended effect, affected consumers and the evidence needed to classify the release.

The passport contains representative evaluation rather than a single average score. It covers consequential populations, known hard cases, abstention, fallback, evidence quality, workflow response and downstream proxy or outcome where available. The owner explains why the set remains representative and where uncertainty persists.

Compatibility has technical, behavioural, evidence and operational dimensions. An API can remain stable while retrieval sources change. A model can improve overall accuracy while altering a small high-consequence population. Evidence export may lose fields even as response quality improves. Support capacity may be insufficient for the migration.

Release class determines notice, independent review, staged population, observation and rollback. Emergency change follows an expedited path with documented threat, temporary control and later reconciliation. It does not erase lineage or affected-case duties.

Rollback and isolation must be tested against dependencies. A prompt may depend on a new model behaviour; a data schema may not be backward compatible; completed actions may be irreversible. The passport distinguishes component rollback from decision-service recovery.

Production ML systems accumulate debt through entanglement, unstable dependencies, feedback loops and configuration complexity.[8] The ML Test Score frames production readiness across data, model, infrastructure and monitoring tests.[9] Data validation research shows how schema and distribution checks can become systematic production controls.[10]

A vendor change enters the same passport even when it occurs outside the product calendar. The vendor supplies its change evidence; the product owner classifies local compatibility, runs the representative pack and chooses a safe rollout or stop. Contractual notice matters because an unversioned forced update removes local transition authority.

Beyond rollbackRecover the service, the cases and the downstream state

A rollback changes the active component. Recovery restores an acceptable decision service and reconciles consequences already produced. Confusing the two creates the rollback illusion: the prompt is restored, dashboards turn green and affected customers remain in the wrong state.

The incident record first bounds exposure. It identifies versions, time, population, routes, inputs, outputs, human actions and downstream decisions. If exact lineage is missing, the team states uncertainty and searches a conservative envelope. Confidence in the affected-case set becomes part of severity and restart authority.

Technical remediation may roll back, forward-fix, isolate a dependency, narrow a population or change a policy. Operational remediation reviews affected decisions, restores records, communicates with users or affected parties, compensates where appropriate and clears backlogs created by fallback. Risk remediation reassesses exposure, controls and notification.

Recovery tests match the failed path. A provenance defect needs source lineage and case reconstruction tests, not only answer-quality evaluation. A human-workflow failure needs interface, workload and override evidence. A harmful outcome needs representative cases and downstream monitoring. Generic regression is necessary but cannot close the incident alone.

The observation window begins after bounded production returns. It states population, traffic, duration, comparison, indicators, review cadence and exit criteria. High-consequence or slowly observed outcomes may require a longer window or staged expansion. A deadline cannot substitute for enough evidence to see recurrence.

Premature recovery occurs when offline evaluation passes but representative production, human behaviour or affected-case review is absent. The service remains recovered, not normal, until the declared evidence is complete. If a trigger fires, the transition back to degraded or suspended is automatic within the owner’s authority.

The 2026 interagency model-risk guidance addresses outcome analysis, ongoing monitoring, governance, documentation and vendor models.[11] Those practices support component assurance; the run control plane joins them to service state, affected decisions and operational response.

Resilience is more than returning to a previous equilibrium. Woods distinguishes rebound, robustness, graceful extensibility and sustained adaptability as different concepts.[15] Degraded modes and bounded recovery make that distinction practical: the system can reduce exposure, adapt capacity and learn without declaring every disturbance solved.

Incident authorityChange command emphasis as consequence spreads

The existing incident commander owns tempo, coordination, record and communication. AI incidents add typed leads rather than a new hierarchy. Platform or vendor leads control shared service containment. Domain leads control workflow mode and affected decisions. Risk or compliance leads interpret binding constraints and aggregate exposure.

Severity activates authority. A low-confidence statistical signal may remain with the product owner in observed state. A verified workflow effect activates domain incident authority. Shared failure across domains activates platform coordination. Exposure beyond delegated tolerance activates enterprise risk and governing-body escalation.

No technical commander should restart a business decision without domain acceptance, and no domain owner should demand continued use of an unsafe shared service. Platform stop and domain stop rights overlap for different objects. The incident record states which acceptance conditions each owner controls.

Communication names state and consequence rather than speculating about model failure. Responders say which decision service, version, population and operating mode are affected; which fallback is active; what users should do; what evidence is being preserved; and when the next decision will occur.

Basel operational-resilience principles cover governance, business continuity, dependency mapping, third-party relationships, testing and incident management.[12] The run-state record supplies the AI decision context that enterprise resilience processes need to assess a critical operation.

European Union AI regulation includes lifecycle obligations relevant to risk management, records, human oversight, accuracy and resilience, quality systems, deployer duties, post-market monitoring and serious-incident reporting for systems in scope.[13] Legal classification and notification are handled by qualified roles; the control plane ensures the evidence and authority path exists.

ISO/IEC 42001 frames an AI management system using organisational governance and continual improvement.[14] Incident and change receipts become management-system evidence when they show decisions, learning, corrective action and controlled return or retirement.

End-of-life controlRetire the capability, its dependencies and its informal substitutes

Retirement begins with a reason and an owner. Persistent failure, changing regulation, weak economics, replacement, unacceptable concentration or an expired decision need can all trigger it. The owner identifies continuing obligations and chooses whether cases, outputs or explanations must remain accessible after execution stops.

A dependency map works inward and outward. Inward dependencies include models, prompts, tools, data, connectors, credentials, compute, vendor contracts and evaluation assets. Outward dependencies include scheduled jobs, downstream workflows, reports, caches, interfaces, alerts, training, user bookmarks and manual practices built around the service.

Retirement failure often occurs at the informal edge. The official interface closes, but users keep copied prompts, spreadsheets or cached output because no replacement meets their workflow. The owner observes migration, removes unsupported access, communicates the permitted route and investigates why workarounds remain. Enforcement without a usable alternative can drive use further from visibility.

Permissions and automation receive positive removal proof. Credentials are revoked; jobs and queues are disabled; webhooks and connectors are removed; model and data access are closed; cost centres stop receiving usage; alerts move to the replacement or close. A scan after the planned end date looks for residual calls and shadow paths.

Evidence preservation is selective and governed. The retirement receipt names the record custodian, lawful purpose, retention, access and deletion schedule for change passports, evaluations, incident records, affected-case evidence and approvals. Keeping everything indefinitely is not a control, while deleting the operating history can make later investigation impossible.

NIST’s Generative AI Profile includes lifecycle risk-management considerations for generative systems.[3] Generated artefacts make retirement particularly difficult because copies can remain outside the service. The dependency map therefore covers stored outputs, embedded content, reusable prompt assets and user routes as well as the deployed model.

Financial and service closure follows technical removal. The owner terminates or narrows vendor commitments, confirms residual obligations, closes support, updates the service catalogue and measures whether the replacement produces acceptable outcomes. Retirement is complete when no unsupported decision path remains, not when the final deployment job succeeds.

Worked incidentDegrade a lending service when document provenance disappears

A lending preparation service retrieves documents and generates an evidence summary for underwriters. Service latency and availability are normal. A data-quality monitor detects that some retrieved passages lack source identifiers after a corpus connector change.

The alert enters observed state because provenance loss could make a consequential recommendation unreviewable. The transition record identifies the connector version, lending population, first detection time, confidence, owner and a two-hour investigation expiry. No one retrains or rolls back reflexively.

Investigation confirms the defect affects recent income-document retrieval across two products. The service moves to degraded state. It returns retrieved documents and highlights missing provenance, but withholds the generated recommendation. Underwriters use the tested evidence-only workflow for cases within its capacity; excess cases pause.

The product owner controls workflow mode and customer consequence. The platform lead isolates the connector and preserves retrieval logs. Data specialists repair the source contract. Risk reviews whether the affected population and evidence gap exceed tolerance. The incident commander joins these actions and communications.

Stable identifiers locate decisions produced since the faulty connector version entered service. Cases with complete evidence are documented and cleared. Cases with missing lineage receive re-review before further action. Where a decision already changed customer state, remediation corrects the record and activates appropriate communication.

The change passport for the repaired connector states schema, intended effect, compatibility, provenance conformance, representative lending cases, rollback, staged release and outcome observation. Offline tests include the original failure and corpus variation. Passing them authorises recovered state, not immediate normal operation.

A bounded production window begins with one product and limited traffic. Operators inspect provenance completeness, retrieval composition, underwriter workflow, fallback queue and decision corrections. Exit criteria require no recurrence, representative coverage, completed case review and acceptable service and workflow evidence.

At the end of the window, the owner chooses return or retirement. If the connector proves reliable and affected cases are reconciled, the service returns to normal with the passport and incident learning attached. If source contracts remain unstable, the connector retires and the evidence-only route becomes the supported path until a replacement qualifies.

This worked case also exposes drift noise. Had a corpus distribution alert fired without provenance, recommendation, workflow or outcome effect, the state could remain observed until expiry and then return to normal with evidence. The control plane rewards material investigation rather than alert volume.

Retirement is complete only after scheduled synchronisation, connector credentials, cached indexes, prompts referring to the source, dashboards, documentation and user workarounds are removed or redirected. Required incident and decision records remain under retention control. Closing the user interface alone would leave an active dependency.

The final retirement review compares the dependency map with live evidence. It samples access logs, scheduled work, support contacts, expense, stored assets and user behaviour after closure. Any residual path receives an owner and deadline. Finance confirms commitments have ended, records staff confirm preservation, and the product owner signs that no unsupported decision route remains. This post-closure proof distinguishes a retired capability from an abandoned one.

Decision instrumentChoose a run state from evidence and consequence

The AI Run-State Console turns a live signal into one of five operational decisions. It does not score maturity or automatically retrain. Enter the decision service, version, population, four evidence streams, consequence, authority, safe mode, affected cases, change, recovery and retirement facts.

Run it at signal triage, incident transitions, change approval, recovery review and retirement. The output names the operational decision, owner and required evidence. The state receipt remains attached to the incident or change record in the existing enterprise process.

ConclusionReturn through evidence or close every path

Running AI means operating a decision service and its versioned context. Endpoint health remains vital, but behaviour and consequence can move through data, retrieval, prompts, tools, policy, people, workflow and vendors while the endpoint stays green.

The six states stop ambiguous instructions such as monitor, limit, rollback and close from carrying too much meaning. The four evidence streams lead severity back to affected decisions. The change passport makes every behaviour-bearing surface visible. Incident authority joins platform, domain and risk roles without duplicating the enterprise command spine.

Recovery is a production claim supported by representative evidence, repaired cases and an observation window. Retirement is a dependency-removal claim supported by closed permissions, jobs, routes and workarounds plus preserved records. Neither is a colour on a dashboard.

The decisive question is not whether the model is running. It is whether the named decision population is receiving an acceptable service, whether weak signals can change the operating mode, whether cases can be found and repaired, and whether the organisation can return under evidence or retire completely. That is the discipline required to run AI.

Good operations make uncertainty actionable without making every alert an emergency. They preserve calm investigation, decisive containment, accountable repair and a clean end when evidence no longer supports return.

Source trailReferences

1. NIST (2023), AI Risk Management Framework Core. Official resource.
2. NIST (2023), AI RMF Playbook. Official resource.
3. NIST (2024), Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. DOI.
4. Beyer, B. et al. (eds.) (2016), ‘Managing incidents’, Site Reliability Engineering, Google. Online chapter.
5. Murphy, N. R. et al. (eds.) (2018), ‘Incident response’, The Site Reliability Workbook, Google. Online chapter.
6. Beyer, B. et al. (eds.) (2016), ‘Service level objectives’, Site Reliability Engineering, Google. Online chapter.
7. Beyer, B. et al. (eds.) (2016), Site Reliability Engineering, Google. Online book.
8. Sculley, D. et al. (2015), ‘Hidden technical debt in machine learning systems’, Advances in Neural Information Processing Systems 28. Google Research record.
9. Breck, E. et al. (2017), ‘The ML Test Score: A rubric for ML production readiness and technical debt reduction’, IEEE Big Data. Google Research record.
10. Breck, E. et al. (2019), ‘Data validation for machine learning’, Proceedings of MLSys. Google Research record.
11. Board of Governors of the Federal Reserve System, OCC and FDIC (2026), Revised Guidance on Model Risk Management, SR 26-2. Official guidance.
12. Basel Committee on Banking Supervision (2021), Principles for operational resilience. Official publication.
13. European Union (2024), Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence. Official text.
14. ISO/IEC (2023), ISO/IEC 42001:2023, Information technology: Artificial intelligence: Management system. Standard record.
15. Woods, D. D. (2015), ‘Four concepts for resilience and the implications for the future of resilience engineering’, Reliability Engineering & System Safety, 141, 5–9. DOI.