Rajesh Mahapatra · Applied AI strategyProcess reinvention

Retiring the Old Process After AI Arrives

A service-level exit architecture for ending legacy work only after every obligation, control, exception, record and recovery route has a proven future, and every obsolete live path can no longer take new work.

TLDR

  1. A process is not retired when the AI tool launches; it is retired when a defined service obligation leaves one authorised route and no unsupported case is stranded.
  2. Dual running is a bounded evidence protocol with one authoritative decision, a fixed review date and an exit question, not a permanent comfort blanket.
  3. Map hidden controls, tacit work, records, appeals, accessibility and recovery before removing the old route or copying its steps.
  4. Fallback must name its population, trigger, people, data, access, capacity, exercise and reintegration, or it is only a promise.
  5. Closure requires proof that access, queues, contracts, records, costs and obsolete targets are resolved, with reauthorisation for material change.

The new process that never became primary

A customer-service team launches AI guidance and reports near-universal adoption. Yet every agent still copies the answer into a personal spreadsheet, sends difficult cases through an old email approval and records the final decision in the legacy application. The new route creates advice; the old process still carries authority, evidence and recovery. Cost has doubled, records disagree, and managers can choose whichever route supports the easier story.

Closing the old application tomorrow would be reckless. The email path may contain an unnamed escalation, the spreadsheet may preserve language support, and nobody has rehearsed service during model failure. Keeping everything indefinitely is also a decision: duplicate work, divided accountability and dormant attack surface become permanent. Retirement must therefore be authorised at the level of the service obligation, not celebrated at the level of the launch.

Home · Writing · Research Essays

Research Essays

Retiring the Old Process After AI Arrives

Rajesh Ranjan Mahapatra

A service-level exit architecture for retiring legacy processes without permanent dual running, premature cutover or stranded obligations.

Start reading
Research EssaysEssay

© 2026 Rajesh Ranjan Mahapatra. 21 min read

Retiring the Old Process After AI ArrivesAll Research Essays

01 · What retirement actually removesRetire a service obligation, not a system label

The unit of retirement is a service obligation for a defined case population, consequence and operating condition. A licence, form or application is only one place that obligation may reside.

An obligation can include a decision, response time, authority check, explanation, appeal, accessible channel, record, reconciliation, control or remedy. It may be performed through software, local judgement, a vendor call, a mailbox or an informal handoff. A launch plan usually names the visible steps. Retirement proof must find the services that were never written down yet keep real cases moving.

This changes the executive question. “Is the new tool adopted?” becomes “For which population and condition does the new route now deliver every authorised service, and what evidence allows the former route to change state?” Average model performance cannot answer it. Neither can one calm month. Rare contraindications, peak volume, inaccessible interfaces, disputed cases, outages and downstream recovery may carry the obligations that determine whether closure is safe.

Two process tracks resolve into one primary route Old and new tracks duplicate work and produce conflicting records before converging into one primary route with a bounded exception branch. Parallel work must end in an explicit state OLD ROUTE NEW ROUTE DUPLICATION two records two reviews route shopping split authority PRIMARY bounded exception OLD ENTRY CLOSES
Figure 1. Illustrative transition. The destination is one authorised primary service plus any justified, bounded exception route, not two ordinary processes.

Thought experiment: perfect average, missing appeal

The new route is faster and more accurate on ordinary cases. One affected group cannot obtain an explanation or appeal. If the old route closes, average performance improves while a required service disappears. The missing obligation blocks retirement until it is transferred, redesigned with authority or formally ended through a legitimate decision.

Negative control: the step that should end

An old approval merely repeats an automated eligibility check and never changes action. Its control objective is now met earlier with stronger evidence. Preserving the click adds no protection. Retirement should remove the activity, document why the objective remains covered and withdraw the obsolete target and training.

Retirement is not the reverse of deployment. Deployment proves that a route can operate. Retirement proves that necessary services have a future, unnecessary activity may stop, records remain authoritative, recovery works and the old route cannot return through habit. That proof spans business, risk, records, security, workforce, vendor and affected-party concerns. A technical shutdown without these decisions can hide rather than resolve the process.

02 · Original synthesisThe Process Exit Architecture

Nine layers connect the case population to authorised closure. A route can pass model tests and still fail retirement because one control, population, record or fallback remains unresolved.

The first two layers establish who is served and what must be delivered. Work, authority and controls show how commitments are made and evidenced. Exceptions, people and dependencies test non-ordinary conditions. Process state names what the old route may still do. Closure and reauthorisation make the state temporary until the evidence permits a final end.

Process Exit Architecture Nine linked chambers carry cases through population, obligations, authority, controls, exceptions, people, dependencies, state and closure. Nine chambers between launch and exit CASE POPULATION SERVICE OBLIGATIONS WORK & AUTHORITY CONTROLS & EVIDENCE EXCEPTION & RECOVERY PEOPLE & CAPABILITY TECH & DEPENDENCIES PROCESS STATE CLOSURE & REAUTHORISE Material change reopens the whole service-level decision
Figure 2. This article's synthesis. Closure loops back because changed volume, law, staffing, population or recovery needs can invalidate a process state.
Layer Old-route question New-route proof Possible state Owner Closure condition
Case population Who still enters and why? Ordinary, rare, peak and affected populations covered Primary or exception-only Service owner No unnamed exclusion
Service obligation Which outcome or right resides here? Service, explanation, appeal and remedy demonstrated Transfer or redesign Business owner Authorised future named
Work and authority Who decides, acts and hands off? Decision and action rights work in practice Parallel evidence Process owner One governing route
Controls and evidence Which risk and record are covered? Objective, residual risk and proof accepted Archive or prohibit Risk and records Continuity gate signed
Exceptions and recovery What happens off the happy path? Named routes tested Warm or cold fallback Operations Entry and return work
People and capability Which tacit work or skill remains? Roles, burden, competence and voice addressed Retain or transition Workforce owner Capability observed
Technology and dependencies What still calls or funds it? Interfaces, vendors and consumers resolved Archive or decommission Technology owner No live hidden dependency
Process state What may the route do now? Entry, capacity, evidence, cost and expiry explicit One of eight states State owner Next decision dated
Closure and reauthorisation Can work or habit revive it? Access, cost, record and monitoring receipts Decommissioned Executive sponsor Proof set complete

The supporting Legacy Process Exit Contract names the service and population; retirement sponsor; old and new authoritative routes; obligations; authority, control and record transfer; permitted coexistence purpose and fixed review date; exception or fallback entry; staff, data, access and tooling; reactivation and return conditions; communications; contract and asset disposition; dual-operation cost; and expiry, closure proof and reauthorisation. It must state what will stop. “Retained for comfort” is not a process state.

03 · Find the process that is actually runningMap replaced, duplicated, split and missing work

The Process Coexistence Map compares every activity, decision, control, record and service obligation across old and AI-enabled routes. It reveals shadow work that a pre-launch diagram cannot show.

For each item, record old and new location and owner; whether it is replaced, redesigned, duplicated, split, missing or legitimately ended; the authority for change; case population and operating condition; authoritative record and reconciliation rule; entry and exit rule; capacity and skill; downstream consumer; affected party; and closure evidence. Observe representative work and inspect records. Speak with operators, exception handlers, control teams, support staff and affected users. Declared procedure, system trace and enacted work are evidence sources, not interchangeable truths.

A copied step is not necessarily preserved control. An email approval may contain segregation of duties, or it may be an obsolete habit. Test the control objective and service obligation. If the new process eliminates the underlying risk, authorise the end of the old activity. If the objective remains, prove its new placement, evidence and owner. This avoids both mechanical duplication and accidental removal.

Process Coexistence Map Old and new work tiles are classified as replaced, redesigned, duplicated, split, missing or ended, with missing obligations highlighted. A launch diagram is a hypothesis; coexistence is observed OLD ROUTE NEW ROUTE approval record recovery decision record exception REPLACED REDESIGNED DUPLICATED SPLIT MISSING FORMALLY ENDED Every classification needs authority, affected population, record rule and closure evidence
Figure 3. This article's synthesis. The map classifies obligation movement rather than assuming every old step should be copied or discarded.

Thought experiment: delete the email approval

An invoice team removes an email approval because the AI-enabled flow checks policy automatically. During observation, the approval turns out to separate request and payment authority for a small supplier class. The new route validates policy but does not preserve segregation. The retirement claim fails for that population. The organisation can redesign the control inside the new workflow rather than keep every email, but it cannot erase the objective by calling the message inefficient.

04 · Stop calling everything availableAssign one of eight explicit process states

The Process State Register gives the old route an intelligible purpose, entry rule, capacity, evidence, cost, expiry and next decision. “Available” says none of these things.

Primary is authorised for ordinary live work and holds the governing record. Parallel evidence sends a bounded representative sample through both routes while one rule prevents conflicting live outcomes. Exception-only serves named cases the new route cannot yet cover. Warm fallback retains current people, data and tools for a defined disruption and is exercised. Cold recovery preserves artefacts with stated reactivation lead time. Archive permits governed record access but no new work. Prohibited blocks use because the route creates unacceptable conflict or unsupported outcomes. Decommissioned closes live access, integrations, queues, credentials, contracts and duties while governing retained records separately.

Process State Register A route moves across eight explicit states from primary through evidence, exceptions, fallback and archive to prohibited or decommissioned. Every surviving route needs a named operating state PRIMARY PARALLEL EVIDENCE EXCEPTION ONLY WARM FALLBACK COLD RECOVERY ARCHIVE PROHIBITED DECOM- MISSIONED evidence can narrow the authorised route failed proof can restore or reverse state
Figure 4. State change is reversible while evidence remains incomplete. Archive and decommissioned are different because retained records need not keep a live work route.
State Permitted work Entry rule Capacity and record Exercise or evidence Cost Expiry Next decision
Primary Ordinary live cases Authorised population Full capacity; authoritative record Outcome monitoring Operating cost Review date Retain, narrow or replace
Parallel evidence Representative comparison only Fixed protocol Bounded duplicate capacity; one governing outcome Adjudicated differences Explicit dual cost Short fixed window Promote, extend or reverse
Exception-only Named unsupported cases Case criteria Reserved skill; linked record Coverage repair evidence Priced exception service Repair deadline Close or retain narrowly
Warm fallback Disruption service Declared incident Ready people and current data Observed exercises Maintenance and exercise Continuity review Renew or redesign
Cold recovery No routine cases Executive reactivation Lead time; restored record Artefact verification Storage and refresh Retention review Warm, archive or close
Archive Record access only Governed request No live capacity; retained evidence Retrieval test Retention cost Disposition date Delete or extend lawfully
Prohibited No new or recovered work Risk decision Entry blocked Revival detection Containment Until reauthorised Repair or decommission
Decommissioned None Proof set complete Live paths removed; records separate Closure receipts Residual archive only Final or legal hold Monitor unauthorised revival

A state is assigned to a route for a case population and condition, not to an application in the abstract. The same old process can be prohibited for ordinary work, exception-only for a rare population and archived for historical records. State ownership prevents the label “fallback” from concealing ordinary use.

05 · Comparison with an exit questionUse dual running as a test, not an operating habit

The Dual-Run Evidence Protocol begins with the retirement claim and ends when comparison no longer changes the decision. It never permits two conflicting live outcomes.

Define the question before selecting a sample. Establish population, exclusions, volume, seasonality and consequence tiers. Include ordinary, peak, rare, adversarial, accessibility, appeal, incident and recovery cases. Name one authoritative record and one decision rule while both routes run. Compare service, quality, safety, evidence, burden, cost, delay, rework, distribution and affected-party consequence. Adjudicate differences by model, data, workflow, authority, control, skill, interface, dependency or an old-process defect. Test failed dependencies and controlled reactivation. Record missing evidence and plausible rivals. Stop when the decision value is exhausted.

The old output is not automatically ground truth. A legacy route can contain known and unknown defects. The new route can be better overall yet fail an essential tail. Comparison should ask why outcomes diverge and which obligation each route meets, not reward similarity. Where running both routes creates unacceptable workload, inconsistent decisions or harm, use shadow evidence, synthetic cases, historical replay or staged cohorts instead.

Dual-Run Evidence Protocol Representative cases feed old and new comparison rails while one authoritative decision rail prevents conflicting outcomes and an adjudicator classifies differences. Compare two routes; issue one governing result REPRESENTATIVE CASE SET OLD ROUTE NEW ROUTE DIFFERENCE ADJUDICATION BY CAUSE ONE OUTCOME service · safety · evidence · burden · cost · distribution · recovery A fixed review date forces the next process-state decision
Figure 5. This article's synthesis. Parallel evidence protects comparison without allowing two live answers to reach the affected party.

Thought experiment: the calm-month proof

A new invoice route succeeds for four quiet weeks. Leaders close the old process before quarter-end volume. At peak, a downstream reconciliation queue fails and the former team no longer has access to recover it. The calm month tested ordinary operation, not the retirement claim. A valid protocol would have represented peak demand, in-flight records, failed dependency and reactivation before closing capacity.

Goh, Gao and Agarwal's longitudinal healthcare study describes technology and routines as co-evolving rather than changing at installation. Edmondson, Bohmer and Pisano found markedly different implementation processes across sixteen hospitals introducing a new surgical technology. These settings do not prove a universal retirement formula, but they support observing enacted routines, trials and reflection before assuming that a formal design has displaced old work.

06 · The work the old route still performsFind stranded obligations before they become incidents

The Stranded Obligation Test asks whether the old process contains a necessary service that is absent, weaker or ownerless in the new route.

Inspect identity, eligibility and authority checks; segregation and independent review; explanation, notice, consent, appeal and remedy; accessibility, language and assisted service; reconciliation and record retention; exception classification and escalation; professional judgement and local context; downstream notification; incident containment and manual recovery; workforce consultation and protected reporting; vendor duties and data disposition; and the action that captures promised value. For each finding choose transfer, redesign, formally end, bounded retain or block retirement.

Do not preserve an activity merely because it existed. A weak legacy approval can be removed if the objective no longer applies or has a stronger replacement. Conversely, do not assume that a replacement screen carries every service performed through conversation, tacit work or locally maintained records. The test follows the obligation to its affected population and evidence.

Stranded Obligation Test A scanning beam illuminates hidden approval, appeal, record, accessibility, tacit skill and recovery obligations inside an old process. The old process may contain services the map never named OLD ROUTE APPROVAL APPEAL RECORD ACCESSIBLE SERVICE TACIT SKILL RECOVER transfer · redesign · formally end · bounded retain · block
Figure 6. This article's synthesis. The scanner looks for service obligations, not reasons to preserve the legacy interface unchanged.
Hidden service Affected population Evidence Authorised treatment Authority Owner Retirement effect
Segregation check High-value suppliers Approval history and control objective Redesign in new route Risk acceptance Finance control Block until tested
Explanation and appeal Rejected applicants Notices, complaints and remedies Transfer service Policy and legal Service owner Reverse cutover if absent
Accessible channel Language or access cohort Completion and assisted-service observation Bounded retain while repairing Service standard Accessibility owner Exception-only state
Authoritative record All in-flight cases Completeness and reconciliation Migrate and archive Records policy Records owner No closure before receipt
Tacit exception judgement Rare consequential cases Observed cases and expert rationale Transfer capability Professional owner Workforce lead Retain skilled route temporarily
Obsolete duplicate click No distinct population Never changes action or evidence Formally end Control owner Process owner Remove immediately

The Control and Record Continuity Gate pairs every old control objective, risk, owner, evidence and frequency with the proposed new treatment. It records changes to prevention, detection, correction and compensation; segregation, access and override; authoritative records and in-flight reconciliation; retention, legal hold, archive, migration and deletion; case traceability; independent tests and defects; residual risk acceptance; and closure proof. Control equivalence does not require identical steps. It requires explicit treatment of the objective and consequence.

07 · Recovery that can actually runDesign the smallest viable fallback

A fallback is an operating service with an entry condition and return path. A document, dormant login or departed expert is not fallback capability.

The Fallback Viability Contract names the disruption; activation authority and communication; population and priority; warm or cold state and recovery time; people, roles and minimum staffing; skill exercise and observed competence; data currency and authoritative record; tools, credentials, vendor support and infrastructure; capacity, duration and degraded-service limit; control, evidence, privacy and security boundary; reintegration; exercise cadence and repair; cost, expiry and next retirement review.

Retaining the entire legacy process can be less resilient than creating a smaller recovery route. A full duplicate gathers stale integrations, unclear ownership and conflicting records. A bounded fallback might preserve critical service for high-consequence cases at reduced volume, with current data and exercised operators. NIST contingency guidance stresses analysis, roles, recovery priorities and testing in the federal information-system context. ISO 22301:2019 remains published with a later edition under development. These sources support disciplined continuity, not the claim that any particular fallback design is sufficient.

Fallback Viability Circuit People, data, credentials, capacity, controls and reintegration form a recovery circuit that must close under a timed exercise. A fallback exists only when the circuit closes PEOPLE DATA ACCESS CAPACITY CONTROL REINTEGRATE TIMED EXERCISE Entry, degraded service and return to the new authoritative record are observed
Figure 7. This article's synthesis. The recovery circuit fails if any essential element is stale, unavailable or ownerless.
Trigger Readiness Activation Degraded service Reintegration Access closure Record disposition Proof
Model unavailable Warm staff, current data Incident commander Priority cases at capped volume Reconcile manual cases Fallback rights expire New record remains authoritative Timed exercise
Rare contraindication Specialist rota and guidance Named clinical authority Exception-only case Linked disposition No ordinary entry Trace both routes Representative rare-case review
Platform outage Tools, credentials, supplier contacts Continuity owner Minimum service promise Backlog and version check Revoke incident access In-flight reconciliation Peak exercise
Decommission old route All obligations transferred Executive closure owner None after closure Not applicable Queues, accounts and interfaces revoked Retain, migrate or delete lawfully Signed close-out report

The Retirement Cost and Benefit Ledger keeps new-process operating cost separate from residual people, licence, vendor and infrastructure cost; reconciliation; shadow work; duplicate assurance; fallback maintenance; migration and archive work; released capacity and whether it was captured; risk changes; worker and customer burden; delayed benefit; and recovery reserve. A business case is not complete while old work, access and expense remain unpriced inside the operating system.

08 · Worked state decisionsTen cases that separate retirement from abandonment

Each case names the service population, hidden obligation, authorised state and closure evidence. Together they include full retirement, bounded fallback, exception-only service, extended evidence and reversal.

1. Spreadsheets after service launch

Population: ordinary customer contacts. Finding: personal sheets preserve answer fragments and an old mailbox carries difficult approvals. State: map the shadow route, repair missing service, prohibit new ordinary entry and migrate required records. Closure: spreadsheets and mailbox no longer accept work; outcome and appeal remain available.

2. Two credit records

Population: bank credit files during comparison. Finding: legacy memo and AI evidence pack create duplicated review and conflicting records. State: parallel evidence with one governing decision and adjudicated differences. Closure: control and record continuity pass, in-flight cases reconcile, and the memo becomes archive rather than a second truth.

3. Rare clinical contraindication

Population: cases outside ordinary model coverage. Finding: the new route lacks specialist handling. State: retain a named exception-only service with current authority and record linkage. Closure: do not force full retirement until representative rare cases pass, while ordinary work cannot enter the exception route.

4. The hidden finance control

Population: higher-value supplier payments. Finding: an email approval quietly enforces segregation of duties. State: block retirement for that population, redesign the control in the new route and independently test evidence. Closure: the control objective and residual risk are signed, then the email path is prohibited.

5. Warm outage service

Population: critical cases during platform failure. Finding: the manual procedure exists but credentials and data are stale. State: repair and exercise a warm fallback with minimum staffing, priorities and reintegration. Closure: the full legacy workflow can end once the smaller recovery circuit passes at realistic duration.

6. Faster service without appeal

Population: users receiving adverse outcomes. Finding: the new interface offers neither explanation nor a working challenge. State: reverse the cutover for the affected service, restore continuity and repair the new route. Closure: affected users can exercise notice, appeal and remedy before the old channel ends.

7. Excluded night and language users

Population: night-shift, multilingual and accessibility cohorts. Finding: the enterprise average hides failure to complete the new path. State: bounded exception-only service with named entry and deadline. Closure: each cohort demonstrates service under real conditions; worker and affected-user evidence informs the decision.

8. Contract and interface tail

Population: downstream partner cases. Finding: an old interface remains consumed and the vendor contract is nearing automatic renewal. State: sequence dependency cutover, data return and contract exit rather than leave the entire process live. Closure: partner acceptance, stopped feeds, revoked credentials and commercial receipts agree.

9. Manual skill has decayed

Population: recovery cases after prolonged automation. Finding: the listed operators cannot restore service during an exercise. State: fallback viability fails; redesign the recovery route and rebuild bounded competence. Closure: observed recovery, not course completion, supports the next state. The current fallback cannot be removed prematurely.

10. Small business, short evidence window

Population: a limited but varied monthly caseload. Finding: a long parallel run costs more than the process. State: use representative ordinary, exception and recovery cases, a one-page exit contract and one tested manual procedure. Closure: duplicate tools close quickly while a proportionate external adviser challenges the evidence.

Strongest rival: keeping the old process can be rational

Retention can preserve service during model failure, serve populations the new path cannot cover, maintain recovery skill, meet record duties and limit vendor dependence. AI behaviour can change after deployment. A hard cutover may destroy the ability to recover. In a small organisation, elaborate state machinery can cost more than the work it protects.

The answer is explicit state rather than automatic retirement. Keep exception-only or fallback service when consequence and evidence justify it, but bind population, entry, capacity, cost, exercise and expiry. Design recovery around minimum service instead of preserving an entire duplicate workflow by habit. Use a one-page contract where scale is small. Complexity should follow consequence. The rival becomes a reason to specify retention, not a licence for indefinite coexistence.

Failure boundary. Do not retire while a necessary obligation is missing, one authoritative record is absent, affected populations cannot obtain service or remedy, fallback depends on stale people or access, or an uncontrolled dependency remains. Do not retain ordinary dual operation where two routes can issue conflicting outcomes, route shopping is possible or the comparison has no fixed question and expiry.

09 · Executable instrumentThe Old-Process Retirement Designer

The designer converts a retirement proposal into one of five process-state decisions. It does not produce a readiness percentage. Its output is a draft docket showing which proof changes the authorised state.

Define the service and population, then identify the old and new authoritative routes. Test obligations, representative evidence, stranded controls, records, fallback, people, dependencies, cost and closure. Scenario buttons exercise full retirement, bounded fallback, exception-only continuation, an extended evidence window and reversal. A favourable result permits accountable owners to complete the docket and closure proof; it does not replace legal, safety, records or affected-party review.

Old-Process Retirement Designer Obligations, evidence, state, fallback, owners and closure feed an exit docket with five live routes. Evidence enters; a process-state decision leaves OBLIGATION EVIDENCE STATE FALLBACK OWNERS CLOSURE RETIREMENT DOCKET RETIRE FALLBACK EXCEPTION EXTEND REVERSE
Figure 8. This article's executable synthesis. The result names a state and proof obligation, never a composite score.

Decommission Proof

Retirement is complete when, as applicable, no ordinary case can enter the old route; old queues, forms, mailboxes, macros and local stores are closed or archived; identities, credentials and integrations are revoked; in-flight cases reconcile; retention, legal hold, migration and deletion are verified; obsolete controls, dashboards, targets, procedures and training are withdrawn; licences, vendor support and data return are resolved; fallback and exception routes match their authorised states; workers, downstream teams and affected users know the route; cost and capacity release are evidenced; closure owners sign; and monitoring can detect unauthorised revival.

The Process Retirement Docket records the retirement claim, population and obligations; coexistence map and state register; dual-run design and differences; stranded-obligation treatment; control and record continuity; fallback and recovery proof; workforce effects and voice; dependencies and contracts; affected-party continuity; cost and residual risk; interim protection and deadlines; and the final proof set. Reauthorise after material change to the model, data, population, service, consequence, workflow, authority, control, record, staffing, skill, volume, dependency, vendor, law or recovery need, and after failed fallback, shadow revival, unreconciled records, incident or appeal failure.

Rehearse closure before removing access. Give a representative ordinary case, an in-flight case, a disputed record and a recovery event to the teams that will operate after cutover. Ask them to complete service without the old queue, mailbox, spreadsheet or expert shortcut. Trace every failed handoff to an obligation, dependency, authority or capability gap. This rehearsal can delay closure, narrow the retiring population or change the fallback state. After access is removed, watch process-level entry points and record flows for attempted revival. Detect the return of shadow work without turning the check into employee surveillance.

10 · The closure decisionThe old route ends when its necessary services have a future

A launch proves that a new process can begin. Retirement proves that the former process may stop.

Executives should ask for the service obligation and affected population, not a percentage labelled adoption. They should inspect what is replaced, redesigned, split, missing and ended; the one governing record during comparison; the state and expiry of every surviving route; the observed fallback exercise; and the receipts that make obsolete work incapable of accepting a new case.

The Process Exit Architecture avoids two symmetric mistakes. Premature cutover strands service, control, records and recovery. Permanent dual running preserves cost, ambiguity and shadow authority. Both mistakes arise when transition is treated as an atmosphere rather than a state decision with entry, capacity, evidence and exit.

Retire only when every necessary obligation has an authorised and tested future, every justified remnant has a bounded state, and every unnecessary live route can no longer be used. If that proof is absent, extend evidence, retain a narrow exception, build a viable fallback or reverse the cutover. If it is present, close the old process completely enough that habit cannot quietly bring it back.

Evidence and limitsPrimary and empirical sources

Sources were checked on 3 September 2026. NIST AI RMF 1.0 is the operative cited version and NIST reports a revision in progress. NIST SP 800-34 Rev. 1 is scoped to US federal information systems. ISO 22301:2019 remains published while a later edition is under development. UK, US and EU sources retain their jurisdictional scope. Workplace, healthcare, automation and implementation research is used within the populations and designs studied.

  1. National Institute of Standards and Technology. AI Risk Management Framework Core, version 1.0.
  2. UK Government. Artificial Intelligence Playbook for the UK Government.
  3. US Government Accountability Office. Artificial Intelligence: An Accountability Framework, GAO-21-519SP.
  4. UK Government Service Manual. Moving Away from Legacy Systems.
  5. UK Government Security. Retiring Service Components Securely.
  6. National Institute of Standards and Technology. Contingency Planning Guide for Federal Information Systems, SP 800-34 Rev. 1.
  7. International Organization for Standardization. ISO 22301:2019 Security and Resilience.
  8. Organisation for Economic Co-operation and Development. The Impact of AI on the Workplace.
  9. International Labour Organization. Global Case Studies of Social Dialogue on AI and Algorithmic Management.
  10. European Union. Regulation (EU) 2024/1689.
  11. Goh, J., Gao, G. and Agarwal, R. Evolving Work Routines. Information Systems Research, 2011.
  12. Edmondson, A., Bohmer, R. and Pisano, G. Disrupted Routines. Administrative Science Quarterly, 2001.
  13. Endsley, M. and Kiris, E. The Out-of-the-Loop Performance Problem and Level of Control in Automation. Human Factors, 1995.
  14. Bainbridge, L. Ironies of Automation. Automatica, 1983.
  15. Parasuraman, R. and Riley, V. Humans and Automation: Use, Misuse, Disuse, Abuse. Human Factors, 1997.
  16. Goodhue, D. and Thompson, R. Task-Technology Fit and Individual Performance. MIS Quarterly, 1995.
  17. Klein, K. and Sorra, J. The Challenge of Innovation Implementation. Academy of Management Review, 1996.
  18. May, C. and Finch, T. Implementing, Embedding, and Integrating Practices. Sociology, 2009.