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
R-CDPP.NNN
| Component | Meaning |
|---|---|
| R | Registry prefix |
| C | Class (1-4) |
| D | Domain within the class (1-9) |
| PP | Pattern within the domain (00-99) |
| NNN | Risk sequence within the pattern (001-999) |
Enforced by
^R-[1-4][1-9][0-9]{2}\.[0-9]{3}$.
Patterns are assigned at multiples of ten.
R-1110,
R-1120
and
R-1130
are
siblings rather than a hierarchy: the tens are a thematic clustering convention, and
the nine codes between each leave room to insert a related pattern beside the one it
belongs next to instead of at the end.
R-1111
would be a valid pattern and a sibling
of
R-1110, not a child of it.
Example:
R-4210.003
is class
4
(Harms), domain
2
(Content, Conduct &
Creative Economy Harms), pattern
10
(Content Safety Harms), third risk in that pattern.
Classes
The four classes distinguish the subject of a risk: adversarial conduct, a technical condition or failure, an organizational failure, or an impact.
| Class | Code | ID Range | Subject |
|---|---|---|---|
| Threats | 1 | R-1xxx.xxx | Conduct that requires adversarial action or intentional misuse |
| Failure Modes | 2 | R-2xxx.xxx | Technical conditions or failures that can arise without an adversary |
| Governance Failures | 3 | R-3xxx.xxx | Failures of organizational duties, accountability, or process |
| Harms | 4 | R-4xxx.xxx | Injuries to people, organizations, animals, or the environment |
| Reserved | 5-9 | R-5xxx-9xxx | Future expansion |
The class helps a reader assess the risk and find where someone can intervene. It does not prescribe a team owner or a number of components involved in the fix. A local control may address an attack or a technical failure; an organization may help mitigate several classes of risk. Rule 2 classifies the subject, Rule 3 decides scope, and Rule 8 decides whether a statement contains distinct risks. Pattern grouping and individual risk identity are separate decisions.
Class 4 describes the injury itself. A consequence clause in an attack or failure description does not by itself create a second risk. Rule 3 determines whether the harm is admitted; the absence of a local control is not its admission test.
Classification Structure
Class 1: Threats
| Domain | ID | Patterns |
|---|---|---|
| Prompt & Interface Attacks |
R-1100
|
Prompt Injection, Jailbreak, Cross-Modal Injection, Composed Payloads, Context Displacement |
| Identity & Trust Attacks |
R-1200
|
Masquerading/Impersonation, Agent Authentication & Attribution |
| Supply Chain & Artifact Attacks |
R-1300
|
Supply Chain Attacks, Artifact Tampering, Artifact Exfiltration |
| Data & Model Attacks |
R-1400
|
Feedback Manipulation, Corpus & Memory Poisoning, Evasion, System Artifact Extraction, Privacy Attacks, Adversarial Perturbation |
| Tooling & Privilege Attacks |
R-1500
|
Tool & Execution Abuse, Availability Abuse, Privilege Escalation, Adversarial Output Chaining, Command & Control |
| Malicious Use |
R-1600
|
Content Abuse, Information Operations, Surveillance Enablement, Cyber-Physical, Weapons & Mass-Harm Enablement, Manipulation & Deceptive Design, Intellectual Property Misuse |
| Threats — Misc |
R-1900
|
reserved |
Class 2: Failure Modes
| Domain | ID | Patterns |
|---|---|---|
| Reliability & Calibration |
R-2100
|
Capability Limitations, Hallucination/Miscalibration, Multimodal Failures, Instruction/Data Confusion |
| Alignment & Capability |
R-2200
|
Goal Misalignment, Dangerous Capabilities, RLHF/Tuning Failures, Output Suitability, Specialized Advice |
| Behavioral Drift |
R-2300
|
Fine-Tuning Degradation, Quantization Drift, Distillation Transfer, Retrieval Augmentation Drift |
| Assurance Gaps |
R-2400
|
Transparency Deficits, Evaluation Gaps, Benchmark Gaming |
| Authority & Composition |
R-2500
|
Structural Concentration, Unverified Output Chaining, Provenance & Attribution Loss, Unbounded Execution, Failure Propagation |
| Corpus & Data Defects |
R-2600
|
Training Corpus Defects, Retrieval Corpus Defects, Continuous-Learning Data Defects, Data Preparation Failures |
| Multi-Agent Dynamics |
R-2700
|
Multi-Agent Dynamics, Long-Session Issues |
| Data Exposure |
R-2800
|
Disclosure to the Wrong Recipient, Incidental Capture |
| Failure Modes — Misc |
R-2900
|
reserved |
Class 3: Governance Failures
| Domain | ID | Patterns |
|---|---|---|
| Regulatory & Legal |
R-3100
|
Data Protection & Privacy Obligations, Cross-Border Transfer Obligations, Pre-Market & Conformity Obligations, Transparency & Disclosure Obligations, Prohibited Practice Deployment, Sectoral & Licensure Obligations, Duty of Care & Liability Exposure, Contractual, Licence & Export Obligations, Affected-Party Participation Obligations |
| Accountability & Oversight |
R-3200
|
Governance Gaps |
| Lifecycle & Operations |
R-3300
|
Change Management, Monitoring Gaps, Incident Response, Business Record Preservation, Data Development Oversight |
| Safety Management |
R-3400
|
Evaluation Program Failures, Safety Case Gaps |
| Defective Human-in-the-Loop Setup |
R-3500
|
Review Workflow Failures, Approval Fatigue |
| Governance — Misc |
R-3900
|
reserved |
Class 4: Harms
| Domain | ID | Patterns |
|---|---|---|
| Information & Trust Harms |
R-4100
|
Information Integrity Harms, Reputational Harms |
| Content, Conduct & Creative Economy Harms |
R-4200
|
Content Safety Harms, Emotional Dependence & Attachment Harms, Creative Work & Creator Harms |
| Privacy, Confidentiality & Civil Liberties Harms |
R-4300
|
Privacy Harms, Surveillance Harms, Confidentiality Harms, Civil Liberties Harms |
| Safety & Cyber-Physical Harms |
R-4400
|
Cyber-Physical Harms, Availability Harms, Collateral Harms |
| Fairness & Discrimination Harms |
R-4500
|
Discrimination Harms |
| Economic & Labor Harms |
R-4600
|
Market Concentration & Access Inequality Harms, Labor Substitution & Economic Inequality Harms, Competitive Development Harms, Market & Financial System Harms, Financial and Property Loss Harms |
| Power Concentration & Governance-of-Society Harms |
R-4700
|
Reliance Harms, Loss of Autonomy or Dignity, Infrastructure Dependency Harms, AI Welfare, Existential Harms, Institutional & Legal Order Harms, Power Concentration Harms, International Security & Cooperation Harms |
| Environmental Harms |
R-4800
|
Environmental Harms |
| Harms — Misc |
R-4900
|
reserved |
How to use these classification rules
The purpose of these rules is to enable different readers to classify AI risks in a uniform, repeatable manner. Apply them in order:
| Step | Ask | Settles | Rule |
|---|---|---|---|
| 1 | Is this a risk at all — or a mandate, control, constraint, or rubric? | whether the rest applies | 1 |
| 2 | Does this name adversarial conduct, a technical failure, an organizational failure, or an impact? | the class (provisionally) | 2 |
| 3 | Is AI a substantial contributor? | in scope at all | 3 |
| 4 | Within the class, where is the mechanism best controlled, or which impact category applies? | the domain | 4 |
| 5 | Is the cause a presence or an absence? | which end to assess | 5 |
| 6 | Which step of the chain is the deployment exposed at? | the attachment (the step the risk is about) | 6 |
| 7 | What does a pattern describe in this class? | the pattern | 7 |
Steps 1 and 3 are both scoping steps: step 1 removes statements that are not risks at all, and step 3 removes risks this taxonomy does not cover. Step 2 sits between them as prework for step 3: identifying the subject determines which scope test applies. Difficulty assigning a class is a reason to flag the statement and examine it more closely, not proof that it is out of scope.
Rules 8–10 are not part of this sequence: Rule 8 governs splitting when one statement contains more than one risk, and Rules 9–10 are addressed to the registry's maintainers.
Step #2 is essential orientation. Establish what the risk describes before asking how the blueprint can express it. Then ask where someone can intervene to check the analysis and identify corrective action. A convenient tag, detector, or pattern must not decide the class.
The representational constraint in Rule 5 is a constraint on expression, not a test for classification. An organizational failure remains class 3 even when its host construction has not been modeled; a technical failure does not become organizational merely because no available blueprint field describes it.
Rule 1: Control Statements Are Not Risks
A proposed risk identification that states a legal mandate, requirement, or business control — "Establish an input data policy", "Restrict unsafe tool calls", "Log model activity" — is not a risk that is covered by this AI Risk Taxonomy.
For example, look at control frameworks such as ISO 42001: a satisfied control is what is needed to mitigate a risk, not the risk itself. You can usually judge by phrasing. Note that a nominalized requirement ("Third-party testing of adversarial robustness") is still a requirement, not a risk covered by this taxonomy.
In some cases, the inverse of the control may be a recognizable risk. For example, the statement "Tool calls not monitored or constrained" is an expression of a risk and is the inverse of the control "Restrict unsafe tool calls".
Externally-imposed constraints are also not risks.
A statement describing what a law,
regulation, or licence
forbids
— an export restriction, a processing prohibition, a
data-residency requirement — is a constraint, not a mechanism. The risk is the
non-compliance, which may be a Governance Failure (e.g. under
R-3100 Regulatory & Legal).
The conduct that violates the constraint may itself be a recognizable risk (e.g. 'Use of copyrighted training data').
Evaluation rubrics are not control statements. An entry phrased as acceptance criteria — "Acceptable responses may…, unacceptable responses will…" — is describing a hazard by specifying how to test for it. Identify the hazard that is being evaluated and classify that. The distinction that matters is who authored the sentence about the system: a control statement is the deployer's own commitment, and its satisfaction is the absence of a risk; a rubric is an evaluator's description of a hazard that exists whether or not anyone tests for it.
If there is uncertainty as to whether a statement or hazard being evaluated is a risk that should be classified according to this AI risk taxonomy, continue through Rules 2 and 3. If no class fits it cleanly under Rule 2, treat that as evidence toward an out-of-scope determination under Rule 3.
Rule 2: Risk Classification
This AI Taxonomy has four classes: 1) Threats, 2) Failure Modes, 3) Governance Failures, and 4) Harms.
Classify the subject of the risk: adversarial conduct (class 1), a technical condition or failure that does not require an adversary (class 2), an organizational failure (class 3), or an impact (class 4). Ask where someone can intervene to check the analysis and identify the corrective action. The number of components involved, the team assigned to the fix, or the availability of a local control does not by itself determine the class. If a statement combines subjects, apply Rule 8. Rule 3 still decides admission.
| Subject | Class | Question |
|---|---|---|
| Adversarial conduct or intentional misuse | Threats (1) | Does the mechanism require adversarial action? |
| Technical condition or failure | Failure Modes (2) | Can this arise from the system's properties or operation without an adversary? |
| Organizational failure | Governance Failures (3) | Is the failure one of duty, accountability, or organizational process? |
| Injury or impact | Harms (4) | Does the statement describe the injury itself? |
Prompt injection is a threat because it requires adversarial instructions, not because a single input control might mitigate it. A technical output failure can also have a local filter or validator. Assigning both fixes to the same team does not make the risks the same class. Read the mechanism rather than relying on an upstream author's use of words such as "attack", "failure", or "harm".
The class chosen here is provisional until Rule 3 confirms the risk is in scope. A clean-seeming class assignment is not evidence of scope — a conventional security risk classifies fluently and is still out of scope.
Guidance for applying the class test:
- The classification of a risk as a threat is based on the mechanism, not on whether the candidate statement text mentions abuse. Upstream taxonomies may append boilerplate, such as "may enable, promote, or facilitate…", or "could be abused at scale", to entries whose mechanism is not actually adversarial. The relevant question is whether the mechanism cannot arise without an adversary. If the mechanism requires adversarial action, then it belongs in class 1. If it can arise from ordinary operation, the abuse clause describes an aggravating context, and Rule 8 may apply.
For some risks — those in
R-1600 Malicious Use
especially — the intentional misuse of the
system is where the adversarial conduct sits, and the party misusing it may be the deployer
rather than an outside attacker. Development and deployment of a capability for harmful
purposes is intentional misuse and belongs in class 1. Observe the split between that
intentional misuse and deployment contrary to regulation or law, which is a class 3
governance failure: the first names the conduct, the second names the violation.
-
The classification of a risk as a failure mode is based upon the system's own properties — its limitations, defects, drift, emergent behaviour, or physical and logical configuration. The fact that an attacker may take advantage of a weakness does not make it an attack under class 1, and the fact that a governance process failed to ensure that the system was properly built or configured does not make it class 3. Further, a class 2 risk does not require that the described failure occur every time; a failure that happens one out of every thousand times is still a failure mode of the system.
-
Do not classify a risk as a Governance Failure (class 3) unless the mechanism is truly organizational. If the mechanism is technical but governance failed to put in place the proper mitigation, then keep the technical class and add a relationship to the relevant Governance Failure.
-
Class 4 describes impacts caused or aggravated by AI use or deployment, admitted under Rule 3's recognition test. The harm may arise across many deployments or through competition and coordination effects. A deployment can sometimes reduce its own contribution, such as reducing resource consumption, without controlling the wider harm. That mitigation does not turn the impact into a technical failure. Conversely, a technical failure remains class 2 even when its consequences extend beyond the deployment.
Rule 3: Scope
This registry covers risks that are AI-specific, or to which AI system or deployment is a substantial contributor. It is not a general security or safety taxonomy. Scope is tested differently for mechanisms (classes 1-3) than for harms (class 4), because they are admitted for different reasons.
For risks in classes 1-3, the proper question is the counterfactual test: If you remove the AI component, does the mechanism still exist, at the same severity, in the same system? If the answer is yes, the risk still exists and is unchanged, then it is out of scope for this AI Risk Taxonomy.
| Example | Disposition |
|---|---|
| Weak or misconfigured permissions on a service that happens to host a model | out of scope — remove the model and the sentence is unchanged |
| Credentials elicited through interaction with the model or agent | in scope — the model is the vector; without it the mechanism does not exist |
| CVE in the web framework serving the model | out of scope — conventional application security |
| Model-authored output reaching a shell, template engine, or query planner | in scope — the model authored the payload |
| Adversary reads published papers to learn a target's architecture | out of scope — the control is publication hygiene |
| Adversary probes the live deployment to fingerprint AI services | in scope |
Two further tests, for nodes the counterfactual cannot reach (owner decision, 2026-08-07). The counterfactual asks whether removing the AI leaves the mechanism intact. Some upstream nodes have no "the system" in the sentence at all, so the question has no subject and the answer is not "in scope" — it is that a different test is needed.
-
Mental state. If an act is distinguishable from an ordinary one only by what the actor intended, it is out of scope. "Create an account" and "create an account in order to stage an attack" are the same act, and a taxonomy cannot hold the second without holding the first. This is what puts the adversary's preparation out: acquiring infrastructure, obtaining tooling, training a proxy on public data, crafting a prompt.
Producing a harmful or deceptive artifact through the AI system being assessed is a concrete operation of that system. It is not excluded merely because the artifact may be used in a later attack. - Locality. The subject of a risk is the system where the risk presents. An adversary renting servers is an operation on the adversary's infrastructure; the risk presents later, at the target, and it is whatever they then do there. Record the manifestation, not the preparation for it.
The operative fact is the concrete operation of the system being analyzed.
This is what
keeps probing in scope while preparation goes out, and the distinction is not intent. An
adversary's query is indistinguishable from a user's; the deployment
answering with its model
family, its system prompt, or the sources it retrieves from
is a concrete operation of that
deployment, and it is what the entry is about. The row above admitting fingerprinting stands on
the answering, not on the asking — which is also why
AML.T0042 Verify Attack
is out despite
using the inference API: the response is ordinary, and only the adversary's inference from it
is not.
Note that theft is not exfiltration. Unauthorized data removal by any means — a copied bucket, a flash drive, a compromised host — is theft, and it is out of scope. Exfiltration is in scope when the data leaves through an interface or flow the AI system exposes.
One narrow exception (owner decisions, 2026-08-06, 2026-09-25 and 2026-10-03): theft of the following AI artifacts is in scope regardless of channel. These are model weights and adapters, training and fine-tuning datasets, configuration that would reproduce the system, and stored AI-system configuration sufficient to tailor attacks to the deployment's instructions, capabilities, or tool connections. The AI-system configuration need not reproduce the deployment. Copying must exceed the access or distribution the deployment intends to provide; public accessibility alone does not establish intended release.
For these artifacts the consequence is AI-specific even where the copying mechanism is not. Copied weights provide a working copy of the capability, separable from the served system's controls. Copied AI-system configuration can expose the instructions and tool connections that shape the system's behavior, allowing attacks tailored to that deployment.
The exception does not extend to generic credentials, infrastructure settings, telemetry,
logs, or business data merely because they share a file with AI-system configuration or could
help an attacker. Those remain subject to the channel test. AI-system tool-connection configuration
qualifies when it meets the AI-system-specific condition above; an ordinary infrastructure setting
does not qualify merely because an AI system runs on that infrastructure.
R-1330 Artifact Exfiltration
holds the in-scope form.
Another test for proper scope: is the route something the deployment itself provides — an interface, a response, or an invocation that would appear in a diagram of the system's own dataflows?
An inference API, a rendered response and a tool invocation are all flows the deployment provides; a flash drive is not, no matter how the story around it is told. An insider using legitimate API access at volume is in scope: the route is one the deployment provides, whatever the actor's entitlement. Scope follows the channel, not the authorization.
For risks in class 4, scope is determined by industry or regulatory recognition, not the counterfactual test. Discrimination, labor displacement, misinformation, environmental cost and concentration of power all predate AI and would survive its removal. These are still included in the AI risk registry because the registry's job in class 4 is to inventory what practitioners must reason about, not to prove AI is the unique cause of the harm.
Admission test for a harm: industry or regulatory consensus. A harm is admitted when a recognized body treats it as an AI harm — a regulator, a standards or safety framework, or literature the field has adopted. Cite the source; the citation is the justification.
Do not apply the counterfactual test to a harm, and do not admit a harm on your own reasoning that it is important. The two failure modes this prevents are equal and opposite: silently dropping consensus harms because AI did not originate them, and silently adding harms nobody authoritative has claimed.
Rule 4: Domain Selection
Each class is subdivided into areas of action, termed "domains". Rule 2 has already identified the subject and class. For classes 1–3, choose the domain where the primary mechanism is best controlled. Control locality helps select a domain within the class; it does not override the class test.
Domains are about control points. Do not classify the domain by: - Where downstream consequences are felt - Where an auditor would notice it - The attacker's ultimate goal
When two control points are equally applicable, prefer the earlier one in the flow. This is frequently (but not always) a distinction between a control point that prevents and a control point that contains. Do not tie-break on which control is cheaper or easier to implement; that is a judgement about deployment, not a taxonomic classification.
Classify by the attacked role and mechanism, rather than by the artifact’s name or the attack’s eventual effect. A model supplied with a backdoor is a compromised deployment artifact under R-1300; poisoning data used to train it attacks learning under R-1400. Copying stored weights belongs under R-1300; reconstructing weights from model behavior belongs under R-1400.
For class 4, choose the domain by impact category per Rule 7. A local mitigation of the deployment's contribution does not change the category of injury being assessed.
Rule 5: Identify the Positive Construction of the Risky State
For purposes of this taxonomy, we determine risk placement based upon what can be positively recorded about a system. This is the inverse of many risk-control vocabularies: a control framework states the control (e.g. "Encrypt sensitive data at rest"), while this taxonomy records the risky state that control would remove (e.g. "sensitive data is stored in plain text").
This is an intentional modeling restriction designed to distinguish and classify different types of risks. Because the number of negative statements about a system is infinite, the registry's risk vocabulary is built on the identification and labeling of risky, dangerous, or exceptional states and the effects of those states within the system. There is no mark for "this data is ordinary" — ordinariness is what remains when no risky state applies, not a fact anyone writes down.
For risk classifications, this means that the positive construction of a risky state is construed differently depending on whether the cause is a presence or an absence. For example:
| The cause is… | Assess at | Because |
|---|---|---|
| a presence | the cause | The condition is a positive fact and can be recorded. Confidential material is in the training corpus — the corpus can be marked as holding it, and everything downstream inherits from there. |
| an absence | the exposure | Nothing can record what is missing. A population is absent from the training corpus — there is no mark to place, because nothing is there to mark. The effect is present, though: a determination about a person, arriving somewhere it is acted on, is something a description of the deployment does record. |
Classes 1 and 2 differ only in who introduces the state — an adversary supplies it in Class 1; in Class 2 the system supplies it itself, as a property a system component is recorded as having. The execution path, the place where the risk takes effect (the "sink"), and the ordering are identical in shape.
Class 3 risks are defined almost wholly in terms of their absence, so the first positive construction of a class 3 risk is where a prohibited or risky action takes place due to the missing organizational control. Some class 3 entries have no such point in any single system — "the organization has no AI governance committee" names nothing in a deployment. These are carried as inventory: classified and recorded, with no positive construction expected of them.
Rule 6: Determine Attachment — which step of the chain carries the risk
For purposes of this taxonomy, a risk attaches where it is first recordable in the context of the AI system as a positive fact or effect.
Note that a single hazard or risk statement often narrates several steps of an attack. The risk attaches to the step at which the modelled deployment is exposed. Earlier steps are context recorded in the risk's description, not risks of their own.
| Step | Disposition |
|---|---|
| Adversary trains a proxy model offline to craft an adversarial example | context — the deployment is not yet exposed |
| That example is submitted to the deployment | the risk — this is where control exists |
Note that preparation does not set scope. Adversary-side staging can be AI-specific — passing Rule 3 — and still not be a risk of its own, because nothing in the deployment is yet reachable. Conversely, a hazard statement whose only content is preparation attaches nowhere and is recorded as out of scope with that reason.
This type of reasoning applies across classes 1 and 2. The general construction could be described as: A component or interaction creates or exposes a risky state because that state reaches a sink (where the risky state is used, acted upon, or the harm occurs) before the risky state is removed or mitigated.
Note the importance of ordering over existence: A deployment can include a proper control or guardrail (e.g. there can be a PII filter deployed in the system) but the harm can still occur if the PII filter is not in the path between where the PII is introduced and where it causes harm (the sink).
Rule 7: Pattern Selection
Choose the pattern that describes:
| For Class | Pattern describes |
|---|---|
| Threats | Technique or attack vector |
| Failure Modes | Failure mechanism |
| Governance Failures | Broken control or process |
| Harms | Impact category (who/what is harmed, how) |
For data defects, distinguish material used to train, tune or evaluate a model from reference material retrieved as context during inference. Arrival time does not decide this boundary: continuous learning still updates the model, while retrieval can use a fixed corpus. R-2610 concerns defects in the corpus contents; R-2630 concerns selection and reuse of operational material for subsequent model updates. Assess both where both mechanisms occur. Under Rule 4, a data-admission defect belongs in R-2600 even when its consequence is changed model behavior. The participation of people or automation in admission does not determine the classification.
Rule 8: Handling Multi-Class Risks
A statement can contain more than one risk. Separate risks must identify a materially different corrective action or separately scoped protection obligation. If the same issue can arise through concrete paths that require different interventions, represent those paths as separate risks. Do not enumerate hypothetical paths merely to complete a taxonomy; expand when a source or deployment case establishes them.
For classes 1–3, identify the failure condition or causal mechanism and the specific action needed to prevent, contain, or correct it. Different mechanisms, names, upstream categories, or degrees of severity do not alone establish distinct risks: explain how the distinction changes mitigation. For class 4, prefer a common pattern for the same family of harms and separate leaves when the injury or affected interest requires a materially different remedy or protection obligation. A different population or example alone is insufficient.
A distinct mitigation does not require a unique control technology. Access control, review, monitoring, disclosure, and redress are broad activities, not sufficiently specific mitigation arguments. Name the authorization decision, protected object, acceptance boundary, retained state, or remedy that must change. Separate assets can justify separate risks when their intended recipients, permitted uses, or protection obligations require independent decisions; a different asset name alone does not.
For every proposed split or retained disputed distinction, record each side's precondition, mechanism or injury, and specific corrective action. Give a concrete separating case in which the relevant fix for one side is correctly implemented while the other remains exposed, and explain why. State when both risks can occur and why that represents two mitigation or protection requirements rather than duplicate coverage. Different checks within one coherent corrective action do not by themselves justify separate risks.
Pattern grouping and individual risk identity are separate decisions.
A broad umbrella
belongs at pattern level rather than as a leaf beside its own specializations unless the
leaf has an independently supported mitigation requirement. Do not force disjoint definitions
to preserve labels, invent residual scope, or merge distinct protection obligations because
one product implements both controls. If evidence does not establish a boundary, record the
uncertainty. Upstream node counts do not decide granularity: see "Granularity regimes" in
../docs/crosswalk-mapping-conventions.md.
Patterns carry no taxonomy references; crosswalk links attach to risks. Never create a risk solely to give an upstream node a single link target. A risk exists because its mitigation is distinct.
Apply the class rules before the mitigation test. An attack, a technical failure, an organizational failure, and an injury are different subjects, not interchangeable labels. Linked entries across classes still need independently supported subjects and an explanation of the distinct prevention, correction, protection obligation, or remedy each records. A consequence, motivation, or generic assertion that governance could have prevented an attack is insufficient to create another entry.
Relationships Between Risks
| Type | Label | Use |
|---|---|---|
causes
|
Causes | Mechanism leads to a harm |
exploits
|
Exploits | A threat takes advantage of a failure mode |
enabled_by
|
Enabled By | A mechanism is made possible by a governance failure |
related
|
Related | General association, no direction claimed |
Rule 10: Stability
Identifiers never change once assigned. Names and descriptions may be corrected.
IDs are expected to be referenceable long term, so churn there is expensive. Names and descriptions carry no such cost. Accordingly, a name that misdescribes its contents, or a description that states the mechanism or injury wrongly, should be fixed, because both actively mislead. A risk label may be changed if experience shows that users trying to classify risks are misled by a domain label whose name promises facets its patterns do not implement.
A correction may not change what the entry is: the mechanism for classes 1–3, or the injury and affected interest for class 4. Replacing that subject is a reclassification, not a wording correction, and takes the last row of the table below. Consolidating patterns does not authorize changing the identities of the risks they contain.
| Scenario | Action |
|---|---|
| Merged |
Keep the lowest ID; mark others
status: deprecated
with
superseded_by
|
| Split | Keep original ID for one child; assign new IDs to others |
| Deprecated |
Keep the original ID; set
status: deprecated
|
| Reclassified |
Deprecate original; create new entry with new ID and
superseded_by
link
|
Using the Identifiers
You can use R-IDs to:
- Reference risks in documentation — "Our system implements controls for R-1110.002 (Indirect Instruction Injection)"
- Map to compliance frameworks — Cross-reference R-IDs with NIST AI RMF, OWASP, or other standards
- Track risk assessments — Use R-IDs as stable keys in your risk management systems
- Communicate with stakeholders — Provide precise risk references in reports and discussions
Cross-Reference Taxonomies
- IBM Risk Atlas
- NIST AI RMF
- OWASP LLM Top 10
- OWASP LLM Top 10 (2024)
- OWASP LLM Top 10 (2025)
- OWASP LLM Top 10 (2026)
- CREDO AI UCF
- AILuminate
- MIT AI Risk Repository
- Cisco AI Taxonomy
- Cisco Model Security (MDL)
- OWASP Agentic Security Initiative
- MITRE ATLAS
- MITRE ATT&CK
- NIST AI/ML Framework
- AIUC-1
Registry Versioning
Format
YYYYMM.X
-
YYYY— Year -
MM— Month -
X— Release within month (0-9)
Examples
| Version | Meaning |
|---|---|
202601.0
|
First release, January 2026 |
202601.1
|
Second release, January 2026 |
202602.0
|
First release, February 2026 |
Rules
-
New entries get
introduced_inset to current draft version -
Deprecated entries get
deprecated_inset when deprecated -
Once a version is
published, its entries are immutable - Corrections go in the next version