| name | mapping-selection |
| description | Select the structured references and framework mappings for a CoSAI Risk Map control or risk — for a control: which components it applies to, which risks it addresses, and which mappings (MITRE ATLAS mitigations, NIST AI RMF subcategories, OWASP LLM) fit; for a risk: which components it impacts, which controls address it, and which mappings (MITRE ATLAS techniques, STRIDE, OWASP LLM) fit. Use when authoring or reviewing a control and choosing its components/risks/mappings, or when a mapping looks off (wrong NIST function, a technique used where a mitigation belongs, or over-mapping). Grounds every choice in the actual corpus and the framework applicability rules rather than guessing. |
Mapping Selection
Choose a control's structured references — components, risks, and framework mappings — and justify each. The failure this skill prevents is confident-but-wrong selection: mapping to "related" rather than directly-relevant items, over-mapping, mixing MITRE techniques with mitigations, or picking the wrong NIST AI RMF function.
Scope: both the control direction (a control's components/risks/mappings) and the risk direction (a risk's components/controls/mappings) — see the two sections below.
Procedure
1. Components — where the defense lives
Read risk-map/yaml/components.yaml. Select the components where the control's mechanism actually operates — the locus of the defense. Guidance:
- Prefer the specific components. Each one you list should be a place the control genuinely acts, not merely a place the risk appears.
- Use
"all" only for a universal/governance/assurance control that genuinely applies framework-wide.
- Use
"none" only when the control applies to no specific component.
- Do not over-select. If you are tempted to list five components, check whether the control is really one control or several.
2. Risks — what the control addresses
Read risk-map/yaml/risks.yaml. Select the risks this control directly mitigates. A mapping should be defensible in one sentence ("this control reduces the likelihood/impact of risk X because…"). Flag any that are merely "related." Be selective.
If you set risks: "all", the control is universal — and those risks must not list it back (application is implicit). "none" is not valid for risks.
3. Framework mappings — the discipline
Read references/frameworks-applicability.md for the rules. In brief:
- Applicability: map only to frameworks that apply to controls.
- MITRE ATLAS: controls map to mitigations (
AML.M####), never techniques (AML.T####). If no mitigation fits cleanly, omit ATLAS rather than forcing a technique.
- NIST AI RMF: use the subcategory id (e.g.,
GOVERN-6.2), never the category alone, and pick the right function — this is the most common mistake:
- GOVERN — policy, roles, responsibilities, oversight, culture, risk tolerance. Most preventive design and human-oversight controls land here.
- MAP — establishing context, framing intended use, identifying impacts.
- MEASURE — assessment, testing, metrics, evaluation, tracking.
- MANAGE — responding to, prioritizing, treating, and recovering from identified risks (reactive/operational). Do not use MANAGE for a preventive design control.
- OWASP Top 10 for LLM:
LLMxx:2025.
- Selective: soft cap of 4 per framework; one-sentence rationale each.
- Generate, don't hand-spell: mapping values are version-pinned. Produce them with
scripts/framework_mapping_maintainer.py (ADR-027). If you cannot run it, state the intended mappings and mark them for tool-generation.
4. Reciprocity
For each risk in the control's risks list (unless universal), name the reciprocal risks.yaml edit: that risk's controls array must list this control back.
Risk direction
For a risk entry, the mirror of the control procedure:
Components — where the risk manifests
Read risk-map/yaml/components.yaml. Select the components where the risk actually arises or takes effect (its locus). Be specific; do not list components the risk is merely "related" to.
Controls — what addresses it (control-selection)
Read risk-map/yaml/controls.yaml. Select the controls that directly mitigate this risk, each defensible in one sentence. "Related" is not "addresses." Do not list a universal control (one with risks: "all") — its application is implicit.
Framework mappings — the risk-side rules
- MITRE ATLAS: risks map to techniques (
AML.T####), never mitigations (AML.M####) — the mirror of the control rule. Do not map both a parent technique and its sub-technique.
- STRIDE: one or more of the six categories (
spoofing, tampering, repudiation, information-disclosure, denial-of-service, elevation-of-privilege). STRIDE is risk-side.
- OWASP Top 10 for LLM:
LLMxx:2025.
- NIST AI RMF does NOT apply to risks — it is control-side only. Do not add a NIST AI RMF mapping to a risk.
- Selective (≤4/framework), one-sentence rationale each,
[tool-generate] the pinned values.
Reciprocity
For each control in the risk's controls list, that control's risks array must list this risk back (risk.controls ↔ control.risks).
Output format
- Components: list, each with a one-line reason (the locus).
- Risks: list, each with a one-line reason (direct relevance).
- Mappings: per framework, each value with a one-line rationale and a
[tool-generate] marker if not yet generated.
- Reciprocal edits: the exact
risks.yaml controls additions.
- Flags: anything uncertain — a mapping that needs framework-text verification, a component you were unsure about, a possible over-map.
Reference
references/frameworks-applicability.md — applicability matrix, MITRE mitigation-vs-technique rule, and the NIST AI RMF function cheat-sheet.- Authoritative source:
risk-map/docs/contributing/framework-mappings-style-guide.md (canonical pinned patterns and the maintainer tool).
