About the Identifier Scheme

The AI Risk Registry uses a hierarchical identifier scheme inspired by library classification systems. These identifiers provide stable, human-readable codes that make it easy to reference, cite, and discuss specific AI risks.

Why Structured Identifiers?

As AI risk taxonomies grow and evolve, having stable identifiers becomes essential for:

• Citation and reference — Easily cite specific risks in reports, policies, and research
• Cross-referencing — Map risks to other taxonomies like NIST AI RMF, OWASP LLM Top 10, and MITRE ATLAS
• Communication — Provide a shared vocabulary for discussing AI risks across organizations
• Stability — Identifiers never change once assigned, ensuring links and references remain valid

Identifier Format

Every risk in the registry has a unique identifier following this pattern:

R-CDPS.NNN

Example: R-4210.003 breaks down as: - R — Registry prefix - 4 — Class 4 (Harms) - 2 — Domain 2 (Content & Conduct Harms) - 1 — Pattern 1 (Content Safety Harms) - 003 — Third risk in that pattern

The Four-Class Model

The registry organizes all AI risks into four fundamental classes based on "what kind of thing" the risk represents:

Why Separate Classes?

Mixing fundamentally different risk types (threats, failures, governance gaps, and harms) creates practical problems:

• Ownership ambiguity : Threats are owned by security teams, Failure Modes by engineering, Governance Failures by legal/compliance, and Harms by policy/product.
• Inconsistent assessment : Likelihood of an adversarial attack is assessed differently than likelihood of a system bug.
• Incoherent controls : Controls for attack techniques look nothing like controls for organizational gaps.

Separating these classes enables clearer ownership, consistent assessment, and coherent control mapping.

Classification Structure

Each class contains Domains (broad categories), which contain Patterns (specific risk families), which contain individual Risks .

Class (e.g., Threats)
└── Domain (e.g., Prompt & Interface Attacks)
    └── Pattern (e.g., Prompt Injection)
        └── Risk (e.g., Indirect Prompt Injection)

Class 1: Threats

Adversarial actions an attacker can intentionally trigger in a realistic deployment.

Class 2: Failure Modes

Non-adversarial technical issues arising from limitations, bugs, drift, or emergent behavior.

Class 3: Governance Failures

Organizational and process failures in controls, accountability, or lifecycle management.

Class 4: Harms

Impact statements describing effects on people, organizations, society, or environment.

How Risks Are Classified

When a new risk is identified, it follows these steps to ensure consistent classification.

Step 0: Choose Class

Select based on the primary causal driver :

Step 1: Choose Domain

Select the domain where the primary harm mechanism is best controlled — where the most direct technical or organizational control belongs.

Step 2: Choose Pattern

Select the pattern that best describes:

Handling Complex Risks

When a risk spans multiple classes, split it into linked entries:

Example: "Data poisoning by an insider" involves: - A Threat (the poisoning attack technique) - A Governance Failure (inadequate access controls) - A Harm (data integrity compromise)

Create three linked entries rather than one overloaded entry.

Relationships Between Risks

The registry models causal chains between risks using typed relationships:

These relationships help trace how threats lead to harms and what governance gaps enable them.

Stability Guarantees

Identifiers are permanent. Once a risk is assigned an R-ID, that identifier will never be reassigned to a different risk. This ensures that:

• External references remain valid indefinitely
• Historical analysis can track risks over time
• Cross-taxonomy mappings stay accurate

When risks are merged, split, or deprecated:

Using the Identifiers

You can use R-IDs to:

1. Reference risks in documentation — "Our system implements controls for R-1110.007 (Indirect Prompt Injection)"
2. Map to compliance frameworks — Cross-reference R-IDs with NIST AI RMF, ISO 42001, or other standards
3. Track risk assessments — Use R-IDs as stable keys in your risk management systems
4. Communicate with stakeholders — Provide precise risk references in reports and discussions

Cross-References

Each risk in the registry includes mappings to external taxonomies where applicable, including:

• NIST AI Risk Management Framework
• OWASP LLM Top 10
• MITRE ATLAS
• IBM AI Risk Atlas
• Cisco AI Taxonomy
• EU AI Act risk categories
• MIT AI Risk Repository

These mappings help you understand how risks relate to frameworks you may already be using.

Registry Versioning

The registry uses version numbers in the format YYYYMM.X :

• YYYY — Year
• MM — Month
• X — Release within month (0-9)

Examples: - 202601.0 — First release, January 2026 - 202601.1 — Second release, January 2026 - 202602.0 — First release, February 2026

Each risk tracks when it was introduced and, if applicable, when it was deprecated, enabling historical analysis.