§1What is this?
The EW-AiRM™ Mapping Explorer is a browseable map between two large datasets: the risks of AI systems catalogued by MIT, and the controls organisations can put in place to mitigate them.
The Explorer answers two reciprocal questions in a single interface:
- "Given this risk, which controls should I be thinking about?" — Browse by Risk view, on a pale-red background.
- "Given this control, which risks does it address?" — Browse by Control view, on a pale-green background.
Both views draw from the same underlying mapping, just read in opposite directions. Switching between them is a single click at the top-left of the header.
1,150Mapped Risks
780Unmapped Risks
831Controls
173kPrimary
281kSecondary
312kTertiary
766kTotal Mappings
The mapping covers 1,150 AI risks across the 7 domains and 24 sub-domains of the MIT Domain Taxonomy, and 831 controls across 27 mitigation categories grouped into four areas (Governance, Technical & Security, Operational Process, Transparency & Accountability). The combined mapping produces 765,944 Risk×Control pairs, each classified into one of three strength tiers.
A further 780 "unmapped" risks — ones that sit outside the canonical 24 sub-domains — are available via the "Include Unmapped" toggle and carry semantic-only candidate controls (explained in §7).
§2The underlying data
The Explorer stitches together two independently maintained, publicly licensed datasets:
- MIT AI Risk Repository v4 (3 December 2025 snapshot) — a living catalogue of AI-associated risks extracted from the academic, policy, and grey literature. The Explorer uses the 1,150 risks that fall under the 24 canonical sub-domains.
- MIT AI Mitigation Database (23 July 2025 public snapshot) — a catalogue of 831 controls distributed across 27 MitigationCode categories.
Both are published under CC BY 4.0. Neither dataset contains native cross-references to the other — the Risk↔Control mapping is constructed from scratch by combining a hand-built rule matrix (structural backbone) with a TF-IDF semantic similarity layer (within-tier ranking). The full methodology is documented in the companion 63-page Methodology Report.
A note on the 1,734 figure
Earlier EW-AiRM™ documentation sometimes cites 1,734 risks. The full atomic-risk pool in the Repository v4 is actually 1,930 — 1,150 with valid canonical sub-domain assignments (the MAPPED set) plus 780 without (the UNMAPPED set). The 1,734 figure corresponds to an earlier Repository version; 1,150 is the correct denominator for a sub-domain-grouped mapping, and 1,930 for the complete atomic pool.
§3The three tiers — what they mean
Every Risk×Control pair carries one of three strength tiers. These are not severity ratings of the risk; they describe how directly the control category is designed to address the type of risk in question.
PRIMARY
Specifically designed to address
The control category exists explicitly to mitigate risks of this type. The category is the proximate, targeted mitigation.
Example: Category 2.1 (Model & Infrastructure Security) is Primary for sub-domain 2.2 (AI system security vulnerabilities) — this is precisely what the category was built for.
Weight: 3
SECONDARY
Significant but not principal
The control category addresses the risk as a significant concern, but its main purpose lies elsewhere. These are important supporting controls.
Example: Category 3.1 (Testing & Auditing) is Secondary for sub-domain 2.2 (Security) — testing is part of the security regime, though its own principal target is robustness and bias verification.
Weight: 2
TERTIARY
Cross-cutting / indirect
The control category provides broad governance coverage or indirect mitigation applicable across most sub-domains. Think board structure, general risk management, whistleblower protection.
Example: Category 1.1 (Board Structure & Oversight) is Tertiary for most sub-domains — a well-governed organisation applies it uniformly, but it doesn't target any one failure mode specifically.
Weight: 1
How many tiers per sub-domain?
A typical risk sub-domain row in the rule matrix has 4–6 Primary, 5–7 Secondary, and 4–8 Tertiary control categories, with the rest of the 27 categories unmapped for that sub-domain. The full 24×27 matrix is colour-coded P/S/T in the Rule_Matrix sheet of the workbook.
Why the true totals aren't evenly split
Across the 765,944 pairs in the full dataset, Tertiary (311,674) and Secondary (280,857) together exceed Primary (173,413). This is structural, not a quirk:
- A narrow Primary category like 1.6 (Environmental Impact) applies to only one sub-domain, so it contributes few Primary rows.
- Broad cross-cutting categories like 3.1 (Testing & Auditing — 127 controls) and 1.2 (Risk Management — 125 controls) are Secondary or Tertiary for most sub-domains, and they happen to hold the largest number of individual controls.
This reflects the structure of AI-governance literature: more controls are written about broad testing, documentation, and governance than about any one narrow failure mode. Within the Explorer, the Top-N selector (§6) applies per tier precisely so Primary mappings are never crowded out by the much larger Secondary and Tertiary pools.
§4Scoring & within-tier ranking
Within each tier, controls are ranked by a composite score that combines the tier weight with a TF-IDF cosine similarity between risk text (name + description) and control text (name + definition):
Tier weights are 3 / 2 / 1 for Primary / Secondary / Tertiary. The (1 + ...) construction ensures tier dominates ordering: a Primary pair with zero similarity (score 3.00) still outranks a Secondary pair with perfect similarity (score 4.00 would need Secondary × 2 = 4 × 1.5, which requires similarity ≥ 0.5, rarely reached). Within a tier, higher-similarity pairs rank higher.
Each risk sees its mapped controls ranked; those ranks drive the Top-N selector. Similarity scores are shown on every mapping row as sim 0.234 with a small bar — higher bars indicate stronger lexical overlap between the risk description and the control definition.
Similarity is lexical, not semantic
TF-IDF captures shared terminology but not shared meaning. A risk using "red-teaming" language and a control using "adversarial testing" language will score low even if they are conceptually equivalent. Treat within-tier rank as advisory, not definitive — if a control with lower similarity score looks relevant, it probably is. A dense-embedding refresh is planned for v2.
§5Reading the Explorer UI
Browse by Risk
Pale-red background. Tree on the left organises 1,150 risks by 7 domains → 24 sub-domains. Click any sub-domain to see its risks; click any risk to see the controls mapped to it.
On the risk detail page, you'll see:
- Risk name, description, source, domain, sub-domain.
- (If Mapping Counts toggle on) a chip row showing total mapped and per-tier breakdown.
- A tier-summary strip showing how many controls are visible per tier relative to the total.
- Mapped controls, grouped by tier with PRIMARY / SECONDARY / TERTIARY separator bars. Each row shows rank within tier, tier badge, control ID and category, control name, similarity score.
Browse by Control
Pale-green background. Tree on the left organises 831 controls by 4 top-level areas → 27 categories. Click any category to see its controls; click any control to see the risks it addresses.
On the control detail page, you'll see:
- Control name, definition, category, area, source.
- (If Mapping Counts toggle on) a chip row showing total risks addressed and per-tier breakdown.
- A tier-summary strip.
- Addressed risks, grouped by tier with separator bars. Each row shows rank, tier badge, risk ID and sub-domain, risk name, similarity score.
Clicking any row in a mapping list jumps to the reciprocal view — so clicking a control from a risk's list brings you to that control's risks-addressed view, with the mode background switching from pale-red to pale-green to reinforce the context change.
Tier chips
Three coloured chips in the header — Primary (green), Secondary (amber), Tertiary (yellow) — let you filter the mapping lists by tier. All three are on by default. Click a chip to dim it; click again to re-enable. Hover any chip for a summary of what the tier means.
§6Toggles & the Top-N selector
Four controls in the header let you tune the display without changing the underlying data.
Top-N Selector (Top-10 / 30 / 50 / ALL)
Applies per enabled tier. With all three tiers on and Top-30 selected, you see up to 90 controls per risk (30 Primary + 30 Secondary + 30 Tertiary). Default: 30.
When to use each: Top-10 for quick triage of most-relevant controls; Top-30 for normal browsing (default); Top-50 when you want the full shortlist for a working session; ALL to see everything in the payload (up to the 50-per-tier cap for forward view, 30-per-tier for reverse).
Mapping Counts toggle
When on, every risk and control shows a count in brackets — (N) for total, plus per-tier breakdowns on detail pages (X total · Y Primary · Z Secondary · W Tertiary).
Pill colours: green for high counts (≥100), default for normal (20–99), amber for sparse (<20). Useful for spotting risks with thin coverage or high-leverage controls.
Advanced Search toggle
Default search filters tree labels only (risk names, control names, IDs, sub-domain codes). Advanced Search extends the search into full risk descriptions and control definitions.
Results appear in a three-section overlay (Mapped risks, Unmapped risks, Controls) with matched terms highlighted in gold. Up to 200 matches per section; refine the query if you exceed that.
Include Unmapped Risks toggle
Off by default. When on, a second section appears in the Risk-view tree containing the 780 risks outside the canonical 24 sub-domains. These carry semantic-only candidate controls (see §7) and use the red unmapped colour palette throughout.
Search behaviour
Three forms of search are supported:
- Tree filter (basic) — type any substring; tree items not matching are hidden. Applies to risk names, control names, category names, and IDs in the tree.
- ID jump — type an exact ID like
R0378 or C520 to jump directly. Works for unmapped Risk IDs (R1151–R1930) too — the Include Unmapped toggle auto-enables if needed.
- Advanced Search — toggle on, then type a search term to scan full descriptions and definitions. Results shown in the main panel instead of filtering the tree.
§7Unmapped risks
Not every risk in the MIT Repository fits neatly into one of the 24 canonical sub-domains. These 780 "unmapped" risks are treated separately.
Three buckets of unmapped risks:
| Bucket | Count | Meaning |
|---|
NO_SUBDOMAIN |
661 |
Mostly "Additional evidence" rows from the Repository that didn't carry forward a sub-domain assignment from their parent risk. |
EXPLICITLY_EXCLUDED |
86 |
Risks marked X.1 > Excluded by MIT — often NSFW prompt examples explicitly removed from the canonical taxonomy. |
ROOT_LEVEL |
33 |
Risks assigned to a root-level sub-domain like 7.0 > AI system safety, failures, & limitations but not refined to a specific canonical sub-domain (7.1–7.6). |
Because these risks don't slot into the rule matrix, they can't receive a rule-matrix-driven Primary/Secondary/Tertiary tier. Instead, they get semantic-only candidate controls — up to 10 controls per risk, ranked purely by TF-IDF cosine similarity. Each candidate carries a Coverage_Flag:
- SEMANTIC_CANDIDATE (similarity ≥ 0.10) — plausible match, advisory
- WEAK_CANDIDATE (0.05 ≤ similarity < 0.10) — low-confidence hint
- INSUFFICIENT_DATA — source risk description too short to match anything
Unmapped risks and their candidate controls should be treated as expert-review seed material — a starting point for manual classification into the canonical taxonomy or contribution back to the MIT Repository. They should not be treated as validated Risk↔Control relationships on their own.
§8Caveats
Important limitations to bear in mind
- The mapping is descriptive, not prescriptive. It shows which controls could plausibly apply to which risks. It doesn't tell you which controls you must implement, nor weight them by cost, effort, or maturity.
- The rule matrix reflects the author's judgement. Individual tier cells (P/S/T) are contestable and should be validated by your own organisation before operational use. A structured Delphi-style review is the recommended v2 path.
- TF-IDF similarity is lexical, not semantic. Conceptually-equivalent pairs using different vocabularies (e.g., "red-teaming" vs "adversarial testing") will score low. Treat within-tier rank as advisory.
- Sparse sub-domains (7.5 AI welfare and rights, 6.4 Competitive dynamics, 1.3 Unequal performance across groups) have small risk counts that make coverage ratios unstable.
- Dataset drift. The Repository (Dec 2025) and Mitigation DB (Jul 2025) are independently maintained — some 4.5 months apart. Changes to either after those dates may affect mapping validity. A quarterly refresh is recommended.
The full 63-page Methodology Report discusses these and five other limitations in depth, and proposes a concrete six-gap-type closure plan covering rule-matrix validation, dense-embedding refresh, sparse sub-domain reinforcement, dataset-drift monitoring, missing-control identification, and regulatory cross-walks to the EU AI Act, ISO/IEC 42001, and NIST AI RMF.
