# NXSS: Standards

### Part III — NXSS: Nexus Standards Stack

#### 3.1 Overview of NXSS as Normative & Semantic Core

The **Nexus Standards Stack (NXSS)** is the **authoritative reference layer** that turns the Nexus Ecosystem from “a collection of tools” into a **coherent, governed infrastructure**.

Where the Nexus Rail specifies *how* systems are built and run, NXSS specifies *what counts as correct, admissible, and legitimate*:

* It defines the **canonical semantics** of risk and resilience (GRIx and related schemas).
* It encodes **obligations and guardrails** for data, models, AI/agents, evidence, and automation.
* It provides the **testable baselines** (CL/EQL, SDZ, safety tiers, lawful-basis matrices) that RNCs, NCCs, vendors, and host institutions MUST respect to claim NRM-conformance.

NXSS is jointly stewarded by:

* **GCRI** — as scientific and technical authority: semantics, evidence methods, model and AEP standards.
* **GRF** — as standards and assurance authority: CL/EQL regimes, GRF-IP profiles, conformance, certification.
* **GRA** — as capital and industry authority: mapping of NRM Profiles and evidence standards into risk-financing and market practices.

NXSS is **implementation-agnostic** at the code level but **binding** at the behavioural level: any compliant stack (whether built on Fabric/OneLake or not) must be demonstrably compatible with NXSS.

***

#### 3.2 Core Semantic Engines & Schemas

**3.2.1 GRIx: Global Risk & Resilience Index / Ontology Engine**

**GRIx** is the **primary ontology engine and index framework** for the Nexus Ecosystem. It provides a unified semantic substrate for:

* **Risk entities** — e.g., *Hazard*, *ExposureUnit*, *VulnerabilityGroup*, *Asset*, *CriticalFunction*, *Institution*, *Instrument*, *Programme*, *Community*, *Ecosystem*.
* **Relations** — e.g., *exposedTo*, *dependsOn*, *controlledBy*, *insuredBy*, *financedBy*, *regulatedBy*, *supplies*, *suppliedBy*, *affectedBy*.
* **Indicators and indices** — e.g., hazard intensity, fragility curves, resilience scores, system stress indices, equity and justice metrics.

Formally, GRIx is defined as:

* A **modular ontology**:\
  \- Core ontology Ocore\mathcal{O}\_{core}Ocore​ (cross-domain concepts)\
  \- Domain ontologies Od\mathcal{O}\_{d}Od​ (e.g., climate, bio, cyber, finance, infrastructure, social)\
  \- Extension modules Oext\mathcal{O}\_{ext}Oext​ (local, Indigenous, programme-specific concepts)
* Implemented via:
  * **OWL / RDF** for formal reasoning and interoperability.
  * **JSON-LD / YAML schemas** for practical data binding and API-level use.
  * **Fabric IQ ontology items** for live, entity-centric modelling and graph views.

GRIx provides **canonical identifiers, units, and transformation rules** so that:

* A “substation” in an African power system and a “substation” in a North American grid can be analysed and compared.
* Equity, resilience, and basis-risk metrics are defined consistently across jurisdictions and programs.

**NRM Profile conformance requires** explicit mapping to relevant GRIx modules.

**3.2.2 Chronotope Schemas (Time–Space–Context Models)**

Risk is inherently **spatiotemporal and contextual**. Chronotope schemas formalise:

* **Temporal structures**:
  * Observational timelines (real-time telemetry vs retrospective data).
  * Scenario timelines (pre-shock, shock, recovery, adaptation).
  * Policy timelines (budget cycles, regulatory cycles, planning horizons).
* **Spatial structures**:
  * Physical coordinates and reference systems.
  * Jurisdictions (states, provinces, municipalities, Indigenous territories).
  * Functional regions (river basins, grid zones, health catchment areas).
* **Contextual lenses**:
  * Scenario identifiers (e.g., climate pathways, macro-financial regimes, regulatory environments).
  * Operational states (normal operations, alert, emergency, degraded).

Chronotope schemas guarantee that **every data point, index, and decision** is annotated with:

(time, space, context)(time,\\, space,\\, context)(time,space,context)

This enables:

* Explicit lead–lag analyses (e.g., early warning vs payout timing).
* Multi-scale aggregation and disaggregation (community → city → region → nation).
* Reproducible comparisons across events, programmes, and jurisdictions.

**3.2.3 Episode Schemas (Signals → Decisions → Actions → Outcomes)**

**Episode schemas** encode **full risk episodes** as structured, machine-readable objects:

* **Signal set**:
  * What was sensed (e.g., rainfall anomalies, cyber breach indicators, health surveillance signals).
  * Where and when; associated AEPs and EQL.
* **Decision set**:
  * Who decided (roles and institutions via NXIdentity).
  * Under which governance process (NVM quorum, ministerial authority, regulatory order).
  * Which NRM Profiles and evidence were invoked.
* **Action set**:
  * Capital moves (e.g., triggering parametric covers, unlocking contingency lines).
  * Operational actions (e.g., emergency routing, planned outages, public communication).
  * Playbooks and rules executed.
* **Outcome set**:
  * Measured impacts (losses avoided, losses incurred, distributional outcomes).
  * Residual risks and system changes (e.g., new vulnerabilities, structural adaptations).

Each episode is **hash-anchored** (via NXSOS `nxproto.aep-anchor` / episode anchor) and linked to GRIx entities and chronotope contexts. Episodes are the **atomic units** for:

* Audit and liability analysis.
* Learning and performance evaluation.
* Updating models, rulebooks, and curricula.

***

#### 3.3 Sovereign Data Zones (SDZ)

**3.3.1 SDZ Classes, Tiers, and Residency Rules**

**Sovereign Data Zones (SDZ)** encode formal **data sovereignty and sensitivity regimes**. At minimum:

* **SDZ classes** define normative protections:
  * **SDZ-0** — Global public: fully open, non-sensitive data (e.g., global climate indices, open geospatial layers).
  * **SDZ-1** — Public-interest sensitive: aggregate or anonymised data whose misuse could still harm communities or markets.
  * **SDZ-2** — Regulated confidential: pseudonymised or indirect identifiers in regulated domains (e.g., financial, health).
  * **SDZ-3** — Hardened sovereign: highly sensitive, security-relevant, or identity-linked data; must remain within tightly controlled sovereign domains.
* **Tiers** refine requirements by sector (e.g., SDZ-2H for health, SDZ-2F for finance), mapping to specific legal regimes and ethical standards.

For each SDZ class/tier, NXSS specifies:

* **Residency** (where data may reside): jurisdiction, cloud region, on-prem, secure enclaves.
* **Processing modes**: compute-to-data only, encryption requirements, query and aggregation constraints.
* **Access**: permissible roles, institutions, and agent classes; mandatory oversight.

These constraints are compiled into machine-enforceable **Policy DSL** rules and implemented by **NXSOS GeoGuard + IAM-broker**.

**3.3.2 SDZ and Cross-Border Data Governance**

SDZs also underpin **cross-border and cross-rail collaboration**:

* **Federated analytics**:
  * NRM computations use federated queries and secure multi-party computation patterns where necessary, ensuring sensitive data never leaves its SDZ while still contributing to global analyses.
* **Cross-border SDZ agreements**:
  * RNCs and member states can define explicit **SDZ interoperability agreements** (e.g., for transboundary water basins, regional grids, refugee flows), specifying:
    * Shared datasets and derived products.
    * Legal bases, oversight mechanisms, and revocation conditions.
    * Monitoring and reporting obligations.
* **Compliance mapping**:
  * SDZ classes/ties are mapped to regulatory stacks (GDPR, HIPAA, financial secrecy laws, open data mandates, Indigenous data sovereignty principles), giving regulators a clear view of **how the rail operationalises compliance**.

For NRM, SDZ ensures high-fidelity risk intelligence while preserving **sovereignty, safety, and legitimacy**.

***

#### 3.4 Conformance & Evidence Standards

**3.4.1 CL (Conformance Levels, CL1–CL4)**

**Conformance Levels (CL)** define **graduated architectural and operational requirements**:

* **CL1 — Exploratory**
  * Minimal GRIx mapping, basic security and logging, non-critical usage.
  * Suitable for prototyping, training environments, and non-binding analysis.
* **CL2 — Operational**
  * Full SDZ enforcement, Data Fabric with lineage, basic ML governance, standardised AEP structuring.
  * Suitable for internal decision support and low-to-medium stakes policy/planning.
* **CL3 — Critical**
  * Integrated NXSOS governance; CL/EQL-aware evidence; agent safety tiers enforced; end-to-end observability; tested rulebooks and playbooks.
  * Suitable for decisions with significant financial, infrastructure, or social impact (e.g., supervisory uses, major public programmes).
* **CL4 — Systemic**
  * Multi-rail interoperability; NXHIVE integration; systemic stress testing; continuous monitoring; external certification; robust rollback and fail-safe protocols.
  * Required where outputs inform **systemic capital flows, regulatory decisions, or critical infrastructure operations** affecting large populations or economies.

CL is assigned to **rails, packs, observatories, and applications** and must be:

* Discoverable (e.g., via NXUNIV).
* Justified via test suites and audits.
* Explicitly referenced in policy and contractual documents (e.g., “facility X relies on CL3 NRM evidence”).

**3.4.2 EQL (Evidence Quality Levels, EQL1–EQL5)**

**Evidence Quality Levels (EQL)** classify **AEPs and other analytic outputs** by methodological robustness:

* **EQL1 — Exploratory**
  * Informal, indicative, minimal validation, not suitable for binding decisions.
* **EQL2 — Structured but limited**
  * Some validation; constraints in data coverage, methods, or generalisability; acceptable for exploratory planning.
* **EQL3 — Operational standard**
  * Adequate data, transparent methods, validation against benchmarks; suitable for routine operational and policy decisions, subject to governance oversight.
* **EQL4 — High-evidence**
  * Multi-source corroboration; independent review; stress testing; sensitivity and uncertainty analysis; suitable for high-stakes decisions and regulatory processes.
* **EQL5 — Canonical**
  * Replicated across independent observatories; endorsed under specific GRF-IP profiles; continuous performance monitoring; used as **reference evidence** in systemic programmes.

EQL is determined through a combination of:

* **GCRI technical criteria** (data quality, model performance, reproducibility).
* **GRF assurance processes** (peer review, cross-observatory comparison, governance checks).

Decision protocols and NRM Profiles MUST specify **minimum EQL thresholds** (e.g., “no capital trigger without ≥EQL3 evidence”).

**3.4.3 GRF-IP Implementation Profiles**

**GRF Implementation Profiles (GRF-IP)** are **binding bundles** of standards for specific NRM contexts:

* Example profiles:
  * GRF-IP–NRM–Climate–Sovereign–Fiscal
  * GRF-IP–NRM–Cyber–CriticalInfra
  * GRF-IP–NRM–Pandemic–HealthSystems

Each profile specifies:

* **Required CL** for rails, packs, and observatories.
* **Minimum EQL** for AEPs used in particular decisions.
* **Mandatory SDZ classes, safety tiers, and legal/compliance overlays**.
* **Expected model and ontology modules** (GRIx subsets, chronotope and episode specifics).

GRF-IP profiles provide regulators, DFIs, and ministries with a **concrete, testable spec** for “what constitutes compliant NRM use” in a given policy or financial instrument.

***

#### 3.5 Identity & Credential Standards

**3.5.1 DID/VC Identity Profiles**

NXSS adopts **Decentralised Identifiers (DIDs)** and **Verifiable Credentials (VCs)** as the core identity and attestation mechanism:

* **DID documents** represent:
  * Institutional entities (RNCs, NCCs, ministries, utilities, firms).
  * System components (rails, packs, observatories, agents, critical models).
  * Individual roles where appropriate and lawful (e.g., validators, incident commanders, community representatives).
* **VCs** encode attestations about:
  * Competence (training, certification, NRM Academy credentials).
  * Conformance (CL/EQL certifications; model approvals).
  * Governance authority (DAO roles, NVM quorum seats).

Use of DIDs/VCs allows **cryptographically strong links** between:

* Who did what (episodes).
* Under which authority.
* With which evidence.

**3.5.2 NXIdentity Roles, Keys, and Credential Types**

**NXIdentity** is the logical **role and credential framework**:

* **Role taxonomies**:
  * Technical (Architect, Data Engineer, Model Owner, Agent Maintainer).
  * Scientific (NCC Lead, Domain Scientist, Model Reviewer).
  * Governance (Regulator, Ministry Official, Community Board Member).
  * Operational (Emergency Manager, Grid Operator, Treasury Officer).
* **Key and credential management**:
  * Key types and storage requirements (e.g., HSM-backed keys for high-privilege roles).
  * Delegation patterns (e.g., role-based delegations, time-bound authorisations).
  * Rotation and revocation procedures.

NXIdentity connects directly to NXSOS (`nxsos.iam-broker`) and NXHIVE, ensuring that **authority and competence are formally represented and machine-enforceable** in all high-stakes operations.

***

#### 3.6 DSLs & Protocol Specifications

**3.6.1 Nexus Protocol (Logical Specification of the Rail)**

The **Nexus Protocol** is the **canonical, machine-executable spec** for the behaviour of the rail. It defines:

* Object types (Rails, Packs, AEPs, Profiles, Episodes, Models, Agents, Rulebooks).
* Lifecycle transitions (e.g., AEP draft → reviewed → certified → archived).
* Interaction patterns (e.g., AEP request-response flows, NVM quorum flows, DAO proposals and votes).
* Dual logging semantics (how artefacts acquire legal and economic effect via GRF Council Register + Nexus Ledger entries).

It is implemented in NXSOS (`nxproto.*`) and specified in formal schemas (e.g., state machines, temporal logic constraints where needed).

**3.6.2 Policy DSL (Access, Residency, Safety, GeoGuard, HIL, Lawful Basis)**

The **Policy DSL** is a **declarative language** for encoding policies that must be enforced at runtime:

* Access control policies (attribute-based and role-based).
* Residency and GeoGuard policies (jurisdictional and SDZ constraints).
* Safety policies (e.g., max autonomy level for agents, restricted operations).
* Human-in-the-loop requirements (e.g., multi-signature approvals for specific actions).
* Lawful-basis conditions (linking to lawful-basis matrices).

Policies are:

* Version-controlled;
* Testable (unit and property-based tests);
* Enforced in real time by NXSOS, Data Fabric, and ML Fabric.

**3.6.3 Playbook DSL (AAP/IRP Playbooks)**

The **Playbook DSL** defines:

* **Anticipatory Action Plans (AAPs)** (e.g., pre-disaster cash transfers, pre-positioning of resources).
* **Incident Response Plans (IRPs)** (e.g., cyber incident mitigation, grid restoration, outbreak response).

It includes constructs for:

* Triggers and guard conditions (linked to indices/AEPs).
* Control flow (branching, parallelism, timeouts, retries).
* Escalation and communication steps.
* Binding to operational systems and human roles.

Playbooks are simulated, stress-tested, and certified at specific CLs before they are allowed into critical operations.

**3.6.4 Agent Capability DSL**

The **Agent Capability DSL** formalises **what an agent is allowed to do**:

* **Perception scope** (which data, ontologies, and events can be read).
* **Reasoning scope** (which models, rulebooks, and scenarios can be invoked).
* **Action scope** (which actions, in which domains, at what safety tier).
* **Oversight and reporting** (what must be logged, flagged, or escalated).

This DSL allows regulators, RNCs, and institutions to **inspect, compare, and approve agent capabilities** in a structured, systematic way.

**3.6.5 Rail Configuration DSL (rail.yaml)**

`rail.yaml` is the **canonical representation** of a rail configuration:

* Identity (rail ID, purpose, scope).
* Attached domain packs and observatories.
* Governance config (DAO, NVM quorum, participants).
* CL and SDZ baselines; safety and lawful-basis overlays.
* Operational parameters (SLOs, capacity constraints, fail-safe modes).

`rail.yaml` is treated as code:

* Stored in version control;
* Subject to review and automated checks (linting, policy validation, simulation);
* Anchored on chain/ledger for integrity and provenance.

**3.6.6 Pack Configuration DSL (pack.yaml)**

`pack.yaml` defines **Nexus Packs (NXPCK)** — composable, domain-specific bundles:

* Domain ontologies and extensions.
* Data connectors and pipelines.
* Reference models, indices, and AEP templates.
* Rulebooks, playbooks, dashboards.
* Safety overlays and CL/EQL targets.

Packs can be published, certified, and discovered via **NXUNIV**, enabling reuse and systematic domain extension.

***

#### 3.7 Safety, Security & Crypto Baselines

**3.7.1 AI / Agent Safety Tiers and Classifications**

NXSS defines **AI/agent safety tiers** that classify agentic systems along axes of:

* **Impact domain** (e.g., advisory vs critical infrastructure, financial vs public health).
* **Autonomy** (e.g., read-only, recommend-only, act-with-approval, fully autonomous).
* **Consequence level** (e.g., financial-only, life-safety implications, systemic risk implications).

Each tier has:

* Mandatory governance processes (e.g., NVM approval, external audit).
* Required testing (adversarial testing, red teaming, simulation of failure modes).
* Obligatory human oversight structures.

Agents MUST declare their tier, and NXSOS MUST enforce tier-appropriate mechanisms (e.g., hard blocks on higher-risk actions without approvals).

**3.7.2 BioSafe & Dual-Use Safeguards**

In domains with biological or dual-use risk:

* **BioSafe constraints** define prohibited and restricted functionalities (e.g., no assistance in constructing pathogens, restricted access to certain datasets).
* Scenario modelling and simulation tools in these domains must be **sandboxed and monitored**.

NRM Profiles in health, biosecurity, or related fields MUST integrate BioSafe policies at both design and runtime.

**3.7.3 PQ Crypto Baselines & PQGuard Guardrails**

NXSS includes **post-quantum (PQ) security baselines**:

* Recommended PQ algorithms and transition strategies.
* Requirements for long-lived artefacts (ledger records, AEP anchors, contracts).
* PQGuard runtime that:
  * Flags non-compliant cryptography.
  * Enforces migration schedules and blocks high-risk uses of legacy schemes.

This protects the **long-term integrity and non-repudiation** of NRM evidence and decisions.

**3.7.4 Privacy & Zero-Trust Constraints**

NXSS assumes a **zero-trust security model** by default:

* Every request is authenticated, authorised, and policy-evaluated.
* Network location, infrastructure, and identity are insufficient to grant access; all paths are verified.
* Privacy-preserving transformations (aggregation, differential privacy, synthetic data, k-anonymity) are mandated in specific profiles, especially where vulnerable communities are involved.

Privacy-by-design is not optional; it is part of CL/EQL conformance and SDZ governance.

***

#### 3.8 Lawful-Basis Matrices and Compliance Profiles

**Lawful-basis matrices** link **data categories, use cases, and actors** to legally and ethically acceptable bases for processing:

* Axes include:
  * Data category (e.g., health, financial, location, community knowledge).
  * Actor (e.g., ministry, regulator, insurer, DFI, community node).
  * Use case (e.g., stress testing, payout trigger, anticipatory action).

For each cell, the matrix specifies:

* Allowed legal bases (e.g., explicit consent, legal obligation, public task, legitimate interest).
* Additional procedural or governance requirements (e.g., community consent, Indigenous review bodies).

**Compliance profiles** (e.g., “GDPR-BE-high”, “US-health-critical”, “Indigenous-knowledge-protected”) package lawful-basis matrices, SDZ classes, and policy DSL fragments into reusable, testable templates.

These profiles are attached to:

* Rails and packs (as preconditions for deployment).
* AEPs (as part of their provenance).
* Agents and playbooks (as constraints on their behaviour).

***

#### 3.9 Test Suites & Certification Baselines

**3.9.1 Conformance Test Suites (CL/EQL)**

For each **CL/EQL combination**, NXSS specifies test suites that evaluate:

* **Architectural compliance** (presence of required components, correct wiring of NXSOS, SDZ enforcement).
* **Process compliance** (governance workflows, NVM quorums, documentation, approval trails).
* **Evidence and model compliance** (AEP structure, model documentation, validation, monitoring).

These suites form the basis for:

* GRF-led certification of rails, packs, observatories, and agents.
* Self-assessment and internal audits for institutions.
* Regulator and DFI due diligence for programmes that rely on NRM evidence.

**3.9.2 Core API Schemas (OpenAPI / gRPC / JSON Schema)**

NXSS provides **canonical API schemas** (OpenAPI, gRPC, JSON Schema) for:

* Discovery and management of rails and packs.
* AEP lifecycle (request, generation, retrieval, revocation).
* Indices, alerts, and episode event streams.
* Identity, credentials, and governance interactions.
* Agent control (registration, capability declaration, command channels).

These schemas enforce **syntactic and semantic interoperability** across vendors and RNCs.

**3.9.3 Event Formats for Indices, Alerts & Episodes**

Standardised event schemas define:

* **Index events**: risk/resilience indices, with identifiers, units, uncertainty ranges, and provenance.
* **Alert events**: severity, scope, recommended actions, HIL requirements, escalation paths.
* **Episode events**: linking signals, AEPs, decisions, and outcomes; necessary for replay and analysis.

Consistent event formats are essential for **cross-rail observability, stress testing, and systemic risk analysis**.

***

#### 3.10 Open-Source, Licensing & Contribution Governance

**3.10.1 Licensing Model (Code, Ontologies, Schemas, AEP Templates)**

NXSS is designed as **global digital public infrastructure**:

* **Reference code** for core components (NXSOS, NXSTUDIO, NXOBS, DSL compilers, etc.) is released under permissive or copyleft licences chosen to:
  * Ensure openness and inspectability of core governance logic.
  * Allow commercial ecosystems to thrive without enclosing the public core.
* **Ontologies, schemas, and AEP templates** are released under open content licences:
  * Allowing reuse, adaptation, and republication with attribution.
  * Requiring transparent declaration of extensions.
* **Security-sensitive artefacts** (certain BioSafe rules, INT schemas) may have distribution controls while still being governed under NXSS processes.

**3.10.2 Contribution Process (RFC/NEP Flow, Review, Acceptance)**

NXSS evolves through a formal **RFC / Nexus Enhancement Proposal (NEP)** process:

1. **Drafting** — by GCRI/GRF working groups, RNC/NCC teams, vendors, or community/Indigenous representatives.
2. **Public review** — transparent comment period; structured input from stakeholders.
3. **Technical and normative evaluation** — by designated committees (e.g., GCRI technical boards, GRF standards boards, community/Indigenous advisory bodies).
4. **Decision and publication** — acceptance, partial acceptance, or rejection, with rationale; new or updated NXSS artefacts versioned and dual-logged (Council Register + Nexus Ledger).

This process ensures **traceable, transparent governance** over the standards that shape the rail.

**3.10.3 Compatibility, Forks, and Anti-Fragmentation Policies**

To maintain a **coherent global ecosystem**:

* NXSS maintains:
  * A **compatibility matrix** across versions and profiles.
  * Migration guides and deprecation policies for outdated or unsafe constructs.
* Forks and local variants are allowed but:
  * MUST declare divergence and compatibility relationships.
  * MAY lose CL/EQL recognition if they deviate from critical safety, semantic, or governance baselines.
  * SHOULD preserve semantic bridges (mapping layers) to canonical GRIx and NXSS to retain interoperability.

The aim is not to prevent local innovation, but to **avoid fragmented, incompatible “Nexus-like” systems** that erode trust, comparability, and systemic coherence.

***

Taken together, **NXSS** is the **constitutional and semantic backbone** of the Nexus Ecosystem: it tells us *what the world looks like* in risk terms, *what counts as good evidence*, *how systems and agents must behave*, and *how we know they are doing what they claim*. Without NXSS, the Nexus Rail would be just another stack; with NXSS, it becomes a governed, contestable, and interoperable **global operating rail for risk and resilience**.


---

# 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/nxss-standards.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.