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

# 14 AIGO Governance Schema Documentation v0.1

# AIGO — Governance Schema Documentation

## 1. Document Purpose

This document describes the machine-readable AIGO Governance Schema.

The schema provides the structured representation of an organization's AI governance arrangement within the AIGO AI Governance Operating Framework.

It is intended to support:

* governance scope;
* governance objectives;
* governance principles;
* governance authority;
* governance bodies;
* committees;
* governance roles;
* decision authority;
* delegated authority;
* reporting;
* escalation;
* AI system governance;
* classification governance;
* risk governance;
* control governance;
* lifecycle governance;
* human oversight;
* monitoring;
* assurance;
* incident management;
* change management;
* risk acceptance;
* retirement;
* third-party governance;
* regulatory requirements;
* documentation;
* evidence;
* exceptions;
* governance metrics;
* governance maturity;
* management review;
* continual improvement;
* resources;
* competence and training;
* communication;
* governance changes;
* approvals;
* review scheduling; and
* framework traceability.

The JSON schema defines structural requirements.

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

***

## 2. Schema Information

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

***

## 3. Scope

The Governance Schema applies to the organization-level arrangement through which AI activities are governed.

It may represent governance at:

* enterprise level;
* group level;
* business-unit level;
* functional level;
* program level;
* AI portfolio level; or
* another authorized organizational level.

The governance arrangement may encompass one or more AI systems and AI-enabled activities.

The organization's formal governance documents and authorities remain controlling.

***

## 4. Object Model

The primary object represented by this schema is:

```text theme={null}
GOVERNANCE
```

A Governance record represents the structured arrangement through which the organization establishes accountability, authority, decision rights, oversight, risk management, controls, lifecycle governance, assurance, and continual improvement for AI.

The Governance record should remain distinct from:

* individual AI System records;
* individual Risk records;
* individual Control records;
* Assessments;
* Approvals;
* Monitoring records;
* Incidents;
* Changes;
* Assurance engagements;
* Evidence records;
* Management Reviews;
* Improvements; and
* Retirement records.

The Governance record provides organizational context and governance rules for those operational records.

***

## 5. Governance Record Identity

A Governance record should contain stable identity information.

Key fields include:

* `id`;
* `objectType`;
* `objectVersion`;
* `schemaVersion`;
* governance name;
* governance owner;
* governance scope;
* governance objectives;
* governance structure; and
* status.

Example:

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

The governance record identifier should remain stable while the governance arrangement is maintained.

Materially separate governance arrangements should normally have distinct identifiers.

***

## 6. Governance Status

Governance arrangements may progress through controlled states.

Typical conceptual states include:

```text theme={null}
DRAFT
PROPOSED
UNDER_REVIEW
APPROVED
ACTIVE
RESTRICTED
SUSPENDED
UNDER_REVISION
SUPERSEDED
RETIRED
```

The exact enumeration defined in the JSON schema is authoritative.

A status value does not itself create organizational authority.

The governance arrangement must be approved and established through the applicable organizational process.

***

## 7. Governance Purpose

The governance record should establish why the governance arrangement exists.

Its purpose may include:

* ensuring accountability for AI;
* establishing decision authority;
* managing AI risk;
* ensuring appropriate controls;
* governing the AI lifecycle;
* protecting affected persons;
* supporting compliance;
* establishing oversight;
* enabling assurance;
* monitoring performance; and
* supporting continual improvement.

The purpose should align with the organization's AI strategy and governance obligations.

***

## 8. Governance Scope

The governance scope should clearly identify what is governed.

Scope may include:

* organizational units;
* business functions;
* jurisdictions;
* geographies;
* AI systems;
* AI-enabled activities;
* lifecycle stages;
* suppliers;
* technologies;
* business processes; and
* excluded activities.

Exclusions should have explicit rationale where their absence could otherwise create ambiguity.

***

## 9. Organizational Scope

The governance record may identify:

* legal entities;
* subsidiaries;
* business units;
* departments;
* functions;
* programs;
* regions; and
* shared services.

This establishes where the governance arrangement applies organizationally.

***

## 10. Geographic and Jurisdictional Scope

AI governance may differ across jurisdictions.

The record should identify applicable:

* countries;
* regions;
* legal jurisdictions;
* operating locations; and
* regulatory environments.

Jurisdictional scope is particularly important where requirements differ across locations.

***

## 11. AI Scope

The governance arrangement should identify which AI systems or AI-enabled activities are subject to governance.

The scope may cover:

* internally developed AI;
* externally provided AI;
* embedded AI;
* AI-enabled applications;
* generative AI;
* decision-support systems;
* autonomous systems;
* AI services;
* models;
* AI components; and
* other defined AI activities.

The AI System Schema provides the detailed machine-readable record for each governed AI system.

***

## 12. Exclusions

Organizations may exclude certain activities from scope.

Examples may include:

* non-AI systems;
* experimental environments;
* personal productivity tools;
* temporary development activities; or
* other defined categories.

Exclusions should be documented carefully.

A broad exclusion that removes material risk from governance should require appropriate authority and rationale.

***

## 13. Governance Authority

Governance authority establishes the basis on which the organization can:

* establish requirements;
* assign responsibilities;
* approve decisions;
* require assessments;
* accept risk;
* require remediation;
* suspend operation;
* restrict use; and
* retire systems.

The authority source may include:

* organizational mandate;
* board resolution;
* policy;
* governance charter;
* delegated authority;
* committee mandate; or
* other controlled source.

***

## 14. Authority Level

The governance schema supports authority levels such as:

```text theme={null}
ENTERPRISE
GROUP
BUSINESS_UNIT
FUNCTIONAL
SYSTEM
LOCAL
```

The authority level should correspond to the actual organizational governance structure.

Authority should not be inferred solely from the title of a role or committee.

***

## 15. Decision Rights

Governance should define decision rights explicitly.

Decision rights may include:

* system registration;
* classification;
* risk acceptance;
* control exception;
* deployment;
* continued operation;
* material change;
* incident escalation;
* suspension;
* resumption;
* retirement; and
* governance change.

Each decision should have an accountable owner and appropriate approval authority.

***

## 16. Governance Objectives

Governance objectives should describe the outcomes the governance arrangement is intended to achieve.

Examples include:

* effective AI accountability;
* proportionate risk management;
* reliable decision-making;
* human oversight;
* compliance;
* transparency;
* security;
* privacy;
* safety;
* fairness;
* traceability;
* resilience; and
* continual improvement.

Each material objective may have:

* owner;
* priority;
* target outcome;
* metric; and
* review requirement.

***

## 17. Governance Principles

The governance arrangement may identify applicable principles including:

* accountability;
* transparency;
* human oversight;
* risk management;
* security;
* privacy;
* fairness;
* safety;
* reliability;
* traceability;
* proportionality;
* continuous improvement;
* sustainability;
* explainability; and
* inclusiveness.

The principles should guide governance decisions and operating practices.

***

## 18. Governance Structure

The Governance Schema supports a structured governance hierarchy.

A conceptual structure is:

```text theme={null}
Executive / Board Authority
          ↓
Primary AI Governance Body
          ↓
AI Governance Committees
          ↓
Functional Governance
          ↓
AI System Owners / Risk Owners / Control Owners
          ↓
Operational Teams
```

The actual hierarchy should reflect the organization.

***

## 19. Governance Bodies

A governance body should identify:

* body identifier;
* name;
* purpose;
* authority;
* chair;
* members;
* meeting frequency;
* quorum; and
* decision types.

Examples include:

* AI Governance Committee;
* AI Risk Committee;
* Responsible AI Committee;
* Technology Risk Committee;
* Privacy Committee;
* Security Committee; and
* executive governance bodies.

***

## 20. Governance Committees

Committees may be established where governance requires collective decision-making.

The committee record should establish:

* purpose;
* authority;
* membership;
* chair;
* quorum;
* meeting frequency;
* decision rights;
* escalation; and
* records requirements.

Committee arrangements should avoid overlapping or conflicting decision rights.

***

## 21. Governance Roles

The governance record should identify key roles.

Typical roles include:

* AI Governance Owner;
* AI System Owner;
* Business Owner;
* Risk Owner;
* Control Owner;
* Technical Owner;
* Security Owner;
* Privacy Owner;
* Assurance Owner;
* Compliance Owner; and
* other organizational roles.

Each role should have clearly defined:

* responsibilities;
* authority;
* accountability;
* escalation path; and
* segregation requirements.

***

## 22. Role Accountability

Responsibility and accountability should remain distinguishable.

A role may perform a task without being accountable for the governance outcome.

The governance model should identify the person or function accountable for decisions and outcomes.

This is particularly important for:

* risk acceptance;
* system approval;
* material changes;
* incidents;
* exceptions; and
* retirement.

***

## 23. Segregation of Duties

Governance should establish segregation where required.

Potential separations include:

```text theme={null}
Requestor
    ≠
Assessor
    ≠
Approver
```

The required separation depends on:

* risk;
* decision significance;
* independence;
* organizational policy; and
* regulatory requirements.

Where segregation cannot be maintained, the exception should be controlled and documented.

***

## 24. Decision Authority

The Governance Schema supports a decision-authority model.

Each decision should identify:

* decision;
* decision owner;
* required reviews;
* approval authority;
* escalation requirements; and
* applicable conditions.

The decision authority should correspond to the governance arrangement and delegation model.

***

## 25. Delegated Authority

Governance may delegate authority.

A delegation should identify:

* delegator;
* delegate;
* authority type;
* scope;
* conditions;
* limitations;
* effective date; and
* expiry date where applicable.

Delegations should be controlled and reviewable.

Expired delegation should not be assumed to remain effective.

***

## 26. Reporting Structure

Governance reporting should provide appropriate visibility to management and governance bodies.

Reporting may include:

* AI inventory;
* risk;
* controls;
* monitoring;
* incidents;
* changes;
* assurance;
* accepted risks;
* exceptions;
* maturity;
* improvement; and
* retirement.

Reporting frequency should be proportional to governance needs.

***

## 27. Escalation Framework

Governance should define escalation criteria.

Possible triggers include:

* risk above tolerance;
* significant incident;
* critical control failure;
* material regulatory issue;
* major security or privacy issue;
* significant fairness or safety concern;
* material change;
* monitoring threshold breach;
* assurance finding; or
* governance failure.

Escalation levels should identify:

* criteria;
* authority;
* timeframe; and
* required actions.

***

## 28. Emergency Escalation

Emergency escalation should provide a rapid route for situations that cannot wait for ordinary governance cycles.

Examples include:

* imminent safety harm;
* serious security incident;
* significant privacy incident;
* major AI failure;
* regulatory emergency; or
* uncontrolled high-risk AI operation.

Emergency escalation should remain traceable and subject to retrospective review where appropriate.

***

## 29. AI System Governance

The governance arrangement should define how AI systems are governed across their lifecycle.

This may include requirements for:

* registration;
* inventory;
* profiling;
* classification;
* risk assessment;
* control implementation;
* approval;
* monitoring;
* assurance;
* change management;
* incident management; and
* retirement.

The AI System Schema provides the machine-readable operational representation of each system.

***

## 30. AI Inventory Governance

The organization should maintain an authoritative AI inventory.

Governance should identify:

* inventory owner;
* inventory location;
* registration requirements;
* review frequency;
* completeness expectations;
* status management; and
* escalation for unregistered AI.

An AI system should not enter governed operation without the required registration unless an authorized exception exists.

***

## 31. Classification Governance

Governance should establish:

* classification methodology;
* criteria;
* classification owner;
* approval authority;
* reclassification triggers; and
* review frequency.

Classification criteria may include:

* intended purpose;
* affected persons;
* autonomy;
* impact;
* risk;
* data sensitivity;
* safety;
* security;
* privacy;
* jurisdiction; and
* regulatory requirements.

Classification should be reviewed when material system characteristics change.

***

## 32. Risk Governance

Risk governance should define:

* risk methodology;
* risk owner;
* risk appetite;
* risk tolerance;
* assessment frequency;
* escalation thresholds;
* acceptance authority; and
* risk reporting.

The Governance record establishes the risk-management environment.

Individual risk records are maintained through the Risk Schema.

***

## 33. Control Governance

Control governance should establish:

* control framework;
* control ownership;
* assessment frequency;
* critical-control criteria;
* exception authority; and
* monitoring requirements.

The organization should maintain traceability between:

```text theme={null}
Requirement
   ↓
Risk
   ↓
Control
   ↓
Assessment
   ↓
Evidence
   ↓
Assurance
```

***

## 34. Lifecycle Governance

Governance should apply throughout the AI lifecycle.

Lifecycle stages may include:

1. Planning
2. Design
3. Development
4. Data Preparation
5. Testing and Validation
6. Approval
7. Deployment
8. Operation
9. Monitoring
10. Change
11. Assurance
12. Retirement

Governance should establish stage-gate requirements, required reviews, evidence, and approval authority.

***

## 35. Lifecycle Stage Gates

A stage gate should define:

* lifecycle stage;
* required reviews;
* required evidence;
* approval authority; and
* exit criteria.

A system should not progress through a controlled stage gate without satisfying the applicable requirements or receiving an authorized exception.

***

## 36. Human Oversight Governance

Governance should establish when human oversight is required.

It may define:

* oversight model;
* competence;
* authority;
* intervention;
* override;
* escalation;
* review;
* monitoring; and
* restrictions on automated operation.

Human oversight requirements should be proportionate to risk and impact.

***

## 37. Monitoring Governance

The governance arrangement should define:

* monitoring ownership;
* required monitoring categories;
* minimum frequency;
* thresholds;
* escalation;
* enhanced-monitoring triggers; and
* monitoring review.

The Monitoring Schema provides the operational record structure.

Governance should ensure that material risks have appropriate monitoring coverage.

***

## 38. Assurance Governance

Governance should define:

* assurance owner;
* assurance types;
* minimum frequency;
* independence requirements;
* follow-up; and
* escalation.

Assurance plans should be risk-based.

High-risk AI systems and critical controls may require more frequent or more independent assurance.

***

## 39. Incident Governance

Incident governance should establish:

* incident procedure;
* incident owner;
* severity model;
* notification requirements;
* escalation;
* closure requirements; and
* post-incident review.

The Incident Schema provides the machine-readable incident record.

Incident governance should connect incidents to:

* risk;
* controls;
* monitoring;
* changes;
* assurance; and
* improvement.

***

## 40. Change Governance

Change governance should establish:

* change procedure;
* change owner;
* materiality criteria;
* approval authority;
* testing;
* rollback;
* post-implementation validation; and
* monitoring.

Material changes should not bypass governance without an explicitly controlled emergency or exception pathway.

***

## 41. Risk Acceptance Governance

Governance should define:

* when risk acceptance is required;
* acceptance authority;
* conditions;
* expiry;
* review frequency; and
* escalation.

Risk acceptance should be separate from ordinary risk assessment.

The Risk record identifies the risk.

The Risk Acceptance or Approval record provides the formal decision where required.

***

## 42. Retirement Governance

Governance should establish:

* retirement triggers;
* approval authority;
* readiness requirements;
* data disposition;
* closure requirements;
* evidence retention; and
* post-retirement obligations.

Retirement should be governed as a lifecycle transition, not simply a technical shutdown.

***

## 43. Third-Party Governance

Where external AI providers are used, governance should establish:

* due diligence;
* supplier risk assessment;
* contractual requirements;
* security;
* privacy;
* assurance;
* monitoring;
* incident notification;
* material change notification; and
* termination requirements.

Third-party governance should maintain accountability even when services are externally provided.

***

## 44. Regulatory and External Requirements

The governance arrangement should identify applicable:

* laws;
* regulations;
* standards;
* contracts;
* internal policies; and
* external commitments.

Each requirement may identify:

* source;
* reference;
* requirement;
* applicability;
* owner;
* evidence; and
* review frequency.

External mapping repositories provide detailed framework mappings.

Current AIGO mapping structures include:

```text theme={null}
mappings/iso-42001/
mappings/nist-ai-rmf/
mappings/eu-ai-act/
mappings/other/
```

***

## 45. Documentation Governance

Governance should establish controls for:

* controlled documents;
* repositories;
* ownership;
* retention;
* review;
* versioning;
* change control; and
* access.

Documents should remain traceable to the governance arrangement and associated records.

***

## 46. Evidence Governance

Governance should establish:

* evidence repository;
* evidence ownership;
* minimum evidence requirements;
* retention;
* access;
* quality;
* integrity; and
* review.

The Evidence Schema provides the operational structure for evidence records.

***

## 47. Exception Governance

Exceptions should be controlled.

An exception process should establish:

* request;
* requirement;
* reason;
* risk;
* compensating controls;
* duration;
* approval authority;
* monitoring; and
* review.

Exceptions should be time-bounded where practical.

Repeated exceptions may indicate that the underlying requirement or operating model should be reviewed.

***

## 48. Governance Metrics

Governance metrics should measure whether governance is functioning as intended.

Possible metrics include:

* AI registration coverage;
* classification completion;
* risk assessment completion;
* control effectiveness;
* approval timeliness;
* monitoring coverage;
* incident response;
* assurance completion;
* improvement completion;
* retirement completion;
* evidence completeness; and
* governance maturity.

Metrics should have:

* definition;
* owner;
* frequency;
* target;
* threshold; and
* reporting destination.

***

## 49. Governance Maturity

The Governance Schema supports representation of governance maturity.

Maturity information may include:

* current level;
* target level;
* maturity model;
* strengths;
* gaps;
* assessment;
* improvement actions.

A maturity score should be supported by an appropriate assessment method.

Maturity should not replace direct measurement of governance effectiveness.

***

## 50. Management Review Governance

Governance should establish:

* management review requirement;
* frequency;
* authority;
* inputs;
* outputs;
* review criteria; and
* follow-up.

Management review should evaluate the continuing suitability, adequacy, effectiveness, and performance of AI governance.

The Management Review Schema provides the operational record.

***

## 51. Continual-Improvement Governance

Governance should establish:

* improvement requirement;
* improvement sources;
* prioritization;
* ownership;
* verification;
* standardization; and
* reporting.

Improvements may originate from:

* incidents;
* assurance;
* monitoring;
* risk;
* control assessments;
* stakeholder feedback;
* maturity assessment;
* regulatory change; and
* management review.

***

## 52. Resource Governance

AI governance requires appropriate resources.

Governance should consider:

* staffing;
* competence;
* technology;
* funding;
* specialist support;
* infrastructure; and
* governance capacity.

Resource constraints that materially affect governance effectiveness should be recorded and escalated.

***

## 53. Training and Competence Governance

Governance should define competence requirements for relevant roles.

Training governance may include:

* required roles;
* competencies;
* training topics;
* frequency;
* owner;
* completion monitoring; and
* effectiveness.

Competence requirements should be proportionate to role and risk.

***

## 54. Communication Governance

Governance should establish:

* stakeholder groups;
* communication channels;
* communication frequency;
* disclosure requirements;
* owner; and
* escalation.

Communication should be proportionate to system impact and governance significance.

***

## 55. Governance Changes

Changes to the governance arrangement should be formally controlled.

Governance changes may concern:

* structure;
* roles;
* authority;
* policy;
* procedure;
* controls;
* lifecycle;
* risk;
* monitoring;
* assurance;
* regulatory requirements; or
* documentation.

A governance change may require:

* impact assessment;
* risk assessment;
* approval;
* implementation;
* communication; and
* verification.

The Change Schema may be used where the governance change is managed as a formal change.

***

## 56. Governance Approvals

The Governance record may reference formal approvals establishing or modifying the governance arrangement.

Approval information should identify:

* approval ID;
* approval type;
* decision;
* authority;
* date;
* conditions; and
* evidence.

An approval record remains authoritative for the individual decision.

***

## 57. Governance Review Schedule

The governance arrangement should be reviewed periodically and when triggered.

Triggers may include:

* significant incidents;
* material AI changes;
* regulatory developments;
* assurance findings;
* strategic changes;
* technology developments;
* changes in risk appetite;
* maturity findings; or
* significant organizational changes.

The review schedule should identify:

* frequency;
* next review date;
* review owner; and
* trigger criteria.

***

## 58. Governance Traceability

The Governance record should maintain traceability to the AIGO framework architecture.

The logical relationship is:

```text theme={null}
Governance Authority
        ↓
Governance Structure
        ↓
Roles / Decision Rights
        ↓
AI System Governance
        ↓
Risk / Controls / Lifecycle
        ↓
Monitoring / Assurance / Incidents / Changes
        ↓
Management Review
        ↓
Improvement
        ↓
Governance Change
```

This supports controlled evolution of the governance arrangement.

***

## 59. Governance and AI Portfolio

At portfolio level, governance should provide visibility across:

* all registered AI systems;
* classifications;
* risks;
* controls;
* approvals;
* incidents;
* changes;
* assurance;
* monitoring;
* improvement; and
* retirement.

Portfolio-level aggregation should not replace the individual records required for operational accountability.

***

## 60. Governance and Risk Appetite

The governance arrangement should establish or reference the organization's AI risk appetite.

Risk appetite should guide:

* classification;
* risk evaluation;
* treatment;
* acceptance;
* escalation;
* approval;
* monitoring; and
* management review.

Risk tolerance may be more specific and operational than risk appetite.

Both should be governed and maintained as controlled concepts.

***

## 61. Governance and Accountability

Ultimate accountability should be identifiable.

The governance structure should prevent situations where:

* responsibility is distributed without accountability;
* approval authority is unclear;
* risks have no owner;
* controls have no owner;
* incidents have no accountable coordinator; or
* governance bodies have overlapping decision rights.

Clear accountability is a foundational governance requirement.

***

## 62. Governance and Proportionality

Governance should be proportionate to:

* AI system risk;
* potential impact;
* autonomy;
* affected-person scale;
* regulatory requirements;
* organizational complexity;
* system criticality;
* technology;
* supplier dependence; and
* lifecycle stage.

Not every AI system requires identical governance controls.

The governance arrangement should define the criteria used to apply proportionate governance.

***

## 63. Governance and Independence

Certain functions may require independence from operational ownership.

Independence may be particularly important for:

* assurance;
* risk challenge;
* control assessment;
* significant approvals;
* investigations;
* high-consequence assessments; and
* management escalation.

Independence requirements should be explicit.

***

## 64. Governance Records

The Governance record should establish the relationships among the organization's controlled AI governance records.

Typical record families include:

```text theme={null}
Governance
AI System
Risk
Control
Assessment
Approval
Monitoring
Incident
Change
Assurance
Evidence
Management Review
Improvement
Retirement
```

These records should maintain common identifiers and traceability.

***

## 65. Governance Validation Requirements

A valid Governance record should satisfy:

### Structural Validation

The JSON document must validate against:

`14-AIGO-Governance-Schema-v0.1.json`

### Scope Validation

Governance scope should be explicitly defined.

### Authority Validation

Governance authority and decision rights should be identifiable.

### Objective Validation

Governance objectives should be established.

### Structure Validation

Governance bodies and reporting relationships should be defined.

### Role Validation

Relevant roles should have accountable responsibilities.

### Decision Authority Validation

Material decisions should have defined approval authority.

### Risk Governance Validation

Risk appetite, tolerance, ownership, and escalation should be defined where applicable.

### Control Governance Validation

Control ownership and assessment requirements should be established.

### Lifecycle Validation

Lifecycle governance and stage-gate requirements should be defined.

### Monitoring Validation

Required monitoring governance should be defined.

### Assurance Validation

Assurance requirements and independence should be established.

### Incident Validation

Incident governance and escalation should be defined.

### Change Validation

Material-change criteria and approval requirements should be defined.

### Retirement Validation

Retirement requirements should be established.

### Evidence Validation

Evidence governance and retention should be addressed.

### Management Review Validation

Management review requirements should be defined.

### Improvement Validation

Continual-improvement governance should be established.

### Traceability Validation

The governance arrangement should remain traceable to the underlying AIGO framework and operational records.

***

## 66. Schema Limitations

JSON Schema cannot independently determine:

* whether governance authority is legally valid;
* whether governance bodies are actually effective;
* whether roles have sufficient competence;
* whether decision rights are appropriately allocated;
* whether governance objectives are achieved;
* whether risk appetite is reasonable;
* whether controls are effective;
* whether governance is proportionate;
* whether management exercises sufficient oversight; or
* whether the governance arrangement complies with all applicable obligations.

Those matters require organizational governance, evidence, assessment, assurance, and management judgment.

***

## 67. Relationship to Templates

The Governance Schema corresponds primarily to:

`guidance/03-templates/01-AIGO-AI-Governance-Template-v0.1.md`

It also provides organizational context for records created through:

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

The Markdown template provides the human-readable governance record.

The JSON schema provides the machine-readable structure.

***

## 68. Relationship to Procedures

The Governance Schema should be used with applicable governance procedures, including:

`guidance/02-procedures/01-AIGO-AI-Governance-Procedure-v0.1.md`

and supporting procedures for:

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

The procedures define how governance is operated.

***

## 69. Framework Traceability

| AIGO Component          | Relationship                                      |
| ----------------------- | ------------------------------------------------- |
| Framework Charter       | Establishes framework authority and scope         |
| Framework Principles    | Establishes governance principles                 |
| Governance Domains      | Defines governed AI areas                         |
| Governance Roles        | Defines roles and accountability                  |
| AI Governance Lifecycle | Defines lifecycle governance                      |
| AI Risk Management      | Provides risk governance structure                |
| AI Governance Controls  | Provides control governance                       |
| AI Governance Maturity  | Provides maturity framework                       |
| AI System Profiles      | Provides AI-system context                        |
| Implementation Guidance | Defines operational governance implementation     |
| Operational Procedures  | Defines governance processes                      |
| Templates               | Provides human-readable governance records        |
| External Mappings       | Provides external requirements and traceability   |
| Schemas                 | Provides machine-readable governance structures   |
| Tools                   | Provides future validation and repository support |

***

## 70. Governance Traceability Model

The recommended governance traceability chain is:

```text theme={null}
Governance Authority
        ↓
Governance Objectives
        ↓
Governance Structure
        ↓
Roles / Decision Rights
        ↓
Requirements
        ↓
Risks
        ↓
Controls
        ↓
Assessments
        ↓
Approvals
        ↓
Monitoring
        ↓
Incidents / Changes / Assurance
        ↓
Evidence
        ↓
Management Review
        ↓
Improvement
        ↓
Governance Change
```

This creates an end-to-end relationship between organizational governance and operational AI governance.

***

## 71. Example Record

A conceptual Governance record may look like:

```json theme={null}
{
  "id": "GOV-001",
  "objectType": "GOVERNANCE",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "ACTIVE",
  "governanceName": "Enterprise AI Governance Arrangement",
  "governanceOwner": {
    "role": "AI Governance Owner"
  },
  "governanceScope": {
    "description": "Enterprise AI systems and AI-enabled activities within the organization's defined scope.",
    "aiSystemIds": [
      "AI-SYS-001",
      "AI-SYS-002"
    ]
  },
  "governanceObjectives": [
    {
      "objectiveId": "OBJ-001",
      "description": "Ensure AI systems are appropriately governed throughout their lifecycle.",
      "priority": "HIGH",
      "owner": {
        "role": "AI Governance Owner"
      }
    }
  ],
  "governanceStructure": {
    "primaryGovernanceBody": "AI Governance Committee"
  },
  "riskGovernance": {
    "riskAppetite": "AI risk should remain within approved organizational tolerance.",
    "riskTolerance": "Material risks above defined tolerance require escalation."
  },
  "lifecycleGovernance": {
    "requiredStages": [
      "PLANNING",
      "DESIGN",
      "DEVELOPMENT",
      "TESTING",
      "APPROVAL",
      "DEPLOYMENT",
      "OPERATION",
      "MONITORING",
      "CHANGE",
      "ASSURANCE",
      "RETIREMENT"
    ]
  },
  "reviewSchedule": {
    "frequency": "ANNUAL"
  }
}
```

The actual record must conform to the authoritative JSON schema.

***

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

***

## 73. Change and Version Management

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

Potential impacts should be assessed against:

* governance documents;
* governance procedures;
* roles;
* decision authority;
* committees;
* risk management;
* controls;
* lifecycle governance;
* monitoring;
* assurance;
* incidents;
* changes;
* management review;
* improvement;
* external mappings;
* schemas; and
* validation tooling.

Breaking changes should include migration guidance where necessary.

Governance-schema changes may have organizational consequences and therefore should receive appropriate governance approval.

***

## 74. Future Extensions

Future versions may support:

* machine-readable governance charters;
* organizational hierarchy integration;
* policy-as-code;
* automated decision-right validation;
* committee workflow;
* governance authority validation;
* automated regulatory applicability;
* portfolio governance analytics;
* governance maturity analytics;
* machine-readable risk appetite rules;
* automated lifecycle gate enforcement; and
* cross-organization governance federation.

Extensions should preserve explicit authority, accountability, traceability, and governance integrity.

***

## 75. Document Control

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

***

## 76. Document Status

**Document:** AIGO — Governance Schema Documentation

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

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

**Document Type:** Schema Documentation

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

End of Document