Sunset stage

Summary of the Sunset Stage

The Sunset stage is the formally governed retirement of an AI capability from production. It is a distinct, final lifecycle stage after Operate, focused on preserving evidence, auditability, and institutional learning rather than simply turning a tool off.

Purpose and Rationale

By the time an AI capability reaches Sunset, it has typically accumulated:

• Large volumes of outputs embedded in matters, submissions, or training data
• AI Council decisions, Risk Register entries, and incident/post-incident records
• Materiality calibrations and control configurations that shaped downstream workflows
• Procurement, vendor, and operational dependencies

A structured Sunset ensures this history is preserved and reconstructable. Unstructured retirement (silent deletion, account suspension, quiet deprovisioning) destroys the evidentiary basis for understanding how the capability operated and how decisions were made.

Canonical Sunset Triggers (from GOV-01)

Sunset is initiated when one or more of the following documented triggers occur, each with an owner and evidence trail:

1. Terminal drift – The capability cannot be kept within tolerance and remediation is uneconomic.
2. Replacement – A successor capability is approved and a transition plan exists.
3. Use case sunset – The underlying workflow is retired or restructured so the capability is no longer needed.
4. Materiality change – The capability falls outside the risk appetite in the Charter and no acceptable mitigation is available.
5. Regulatory or doctrinal change – New methodology, regulator guidance, or institutional position requires retirement.

Canonical Sunset Artefacts

A defensible Sunset produces a specific artefact set:

• Sunset Decision Record – AI Council decision documenting the trigger, evidence considered, and effective date.
• Sunset Post-Mortem (input to DE-5) – Structured retrospective on what worked, what failed, and what the methodology should learn.
• Evidence Preservation Plan – How records will be retained and accessed (Risk Register entry, telemetry archive, AI Council Decision Log, etc.).
• Successor Mapping – For replacements, explicit mapping of capabilities, controls, and evidence into the successor.
• Stakeholder Notice – Communications to affected users, clients, and counterparties as required.

Sunset as a Defensibility Test

Sunset functions as a test of programme defensibility:

• It demonstrates that governance covers the entire lifecycle, not just intake and operation.
• A programme with several well-executed, well-documented Sunsets is materially more defensible than one with none.
• Sunset evidence feeds into STR-07 Annual Charter Refresh and Continuous Learning (DE-5), providing some of the most informative inputs on how the methodology performs over time.

A programme that does not generate Sunset evidence is effectively claiming lifecycle maturity that its artefacts do not substantiate.