> 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-rls.md). # NXS-RLS NXS-RLS, the participants, agreements, protocols, obligations and lawful handoffs 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-RLS** is one of the twenty systems of the Nexus ecosystem: the participants, agreements, protocols, obligations and lawful handoffs 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 Rails`. ## Purpose and context Protocol-governed multi-App orchestration. Its domain is participants, agreements, obligations, protocol handoffs and receipts. A typical setting is an inter-institutional evidence handoff with conditional acceptance and disputed obligations. ## What it is the authority for It is the single owner of these fact families; any other system that needs them reads them from NXS-RLS: regulated protocol state. | Record | What the system must keep | | ---------------- | ------------------------------------------------------------------------------------- | | agreement | Bind effective conditions and relevant clauses. | | obligation | Distinguish due, satisfied, disputed, waived and unknown under applicable rules. | | handoff envelope | Preserve sender/recipient, rights, digest and purpose. | | receipt evidence | Separate local preparation, delivery acknowledgement, acceptance and external effect. | ## 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 | | Obligations | Specialist | Records: obligation, obligation dependency, performance submission, fulfillment assessment, exception or dispute | | Handoffs | Specialist | Records: protocol profile, handoff envelope, transport attempt, handoff receipt, handoff correction | **Kinds of work it carries:** Protocol rails; Conformance programmes; Protocol Readiness; Handoff Package; Transaction Receipt; Obligation Posture; Dispute Record; Data-sharing networks; Verifiable credential networks; Messaging standard migrations; Protocol readiness assessments; Conformance portfolios; Participant onboarding programmes; Obligation programmes; Service level agreements; Consortium and partnership agreements; Regulatory reporting obligations; Lawful handoff programmes; Transaction receipt ledgers; Settlement reference programmes; Electronic trade document programmes; Supply-chain coordination rails; Dispute cases; Exception and reconciliation 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 | Participants, agreements, protocols, obligations and lawful handoffs | | 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-S18](https://nexustandards.com/standards/nrs/#nrs-s18): NXS-RLS (Participants, agreements and handoffs) (status OPEN) | | Nexus Risk Standards that apply | 13 in 6 series: programme: [NRS-E5](https://nexustandards.com/standards/nrs/#nrs-e5), [NRS-E7](https://nexustandards.com/standards/nrs/#nrs-e7); finance: [NRS-F6](https://nexustandards.com/standards/nrs/#nrs-f6), [NRS-F8](https://nexustandards.com/standards/nrs/#nrs-f8), [NRS-F9](https://nexustandards.com/standards/nrs/#nrs-f9); policy: [NRS-P3](https://nexustandards.com/standards/nrs/#nrs-p3), [NRS-P7](https://nexustandards.com/standards/nrs/#nrs-p7), [NRS-P9](https://nexustandards.com/standards/nrs/#nrs-p9), [NRS-P10](https://nexustandards.com/standards/nrs/#nrs-p10); system: [NRS-S18](https://nexustandards.com/standards/nrs/#nrs-s18); technology: [NRS-T7](https://nexustandards.com/standards/nrs/#nrs-t7), [NRS-T15](https://nexustandards.com/standards/nrs/#nrs-t15); cross-cutting: [NRS-X4](https://nexustandards.com/standards/nrs/#nrs-x4) | | Nexus Reports technology streams | ZTA Digital identity and trust | ## Inputs What it receives, and from whom. Each interface carries its context (estate, tenant, workspace, purpose, jurisdiction, time and place) and is checked under the policy authority. | From | What it receives | | ------------------------------------------- | ------------------------------ | | [NXS-CMD](/organization/systems/nxs-cmd.md) | authorized handoff preparation | ## 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 | | ------------------------------------------- | --------------------------------------- | | external authorities | lawful external action handoff | | [NXS-NSF](/organization/systems/nxs-nsf.md) | authorization/policy evaluation request | | the evidence fabric | append consequential receipt/evidence | ## Interfaces with other systems Beyond its interfaces, it relies on fact families owned elsewhere: policy authority ([NXS-NSF](/organization/systems/nxs-nsf.md)); consent authority ([NXS-NSF](/organization/systems/nxs-nsf.md)); delegation authority ([NXS-NSF](/organization/systems/nxs-nsf.md)). ## Areas it serves | Area | Category | What the area covers | | ---------------------------------------------------------- | ----------- | ----------------------------------------------------- | | [Business continuity](/organization/systems/areas.md) | Management | Keep essential services running through disruption | | [Country reports](/organization/systems/areas.md) | Research | Quarterly and annual reports with open methods | | [Disaster finance](/organization/systems/areas.md) | Finance | Pre-arranged finance and contingent liabilities | | [Insurance resilience](/organization/systems/areas.md) | Finance | Protection gaps and risk transfer questions | | [Cross-border cooperation](/organization/systems/areas.md) | Policy | Shared rivers, grids, ports and supply corridors | | [Development finance](/organization/systems/areas.md) | Development | Resilience project preparation with development banks | ## 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 | | FAIR Guiding Principles | Wilkinson et al., Scientific Data | 2016 | Findable, accessible, interoperable, reusable | | Fundamental Principles of Official Statistics | United Nations General Assembly resolution 68/261 | 2014 | Integrity of official statistics | | Retraction Guidelines | Committee on Publication Ethics (COPE) | 2019 | Correction and retraction practice | | G20/OECD Framework on Disaster Risk Assessment and Risk Financing | G20 and OECD | 2012 | Government approach to risk financing | | Global Shield against Climate Risks | V20 group and G7 | 2022 | Pre-arranged finance for vulnerable countries | | Sendai Framework 2015-2030, Priority 3 | UNDRR | 2015 | Investing in disaster risk reduction | | Insurance Core Principles | International Association of Insurance Supervisors (IAIS) | 2019 | Supervisory context for insurance markets | | Application Paper on the Supervision of Climate-related Risks in the Insurance Sector | IAIS | 2021 | Climate risk in insurance supervision | | Insurance Development Forum | Public-private partnership of insurers and international organisations | 2015 | Comparator for protection-gap collaboration | | 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 | | Environmental and Social Framework | World Bank | 2018 | Safeguards and stakeholder engagement | | Performance Standards on Environmental and Social Sustainability | International Finance Corporation (IFC) | 2012 | Private-sector project standards | | Equator Principles 4 | Equator Principles Association | 2020 | Project-finance risk management | ## 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: * portals (Portals/Hub) * app runtime (Apps) * payment execution (external) * labs research authority (Labs) **Method boundary.** Receipt verification establishes bounded event evidence. Delivery is not acceptance, and acceptance is not settlement. Temporal obligations must include calendars, time zones and conditions. Do not collapse delivered, acknowledged, accepted, executed and observed outcome. [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-rls.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.