> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aigoframework.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 13 AIGO Retirement Schema Documentation v0.1

# AIGO — Retirement Schema Documentation

## 1. Document Purpose

This document describes the machine-readable AIGO Retirement Schema.

The schema provides the structured representation of the controlled retirement of AI systems and associated governed components under the AIGO AI Governance Operating Framework.

It is intended to support:

* retirement identification;
* retirement triggers;
* retirement rationale;
* retirement scope;
* stakeholder impact;
* replacement and transition;
* business continuity;
* retirement risk assessment;
* residual risk;
* risk acceptance;
* control disposition;
* monitoring closure;
* incident review;
* assurance;
* data disposition;
* model disposition;
* technical shutdown;
* access removal;
* integration closure;
* supplier closure;
* security closure;
* privacy closure;
* regulatory requirements;
* documentation updates;
* change management;
* retirement approval;
* readiness assessment;
* execution planning;
* execution;
* verification;
* post-retirement risk review;
* post-retirement monitoring;
* post-retirement incident handling;
* lessons learned;
* continual improvement;
* final retirement confirmation;
* evidence;
* traceability; and
* formal closure.

The JSON schema defines structural requirements.

This documentation explains the intended meaning, governance context, validation expectations, and traceability model for retirement records.

***

## 2. Schema Information

| Field               | Value                                         |
| ------------------- | --------------------------------------------- |
| Schema              | AIGO Retirement Schema                        |
| Schema Identifier   | `https://aigo.example/schema/retirement/v0.1` |
| Schema Version      | `0.1`                                         |
| JSON Schema Dialect | JSON Schema Draft 2020-12                     |
| Object Type         | `RETIREMENT`                                  |
| File                | `13-AIGO-Retirement-Schema-v0.1.json`         |
| Status              | Draft                                         |
| Framework           | AIGO — AI Governance Operating Framework      |

***

## 3. Scope

The Retirement Schema applies to the formal retirement of:

* AI systems;
* model versions;
* AI-enabled applications;
* AI services;
* supporting data pipelines;
* infrastructure;
* integrations;
* supplier services;
* governance records associated with a system; and
* other components that must be withdrawn as part of AI system retirement.

Retirement may be initiated because:

* the system is no longer required;
* a replacement system is available;
* the system is obsolete;
* risk is unacceptable;
* performance is unacceptable;
* a strategic decision has been made;
* a regulatory requirement applies;
* security or privacy concerns exist;
* a serious incident occurred;
* technology reached end of life;
* a supplier relationship ends; or
* another approved retirement trigger occurs.

***

## 4. Object Model

The primary object represented by this schema is:

```text id="9o45mi" theme={null}
RETIREMENT
```

A Retirement record represents a formally governed process for ending operational use of an AI system or associated component.

The Retirement record should remain distinct from:

* the AI System record;
* the Risk record;
* the Control record;
* the Monitoring record;
* the Incident record;
* the Change record;
* the Assurance record;
* the Approval record;
* the Improvement record; and
* Evidence records.

Related records should normally be connected through stable identifiers.

***

## 5. Core Identity

A Retirement record should contain stable identity information.

Key fields include:

* `id`;
* `objectType`;
* `objectVersion`;
* `schemaVersion`;
* `aiSystemId`;
* retirement trigger;
* retirement rationale;
* retirement owner; and
* retirement status.

Example:

```json id="io2n9p" theme={null}
{
  "id": "RETIRE-001",
  "objectType": "RETIREMENT",
  "objectVersion": "1.0",
  "schemaVersion": "0.1"
}
```

The retirement identifier should remain stable throughout the retirement lifecycle.

A distinct retirement activity should normally receive a distinct identifier.

***

## 6. AI System Relationship

The retirement record should identify the AI system being retired.

Example:

```json id="kvzz6y" theme={null}
{
  "aiSystemId": "AI-SYS-001"
}
```

The AI System record remains authoritative for:

* system identity;
* ownership;
* classification;
* lifecycle status;
* business context;
* system history; and
* related governance records.

The Retirement record provides the authoritative retirement process.

***

## 7. Retirement Trigger

The trigger identifies why retirement is being initiated.

The schema supports triggers including:

```text id="zmpcgc" theme={null}
SYSTEM_NO_LONGER_REQUIRED
REPLACEMENT_SYSTEM
OBSOLESCENCE
UNACCEPTABLE_RISK
UNACCEPTABLE_PERFORMANCE
STRATEGIC_DECISION
COST_RESOURCE_DECISION
REGULATORY_REQUIREMENT
SECURITY_CONCERN
PRIVACY_CONCERN
INCIDENT
CONTROL_FAILURE
SUPPLIER_TERMINATION
CONTRACT_EXPIRY
TECHNOLOGY_END_OF_LIFE
BUSINESS_PROCESS_CHANGE
OTHER
```

The exact enumeration defined in the JSON schema is authoritative.

Where retirement follows an incident, risk decision, change, or management decision, the relevant source record should be referenced.

***

## 8. Retirement Rationale

The retirement rationale should explain why the system should no longer remain operational.

The rationale may include:

* business justification;
* risk justification;
* technical justification;
* governance justification;
* regulatory justification;
* security justification;
* privacy justification; and
* strategic justification.

The rationale should be sufficiently clear for an independent reviewer to understand the retirement decision.

***

## 9. Retirement Owner

The retirement owner is accountable for coordinating the retirement lifecycle.

Responsibilities may include:

* defining scope;
* coordinating assessments;
* obtaining approvals;
* planning transition;
* coordinating technical shutdown;
* managing dependencies;
* ensuring data disposition;
* ensuring access removal;
* coordinating verification;
* preserving evidence;
* confirming final status; and
* closing the retirement record.

Operational tasks may be delegated.

Accountability should remain explicit.

***

## 10. Retirement Scope

The scope should identify precisely what will be retired.

It may include:

* model;
* model version;
* application;
* API;
* data pipeline;
* infrastructure;
* monitoring;
* controls;
* documentation;
* integrations;
* supplier services;
* contracts; and
* governance records.

The schema supports environments, business units, jurisdictions, and exclusions.

Material exclusions should be explicitly documented.

***

## 11. Retirement Complexity

Retirement complexity may be classified according to the organizational methodology.

Typical levels include:

```text id="qjfwcc" theme={null}
LOW
MEDIUM
HIGH
CRITICAL
```

Complexity may consider:

* system dependencies;
* affected users;
* business criticality;
* data volume;
* regulatory requirements;
* supplier dependencies;
* technical complexity;
* transition requirements; and
* residual risk.

***

## 12. Retirement Impact

Impact assessment should consider the consequences of retiring the system.

Potential impact areas include:

* business operations;
* affected persons;
* customers;
* employees;
* stakeholders;
* service availability;
* data;
* security;
* privacy;
* suppliers;
* legal requirements;
* regulatory obligations;
* replacement systems; and
* business continuity.

Retirement should not be treated as risk-free merely because operational use ends.

***

## 13. Stakeholder Impact

The retirement record may identify affected stakeholders.

Stakeholders may include:

* users;
* customers;
* employees;
* applicants;
* suppliers;
* partners;
* affected persons;
* regulators; and
* other parties.

The record should identify:

* expected retirement impact;
* engagement requirements;
* communication;
* responsible owner; and
* status.

***

## 14. Affected Persons

Where retirement affects individuals or groups, the record should consider:

* service impact;
* access;
* decision processes;
* data;
* rights;
* continuity;
* communications; and
* remediation.

Affected-person information should be minimized and protected.

***

## 15. Communications

Retirement may require communication to:

* users;
* customers;
* employees;
* suppliers;
* business partners;
* regulators;
* affected persons;
* governance bodies; and
* other stakeholders.

Communication records should identify:

* recipient;
* purpose;
* planned date;
* actual date;
* owner;
* status; and
* evidence.

Communication requirements should be determined by impact and applicable obligations.

***

## 16. Replacement and Transition

Where a replacement exists, the retirement record should identify:

* replacement AI system;
* replacement status;
* transition strategy;
* parallel operation;
* transition duration;
* transition risks; and
* transition owner.

Possible replacement states include:

```text id="he4i5n" theme={null}
NONE
PLANNED
IN_DEVELOPMENT
TESTING
APPROVED
OPERATIONAL
FULLY_OPERATIONAL
```

Retirement should not proceed where a required replacement or continuity arrangement is not ready unless an authorized decision permits it.

***

## 17. Business Continuity

The retirement record should determine whether continuity arrangements are required.

Continuity may rely on:

* replacement system;
* manual fallback;
* alternate service;
* retained functionality;
* temporary process; or
* other approved arrangements.

Readiness should be verified where business continuity is material.

Possible readiness states include:

```text id="u6yud0" theme={null}
READY
READY_WITH_CONDITIONS
NOT_READY
NOT_APPLICABLE
```

***

## 18. Retirement Risk Assessment

Retirement may create risks distinct from normal operation.

Potential retirement risks include:

* service disruption;
* incomplete shutdown;
* residual access;
* data-loss;
* unintended data retention;
* security exposure;
* privacy exposure;
* orphaned dependencies;
* supplier disputes;
* incomplete monitoring closure;
* regulatory non-compliance;
* replacement failure;
* business continuity failure; and
* residual risk after retirement.

The retirement risk assessment should consider the full transition period.

***

## 19. Retirement Risk Levels

The risk assessment should use the organization's approved risk methodology.

Risk may be evaluated using:

* likelihood;
* impact;
* risk level;
* treatment;
* owner;
* status; and
* evidence.

The common AIGO `RiskLevel` definition should be used where applicable.

***

## 20. Residual Risk

Residual risk should be evaluated after retirement controls and treatments are implemented.

Residual risk may remain because:

* data is retained;
* dependencies remain;
* historical obligations continue;
* monitoring continues temporarily;
* legal requirements persist;
* supplier arrangements remain; or
* another related risk remains active.

The Retirement record should identify whether residual risk remains within tolerance.

***

## 21. Risk Acceptance

Where residual retirement risk requires formal acceptance, the record should reference the applicable risk acceptance.

The acceptance should identify:

* risk;
* authority;
* status;
* effective date;
* expiry;
* conditions; and
* rationale.

Retirement should not be considered complete simply because the operational system has been shut down if material residual risk remains unmanaged.

***

## 22. Control Disposition

Retirement may affect controls.

Controls may be:

* retired;
* transferred;
* retained;
* modified;
* replaced; or
* otherwise reconfigured.

The Retirement record should identify the disposition of relevant controls and closure evidence.

Controls that remain necessary after retirement should not be removed merely because the AI system is inactive.

***

## 23. Monitoring Closure

Monitoring associated with the retired system should be reviewed.

Actions may include:

* stopping monitoring;
* transferring monitoring;
* retaining historical monitoring;
* establishing post-retirement monitoring; or
* modifying monitoring.

The final monitoring state should be documented and evidenced.

***

## 24. Incident Review

Open incidents should be reviewed before retirement.

The organization should determine whether:

* incidents must be closed;
* investigations must continue;
* evidence must be preserved;
* post-retirement incident handling is required;
* regulatory requirements remain; or
* incidents affect retirement readiness.

A system should not be retired in a manner that destroys necessary incident evidence.

***

## 25. Assurance Review

Depending on risk and significance, retirement may require assurance.

Assurance may evaluate:

* retirement readiness;
* data disposition;
* technical shutdown;
* access removal;
* risk closure;
* monitoring closure;
* control disposition;
* regulatory compliance;
* evidence; and
* final retirement verification.

The Assurance Schema remains authoritative for the assurance activity.

***

## 26. Data Disposition

Data associated with the AI system should be classified and handled appropriately.

Possible actions include:

```text id="e4ll20" theme={null}
RETAIN
ARCHIVE
TRANSFER
ANONYMIZE
DELETE
DESTROY
OTHER
```

The record should identify:

* categories of data;
* retention requirement;
* retention period;
* destination;
* deletion or destruction method;
* verification method;
* owner; and
* evidence.

Data should not be deleted solely because the AI system is retired when retention obligations continue.

***

## 27. Model Disposition

Model artifacts may be:

* retained;
* archived;
* transferred;
* deleted;
* destroyed; or
* otherwise disposed of.

The disposition should consider:

* legal obligations;
* intellectual property;
* reproducibility;
* assurance;
* incident investigation;
* regulatory requirements;
* security; and
* historical traceability.

***

## 28. Technical Disposition

Technical components should be systematically addressed.

These may include:

* applications;
* infrastructure;
* APIs;
* databases;
* pipelines;
* configuration;
* containers;
* storage;
* secrets;
* certificates;
* monitoring;
* integrations; and
* dependencies.

Technical disposition should verify that retired components cannot continue operating unintentionally.

***

## 29. Access Removal

Access should be reviewed and removed where no longer necessary.

Access types may include:

* user access;
* service accounts;
* API keys;
* privileged accounts;
* machine identities;
* certificates;
* credentials;
* supplier access; and
* other technical access.

Removal should be verified.

Orphaned accounts are a material retirement risk.

***

## 30. Integration Closure

Integrations should be reviewed for:

* APIs;
* data feeds;
* system-to-system connections;
* event streams;
* scheduled jobs;
* authentication;
* downstream dependencies; and
* upstream dependencies.

Each material integration should be:

* removed;
* transferred;
* replaced;
* retained; or
* otherwise dispositioned.

Orphaned dependencies should be specifically checked.

***

## 31. Supplier Closure

Third-party relationships may need to be terminated or transitioned.

Supplier closure may include:

* service termination;
* contract closure;
* data return;
* data deletion;
* credential removal;
* access termination;
* final invoice;
* evidence retention;
* notification; and
* contractual obligations.

Supplier closure should be coordinated with procurement and legal processes where necessary.

***

## 32. Security Closure

Security review should determine whether retirement leaves:

* exposed services;
* credentials;
* unprotected storage;
* residual access;
* unused interfaces;
* vulnerable components;
* logging gaps; or
* other security exposure.

The security closure result should be documented and supported by evidence.

***

## 33. Privacy Closure

Privacy closure should address:

* data disposition;
* retention;
* deletion;
* access;
* transfers;
* affected-person requirements;
* privacy notifications; and
* remaining privacy obligations.

Privacy closure should be coordinated with the organization's privacy process.

***

## 34. Regulatory Requirements

Retirement may have legal or regulatory obligations.

These may concern:

* record retention;
* notification;
* data handling;
* customer communication;
* regulatory reporting;
* system documentation;
* audit records;
* contractual obligations; or
* other continuing obligations.

The Retirement record should identify applicable requirements and the evidence demonstrating compliance.

***

## 35. Documentation Updates

Retirement should update controlled records such as:

* AI inventory;
* AI System profile;
* classification;
* risk register;
* control register;
* monitoring;
* governance records;
* supplier records;
* documentation;
* technical records; and
* reporting.

The system should not remain operationally marked as active after authorized retirement.

***

## 36. Change Management

Retirement is normally a material lifecycle change.

The Retirement record should reference the applicable Change record where change-management requirements apply.

The Change record remains authoritative for formal change governance.

Retirement activities should align with approved change scope.

***

## 37. Retirement Approval

Formal approval may be required before retirement.

The approval should consider:

* retirement trigger;
* scope;
* risk assessment;
* replacement readiness;
* continuity;
* data disposition;
* access removal;
* monitoring closure;
* incident status;
* security;
* privacy;
* supplier arrangements;
* regulatory requirements; and
* evidence.

The Approval Schema remains authoritative for the approval decision.

***

## 38. Retirement Readiness

Before execution, readiness should be evaluated.

Readiness may cover:

* approval;
* risk assessment;
* incident review;
* replacement readiness;
* continuity;
* data disposition;
* access removal;
* monitoring closure;
* technical shutdown;
* supplier closure;
* security;
* privacy; and
* evidence retention.

Possible readiness statuses include:

```text id="mxr2at" theme={null}
READY
READY_WITH_CONDITIONS
NOT_READY
```

A retirement should not proceed without required readiness unless an authorized exception exists.

***

## 39. Execution Plan

The retirement execution plan should define:

* activities;
* sequence;
* owners;
* dependencies;
* planned dates;
* evidence requirements; and
* status.

A controlled sequence reduces the risk of:

* accidental service disruption;
* orphaned integrations;
* incomplete access removal;
* data loss;
* evidence loss; or
* premature shutdown.

***

## 40. Retirement Execution

Execution should record:

* activities completed;
* issues;
* deviations;
* execution status;
* responsible parties;
* completion date; and
* evidence.

Potential execution statuses include:

```text id="6pc5yw" theme={null}
NOT_STARTED
IN_PROGRESS
PARTIALLY_COMPLETED
COMPLETED
FAILED
CANCELLED
```

The authoritative schema enumeration is controlling.

***

## 41. Execution Deviations

A deviation occurs when retirement execution differs materially from the approved plan.

The record should identify:

* deviation;
* impact;
* owner;
* approval requirement;
* approval reference; and
* evidence.

Material deviations may require reassessment or change control.

***

## 42. Retirement Verification

Verification confirms that retirement was actually achieved.

Verification may include tests for:

* system availability;
* API availability;
* access;
* credentials;
* scheduled jobs;
* data processing;
* integrations;
* monitoring;
* dependencies;
* infrastructure;
* supplier access;
* control status; and
* inventory status.

The verification should state:

* objective;
* scope;
* tests;
* results;
* conclusion;
* verifier; and
* evidence.

***

## 43. Verification Outcomes

Typical outcomes include:

```text id="u3m9h7" theme={null}
PASSED
PASSED_WITH_CONDITIONS
FAILED
INCONCLUSIVE
```

The exact schema enumeration is authoritative.

A failed retirement verification should trigger appropriate remediation and prevent premature closure.

***

## 44. Final Retirement Confirmation

The record should establish the final state of the AI system.

Confirmation may include:

* system retired;
* retirement date;
* scope confirmed;
* system no longer approved for operational use;
* inventory updated;
* governance records updated; and
* confirmation authority.

Final retirement confirmation should only occur after required verification.

***

## 45. Post-Retirement Risk Review

Retirement may create continuing risks.

A post-retirement risk review should consider:

* residual risk;
* outstanding risks;
* transferred risks;
* retained data;
* remaining dependencies;
* historical obligations;
* supplier obligations; and
* other continuing exposure.

The Risk record remains authoritative for ongoing risks.

***

## 46. Post-Retirement Monitoring

Some systems or components may require monitoring after retirement.

Reasons may include:

* retained interfaces;
* retained data;
* regulatory obligations;
* residual security exposure;
* transition period;
* replacement instability; or
* residual risk.

Post-retirement monitoring should specify:

* whether required;
* scope;
* duration;
* owner;
* exit criteria; and
* status.

***

## 47. Post-Retirement Incident Handling

The organization should define how incidents discovered after retirement are handled.

Potential post-retirement incidents include:

* unauthorized system operation;
* residual access;
* data exposure;
* retained vulnerabilities;
* incorrect inventory state;
* supplier failures; or
* unintended downstream impact.

The record should identify the applicable incident-management process and ownership.

***

## 48. Lessons Learned

Retirement should generate lessons where appropriate.

Lessons may concern:

* planning;
* dependencies;
* data;
* security;
* privacy;
* supplier management;
* change management;
* continuity;
* governance;
* evidence; or
* technical architecture.

Lessons learned may generate Improvement records.

***

## 49. Continual Improvement

Retirement experiences may identify governance improvements.

Examples include:

* better inventory;
* better dependency mapping;
* improved retirement checklists;
* improved evidence requirements;
* stronger supplier termination controls;
* improved data disposition;
* stronger access-removal controls; or
* improved readiness criteria.

Improvements should be managed through the Improvement Schema.

***

## 50. Evidence

Retirement evidence may include:

* retirement approval;
* readiness assessment;
* risk assessment;
* change records;
* technical shutdown records;
* access-removal evidence;
* data deletion or archive evidence;
* supplier closure;
* monitoring closure;
* security review;
* privacy review;
* verification tests;
* final confirmation; and
* inventory updates.

Evidence should be managed under the Evidence Schema where appropriate.

***

## 51. Evidence Completeness

The retirement record should indicate whether required evidence is:

* complete;
* substantially complete;
* partially complete; or
* incomplete.

Material evidence gaps should be identified and addressed before closure where required.

***

## 52. Traceability

Retirement should preserve traceability to the AI system's historical governance.

A recommended traceability chain is:

```text id="x3myto" theme={null}
AI System
    ↓
Registration
    ↓
Classification
    ↓
Risk
    ↓
Controls
    ↓
Monitoring
    ↓
Incidents
    ↓
Changes
    ↓
Assurance
    ↓
Retirement Approval
    ↓
Retirement Execution
    ↓
Verification
    ↓
Final Confirmation
    ↓
Closure
```

The chain may also include:

```text id="9f3tuv" theme={null}
Evidence
Management Review
Improvement
Risk Acceptance
Supplier Records
Regulatory Records
```

Historical relationships should not be deleted merely because the system is retired.

***

## 53. Retirement Closure

The retirement record should be formally closed after:

* execution;
* verification;
* final confirmation;
* evidence retention;
* residual-risk review;
* required post-retirement monitoring arrangements;
* documentation updates; and
* other closure criteria.

Possible closure states include:

```text id="r8j7s7" theme={null}
CLOSED
CLOSED_WITH_CONDITIONS
DEFERRED
REOPENED
CANCELLED
```

The exact enumeration defined in the schema is authoritative.

***

## 54. Retirement Reopening

A retirement record may need to be reopened when:

* the system remains operational;
* residual access is discovered;
* data disposition was incomplete;
* retirement verification failed;
* a dependency remains active;
* regulatory obligations were missed; or
* another material retirement deficiency is discovered.

Reopening should preserve historical closure information.

***

## 55. Retirement Reporting

Retirement records may support governance reporting.

Useful metrics include:

| Metric                         | Purpose                      |
| ------------------------------ | ---------------------------- |
| Systems retired                | Lifecycle activity           |
| Retirements by trigger         | Retirement drivers           |
| Retirements overdue            | Governance backlog           |
| Retirement failures            | Execution risk               |
| Retirements with residual risk | Remaining exposure           |
| Retirements with conditions    | Closure constraints          |
| Access-removal exceptions      | Security exposure            |
| Data-disposition exceptions    | Privacy and records exposure |
| Supplier closure exceptions    | Third-party exposure         |
| Post-retirement incidents      | Retirement effectiveness     |
| Verification failure rate      | Retirement quality           |

Metrics should have controlled definitions and reporting periods.

***

## 56. Retirement Validation Requirements

A valid Retirement record should satisfy:

### Structural Validation

The JSON document must validate against:

`13-AIGO-Retirement-Schema-v0.1.json`

### AI System Validation

The affected AI System should be identifiable.

### Trigger Validation

The retirement trigger should be defined.

### Scope Validation

Retirement scope should be explicit.

### Risk Validation

Retirement risks should be assessed where required.

### Readiness Validation

Required readiness conditions should be satisfied.

### Approval Validation

Required approval should be obtained before execution.

### Data Validation

Data disposition requirements should be addressed.

### Access Validation

Relevant access should be removed or transferred.

### Monitoring Validation

Monitoring closure or post-retirement monitoring should be addressed.

### Supplier Validation

Supplier dependencies should be closed, transferred, or otherwise dispositioned.

### Security Validation

Security closure should be established where applicable.

### Privacy Validation

Privacy closure should be established where applicable.

### Execution Validation

Retirement execution should match approved scope.

### Verification Validation

Retirement should be independently verified where required.

### Evidence Validation

Material retirement actions should have appropriate evidence.

### Closure Validation

Final closure should satisfy applicable criteria.

### Traceability Validation

Historical relationships to governance records should remain intact.

***

## 57. Schema Limitations

JSON Schema cannot independently determine:

* whether retirement is actually appropriate;
* whether replacement readiness is sufficient;
* whether continuity plans work;
* whether all dependencies were discovered;
* whether data was fully disposed of;
* whether access was completely removed;
* whether residual risk is acceptable;
* whether technical shutdown was complete;
* whether regulatory obligations were satisfied; or
* whether final verification is reliable.

These matters require governance procedures, technical controls, evidence, testing, and assurance.

***

## 58. Relationship to Templates

The Retirement Schema corresponds primarily to:

`guidance/03-templates/15-AIGO-AI-Retirement-Template-v0.1.md`

It also interacts with:

* AI system registration;
* AI system profile;
* classification;
* risk assessment;
* control assessment;
* approval;
* monitoring;
* incident;
* change management;
* assurance;
* evidence;
* management review; and
* improvement templates.

The Markdown template provides the human-readable retirement record.

The JSON schema provides the machine-readable structure.

***

## 59. Relationship to Procedures

The schema should be used with:

`guidance/02-procedures/12-AIGO-AI-Retirement-Procedure-v0.1.md`

and, where applicable:

* AI governance;
* AI system registration;
* classification;
* risk assessment;
* control assessment;
* approval;
* monitoring;
* incident management;
* change management;
* assurance;
* risk acceptance; and
* continuous improvement procedures.

The procedure defines retirement planning, readiness, authorization, execution, verification, evidence, closure, and post-retirement review.

***

## 60. Framework Traceability

| AIGO Component          | Relationship                                          |
| ----------------------- | ----------------------------------------------------- |
| Governance Domains      | Defines retirement authority and accountability       |
| Governance Roles        | Defines retirement ownership and approval             |
| AI Governance Lifecycle | Provides retirement stage and transition requirements |
| AI Risk Management      | Provides retirement and residual-risk assessment      |
| AI Governance Controls  | Provides control disposition requirements             |
| AI Governance Maturity  | Supports retirement capability assessment             |
| AI System Profiles      | Identifies the retirement subject                     |
| Implementation Guidance | Defines retirement implementation expectations        |
| Operational Procedures  | Defines retirement workflow                           |
| Templates               | Provides human-readable retirement records            |
| External Mappings       | Provides regulatory and standards context             |

***

## 61. Retirement Traceability Model

The recommended traceability model is:

```text id="y7j1b8" theme={null}
Retirement Trigger
       ↓
Retirement Scope
       ↓
Impact / Risk Assessment
       ↓
Readiness
       ↓
Approval
       ↓
Execution Plan
       ↓
Execution
       ↓
Verification
       ↓
Final Confirmation
       ↓
Post-Retirement Review
       ↓
Closure
```

Supporting traceability should include:

```text id="5kmzv5" theme={null}
Evidence
Risk Acceptance
Monitoring
Incident
Change
Assurance
Improvement
Management Review
Supplier Records
Regulatory Records
```

***

## 62. Example Record

A conceptual Retirement record may look like:

```json id="m7xv97" theme={null}
{
  "id": "RETIRE-001",
  "objectType": "RETIREMENT",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "IN_PROGRESS",
  "aiSystemId": "AI-SYS-001",
  "systemName": "Example AI Decision Support System",
  "retirementOwner": {
    "role": "AI System Owner"
  },
  "retirementTrigger": "REPLACEMENT_SYSTEM",
  "retirementRationale": "The approved replacement system provides the required capability with improved governance and technical support.",
  "plannedRetirementDate": "2026-12-31",
  "replacement": {
    "replacementExists": true,
    "replacementAiSystemId": "AI-SYS-002",
    "replacementStatus": "OPERATIONAL",
    "transitionStrategy": "Controlled migration followed by verified shutdown."
  },
  "riskAssessment": {
    "assessmentId": "ASSESS-020"
  },
  "changeManagement": {
    "required": true,
    "changeId": "CHANGE-020"
  },
  "approval": {
    "decision": "APPROVED"
  },
  "evidence": {
    "evidenceIds": [
      "EVID-100",
      "EVID-101"
    ]
  }
}
```

The actual record must conform to the authoritative JSON schema.

***

## 63. Schema Registry Relationship

This schema is registered in:

`schemas/00-AIGO-Schema-Registry-v0.1.json`

The registry should maintain:

* schema identifier;
* object type;
* version;
* controlled path;
* status;
* dependencies;
* referenced schemas;
* owner;
* documentation path; and
* traceability metadata.

***

## 64. Change and Version Management

Changes to the Retirement Schema should be managed through AIGO change management.

Potential impacts should be assessed against:

* retirement procedures;
* retirement templates;
* AI system inventory;
* risk management;
* control management;
* monitoring;
* incident management;
* change management;
* assurance;
* evidence;
* supplier governance;
* privacy;
* security;
* regulatory obligations; and
* validation tooling.

Breaking changes should include migration guidance where necessary.

***

## 65. Future Extensions

Future versions may support:

* automated retirement workflows;
* dependency graph validation;
* automated access-discovery;
* infrastructure discovery;
* data-lineage validation;
* automated evidence collection;
* retirement readiness scoring;
* post-retirement monitoring automation;
* supplier termination workflows;
* machine-readable regulatory retention rules; and
* automated retirement conformance testing.

Extensions should preserve historical traceability, evidence integrity, approval accountability, and final retirement verification.

***

## 66. Document Control

| Field               | Value                                 |
| ------------------- | ------------------------------------- |
| Document            | AIGO Retirement Schema Documentation  |
| Version             | 0.1                                   |
| Status              | Draft                                 |
| Document Identifier | `AIGO-SCHEMA-DOC-013`                 |
| Document Type       | Schema Documentation                  |
| Schema              | `13-AIGO-Retirement-Schema-v0.1.json` |
| Owner               |                                       |
| Technical Reviewer  |                                       |
| Governance Reviewer |                                       |
| Approved By         |                                       |
| Effective Date      |                                       |
| Next Review Date    |                                       |

***

## 67. Document Status

**Document:** AIGO — Retirement Schema Documentation

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

**Document Identifier:** `AIGO-SCHEMA-DOC-013`

**Document Type:** Schema Documentation

This document provides the human-readable interpretation, governance context, validation expectations, and traceability guidance for the AIGO Retirement Schema.

End of Document