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

# 02 AIGO Risk Schema Documentation v0.1

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

```text id="x2nvw4" theme={null}
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:

```json id="pl9r6n" theme={null}
{
  "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:

```text id="x6t1aa" theme={null}
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:

```json id="0vrv8j" theme={null}
{
  "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:

```text id="zzkg4m" theme={null}
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:

```text id="iz7d8r" theme={null}
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:

```text id="5rbzgz" theme={null}
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:

```json id="j7ktul" theme={null}
{
  "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:

```json id="e85va4" theme={null}
{
  "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:

```json id="6v6qf2" theme={null}
{
  "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:

```json id="lr0e7c" theme={null}
{
  "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:

```text id="j0p7et" theme={null}
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:

```text id="6ejt3f" theme={null}
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:

```text id="3ssnri" theme={null}
AI System / Context
        ↓
Risk
        ↓
Assessment
        ↓
Treatment
        ↓
Control
        ↓
Evidence
        ↓
Residual Risk
        ↓
Acceptance / Escalation
        ↓
Monitoring
        ↓
Reassessment
```

Additional relationships may connect the risk to:

```text id="0d22wu" theme={null}
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:

```json id="lw8tyx" theme={null}
{
  "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