> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/introduction/knowledge/i.-system-overview.md). # I. System Overview Overview of the Nexus programme and its systems: why it exists, its five-area structure, One Rail-Two Stacks, the institutions, twenty systems and status.
Document record · Draft · Legal review required · Updated 21 October 2026 | | | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Status** | Draft. Explanatory page; it creates no rights or obligations. | | **Legal review** | Required before final publication. | | **Version** | 2026.10.21-r3 | | **Updated** | 21 October 2026 · reviewed every 180 days | | **Owner** | Documentation desk (named reviewer pending) | | **Based on** | Nexus Documentation Standard (draft); Nexus constitutional directives D-V3-0001, D-V3-0003, D-V3-0004 and D-V3-0005; Nexus institutional architecture and participation; the Nexus model and the Nexus Consortium model as published on the sites (2026-10-21); the [Nexus Standards](/organization/institutions/nexus-standards.md) governance and [NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
**Where this fits:** all six sectors · all six pillars, above all Nexus Standards and Nexus Reports for the rules of this documentation · the Nexus Consortium, with GCRI Canada as Secretariat · Publish and Renew in the cycle · overview. {% hint style="info" %} **Read with the current model (21 October 2026).** This page now reads against the two linked models that organize the whole documentation: [coupled risk](/organization/model/coupled-risk.md) across six sectors and fifteen relations, and [applied response](/organization/model/applied-response.md) through six pillars, eighteen handoffs and one [programme year](/organization/programme/the-programme-year.md) with gates G0 to G7 \[12]. Institutional roles follow the current public wording \[13]: GCRI Canada is Lead Institution, Consortium Secretariat and lead contracting organization; [GRF](/organization/institutions/grf.md) leads leadership, institutional dialogue and the governance of the annual [Nexus Universe](/organization/programme/universe.md) programme, recording each gate; [GRA](/organization/institutions/gra.md) makes risk evidence readable to finance and insurance and does not lend, underwrite, rate, invest, advise on or arrange transactions. In a country the programme is [National Nexus](/organization/governance-in-operation/national-nexus.md): a National Desk, a National Model, a National Portfolio and three participation pillars, the [NNC](/organization/governance-in-operation/nnc.md) for institutions, the [NLC](/organization/governance-in-operation/nlc.md) for leaders in a personal capacity and the [NWG](/organization/governance-in-operation/nwg.md) for expert work, with six CERTs under the working groups. The [National Standards Council](/organization/governance-in-operation/national-standards-council.md) is the NNC's standards function \[14] \[15]. Everything described here is in formation: no national programme is recorded as constituted or active, and the current service level is R0, information and enquiries ([status and service levels](/organization/governance-in-operation/status-and-service-levels.md)) \[16]. The case for one model rests on the evidence that risks compound and cascade across sectors and borders \[17] and on the international frameworks that ask for whole-of-society risk governance \[18] \[19]. {% endhint %} {% hint style="info" %} **Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service. {% endhint %} ## In brief The Nexus programme is a public-good effort to help countries and institutions understand and manage interconnected risks through shared evidence, standards and infrastructure. It combines an independent consortium of institutions, nationally owned programmes and a proprietary technical architecture organized as twenty systems. Its core design rule, One Rail-Two Stacks, keeps the public-good rail that produces evidence and readiness separate from the actors who decide and execute. Most of the platform described here is target architecture, not a running service \[1]\[2]\[3]. ## Summary This overview explains what the **Nexus Ecosystem** is, why it exists, and how its five primary knowledge domains work together. It connects **institutional order**, **operations**, **cooperation**, **standardization**, and **acceleration** into one searchable system view. Use this page before going deeper into [Organization](/organization/introduction/organization.md), [Operations](/organization/introduction/operations.md) and [Standardization](/organization/introduction/standardization.md). Sections 1.12 to 1.20 add the definitions, institutional roles, systems and status statements on which the earlier sections rely. {% hint style="info" %} **Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol system, in collaboration with [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric, and [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. Together these three systems form the observatory ecosystem. [**Nexus of Observatories**](/organization/systems.md)**.** Every Nexus platform and system includes its own observatory capability, covering remote sensing, in-situ instruments and edge deployments. Across every area where these observatories are implemented, including implementation pilots in programme areas, they form the Nexus of Observatories, which is part of the not-for-profit programme architecture. On this site, "Nexus Observatory" refers only to this observatory capability and to the protocol above. {% endhint %} ## 1.1 The meaning of the Nexus ecosystem The Nexus Ecosystem (in this page, the whole Nexus programme; see 1.12) is a deliberately constructed institutional and operating order designed to make complex risk, resilience, readiness, infrastructure, standards, finance-readiness, and public-purpose action intelligible and usable within one coherent architecture. It is not a single organization, not a software stack alone, not a forum, not a fund, not a policy network, and not a deployment program in isolation. It is a system of systems: institutional, semantic, technical, operational, and developmental at once. Its central claim is that the conditions shaping the present era can no longer be understood or governed through fragmented institutional forms. Public risk is no longer separable from infrastructure. Infrastructure is no longer separable from trust. Trust is no longer separable from verifiability, institutional legitimacy, and standards-bearing interoperability. Readiness is no longer separable from observability, routeability, and lawful downstream consequence. The Nexus Ecosystem exists because these relationships must be organized as one governing reality rather than treated as adjacent concerns managed by separate actors with separate languages. The system is therefore designed to provide a common coordinating function: to turn fragmentation into coordinated intelligibility without erasing sovereignty, without privatizing the public-good rail, and without allowing technical centrality or commercial capability to become a substitute for constitutional legitimacy. ## 1.2 Why Nexus exists Nexus exists because the dominant institutional arrangements of the present period fail in structurally predictable ways. Research institutions can generate analysis, but they cannot by themselves hold a globally interoperable and deployment-relevant public-good rail. Policy institutions can convene, but convening alone does not create standards-bearing continuity, runtime trust, or routeable readiness. Markets can price, but they cannot author public truth. Technical vendors can build, but they cannot legitimately hold the constitutional center of a system intended to serve sovereigns, public institutions, and long-horizon public-purpose needs. States carry sovereign authority, but no single state can independently supply a globally interoperable, public-interest, anti-fragmentation infrastructure for shared risk, resilience, and readiness. The result is a recurring pattern: evidence remains upstream, standards remain abstract, interoperability remains rhetorical, trust remains under-institutionalized, and deployment becomes either fragmented, commercially enclosed, or politically brittle. Nexus is designed to help correct that pattern. International assessments describe the same pattern of interacting risks (see 1.13). It exists to create one coherent order in which truth, governance, participation, standards, and realization remain linked but non-collapsing. It exists to give serious institutions a common rail on which shared meaning, verification, routeability, and implementation discipline can travel without being silently redefined by the strongest participant, the most visible delivery surface, or the most capitalized actor. ## 1.3 The structural thesis of Nexus The structural thesis of Nexus is simple in statement and demanding in consequence: there must be one common rail of meaning, trust, standards, and routeability, but that rail must be carried through differentiated institutions and differentiated functions, not through one totalizing center. This thesis requires several linked propositions. First, there must be a **constitutional order**. The system cannot rely on informal goodwill, branding, network effects, or ad hoc alignment. It must have defined institutions, defined roles, defined authorities, and defined limits. Second, there must be an **operating order**. Constitutional clarity without working mechanisms produces stagnation. The system must know how work is produced, reviewed, corrected, published, governed, and maintained. Third, there must be a **cooperation order**. Participation must be structured, not merely welcomed. Ecosystems only remain healthy if contribution pathways, councils, memberships, guilds, and alliance interfaces are defined with discipline. Fourth, there must be a **standards order**. Meaning must remain canonical across jurisdictions, sectors, and deployments. Trust must be designed, not implied. Interoperability must be structural, not symbolic. Fifth, there must be a **realization order**. If the architecture cannot become materially, institutionally, and geographically real, it remains incomplete. Realization, however, must remain subordinate to the constitutional and standards-bearing order that gives it meaning. Taken together, these propositions give Nexus its five-part knowledge architecture and its deeper conceptual coherence. ## 1.4 The five-area architecture The Nexus knowledge system is organized into five primary areas because each area corresponds to a different class of truth and a different burden-bearing function within the whole architecture. ### 1.4.1 Organization Introduction: [Organization introduction](/organization/introduction/organization.md). Organization defines the constitutional and institutional order of the system. It explains who the core institutions are, how authority is distributed, how governance is structured, how federation works, and how the system remains one coherent order across global, regional, national, and host levels. Organization answers the question: **What is the institutional form of Nexus, and how is its authority constituted?** ### 1.4.2 Operations Introduction: [Operations introduction](/organization/introduction/operations.md). Operations describes the working order of the system. (Earlier versions of this page called this area "Operation"; the site part is named Operations.) It explains frameworks, workflows, mechanisms, production logic, reporting discipline, forum structures, media operations, and platforms. It is where institutional design is intended to become repeatable practice. Operations answers the question: **How is Nexus designed to function as a working system rather than only an institutional thesis?** ### 1.4.3 Cooperation Introduction: [Cooperation introduction](/organization/introduction/cooperation.md). Cooperation defines the participation architecture of the system. It explains alliances, guilds, councils, memberships, ecosystem interfaces, and domain-specific participation structures. It is where multi-actor coordination becomes governed rather than informal. Cooperation answers the question: **Who participates in Nexus, through what structures, and under what safeguards and contribution rules?** ### 1.4.4 Standardization Introduction: [Standardization introduction](/organization/introduction/standardization.md). Standardization defines the canonical architecture of the system. It explains the common rail, the semantic spine, protocol logic, trust architecture, conformance system, sovereignty framework, standards operating system, and routeability grammar. It is the keeper of coherence. Standardization answers the question: **What is authoritative, canonical, interoperable, and valid across the whole system?** ### 1.4.5 Acceleration Introduction: [Acceleration introduction](/organization/introduction/acceleration.md). Acceleration describes the realization architecture of the system. It explains how Nexus is intended to become materially real through compute infrastructure, observatory nodes (NXS-OPS), consortiums, specialized guilds, programs, studios, accelerators, partner ecosystems, and deployment pathways. It is the domain where the architecture enters the world without losing its constitutional and standards-bearing discipline. Acceleration answers the question: **How is Nexus intended to become real in institutions, infrastructures, sectors, regions and host environments, and what is its evidence state today?** ## 1.5 The order of reading The order of the knowledge system is not arbitrary. It reflects the internal logic of the architecture. A reader begins with **Organization** because institutional authority and structure must be understood before any downstream layer can be interpreted correctly. The reader then proceeds to **Operations**, because an institutional order that cannot be understood as a working system remains incomplete. The reader then proceeds to **Cooperation**, because participation structures can only be read correctly once the reader understands both authority and operating logic. The reader then proceeds to **Standardization**, because canonical doctrine and technical architecture must be understood in relation to the institutional and operational order that governs them. The reader then proceeds to **Acceleration**, because realization should be read last: not because it is secondary, but because it is the domain in which all prior layers are instantiated and therefore the domain most vulnerable to misreading when isolated from them. This sequence preserves the architecture against a common failure mode: reading the most visible or technically impressive layer as though it were the whole system. ## 1.6 The public-good core and the discipline of separation A central feature of Nexus is its refusal to collapse public-good authority into execution-side capability. The system is designed around a strict distinction between the public-good constitutional core and downstream enterprise, capital, service, and execution-facing layers. This distinction is not cosmetic. It is one of the chief protections of the architecture. Without it, technical capability could become a substitute for legitimacy.\ Without it, capital proximity could become a substitute for public authority.\ Without it, deployment could become a substitute for truth.\ Without it, routeability could become a substitute for execution readiness.\ Without it, the common rail could be quietly enclosed by whichever actor scales fastest. Nexus therefore preserves institutional differentiation across the functions of evidence stewardship, recognition, routeability, protocol continuity, runtime support, ecosystem participation, and realization. The system is stronger because these functions are interoperable but not substitutable. ## 1.7 Sovereignty, federation, and global coherence Nexus is designed to be globally coherent but not globally centralized. It is designed to respect national sovereignty without isolating national programmes from one another. It is designed to be federated but not fragmented. This means the system is designed so that national lawful grounding remains real, host truth remains visible, local capacity can deepen over time, and regional coordination can emerge where appropriate, all without breaking the common rail of meaning, trust, standards, and routeability. Federation, in this context, is not an administrative convenience. It is the method by which one coherent system can exist across multiple jurisdictions, hosts, and contexts without becoming either a hidden hierarchy or a loose confederation of incompatible local variants. Nexus therefore treats federation as a first-order structural principle and not as a later scaling tactic. ## 1.8 Standards, trust, and routeability The system is not only institutional. It is also semantic, technical, and trust-bearing. A core premise of Nexus is that modern public-purpose systems fail not only because of weak institutions, but because they lack a common rail of meaning, verifiability, and bounded handoff. For that reason, Nexus treats standardization as foundational rather than secondary. Semantics, protocol logic, identity, trust, conformance, proof, and routeability are not support functions. They are part of the governing architecture itself. This matters especially for routeability. Nexus is designed to make readiness and evidence more legible to public authorities, multilaterals, financial institutions, insurers, strategic backers, and other serious downstream readers without allowing the public-good core to become an execution actor. That is why routeability is not equivalent to execution. It is a governed state of bounded readiness and intelligibility: on this site, routeability means a lawful handoff of a readiness dossier to a competent party, which then decides under its own authority (see [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md)). The distinction must remain bright for the system to remain credible, and the V3 boundary formulas in 1.14 state it verbatim. ## 1.9 Realization through compute and observatory infrastructure The architectural sequence culminates in realization. In Nexus, realization is designed not to begin with abstract deployment claims. It is designed to begin with infrastructure "intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment" \[4], with observability, trust-bearing runtime environments and institutional vehicles capable of lawful and supportable implementation. In the earlier vocabulary of this site, compute infrastructure (the Acceleration section "Nexus Compute") is the organizing envelope of realization, and observatory nodes are its distributed points of observation. In V3 terms these correspond to [NXS-COR](/organization/systems/nxs-cor.md), the distributed compute system for compute, providers and regions, and [NXS-NET](/organization/systems/nxs-net.md), the network intelligence and communications resilience system, and to NXS-OPS observatory nodes (see 1.16 and 1.17). Together with national and regional consortiums, specialized guilds and structured programmes, they are intended to make the architecture materially real without allowing realization to outrun institutional and standards-bearing discipline. None of this states that such infrastructure operates today: the status of every System capability is given per dimension in 1.16, and the status note at the top of this page applies. This is a defining feature of the system. Nexus is not satisfied with conceptual coherence. It is designed for implementable coherence. ## 1.10 The knowledge system as safeguard The structure of the Nexus knowledge base is itself one of the safeguards of the system. It prevents one layer from speaking with the authority of another.\ It prevents deployment language from rewriting standards language.\ It prevents participation language from rewriting governance language.\ It prevents technical architecture from being mistaken for the whole system.\ It prevents institutional identity from being thinned into branding. In this sense, the knowledge architecture is not merely a publishing convenience. It is one of the means by which Nexus preserves seriousness, coherence, and integrity over time. ## 1.11 Final overview statement The Nexus Ecosystem should therefore be understood as a unified institutional and operating design for collective security, resilience, readiness, infrastructure that respects national sovereignty, standards-bearing interoperability and lawful real-world realization. It is built on one common rail and carried through differentiated domains of authority, operation, participation, standardization, and realization. Its knowledge system reflects that architecture deliberately. Organization, Operations, Cooperation, Standardization, and Acceleration are not menu categories. They are the five major domains through which the system is designed to remain intelligible, governable and deployable without collapsing into fragmentation or hidden centralization. This is the overview through which all further reading should proceed. ## 1.12 What "Nexus" means on this site The word appears in several senses. On this site: * **The Nexus programme** is the whole effort described in this documentation: the public-good Nexus Consortium, the national and regional Nexus Consortiums, the annual Nexus Universe programme, the [Nexus Reports](/organization/programme/reports.md) publication programme and the Nexus systems \[4]. * **The twenty Nexus systems** form "one coherent, federated, independently reconstructible system of systems" \[1], whose technology is made available to the Nexus Consortium as shared infrastructure for public-good and consortium purposes, by an external provider at arm's length \[4]. * [**NXS-CMD**](/organization/systems/nxs-cmd.md) **(integrated posture and executive synthesis)**, the system command home, which brings every subsystem's state into one integrated posture, is system 1 of the twenty; on this site the system is always shown by its code \[2]. * **Nexus Ecosystem** is also the title of a section in the Standardization part; the section title is kept as written. * Lowercase "nexus" in phrases such as "the water-energy-food nexus" is ordinary English and names no institution or product \[5]. ## 1.13 The problem in international context Risk no longer stays inside one sector or one country. International assessments describe hazards and vulnerabilities that interact, so that a shock in one system travels into others: * The **Sendai Framework for Disaster Risk Reduction 2015-2030**, endorsed by the UN General Assembly in resolution 69/283, makes understanding disaster risk its first priority for action and calls for multi-hazard, multisectoral approaches \[6]\[7]. * The **IPCC Sixth Assessment Report** synthesis assesses that climate-related risks are becoming more complex and harder to manage, with compounding risks and risks cascading across sectors and regions \[8]. * UNDRR's **Global Assessment Report** series examines the systemic nature of risk and the limits of managing hazards one at a time \[9]. * The **2030 Agenda for Sustainable Development** (resolution 70/1) frames development, resilience and risk reduction as integrated goals \[10]. The Nexus programme responds to the practical gap these documents describe: evidence that is fragmented across institutions, standards that are not shared, and readiness that is hard for decision makers, financiers and communities to read. It is one response among many and does not speak for any of these frameworks. {% hint style="info" %} **Alignment, not endorsement.** References to the Sendai Framework, the IPCC, UNDRR and the 2030 Agenda describe design intent and context. They do not imply endorsement, partnership or affiliation with any UN body or government \[5]. {% endhint %} ## 1.14 The core design rule: One Rail-Two Stacks **Definition.** One Rail-Two Stacks is the separation of a non-executing public-good rail from separately governed enterprise and sovereign execution \[3]. It gives the "discipline of separation" in 1.6 its binding form. * **The public-good rail** "creates evidence, observability, standards discipline, readiness records, transparent methods, public-safe products, learning, finance-readiness, insurance-readiness and correction pathways" \[3]. It informs, evidences, verifies, routes and records. It does not become a regulator, emergency commander, lender, investor, insurer, underwriter, procurement authority, settlement system or operator \[1]. * **The enterprise and sovereign execution stack** is where national consortium companies, project vehicles, qualified providers, operators, hosts, public authorities, financial institutions, insurers and other competent actors execute lawful activities under their own authority and contracts \[3]. * **Consequential actions** that can change external legal, financial, safety, public-authority or material state carry a defined envelope of fields (actor, mandate, policy decision, authority owner, purpose, jurisdiction, approvals, rollback, receipt and correction path) before any handoff \[3]. The boundary formulas apply verbatim across this site: "Finance-readiness is not finance. Insurance-readiness is not underwriting. Verification is not certification. Participation is not consent. Public-authority learning is not approval. Technology readiness is not procurement approval. A warning-support candidate is not an official warning. A decision-support package is not an official decision." \[3] [NXS-RLS](/organization/systems/nxs-rls.md) (system 18, the technical rails and protocol infrastructure for protocol-governed work across institutions), the One Rail-Two Stacks doctrine and the [`Nexus Rail`](/organization/standardization/nexus-rail.md) Standardization section are three different things; the "common rail" of earlier sections refers to the public-good rail of this doctrine. Decisions stay with competent actors. ## 1.15 Institutions The institutional order is explained in the [Organization introduction](/organization/introduction/organization.md) and is not restated in full here. In summary, using register wording \[4]: * **GCRI Canada** ([The Global Centre for Risk and Innovation](/organization/institutions/gcri.md)) is the Lead Institution, Consortium Secretariat and lead contracting organization for the Nexus Consortium. * **The Global Risks Forum (GRF)** and **The Global Risks Alliance (GRA)** are independent consortium stewards: GRF for leadership, dialogue and Nexus Universe programme governance; GRA for the finance, insurance and development-readiness interface, with no regulated financial activity. * **National hosts and anchor institutions** run national programmes under written agreements and recorded local mandates; national counterparts own the agenda, data and decisions. * **Competent public authorities** hold all sovereign, regulatory, fiduciary and operational decisions. {% hint style="warning" %} **Platform ownership and licensing status.** Legal title and licensing authority for each system asset remain subject to verification, to valid instruments and to government, institutional, customer and third-party exceptions. Licensing terms, technology development and infrastructure operation are set out in the applicable agreements. No executed assignment or licence is established by this page. (Institutional register notice, owner-confirmed, counsel review pending) \[4] {% endhint %} "Nexus Observatory Protocol" on this site means the observation protocol owned by NXS-OPS in collaboration with NXS-EOP and NXS-SIG. Other pages use "observatory" for NXS-OPS observatory nodes or for an evidence layer; those senses are distinct from the protocol. ## 1.16 The twenty systems and shared fabrics There are exactly twenty canonical systems, in fixed order with fixed identifiers. Nothing is "system 21", and shared fabrics are never counted among the twenty \[1]\[2]. Acronyms without an approved long form are not expanded. | # | System (display code) | Constitutional scope (summary) | | -- | ------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | 1 | NXS-CMD | Integrated command home, institutional posture, mission and portfolio intelligence, executive synthesis, accountable handoff | | 2 | [NXS-NST](/organization/systems/nxs-nst.md) | Civilian common operating picture, incidents, facilities, routes, resources, coordination zones | | 3 | [NXS-DSS](/organization/systems/nxs-dss.md) | Decision cases, evidence qualification, scenarios, options, uncertainty, decision-support packages | | 4 | NXS-COR | Compute, nodes, clusters, runtimes, workload placement, capacity | | 5 | [NXS-NXQ](/organization/systems/nxs-nxq.md) | Software, packages, connectors, models, tools, agents, entitlements | | 6 | [NXS-GRX](/organization/systems/nxs-grx.md) | Canonical data, metadata, provenance, quality, uncertainty, risk products, data federation | | 7 | NXS-EOP | Earth observation, geospatial computation, imagery, derived EO products | | 8 | [NXS-EWS](/organization/systems/nxs-ews.md) | Multi-hazard monitoring, impact forecasting, warning-support cases and candidates | | 9 | [NXS-AAP](/organization/systems/nxs-aap.md) | Anticipatory-action frameworks, triggers, preparedness, finance-readiness | | 10 | NXS-NET | Network topology, connectivity, telemetry, communications continuity | | 11 | NXS-OPS | Physical instruments, observatory nodes, sensors, calibration, primary observation evidence | | 12 | NXS-SIG | Authorized signal, spectrum, timing and communications-integrity observations | | 13 | [NXS-NSF](/organization/systems/nxs-nsf.md) | Constitutional trust, authorization, policy and assurance, public-safe release, correction governance | | 14 | [NXS-HUB](/organization/systems/nxs-hub.md) | Institutional knowledge, records, citations, collaboration, runbooks, learning | | 15 | [NXS-STU](/organization/systems/nxs-stu.md) | Visual composition, dashboards, maps, forms, workflow experiences, deployment profiles | | 16 | [NXS-FAC](/organization/systems/nxs-fac.md) | Blueprints, builder operations, code and artifact generation, verification, builds, assembly | | 17 | [NXS-APP](/organization/systems/nxs-app.md) | Application catalogue, installation, instances, upgrades, rollback, retirement | | 18 | NXS-RLS | Participants, roles, agreements, protocols, lawful handoffs, transaction envelopes, receipts | | 19 | [NXS-POR](/organization/systems/nxs-por.md) | Public, client, regulator, partner and developer delivery surfaces | | 20 | [NXS-LAB](/organization/systems/nxs-lab.md) | Research, experiments, simulations, frontier technology evaluation | *Table 1. The twenty canonical systems in V3 order. Source: D-V3-0003 \[2].* **Shared fabrics** cut across the twenty and each has an explicit boundary: NXS-CMD Command Centre; Universal Runtime; UNI Identifier Fabric; Ontology Fabric; Chronotope Fabric; NXS-GRX Graph; Passport Projection Fabric; Evidence and Receipt Fabric; Rights Control Plane; NEIF (owned by NXS-STU); NIRF; Station Artifact Fabric; Polyglot Run Service \[1]. Examples of their boundaries: "Identifier resolution is not authorization, certification or truth"; a receipt proves the recorded event within scope, not broader correctness \[1]. ### Status per dimension | Dimension | The systems as a whole | Evidence | | ----------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------ | | Target | Defined | D-V3-0001 to D-V3-0009 \[1]\[2]\[3] | | Implemented | Varies by capability; not summarized on this page | Capability ledger, last evaluated 2026-08-26 and stale against the current head \[5] | | Verified | Varies by capability; not summarized on this page | Same ledger | | Observed | No institutionally observed binding; operational state at most observed in a laboratory setting | Claim register \[11] | | Accepted | No record | None | *Table 2. Status of the systems by dimension. No merged readiness score is given or implied \[11].* ## 1.17 How the site's concepts map to the systems Several section names on this site predate the V3 system names. The figure shows the crosswalk proposed by the 2026 documentation audit for owner review.
Proposed crosswalk from site pages to V3 systems. In Acceleration, Compute pages point to NXS-COR and NXS-NET, Edge pages to NXS-OPS, NXS-EOP and NXS-EWS, Foundry pages to NXS-FAC and NXS-STU, and Marketplace pages to NXS-NXQ and NXS-APP. In Standardization, Protocol pages point to NXS-NSF and NXS-RLS, and Registry and ontology pages to the UNI and Ontology shared fabrics.

Figure 1. Proposed crosswalk from site concepts to V3 systems and shared fabrics. Editorial proposal awaiting owner review, not a V3 mapping and not a status claim. Source: twenty-system constitution D-V3-0003 and the 2026-10-16 documentation audit, as of 2026-10-16.

Text description of Figure 1 The figure has two panels. On the left, the Acceleration section holds four page families, each joined by a line to the V3 systems proposed for it: Compute pages to NXS-COR (compute and capacity) and NXS-NET (network and telemetry); Edge pages to NXS-OPS, NXS-EOP and NXS-EWS (observation, Earth observation and warning support); Foundry pages to NXS-FAC and NXS-STU (builds, assembly, dashboards and maps); Marketplace pages to NXS-NXQ and NXS-APP (software packages and the application catalogue). "Marketplace" has no V3 system of its own. On the right, the Standardization section holds two page families: Protocol pages, proposed for NXS-NSF and NXS-RLS (trust, public release, roles and handoffs), and Registry and ontology pages, proposed for the UNI Identifier and Ontology shared fabrics, which are not counted among the twenty systems. Every link is a proposal awaiting owner review.
## 1.18 Sovereignty, federation and data The systems are "intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment" \[4]. On this site "sovereign" describes a public authority's own powers or that design intent; it is never a product attribute \[5]. Two design rules follow from V3 and the institutional architecture, and they give section 1.7 its concrete form: * **National ownership.** National counterparts own the agenda, data and decisions; external institutions keep their legal, scientific, regulatory, emergency, financial and governmental authority \[1]\[4]. * **Compute-to-data.** For restricted and sovereign data the default pattern is to bring computation to the data; cross-border movement is an evidenced exception \[1]. ## 1.19 What the Nexus programme is not * Not a government, regulator, intergovernmental organization or UN body, and not an emergency service. * Not a lender, investor, insurer, underwriter, rating agency or procurement authority. * Not a certification body: "Verification is not certification" \[3]. * Not a single organization: it combines independent institutions, national programmes and a proprietary platform with separate legal identities \[4]. * Not a running production service today: see the status note at the top of this page and Table 2. ## 1.20 Key terms | Term | Meaning on this site | | ------------------- | ------------------------------------------------------------------------------------------------------------- | | Public-good rail | The non-executing part of the programme that creates evidence, readiness records and correction pathways \[3] | | Execution stack | Competent actors acting under their own authority and contracts \[3] | | Routeability | A lawful handoff of a readiness dossier to a competent party, which then decides | | Shared fabric | A cross-cutting capability with an explicit boundary, not counted among the twenty systems \[1] | | System display code | The fixed Nexus Standards code of a V3 system, for example NXS-GRX | ## Next steps * Read [II. Knowledge Architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) for the structural logic of the five domains. * Read [V. Scope and Boundaries](/organization/introduction/knowledge/v.-scope-and-boundaries.md) for what the knowledge base includes and excludes. * Move to [Organization](/organization/introduction/organization.md) to begin the main domain sequence. ## Related pages * Up: [Knowledge](/organization/introduction/knowledge.md) * Across: [0. Knowledge system](/organization/introduction/knowledge/0.-knowledge-system.md) · [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) · [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) * Counterparts: [Organization introduction](/organization/introduction/organization.md) · [Acceleration introduction](/organization/introduction/acceleration.md) · [Standardization introduction](/organization/introduction/standardization.md) ## Sources 1. Nexus constitutional directive D-V3-0001, *Master directive V3* (system of systems, shared fabrics, authority invariants, compute-to-data). Internal record, cited by identifier. 2. Nexus constitutional directive D-V3-0003, *Twenty-system constitution*. Internal record, cited by identifier. 3. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks and non-execution* (public-good rail, execution stack, consequential action envelope, boundary formulas). Internal record, cited by identifier. 4. Nexus institutional register, *Nexus institutional architecture and participation*, including the lead contracting organization and consortium stewardship notices; platform title and licensing instruments remain unverified. Internal record; owner-confirmed, counsel review pending. 5. Nexus Documentation Standard, draft of 16 October 2026: status, naming, external frameworks and sovereignty wording. Internal editorial standard; not published. 6. United Nations Office for Disaster Risk Reduction (2015). *Sendai Framework for Disaster Risk Reduction 2015-2030*. [preventionweb.net](https://www.preventionweb.net/files/43291_sendaiframeworkfordrren.pdf). Accessed 2026-10-16. 7. United Nations General Assembly (2015-06-03). *Resolution 69/283, Sendai Framework for Disaster Risk Reduction 2015-2030*. [docs.un.org](https://docs.un.org/en/A/RES/69/283). Accessed 2026-10-16. 8. Intergovernmental Panel on Climate Change (2023). *AR6 Synthesis Report: Climate Change 2023*. [ipcc.ch](https://www.ipcc.ch/report/ar6/syr/). Accessed 2026-10-16. 9. United Nations Office for Disaster Risk Reduction. *Global Assessment Report on Disaster Risk Reduction* (series). [undrr.org](https://www.undrr.org/gar). Accessed 2026-10-16. 10. United Nations General Assembly (2015-09-25). *Resolution 70/1, Transforming our world: the 2030 Agenda for Sustainable Development*. [docs.un.org](https://docs.un.org/en/A/RES/70/1). Accessed 2026-10-16. 11. Nexus constitutional directive D-V3-0005, *Product truth, claims and evidence*, and the claim register (release hold and observed bindings). Internal record, cited by identifier. 12. GCRI. *How Nexus works*: the six pillars, the eighteen handoffs and the eight-step cycle. [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Accessed 2026-10-21. 13. GCRI. *GCRI, GRF and GRA* (roles, boundaries and decision rights). [therisk.global/consortium/institutions](https://therisk.global/consortium/institutions/). Accessed 2026-10-21. 14. GCRI. *How Nexus Consortium works*, with the National Nexus pages on the NNC, NLC and NWG (the Nexus Consortium model as published). [therisk.global/consortium](https://therisk.global/consortium/). Accessed 2026-10-21. 15. Nexus Standards. *Governance*: the Global Standards Council, technical committees, National Standards Councils and the secretariat. [nexustandards.com/governance](https://nexustandards.com/governance/). Accessed 2026-10-21. 16. GCRI. *Programme status* (programme states and service levels; current level R0). [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Accessed 2026-10-21. 17. Pescaroli, G. and Alexander, D. (2018). Understanding compound, interconnected, interacting, and cascading risks: a holistic framework. *Risk Analysis* 38(11): 2245–2257. [doi:10.1111/risa.13128](https://doi.org/10.1111/risa.13128). 18. UN General Assembly (2015). *Sendai Framework for Disaster Risk Reduction 2015–2030*. A/RES/69/283. [undrr.org](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030). 19. OECD (2014). *Recommendation of the Council on the Governance of Critical Risks*. OECD/LEGAL/0405. [legalinstruments.oecd.org](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405). ## Editorial record * As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted. Human review: pending; no named reviewer or approver yet. * Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits. * Change log: 2026-10-16 r1, upgraded to the documentation standard draft. Added the Record block, status note and In brief; removed the empty "Part I" heading and fixed heading levels; replaced absolute self-links with relative links; renamed "Operation" to "Operations"; replaced "common civilizational function", "sovereign-grade", "Sovereign Compute" as a product and "north-star" wording; recast present-tense capability statements as design; added the meanings of "Nexus", sourced international context, One Rail-Two Stacks, register-based institutional summary, the twenty systems, a status table, the concept-to-system crosswalk figure, sovereignty and data rules, boundaries, key terms and sources. 2026-10-16 r2, readable document record and status note; Nexus Standards system codes; Nexus Standards system naming and Nexus Observatory Protocol naming; company references removed; plain-language sources. 2026-10-21 r3, aligned with the latest sources: Where this fits line and current-model note added; institutional roles, standards governance (no standards foundation or protocol authority as an institution), councils (six [Helix councils](/organization/governance-in-operation/councils.md), CERTs), National Nexus and the finance boundary corrected against the Nexus model, the Nexus Consortium model and the Nexus Standards governance; retired labels mapped to successors; sources extended with the public site pages, Nexus Standards identifiers and international frameworks. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/introduction/knowledge/i.-system-overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.