Skip to main content
Jira progress: loading…

RMAP

Risk Mapping Engines

1. Identity​

AttributeValue
Type codeRMAP
Canonical nameRisk Mapping Engines
Parent type—
Type statusreview
Tier scopetier-2, tier-3
Invocationchained
Payload effectannotate
Lineage rolestamps-cmi

RMAP is a category boundary, not an identity. Members are identified by MEID, versioned through ZAR as CMIs, and carry mice.category: RMAP. The type itself has no MEID, no CMI and no runtime presence.

2. Purpose and boundary​

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.

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.

3. Membership criteria​

3.1 Inclusion tests​

A micro engine is a member of RMAP when its specification satisfies the following:

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

Examples

  • Mapping water stress metrics to physical risk bands
  • Translating emissions intensity into transition risk levels
  • Assigning supply-chain indicators to exposure categories

3.2 Exclusions​

A micro engine is not a member of RMAP when any of the following is its responsibility; each belongs to the type named:

  • ❌ 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.

3.3 Boundary cases​

  • RMAP versus SCORE: RMAP assigns a category or band from thresholds under one framework; SCORE combines several signals into a composite indicator with weights.
  • RMAP versus META: a risk band is RMAP; a taxonomy or scope tag is META.
  • RMAP versus ALERT: RMAP interprets into risk space; ALERT detects a rule violation and recommends an escalation.

4. Design rules​

RULE-RMAP-001 — Framework-Driven Mapping

Every risk mapping is tied to a declared framework (e.g. TCFD, ESRS, internal risk models).

RULE-RMAP-002 — Deterministic Interpretation

Given the same inputs and rules, RMAP engines always produce the same classifications.

RULE-RMAP-003 — Explainability by Construction

Each risk outcome is traceable to explicit thresholds, rules, or mappings.

RULE-RMAP-004 — Non-Mutating Values

RMAP engines SHALL NOT alter the underlying numeric signal values.

5. Contract​

5.1 Inputs​

RMAP engines consume:

  • Validated and (optionally) normalized signals
  • Enriched metadata (taxonomy, scope, context)
  • Explicit risk framework definitions, including:
    • thresholds
    • categories
    • mapping rules

Inputs SHALL be complete and temporally consistent.

5.2 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.

6. Position in the computation chain​

6.1 Placement​

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.

7. Identity rules for members​

Members are micro engines (CMPS-001 mice: block) whose identity satisfies all of the following:

  • mice.category SHALL be RMAP.
  • The CAPABILITY segment of the MEID (MEID_<DOMAIN>_<CAPABILITY>_<FUNCTION>) SHALL be one of CLASSIFY.
  • The DOMAIN segment SHALL be RISK.
  • Typical FUNCTION segments: CLASSIFIER, HAZARD.
  • CMI kinds bound through zar.meid_cmi_binding SHALL be among ENGINE, RULESET.
  • Lineage: members append their CMI stamp to the USO lineage tail.
  • Tier scope: tier-2, tier-3; invocation: chained; payload effect: annotate.
  • USO role: interprets signals into risk frameworks

RMAP identifiers appear in:

  • signal lineage (CMI stamps),
  • risk explainability layers,
  • audit and governance trails.

10. Members​

Loading micro engines…
  • NORM — Normalization Engines
  • META — Metadata Enrichment Engines
  • AGGR — Aggregation Engines
  • GEOX — Geospatial Engines
  • SCEN — Scenario Engines
  • SCORE — Scoring Engines
  • AME — Assurance / Meta engines
  • CALC — Calculation Engines
  • AAE — Autonomous Assurance Engine


GitHub RepoRequest for Change (RFC)