> ## 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.

# 08 AIGO Change Schema Documentation v0.1

# AIGO — Change Schema Documentation

## 1. Document Purpose

This document describes the machine-readable AIGO Change Schema.

The schema provides the structured representation of changes to AI systems, AI models, data, controls, governance arrangements, supporting technology, processes, and other governed components within the AIGO AI Governance Operating Framework.

It is intended to support:

* change identification;
* change requests;
* change classification;
* materiality determination;
* change impact assessment;
* risk assessment;
* control assessment;
* testing and validation;
* approval;
* implementation;
* deployment;
* rollback;
* monitoring;
* incident relationships;
* evidence;
* verification;
* closure; and
* continual improvement.

The JSON schema defines structural requirements.

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

***

## 2. Schema Information

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

***

## 3. Scope

The Change Schema applies to changes that may affect:

* AI systems;
* models;
* model versions;
* data;
* prompts;
* configurations;
* algorithms;
* applications;
* infrastructure;
* integrations;
* controls;
* monitoring;
* human oversight;
* intended purpose;
* business processes;
* suppliers;
* governance arrangements; or
* other AIGO-governed components.

Changes may be:

* planned;
* routine;
* standard;
* material;
* major;
* emergency;
* corrective;
* preventive;
* security-related;
* regulatory; or
* another approved category.

The organization's change-management methodology determines the detailed classification and approval requirements.

***

## 4. Object Model

The primary object represented by this schema is:

```text id="n5x5mr" theme={null}
CHANGE
```

A Change record represents a proposed, approved, implemented, or completed modification to a governed object or condition.

The Change record should remain distinct from:

* the AI System being changed;
* the Risk assessment;
* the Control assessment;
* the Assessment record;
* the Approval decision;
* the Incident record;
* the Monitoring record;
* the Assurance record; and
* Evidence records.

These relationships should normally be maintained through stable identifiers.

***

## 5. Core Identity

A Change record should contain stable identity information.

Key fields include:

* `id`;
* `objectType`;
* `objectVersion`;
* `schemaVersion`;
* change title;
* change status;
* change type;
* change owner;
* affected object; and
* proposed or actual implementation information.

Example:

```json id="c4at79" theme={null}
{
  "id": "CHANGE-001",
  "objectType": "CHANGE",
  "objectVersion": "1.0",
  "schemaVersion": "0.1"
}
```

The change identifier should remain stable throughout the change lifecycle.

A materially distinct change should receive a new identifier.

***

## 6. Change Purpose

The change record should clearly describe why the change is required.

Reasons may include:

* business improvement;
* risk treatment;
* incident remediation;
* performance improvement;
* security remediation;
* regulatory compliance;
* privacy requirement;
* fairness improvement;
* technology replacement;
* model update;
* data update;
* control improvement;
* monitoring enhancement;
* supplier change;
* lifecycle transition; or
* another approved reason.

The rationale should be sufficiently clear to support impact assessment and approval.

***

## 7. Change Subject

The change should identify what is being changed.

Possible subjects include:

* AI system;
* model;
* model version;
* data pipeline;
* data source;
* application;
* infrastructure;
* control;
* monitoring arrangement;
* governance arrangement;
* process;
* procedure;
* supplier service; or
* another governed object.

The applicable object should be referenced through a stable identifier.

***

## 8. Change Type

The change type provides a controlled classification of the requested modification.

Typical categories include:

```text id="ajurc4" theme={null}
ROUTINE
STANDARD
MINOR
MATERIAL
MAJOR
EMERGENCY
CORRECTIVE
PREVENTIVE
REGULATORY
SECURITY
PRIVACY
MODEL
DATA
CONTROL
GOVERNANCE
RETIREMENT
OTHER
```

The authoritative enumeration defined in the JSON schema is controlling.

Organizations may maintain additional controlled classifications through governed extensions.

***

## 9. Change Materiality

A key governance question is whether the proposed change is material.

Materiality may consider:

* impact on intended purpose;
* risk impact;
* classification impact;
* affected-person impact;
* autonomy;
* model behavior;
* data changes;
* control changes;
* monitoring changes;
* human-oversight changes;
* security impact;
* privacy impact;
* fairness impact;
* regulatory significance;
* business continuity;
* supplier impact; and
* technical architecture changes.

The materiality determination should be recorded explicitly.

***

## 10. Change Owner

The change should have an accountable owner.

The change owner is responsible for:

* defining the change;
* coordinating impact assessment;
* obtaining required reviews;
* ensuring approvals;
* coordinating implementation;
* managing dependencies;
* ensuring testing;
* coordinating rollback where necessary;
* confirming implementation;
* supporting verification; and
* ensuring closure.

Technical implementation may be performed by separate teams.

***

## 11. Requestor

The requestor is the person or function that initiates the change.

The requestor may be:

* system owner;
* business owner;
* risk owner;
* control owner;
* technical owner;
* security team;
* privacy team;
* incident management;
* assurance;
* management; or
* another authorized party.

The requestor and change owner may be the same person or different parties.

***

## 12. Change Status

The Change record should distinguish lifecycle status from change classification.

Typical conceptual statuses include:

```text id="2ovk7s" theme={null}
DRAFT
SUBMITTED
UNDER_ASSESSMENT
AWAITING_APPROVAL
APPROVED
SCHEDULED
IN_PROGRESS
IMPLEMENTED
UNDER_VERIFICATION
COMPLETED
ROLLED_BACK
REJECTED
DEFERRED
CANCELLED
FAILED
```

The exact enumeration defined in the JSON schema is authoritative.

Status changes must follow the applicable AIGO change-management procedure.

***

## 13. Change Lifecycle

A typical change lifecycle is:

```text id="b0f6r2" theme={null}
Need Identified
      ↓
Change Request
      ↓
Change Classification
      ↓
Impact Assessment
      ↓
Risk Assessment
      ↓
Control Assessment
      ↓
Testing Plan
      ↓
Approval
      ↓
Implementation Planning
      ↓
Implementation
      ↓
Validation
      ↓
Enhanced Monitoring
      ↓
Closure
```

Emergency changes may follow an expedited path with retrospective governance where authorized.

***

## 14. Change Scope

The change record should identify:

* systems affected;
* components affected;
* environments affected;
* organizational units;
* jurisdictions;
* users;
* stakeholders;
* affected processes;
* included activities; and
* excluded activities.

The scope should be precise enough to support impact assessment and implementation control.

***

## 15. Current State

The record should describe the current state before the change.

This may include:

* current system version;
* model version;
* current configuration;
* current process;
* current control;
* current monitoring;
* current risk;
* current supplier;
* current environment; and
* current operating state.

This establishes a baseline against which the change can be evaluated.

***

## 16. Target State

The proposed target state should identify:

* new version;
* new model;
* new configuration;
* new data;
* new process;
* revised control;
* revised monitoring;
* revised supplier;
* revised intended purpose; or
* other target condition.

The target state should be clear enough to support testing and approval.

***

## 17. Change Rationale

The rationale should establish:

* why the current state is insufficient;
* why the proposed change is needed;
* expected benefits;
* expected risk reduction;
* required compliance improvements;
* business necessity; and
* relevant constraints.

A change should not be justified solely by technical preference where governance impact is material.

***

## 18. Impact Assessment

A material change should be assessed for impact.

Impact areas may include:

* AI system behavior;
* model performance;
* data;
* risk;
* controls;
* classification;
* human oversight;
* monitoring;
* security;
* privacy;
* fairness;
* safety;
* business operations;
* stakeholders;
* affected persons;
* suppliers;
* legal and regulatory obligations; and
* continuity.

Each material impact should have a defined assessment outcome.

***

## 19. Risk Assessment

Changes may introduce or modify risk.

The Change record should reference relevant Risk and Assessment records where applicable.

Risk considerations may include:

* new risks;
* changed likelihood;
* changed impact;
* changed residual risk;
* control degradation;
* new dependencies;
* transition risks;
* rollback risks;
* operational risks; and
* unintended consequences.

The Risk Schema remains authoritative for enduring risk records.

***

## 20. Control Impact

A change may affect:

* existing controls;
* control effectiveness;
* control ownership;
* control configuration;
* evidence requirements;
* monitoring;
* compensating controls; or
* required new controls.

Control impacts should be explicitly identified where material.

A change should not be implemented with the assumption that existing controls remain effective without assessment when their assumptions have changed.

***

## 21. Classification Impact

A material change may require reassessment of AI system classification.

Potential triggers include:

* new intended purpose;
* increased autonomy;
* expanded user population;
* broader jurisdiction;
* greater affected-person impact;
* changed regulatory status;
* new safety considerations;
* new data sensitivity; or
* significant model capability changes.

Where reclassification is required, the Change record should reference the relevant Classification or Assessment record.

***

## 22. Intended-Purpose Impact

A change to intended purpose may be highly significant.

Examples include:

* expanding use to a new business process;
* using the system for a new decision;
* adding automated decision authority;
* extending to a new stakeholder group;
* changing the target population; or
* changing from decision support to autonomous operation.

Intended-purpose changes should be assessed through the organization's classification and risk processes.

***

## 23. Human-Oversight Impact

Changes should assess whether human oversight is affected.

Consider:

* review role;
* authority;
* workload;
* competence;
* intervention;
* override;
* escalation;
* automation bias;
* decision speed; and
* ability to detect errors.

Changes that reduce meaningful human oversight may require enhanced governance.

***

## 24. Security Impact

Security impact may include changes to:

* attack surface;
* identity;
* permissions;
* infrastructure;
* interfaces;
* data flows;
* model exposure;
* logging;
* secrets;
* vulnerabilities;
* third-party dependencies; or
* security monitoring.

Security assessment and controls should be updated where required.

***

## 25. Privacy Impact

Privacy impact may include changes to:

* data categories;
* data sources;
* data purpose;
* retention;
* access;
* transfer;
* processing;
* affected persons;
* supplier involvement; or
* privacy safeguards.

Privacy assessment should be performed when required.

***

## 26. Fairness Impact

Changes may alter:

* data distributions;
* model performance;
* group outcomes;
* error rates;
* affected populations;
* decision thresholds;
* user interfaces; or
* workflow.

Where fairness is relevant, the organization should determine whether additional fairness assessment and monitoring are necessary.

***

## 27. Safety Impact

For safety-relevant systems, change assessment should consider:

* changed failure modes;
* new hazards;
* degraded safeguards;
* control dependencies;
* fallback;
* human intervention;
* recovery;
* testing; and
* safe-state behavior.

Material safety changes should receive appropriate review and approval.

***

## 28. Stakeholder Impact

Changes may affect:

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

The record should identify significant stakeholder impacts and required engagement or communication.

***

## 29. Business Continuity Impact

Changes should consider:

* service availability;
* dependency changes;
* recovery;
* fallback;
* migration;
* transition;
* outage duration;
* rollback;
* critical processes; and
* disaster recovery.

High-impact changes should establish a tested continuity or rollback approach where appropriate.

***

## 30. Third-Party Impact

Changes involving external providers may affect:

* contracts;
* service levels;
* model versions;
* data processing;
* security;
* privacy;
* monitoring;
* assurance;
* incident notification; and
* termination rights.

Supplier changes should be coordinated with third-party governance.

***

## 31. Change Dependencies

A change may depend on:

* another change;
* approval;
* assessment;
* supplier action;
* infrastructure;
* data;
* control;
* monitoring;
* staffing;
* training; or
* business readiness.

Dependencies should be identified, owned, and tracked.

A blocked dependency may prevent implementation.

***

## 32. Implementation Plan

The change should have an implementation plan appropriate to its complexity.

The plan may include:

* implementation steps;
* sequence;
* owner;
* dependencies;
* planned date;
* expected duration;
* resources;
* communications;
* testing;
* validation;
* rollback; and
* completion criteria.

Implementation should follow the approved change scope.

***

## 33. Testing

Testing should verify that the change works as intended and does not introduce unacceptable effects.

Testing may include:

* functional testing;
* technical testing;
* security testing;
* privacy testing;
* performance testing;
* fairness testing;
* model validation;
* integration testing;
* regression testing;
* user acceptance testing;
* safety testing; and
* resilience testing.

Testing should be proportionate to change risk.

***

## 34. Test Evidence

Test results should identify:

* test identifier;
* objective;
* procedure;
* expected result;
* actual result;
* outcome;
* tester;
* date;
* limitations; and
* supporting evidence.

Failed tests should be investigated before implementation proceeds unless an authorized decision permits otherwise.

***

## 35. Approval

Material changes should receive approval before implementation where required.

Approval requirements may depend on:

* change classification;
* AI classification;
* risk;
* impact;
* control criticality;
* regulatory significance;
* affected-person impact; and
* governance authority.

The Approval Schema remains authoritative for formal approval decisions.

***

## 36. Emergency Changes

Emergency changes may be necessary to:

* contain an incident;
* protect people;
* address security threats;
* meet urgent legal requirements;
* restore critical services; or
* prevent material harm.

Emergency changes should document:

* emergency reason;
* decision authority;
* risk;
* temporary controls;
* implementation;
* monitoring;
* rollback;
* retrospective assessment; and
* retrospective approval where required.

Emergency status should not permanently bypass ordinary governance.

***

## 37. Implementation Execution

The execution record should capture:

* actual implementation;
* start and completion;
* activities performed;
* deviations;
* issues;
* blockers;
* implementation owner;
* evidence;
* outcome; and
* whether rollback occurred.

Material deviations should be reviewed and approved where required.

***

## 38. Rollback Planning

Material changes should have a rollback strategy where feasible.

A rollback plan should identify:

* rollback trigger;
* rollback decision authority;
* rollback steps;
* target state;
* dependencies;
* expected service impact;
* verification;
* communications; and
* evidence.

Rollback should itself be governed when it constitutes a material change.

***

## 39. Rollback Execution

If rollback occurs, the Change record should document:

* reason;
* trigger;
* decision authority;
* activities;
* resulting state;
* residual risk;
* incident relationship where applicable;
* evidence; and
* follow-up.

A failed change may require an Incident or Improvement record.

***

## 40. Post-Implementation Validation

After implementation, validation should determine whether:

* the change was implemented as approved;
* the intended result was achieved;
* controls remain effective;
* monitoring is functioning;
* risk remains acceptable;
* unexpected impacts occurred;
* stakeholders were affected; and
* further action is required.

Validation may require formal Assessment or Assurance.

***

## 41. Enhanced Monitoring

Material changes may require enhanced monitoring after implementation.

Enhanced monitoring may track:

* model performance;
* system stability;
* error rates;
* fairness;
* security;
* privacy;
* user feedback;
* incident indicators;
* control effectiveness; and
* risk indicators.

The monitoring arrangement should specify the duration and exit criteria.

***

## 42. Change and Incident Management

A change may result from an incident, and a change may itself cause an incident.

Relationships may therefore include:

```text id="sclnmf" theme={null}
INCIDENT
   ↓
CHANGE
   ↓
IMPLEMENTATION
   ↓
MONITORING
   ↓
VERIFICATION
```

or:

```text id="wp0d5u" theme={null}
CHANGE
   ↓
Unexpected Effect
   ↓
INCIDENT
```

Both relationships should be preserved where material.

***

## 43. Change and Risk Management

Change management and risk management are closely connected.

A change should identify:

* existing affected risks;
* newly introduced risks;
* changed risk levels;
* control impacts;
* residual risk;
* treatment requirements; and
* acceptance requirements.

A material change should trigger risk reassessment where required.

***

## 44. Change and Control Management

Changes may modify:

* control design;
* control operation;
* control frequency;
* control ownership;
* control evidence;
* control monitoring; or
* compensating controls.

Where controls are affected, a Control Assessment may be required.

***

## 45. Change and Monitoring

Changes may require:

* new indicators;
* revised thresholds;
* increased monitoring;
* temporary monitoring;
* new alerts;
* revised response actions; or
* monitoring retirement.

Monitoring should be updated before the changed system enters operation where required.

***

## 46. Change and Assurance

Material or high-risk changes may require assurance before or after implementation.

Assurance may review:

* change process;
* impact assessment;
* testing;
* approval;
* implementation;
* rollback;
* controls;
* monitoring; and
* post-implementation results.

Assurance findings should remain separate from the Change record.

***

## 47. Evidence

Change evidence may include:

* approved request;
* impact assessment;
* risk assessment;
* test results;
* approval;
* implementation logs;
* configuration records;
* deployment records;
* monitoring results;
* rollback records;
* stakeholder communications;
* validation results; and
* assurance findings.

Evidence should be managed under the Evidence Schema where appropriate.

***

## 48. Change Closure

A change should be closed when the organization's closure criteria are satisfied.

Closure may require confirmation that:

* implementation is complete;
* approved scope was respected;
* deviations were addressed;
* testing passed;
* monitoring is active;
* risk was reassessed where required;
* controls remain adequate;
* approval conditions are complete;
* stakeholder communication occurred; and
* evidence is retained.

An unresolved post-implementation issue should prevent closure or result in a linked follow-up record.

***

## 49. Change Failure

A change may fail when:

* implementation cannot be completed;
* testing fails;
* rollback is required;
* unexpected risk is identified;
* critical controls fail;
* significant incidents occur;
* business continuity is compromised; or
* governance conditions are violated.

A failed change should be documented and may require:

* incident management;
* risk reassessment;
* corrective action;
* assurance; or
* improvement.

***

## 50. Change Reassessment

Changes may need reassessment when:

* scope changes;
* implementation differs materially from the approved plan;
* risk changes;
* new dependencies arise;
* testing reveals unexpected behavior;
* incidents occur;
* approval conditions change; or
* external requirements change.

The reassessment should preserve traceability to the original change.

***

## 51. Change Traceability

The recommended change traceability model is:

```text id="5nq50a" theme={null}
Business / Governance Need
          ↓
Change Request
          ↓
Classification
          ↓
Impact Assessment
          ↓
Risk Assessment
          ↓
Control Assessment
          ↓
Testing
          ↓
Approval
          ↓
Implementation
          ↓
Validation
          ↓
Monitoring
          ↓
Closure
```

Additional relationships may connect the change to:

```text id="k1kfjf" theme={null}
Incident
Evidence
Assurance
Improvement
Management Review
Retirement
```

***

## 52. Change Reporting

Change records may support governance reporting.

Useful metrics include:

| Metric                             | Purpose                  |
| ---------------------------------- | ------------------------ |
| Change volume                      | Change activity          |
| Changes by classification          | Materiality distribution |
| Material changes                   | Governance exposure      |
| Failed changes                     | Change quality           |
| Rolled-back changes                | Stability                |
| Emergency changes                  | Emergency governance     |
| Changes causing incidents          | Change-related risk      |
| Overdue changes                    | Delivery backlog         |
| Changes without required approval  | Governance deficiency    |
| Changes with unresolved conditions | Closure effectiveness    |

Metrics should have controlled definitions and reporting periods.

***

## 53. Change Validation Requirements

A valid Change record should satisfy:

### Structural Validation

The JSON document must validate against:

`08-AIGO-Change-Schema-v0.1.json`

### Identity Validation

The change identifier must be unique and stable.

### Scope Validation

The affected objects and boundaries must be defined.

### Classification Validation

The change type and materiality should be determined according to approved criteria.

### Impact Validation

Material impacts should be assessed.

### Risk Validation

Relevant risks should be evaluated.

### Control Validation

Affected controls should be evaluated where necessary.

### Testing Validation

Required testing should be completed and supported by evidence.

### Approval Validation

Required approval should be obtained before implementation unless a governed emergency pathway applies.

### Implementation Validation

Implementation should remain consistent with approved scope.

### Rollback Validation

Rollback capability should be addressed where appropriate.

### Post-Implementation Validation

The implemented change should be verified.

### Closure Validation

Closure should satisfy applicable criteria.

### Traceability Validation

The change should remain traceable to relevant system, risk, control, assessment, approval, monitoring, incident, assurance, evidence, and improvement records.

***

## 54. Schema Limitations

JSON Schema cannot independently determine:

* whether a change is materially classified;
* whether impact assessment is adequate;
* whether testing is sufficient;
* whether approval authority is appropriate;
* whether implementation matches reality;
* whether rollback is effective;
* whether risk remains acceptable; or
* whether the change achieved its intended outcome.

These matters require governance processes, qualified judgment, evidence, testing, monitoring, and assurance.

***

## 55. Relationship to Templates

The Change Schema corresponds primarily to:

`guidance/03-templates/11-AIGO-AI-Change-Management-Template-v0.1.md`

It also interacts with:

* AI system registration;
* risk assessment;
* control assessment;
* approval;
* monitoring;
* incident;
* assurance;
* evidence;
* improvement; and
* retirement templates.

The Markdown template provides the human-readable operational record.

The JSON schema provides the machine-readable structure.

***

## 56. Relationship to Procedures

The schema should be used with:

`guidance/02-procedures/07-AIGO-AI-Change-Management-Procedure-v0.1.md`

and, where applicable:

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

The procedure defines how changes are proposed, assessed, approved, implemented, monitored, verified, and closed.

***

## 57. Framework Traceability

| AIGO Component          | Relationship                                       |
| ----------------------- | -------------------------------------------------- |
| Governance Domains      | Defines change authority and decision requirements |
| Governance Roles        | Defines change ownership and approval              |
| AI Governance Lifecycle | Identifies lifecycle changes                       |
| AI Risk Management      | Provides change-risk assessment                    |
| AI Governance Controls  | Provides control impact requirements               |
| AI Governance Maturity  | Supports change capability assessment              |
| AI System Profiles      | Identifies affected system and version             |
| Implementation Guidance | Defines implementation expectations                |
| Operational Procedures  | Defines change workflow                            |
| Templates               | Provides human-readable change records             |
| External Mappings       | Provides regulatory and standards context          |

***

## 58. Example Record

A conceptual Change record may look like:

```json id="9eq1g0" theme={null}
{
  "id": "CHANGE-001",
  "objectType": "CHANGE",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "AWAITING_APPROVAL",
  "changeType": "MATERIAL",
  "title": "Upgrade production AI model",
  "aiSystemId": "AI-SYS-001",
  "currentState": {
    "modelVersion": "2.3"
  },
  "targetState": {
    "modelVersion": "2.4"
  },
  "riskIds": [
    "RISK-001",
    "RISK-003"
  ],
  "controlIds": [
    "CTRL-001",
    "CTRL-004"
  ],
  "assessmentIds": [
    "ASSESS-011"
  ],
  "approvalIds": [
    "APPROVAL-007"
  ],
  "monitoringIds": [
    "MON-004"
  ],
  "evidenceIds": [
    "EVID-060",
    "EVID-061"
  ]
}
```

The actual record must conform to the authoritative JSON schema.

***

## 59. 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.

***

## 60. Change and Version Management

Changes to the Change Schema should themselves be treated as controlled framework changes.

Potential impacts should be assessed against:

* existing Change records;
* change procedures;
* approval workflows;
* risk assessment;
* control assessment;
* monitoring;
* incident management;
* assurance;
* evidence;
* reporting;
* external mappings; and
* validation tooling.

Breaking changes should include migration guidance where necessary.

***

## 61. Future Extensions

Future versions may support:

* machine-readable change workflows;
* dependency graphs;
* deployment pipelines;
* automated impact analysis;
* policy-as-code approval gates;
* rollback automation;
* change risk scoring;
* release-management integration;
* continuous validation;
* configuration-drift detection; and
* automated post-implementation verification.

Extensions should preserve stable change identity, approval traceability, and historical records.

***

## 62. Document Control

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

***

## 63. Document Status

**Document:** AIGO — Change Schema Documentation

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

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

**Document Type:** Schema Documentation

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

End of Document