# NXSR: Rails

### Part VI — NXSR & NXPCK: Rails and Packs

Within the Nexus Ecosystem, **Nexus Rails (NXSR)** and **Nexus Packs (NXPCK)** are the two principal deployment constructs through which Nexus Risk Management (NRM) becomes *operational reality* rather than abstract architecture.

* **NXSR — Nexus Rails** are long-lived, polycentrically governed deployments of the Nexus stack, defined for a specific **mission × geography × institutional perimeter** (for example, “East Africa climate & food security rail”, “EU cyber–critical infrastructure rail”, “US sovereign climate–macro rail”). Each rail encodes its own governance, data sovereignty, risk scope, capital architecture, and operating envelopes.
* **NXPCK — Nexus Packs** are reusable **domain modules** that encapsulate ontologies, data and ML pipelines, models, playbooks, dashboards, and governance templates for specific NRM use-cases (for example, “Coastal flood & infrastructure pack”, “Pandemic & health system stress pack”, “Systemic cyber–grid pack”). Packs can be deployed onto many rails, with local adaptation, without fragmenting standards.

If **NXSECO** is the overall socio-technical system and **NXSOS/NXSTUDIO/NXOBS** provide the runtime and intelligence fabric, then NXSR and NXPCK provide the **deployment grammar**:

* Rails answer: **Where? For whom? Under what rules and risk perimeter?**
* Packs answer: **For what risk problems? With which models, evidence, and operational patterns?**

Together, they enable incremental yet coherent rollout of NRM across countries, regions, sectors, and communities while maintaining global semantic, technical, and governance interoperability.

***

#### 6.1 NXSR — Nexus Rails

An individual **Nexus Rail** is a *governed instantiation* of the Nexus Ecosystem applied to a clearly delimited scope:

* **Geographical**: a sovereign state, regional bloc, river basin, coastal corridor, urban network, etc.
* **Thematic**: climate and multi-hazard DRR, bio/pandemic risk, cyber and digital risk, systemic financial risk, humanitarian crises, or integrated multi-risk portfolios.
* **Institutional**: a defined set of ministries, regulators, DFIs, critical infrastructure operators, financial institutions, municipalities, communities, and Indigenous nations participating under a shared governance arrangement.

Each rail represents a **full NRM loop** — Sense → Evidence → Scenario → Decision → Capital → Learn — implemented on top of:

* The **operating system and trust plane** (NXSOS).
* The **intelligence and data plane** (NXSTUDIO, NXOBS, NXCOMMS, NXN, NXNODE).
* The **standards and ontology core** (NXSS / GRIx / SDZ / DSLs).

Concretely, one can think of a rail as a combination of:

1. A **technical configuration** (what runs where, with which ontologies and models).
2. A **legal and policy shell** (which rules, lawful bases, and capital structures apply).
3. A **governance regime** (who decides what, with what quorums and accountability).

All of this is crystallised in its Rail Manifest.

***

**6.1.1 Rail Manifest (*****rail.yaml*****)**

Every rail MUST be defined by a **Rail Manifest**, canonically represented as `rail.yaml`. This manifest is simultaneously:

* A **machine-readable configuration artefact** used by NXSTUDIO, NXSOS, and DevOps/CI-CD pipelines; and
* A **normative reference** for GRF, GCRI, GRA, RNCs, NCCs, and for Clause Commons / Legal Shell instruments (MoUs, facility agreements, policy decisions).

At a minimum, `rail.yaml` SHALL specify:

1. **Identity and scope**
   * Rail identifier and human-readable name.
   * Geographical scope (countries, regions, basins, corridors, city networks).
   * Thematic scope (for example, “multi-hazard DRR and climate adaptation”, “systemic financial–climate risk”, “national health system crisis rail”).
   * Primary host(s): RNC operator plus designated sovereign/institutional sponsors (e.g., ministries, regulators, DFIs).
2. **Governance profiles**
   * The applicable **GRF-IP profile(s)** (which standards, conformance, and assurance templates apply).
   * CL/EQL minima for key decision classes (for example, “AEPs used for sovereign risk transfer MUST be ≥EQL4; observatories generating those AEPs MUST be ≥CL3”).
   * NVM quorum templates and DAO configurations (see 6.1.2, 6.1.5), including constituency classes (government, finance, infrastructure, academia/NCCs, communities/Indigenous).
3. **SDZ and lawful-basis configuration**
   * SDZ classes and tiers active on the rail (e.g., SDZ-1 public, SDZ-2H health, SDZ-2F financial, SDZ-3 sensitive/defence).
   * Cross-border data governance rules (what can/cannot leave the jurisdiction and under what lawful basis).
   * Lawful-basis matrices for core data categories and INT modules (e.g., GEOINT, BIOINT, FININT), aligned with national/international regulatory frameworks.
4. **Technical topology and hosting**
   * Primary and secondary hosting regions and cloud/sovereign data centres.
   * Mapping of **observatories**, **NXSTUDIO instances**, and **NXNODE classes** to physical/virtual infrastructure.
   * Edge and RT deployments where relevant (e.g., RT Edge Plane for grid control, health monitoring, or flood early warning).
5. **Packs and NRM Profiles in force**
   * The set of NXPCKs activated on this rail, including versions and certification status.
   * The NRM Profiles implemented (e.g., NRM–Coastal–Urban–Infrastructure–CL3/EQL4; NRM–Pandemic–National–Health–CL2/EQL3).
   * Mapping from packs to institutional actors (who implements which parts).
6. **SLOs, safety envelopes, and performance metrics**
   * Operational SLOs:
     * Maximum allowed event → evidence → decision → cash latency for specific facilities.
     * Minimum data coverage and observatory uptime for critical indicators.
     * Required refresh frequency for key indices and AEPs.
   * Safety envelopes for AI, automation, and capital triggers, including:
     * Allowed safety tiers and HIL requirements.
     * Boundaries on model usage, scenario generalisation, and actuation.
   * Energy/carbon and resource footprint constraints where applicable (sustainability-by-design).
7. **DR/BC and degraded-mode policies**
   * DR/BC patterns consistent with NXSOS (4.4): primary/secondary failover, backup observatories, and NXMirror configurations.
   * Semantic degradation rules (permissible CL/EQL downgrades, what becomes advisory-only under partial failure).
   * Manual override protocols and required documentation when operating in “safe mode” or extraordinary conditions.

The `rail.yaml` manifest is versioned, cryptographically signed, anchored (e.g., via `nxproto.licence-registry` and `nxproto.aep-anchor`), and treated as a **governance artefact**. Modifications to `rail.yaml` are tracked as **events** and MAY require NVM quorum approval when they materially affect risk, rights, or capital.

***

**6.1.2 Rail DAOs & NVM Governance**

Each rail SHALL be accompanied by a **Rail DAO**, whose parameters are defined in `rail.yaml` and realised via `nxproto.dao-nvm-engine`. This DAO is the **institutional nerve centre** of the rail.

Key characteristics:

* **Constituency**\
  Rail DAOs MUST be **polycentric and multi-stakeholder**. At minimum, they SHOULD include verifiable representatives (with DIDs/VCs) from:
  * Sovereign/public authorities (e.g., Finance, Climate, Interior, Health, Energy, Telecoms, depending on rail scope).
  * Regulators and supervisors (financial sector, critical infrastructure, data protection, etc.).
  * Critical infrastructure and industry operators (utilities, grid operators, telcos, hospitals, logistics, key corporates).
  * Financial institutions and DFIs participating in NRM-linked capital programmes.
  * Academia and NCCs hosting observatories or competence centres.
  * Civil society, communities, and Indigenous nations, with explicit roles and veto/consent mechanisms where appropriate.
* **NVM-based quorum rules**\
  The **Nexus Validation Machine (NVM)** defines quorum rules for **classes of decisions**:
  * Routine technical decisions (e.g., parameter tuning within safety envelopes) MAY be delegated to NCC/RNC implementers under simple quorum.
  * Material changes to CL/EQL minima, adoption of new high-stakes packs, or binding of sovereign risk-transfer facilities MUST meet stronger NVM thresholds (e.g., 3-of-6 with required participation from sovereign, regulator, community, and independent science).
  * Cross-rail or systemic decisions (e.g., affecting multiple sovereigns or regional corridors) MAY be escalated to NXHIVE-level DAOs.
* **Decision types and logging**\
  Rail DAOs are responsible for:

  * Approving NRM Profiles to be operationalised on the rail.
  * Authorising the use of specific AEP classes and observatories for capital and policy decisions.
  * Modifying safety envelopes, SDZ rules, or lawful-basis matrices in response to evolving risk, law, or ethics.
  * Admitting, suspending, or expelling rail participants at CL3–4.
  * Declaring and lifting emergency modes (6.1.5).

  All decisions are recorded as **episodes** with full evidence references, enabling ex post evaluation, audit, and learning.

Rail DAOs thereby ensure that NRM implementation is *governed by explicit, contestable, and documented multi-party choices*, not by opaque technical configurations.

***

**6.1.3 Rail-Local Catalogs (AEPs, Indices, Decision Logs, Profiles)**

Each rail maintains a suite of **rail-local catalogs**, which together constitute the **canonical record of epistemic and operational activity** on that rail:

1. **AEP Catalog**
   * Index of all Assurance & Evidence Packs that have been produced or used under the rail’s governance.
   * For each AEP:
     * EQL level and date of certification.
     * Producing observatory (with CL and domain).
     * Validity intervals, domain of applicability, and known limitations.
     * Deprecation and retraction status, with reasons and affected decisions.
2. **Index Catalog**
   * Registry of all **indices** (risk, resilience, systemic stress, equity/justice) used in the rail’s operational logic.
   * For each index:
     * Formal GRIx definition and parameters.
     * Model lineage and calibration protocol.
     * Applicable NRM Profiles and contexts (e.g., urban floods, sovereign stress tests).
3. **Decision Log Catalog**
   * Structured record of decisions where NRM evidence materially influenced outcomes, including:
     * Governance decisions (Rail DAO and NVM outcomes).
     * Capital trigger decisions (payouts, credit line activations/stand-downs, contingency windows).
     * Policy and regulatory decisions (budget allocations, resilience investments, regulatory changes).
   * Each entry links to AEPs, indices, models, and deliberation records, enabling rigorous ex post analysis.
4. **Profile Catalog**
   * Registry of NRM Profiles in force on the rail (e.g., NRM–Drought–FoodSecurity–CL2/EQL3).
   * Status and versions of profiles, with their associated packs, institutions, and conformance levels.
   * Mapping to legal programmes and facilities (e.g., sovereign climate facility, multilateral guarantee, insurance pools).

These catalogs are accessible through NXSTUDIO/DSS for practitioners and through APIs for regulators, evaluators, and NXHIVE cross-rail analysis, enabling **regulatory reliance, scholarly replication, and systemic oversight**.

***

**6.1.4 Rail SLOs & Safety Envelopes**

Rails MUST define explicit **Service Level Objectives (SLOs)** and **safety envelopes**, encoded in `rail.yaml` and enforced at runtime via NXSOS and NXSTUDIO.

Typical SLO classes include:

* **Timeliness**
  * Maximum allowable latency between event detection and AEP availability for predefined event classes.
  * Maximum latency from evidence readiness to decision and capital movement for relevant programmes (e.g., “Parametric payout median ≤ 14 days; 90th percentile ≤ 30 days”).
* **Availability and coverage**
  * Minimum uptime for key observatory functions and indices.
  * Minimum spatial, temporal, and population coverage for data and models associated with CL3–4 decisions.
* **Quality and robustness**
  * Minimum EQL requirements for evidence used in specific decision classes (e.g., ministerial vs local operational decisions).
  * Maximum tolerated **basis-risk** metrics for indexed instruments and policies.
  * Thresholds for acceptable model uncertainty and drift.

**Safety envelopes** define **hard boundaries** within which NRM automation and AI must operate, including:

* Prohibitions or HIL requirements for autonomous actuation on critical infrastructure or safety-critical domains.
* Constraints on the use of certain models (e.g., dual-use bio models) to specified contexts and institutions.
* Rules forbidding capital triggers when confidence flags (e.g., severe data degradation, contested models) exceed thresholds.

These SLOs and safety envelopes create a formal link between **technical performance**, **epistemic quality**, and **public-interest mandates**, and are integral to evaluation (Part VIII).

***

**6.1.5 Rail-Level NVM Quorums, Escalation Paths, Emergency Modes**

Rail governance MUST explicitly codify **quorums, escalation paths, and emergency modes** for NRM operations.

1. **Rail-level NVM quorums**

   * Actions are stratified into classes (routine, material, systemic, constitutional).
   * For each class, NVM defines:
     * Required quorum size and diversity of signers (e.g., government, finance, infrastructure, community, independent science, external assurance).
     * Whether remote or time-bounded signoff is acceptable (e.g., crisis response vs long-term profile changes).

   Examples:

   * Parameter tweaks or non-binding dashboards MAY be authorised by technical owners alone within pre-agreed bounds.
   * Adoption of a new hazard model that materially shifts triggers MUST satisfy a broad NVM quorum.
   * Suspension of a capital facility or change in payout priorities MAY require extended quorums and GRF or multilateral observers.
2. **Escalation paths**
   * Clear protocols for escalating:
     * Breaches or near-breaches of safety envelopes.
     * Conflicts between observatories or methodological disputes.
     * Community or Indigenous grievances regarding epistemic injustice or harm.
   * Escalation levels:
     * Local operational teams → NCC technical committees.
     * NCC → Rail DAO/NVM.
     * Rail DAO/NVM → GRF Council or NXHIVE (for cross-rail or systemic issues).
3. **Emergency modes**
   * Pre-defined operational states such as “heightened alert”, “crisis mode”, “fallback/safe mode”, each specifying:
     * Modified SLOs (e.g., temporarily accepting EQL3 instead of EQL4 for certain decisions under severe constraints).
     * Temporary rebalancing of decision rights (e.g., empowering emergency managers while strengthening ex post accountability).
     * Limitations on automation and capital movements to prevent over-reaction or harm.
   * Each emergency mode MUST have:
     * Explicit triggers and exit conditions.
     * Obligatory **post-event reviews** using NRM evidence to assess appropriateness, impacts, and needed protocol changes.

In sum, rail-level governance transforms NRM from an abstract methodology into a **living constitutional practice**, with explicit, auditable rules about how the system behaves in both routine and extreme conditions.

***

#### 6.2 NXPCK — Nexus Packs

Where rails provide the **infrastructure and governance envelope**, **Nexus Packs (NXPCK)** provide the **domain- and mission-specific content** through which NRM is applied to concrete problems. Packs are:

* **Composable**: multiple packs can be activated on a single rail.
* **Reusable**: a pack can be deployed across many rails with local parameterisation.
* **Governed artefacts**: subject to CL/EQL targets, certification, and safety templates.

They function as **installable NRM modules**: a pack “teaches” a rail how to reason about a particular risk domain, what to measure, how to act, and how to evaluate.

***

**6.2.1 Pack Manifest (*****pack.yaml*****)**

Each pack is defined by a **Pack Manifest**, `pack.yaml`, which is the authoritative specification of its content and constraints. It MUST include:

* **Identity and scope**
  * Pack ID, version, and human-readable name (e.g., `nrmpck.coastal-flood-infra.v1`).
  * Domain(s) (e.g., climate, hydrology, infrastructure, municipal finance).
  * Supported NRM Profiles and canonical use-cases (e.g., “coastal flood risk for port cities with critical logistics nodes”).
* **Dependencies and compatibility**
  * Minimum required versions of NXSS, NXSOS, NXSTUDIO, NXOBS components.
  * Required or optional GRIx extensions (e.g., specific hazard or infrastructure ontologies).
  * Compatible CL/EQL ranges and safety tiers (e.g., validated for CL2–3 deployments under EQL2–4).
  * Dependencies on other packs (e.g., generic climate hazard pack, generic sovereign fiscal stress pack).
* **Conformance and certification**
  * Applicable GRF-IP profile(s) and test suites.
  * Current certification status and expiry/renewal processes.
  * Known limitations, caveats, and conditions of use.

Pack manifests are versioned and anchored; significant changes to `pack.yaml` follow formal **NEP/RFC flows** and may require NVM/GRF signoff for high-stakes applications.

***

**6.2.2 Pack Ontologies & Domain Models (GRIx Extensions)**

Each pack extends the **semantic and modelling substrate** of NRM:

* **GRIx extensions**
  * New or refined entities, relationships, and attributes that reflect domain-specific knowledge, for example:
    * Coastal flood pack: levee segments, flood defence assets, critical road links, port terminals, shelter capacities.
    * Pandemic pack: health system tiers, ICU capacity, supply chains for key pharmaceuticals, contact networks.
  * Domain-specific attributes (e.g., defence standard, design return period, surge capacity, redundancy).
* **Domain models**
  * Hazard models (e.g., storm surge, rainfall-runoff, disease transmission).
  * Vulnerability and fragility models (e.g., asset damage curves, health susceptibility functions).
  * Impact models (e.g., economic losses, service disruption, health burden, knock-on effects).
* **Semantic constraints**
  * Encoded as GRIx and Policy DSL rules (e.g., conservation principles, physical bounds, institutional obligations).
  * Used for consistency checking, anomaly detection, and scenario sanity checking.

These semantic and model extensions allow the generic NRM architecture to **speak the language** of specific risk domains without sacrificing interoperability.

***

**6.2.3 Pack AAP/IRP Playbooks & Workflows**

Packs package **operational knowledge** in the form of:

* **Anticipatory Action Plans (AAPs)**
  * Pre-event interventions triggered by thresholds or forecasts (e.g., pre-positioning supplies, anticipatory cash transfers, infrastructure maintenance, “slow-moving crisis” measures).
  * Parameterised by domain indices such as drought severity, surge levels, or hospital load forecasts.
* **Incident Response Playbooks (IRPs)**
  * Time-critical crisis and immediate response sequences, for example:
    * Dynamic load shedding in power systems.
    * Evacuation, sheltering, and transport rerouting for coastal floods.
    * Surge protocols and triage for health systems under stress.

Each playbook is expressed in **Playbook DSL** and includes:

* Detailed event, precondition, and trigger definitions.
* HIL requirements and NVM checkpoints for critical steps.
* Explicit mapping to legal clauses, institutional mandates, and accountability (via Clause Commons).
* Safety analysis and limitations (e.g., where the playbook must *not* be used).

Executed via NXSTUDIO (AAP module, NEXCORE, NEXQ), these playbooks turn **NRM evidence into structured practice**, reducing reliance on ad hoc improvisation.

***

**6.2.4 Pack Dashboards, KPIs & Reporting Templates**

To ensure observability, usability, and comparability, packs include **reference UX components**:

* **Dashboards** (e.g., Power BI templates) for key roles:
  * CRO or risk office dashboard.
  * Supervisory/regulator dashboard.
  * Critical infrastructure operator dashboard.
  * Municipal or community-facing dashboard.
* **KPIs and metrics**:
  * Domain-specific performance and resilience indicators (e.g., days of service interruption avoided, population coverage of early warning, reduction in mortality/morbidity, avoided losses).
  * Equity metrics (distribution of risk, benefits, and support across communities and vulnerable groups).
* **Reporting templates**:
  * Structured layouts for board papers, ministerial briefs, supervisory submissions, and public communication.
  * Suggested narratives linking NRM evidence to decisions and outcomes, while preserving uncertainty and limitations.

These artefacts can be localised by RNCs/NCCs but provide a **standard baseline**, facilitating learning and benchmarking across rails.

***

**6.2.5 Pack Connectors, Pipelines & Reference ML Models**

Packs also include **reference implementation assets** to minimise time-to-deployment:

* **Connectors**
  * Definition of standard connectors to external data sources (e.g., specific satellite products, reanalysis datasets, global disease surveillance, financial or trade feeds).
  * SDZ-aware ingestion configs and sample data contracts.
* **Pipelines**
  * ETL/Data engineering pipelines aligned to GRIx and SDZ taxonomy, ready to run under NXSTUDIO OP and Data Fabric.
  * Built-in data quality checks and alerts tuned to domain specifics.
* **Reference ML/AI models**
  * Baseline hazard, impact, and risk models with:
    * Full training data provenance, documentation, and licensing.
    * Model cards, benchmarks, robustness tests, and fairness assessments.
    * Recommended “domains of application” and explicit warnings where extrapolation would be unsafe.

These assets are deployable through **ML Fabric** and can be adapted or replaced by more advanced models while preserving the pack’s interface contracts.

***

**6.2.6 Pack CL/EQL Targets & Governance Patterns**

Each pack must specify **target CL/EQL regimes** and **governance patterns** to ensure that it is used at appropriate levels of maturity and evidence quality:

* **CL/EQL targets**
  * For each major component (indices, AEP templates, playbooks, models), the pack SHOULD define:
    * Intended CL range (e.g., suitable for CL2 rails in pilot mode, CL3 rails under certain conditions).
    * Intended EQL levels (e.g., EQL3 early warning, EQL4 risk transfer, EQL5 research-grade synthesis).
* **Governance patterns**
  * Default patterns for:
    * Peer review and independent replication of models and AEPs.
    * Conflict-of-interest management in domain committees.
    * Community and Indigenous engagement where domain scope affects local livelihoods, rights, or knowledge systems.

These patterns are rendered as **GRF-IP compatible templates**, offering regulators, RNCs, and multilateral bodies a clear governance blueprint for pack adoption.

***

**6.2.7 Pack Safety Overlays & NVM Templates**

Finally, packs MUST define **safety overlays** and **NVM templates** that address domain-specific risks and ethics:

* **Safety overlays**
  * Additional constraints, above generic NXSS/NXSOS rules, addressing:
    * Automation: restricting or disallowing fully autonomous interventions in certain domains (e.g., biosecurity, health interventions, certain cyber actions).
    * Model usage: preventing dual-use or high-hazard models from being deployed in contexts where oversight is weak or incentives perverse.
    * Data flows: enforcing stronger privacy or de-identification rules for especially sensitive data (e.g., health, identity, political persecution risk).
* **NVM templates**
  * Domain-specific proposals for:
    * Composition of quorums (which expertises *must* be present for certain decisions).
    * Classes of decision requiring NVM sign-off (e.g., adoption of a new epidemic model that changes intervention thresholds).
    * Escalation protocols for epistemic or ethical disputes, including special pathways for community/Indigenous voices when their rights, land, or knowledge are implicated.

These overlays and templates ensure that NRM deployments are **not merely technically proficient**, but **aligned with domain-specific safety, ethical, and justice requirements**, and can be systematically audited and improved.

***

In combination, **Rails (NXSR)** and **Packs (NXPCK)** constitute the **deployment and composition layer of the Nexus Ecosystem**:

* Rails specify **where the NRM system lives, who participates, and under which constitutional and operational rules**.
* Packs specify **which risks are addressed, with what semantics, evidence, and operational pathways**.

This separation of concerns allows the Nexus Ecosystem to be **globally coherent yet locally responsive**, enabling Member States, regions, sectors, and communities to move from legacy ERM towards **Nexus Risk Management** in a controlled, evidence-based, and justice-aware manner.


---

# 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/technology/nxsr-rails.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.