RMAP
Risk Mapping Engines
1. Overview
Risk Mapping Engines (RMAP) are micro-engines that translate validated and enriched signals into risk-relevant representations using explicit risk frameworks.
RMAP engines do not compute, aggregate, or modify numeric values. They interpret existing signals by mapping them into risk categories, bands, or taxonomies used for disclosure, scenario analysis, and governance.
RMAP is an engine type within the MICE taxonomy. Concrete risk mappers are implemented as MEID-registered micro engines.
2. Design Principles
-
Framework-Driven Mapping
Every risk mapping is tied to a declared framework (e.g. TCFD, ESRS, internal risk models). -
Deterministic Interpretation
Given the same inputs and rules, RMAP engines always produce the same classifications. -
Explainability by Construction
Each risk outcome is traceable to explicit thresholds, rules, or mappings. -
Non-Mutating Values
RMAP engines never alter the underlying numeric signal values.
3. Scope of Responsibility
3.1 What RMAP engines do
RMAP engines perform semantic interpretation of signals into risk space, including:
- Mapping metrics to risk categories
- Assigning qualitative or ordinal risk levels (e.g. low / medium / high)
- Aligning signals with external risk frameworks
- Translating raw indicators into governance-consumable risk views
Typical examples:
- Mapping water stress metrics to physical risk bands
- Translating emissions intensity into transition risk levels
- Assigning supply-chain indicators to exposure categories
4. What RMAP engines do not do
RMAP engines explicitly do not perform:
- ❌ Numeric computation (CALC)
- ❌ Aggregation or roll-ups (AGGR)
- ❌ Normalization or scaling (NORM)
- ❌ Taxonomy tagging or enrichment (META)
- ❌ Estimation or extrapolation (SEM)
- ❌ Policy enforcement or routing (ZSSR)
RMAP engines interpret — they do not decide or enforce.
5. Inputs
RMAP engines consume:
- Validated and (optionally) normalized signals
- Enriched metadata (taxonomy, scope, context)
- Explicit risk framework definitions, including:
- thresholds
- categories
- mapping rules
Inputs must be complete and temporally consistent.
6. Outputs
RMAP engines produce:
- Risk classifications or bands
- Risk metadata, such as:
- framework identifier
- risk category
- severity level
- Provenance references linking:
- source signal(s)
- applied mapping rules
- engine version
RMAP outputs are commonly consumed by:
- scenario engines (SCEN),
- scoring engines (SCORE),
- governance and reporting layers,
- assurance workflows.
7. Position in the computation chain
Risk mapping typically occurs after computation, aggregation, normalization, and enrichment:
INPUT
→ VALI
→ CALC
→ TRFM
→ AGGR
→ NORM
→ META
→ RMAP
→ SCEN / SCORE / Reporting
This ensures that risk interpretation is applied to trusted, contextualized data.
8. Canonical identification
- Engine Type: RMAP
- USO role: interprets signals into risk frameworks
- Category: Micro Engine (MICE)
RMAP identifiers appear in:
- signal lineage (CMI stamps),
- risk explainability layers,
- audit and governance trails.
9. Registry view
All engines tagged as rmap:
10. Design rationale
Risk is not a number — it is a mapping between facts and decision frameworks.
By isolating risk mapping into a dedicated engine type, ZAYAZ ensures:
- clear separation between facts and interpretation,
- consistent risk logic across reports and scenarios,
- explainable risk outcomes for auditors and stakeholders,
- reuse of risk frameworks without recomputing metrics.
11. Related engine types
- META — Metadata Enrichment Engines
- NORM — Normalization Engines
- SCEN — Scenario Engines
- SCORE — Scoring Engines
- AAE — Autonomous Assurance Engine
Stable