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:

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:

{
  "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:

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:

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:

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:

INCIDENT
   ↓
CHANGE
   ↓
IMPLEMENTATION
   ↓
MONITORING
   ↓
VERIFICATION

or:

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:

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:

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:

{
  "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

​AIGO — Change Schema Documentation

​1. Document Purpose

​2. Schema Information

​3. Scope

​4. Object Model

​5. Core Identity

​6. Change Purpose

​7. Change Subject

​8. Change Type

​9. Change Materiality

​10. Change Owner

​11. Requestor

​12. Change Status

​13. Change Lifecycle

​14. Change Scope

​15. Current State

​16. Target State

​17. Change Rationale

​18. Impact Assessment

​19. Risk Assessment

​20. Control Impact

​21. Classification Impact

​22. Intended-Purpose Impact

​23. Human-Oversight Impact

​24. Security Impact

​25. Privacy Impact

​26. Fairness Impact

​27. Safety Impact

​28. Stakeholder Impact

​29. Business Continuity Impact

​30. Third-Party Impact

​31. Change Dependencies

​32. Implementation Plan

​33. Testing

​34. Test Evidence

​35. Approval

​36. Emergency Changes

​37. Implementation Execution

​38. Rollback Planning

​39. Rollback Execution

​40. Post-Implementation Validation

​41. Enhanced Monitoring

​42. Change and Incident Management

​43. Change and Risk Management

​44. Change and Control Management

​45. Change and Monitoring

​46. Change and Assurance

​47. Evidence

​48. Change Closure

​49. Change Failure

​50. Change Reassessment

​51. Change Traceability

​52. Change Reporting

​53. Change Validation Requirements

​Structural Validation

​Identity Validation

​Scope Validation

​Classification Validation

​Impact Validation

​Risk Validation

​Control Validation

​Testing Validation

​Approval Validation

​Implementation Validation

​Rollback Validation

​Post-Implementation Validation

​Closure Validation

​Traceability Validation

​54. Schema Limitations

​55. Relationship to Templates

​56. Relationship to Procedures

​57. Framework Traceability

​58. Example Record

​59. Schema Registry Relationship

​60. Change and Version Management

​61. Future Extensions

​62. Document Control

​63. Document Status