> 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-por.md). # NXS-POR NXS-POR, the public, citizen, client, regulator, partner and developer delivery 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-POR** is one of the twenty systems of the Nexus ecosystem: the public, citizen, client, regulator, partner and developer delivery 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 Portals`. ## Purpose and context External delivery, publication reachability and audience experience surfaces. Its domain is public, partner, client and developer projections and controlled delivery. A typical setting is a public-risk information portal with restricted partner products and correction workflows. ## 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-POR: external delivery. | Record | What the system must keep | | ------------------ | --------------------------------------------------------------------- | | audience profile | Do not confuse audience selection with authorization. | | publication source | Retain report/data version and source rights. | | disclosure profile | Apply field-level minimization, embargo and jurisdiction constraints. | | channel | Record availability, credentials reference and delivery semantics. | | correction policy | Preserve withdrawal, replacement and recipient notification history. | ## 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 | | Audiences | Specialist | Records: audience profile, product projection rule, subscription binding, projection preview, audience release binding | | Publishing | Specialist | Records: publication package, publication approval, publication schedule, publication attempt, publication correction | **Kinds of work it carries:** Publications; Delivery products; Public Portal; Client Portal; Partner Portal; Regulator Portal; Developer Portal; Applied-domain PORT; Open-data release programmes; Statutory and annual report programmes; Public portals; Citizen service portals; Client portals; Partner portals; Regulator portals; Applied-domain portals (PORTs); Developer portals; API product programmes; Product release channels; Submission intake programmes; Public consultations; Notification services; Feedback and satisfaction programmes; Accessibility conformance programmes; Plain-language programmes; Corrections and withdrawal programmes; Audience reach 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 | Public, citizen, client, regulator, partner and developer delivery | | 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-S19](https://nexustandards.com/standards/nrs/#nrs-s19): NXS-POR (Public, client and partner delivery) (status OPEN) | | Nexus Risk Standards that apply | 13 in 9 series: ai-native: [NRS-A7](https://nexustandards.com/standards/nrs/#nrs-a7); core: [NRS-C12](https://nexustandards.com/standards/nrs/#nrs-c12); development: [NRS-D2](https://nexustandards.com/standards/nrs/#nrs-d2), [NRS-D7](https://nexustandards.com/standards/nrs/#nrs-d7), [NRS-D10](https://nexustandards.com/standards/nrs/#nrs-d10); programme: [NRS-E2](https://nexustandards.com/standards/nrs/#nrs-e2), [NRS-E4](https://nexustandards.com/standards/nrs/#nrs-e4); intelligence: [NRS-I2](https://nexustandards.com/standards/nrs/#nrs-i2), [NRS-I5](https://nexustandards.com/standards/nrs/#nrs-i5); policy: [NRS-P11](https://nexustandards.com/standards/nrs/#nrs-p11); system: [NRS-S19](https://nexustandards.com/standards/nrs/#nrs-s19); technology: [NRS-T13](https://nexustandards.com/standards/nrs/#nrs-t13); cross-cutting: [NRS-X7](https://nexustandards.com/standards/nrs/#nrs-x7) | | Nexus Reports technology streams | None | ## 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-APP](/organization/systems/nxs-app.md) | external application projection | | [NXS-NSF](/organization/systems/nxs-nsf.md) | public-safe release decision | | [NXS-GRX](/organization/systems/nxs-grx.md) | public-safe product derivative; correction and supersession propagation | | the evidence fabric | public evidence/claim projection | | the estate and tenancy fabric | client/partner account context | | [NXS-HUB](/organization/systems/nxs-hub.md) | published knowledge content | ## 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-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: global identity root (the UNI identifier fabric); 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 | | ----------------------------------------------------- | ----------- | --------------------------------------------------------- | | [Country reports](/organization/systems/areas.md) | Research | Quarterly and annual reports with open methods | | [Sustainable finance](/organization/systems/areas.md) | Finance | Disclosure, taxonomies and resilience investment evidence | | [Capital resilience](/organization/systems/areas.md) | Finance | Long-horizon evidence for pensions and public funds | | [Climate adaptation](/organization/systems/areas.md) | Policy | Adaptation planning, finance and progress tracking | | [Country programmes](/organization/systems/areas.md) | Development | Nationally owned programmes across fifteen hubs | ## 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 | | -------------------------------------------------------------------------- | -------------------------------------------------------------- | ---- | --------------------------------------------- | | 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 | | IFRS S1 and IFRS S2 Sustainability and climate-related disclosures | International Sustainability Standards Board (ISSB) | 2023 | Global baseline for disclosure | | Recommendations of the Taskforce on Nature-related Financial Disclosures | Taskforce on Nature-related Financial Disclosures (TNFD) | 2023 | Nature-related risk disclosure | | Taxonomy Regulation, Regulation (EU) 2020/852 | European Union | 2020 | Classification of sustainable activities | | Recommendations of the Task Force on Climate-related Financial Disclosures | Financial Stability Board (FSB) | 2017 | Foundation of climate disclosure | | Principles for Responsible Investment | PRI, with UNEP FI and the UN Global Compact | 2006 | Incorporating material risks | | Santiago Principles | International Forum of Sovereign Wealth Funds (IFSWF) | 2008 | Governance of sovereign funds | | G20/OECD Principles of Corporate Governance | OECD | 2023 | Board oversight of sustainability risks | | Paris Agreement, Article 7 | United Nations Framework Convention on Climate Change (UNFCCC) | 2015 | Global goal on adaptation | | UAE Framework for Global Climate Resilience | UNFCCC, COP28 | 2023 | Targets for adaptation progress | | National Adaptation Plan process (Cancun Adaptation Framework) | UNFCCC | 2010 | Planning process for adaptation | | Paris Declaration on Aid Effectiveness | OECD Development Assistance Committee | 2005 | Country ownership | | Busan Partnership for Effective Development Co-operation | Fourth High Level Forum on Aid Effectiveness | 2011 | Use of country systems | | UN Sustainable Development Cooperation Framework guidance | United Nations Sustainable Development Group | 2019 | Alignment with UN country planning | ## In the programme | Pillar | Room | What happens there | | --------------------------------------------------- | ---------- | ------------------------------------- | | [Nexus Reports](/organization/programme/reports.md) | Publishing | Public release and accessible formats | ## 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: * Hub workspaces/knowledge/editorial authority * Apps runtime install/deploy * NXS-NSF identity/public-safe approval creation * Studio visual composition * Factory production builds * Labs research execution * UNI registry authority **Method boundary.** Audience analytics need clear denominators, privacy limits and exclusion handling. A reachable URL does not prove intended audience receipt, comprehension or official endorsement. Do not assume a technically reachable audience is authorized to receive all source fields. [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-por.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.