​

Incident Schema

The AIGO Incident Schema provides the machine-readable structure for recording AI-related incidents and the governance activities performed in response to them. Incident management connects operational events with risk management, controls, evidence, corrective action, assurance, and continual improvement.

​

Purpose

The Incident Schema supports consistent recording of:

• incident identity
• affected AI systems
• incident classification
• severity or significance
• detection information
• investigation
• containment and response
• affected stakeholders
• supporting evidence
• root-cause information
• corrective actions
• governance impact
• follow-up activities
• closure information

This allows incidents to remain traceable throughout the governance lifecycle.

​

Role in the AIGO architecture

Incidents provide an important feedback mechanism within the AIGO lifecycle. A representative relationship is: AI system → monitoring → incident → investigation → response → corrective action → reassessment → improvement An incident may also connect directly to:

• risks
• controls
• assessments
• approvals
• changes
• monitoring
• assurance
• evidence
• improvement

This allows an organization to determine whether an incident represents an isolated event or evidence of a broader governance weakness.

​

What an incident represents

An incident record represents a defined event, condition, or suspected event requiring governance or operational attention. Depending on organizational policy, incidents may include:

• unexpected AI system behavior
• significant performance failures
• safety-related events
• security events
• privacy-related events
• harmful or inappropriate outputs
• control failures
• unauthorized use
• policy violations
• material governance failures
• significant stakeholder impacts
• regulatory or contractual events

The organization should define its own incident criteria and severity model appropriate to its AI governance context.

​

Incident identification

An incident record should provide sufficient information to establish what occurred and what system or governance activity was affected. Relevant information may include:

• incident identifier
• detection date and time
• reporting source
• affected AI system
• affected deployment or component
• incident description
• operating context
• affected stakeholders
• initial classification
• initial severity
• current status

The initial record may be incomplete. The investigation process should allow the record to be updated as additional information becomes available.

​

Incident classification and severity

Incident classification helps determine the appropriate response and escalation pathway. Factors may include:

• potential impact
• actual impact
• affected stakeholders
• scope
• duration
• recurrence
• system criticality
• risk significance
• regulatory or contractual implications
• control failures

The exact classification and severity vocabulary should follow the applicable organizational and AIGO definitions. Severity should not be determined solely from technical impact where the incident may affect people, rights, safety, governance, or other significant interests.

​

Detection

Incidents may be detected through:

• monitoring
• user reports
• employee reports
• assurance activities
• control assessments
• testing
• audits
• security processes
• risk reviews
• external notifications
• automated governance evaluation

The source of detection should be preserved where relevant because it can help identify weaknesses or patterns in the governance system. A monitoring signal does not automatically constitute an incident. Organizations should define the criteria used to determine when an observation becomes an incident.

​

Investigation

Incident investigation establishes the facts needed to determine:

• what happened
• when it happened
• what was affected
• why it happened
• whether the event is ongoing
• what risks were created or increased
• which controls were affected
• whether governance decisions remain valid
• what corrective actions are required

Investigation conclusions should be supported by appropriate evidence. Where the cause remains uncertain, the record should preserve that uncertainty rather than presenting an unverified conclusion as established fact.

​

Response and containment

Incident response may include:

• containment
• temporary suspension
• access restriction
• rollback
• remediation
• stakeholder notification
• additional monitoring
• escalation
• risk reassessment
• change management
• approval review

The appropriate response depends on the nature and significance of the incident. Incident response should remain traceable to the incident record and the decisions made during the response.

​

Evidence

Incident records should preserve evidence needed to understand, investigate, respond to, and learn from the event. Evidence may include:

• system logs
• monitoring records
• alerts
• model outputs
• test results
• screenshots
• communications
• configuration records
• change records
• control assessments
• approval records
• investigation findings
• remediation evidence

Evidence retention should follow applicable organizational, legal, contractual, and regulatory requirements.

​

Relationship to risk

Incidents can reveal that existing risk assessments are incomplete or no longer accurate. A representative relationship is: incident → finding → risk reassessment → risk treatment An incident may:

• identify a previously unknown risk
• increase an existing risk
• demonstrate that a risk treatment was ineffective
• reveal a new affected stakeholder
• change the assessed likelihood or impact
• require additional controls

Incident records should therefore be connected to affected risk records where appropriate.

​

Relationship to controls

An incident may reveal:

• a missing control
• an incorrectly designed control
• a control implementation failure
• an ineffective control
• a control operating outside its intended scope
• a need for compensating controls

This relationship can be represented as: incident → control finding → control assessment → remediation → evidence Incident management should therefore provide feedback into control management and continual improvement.

​

Relationship to approval

A significant incident may require review of an existing governance approval. Depending on the circumstances, an incident may result in:

• no change to approval
• additional approval conditions
• temporary suspension
• re-approval
• withdrawal of approval
• restricted use

The incident record should preserve the relationship between the event and any resulting governance decision.

​

Relationship to change management

Corrective actions may require changes to:

• the AI system
• model or components
• configuration
• data
• intended use
• deployment context
• controls
• monitoring
• governance procedures

Where such changes are material, they should enter the applicable change-management process. The relationship can therefore be represented as: incident → corrective action → change → reassessment → approval This prevents corrective actions from bypassing normal governance controls.

​

Corrective action

Corrective actions should address identified causes or contributing factors rather than only the immediate symptom. Actions may include:

• technical remediation
• control improvements
• process changes
• additional monitoring
• training
• governance changes
• documentation updates
• risk treatment changes
• changes to system use or deployment

Where appropriate, each action should have:

• an owner
• defined scope
• due date
• status
• verification method
• supporting evidence

​

Root-cause and systemic learning

AIGO incident management should distinguish between immediate cause, contributing factors, and systemic governance weaknesses where appropriate. Repeated incidents may indicate that the underlying governance process requires improvement. For example, recurring incidents associated with the same control may indicate a need to redesign the control rather than repeatedly remediate individual events.

​

Closure

An incident should only be closed when the organization has determined that the required response and follow-up activities have been completed or otherwise formally resolved. Closure may require confirmation that:

• immediate response is complete
• required remediation is complete
• residual risk has been evaluated
• required approvals have been obtained
• affected stakeholders have been addressed where applicable
• evidence has been preserved
• lessons learned have been recorded
• required improvement actions have been initiated

Closure does not necessarily mean that every long-term improvement action has been completed. Where actions remain open, they should remain traceable through the relevant governance records.

​

Relationship to assurance

Incident records can become important inputs to assurance activities. Assurance may examine whether:

• incidents were identified appropriately
• escalation requirements were followed
• investigations were adequate
• evidence was preserved
• corrective actions were effective
• governance decisions were revisited when necessary
• recurring incidents were addressed systematically

Incident trends may also be used as assurance indicators for governance effectiveness.

​

Relationship to machine-readable evaluation

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

• required incident information exists
• incidents above a defined significance threshold were escalated
• required evidence exists
• corrective actions have been assigned
• required follow-up activities are recorded
• significant incidents triggered reassessment
• incident records are linked to affected systems

Automated evaluation can support consistency and detection but does not replace incident investigation or governance judgment.

​

Machine-readable implementation

An organization implementing AIGO may use the Incident Schema as the structural contract for incident records. A governance implementation could:

1. detect or receive an incident
2. create an incident record
3. identify the affected AI system
4. classify the incident
5. assess initial severity
6. initiate investigation
7. record response and containment
8. preserve evidence
9. identify affected risks and controls
10. define corrective actions
11. determine governance consequences
12. verify follow-up actions
13. close the incident
14. feed lessons learned into continual improvement

The schema defines the structure of the governance record. It does not prescribe a particular incident-management platform, ticketing system, security tool, workflow engine, or organizational response model.

​

Validation

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

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

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

​

Canonical source

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