COMPEL Certification Body of Knowledge — Module 1.2: The COMPEL Six-Stage Lifecycle
Article 28 of 28
AI systems are not permanent installations. They degrade, become obsolete, accrue technical debt, fail to deliver promised value, develop compliance exposures, or produce ethical outcomes that were acceptable when first deployed but are no longer acceptable given evolved organizational standards or societal expectations. Every AI system has a lifecycle that ends — in retirement, in fundamental redesign, or in replacement — and the governance of that ending is as important as the governance of the beginning.
Most organizations handle AI system retirement reactively, as a crisis response to a failure, a regulatory finding, or an executive decision made without systematic evaluation. This reactive pattern produces poor outcomes: systems are retired without adequate data disposition planning, without stakeholder communication, without knowledge capture, without clear handoffs to successor initiatives. The institutional knowledge embedded in a retired system — the lessons about what worked, what failed, and why — dissipates rather than feeding forward into the next initiative.
The Retirement and Redesign Decision Record is the governance instrument that makes AI system lifecycle endings as deliberate as their beginnings. It establishes the criteria by which retirement or redesign decisions are triggered, documents the evidence base for those decisions, defines the process by which systems are safely decommissioned, and captures the institutional knowledge that should survive the system's retirement. As the final mandatory artifact in the COMPEL system (TMPL-L-009), it closes the lifecycle loop and prepares the organization for the next cycle's fresh beginning.
Recognizing When Retirement or Redesign Is Appropriate
The most consequential governance decision embedded in the Retirement and Redesign Decision Record is recognizing when action is required. Organizations have strong institutional biases toward keeping existing systems running: sunk cost reasoning, stakeholder resistance to change, the operational disruption of transitions, and the difficulty of justifying retirement when the system is still functioning at some level. These biases must be explicitly countered by structured sunset criteria.
Sunset Criteria
The COMPEL framework defines four categories of sunset criteria, each of which may independently trigger a retirement or redesign consideration:
Value degradation. An AI system whose realized value falls persistently below the minimum acceptable threshold defined in the Value Thesis Register has ceased to justify its operational and governance costs. Value degradation may be absolute — the system never delivered projected outcomes — or relative, where the system delivered value initially but performance has declined as the model drifted, the use case context changed, or competing alternatives emerged. The ROI Analysis Report (TMPL-L-003) is the primary evidence source for value degradation triggers.
Risk profile evolution. An AI system that was deployed within the organization's Risk Appetite Statement (TMPL-C-005) may subsequently develop a risk profile that exceeds that appetite. Model drift that introduces bias where none previously existed, regulatory changes that reclassify the system as high-risk, or accumulated technical debt that undermines security controls are examples of risk profile evolution that may trigger retirement or redesign. The Control Performance Report (TMPL-E-006) and the Risk Acceptance Register (TMPL-E-003) are the primary evidence sources for risk profile triggers.
Operational unsustainability. An AI system that requires disproportionate operational resources to maintain — relative to its value contribution — may be a candidate for retirement. Operational unsustainability may arise from technical debt accumulation, vendor dependency on end-of-life components, talent scarcity in maintaining specialized systems, or governance overhead that has grown beyond the system's risk and value profile. This criterion should be applied carefully to avoid premature retirement of systems that are operationally complex but genuinely valuable.
Strategic misalignment. An AI system deployed under a prior strategic direction may become misaligned with the current AI Ambition Statement (TMPL-C-001) as organizational strategy evolves. Systems that were once central to the transformation agenda may become peripheral as priorities shift. Strategic misalignment does not necessarily require immediate retirement, but it does require deliberate governance attention to prevent the perpetuation of systems that are consuming governance capacity without contributing to current strategic objectives.
Retirement Versus Redesign
The Retirement and Redesign Decision Record must explicitly address whether the appropriate response to a sunset trigger is full retirement (decommissioning the system and withdrawing its functionality) or fundamental redesign (replacing the system's architecture, model, or governance design while preserving the use case). This is a consequential choice with different governance implications:
Retirement is appropriate when the use case itself is no longer viable, when the system's technical foundation is irreparable, when regulatory requirements preclude continued operation, or when the value case for redesign does not exceed the cost.
Redesign is appropriate when the use case remains valid, when the failure lies in the system's design rather than the underlying need, and when evidence suggests that a redesigned system would deliver acceptable performance. Redesign should not be chosen as a face-saving alternative to retirement when retirement is the appropriate governance conclusion; it should be chosen only when there is genuine evidence of a viable path to an improved system.
Replacement by third-party solution is a variant of redesign that substitutes a vendor-provided capability for the organization's own build. It may be appropriate when the capability domain has matured sufficiently that commercial solutions now outperform custom builds and when vendor risk assessments (TMPL-M-006) support the transition.
The Retirement Process
When retirement is the governance decision, the Retirement and Redesign Decision Record must specify a managed decommissioning process across five dimensions:
Data Disposition
Data disposition is frequently the most complex dimension of AI system retirement, and it is the one most likely to produce compliance exposures if handled reactively. The disposition plan must address:
Training data and model artifacts — the datasets used to train the system, the model weights, and the training infrastructure. These artifacts may be subject to data residency requirements, intellectual property protections, or contractual restrictions that govern how they can be stored, transferred, or destroyed. The retention requirements specified in the Artifact Lifecycle section of Article 14: Mandatory Artifacts and Evidence Management apply to training data and model artifacts alongside governance documents.
Inference data — the operational data that the AI system has processed during its deployment. This data is frequently subject to privacy regulations: GDPR's right to erasure, sector-specific data retention requirements, and litigation hold obligations may all be relevant. The disposition plan should be reviewed by the legal and compliance function before execution.
System-generated records — decisions made, outputs produced, recommendations generated. For AI systems that have informed consequential decisions, the records of those decisions may need to be retained for years beyond the system's retirement to support regulatory reporting, legal proceedings, or audit inquiries.
Audit artifacts — the complete set of governance artifacts produced during the system's lifecycle. These should be archived in the governance repository under the archival standards defined in Article 14, with clear labeling that identifies them as retired-system artifacts and ensures they remain retrievable for future reference.
Stakeholder Communication
Users, managers, dependent systems, and external stakeholders affected by the AI system's retirement should be notified through a structured communication plan that addresses:
What is being retired and why. Honest, specific communication about the retirement rationale — distinguishing honest acknowledgment of failure when relevant from strategic evolution when that is the case — builds organizational trust. Vague communications ("the system is being retired as part of our technology roadmap") when the actual reason is performance failure erode credibility when the true reason becomes known.
When retirement will occur and in what stages. A phased retirement timeline — with defined milestones for reduced functionality, final decommission, and data disposition — gives dependent parties time to adapt and reduces the operational disruption of abrupt withdrawal.
What users should do instead. Retirement communications that identify the alternative — a successor system, a manual process, an external service — are more useful than communications that simply announce removal. Users who receive no alternative will find their own, and the alternatives they find may create shadow governance risks.
Who to contact with questions or concerns. Named points of contact with specific responsibilities reduce the organizational confusion that major system changes generate.
Lessons Learned Capture
The institutional knowledge embedded in an AI system's lifecycle — the design decisions made and the reasoning behind them, the failures encountered and their root causes, the governance approaches that worked and those that did not — is among the most valuable outputs of the system's operation. This knowledge is at high risk of dissipation during retirement, as the practitioners closest to the system turn their attention to successor initiatives.
The lessons learned component of the Retirement and Redesign Decision Record should be structured to capture:
Technical lessons — what was learned about model performance, architecture choices, data requirements, monitoring approaches, and failure modes that should inform future system design.
Governance lessons — what was learned about control design, governance process effectiveness, reporting cadence, and oversight model calibration that should inform future governance architecture.
Adoption lessons — what was learned about user behavior, training effectiveness, change resistance, and adoption barriers that should inform future deployment approaches.
Value realization lessons — what was learned about value thesis accuracy, value measurement methodology, and the conditions that enabled or constrained value realization.
These lessons should be formatted for integration into the Knowledge Base (TMPL-L-005) and referenced in the Improvement Initiative Register (TMPL-L-004), ensuring that they feed forward into the next cycle's planning. Lessons that are documented but not integrated into future planning are lessons that were not actually learned.
Handoff to Next Cycle
For systems that are being retired and replaced — whether by a redesigned system or a successor initiative — the Retirement and Redesign Decision Record should specify the handoff governance:
Transition period management — how will the gap between retirement and replacement be governed? Users who rely on AI-assisted workflows that are retired before a replacement is available will either go without the capability or develop workarounds. Planned transition management — including manual process fallbacks, interim governance oversight, and explicit transition timelines — is more effective than organic adaptation.
Successor system seeding — what should the team designing the successor system know about the predecessor system's history? The lessons learned capture provides the knowledge base; the handoff process ensures that it is actually received and incorporated by the successor team.
Continuity of evidence chains — governance artifacts from the retired system's lifecycle may be relevant to the successor system's risk assessment, regulatory standing, and accountability documentation. The archival strategy should ensure that these artifacts remain accessible to the successor team.
The Redesign Process
When redesign is the governance decision, the Retirement and Redesign Decision Record transitions from a decommissioning instrument into a redesign mandate. The Record should specify:
Redesign scope and rationale — which aspects of the system are being redesigned and why. A redesign mandate that specifies only "improve the system" provides insufficient governance guidance; a mandate that specifies "replace the current model architecture with an approach that addresses the identified bias in demographic group X, with the revised system achieving bias metrics of Y as measured by Z methodology" provides actionable direction.
Governance reset requirements — which governance artifacts from the current system lifecycle can be carried forward into the redesigned system, and which must be reproduced from scratch. A fundamental model redesign may require new Data Readiness Reports, new bias assessments, and new Deployed System Records; a targeted fix to a specific control gap may require only updated Control Implementation Evidence.
Redesign governance pathway — which COMPEL stages must be completed for the redesigned system? A minor redesign affecting only technical implementation may be governed through an expedited pathway that skips stages already adequately addressed by existing artifacts; a fundamental redesign that changes the system's risk profile requires traversal of the full COMPEL cycle from the relevant entry stage forward.
Success criteria for the redesigned system — what outcomes must the redesigned system achieve to be considered a successful response to the retirement trigger? These criteria become the value thesis and risk management targets for the redesigned system's lifecycle.
Decision Documentation and Accountability
The Retirement and Redesign Decision Record must be documented with the same rigor as the Scaling Decision Record. Required content includes:
Triggering evidence — a summary of the sunset criteria assessments that triggered the retirement or redesign consideration, with references to the source artifacts.
Options analysis — a structured evaluation of the retirement, redesign, and replacement options considered, with the evidence base for each option's assessment.
Decision and rationale — the formal decision, the decision authority, the date, and a rationale that future reviewers can understand without access to institutional memory.
Process plan — for retirement decisions, a high-level summary of the disposition plan, communication plan, lessons learned capture plan, and transition management approach.
Redesign mandate — for redesign decisions, the specific redesign scope, governance requirements, and success criteria.
Dissenting views — documented where present, for the same reasons as in the Scaling Decision Record.
The decision authority for retirement and redesign decisions should be at least as senior as the authority that originally authorized the system's deployment. Systems that required Executive Sponsor authorization to deploy require at least the same authority to retire or fundamentally redesign.
Conclusion
The Retirement and Redesign Decision Record completes the COMPEL lifecycle. It closes the loop opened by the AI Ambition Statement, bringing each AI system's governance journey to a deliberate, documented, and knowledge-preserving conclusion — regardless of whether that conclusion is a proud graduation to a successor system or an honest acknowledgment that the system fell short of its promise.
Organizations that govern endings as rigorously as beginnings will find that their AI portfolios improve over time in ways that informal lifecycle management cannot produce. The lessons from retired systems inform the design of successor systems. The honest documentation of failures builds the institutional candor that accelerates learning. The careful handling of data disposition protects the organization from the compliance exposures that reactive decommissioning creates.
Every AI system, in its retirement, has one final contribution to make: the knowledge it has generated about how AI governance should be done better. The Retirement and Redesign Decision Record is the instrument that captures that contribution and ensures it persists.
This article is part of the COMPEL Certification Body of Knowledge, Module 1.2: The COMPEL Six-Stage Lifecycle. It is the final article in the mandatory artifacts series and should be read in conjunction with Article 27: Scaling Decision Records, which addresses the complementary decision to expand rather than retire an AI system. For the knowledge base integration that preserves retirement lessons across cycles, see the Learn stage treatment of the Knowledge Base Updates (TMPL-L-005). For the artifact archival requirements that govern the governance record of retired systems, see Article 14: Mandatory Artifacts and Evidence Management. For the Recalibration Trigger Report that synthesizes retirement and scaling decisions into cycle-level insights, see the Learn stage (TMPL-L-006).