​

Change Schema

The AIGO Change Schema provides the machine-readable structure for recording governed changes affecting AI systems, their operating environments, governance arrangements, controls, risks, or lifecycle conditions. Change management provides the mechanism for determining whether an existing governance state remains appropriate after a change.

​

Purpose

The Change Schema supports consistent recording of:

• change identity
• affected AI system
• change description
• change rationale
• change status
• change type
• materiality
• affected governance conditions
• impact assessment
• affected risks
• affected controls
• required approvals
• implementation actions
• supporting evidence
• monitoring requirements
• assurance activities
• resulting governance decisions

This allows material changes to remain traceable throughout the AI system lifecycle.

​

Role in the AIGO architecture

Change management provides a feedback mechanism within the AIGO lifecycle. A representative relationship is: AI system → change → impact assessment → reassessment → decision → implementation → monitoring A change can also connect to:

• classification
• risks
• controls
• assessments
• approvals
• evidence
• monitoring
• assurance
• incidents
• improvement
• retirement

This allows an organization to determine whether the governance state before the change remains valid after the change.

​

What a change represents

A change record represents a controlled modification to an AI system or its governance context. Potential changes include:

• system functionality
• model or component
• data
• intended use
• deployment environment
• operating context
• stakeholders
• ownership
• controls
• monitoring
• governance requirements
• applicable policies
• risk treatment
• approval conditions

Not every change requires the same governance treatment. The applicable process should determine whether the change is administrative, operational, technical, material, or otherwise significant.

​

Change materiality

Materiality should be assessed rather than assumed. Factors that may influence materiality include:

• changes to intended use
• changes to system capabilities
• changes in affected stakeholders
• changes in potential impact
• changes in risk exposure
• changes to classification
• changes to applicable requirements
• changes to controls
• changes to approval conditions
• significant model changes
• significant data changes
• changes in operating environment

A materiality determination should be recorded together with the criteria and information used to reach the decision.

​

Change status

A change record should preserve its lifecycle status. Depending on the applicable AIGO implementation, statuses may include concepts such as:

• proposed
• under assessment
• approved
• rejected
• in implementation
• implemented
• suspended
• cancelled
• closed

The canonical Change Schema defines the permitted machine-readable structure and values. Status should be interpreted together with the change scope and governance decision.

​

Change rationale

A governed change should document why the change is being proposed or implemented. The rationale may include:

• business need
• technical requirement
• risk treatment
• incident remediation
• regulatory requirement
• performance improvement
• security improvement
• control improvement
• operational requirement
• stakeholder requirement
• continual improvement

A clear rationale helps reviewers understand the purpose of the change and evaluate whether the proposed implementation is appropriate.

​

Impact assessment

A change may require assessment of its potential effects. Impact assessment may consider:

• system behavior
• intended use
• stakeholders
• risks
• controls
• evidence
• monitoring
• assurance
• approval status
• applicable requirements
• lifecycle status

The assessment should identify which governance records are affected and whether they require revision, reassessment, or replacement.

​

Relationship to classification

A material change may require the AI system to be reclassified. For example, a change to:

• intended use
• affected population
• deployment context
• system capability
• risk exposure

may alter the governance treatment applicable to the system. The relationship can therefore be represented as: change → classification review → classification decision → governance pathway The existing classification should not be assumed to remain valid after a material change.

​

Relationship to risk

Changes can introduce new risks or alter existing risks. A representative relationship is: change → impact assessment → risk reassessment → treatment → controls A change record should therefore preserve relationships to affected risk records where applicable. The resulting risk assessment may determine that:

• existing treatment remains adequate
• additional controls are required
• monitoring must increase
• residual risk changes
• risk acceptance is required
• approval must be reconsidered

​

Relationship to controls

Changes can affect the applicability or effectiveness of existing controls. A change may require:

• existing controls to be reassessed
• additional controls
• control modifications
• compensating controls
• additional evidence
• additional monitoring
• control retirement or replacement

The relationship can be represented as: change → affected control → assessment → evidence → decision

​

Relationship to approval

Material changes may require governance approval before implementation. Depending on the governance model, the change may require:

• no additional approval
• approval confirmation
• conditional approval
• renewed approval
• approval by a higher authority
• suspension of an existing approval
• withdrawal of approval

The change record should preserve the relationship between the proposed change and the resulting governance decision.

​

Implementation actions

An approved change should identify the actions required to implement it. Implementation information may include:

• implementation owner
• implementation steps
• dependencies
• target date
• rollback considerations
• testing requirements
• validation requirements
• evidence requirements
• monitoring requirements

Implementation records should remain connected to the originating change.

​

Evidence

Change governance should preserve evidence demonstrating what was assessed, approved, implemented, and verified. Evidence may include:

• change requests
• impact assessments
• test results
• approvals
• configuration records
• deployment records
• validation results
• monitoring results
• control assessments
• assurance findings

Evidence should be retained according to applicable organizational requirements.

​

Change verification

After implementation, the organization may need to verify that the change achieved its intended outcome and did not introduce unacceptable consequences. Verification may consider:

• expected functionality
• risk changes
• control operation
• monitoring results
• approval conditions
• stakeholder impacts
• incidents
• evidence completeness

A change should not necessarily be considered complete solely because the technical implementation has finished. Governance verification may also be required.

​

Relationship to monitoring

Changes may introduce new monitoring requirements. For example: change → impact assessment → monitoring requirement → monitoring result Monitoring can then determine whether the changed system continues to operate within the expected governance conditions. Monitoring results may subsequently trigger additional change, risk reassessment, incident management, or assurance.

​

Relationship to incidents

Incidents can create changes requiring formal governance. For example: incident → corrective action → change → assessment → approval → implementation The Change Schema can therefore preserve traceability between an operational incident and the governance-controlled modification made in response.

​

Relationship to assurance

Assurance may examine whether change management is operating effectively. Assurance may consider:

• whether material changes were identified
• whether impact assessments were performed
• whether required approvals were obtained
• whether affected risks and controls were reassessed
• whether evidence was preserved
• whether implementation was verified
• whether monitoring requirements were updated

Change records therefore provide useful evidence for governance assurance.

​

Relationship to machine-readable evaluation

Change records can participate in the AIGO machine-readable governance evaluation layer. The architecture separates: governance records → evaluation rules → evaluation → result Evaluation rules may check conditions such as:

• required change information exists
• material changes received appropriate assessment
• required approvals exist
• affected controls were reassessed
• required evidence exists
• post-change verification was completed
• required monitoring was established

Automated evaluation supports governance consistency but does not itself determine whether a change is appropriate in every context.

​

Machine-readable implementation

An organization implementing AIGO may use the Change Schema as the structural contract for governed change records. A governance implementation could:

1. identify a proposed change
2. identify the affected AI system
3. record the change rationale
4. assess materiality
5. perform impact assessment
6. identify affected risks and controls
7. determine required governance actions
8. obtain required approval
9. implement the change
10. collect implementation evidence
11. perform post-change verification
12. update monitoring and assurance requirements
13. close the change
14. feed lessons learned into continual improvement

The schema defines the structure of the governance information. It does not prescribe a particular change-management platform, ticketing system, deployment system, workflow engine, or technical implementation process.

​

Governance outcomes

A governed change may result in:

• no additional governance action
• updated classification
• updated risk assessment
• modified controls
• additional evidence requirements
• additional monitoring
• renewed approval
• assurance activity
• risk acceptance
• lifecycle status change
• additional corrective action

The resulting decision should remain traceable to the original change.

​

Validation

Change artifacts participate in the broader AIGO validation model. Relevant validation may include:

• schema validation
• reference validation
• traceability validation
• evidence relationships
• framework consistency
• document integrity
• repository health
• rule validation
• evaluation fixture validation
• evaluation orchestration validation

A passing validation result indicates that the tested artifact or repository content satisfies the implemented validation checks within the applicable scope. It does not establish legal compliance, certification, accreditation, or regulatory conformity.

​

Canonical source

Machine-readable schema: schemas/08-change/08-AIGO-Change-Schema-v0.1.json Schema documentation: schemas/08-change/08-AIGO-Change-Schema-Documentation-v0.1.md Implementation procedure: guidance/02-procedures/07-AIGO-AI-Change-Management-Procedure-v0.1.md Implementation template: guidance/03-templates/11-AIGO-AI-Change-Management-Template-v0.1.md