# Front matter

### 1. Preface

#### 1.1 Purpose of This Document

This document defines **Nexus Risk Management (NRM)** as a **technical, scientific, governance, and business standard** for systemic risk management in the human–machine–nature intelligence era.

It has five primary purposes:

1. **Formalise the concept of NRM**
   * Provide a **precise and reproducible definition** of Nexus Risk Management as:
     * The **systemic, ecosystem-facing extension** of Enterprise Risk Management (ERM), and
     * The risk-specific instantiation of the **Nexus Ecosystem Rail** (data, semantics, AI, governance, capital).
   * Clarify how NRM **aggregates** and **orchestrates** existing risk regimes (financial, engineering, disaster risk reduction, climate, health, cyber, social), rather than attempting to replace them.
2. **Specify architecture and implementation requirements**
   * Describe the **end-to-end architecture** of NRM on the Nexus Rail and UNOSINT stack:
     * Semantic layer (core risk ontology and domain modules),
     * Data and graph layer (federated risk mesh),
     * Analytics and AI layer (scoring, simulations, rulebooks),
     * Interfaces, controls, and auditability.
   * Define minimum technical, process, and governance requirements for systems, institutions, and programmes that claim **NRM conformance**.
3. **Anchor mandates and authorities within Nexus institutions**
   * Operationalise the roles of:
     * **GCRI** as the technical and scientific steward of NRM methods and infrastructure,
     * **GRF** as the governance, standard-setting, and consortia authority for NRM,
     * **GRA** as the capital and industry authority that translates NRM into risk financing and resilience programmes.
   * Specify how **Regional Nexus Consortia (RNCs)** and **Nexus Competence Cells (NCCs)** implement NRM in countries, sectors, and regions.
4. **Provide a reference for external adoption and regulatory reliance**
   * Give regulators, supervisors, DFIs, enterprises, and infrastructure operators a **single, stable reference** for:
     * What “Nexus Risk Management” means in practice,
     * What outputs (e.g., NRM Profiles, Assurance & Evidence Packs) can be relied upon,
     * What governance and assurance mechanisms sit behind those outputs.
5. **Support research, education, and continuous improvement**
   * Provide academics, method developers, and the Nexus **Risk Academy** with:
     * A common conceptual and technical baseline for curriculum, research programmes, and evaluation,
     * Clear interfaces where new models, ontologies, and methods can be incorporated into NRM under agreed safeguards.

In simple terms, this document is the **NRM “constitution and operating manual”**: it is both the canonical definition of Nexus Risk Management and the specification implementers must follow.

***

#### 1.2 Intended Audiences

NRM is inherently cross-disciplinary. This document is therefore written for several expert communities, each of which will use it differently.

**(a) Public authorities and regulators**

* **Who:**\
  Central banks, prudential and securities regulators, insurance supervisors, financial stability boards; ministries of finance, climate, environment, health, interior, infrastructure; disaster risk management and civil protection agencies.
* **Why:**\
  To understand how NRM can:
  * Enhance supervisory stress testing and systemic risk oversight,
  * Support sovereign and sub-sovereign risk financing and resilience planning,
  * Provide a **trusted evidence rail** that can be referenced in regulations, frameworks, and public programmes.
* **How:**\
  By drawing on Parts II, IV, V, VI and relevant annexes for concrete adoption patterns.

**(b) CROs, ERM leaders, and corporate strategists**

* **Who:**\
  Chief Risk Officers, Chief Strategy Officers, heads of ERM, treasury, sustainability, and resilience functions in banks, insurers, asset managers, corporates, and critical infrastructure operators.
* **Why:**\
  To:
  * Map existing ERM frameworks, models, and data into the NRM architecture,
  * Understand the **incremental path** from “ERM-only” to “ERM + NRM on Nexus Rail”,
  * Participate in NRM-based scenarios, facilities, and industry alliances.
* **How:**\
  By using this document as:
  * A **technical integration guide** (for risk & data teams),
  * A **governance reference** (for committees and board discussions),
  * A **business case** (for investment in NRM participation).

**(c) DFIs, multilaterals, and international organisations**

* **Who:**\
  Multilateral development banks, climate funds, UN agencies, regional development banks, international organisations involved in DRR, climate, health, cyber, and infrastructure resilience.
* **Why:**\
  To:
  * Treat NRM as a **global public-good rail** for risk intelligence and financing,
  * Align NRM with agendas like the Sendai Framework, Paris Agreement, SDGs, One Health, and digital public goods initiatives,
  * Co-develop NRM-based sovereign and regional risk finance and resilience programmes.
* **How:**\
  By referencing this document in programme design, financing frameworks, and technical assistance.

**(d) Engineers, infrastructure operators, and technical practitioners**

* **Who:**\
  Operators and engineers in energy, water, transport, logistics, health, telecoms, cyber, and industrial systems.
* **Why:**\
  To:
  * See how their existing risk, reliability, and operational data can be represented in NRM,
  * Engage in cross-sector, multi-hazard NRM scenarios that connect engineering reality to finance and policy,
  * Understand the guardrails for sharing sensitive operational data via the Nexus Rail.
* **How:**\
  By using the technical architecture and operating model sections as a **translation layer** from engineering risk to systemic NRM.

**(e) Academics, researchers, and AI/model developers**

* **Who:**\
  Scholars in risk science, Earth system science, complexity theory, AI/ML, macro-finance, institutional economics, law, Indigenous studies, STS, and public policy; model developers and data scientists.
* **Why:**\
  To:
  * Treat NRM as a **live infrastructure for applied research**, not just a conceptual model,
  * Contribute models, ontologies, and evaluation methods that can be adopted across RNCs and NCCs,
  * Understand how scholarly outputs can become **NRM building blocks** (e.g., NRM Profiles, AEPs) with formal governance.
* **How:**\
  By leveraging NRM as a bridging framework between disciplinary advances and real-world deployments.

**(f) Communities, Indigenous nations, and civil society**

* **Who:**\
  Community organisations, Indigenous governance bodies, NGOs, citizen science initiatives, and local practitioners.
* **Why:**\
  To:
  * Understand what NRM is and is not allowed to do with community and Indigenous knowledge,
  * Identify formal points of **participation, consent, co-authorship, refusal, and grievance**,
  * Shape NRM design so that it reflects lived experience, justice concerns, and place-based intelligence.
* **How:**\
  By focusing on the epistemic and governance sections, and using them as a basis for negotiation and oversight.

***

#### 1.3 Relationship to Nexus Ecosystem Charter and Related Instruments

The **Nexus Ecosystem Charter** is the overarching governance and architectural baseline for all Nexus activities. It specifies, among other things:

* The **dual-stack design**:
  * A **public-interest stack** (GCRI, GRF, NSF, GRA, etc.) that sets standards, protocols, and governance, and
  * A **for-profit delivery stack** (licensed entities and consortia) that builds and operates infrastructure and services on top.
* The roles and responsibilities of **core institutions**:
  * GCRI as science/methods/innovation authority,
  * GRF as governance/standards/assurance authority,
  * GRA as market/capital/implementation alliance,
  * NSF as protocol authority and ledger steward.
* Principles and mechanisms of:
  * Data sovereignty and compute-to-data,
  * Dual logging (Council Register + Nexus Ledger) for actions with legal and protocol effect,
  * Multi-regional Nexus Consortia as implementing arms,
  * MSO (Mandatory Support Obligation) and Treasury Grid.

Within that hierarchy, this **NRM document** is:

* A **specialised annex and reference specification** for the **risk management domain** of Nexus:
  * It operationalises the Charter in the specific context of risk intelligence, risk financing, and resilience.
  * It defines how the Charter’s general principles (e.g., sovereignty, equity, open standards, anti-capture) are concretely enforced for NRM.
* A **bridge** between:
  * The general governance and protocol rules in the Charter, and
  * Domain-specific technical specifications (e.g., Nexus SDKs, ontology schemas, Risk Academy curricula, RNC and NCC charters).

In case of conflict:

* The **Nexus Ecosystem Charter prevails** for governance, roles, and protocol principles.
* This NRM document must be updated (via the change control mechanisms described in §3.2) to restore alignment.

Other key documents this text is intended to interact with include:

* **Nexus Global Consortium Charter** and regional/national consortia charters (for deployment and governance),
* **Nexus SDK and technical specifications** (for implementation),
* **Risk Academy frameworks and curricula** (for capability-building),
* **NSF protocol rules and licenses** (for conformance, MSO, and ledger integration).

***

#### 1.4 How to Read and Use This Document

This document is structured to function both as a **policy/strategy narrative** and as a **technical/guidance reference**.

**Reading paths by role**

* **If you are a policy-maker or regulator:**
  * Start with §2 (Executive Summary), then §9–12 (Definition and Scope), §20–25 (Governance and Authority), and §36–40 (Adoption and Roadmap).
  * Use annexes (e.g., mappings to Basel, Sendai, IPCC, NIST) when designing regulatory or policy references to NRM.
* **If you are an ERM leader or CRO:**
  * Start with §2 (Executive Summary), then §9–11 (NRM conceptual model), §13–19 (Nexus Rail and UNOSINT), and §26–31 (Operating Model).
  * Treat the annexes on integration patterns as templates for ERM→NRM extension.
* **If you are in GCRI, NCCs, or technical teams:**
  * Focus on §13–19 (architecture), §26–31 (processes), and the formal specifications annexes.
  * This is your primary **design and implementation manual**.
* **If you are in GRF, GRA, or consortia governance:**
  * Emphasise §20–25 (governance/authority), §32–35 (economic/value architecture), and §36–40 (roadmap).
* **If you represent communities or Indigenous nations:**
  * Focus on §7 (epistemic foundations), §24 (community and Indigenous governance), and §41–44 (evaluation and transparency).
  * These sections describe how NRM recognises your rights and how you can exercise oversight.

**Normative vs descriptive content**

* Clauses using **“shall”, “must”, “may not”** are intended as **normative requirements** for NRM-conformant implementations, institutions, or programmes.
* Clauses using **“should”, “may”, “can”** are **recommended practices** or options.
* Explanatory sections provide rationale; they become binding only if explicitly referenced from normative clauses.

**Use as a reference**

* When designing policies, contracts, or technical architectures that rely on NRM, stakeholders should:
  * Cite the relevant **NRM version** (see §3.2),
  * Reference specific sections and annexes (e.g., “NRM v1.0, §12.3, Annex C”),
  * Treat this document as the **canonical source** for NRM definitions and obligations, subject to any jurisdiction-specific legal adaptations.

***

### 2. Executive Summary

#### 2.1 The Case for Nexus Risk Management (NRM)

The global risk landscape has changed in three decisive ways:

1. **Risks are deeply networked and multi-domain.**\
   Climate change, ecosystem degradation, pandemics, cyber incidents, financial instability, supply chain disruptions, and social unrest are no longer isolated episodes. They emerge from highly coupled **socio-technical-ecological systems**, with feedback loops, thresholds, and cascading failures.
2. **Critical risk intelligence is external to individual enterprises.**\
   Earth system models, satellite and sensor networks, epidemiological surveillance, cyber telemetry, infrastructure data, and local community and Indigenous knowledge all sit **outside** the traditional ERM perimeter. Yet they materially determine an enterprise’s risk.
3. **AI has become structural.**\
   Machine learning and AI are now used to make or influence decisions across finance, logistics, health, infrastructure, and information systems—often with opaque logic and emergent behaviour. They are simultaneously **tools for managing risk** and **sources of new systemic risk**.

**Enterprise Risk Management (ERM)** remains indispensable for ordering risk inside firms. But by design it:

* Focuses on the firm-level balance sheet and P\&L,
* Treats most systemic risk as exogenous “scenario input,”
* Relies on fragmented, proprietary data and models for external signals,
* Has limited visibility or authority beyond organisational boundaries.

This gap has consequences:

* Public authorities confront **misaligned, incomparable risk assessments** from different sectors and firms.
* Financial institutions cannot easily align portfolios with **systemic resilience and transition pathways**, even when they want to.
* Communities and Indigenous nations often **see the risks first**, but have little structural influence on how those risks are defined, priced, and financed.

**Nexus Risk Management (NRM)** is proposed as a remedy: a **federated risk architecture** that:

* Builds on ERM and existing standards,
* Integrates **human, machine, and nature intelligence**, and
* Treats risk management as a form of **shared digital and institutional infrastructure**, not just a firm-specific function.

***

#### 2.2 From ERM to NRM: High-Level Upgrade

The relationship between ERM and NRM is intentionally **complementary**:

* ERM is **internal**: how an enterprise identifies, assesses, and manages risk within its own governance and regulatory perimeter.
* NRM is **external and systemic**: how those internal views are:
  * Connected to external systemic risk intelligence,
  * Harmonised across actors and sectors, and
  * Translated into shared scenarios, policies, and capital flows.

Key aspects of the upgrade:

1. **Perimeter expansion**
   * From risk *to* the firm → risk **to and from** ecosystems, infrastructures, communities, and the financial system.
   * From siloed sectoral views → **cross-domain and cross-actor** views on a shared rail.
2. **Intelligence expansion**
   * From internal models + vendor views → **human–machine–nature intelligence**:
     * Internal ERM models,
     * AI-based scoring and simulations,
     * Earth system and ecological indicators,
     * Community and Indigenous knowledge.
3. **Action expansion**
   * From reporting and planning → **money-in-motion and policy**:
     * NRM outputs drive risk finance facilities, resilience investments, and regulatory interventions,
     * ERM outputs become input to NRM Profiles that are recognised by supervisors, DFIs, and programme designers.
4. **Governance expansion**
   * From firm-level committees → **multi-level consortia and councils**:
     * Regional Nexus Consortia (RNCs) and NCCs,
     * Community and Indigenous councils with defined powers,
     * Global and regional bodies under GRF and GCRI.

NRM is not a wholesale replacement. It is a **rail and operating system** that ERM plugs into, allowing existing risk practice to function in a systemic, AI-rich, climate-constrained world.

***

#### 2.3 Core Components: Nexus Rail, UNOSINT, GCRI, GRF, GRA

NRM rests on five interconnected components:

**(a) Nexus Rail – Semantic and Data Backbone**

* A **federated, standards-based infrastructure** for sharing and relating risk-relevant information, comprising:
  * Core and domain-specific **risk ontologies**,
  * A **federated risk graph** that connects sovereign data nodes,
  * Shared **rulebook formats** for triggers, thresholds, and decision logic.

The Rail ensures that different actors—ministries, regulators, firms, utilities, communities—can see and query risk in a **consistent and explainable way** without centralising raw data.

**(b) UNOSINT – Universal Nexus Open Source Intelligence**

* An **open intelligence stack** that:
  * Ingests and fuses multi-source data (OSINT, EO/GIS, climate, health, cyber, infrastructure, financial, community, Indigenous),
  * Produces **Assurance & Evidence Packs (AEPs)** with:
    * Data, models, assumptions, uncertainties, ethics/justice notes, and provenance,
  * Embeds **co-authorship**: scientists, local and Indigenous knowledge holders, and AI systems all leave signatures and metadata.

UNOSINT provides the **evidence layer** for NRM Profiles, supervisory analysis, and scenario work.

**(c) GCRI – Global Centre for Risk & Innovation**

* The **technical and scientific authority** behind NRM:
  * Designs and stewards Nexus Rail, ontologies, AEP formats, scoring engines, and simulation methods,
  * Runs research programmes on complex systems, AI risk, and justice-by-design,
  * Anchors the **Risk Academy** and Nexus Competence Cells (NCCs), which train practitioners and operate national/sectoral implementations.

GCRI ensures NRM is technically rigorous, methodologically transparent, and continuously updated.

**(d) GRF – Global Risks Forum**

* The **governance and consortia authority**:
  * Charters and oversees Regional Nexus Consortia and thematic/national consortia implementing NRM,
  * Sets NRM conformance standards, profiles, and evidence quality levels,
  * Provides policy and constitutional forums where states, regions, communities, and Indigenous nations co-govern how NRM is used,
  * Hosts grievance, appeal, and meta-governance processes.

GRF ensures NRM is equitable, legitimate, and resistant to capture.

**(e) GRA – Global Risks Alliance**

* The **capital and industry authority**:
  * Convenes financial institutions, corporates, utilities, and infrastructure operators,
  * Translates NRM outputs into **risk transfer, risk-sharing, and resilience products**:
    * Parametric covers, resilience bonds, contingent lines, credit enhancements, etc.,
  * Ensures that commercial applications respect public-interest rules and NRM conformance.

GRA makes NRM economically meaningful by connecting it directly to **capital allocation and risk financing**.

***

#### 2.4 Key Claims, Boundaries, and Non-Goals

To avoid misinterpretation, NRM is explicitly characterised by what it **does** and **does not** claim.

**Key claims**

1. **Integration, not replacement**
   * NRM is an **integration rail** across existing standards and practices (Basel, COSO, ISO 31000, Sendai, IPCC, NIST, etc.). It offers:
     * Common semantics,
     * Shared evidence structures,
     * Governance and capital linkages.
2. **Human–machine–nature intelligence by design**
   * NRM treats:
     * Human and institutional expertise,
     * AI and simulation models,
     * Earth system and ecological signals,\
       as co-equal, governed sources of intelligence, rather than privileging a single model or discipline.
3. **Governed, open, digital public-good core**
   * The core of NRM (ontologies, formats, baseline models, conformance rules) is:
     * Openly specified,
     * Governed as a public-interest asset,
     * Deployed via federated, sovereign nodes, not a single central platform.
4. **Actionability through finance and policy**
   * NRM is explicitly designed to **drive decisions**:
     * Supervisory and policy decisions (e.g., stress tests, contingency planning),
     * Capital allocation (e.g., facilities, bonds, reinsurance),
     * Operational decisions (e.g., investments in resilience, adaptation, and preparedness).
5. **Reflexive and self-critical**
   * NRM includes mechanisms to:
     * Monitor its own systemic impact,
     * Recognise procyclicality, concentration, or bias,
     * Roll back or simplify designs if they prove harmful or unstable.

**Boundaries and non-goals**

1. **NRM does not claim legal authority on its own.**
   * It becomes binding only when:
     * Adopted via laws, regulations, or contracts, or
     * Used as a condition of membership in Nexus consortia or facilities.
2. **NRM does not prescribe policy choices or risk appetites.**
   * It provides structured evidence, scenarios, and options;
   * Policy choices, distributional decisions, and risk tolerances remain the responsibility of **legitimate decision-makers**.
3. **NRM does not enforce a single worldview or ontology.**
   * It supports plural ontologies, contested knowledge, and the right of communities and Indigenous nations to:
     * Withhold data or knowledge,
     * Challenge models and assumptions,
     * Design and govern their own NRM interfaces.
4. **NRM does not eliminate uncertainty or value conflict.**
   * It offers a **better-organised, more transparent way** to navigate deep uncertainty and conflicting values; it does not pretend to make risk objective or politics disappear.

***

### 3. Document Status and Authority

#### 3.1 Legal and Normative Status (Standard, Reference Spec, Charter Annex)

This document has a **tripartite status**:

1. **Nexus internal standard**
   * Within the Nexus Ecosystem, this document operates as the **binding standard** for:
     * Use of the term “Nexus Risk Management” or “NRM-conformant”,
     * Design of NRM-related tooling, programmes, and consortia.
   * Nexus-aligned institutions (GCRI, GRF, GRA, NSF, RNCs, NCCs) **shall** conform to this document, subject to updates.
2. **External reference specification**
   * For regulators, governments, DFIs, firms, and vendors, this document is a **reference specification** that can be:
     * Incorporated by reference into regulations, guidance, facility term sheets, or procurement,
     * Used as a due-diligence benchmark when evaluating tools or programmes claiming to use “Nexus Risk Management”.
3. **Charter annex and elaboration**
   * Normatively, this text is an **annex to the Nexus Ecosystem Charter** for the risk domain.
   * It **does not override** the Charter; instead, it:
     * Interprets the Charter’s principles and roles for risk management,
     * Provides an actionable framework for applying those principles in technical and institutional designs.

It is important to stress:

* This document alone **does not create enforceable legal obligations** in any jurisdiction.
* Legal effect arises when:
  * States or regulators explicitly adopt or reference NRM (wholly or partly), or
  * Parties contractually bind themselves to NRM conformance (e.g., in facility agreements, membership contracts, or licensing terms).

***

#### 3.2 Versioning and Change Control

NRM is intended to evolve. This requires:

* A versioning scheme that supports **stability for adopters** and **adaptation to new science, risk, and practice**, and
* A governance process for changes that preserves integrity, inclusiveness, and anti-capture safeguards.

**Versioning scheme**

* **Major versions (e.g., NRM v1.0, v2.0, …)**
  * Used when:
    * Core definitions or architecture change in ways that affect conformance, or
    * Significant new domains or governance mechanisms are incorporated.
  * May require:
    * Explicit migration plans,
    * Regulatory or contractual updates.
* **Minor versions (e.g., NRM v1.1, v1.2, …)**
  * Used for:
    * Clarifications and elaborations,
    * Additional non-breaking features or annexes.
  * Generally **backward-compatible** for conformant implementations of the same major version.

**Change control bodies and process**

* **NRM Change Control Board (NRM-CCB)**
  * Constituted under GRF, with representation from:
    * GCRI (technical/scientific),
    * GRF (governance/standards),
    * GRA (capital/industry),
    * Regional consortia (RNCs),
    * Community/Indigenous councils,
    * Independent experts (e.g., AI safety, Earth system science, law).
  * Responsibilities:
    * Review and approve proposed changes,
    * Ensure consistency with the Nexus Charter,
    * Assess systemic risk, equity, and feasibility impacts.
* **Proposal and consultation**
  * Change proposals can originate from:
    * GCRI, GRF, GRA, RNCs, NCCs, or external stakeholders.
  * Material changes **must**:
    * Undergo documented impact assessment,
    * Be published for stakeholder comment with a clear timeline,
    * Include draft migration or transition guidance.
* **Deprecation and sunset policies**
  * Deprecated elements are marked with:
    * A sunset date,
    * Recommended migration paths.
  * Once sunset, they **may not** be used in new NRM-conformant implementations; legacy use is treated per agreed transition rules.

Adopters should explicitly reference the **NRM major/minor version** in any legal or supervisory instruments that depend on this specification, and monitor change control communications from GRF and GCRI.

***

#### 3.3 Alignment with Existing Standards (Basel, COSO, ISO 31000, Sendai, IPCC, NIST, etc.)

NRM is designed to be a **standards aggregator and translator**, not a competitor. Its alignment posture is:

1. **Reuse before reinvent**
   * Where established standards exist, NRM:
     * Reuses their definitions and taxonomies where feasible,
     * Builds mapping layers (in the ontology and profile schemas),
     * Documents assumptions and any deviations.
2. **Explicit mappings**
   * Annexes provide crosswalks and reference mappings, for example:
     * **Financial risk:** Basel risk categories and stress testing taxonomies → NRM risk entities and scenarios,
     * **ERM frameworks:** COSO and ISO 31000 processes → NRM process and governance constructs,
     * **Disaster risk:** Sendai hazard and risk classes → NRM hazard and exposure ontologies,
     * **Climate and transition:** IPCC scenario families and metrics → NRM climate and transition profiles,
     * **Cyber and digital:** NIST CSF categories, subcategories, and informative references → NRM cyber risk and digital infrastructure models.
3. **Compatibility and complementarity**
   * NRM Profiles are designed so that:
     * A Basel-compliant stress test or ISO 31000 process can be expressed *within* an NRM scenario or AEP,
     * Existing national DRR strategies or climate plans can be linked to NRM evidence and capital architectures.
   * Where NRM introduces new dimensions (e.g., equity metrics, multi-system propagation logic), these are **additive** and clearly identified.
4. **Engagement with standard-setting bodies**
   * GRF and GCRI shall:
     * Seek structured engagement with bodies such as ISO, IEC, BIS/BCBS, IAIS, IOSCO, NIST, WMO, UNDRR, IPCC, WHO and others,
     * Explore opportunities for co-development, mutual recognition, or joint guidance on systemic risk and digital public-good infrastructure.
5. **Handling divergence**
   * If apparent divergence arises between NRM and a widely used standard:
     * The default assumption is that a mapping or interpretation needs refinement,
     * NRM-CCB shall investigate and, if necessary, adjust NRM or provide guidance on the relationship.
   * Only in cases where a standard is demonstrably incompatible with NRM’s **core normative commitments** (e.g., equity, data sovereignty, planetary boundaries) will NRM adopt a clearly documented, principled deviation.

In summary, stakeholders should view NRM as a **common semantic and governance layer** where existing risk frameworks can interoperate and be extended to systemic, cross-domain problems—without losing their own integrity and regulatory recognition.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-rail/nexus-based-risk-management-nrm/front-matter.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.