# Operations

#### 1. NRM End-to-End Process Framework

NRM is organised around a repeatable, auditable operating sequence that connects **signals → evidence → scenarios → decisions → capital → learning**.

**1.1 Operating Sequence: Sense → Evidence → Scenario → Decision → Capital → Learn**

1. **Sense**
   * Continuous sensing of hazards, stresses, and signals via:
     * UNOSINT data streams (EO/GIS, climate, health, cyber, infrastructure, financial, community),
     * ERM/enterprise data (exposures, incidents, performance),
     * Local and Indigenous observations.
   * Responsible: GCRI, NCCs, RNC observatories, participating institutions, communities.
2. **Evidence (AEP production)**
   * Transformation of raw signals into **Assurance & Evidence Packs (AEPs)**:
     * Data selection, validation, fusion,
     * Model runs and uncertainty characterisation,
     * Equity and justice annotations,
     * Co-authorship and provenance capture.
   * Responsible: NCCs, GCRI teams, approved AEP producers; Consulted: local practitioners, Indigenous knowledge holders.
3. **Scenario**
   * Construction of **NRM scenarios** based on one or more AEPs and NRM Profiles:
     * Definition of shocks, pathways, and time horizons,
     * Systemic propagation across sectors and scales,
     * Identification of risk, resilience, and equity metrics.
   * Responsible: GCRI/NCC scenario teams, regulators/ministries (for policy scenarios), CROs (for firm-level overlays); GRF ensures governance alignment.
4. **Decision**
   * Use of scenarios and AEPs to inform:
     * Policy and regulatory decisions,
     * Board and executive decisions,
     * Community and municipal decisions,
     * Triggering of pre-agreed actions and contingency measures.
   * Responsible: Boards, ministries, regulators, councils, community leaders; Informed: GRA, GRF, GCRI.
5. **Capital**
   * Translation of decisions and NRM Profiles into:
     * Risk transfer and risk-sharing mechanisms (facilities, covers, bonds),
     * Investment and budget allocations,
     * Conditional and parametric disbursements.
   * Responsible: GRA, treasuries, finance ministries, financial institutions; GRF oversees alignment with NRM standards.
6. **Learn**
   * Ex-post analysis:
     * Comparing realised events and outcomes to AEPs and scenarios,
     * Identifying model and ontology gaps,
     * Documenting institutional performance and equity impacts.
   * Responsible: GCRI and NCCs (technical learning), GRF (governance learning), GRA (market/product learning); outputs feed the Risk Academy.

This cycle is **continuous and overlapping**: new sensing and evidence production occur even as prior cycles are still in the “capital” or “learn” phase.

**1.2 RACI (Responsible, Accountable, Consulted, Informed) Across Actors**

A simplified RACI view for the end-to-end NRM cycle (varies by use case):

* **Sense & Evidence (AEPs)**
  * Responsible: NCCs, GCRI observatories, authorised AEP producers.
  * Accountable: GCRI (technical standards), GRF (EQL governance).
  * Consulted: Communities/Indigenous councils, sectoral experts, data stewards.
  * Informed: RNCs, regulators, CROs, GRA.
* **Scenario design & execution**
  * Responsible: GCRI/NCC scenario teams, sectoral working groups.
  * Accountable: GCRI for technical adequacy; GRF for procedural fairness and inclusion.
  * Consulted: Regulators, ministries, industry, communities & Indigenous representatives.
  * Informed: Boards, public agencies, GRA, RNC leadership.
* **Decision-making**
  * Responsible: Decision-maker in mandate (board, regulator, minister, council, community authority).
  * Accountable: Same decision-maker, under their legal and political frameworks.
  * Consulted: NRM governance bodies (GRF), technical stewards (GCRI/NCCs), GRA if linked to facilities.
  * Informed: Affected stakeholders, public (subject to constraints).
* **Capital and risk transfer**
  * Responsible: GRA and participating financial institutions.
  * Accountable: GRA and facility sponsors; regulators where relevant.
  * Consulted: Treasuries, ministries, communities, GRF/GCRI (for standards).
  * Informed: Participants, public (for public-interest programmes).
* **Learning & feedback**
  * Responsible: GCRI/NCCs (technical review), GRF (governance review), GRA (product review).
  * Accountable: Jointly GRF and GCRI for NRM-wide updates.
  * Consulted: All implementation partners, communities, oversight bodies.
  * Informed: All NRM participants, Risk Academy, standards bodies.

This RACI matrix is formalised within NRM Profiles and consortia charters for each major use case.

***

#### 2. Evidence Production and AEP Lifecycle

**2.1 Requesting and Scoping an NRM Evidence Pack**

An AEP is usually initiated by a **formal request** tied to an NRM Profile and decision use case. The requester may be:

* A ministry, regulator, or central bank,
* A consortium (e.g., RNC, GRA facility committee),
* A community or Indigenous council,
* A corporate/financial institution participating in NRM.

Steps:

1. **Trigger**
   * A policy question, risk assessment need, facility design, or upcoming decision is identified.
2. **Scoping**
   * The requester and an assigned NCC/GCRI team jointly:
     * Specify the NRM Profile(s) in scope,
     * Define the geographic, sectoral, and temporal coverage,
     * Clarify decision context and required Evidence Quality Level (EQL).
3. **Terms and consent**
   * Data-sharing agreements, community consent protocols, and sovereignty rules are clarified.
4. **Assignment**
   * An AEP “lead” (NCC, GCRI team, or approved producer) is designated.

The scoping phase ensures that **AEPs are purpose-built** and rights-respecting.

**2.2 Data Gathering, Modelling, and Co-Authoring**

Once scoped:

1. **Data gathering**
   * UNOSINT pipelines and local data sources are engaged,
   * Data mesh principles apply: domain teams publish and document relevant data products.
2. **Modelling**
   * Appropriate models are selected per the NRM Profile:
     * Hazard, impact, macro, systemic, equity models, etc.
   * Models are run and documented with:
     * Assumptions, parameter choices, calibration procedures.
3. **Co-authoring**
   * Communities, Indigenous knowledge holders, and local practitioners:
     * Contribute data, narratives, and interpretations where relevant,
     * Review preliminary outputs for contextual validity.
   * AI systems may assist in:
     * Pattern detection, scenario generation, summarisation,
     * With outputs subject to human review.
4. **Drafting**
   * A draft AEP consolidates:
     * Data, methods, results,
     * Uncertainty analysis,
     * Equity and justice commentary,
     * Co-authorship and provenance metadata.

The co-authoring step is crucial to **epistemic pluralism and trust**.

**2.3 Peer Review, Validation, and Publishing to the Rail**

Before being released:

1. **Peer review**
   * Independent experts (technical, domain, community, Indigenous) review:
     * Data quality, model appropriateness, interpretation,
     * Narrative clarity and limitations.
2. **Validation**
   * Checks against benchmarks (other models, historic events, external studies),
   * Sensitivity analyses and robustness assessments.
3. **Governance review**
   * For high-stakes (EQL4–5) AEPs:
     * GRF or designated panels review process compliance,
     * Community and Indigenous governance bodies confirm consent where applicable.
4. **Publishing to the Rail**
   * Once approved, the AEP is:
     * Assigned an ID, version, and EQL rating,
     * Published as a linked set of artifacts (data, narrative, models) on the Nexus Rail,
     * Registered in relevant catalogues and registries (GRF & GCRI).

AEPs then become discoverable and reusable across NRM scenarios and profiles.

**2.4 Versioning and Retirement of AEPs**

AEPs have explicit lifecycles:

* **Versioning**
  * New evidence, methods, or errors trigger new versions:
    * `AEP-XXX v1.1`, `v2.0`, etc.
  * Change notes explain differences and implications.
* **Validity windows**
  * Some AEPs are:
    * Time-bound (e.g., seasonal risk assessments),
    * Event-bound (e.g., pre-event vs post-event packs).
* **Retirement**
  * When AEPs are no longer suitable:
    * They are marked as deprecated,
    * Sunset dates are defined,
    * Successor AEPs are referenced.

Systems using AEPs must check for **current validity** and handle deprecation appropriately.

***

#### 3. NRM Scenario Design and Execution

**3.1 NRM Scenario Typology (Strategic, Tactical, Stress, Crisis)**

NRM distinguishes four broad scenario types:

1. **Strategic scenarios**
   * Time horizon: 10–30+ years.
   * Purpose: long-term planning, investment strategy, adaptation pathways.
   * Features: integration of Earth system and socio-economic trajectories, intergenerational impacts.
2. **Tactical scenarios**
   * Time horizon: 1–5 years.
   * Purpose: medium-term policy and portfolio planning, programme design.
   * Features: specific policy options, programme rollouts, early warning linkages.
3. **Stress scenarios**
   * Time horizon: months to a few years.
   * Purpose: stress-testing financial systems, firms, infrastructure, and budgets.
   * Features: adverse but plausible shocks, multi-hazard combinations.
4. **Crisis scenarios (real-time)**
   * Time horizon: hours to weeks.
   * Purpose: incident management, emergency response, rapid financing triggers.
   * Features: near-real-time updates, operational decision support, escalation paths.

Each NRM Profile specifies which scenario types it supports and any special requirements.

**3.2 Multi-Party Scenario Composition Across Sectors and Scales**

NRM scenarios are **multi-party** by default:

* **Composition**
  * Scenarios draw on AEPs from multiple domains:
    * E.g., climate AEP + power grid AEP + health system AEP + macro-fiscal AEP.
  * Sectoral and geographic modules can be recombined, ensuring flexibility.
* **Cross-scale integration**
  * Global/planetary assumptions (e.g., warming levels) inform regional and local dynamics,
  * Local AEPs feed back into regional and global assessments (e.g., for loss & damage discussions).
* **Collaborative design**
  * Scenario design is conducted via:
    * Cross-sector workshops,
    * Digital collaboration tools on the Rail,
    * Structured consultation with communities and Indigenous institutions.

This yields scenarios that reflect **real interdependencies**, not isolated sector views.

**3.3 Integration with ERM, Supervisory, and Policy Processes**

NRM scenarios are not parallel exercises; they are integrated into:

* **ERM processes**
  * CROs and ERM teams:
    * Map NRM scenarios into firm-specific exposures and metrics,
    * Use them in risk appetite setting, capital planning, and board reporting.
* **Supervisory processes**
  * Supervisors:
    * Use NRM scenarios as common baselines for cross-firm stress tests,
    * Compare firm responses with systemic perspectives.
* **Policy processes**
  * Ministries and agencies:
    * Use NRM scenarios in budget planning, adaptation and DRR strategies,
    * Test regulatory and fiscal measures against plausible futures.

This integration is facilitated through **standardised scenario descriptors, APIs, and reporting formats** defined in NRM Profiles.

***

#### 4. Decision and Policy Support Workflows

**4.1 Decision Use-Cases (Board, Regulator, Ministry, Municipality, Community)**

NRM supports distinct decision contexts:

* **Board-level decisions (corporate, financial)**
  * Use: strategic risk reviews, major investments, capital allocation, risk appetite.
  * Workflow: ERM team curates relevant AEPs and NRM scenarios → board seminars and deliberation → documented decisions referencing NRM evidence.
* **Regulatory decisions**
  * Use: capital requirements, systemic risk buffers, supervisory expectations, macroprudential tools.
  * Workflow: supervisory analysis using NRM scenarios and AEPs → consultation and impact assessment → rulemaking or supervisory guidance.
* **Ministry and treasury decisions**
  * Use: budget allocation, facility design, contingency planning, adaptation and infrastructure programmes.
  * Workflow: NRM-based fiscal and macro-fiscal analyses → cabinet or parliamentary debate → programme adoption or adjustment.
* **Municipal and local decisions**
  * Use: land-use planning, zoning, local infrastructure investments, emergency preparedness.
  * Workflow: localised NRM views (via NCCs, RNCs) → deliberation in councils and public forums → adoption of local measures.
* **Community and Indigenous governance decisions**
  * Use: risk management at community level, consent and participation in larger programmes, stewardship of lands and waters.
  * Workflow: participatory modelling and dialogue → local decision processes (e.g., councils, elders) → formal positions that feed back into NRM Profiles and policies.

In each case, the **decision-maker remains accountable** within their legal and political framework; NRM is a structured support system.

**4.2 Evidence Interpretation and Deliberation Protocols**

NRM encourages structured evidence use:

* **Evidence briefings**
  * Clear, multi-layered presentations of AEPs and scenarios:
    * Executive summaries,
    * Technical appendices,
    * Equity and justice sections.
* **Deliberation protocols**
  * Steps include:
    * Clarifying the decision question,
    * Reviewing central and alternative scenarios,
    * Exploring distributional consequences,
    * Documenting dissenting views and uncertainties.
* **Use of decision tools**
  * Multi-criteria analysis, robust decision-making frameworks, and other tools help avoid overreliance on single point estimates.

These protocols are codified in NRM guidance and training programmes (Risk Academy).

**4.3 Documentation and Audit of Decisions Involving NRM**

For decisions that explicitly rely on NRM:

* **Documentation**
  * Decisions should:
    * Reference specific AEPs, NRM Profiles, and scenarios,
    * Record key assumptions and trade-offs,
    * Note which stakeholders were consulted and how.
* **Audit**
  * Internal and external audits may:
    * Review whether relevant NRM evidence was considered,
    * Assess consistency with NRM standards and governance procedures,
    * Evaluate outcomes ex post.
* **Dual logging (where high-stakes)**
  * Particularly consequential decisions (e.g., major facility triggers, systemic regulatory moves) may be:
    * Logged in the GRF Council Register,
    * Imprinted in Nexus Ledger entries for protocol-level traceability.

This institutionalises **accountability and learning** around NRM-informed decisions.

***

#### 5. Capital and Risk Transfer Workflows

**5.1 Linking NRM Profiles to Capital Instruments (via GRA)**

GRA coordinates the translation of NRM Profiles into **risk finance and resilience instruments**:

* **Design phase**
  * Selection of relevant NRM Profiles (e.g., NRM-Climate-Finance-Sovereign, NRM-Cyber-Infrastructure).
  * Definition of:
    * Covered perils and events,
    * Trigger conditions and indicators,
    * Eligible beneficiaries and uses of proceeds.
* **Documentation**
  * Term sheets and contracts explicitly reference:
    * NRM Profiles and AEP requirements,
    * EQL and CL thresholds,
    * Governance and review processes.
* **Alignment with regulatory and investor expectations**
  * Instruments are designed to satisfy:
    * Prudential regulation,
    * Investor disclosure and transparency norms,
    * Public-interest objectives.

NRM thus becomes the **reference framework** for sophisticated, systemic risk finance.

**5.2 Triggering and Payout Logic Based on NRM Evidence**

For parametric and contingency instruments:

* **Trigger mechanisms**
  * Are defined in terms of:
    * Observable indices and thresholds (e.g., hazard intensity, service disruption levels, composite stress indicators),
    * Derived from AEPs and NRM Profiles.
* **Evidence workflow**
  * Upon a potential triggering event:
    * NRM evidence is (re)generated or updated (AEPs),
    * Pre-agreed rules verify trigger conditions,
    * An independent or multi-party validation procedure (as per profile) confirms or contests the trigger.
* **Payout and decision linkage**
  * Once triggers are confirmed:
    * Payouts, disbursements, or facility activations follow the contract,
    * Pre-negotiated playbooks guide the use of funds.

This approach combines **speed and predictability** with **transparency and fairness**.

**5.3 Servicing, Monitoring, and Renewal of NRM-Linked Programmes**

Post-implementation, NRM-linked programmes require:

* **Ongoing monitoring**
  * AEPs and NRM indicators track risk evolution, portfolio performance, and equity impacts.
* **Servicing and adjustments**
  * Terms may be adjusted in light of:
    * New evidence or models,
    * Observed basis risk,
    * Changes in underlying exposures or policy frameworks.
* **Renewal or redesign**
  * At programme expiry or review points:
    * NRM evidence supports renegotiation,
    * Improved NRM Profiles inform better structured successors.

GRA, in coordination with GCRI, GRF, and programme sponsors, ensures these processes are governed and documented.

***

#### 6. Learning and Feedback Loops

**6.1 Post-Event and After-Action Reviews Using NRM Data**

After major events (hazards, system failures, crises):

* **Evidence comparison**
  * Observed data are compared to:
    * Pre-event AEPs,
    * Expected scenario outcomes,
    * Trigger and payout performance.
* **After-action reviews (AARs)**
  * Involve:
    * Technical teams (GCRI/NCCs),
    * Decision-makers (ministries, regulators, boards),
    * Communities and Indigenous representatives.
  * Focus on:
    * What worked, what failed,
    * Where NRM helped or hindered,
    * How decisions and actions unfolded relative to NRM guidance.
* **Documentation**
  * AARs are summarised and, where appropriate, published as NRM learning artifacts.

**6.2 Updating Ontologies, Models, Rulebooks, and Profiles**

Lessons learned feed back into NRM’s core:

* **Ontologies**
  * New concepts, entities, relationships, or indicators are added or refined.
* **Models**
  * Calibration parameters, structures, or even model families are adjusted.
* **Rulebooks and triggers**
  * Basis risk analyses and operational experience lead to:
    * Refinements of trigger conditions,
    * Adjustments in thresholds or composite indexes.
* **Profiles**
  * NRM Profiles are updated to:
    * Reflect improved science,
    * Encode better governance and equity provisions,
    * Adapt to shifting policy environments.

These updates follow **change control and governance procedures** (Part IV §3.2), ensuring stability with managed evolution.

**6.3 Feeding Lessons into Risk Academy Curricula and Professional Standards**

Finally, learning loops are institutionalised through the **Risk Academy** and professional communities:

* **Curricular updates**
  * Case studies from NRM deployments and events are integrated into:
    * Core course modules (“Risk in a Complex World”),
    * Specialised tracks (climate, cyber, finance, health, social, infrastructure),
    * Executive and practitioner education.
* **Professional standards**
  * Competency frameworks and certifications for NRM practitioners (analysts, model validators, chairs, programme designers) are updated to:
    * Reflect emerging best practices,
    * Address recurrent weaknesses.
* **Community of practice**
  * NRM practitioners share:
    * Good practices and failure analyses,
    * Tools and templates,
    * Research and innovation opportunities.

In this way, NRM is **not static**; it is a living system that learns from its own operation and from the world it seeks to help navigate.


---

# 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/operations.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.