> 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/systems/nxs-net.md). # NXS-NET NXS-NET, the network topology, connectivity and communications continuity system of the Nexus ecosystem: purpose, rooms, inputs and outputs, areas, standards and boundaries. {% hint style="info" %} This page is generated from the twenty-system charters, the system profiles, the interface and authority registers, the room register, the areas of work, the systems article of the constitution set and the programme spine. Do not edit it in GitBook: change the source and export again. {% endhint %} **NXS-NET** is one of the twenty systems of the Nexus ecosystem: the network topology, connectivity and communications continuity system. It is described here as a system of the ecosystem, with its purpose, its rooms, what it receives and provides, the areas it serves, the standards that apply and its boundaries. Earlier pages may use the retired name `Nexus Network Fabric`. ## Purpose and context Network topology and connectivity readiness records. Its domain is network topology, connectivity, service intent and communications resilience. A typical setting is an edge-site and mission communications network with alternate links. ## What it is the authority for | Record | What the system must keep | | ------------------- | -------------------------------------------------------------------------- | | network | Resolve authorized network and service boundaries. | | link observation | Preserve latency, loss, capacity and collection method. | | service intent | Distinguish reachability, bandwidth, delay, MTU and security requirements. | | failure domain refs | Record common power, carrier or physical-path dependencies. | | change window | Bind maintenance and rollback conditions before applying a route change. | ## Rooms and areas of work Every system has ten rooms: eight shared rooms, which work the same way across systems with this system's domain, and two specialist rooms. | Room | Kind | Purpose | | ---------- | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | Station | Shared | The system's home: posture of the system's own records, freshness, refusals and next actions; never a summary of another system's truth | | Mission | Shared | Mission and task work for the system's domain, linked to Universe missions and Project OS plans | | Builder | Shared | Composition of the system's artifacts and configurations from admitted packages (NXS-STU, NXS-FAC and NXS-NXQ boundaries apply) | | Maps | Shared | Spatial views of the system's records and NXS-GRX products, under the boundary licence gate | | Data | Shared | The system's datasets, sources and lineage as NXS-GRX products or system-owned records | | Commons | Shared | Shared methods, standards, templates and reusable artifacts, including Nexus Standards (NXS, a programme of the Nexus Consortium) participation | | Reports | Shared | Reports and editions built from the system's evidence, with cutoffs and correction history | | Knowledge | Shared | Institutional knowledge, records, runbooks and learning linked to NXS-HUB | | Topology | Specialist | Records: network topology version, network link, service intent, path assessment, network change plan | | Continuity | Specialist | Records: continuity plan, disruption case, continuity exercise, failover operation, restoration assessment | **Kinds of work it carries:** Network estates; Coverage plans; Network Topology; Connectivity Posture; Path Assessment; Communications Continuity Product; Service Health; Campus and site networks; Branch WAN estates; Utility operational telecom networks; Network topology inventories; Link corridors; International capacity dependencies; Satellite terminal fleets; Path diversity reviews; Coverage programmes; Rural connectivity programmes; School and clinic connectivity programmes; Public Wi-Fi networks; Communications continuity plans; Emergency telecoms networks; Critical site connectivity watches; Network hazard exposures; Service health desks; Connectivity posture boards; Traffic engineering programmes; Carrier SLA assurances; Route origin hygiene programmes. **This system in the Nexus model.** Generated from the Nexus Standards index and the programme spine; statuses are registry statuses, never adoption or certification. | | | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Descriptor | Network topology, connectivity and communications continuity | | In the programme | Built, simulated and prepared in the [Foundry pillar](/organization/programme/foundry.md); its records serve the other pillars through the handoffs of [the programme year](/organization/programme/the-programme-year.md), and the competent authority decides outside the programme. | | System profile | [NRS-S10](https://nexustandards.com/standards/nrs/#nrs-s10): NXS-NET (Network topology and continuity) (status OPEN) | | Nexus Risk Standards that apply | 8 in 4 series: nexus-stream: [NRS-N2](https://nexustandards.com/standards/nrs/#nrs-n2), [NRS-N6](https://nexustandards.com/standards/nrs/#nrs-n6); system: [NRS-S10](https://nexustandards.com/standards/nrs/#nrs-s10); technology: [NRS-T2](https://nexustandards.com/standards/nrs/#nrs-t2), [NRS-T14](https://nexustandards.com/standards/nrs/#nrs-t14); cross-cutting: [NRS-X6](https://nexustandards.com/standards/nrs/#nrs-x6), [NRS-X8](https://nexustandards.com/standards/nrs/#nrs-x8), [NRS-X11](https://nexustandards.com/standards/nrs/#nrs-x11) | | Nexus Reports technology streams | CMP Advanced and sovereign compute | ## Outputs What it provides, and to whom. Consumers read projections; the system stays the authority for its own records and their corrections. | To | What it provides | | ------------------------------------------- | ----------------------------------------- | | [NXS-GRX](/organization/systems/nxs-grx.md) | network topology and service observations | | [NXS-NST](/organization/systems/nxs-nst.md) | communications continuity | | [NXS-NSF](/organization/systems/nxs-nsf.md) | authorization/policy evaluation request | | the evidence fabric | append consequential receipt/evidence | ## Areas it serves | Area | Category | What the area covers | | ----------------------------------------------------------- | ---------- | ------------------------------------------------------ | | [Business continuity](/organization/systems/areas.md) | Management | Keep essential services running through disruption | | [Crisis management](/organization/systems/areas.md) | Management | Decision-making and coordination when events escalate | | [Systemic risk](/organization/systems/areas.md) | Research | Cascades and interdependencies across critical systems | | [Infrastructure resilience](/organization/systems/areas.md) | Technology | Energy, water, transport and essential services | | [Cyber resilience](/organization/systems/areas.md) | Technology | Cyber risk to essential services and public systems | | [Shared computing](/organization/systems/areas.md) | Technology | High-performance computing for annual missions | | [Cross-border cooperation](/organization/systems/areas.md) | Policy | Shared rivers, grids, ports and supply corridors | ## Standards that apply Every record of the system is identified through the UNI identifier fabric of Nexus Standards (NS-1), and its public name follows the Nexus Standards naming rules. The areas it serves reference these external standards; naming a standard records where it is referenced and is not a claim of certification, accreditation, conformance or endorsement. | Standard | Issuer | Year | Use | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------- | ---- | ----------------------------------------------------------- | | ISO 22301 Business continuity management systems, Requirements | ISO | 2019 | Management-system requirements | | ISO 22313 Business continuity management systems, Guidance | ISO | 2020 | Practical guidance for implementation | | Principles for Operational Resilience | Basel Committee on Banking Supervision (BCBS) | 2021 | Operational resilience for banks | | Digital Operational Resilience Act, Regulation (EU) 2022/2554 | European Union | 2022 | ICT resilience for EU financial entities, applied from 2025 | | ISO 22361 Security and resilience, Crisis management, Guidelines | ISO | 2022 | Crisis capability and decision-making | | ISO 22320 Emergency management, Guidelines for incident management | ISO | 2018 | Incident command and coordination | | National Incident Management System, third edition | United States Federal Emergency Management Agency (FEMA) | 2017 | Comparator for scalable incident structures | | Global Assessment Report on Disaster Risk Reduction 2019 | UNDRR | 2019 | Systemic risk framing | | Guidelines for the Governance of Systemic Risks | International Risk Governance Center (IRGC) | 2018 | Governance of systemic risks | | Recommendation on the Governance of Critical Risks | OECD | 2014 | Interdependency in national risk policy | | Principles for Resilient Infrastructure | UNDRR | 2022 | Six principles for resilient systems | | ISO 37123 Indicators for resilient cities | ISO | 2019 | Measuring urban resilience | | IEC 62443 Industrial communication networks, security | IEC | 2018 | Security of control systems | | Cybersecurity Framework 2.0 | United States National Institute of Standards and Technology (NIST) | 2024 | Govern, identify, protect, detect, respond, recover | | ISO/IEC 27001 Information security management systems | ISO/IEC | 2022 | Security management requirements | | NIS2 Directive, Directive (EU) 2022/2555 | European Union | 2022 | Obligations for essential entities in the EU | | NIST SP 800-88 Revision 2, Guidelines for Media Sanitization | NIST | 2025 | Sanitisation and validation | | EuroHPC Joint Undertaking access process | European High Performance Computing Joint Undertaking | 2018 | Comparator for review-based allocation | | Convention on the Protection and Use of Transboundary Watercourses and International Lakes | UNECE, open globally since 2016 | 1992 | Cooperation on shared waters | | Convention on the Law of the Non-navigational Uses of International Watercourses | United Nations | 1997 | Principles for shared rivers | | Trade Facilitation Agreement | World Trade Organization (WTO) | 2017 | Border procedures for corridors | ## In the programme | Pillar | Room | What happens there | | ----------------------------------------------------- | ---------- | ------------------------------------------ | | [Nexus Universe](/organization/programme/universe.md) | Continuity | Temporary capacity, stand-down and release | ## Governance boundaries Policy authority for the system sits with [NXS-NSF](/organization/systems/nxs-nsf.md); identifiers come from the UNI identifier fabric. The system exports read projections and commands through typed contracts, and no other system writes its records. It does not own, and never stands in for: * signal integrity / RF quality (NXS-SIG) * compute workloads (NXS-NXS-COR) * live traffic steering / carrier provisioning execution **Method boundary.** Reliability calculations must model shared-risk groups and measurement windows. Reachability alone does not establish acceptable performance; simulated failover must be verified against authorized observed topology. Do not treat a simulated alternate route as a tested communications failover. [All twenty systems](/organization/systems.md) ยท [Areas](/organization/systems/areas.md) *** *Generated page. It records names, roles and design for reading, not readiness: release is on hold, and nothing here is presented as ready, certified or official.* --- # 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/systems/nxs-net.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.