AIGO — Risk Schema Documentation

1. Document Purpose

This document describes the machine-readable AIGO Risk Schema. The schema provides the structured representation of AI-related risks governed under the AIGO AI Governance Operating Framework. It is intended to support:

AI risk identification;
risk description and categorization;
risk source and context;
affected stakeholders and assets;
likelihood and impact assessment;
inherent and residual risk;
risk treatment;
risk ownership;
control relationships;
risk acceptance;
monitoring;
escalation;
reassessment;
incident and change relationships;
assurance; and
risk closure.

The JSON schema defines structural requirements. This documentation explains the intended meaning and governance use of those structures.

2. Schema Information

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

3. Scope

The Risk Schema applies to risks arising from AI systems, AI-enabled activities, governance arrangements, supporting processes, data, models, technology, people, suppliers, and other relevant conditions within the organization’s AIGO scope. The schema may represent:

strategic risks;
governance risks;
operational risks;
technical risks;
model risks;
data risks;
security risks;
privacy risks;
fairness and discrimination risks;
safety risks;
human-oversight risks;
compliance risks;
third-party risks;
lifecycle risks; and
emerging risks.

The organization’s approved risk methodology determines which risks are required to be recorded and how they are evaluated.

4. Object Model

The primary object represented by this schema is:

RISK

A Risk record represents a defined risk requiring governance attention. The record should remain distinct from:

an AI System record;
a Control record;
an Assessment record;
an Approval record;
an Incident record;
a Change record;
an Assurance record; and
an Evidence record.

Related records should normally be connected through stable identifiers.

5. Core Identity

A Risk record should contain stable identity information. Key fields include:

id;
objectType;
objectVersion;
schemaVersion;
risk title or description;
risk owner;
risk status; and
assessment information.

Example:

{
  "id": "RISK-001",
  "objectType": "RISK",
  "objectVersion": "1.0",
  "schemaVersion": "0.1"
}

The risk identifier should remain stable while the risk record is maintained. A materially distinct risk should normally receive a distinct identifier.

6. Risk Statement

The risk record should describe the risk clearly enough for governance stakeholders to understand:

the source or cause;
the event or condition;
the potential consequence;
the affected context;
the relevant AI system or activity; and
the reason the risk requires governance attention.

A useful risk statement generally connects a cause or condition with a possible consequence. For example:

Because the system relies on incomplete operational data,
the model may produce unreliable recommendations,
which could lead to inappropriate business decisions.

The specific wording should follow the organization’s approved risk methodology.

7. Risk Categories

The schema supports categorization of risk. Possible categories include:

governance;
strategic;
legal or regulatory;
compliance;
operational;
financial;
reputational;
technical;
model;
data;
security;
privacy;
fairness;
discrimination;
safety;
reliability;
human oversight;
transparency;
explainability;
third-party;
change;
lifecycle; and
other organization-defined categories.

Organizations may maintain a controlled taxonomy aligned to their risk methodology.

8. Risk Source and Context

The risk record should capture the context in which the risk arises. This may include:

AI system;
business process;
lifecycle stage;
data source;
model;
technology component;
supplier;
human decision process;
governance process;
external environment;
regulatory development; or
incident or change.

Context information helps ensure that risk treatment addresses the underlying source of risk rather than only its symptoms.

9. AI System Relationship

Where a risk relates to an AI system, the risk should reference the relevant AI System record. Example:

{
  "id": "RISK-001",
  "aiSystemId": "AI-SYS-001"
}

A single AI system may have multiple risks. A single risk may also affect multiple systems where the risk is enterprise-wide or shared. The risk record remains authoritative for the risk analysis and treatment.

10. Stakeholder and Affected-Person Context

Risk identification should consider who may be affected. Relevant stakeholders may include:

customers;
employees;
users;
applicants;
suppliers;
business partners;
regulators;
members of the public; and
other affected persons or groups.

The risk record may identify:

affected stakeholder groups;
affected persons;
potential harms;
business effects;
rights or interests potentially affected; and
stakeholder significance.

This information supports proportional risk evaluation.

11. Risk Lifecycle

A risk should move through a controlled governance lifecycle. A typical risk lifecycle is:

Identification
     ↓
Registration
     ↓
Analysis
     ↓
Evaluation
     ↓
Treatment Decision
     ↓
Treatment
     ↓
Residual Risk Evaluation
     ↓
Acceptance / Escalation
     ↓
Monitoring
     ↓
Reassessment
     ↓
Closure / Transfer / Retirement

The organization’s risk procedure governs actual transitions. The schema represents the state but does not authorize the transition.

12. Risk Status

The exact status enumeration defined in the JSON schema is authoritative. Typical risk states may include:

IDENTIFIED
UNDER_ASSESSMENT
OPEN
UNDER_TREATMENT
MONITORED
ACCEPTED
ESCALATED
CLOSED
TRANSFERRED
RETIRED

The organization should use status values consistently across its risk repository.

13. Inherent Risk

Inherent risk represents risk before considering the effectiveness of implemented risk treatments or controls, according to the organization’s methodology. The risk record may capture:

likelihood;
impact;
inherent risk level;
risk rationale; and
assessment date.

The underlying scoring model should be documented through the organization’s risk methodology rather than inferred from the schema alone.

14. Likelihood

Likelihood represents the organization’s assessment of how probable the risk event or condition is within the applicable context. Depending on the organization’s methodology, likelihood may be represented as:

qualitative level;
numerical value;
probability range;
frequency;
scenario-based assessment; or
another approved measure.

The schema should preserve the organization’s defined representation without changing its semantic meaning.

15. Impact

Impact represents the significance of potential consequences if the risk materializes. Impact may consider:

people;
safety;
privacy;
fairness;
security;
financial consequences;
operational disruption;
legal or regulatory consequences;
reputation;
customer impact;
business continuity; and
other material effects.

Impact should be evaluated using the approved AIGO risk methodology.

16. Risk Level

The schema uses the common AIGO RiskLevel definition. Risk levels should be interpreted consistently throughout the AIGO schema ecosystem. A typical conceptual scale may include:

LOW
MEDIUM
HIGH
CRITICAL

The authoritative enumeration is defined by the common definitions schema. Risk level should not be assigned solely through intuition or unsupported judgment.

17. Risk Evaluation

Risk evaluation determines whether the assessed risk is:

acceptable;
tolerable subject to conditions;
requires treatment;
above organizational tolerance;
requires escalation; or
otherwise requires governance action.

Evaluation should consider the organization’s:

risk appetite;
risk tolerance;
regulatory obligations;
affected-person impacts;
control environment;
stakeholder expectations; and
strategic context.

18. Risk Appetite and Tolerance

Risk records may reference the organization’s applicable:

risk appetite;
risk tolerance;
risk thresholds;
escalation thresholds; and
acceptance authority.

The risk record should not establish organizational risk appetite independently. Those requirements should come from the organization’s governance arrangement.

19. Risk Treatment

A risk treatment describes how the organization intends to modify the risk. Typical treatment strategies include:

avoid;
reduce;
control;
transfer;
share;
accept;
restrict;
suspend; or
retire.

The organization should define treatment terminology through its approved methodology. A treatment should normally identify:

treatment action;
responsible owner;
target date;
required controls;
dependencies;
status; and
evidence.

20. Treatment Actions

Treatment actions should be explicit and accountable. Example:

{
  "riskId": "RISK-001",
  "treatment": {
    "action": "Implement additional data-quality controls",
    "owner": {
      "role": "Control Owner"
    },
    "targetDate": "2026-12-01",
    "status": "IN_PROGRESS"
  }
}

Treatment should address the identified cause or consequence of the risk where practical.

21. Control Relationships

Risks may be treated through one or more controls. The risk record should reference control identifiers rather than duplicating the full control definition. Example:

{
  "id": "RISK-001",
  "controlIds": [
    "CTRL-001",
    "CTRL-003"
  ]
}

Control effectiveness remains authoritative in the Control and Control Assessment records.

22. Residual Risk

Residual risk represents the remaining risk after considering implemented controls and treatments. The record may include:

residual risk level;
residual risk rationale;
remaining consequences;
outstanding treatments;
acceptance requirement;
escalation requirement; and
monitoring requirements.

Residual risk should not automatically equal the inherent risk.

23. Risk Acceptance

Risk acceptance is a controlled governance decision. Where required, the risk record should reference the formal risk acceptance record. An acceptance should identify:

accepted risk;
residual risk;
acceptance authority;
decision date;
validity period;
conditions;
rationale; and
review or expiry requirements.

A risk should not be treated as accepted merely because an individual enters "ACCEPTED" into a status field. Formal acceptance should be governed through the applicable AIGO procedure and authority.

24. Risk Escalation

A risk should be escalated when applicable thresholds are exceeded. Potential escalation triggers include:

residual risk above tolerance;
risk involving critical safety concerns;
significant privacy or security impact;
material fairness or discrimination concerns;
unresolved control failures;
repeated incidents;
regulatory concerns;
significant stakeholder impact;
inability to implement required treatment; or
management review direction.

The organization’s governance model determines escalation authority.

25. Risk Monitoring

A risk may require ongoing monitoring. Monitoring can address:

key risk indicators;
control performance;
residual risk;
incident trends;
model or data changes;
stakeholder impacts;
regulatory developments;
treatment progress; and
emerging risk indicators.

Monitoring requirements should be connected to the Monitoring schema where a formal monitoring plan is required.

26. Risk Reassessment

Risk should be reassessed when relevant conditions change. Potential reassessment triggers include:

material AI system changes;
model changes;
data changes;
changes in intended purpose;
changes in operating context;
significant incidents;
control failures;
monitoring threshold breaches;
regulatory changes;
changes in stakeholder impact;
changes in risk appetite; and
management review decisions.

Reassessment should preserve the relationship between the previous and new risk evaluations.

27. Incident Relationship

An incident may create, modify, increase, or reveal a risk. The risk record may therefore reference incident records. Example:

{
  "id": "RISK-001",
  "incidentIds": [
    "INC-004"
  ]
}

Incident records remain authoritative for:

detection;
investigation;
containment;
root cause;
impact;
corrective action; and
incident closure.

The risk record should capture the resulting risk implications.

28. Change Relationship

Changes to an AI system may introduce new risks or alter existing risks. The Risk record should support traceability to relevant change records. Example:

{
  "changeIds": [
    "CHANGE-003"
  ]
}

A material change should trigger risk reassessment where required by the organization’s change-management process.

29. Assessment Relationships

The risk record may reference assessment records supporting:

initial assessment;
reassessment;
impact assessment;
security assessment;
privacy assessment;
fairness assessment;
control assessment;
technical assessment; and
post-incident assessment.

The assessment record remains authoritative for assessment methodology, result, findings, and supporting evidence.

30. Assurance Relationships

Risk management may be subject to assurance. Assurance activities may evaluate:

risk identification;
risk analysis;
risk evaluation;
treatment;
residual risk;
acceptance;
monitoring; and
escalation.

The risk record should reference assurance records where applicable.

31. Evidence Relationships

Evidence may support virtually every stage of risk management. Examples include:

risk assessments;
testing results;
stakeholder analysis;
control evidence;
monitoring results;
incident evidence;
approval records;
assurance findings;
treatment completion evidence; and
acceptance decisions.

Evidence should normally be maintained as independent records and referenced by identifier.

32. Risk Dependencies

Risks may depend on other risks. For example:

RISK-001
   ├── depends on RISK-002
   └── contributes to RISK-005

Dependency relationships should be recorded where they are material to risk treatment or governance decisions. This is particularly important for systemic and portfolio-level AI risks.

33. Aggregated and Systemic Risk

Organizations may need to manage risks that emerge across multiple AI systems. Examples include:

common model-provider dependence;
common data-source failures;
shared cybersecurity vulnerabilities;
common fairness concerns;
concentration risk;
shared infrastructure dependencies; and
organization-wide governance weaknesses.

A systemic risk should be capable of referencing multiple AI systems and related governance records.

34. Emerging Risk

AIGO should support risks that are not yet fully characterized. An emerging risk may contain:

preliminary risk statement;
uncertain likelihood;
uncertain impact;
initial evidence;
monitoring requirements;
assigned owner;
review date; and
trigger conditions for formal reassessment.

The absence of precise quantification should not prevent an emerging risk from being governed.

35. Risk Treatment Effectiveness

Risk treatment should be evaluated after implementation. Evaluation may determine whether:

risk was reduced;
risk remained unchanged;
risk increased;
treatment was partially effective; or
effectiveness cannot yet be determined.

Where treatment is ineffective, further treatment, reassessment, escalation, or other governance action may be required.

36. Risk Closure

A risk should be closed only when the organization’s closure criteria have been satisfied. Possible closure conditions include:

risk no longer exists;
risk has been eliminated;
system has been retired;
risk has been transferred appropriately;
risk has been incorporated into another controlled risk;
applicable treatment is complete and no residual risk remains requiring separate tracking; or
another formally approved closure condition applies.

Closure should be supported by evidence and appropriate authority.

37. Risk Transfer

Where risk is transferred or shared, the risk record should maintain traceability to:

receiving party;
contractual arrangement;
transferred responsibilities;
retained residual exposure;
monitoring;
supplier governance; and
review requirements.

Risk transfer does not necessarily eliminate the organization’s accountability.

38. Third-Party Risks

Third-party AI services may introduce risks concerning:

service availability;
model behavior;
data handling;
privacy;
security;
intellectual property;
transparency;
change notification;
assurance;
contractual obligations; and
supplier concentration.

Such risks should remain explicitly assigned to accountable owners. Supplier relationships should be connected to relevant third-party governance records.

39. Risk and Human Oversight

Where human oversight is a risk treatment or risk factor, the risk record should identify the relevant relationship. Examples include risks arising from:

inadequate human review;
insufficient competence;
automation bias;
unclear override authority;
delayed escalation;
ineffective challenge mechanisms; or
inappropriate delegation.

Relevant controls and oversight arrangements should be referenced rather than duplicated.

40. Risk and Affected Persons

For risks affecting people, the organization should consider:

severity of potential harm;
scale of affected persons;
vulnerability;
reversibility;
duration;
likelihood;
ability to detect harm;
ability to contest decisions; and
available remediation.

These factors may influence classification, treatment, escalation, monitoring, and approval.

41. Risk and Regulatory Requirements

An AI risk may arise directly from external obligations. The risk record may reference:

applicable legal requirements;
regulatory requirements;
standards;
contractual obligations;
internal policy requirements; and
external commitments.

External framework mappings should remain authoritative for detailed requirement mappings. Relevant mapping repositories include:

mappings/iso-42001/
mappings/nist-ai-rmf/
mappings/eu-ai-act/
mappings/other/

42. Risk Reporting

Risk records may be aggregated into governance reporting. Reports may include:

total open risks;
risk distribution;
highest risks;
risks above tolerance;
overdue treatments;
accepted risks;
emerging risks;
systemic risks;
changes in risk profile;
risk trends; and
risk-treatment performance.

Reporting should preserve the distinction between source records and aggregated reporting views.

43. Risk Metrics

Organizations may define risk metrics such as:

Metric	Purpose
Number of open risks	Risk inventory visibility
Number of high or critical risks	Exposure monitoring
Risks above tolerance	Escalation monitoring
Overdue treatments	Treatment effectiveness
Accepted residual risks	Acceptance exposure
Reassessment frequency	Risk governance responsiveness
Emerging risks	Forward-looking awareness
Repeated incidents associated with risk	Risk realization monitoring

Metrics should have defined owners, formulas, thresholds, and review frequency where used.

44. Validation Requirements

A valid Risk record should satisfy:

Structural Validation

The JSON document must validate against: 02-AIGO-Risk-Schema-v0.1.json

Reference Validation

Referenced AI systems, controls, assessments, incidents, changes, assurances, approvals, evidence, and other records should exist where required.

Governance Validation

The record should follow the approved AIGO risk methodology and procedures.

Ownership Validation

Each active risk should have an accountable risk owner.

Treatment Validation

Risks requiring treatment should have appropriately assigned treatment actions.

Acceptance Validation

Accepted residual risks should have appropriate authority and evidence where formal acceptance is required.

Traceability Validation

Risk decisions should remain traceable to supporting assessments, controls, evidence, approvals, and monitoring.

45. Schema Limitations

JSON Schema does not independently determine whether:

the risk statement is substantively correct;
the scoring method is appropriate;
the likelihood assessment is accurate;
the impact assessment is reasonable;
the risk owner has sufficient authority;
the treatment is effective;
the organization has acceptable residual risk; or
regulatory obligations have been satisfied.

Those matters require human judgment, governance processes, evidence, and assurance.

46. Relationship to Templates

The Risk Schema corresponds primarily to the AIGO AI Risk Assessment Template and related risk records. Relevant template: guidance/03-templates/05-AIGO-AI-Risk-Assessment-Template-v0.1.md The template provides the human-readable operational record structure. The JSON schema provides the machine-readable representation.

47. Relationship to Procedures

The schema should be used with: guidance/02-procedures/03-AIGO-AI-Risk-Assessment-Procedure-v0.1.md and, where applicable:

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

The procedure defines how the risk record is created, assessed, treated, accepted, monitored, escalated, reassessed, and closed.

48. Relationship to Framework Components

AIGO Component	Relationship
Governance Domains	Defines where and how risks are governed
Governance Roles	Defines risk ownership and authority
AI Governance Lifecycle	Establishes lifecycle risk context
AI Risk Management	Primary conceptual source for the schema
AI Governance Controls	Provides treatment and control relationships
AI Governance Maturity	Supports assessment of risk-management capability
AI System Profiles	Provides system context
Implementation Guidance	Defines implementation expectations
Operational Procedures	Defines operational risk-management processes
Templates	Provides human-readable risk records
External Mappings	Provides external requirement traceability

49. Risk Traceability Model

The recommended traceability chain is:

AI System / Context
        ↓
Risk
        ↓
Assessment
        ↓
Treatment
        ↓
Control
        ↓
Evidence
        ↓
Residual Risk
        ↓
Acceptance / Escalation
        ↓
Monitoring
        ↓
Reassessment

Additional relationships may connect the risk to:

Incident
Change
Assurance
Management Review
Improvement
Retirement

This structure supports end-to-end governance traceability.

50. Example Record

A conceptual Risk record may look like:

{
  "id": "RISK-001",
  "objectType": "RISK",
  "objectVersion": "1.0",
  "schemaVersion": "0.1",
  "status": "OPEN",
  "aiSystemId": "AI-SYS-001",
  "title": "Unreliable recommendations caused by data-quality degradation",
  "riskCategory": "DATA",
  "riskStatement": "Degraded input data may cause unreliable AI recommendations and inappropriate downstream decisions.",
  "riskOwner": {
    "role": "AI Risk Owner"
  },
  "inherentRisk": "HIGH",
  "controlIds": [
    "CTRL-001",
    "CTRL-002"
  ],
  "assessmentIds": [
    "ASSESS-002"
  ],
  "monitoringIds": [
    "MON-002"
  ],
  "evidenceIds": [
    "EVID-010"
  ]
}

The actual record must conform to the authoritative JSON schema.

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

52. Change and Version Management

Changes to the Risk Schema should be controlled through the AIGO change-management process. Potential impacts should be assessed against:

existing risk records;
reporting;
assessment processes;
risk acceptance;
control relationships;
monitoring;
assurance;
external mappings;
validation tooling; and
downstream integrations.

Breaking changes should include migration guidance where necessary.

53. Future Extensions

Future versions may expand support for:

quantitative risk models;
probabilistic risk;
scenario analysis;
harm taxonomies;
systemic risk;
portfolio risk;
risk aggregation;
automated risk scoring;
risk heatmaps;
risk treatment effectiveness metrics; and
machine-readable external regulatory requirements.

Extensions should remain compatible with the core AIGO risk model.

54. Document Control

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

55. Document Status

Document: AIGO — Risk Schema Documentation Version: 0.1 Status: Draft Working Name: AIGO Full Name: AI Governance Operating Framework Document Identifier: AIGO-SCHEMA-DOC-002 Document Type: Schema Documentation This document provides the human-readable interpretation, governance context, validation expectations, and traceability guidance for the AIGO Risk Schema. End of Document

​AIGO — Risk Schema Documentation

​1. Document Purpose

​2. Schema Information

​3. Scope

​4. Object Model

​5. Core Identity

​6. Risk Statement

​7. Risk Categories

​8. Risk Source and Context

​9. AI System Relationship

​10. Stakeholder and Affected-Person Context

​11. Risk Lifecycle

​12. Risk Status

​13. Inherent Risk

​14. Likelihood

​15. Impact

​16. Risk Level

​17. Risk Evaluation

​18. Risk Appetite and Tolerance

​19. Risk Treatment

​20. Treatment Actions

​21. Control Relationships

​22. Residual Risk

​23. Risk Acceptance

​24. Risk Escalation

​25. Risk Monitoring

​26. Risk Reassessment

​27. Incident Relationship

​28. Change Relationship

​29. Assessment Relationships

​30. Assurance Relationships

​31. Evidence Relationships

​32. Risk Dependencies

​33. Aggregated and Systemic Risk

​34. Emerging Risk

​35. Risk Treatment Effectiveness

​36. Risk Closure

​37. Risk Transfer

​38. Third-Party Risks

​39. Risk and Human Oversight

​40. Risk and Affected Persons

​41. Risk and Regulatory Requirements

​42. Risk Reporting

​43. Risk Metrics

​44. Validation Requirements

​Structural Validation

​Reference Validation

​Governance Validation

​Ownership Validation

​Treatment Validation

​Acceptance Validation

​Traceability Validation

​45. Schema Limitations

​46. Relationship to Templates

​47. Relationship to Procedures

​48. Relationship to Framework Components

​49. Risk Traceability Model

​50. Example Record

​51. Schema Registry Relationship

​52. Change and Version Management

​53. Future Extensions

​54. Document Control

​55. Document Status