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:

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:

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

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:

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

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:

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

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:

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:

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:

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:

Approval
Change
Assurance
Evidence
Management Review
Retirement

55. Example Record

A conceptual Incident record may look like:

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

​AIGO — Incident Schema Documentation

​1. Document Purpose

​2. Schema Information

​3. Scope

​4. Object Model

​5. Core Identity

​6. Incident Title and Description

​7. Incident Detection

​8. Incident Classification

​9. Incident Severity

​10. Incident Status

​11. Incident Owner

​12. AI System Relationship

​13. System Version and Configuration

​14. Incident Timeline

​15. Initial Triage

​16. Immediate Impact Assessment

​17. Affected Persons and Stakeholders

​18. Incident Containment

​19. Emergency Controls

​20. Incident Investigation

​21. Evidence Preservation

​22. Root-Cause Analysis

​23. Control Failure Analysis

​24. Risk Relationship

​25. Risk Reassessment

​26. Classification Reassessment

​27. Incident Remediation

​28. Corrective and Preventive Action

​29. Recovery

​30. Resumption Approval

​31. Notification and Communication

​32. Communication Records

​33. Third-Party Incidents

​34. Security Incidents

​35. Privacy Incidents

​36. Fairness and Discrimination Incidents

​37. Safety Incidents

​38. Monitoring Relationship

​39. Change Management Relationship

​40. Assurance Relationship

​41. Lessons Learned

​42. Continual Improvement

​43. Incident Closure

​44. Reopening an Incident

​45. Incident Evidence

​46. Evidence Integrity and Chain of Custody

​47. Incident Reporting

​48. Incident Trend Analysis

​49. Incident Validation Requirements

​Structural Validation

​Identity Validation

​Classification Validation

​Ownership Validation

​System Validation

​Impact Validation

​Evidence Validation

​Escalation Validation

​Risk Validation

​Remediation Validation

​Closure Validation

​Traceability Validation

​50. Schema Limitations

​51. Relationship to Templates

​52. Relationship to Procedures

​53. Framework Traceability

​54. Incident Traceability Model

​55. Example Record

​56. Schema Registry Relationship

​57. Change and Version Management

​58. Future Extensions

​59. Document Control

​60. Document Status