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

# 07 AIGO Incident Schema Documentation v0.1

# AIGO — Incident Schema Documentation

## 1. Document Purpose

This document describes the machine-readable AIGO Incident Schema.

The schema provides the structured representation of AI-related incidents managed under the AIGO AI Governance Operating Framework.

It is intended to support:

* incident identification;
* incident registration;
* detection and triage;
* incident classification;
* severity assessment;
* affected AI system identification;
* affected-person and stakeholder impact;
* containment;
* investigation;
* root-cause analysis;
* corrective action;
* recovery;
* notification and escalation;
* evidence management;
* risk reassessment;
* control reassessment;
* change management;
* assurance;
* lessons learned;
* continual improvement; and
* incident closure.

The JSON schema defines structural requirements.

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

***

## 2. Schema Information

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

***

## 3. Scope

The Incident Schema applies to incidents involving:

* AI systems;
* AI models;
* AI-enabled business processes;
* AI data;
* AI infrastructure;
* human oversight;
* governance controls;
* third-party AI services;
* security;
* privacy;
* fairness;
* safety;
* reliability;
* compliance; and
* other AI-related operational or governance conditions.

An incident should be registered when an event or condition meets the organization's approved incident criteria.

Not every abnormal condition is necessarily an incident.

The organization should distinguish incidents from:

* ordinary monitoring alerts;
* routine defects;
* expected operational events;
* risks;
* control deficiencies; and
* change requests.

A monitoring alert may become an incident when defined incident criteria are met.

***

## 4. Object Model

The primary object represented by this schema is:

```text id="qeqtlv" theme={null}
INCIDENT
```

An Incident record represents a defined AI-related event or condition requiring formal investigation, response, escalation, or governance action.

The Incident record should remain distinct from:

* the AI System record;
* the Risk record;
* the Control record;
* the Monitoring record;
* the Change record;
* the Assessment record;
* the Assurance record; and
* Evidence records.

Related records should normally be connected through stable identifiers.

***

## 5. Core Identity

An Incident record should contain stable identity information.

Key fields include:

* `id`;
* `objectType`;
* `objectVersion`;
* `schemaVersion`;
* incident title;
* incident status;
* incident severity;
* detection information;
* incident owner; and
* affected AI system.

Example:

```json id="2av0xn" theme={null}
{
  "id": "INC-001",
  "objectType": "INCIDENT",
  "objectVersion": "1.0",
  "schemaVersion": "0.1"
}
```

The incident identifier should remain stable throughout the investigation and closure lifecycle.

A materially distinct incident should normally receive a new identifier.

***

## 6. Incident Title and Description

The incident should have a concise title and a sufficiently detailed description.

The description should explain:

* what happened;
* when it occurred;
* what was observed;
* what system or process was involved;
* what was affected; and
* why the event is considered an incident.

The initial description may be updated as the investigation develops, but historical information should remain traceable.

***

## 7. Incident Detection

The record should identify how the incident was detected.

Possible detection sources include:

* monitoring;
* user report;
* affected-person report;
* employee report;
* security monitoring;
* privacy monitoring;
* automated detection;
* supplier notification;
* audit;
* assurance;
* testing;
* management review;
* regulatory notification; or
* another source.

Detection information should include, where applicable:

* detection date and time;
* detection source;
* detecting party;
* detection method; and
* related monitoring or evidence reference.

***

## 8. Incident Classification

The incident should be classified according to the organization's approved incident taxonomy.

Classification may consider:

* safety;
* security;
* privacy;
* fairness;
* discrimination;
* reliability;
* performance;
* governance;
* compliance;
* data;
* model;
* human oversight;
* third-party;
* operational; and
* other relevant categories.

An incident may have more than one category.

The classification should be revisited if investigation reveals additional impacts.

***

## 9. Incident Severity

Incident severity indicates the significance of the incident.

Severity may consider:

* actual impact;
* potential impact;
* number of affected persons;
* duration;
* geographic scope;
* business impact;
* safety impact;
* privacy impact;
* security impact;
* legal or regulatory significance;
* reputational impact;
* reversibility; and
* systemic implications.

The authoritative severity enumeration defined in the JSON schema is controlling.

Severity should be reassessed when material new information becomes available.

***

## 10. Incident Status

The schema supports incident lifecycle status.

Typical conceptual states include:

```text id="hb2r3a" theme={null}
DETECTED
REGISTERED
TRIAGED
UNDER_INVESTIGATION
CONTAINED
REMEDIATION_IN_PROGRESS
RECOVERY_IN_PROGRESS
AWAITING_REVIEW
CLOSED
CLOSED_WITH_FOLLOW_UP
REOPENED
```

The exact enumeration in the JSON schema is authoritative.

Status represents lifecycle state and does not itself establish that required governance actions have been completed.

***

## 11. Incident Owner

Each material incident should have an accountable incident owner.

The incident owner is responsible for coordinating:

* triage;
* investigation;
* containment;
* escalation;
* communications;
* remediation;
* recovery;
* evidence preservation;
* risk reassessment;
* closure; and
* lessons learned.

Operational activities may be delegated to specialized teams.

***

## 12. AI System Relationship

The incident should reference the affected AI System record.

Example:

```json id="g1v7ab" theme={null}
{
  "id": "INC-001",
  "aiSystemId": "AI-SYS-001"
}
```

Where an incident affects several systems, the record should support multiple system references where permitted.

The AI System record remains authoritative for system identity and lifecycle information.

***

## 13. System Version and Configuration

Where relevant, the incident should identify:

* AI system version;
* model version;
* configuration;
* deployment environment;
* relevant release;
* affected component; and
* relevant change identifier.

This supports investigation and reproducibility.

***

## 14. Incident Timeline

A material incident should preserve a timeline.

The timeline may contain:

```text id="1ib9jd" theme={null}
Detection
Registration
Triage
Escalation
Containment
Investigation
Root Cause Identified
Remediation
Recovery
Verification
Closure
```

Individual events should include timestamps where appropriate.

A reliable incident timeline is important for:

* investigation;
* accountability;
* assurance;
* regulatory response; and
* lessons learned.

***

## 15. Initial Triage

Initial triage should determine:

* whether the event meets incident criteria;
* preliminary severity;
* affected systems;
* affected persons;
* immediate risks;
* immediate containment needs;
* notification requirements;
* escalation requirements; and
* investigation ownership.

Triage information may change as facts become known.

The record should distinguish preliminary conclusions from validated findings.

***

## 16. Immediate Impact Assessment

The initial impact assessment should consider:

* people;
* safety;
* privacy;
* security;
* fairness;
* business operations;
* financial impact;
* regulatory impact;
* reputation;
* service availability;
* downstream systems; and
* third parties.

Potential impact may be recorded even where actual impact is not yet known.

***

## 17. Affected Persons and Stakeholders

Where an incident may affect people, the record should identify relevant groups where appropriate.

Examples include:

* customers;
* employees;
* applicants;
* users;
* suppliers;
* members of the public;
* vulnerable groups; and
* other affected persons.

The record should capture:

* affected group;
* nature of impact;
* actual or potential harm;
* severity;
* communication requirements; and
* remediation.

Personal information should be minimized and protected in accordance with applicable privacy and security requirements.

***

## 18. Incident Containment

Containment is intended to prevent additional harm while the incident is investigated.

Containment actions may include:

* suspending the AI system;
* restricting functionality;
* restricting users;
* disabling an integration;
* reverting a configuration;
* restricting data access;
* activating human review;
* switching to a fallback process;
* isolating an infrastructure component; or
* disabling external connectivity.

Containment should identify:

* action;
* owner;
* time;
* authority;
* status; and
* evidence.

***

## 19. Emergency Controls

Emergency controls may be applied where immediate action is necessary.

Examples include:

* temporary manual processing;
* emergency human approval;
* temporary restrictions;
* additional review;
* blocking high-risk outputs;
* disabling automated decisions; or
* enhanced monitoring.

Emergency measures should be documented and reviewed retrospectively where required.

***

## 20. Incident Investigation

The investigation should establish, as far as reasonably possible:

* what occurred;
* when it occurred;
* why it occurred;
* what components were involved;
* what controls were expected;
* what controls operated;
* what controls failed;
* actual and potential impacts;
* contributing factors;
* root causes;
* affected records; and
* required remediation.

The investigation should distinguish facts from assumptions and unresolved questions.

***

## 21. Evidence Preservation

Incident evidence should be preserved appropriately.

Evidence may include:

* logs;
* model outputs;
* inputs;
* configuration;
* system state;
* screenshots;
* monitoring data;
* communications;
* user reports;
* access records;
* test results;
* code or model versions;
* supplier records; and
* other relevant artifacts.

Where chain of custody is important, it should be maintained.

The Evidence Schema provides the formal machine-readable structure for evidence management.

***

## 22. Root-Cause Analysis

Root-cause analysis should determine why the incident occurred rather than merely describing the immediate failure.

Potential root causes include:

* inadequate governance;
* insufficient controls;
* technical defect;
* data-quality issue;
* model behavior;
* configuration;
* inadequate testing;
* insufficient monitoring;
* human error;
* competence gap;
* supplier failure;
* process failure;
* change-management failure; or
* external conditions.

A single incident may have multiple contributing causes.

***

## 23. Control Failure Analysis

The investigation should determine which controls were:

* expected to operate;
* operating as designed;
* operating ineffectively;
* bypassed;
* unavailable;
* incorrectly configured; or
* missing.

Control failures should be traceable to relevant Control records and, where required, Control Assessment records.

***

## 24. Risk Relationship

An incident may:

* realize an existing risk;
* increase an existing risk;
* reveal a new risk;
* demonstrate that a risk assessment was inadequate; or
* require new risk treatment.

The incident may therefore reference relevant risks.

Example:

```json id="3e4w3g" theme={null}
{
  "id": "INC-001",
  "riskIds": [
    "RISK-001",
    "RISK-007"
  ]
}
```

The Risk Schema remains authoritative for the enduring risk.

The Incident record captures the incident-specific consequences and governance response.

***

## 25. Risk Reassessment

An incident should trigger risk reassessment when material conditions indicate that:

* likelihood has changed;
* impact has changed;
* existing controls are inadequate;
* new risks exist;
* residual risk exceeds tolerance;
* affected-person impact is greater than expected; or
* system context has changed.

The resulting assessment should be independently recorded and referenced.

***

## 26. Classification Reassessment

An incident may reveal that an AI system was incorrectly classified.

Examples include:

* previously unrecognized impact;
* expanded use case;
* increased autonomy;
* broader affected population;
* increased regulatory significance; or
* newly identified safety or fairness concerns.

Where classification may have changed, the system should be reassessed using the organization's classification procedure.

***

## 27. Incident Remediation

Remediation should address the immediate incident and underlying causes where practical.

Actions may include:

* correcting defective behavior;
* restoring services;
* changing controls;
* updating data;
* changing model configuration;
* retraining;
* changing workflows;
* improving human oversight;
* improving monitoring;
* updating procedures;
* addressing supplier issues; or
* other corrective action.

Remediation actions should have:

* owner;
* priority;
* target date;
* status;
* verification requirement; and
* completion evidence.

***

## 28. Corrective and Preventive Action

Corrective action addresses the identified incident cause or deficiency.

Preventive action addresses recurrence or similar incidents.

A mature incident process should consider both.

The organization should distinguish:

```text id="4d4y9h" theme={null}
Containment
     ↓
Correction
     ↓
Corrective Action
     ↓
Preventive Action
     ↓
Verification
```

***

## 29. Recovery

Recovery returns the AI system or affected business process to an authorized operating condition.

Recovery may require:

* restoring services;
* validating system state;
* restoring data;
* restoring configuration;
* re-establishing monitoring;
* re-establishing controls;
* confirming human oversight;
* confirming security and privacy safeguards; and
* obtaining resumption approval where required.

Recovery should not be treated as complete merely because technical services are available again.

***

## 30. Resumption Approval

Where an AI system was suspended or restricted, operation may require formal resumption approval.

The approval should consider:

* incident status;
* remediation;
* residual risk;
* testing;
* control effectiveness;
* monitoring;
* human oversight;
* assurance; and
* any applicable conditions.

The Approval Schema remains authoritative for the formal decision.

***

## 31. Notification and Communication

Incidents may require internal or external notification.

Potential recipients include:

* governance bodies;
* executive management;
* system owners;
* risk owners;
* security teams;
* privacy teams;
* affected persons;
* customers;
* suppliers;
* regulators; and
* other authorities.

Notification requirements should be determined by:

* incident severity;
* impact;
* legal requirements;
* regulatory requirements;
* contractual requirements; and
* organizational policy.

***

## 32. Communication Records

Incident communications should be traceable where material.

The incident record may identify:

* recipient group;
* purpose;
* communication date;
* responsible party;
* response;
* notification status; and
* evidence.

Sensitive communications should be handled using appropriate security controls.

***

## 33. Third-Party Incidents

Where a supplier or external AI provider is involved, the incident record should identify:

* supplier;
* affected service;
* contractual relationship;
* supplier notification;
* supplier response;
* supplier investigation;
* required evidence;
* contractual obligations; and
* remediation.

Supplier incidents may require changes to supplier risk assessments, contracts, controls, monitoring, or assurance.

***

## 34. Security Incidents

Security-related AI incidents may include:

* unauthorized access;
* data compromise;
* prompt injection;
* model manipulation;
* model extraction;
* adversarial attacks;
* compromised credentials;
* malicious data;
* system compromise; or
* other security events.

Security incident handling should integrate with the organization's security incident-management process.

***

## 35. Privacy Incidents

Privacy-related AI incidents may involve:

* unauthorized disclosure;
* inappropriate data use;
* excessive data collection;
* retention failure;
* unauthorized access;
* unlawful processing;
* data leakage; or
* other privacy violations.

The incident process should coordinate with applicable privacy procedures.

***

## 36. Fairness and Discrimination Incidents

Fairness-related incidents may involve:

* disproportionate outcomes;
* discriminatory behavior;
* biased recommendations;
* group-level performance degradation;
* inappropriate use;
* ineffective mitigation; or
* affected-person complaints.

The investigation should preserve relevant group-level evidence while protecting personal information.

***

## 37. Safety Incidents

Safety-related AI incidents may include:

* unsafe output;
* unsafe action;
* control failure;
* failure of human oversight;
* dangerous model behavior;
* unexpected system interaction;
* near miss; or
* safety-critical degradation.

Safety incidents may require immediate suspension, restriction, or escalation.

***

## 38. Monitoring Relationship

Monitoring may detect an incident.

The recommended relationship is:

```text id="i2f9it" theme={null}
Monitoring
    ↓
Alert
    ↓
Triage
    ↓
Incident
```

The monitoring record should identify the alert and indicator.

The incident record should determine whether incident criteria are met.

This preserves the distinction between operational monitoring and formal incident management.

***

## 39. Change Management Relationship

Incident remediation may require changes to:

* system;
* model;
* data;
* controls;
* monitoring;
* processes;
* architecture;
* configuration;
* suppliers; or
* governance arrangements.

Material remediation changes should be governed through the AIGO Change process.

The Change record remains authoritative for the change.

***

## 40. Assurance Relationship

Significant incidents may require assurance or independent review.

Assurance may examine:

* incident response;
* root-cause analysis;
* containment;
* remediation;
* control failures;
* reporting;
* evidence;
* risk reassessment; and
* lessons learned.

The Assurance Schema remains authoritative for assurance findings and conclusions.

***

## 41. Lessons Learned

Every material incident should consider lessons learned.

Lessons may concern:

* governance;
* risk;
* controls;
* monitoring;
* technical design;
* human oversight;
* supplier management;
* change management;
* procedures;
* competence;
* evidence; and
* assurance.

Lessons learned should be converted into improvement actions when appropriate.

***

## 42. Continual Improvement

The incident-to-improvement relationship may be:

```text id="0b0z8q" theme={null}
Incident
   ↓
Finding / Root Cause
   ↓
Improvement Opportunity
   ↓
Improvement Action
   ↓
Implementation
   ↓
Verification
```

The Improvement Schema remains authoritative for the improvement record.

***

## 43. Incident Closure

An incident should be closed only when the applicable closure criteria have been met.

Closure may require confirmation that:

* containment is complete;
* investigation is complete;
* remediation is complete;
* required notifications occurred;
* residual risk is addressed;
* required controls are operational;
* required monitoring is active;
* evidence is preserved;
* lessons are recorded; and
* follow-up actions are assigned.

An incident may be closed with follow-up where the incident is resolved but additional governance actions remain open.

***

## 44. Reopening an Incident

An incident may need to be reopened when:

* new evidence emerges;
* the root cause was incorrect;
* remediation failed;
* additional impact is discovered;
* related incidents occur; or
* regulatory or assurance review identifies a material gap.

The reopening should preserve the original closure history.

***

## 45. Incident Evidence

Incident evidence should be sufficient to establish:

* what occurred;
* what was affected;
* how the incident was detected;
* how it was handled;
* what decisions were taken;
* why those decisions were taken; and
* what remediation was completed.

Evidence should be linked through stable evidence identifiers.

***

## 46. Evidence Integrity and Chain of Custody

Where evidence may be used for:

* legal proceedings;
* regulatory reporting;
* formal assurance;
* disciplinary processes;
* contractual disputes; or
* high-consequence investigations,

the organization should consider enhanced evidence integrity and chain-of-custody controls.

The Evidence Schema supports these requirements.

***

## 47. Incident Reporting

Incident records may support governance reporting.

Useful metrics include:

| Metric                                      | Purpose                  |
| ------------------------------------------- | ------------------------ |
| Incident count                              | Incident activity        |
| Incidents by severity                       | Exposure profile         |
| Incident detection time                     | Monitoring effectiveness |
| Time to containment                         | Response effectiveness   |
| Time to recovery                            | Operational resilience   |
| Repeat incidents                            | Recurrence               |
| Incidents by cause                          | Root-cause trends        |
| Incidents by control failure                | Control weakness         |
| Incidents by AI system                      | System concentration     |
| Open incidents                              | Governance backlog       |
| Incidents requiring escalation              | Governance significance  |
| Incidents requiring regulatory notification | External exposure        |

Metrics should use controlled definitions and consistent reporting periods.

***

## 48. Incident Trend Analysis

Management should consider incident trends across:

* AI systems;
* model versions;
* business units;
* suppliers;
* incident categories;
* severity;
* root causes;
* controls; and
* lifecycle stages.

Trend analysis may identify systemic weaknesses not visible from individual incidents.

Systemic observations should be escalated into risk, assurance, or improvement processes where appropriate.

***

## 49. Incident Validation Requirements

A valid Incident record should satisfy:

### Structural Validation

The JSON document must validate against:

`07-AIGO-Incident-Schema-v0.1.json`

### Identity Validation

The incident identifier must be unique and stable.

### Classification Validation

Incident type and severity should use controlled values.

### Ownership Validation

A responsible incident owner should be assigned.

### System Validation

Affected AI systems should be identifiable where applicable.

### Impact Validation

Material actual or potential impact should be documented.

### Evidence Validation

Material investigative conclusions should have appropriate evidence.

### Escalation Validation

Required escalation should be documented.

### Risk Validation

Material risk implications should be assessed.

### Remediation Validation

Required remediation actions should have owners and target dates.

### Closure Validation

Closure should satisfy defined incident closure criteria.

### Traceability Validation

Incident relationships to monitoring, risk, controls, changes, assurance, evidence, and improvements should be maintained.

***

## 50. Schema Limitations

JSON Schema cannot independently determine:

* whether an event actually occurred;
* whether incident classification is correct;
* whether severity is appropriate;
* whether impact was fully identified;
* whether root-cause analysis is accurate;
* whether remediation is adequate;
* whether notification was legally sufficient;
* whether an incident should remain open; or
* whether recovery is safe.

Those matters require operational processes, investigation, evidence, qualified judgment, and assurance.

***

## 51. Relationship to Templates

The Incident Schema corresponds primarily to:

`guidance/03-templates/10-AIGO-AI-Incident-Template-v0.1.md`

It may also interact with:

* monitoring templates;
* risk assessment templates;
* control assessment templates;
* change-management templates;
* assurance templates;
* evidence templates;
* approval templates; and
* continuous-improvement templates.

The Markdown template provides the human-readable incident record.

The JSON schema provides the machine-readable structure.

***

## 52. Relationship to Procedures

The schema should be used with:

`guidance/02-procedures/08-AIGO-AI-Incident-Management-Procedure-v0.1.md`

and, where applicable:

* AI governance;
* risk assessment;
* control assessment;
* monitoring;
* approval;
* change management;
* assurance;
* risk acceptance;
* continuous improvement; and
* retirement procedures.

The procedure defines incident detection, triage, escalation, containment, investigation, remediation, recovery, notification, and closure.

***

## 53. Framework Traceability

| AIGO Component          | Relationship                                       |
| ----------------------- | -------------------------------------------------- |
| Governance Domains      | Defines incident authority and governance response |
| Governance Roles        | Defines incident ownership and escalation          |
| AI Governance Lifecycle | Provides lifecycle context for incidents           |
| AI Risk Management      | Captures realized and emerging risk                |
| AI Governance Controls  | Identifies control failures and remediation        |
| AI Governance Maturity  | Supports incident-response capability assessment   |
| AI System Profiles      | Identifies affected system                         |
| Implementation Guidance | Defines incident implementation expectations       |
| Operational Procedures  | Defines incident workflow                          |
| Templates               | Provides human-readable incident records           |
| External Mappings       | Provides regulatory and standards context          |

***

## 54. Incident Traceability Model

The recommended traceability chain is:

```text id="3w0m8e" theme={null}
Monitoring / Report / Event
           ↓
Incident
           ↓
Triage
           ↓
Impact
           ↓
Containment
           ↓
Investigation
           ↓
Root Cause
           ↓
Risk / Control Findings
           ↓
Remediation
           ↓
Recovery
           ↓
Verification
           ↓
Closure
           ↓
Lessons Learned
           ↓
Improvement
```

Additional relationships may connect the incident to:

```text id="7lc8y3" theme={null}
Approval
Change
Assurance
Evidence
Management Review
Retirement
```

***

## 55. Example Record

A conceptual Incident record may look like:

```json id="tmn94v" theme={null}
{
  "id": "INC-001",
  "objectType": "INCIDENT",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "UNDER_INVESTIGATION",
  "severity": "HIGH",
  "title": "Unexpected AI recommendation behavior",
  "aiSystemId": "AI-SYS-001",
  "detectionSource": "MONITORING",
  "description": "Monitoring detected a material deterioration in an operational performance indicator.",
  "riskIds": [
    "RISK-001"
  ],
  "controlIds": [
    "CTRL-004"
  ],
  "monitoringIds": [
    "MON-001"
  ],
  "evidenceIds": [
    "EVID-050",
    "EVID-051"
  ]
}
```

The actual record must conform to the authoritative JSON schema.

***

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

***

## 57. Change and Version Management

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

Potential impacts should be assessed against:

* incident procedures;
* incident templates;
* monitoring;
* risk;
* controls;
* change management;
* assurance;
* evidence;
* management reporting;
* notification processes;
* external mappings; and
* validation tooling.

Breaking changes should include migration guidance where required.

***

## 58. Future Extensions

Future versions may support:

* standardized AI incident taxonomy;
* event correlation;
* automated incident creation;
* incident severity scoring;
* formal root-cause taxonomies;
* affected-person impact models;
* regulatory notification schemas;
* digital evidence packages;
* automated remediation workflows;
* incident knowledge bases;
* systemic-risk correlation; and
* machine-readable lessons-learned structures.

Extensions should preserve incident identity, evidence integrity, and historical traceability.

***

## 59. Document Control

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

***

## 60. Document Status

**Document:** AIGO — Incident Schema Documentation

**Version:** 0.1

**Status:** Draft

**Working Name:** AIGO

**Full Name:** AI Governance Operating Framework

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

**Document Type:** Schema Documentation

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

End of Document