> 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-nsf.md). # NXS-NSF NXS-NSF, the trust, authorization, mandate, policy and assurance 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-NSF** is one of the twenty systems of the Nexus ecosystem: the trust, authorization, mandate, policy and assurance 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. ## Purpose and context Trust spine: policy gates, identity, access, proofs, privacy and conformance review. Single writer of consent, delegation, mandate/capacity, sovereignty, disclosure/reliance, assurance and decision-receipt records (ADR 0137); other systems are command producers and read through NXS-NSF. Trust root and key policy: key registry, custody/log/witness policy by classification, rotation, revocation, compromise handling and the SigningRootDecision receipt (ADR 0138). Key material stays in KMS/HSM in the sovereignty cell. Its domain is mandates, purpose, sovereignty, policy decisions and assurance. A typical setting is a cross-jurisdictional project with delegated access and restricted evidence. ## 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-NSF: policy authority; consent authority; delegation authority; trust root and key custody. | Record | What the system must keep | | ----------------------- | ---------------------------------------------------------------------- | | mandate | Bind grantor, delegate, purpose, jurisdiction and expiry. | | policy bundle | Retain source instruments and decision-engine compatibility. | | data handling | Separate classification, residency, consent and disclosure conditions. | | assurance evidence refs | Track freshness, assessor authority and correction history. | | revocation epoch | Invalidate dependent decisions and cached grants on revocation. | ## 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 | | Authority | Specialist | Records: authority source binding, delegation, policy bundle version, authorization decision record, revocation case | | Assurance | Specialist | Records: assurance case, control assessment, evidence assessment, finding, assurance disposition | **Kinds of work it carries:** Assurance cases; Sovereignty reviews; Authorization Decision; Policy Bundle; Sovereignty Decision; Public-Safe Decision; Assurance Posture; AI system assurance; Continuity assurance; Data residency programmes; Cross-border data sharing agreements; Policy compliance portfolios; Policy bundle rollouts; Access authorization models; Mandate & delegation registers; Public release gates; Privacy impact assessments; Consent programmes; Correction workflows; Supplier reliance reviews; External audit readiness; Cyber resilience obligations. **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 | Trust, authorization, mandate, policy and assurance | | 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-S13](https://nexustandards.com/standards/nrs/#nrs-s13): NXS-NSF (Trust, authorization and assurance) (status OPEN) | | Nexus Risk Standards that apply | 24 in 7 series: ai-native: [NRS-A1](https://nexustandards.com/standards/nrs/#nrs-a1), [NRS-A2](https://nexustandards.com/standards/nrs/#nrs-a2), [NRS-A3](https://nexustandards.com/standards/nrs/#nrs-a3), [NRS-A4](https://nexustandards.com/standards/nrs/#nrs-a4), [NRS-A5](https://nexustandards.com/standards/nrs/#nrs-a5); core: [NRS-C1](https://nexustandards.com/standards/nrs/#nrs-c1), [NRS-C4](https://nexustandards.com/standards/nrs/#nrs-c4), [NRS-C8](https://nexustandards.com/standards/nrs/#nrs-c8), [NRS-C10](https://nexustandards.com/standards/nrs/#nrs-c10), [NRS-C11](https://nexustandards.com/standards/nrs/#nrs-c11); programme: [NRS-E3](https://nexustandards.com/standards/nrs/#nrs-e3), [NRS-E6](https://nexustandards.com/standards/nrs/#nrs-e6); policy: [NRS-P3](https://nexustandards.com/standards/nrs/#nrs-p3), [NRS-P5](https://nexustandards.com/standards/nrs/#nrs-p5), [NRS-P6](https://nexustandards.com/standards/nrs/#nrs-p6), [NRS-P9](https://nexustandards.com/standards/nrs/#nrs-p9), [NRS-P10](https://nexustandards.com/standards/nrs/#nrs-p10); system: [NRS-S0](https://nexustandards.com/standards/nrs/#nrs-s0), [NRS-S13](https://nexustandards.com/standards/nrs/#nrs-s13); technology: [NRS-T1](https://nexustandards.com/standards/nrs/#nrs-t1), [NRS-T7](https://nexustandards.com/standards/nrs/#nrs-t7), [NRS-T9](https://nexustandards.com/standards/nrs/#nrs-t9), [NRS-T16](https://nexustandards.com/standards/nrs/#nrs-t16); cross-cutting: [NRS-X6](https://nexustandards.com/standards/nrs/#nrs-x6) | | Nexus Reports technology streams | AIS AI and foundation models; 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 | | ------------------------------------------- | --------------------------------------- | | the estate and tenancy fabric | estate and entitlement context | | [NXS-CMD](/organization/systems/nxs-cmd.md) | authorization/policy evaluation request | | [NXS-NST](/organization/systems/nxs-nst.md) | authorization/policy evaluation request | | [NXS-DSS](/organization/systems/nxs-dss.md) | authorization/policy evaluation request | | [NXS-COR](/organization/systems/nxs-cor.md) | authorization/policy evaluation request | | [NXS-NXQ](/organization/systems/nxs-nxq.md) | authorization/policy evaluation request | | [NXS-GRX](/organization/systems/nxs-grx.md) | authorization/policy evaluation request | | [NXS-EOP](/organization/systems/nxs-eop.md) | authorization/policy evaluation request | | [NXS-EWS](/organization/systems/nxs-ews.md) | authorization/policy evaluation request | | [NXS-AAP](/organization/systems/nxs-aap.md) | authorization/policy evaluation request | | [NXS-NET](/organization/systems/nxs-net.md) | authorization/policy evaluation request | | [NXS-OPS](/organization/systems/nxs-ops.md) | authorization/policy evaluation request | | [NXS-SIG](/organization/systems/nxs-sig.md) | authorization/policy evaluation request | | [NXS-HUB](/organization/systems/nxs-hub.md) | authorization/policy evaluation request | | [NXS-STU](/organization/systems/nxs-stu.md) | authorization/policy evaluation request | | [NXS-FAC](/organization/systems/nxs-fac.md) | authorization/policy evaluation request | | [NXS-APP](/organization/systems/nxs-app.md) | authorization/policy evaluation request | | [NXS-RLS](/organization/systems/nxs-rls.md) | authorization/policy evaluation request | | [NXS-POR](/organization/systems/nxs-por.md) | authorization/policy evaluation request | | [NXS-LAB](/organization/systems/nxs-lab.md) | authorization/policy evaluation request | ## 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-COR](/organization/systems/nxs-cor.md) | placement and runtime obligations | | [NXS-POR](/organization/systems/nxs-por.md) | public-safe release decision | | the evidence fabric | append consequential receipt/evidence | ## Interfaces with other systems Beyond its interfaces, it relies on fact families owned elsewhere: tenancy account root (the estate and tenancy fabric); global identity root (the UNI identifier fabric); external delivery ([NXS-POR](/organization/systems/nxs-por.md)); regulated protocol state ([NXS-RLS](/organization/systems/nxs-rls.md)); runtime authority spine (the runtime authority spine). ## Areas it serves | Area | Category | What the area covers | | ---------------------------------------------------------- | ---------- | ----------------------------------------------------------- | | [Enterprise risk](/organization/systems/areas.md) | Management | Risk governance, appetite and oversight across institutions | | [Cyber resilience](/organization/systems/areas.md) | Technology | Cyber risk to essential services and public systems | | [Sovereign AI](/organization/systems/areas.md) | Technology | National data environments and responsible AI | | [Cross-border cooperation](/organization/systems/areas.md) | Policy | Shared rivers, grids, ports and supply corridors | | [Digital governance](/organization/systems/areas.md) | Policy | AI, data and digital public infrastructure policy | ## 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 31000 Risk management, Guidelines | International Organization for Standardization (ISO) | 2018 | Principles, framework and process | | Enterprise Risk Management, Integrating with Strategy and Performance | Committee of Sponsoring Organizations of the Treadway Commission (COSO) | 2017 | Linking risk appetite to strategy and performance | | Recommendation on the Governance of Critical Risks | Organisation for Economic Co-operation and Development (OECD) | 2014 | Whole-of-government governance of critical risks | | Sendai Framework for Disaster Risk Reduction 2015-2030, Priority 2 | United Nations Office for Disaster Risk Reduction (UNDRR) | 2015 | Strengthening disaster risk governance | | 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 | | ISO/IEC 42001 Artificial intelligence management system | ISO/IEC | 2023 | Management system for responsible AI | | AI Risk Management Framework 1.0 | NIST | 2023 | Govern, map, measure and manage | | Artificial Intelligence Act, Regulation (EU) 2024/1689 | European Union | 2024 | Risk-based obligations where it applies | | Recommendation on the Ethics of Artificial Intelligence | United Nations Educational, Scientific and Cultural Organization (UNESCO) | 2021 | Human rights and ethics baseline | | 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 | | Global Digital Compact | United Nations General Assembly | 2024 | Shared principles for digital cooperation | | Framework Convention on Artificial Intelligence and Human Rights, Democracy and the Rule of Law | Council of Europe | 2024 | Binding AI treaty framework | | OECD AI Principles, updated | OECD | 2024 | Trustworthy AI principles | | General Data Protection Regulation, Regulation (EU) 2016/679 | European Union | 2016 | Data protection benchmark | ## In the programme | Pillar | Room | What happens there | | ------------------------------------------------------- | --------- | ---------------------------------------------------- | | [Nexus Standards](/organization/programme/standards.md) | Assurance | Routing, validation, monitoring and adoption engines | | [Nexus Standards](/organization/programme/standards.md) | Authority | Mandates for adoption and change decisions | | [Nexus Standards](/organization/programme/standards.md) | Commons | The Nexus Standards commons and the UNI catalogue | | [Risk Academy](/organization/programme/academy.md) | Authority | Issuer keys and credential status | ## 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: * parallel consent or delegation stores in other systems (producers keep projections only) * holding private key material in application code * legal authority (external) * autonomous enforcement (prohibited) * court orders / prosecution (prohibited) * observatory lifecycle ownership (NXS-OPS) * network topology (NXS-NET) * signal quality (NXS-SIG) **Method boundary.** Policy evaluation is an adjudicable rule process, not a model-generated confidence score. A mandatory failed control cannot be averaged away; deny, unknown and unavailable must remain distinct. Do not mint a mandate, assurance certification or runtime authorization from a normative draft. [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-nsf.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.