> 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-cor.md). # NXS-COR NXS-COR, the compute, nodes, runtimes, placement and infrastructure lifecycle 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-COR** is one of the twenty systems of the Nexus ecosystem: the compute, nodes, runtimes, placement and infrastructure lifecycle 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 `NEXCORE`. ## Purpose and context Infrastructure representation and infrastructure-readiness state: compute, clusters, nodes, edge, devices, storage, images, workloads, provider adapters, capacity, diagnostics, and infrastructure Object Passports. Placement, capacity reservation and attested trust verdicts for application runtime targets, and substrate access via scoped deploy identities; provider credentials stay with NXS-NXS-COR (ADR 0141). Its domain is compute estates, edge nodes, placement and infrastructure lifecycle. A typical setting is a two-site edge-and-cloud estate with outbound-only connectivity and capped resource use. ## 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-COR: runtime placement capacity attestation. | Record | What the system must keep | | --------------------- | ------------------------------------------------------------------------------------------ | | estate | Preserve the existing landing-zone relationship and accountable owner. | | workload requirements | Require CPU architecture, accelerator, memory, storage, residency and network assumptions. | | node observation | Keep capture time, trust state and desired versus observed configuration. | | placement constraints | Reject infeasible placements before cost optimization. | | maintenance window | Preserve blackout periods, rollback constraints and offline-site conditions. | ## 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 | | Fleet | Specialist | Records: fleet node, compatibility profile, fleet change plan, enrollment receipt | | Placement | Specialist | Records: workload requirement, placement evaluation, capacity reservation, placement plan | **Kinds of work it carries:** Compute estates; Infrastructure deployments; Fleet Posture; Capacity Product; Placement Plan; Runtime Health Product; Infrastructure Evidence; On-premises Kubernetes estates; Multi-cluster fleets; Data centre facilities; Sovereign cloud regions; GPU / HPC fleets; Industrial / OT edge sites; Telco edge / MEC estates; Hospital edge compute; Satellite ground-station compute; Deployable field compute kits; Sovereign workload placement; Workload migration programmes; Cluster and site rollouts; Platform runtime SLO programmes; AI inference serving estates; Compute capacity plans; Energy and carbon-aware compute; Hardware lifecycle refreshes; Disaster recovery sites; Cyber recovery readiness; Compute site hazard resilience; Infrastructure evidence and audits; Firmware and patch campaigns; Air-gapped compute enclaves. **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 | Compute, nodes, runtimes, placement and infrastructure lifecycle | | 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-S4](https://nexustandards.com/standards/nrs/#nrs-s4): NXS-COR (Compute, nodes and runtimes) (status OPEN) | | Nexus Risk Standards that apply | 4 in 3 series: nexus-stream: [NRS-N2](https://nexustandards.com/standards/nrs/#nrs-n2); system: [NRS-S4](https://nexustandards.com/standards/nrs/#nrs-s4); technology: [NRS-T2](https://nexustandards.com/standards/nrs/#nrs-t2), [NRS-T9](https://nexustandards.com/standards/nrs/#nrs-t9) | | Nexus Reports technology streams | CMP Advanced and sovereign compute | ## 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-NXQ](/organization/systems/nxs-nxq.md) | signed workload/package placement request | | [NXS-NSF](/organization/systems/nxs-nsf.md) | placement and runtime obligations | ## 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 | | ------------------------------------------- | ------------------------------------------------------------------------ | | the evidence fabric | execution observation/attestation; append consequential receipt/evidence | | [NXS-NSF](/organization/systems/nxs-nsf.md) | authorization/policy evaluation request | ## Interfaces with other systems Beyond its interfaces, it relies on fact families owned elsewhere: application lifecycle ([NXS-APP](/organization/systems/nxs-app.md)); runtime authority spine (the runtime authority spine); capability and package registry ([NXS-NXQ](/organization/systems/nxs-nxq.md)). ## Areas it serves | Area | Category | What the area covers | | --------------------------------------------------- | ---------- | -------------------------------------------------------- | | [Climate risk](/organization/systems/areas.md) | Research | Physical climate hazards, scenarios and impacts by place | | [Sovereign AI](/organization/systems/areas.md) | Technology | National data environments and responsible AI | | [Earth observation](/organization/systems/areas.md) | Technology | Satellite and geospatial evidence for risk decisions | | [Shared computing](/organization/systems/areas.md) | Technology | High-performance computing for annual missions | | [Stress testing](/organization/systems/areas.md) | Finance | Climate, cyber and operational shocks to exposures | ## 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 | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- | ---- | ----------------------------------------- | | IPCC Sixth Assessment Report, Synthesis Report | IPCC | 2023 | Assessed climate science and risk | | Coupled Model Intercomparison Project Phase 6 (CMIP6) | World Climate Research Programme (WCRP) | 2016 | Climate model ensemble design | | Shared Socioeconomic Pathways (SSPs) | Integrated assessment research community | 2017 | Socioeconomic scenario framework | | 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 | | SpatioTemporal Asset Catalog (STAC) 1.0 | STAC community, an Open Geospatial Consortium community standard | 2021 | Searchable geospatial catalogues | | OGC API, Features, Part 1: Core | Open Geospatial Consortium (OGC) | 2019 | Web access to geospatial features | | CEOS Analysis Ready Data (CEOS-ARD) | Committee on Earth Observation Satellites (CEOS) | 2017 | Analysis-ready product specifications | | ISO/IEC 27001 Information security management systems | ISO/IEC | 2022 | Security controls for shared environments | | 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 | | Principles for the effective management and supervision of climate-related financial risks | Basel Committee on Banking Supervision (BCBS) | 2022 | Supervisory expectations for banks | | NGFS climate scenarios | Network for Greening the Financial System (NGFS) | 2020 | Common scenario framework | | Climate risk stress test | European Central Bank (ECB) | 2022 | Comparator for supervisory design | ## 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: * deploying applications or running a second deployment actuator (Apps) * app runtime ownership (Apps) * blueprint/package generation (Factory) * dashboard/map/workflow configuration (Studio) * identity, trust, privacy, verified compute governance (NXS-NSF) * portals, tickets, audience delivery (Hub) * protocol-governed multi-App orchestration (Rails) * network topology primary source (NXS-NET) * observatory protocol deployment (NXS-OPS) * signal integrity (NXS-SIG) * risk indexes (NXS-NXS-GRX) * EO processing (NXS-EOP) * warning logic (NXS-EWS) * anticipatory-action triggers (NXS-AAP) * decision modeling (NXS-DSS) **Method boundary.** Placement is constrained optimization over verified capacity and policy. Model oversubscription explicitly; a feasible simulation is not proof a node is reachable or attested. Do not allow a room worker to become an unfenced infrastructure controller. [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-cor.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.