> 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/introduction/acceleration/ii.-compute.md). # II. Compute Nexus Compute as a target design: the estate of compute, networks and lifecycle meant to carry the rail under national control, mapped to NXS-COR, NXS-NET and NXS-NSF. **Where this fits:** all six sectors · the [Foundry pillar](/organization/programme/foundry.md), with [Labs](/organization/programme/labs.md), [Nexus Universe](/organization/programme/universe.md) and [Risk Academy](/organization/programme/academy.md) · the [Nexus Consortium](/organization/institutions/nexus-consortium.md) and [National Nexus](/organization/governance-in-operation/national-nexus.md) · the Planning, Readiness preparation and Controlled build phases of [the programme year](/organization/programme/the-programme-year.md) · introduction to the deep doctrine. Canonical homes: [The Model](/organization/model.md) · [Systems](/organization/systems.md) · [Finance readiness](/organization/finance-readiness.md).
Document record · Draft · Legal review required · Updated 21 October 2026 | | | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Status** | Draft. Explanatory page; it creates no rights or obligations. | | **Legal review** | Required before final publication. | | **Version** | 2026.10.21-r3 | | **Updated** | 21 October 2026 · reviewed every 180 days | | **Owner** | Documentation desk (named reviewer pending) | | **Based on** | Nexus constitutional directives D-V3-0001 (*Master directive V3*: shared fabrics), D-V3-0003 (*Twenty-system constitution*) and D-V3-0004 (*One Rail-Two Stacks and non-execution*); the owner decision of 11 October 2026 on Nexus institutional architecture and participation, with GCRI Canada as lead contracting organization; the release hold policy, the claim register and the consortium programme offerings O03 and O09 and the [NXS-NET](/organization/systems/nxs-net.md) Network, in the Nexus institutional register; the Nexus Documentation Standard (draft of 16 October 2026); the Nexus model and the Nexus Consortium model as published on the GCRI, GRF and GRA sites; [Nexus Standards](/organization/institutions/nexus-standards.md) as published at nexustandards.com | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
{% hint style="info" %} **Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service. {% endhint %} ## In brief Nexus Compute, in this documentation, is the target design for the estate of computing, storage, networks, observation equipment, policy controls and lifecycle support meant to carry the common rail in real operating environments under national control. In the V3 constitution it corresponds mainly to [NXS-COR](/organization/systems/nxs-cor.md) (the distributed compute system for compute, providers and regions) for compute and nodes, NXS-NET (the network intelligence and communications resilience system) for connectivity, and [NXS-NSF](/organization/systems/nxs-nsf.md) (the trust, sovereignty and assurance plane for identity, policy gates and access decisions) for policy. No compute estate, dense core, regional cluster or node is recorded as installed, and a blueprint "is not an installed environment" \[1]\[4]\[5]. ## Current position (21 October 2026) This section brings the page up to date with the published sites, the Nexus Standards and the owner's rulings of October 2026. Where the older text below differs, this section and the canonical pages it links govern. **Systems, not products.** The technology this page refers to is the [twenty Nexus systems](/organization/systems.md), each named by its display code (for example NXS-COR for compute and runtimes, NXS-NET for networks, [NXS-FAC](/organization/systems/nxs-fac.md) for builds and verification, [NXS-NXQ](/organization/systems/nxs-nxq.md) for packages and capability lifecycle, [NXS-APP](/organization/systems/nxs-app.md) for the application catalogue and [NXS-RLS](/organization/systems/nxs-rls.md) for agreements and lawful handoffs). The build work is the [Foundry pillar](/organization/programme/foundry.md): "a configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision" \[23]. Technology, infrastructure and service providers work with the Nexus Consortium at arm's length under written agreements. Compute is now described as systems and as an offering, not as a product: NXS-COR holds compute, nodes, runtimes, placement and infrastructure lifecycle, NXS-NET holds network topology and communications continuity, and the Nexus Consortium offers it to countries as O03, data, compute and AI capability, under national control and subject to evidence for each deployment ([Systems](/organization/systems.md); [Use by](/organization/use-by.md)). "Sovereign" names the powers of public authorities over their own infrastructure and data; it is never an attribute of a Nexus product. The UN Universal DPI Safeguards Framework and the GovStack building blocks are the reference points for doing this safely \[24]\[25]. **Finance boundary.** National Consortium Companies and Project SPVs are structures that competent, lawful actors may form outside the programme, under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction, and readiness evidence is not a financing decision \[26]\[27]. Where this page describes such vehicles, read it with [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md) and [National portfolios](/organization/finance-readiness/national-portfolios.md). **Status.** Every programme is in formation and the current service level is R0, information and enquiries; no edition of [Nexus Reports](/organization/programme/reports.md) has been released and no [Risk Academy](/organization/institutions/risk-academy.md) credential has been issued \[28]\[29]. ## Status, scope and terms of this page **Status in the five-state grammar.** Target: defined in this documentation and, for NXS-COR, NXS-NET and NXS-NSF, by the V3 twenty-system constitution \[1]. Implemented: No record of any Nexus compute estate, dense core, regional cluster or node. Verified: No record. Observed: No record. Accepted: No record. The consortium programme describes compute work as an offering at service level R0, information and enquiries only \[5]. **"Sovereign".** Earlier versions of this page named the estate "Nexus Sovereign Compute". This documentation does not use "sovereign" as a product attribute. Main-branch wording is that the systems are "intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment" \[3]. While the release hold is active the sovereign deployment profile is blocked, together with the enterprise SaaS, on-premises, private cloud, OEM-embedded, marketplace and certified public-good profiles \[4]. "Sovereign" remains in use below only for a public authority's own powers or as design intent. **Institutions.** The institutional roles that bear on this page are stated once, in register wording, on [I. Order of the Organization introduction](/organization/introduction/organization/i.-order.md): GCRI Canada ([The Global Centre for Risk and Innovation](/organization/institutions/gcri.md)) is Lead Institution, Consortium Secretariat and lead contracting organization; [The Global Risks Forum](/organization/institutions/grf.md) (GRF) is a consortium steward for leadership, dialogue and Nexus Universe programme governance; [The Global Risks Alliance](/organization/institutions/gra.md) (GRA) is a consortium steward for the finance, insurance and development-readiness interface; and competent public authorities keep all sovereign, regulatory, fiduciary and operational decisions \[3]. Standards discipline sits with NXS-NSF, the trust, sovereignty and assurance plane for identity, policy gates and access decisions, and Nexus Standards is a proposed standards programme with no publisher of record \[1]\[9]. **Words that name systems.** [NXS-STU](/organization/systems/nxs-stu.md), the builder and configuration workspace, which composes but never deploys, is the composition system, not the runtime; execution belongs to the Universal Runtime fabric and the Polyglot Run Service \[1]\[6]. "Foundry build environments" are functions of NXS-FAC, the mission application factory, which produces app blueprints but never runs them \[1]. "Rails" in this chapter are governed deployment designs, not system 18, NXS-RLS, the technical rails and protocol infrastructure for protocol-governed work across institutions \[1]. {% hint style="info" %} **Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol system, in collaboration with [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric, and [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. Together these three systems form the observatory ecosystem. **Nexus of Observatories.** Every Nexus platform and system includes its own observatory capability, covering remote sensing, in-situ instruments and edge deployments. Across every area where these observatories are implemented, including implementation pilots in programme areas, they form the Nexus of Observatories, which is part of the not-for-profit programme architecture. On this site, "Nexus Observatory" refers only to this observatory capability and to the protocol above. {% endhint %} {% hint style="info" %} **Earlier council labels.** This page still uses some labels from earlier versions of this corpus (Investor Council and `Nexus Competence Cells`). These labels predate the current national vocabulary: National Nexus, with the [National Nexus Consortium](/organization/governance-in-operation/nnc.md) (NNC) and its six [Helix councils](/organization/governance-in-operation/councils.md), the [National Leadership Council](/organization/governance-in-operation/nlc.md) (NLC) and the [National Working Groups](/organization/governance-in-operation/nwg.md) (NWG) with their domain response teams ([Governance in operation](/organization/governance-in-operation.md)). Investor Council is a historical label whose nearest current counterpart is the Financial Institutions and Regulators pathway, led with GRA; the mapping of Competence Cells awaits owner decision ([Reference](/organization/reference.md)). Where they appear below they describe earlier design text, not current or constituted bodies \[8]\[9]. {% endhint %} ## Summary This page defines **Compute** within Nexus Acceleration. If **I. Order** explains the realization architecture of Nexus as a whole, then **II. Compute** defines the technical estate intended for national control through which that realization becomes materially possible. Nexus Compute is not generic cloud infrastructure. It is not a conventional data-center strategy. It is not a narrow edge-compute stack. It is not a hardware product. It is not a vendor platform with sovereignty language attached after the fact. Nexus Compute is a governed, systems-scale, sovereignty-compatible technical estate designed to carry the common rail across real operating environments. It provides the compute, observability, workflow, AI, communications, trust, evidence, protocol, lifecycle, and serviceability substrate through which Nexus becomes inhabitable, supportable, correctable, and operationally serious. Compute matters because Nexus cannot become real through documents alone. It needs a technical estate capable of carrying public-good standards, evidence, observability, Registry truth, protocol permissions, NXS-STU runtime, Foundry packages, Digital Public Goods, domain packs, Academy environments, Marketplace extensions, node networks, host environments, public authority learning rooms, and lawful downstream handoffs. Compute is the estate that makes the rail operational. *** ## 2.1 Why Compute Is Foundational to Acceleration Compute is foundational because Acceleration requires an operating substrate. Nexus is designed to connect evidence, observability, standards, ontology, Registry, protocol, public-safe outputs, routeability, readiness, public authority learning, Digital Public Goods, Marketplace extension, and lawful downstream implementation. None of these functions can operate reliably at scale if the technical estate is fragmented, vendor-dependent by default, semantically uncontrolled, poorly governed, or detached from the public-good architecture. Compute is where Nexus becomes technically inhabitable. It is where signals can be ingested. It is where observations can be fused. It is where NXS-STU workflows can run. It is where Foundry packages can be tested. It is where AI systems can operate under constraints. It is where role-bound permissions and entitlements can be expressed (earlier text named role keys and smart licences here; these are research outlook, not Nexus architecture). It is where evidence and proof objects can be preserved. It is where public-safe outputs can be generated. It is where node environments can remain serviceable. It is where data under national custody, local control, and host truth can be respected. Without a compute estate, Nexus remains conceptually strong but operationally thin. With a compute estate, Nexus can become a real public-good operating architecture. *** ## 2.2 What Nexus Compute Means Within Nexus, **Nexus Compute** means the governed compute-and-operations estate capable of carrying the technical life of the common rail under sovereignty-safe, evidence-bearing, standards-disciplined, and correction-capable conditions. It includes: * compute tiers; * storage and memory layers; * observatory node grids; * edge environments; * communications fabric; * AI fabric; * runtime workflow systems; * NXS-STU environments; * Foundry build environments; * evidence and proof layers; * Registry-linked status systems; * policy and trust controls; * entitlement and permission infrastructure under NXS-NSF policy (earlier text: role-key and smart-licence infrastructure, a research outlook); * public-safe publication pathways; * lifecycle, maintenance, and refresh systems; * cybersecurity and access-control systems; * degraded-mode continuity; * backup and recovery logic; * and host-specific operating configurations. Earlier text called this estate "Nexus Compute". The word "sovereign" is not used as a product attribute here: the estate is intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment, and the sovereign deployment profile is blocked while the release hold is active \[3]\[4]. This definition matters because it makes clear that Nexus Compute is an estate, not a device. A compute estate under national control is not measured only by processor capacity, storage size, cloud region, or edge footprint. It is measured by whether it can carry institutional trust, public-good discipline, evidence integrity, workflow reliability, role-bound access, data governance, lifecycle support, and sovereign compatibility under real-world conditions. *** ## 2.3 The Compute Thesis of Nexus The compute thesis of Nexus is that **a public-good-rooted, standards-bearing, sovereignty-compatible architecture can become operationally real only if its technical substrate is designed as a governed estate that integrates compute, observability, communications, AI, workflow runtime, evidence, trust, protocol, serviceability, lifecycle, and host truth as first-order conditions rather than treating them as optional implementation layers**. This thesis has several implications. Compute must carry governance. Compute must support observability. Compute must preserve evidence. Compute must support correction. Compute must respect sovereignty. Compute must be serviceable. Compute must operate under degraded conditions. Compute must express role-bound permissions. Compute must distinguish learning from adoption. Compute must distinguish decision support from lawful decision. Compute must distinguish readiness from execution. Compute must support local variation without fragmenting the common rail. In Nexus, compute is not infrastructure beneath governance. Compute is infrastructure governed by governance. *** ## 2.4 Compute as Estate, Not Appliance Nexus Compute must be understood as an estate. An appliance performs a bounded function. A platform hosts applications. A cloud region offers capacity. An edge box provides local processing. A compute estate, by contrast, carries a whole operating architecture. The estate concept is essential because Nexus needs compute to support many system functions at once: * local sensing; * data ingestion; * observability; * signal fusion; * model execution; * simulation; * NXS-STU runtime; * Foundry packaging; * public authority learning; * evidence traceability; * protocol permissions; * Registry synchronization; * Marketplace integration; * Digital Public Goods; * node operations; * host continuity; * and lawful handoff pathways. No single appliance can carry that burden. No generic platform can be assumed to carry it safely. The estate must be intentionally designed. *** ## 2.5 The Systems Family Doctrine Nexus Compute is a **systems family**, not a single canonical deployment. This is one of its most important design principles. Different environments require different embodiments. A ministry, university, public authority, utility, city, industrial site, port, hospital network, observatory grid, remote community, disaster response setting, maritime corridor, regional hub, and national dense core cannot all use the same physical and operational form. The systems family may include: * national dense cores; * regional compute clusters; * institutional compute environments; * campus nodes; * city nodes; * industrial nodes; * observatory nodes; * edge compute nodes; * mobile or deployable nodes; * backup nodes; * public authority learning nodes; * NXS-STU runtime nodes; * Foundry build environments; * corridor-integrated nodes; * host-supported nodes; * and remote or degraded-connectivity nodes. The form may vary. The constitutional substrate must not. The embodiment may adapt. The common rail must remain intact. The systems family doctrine prevents two failures: false uniformity and uncontrolled divergence. It allows Nexus to adapt to mission conditions without creating many incompatible architectures. *** ## 2.6 Dense Cores, Regional Clusters, and Distributed Grids Nexus Compute uses a tiered estate logic. The estate may include dense cores, regional clusters, distributed observatory grids, local nodes, edge environments, and stackable compute blocks. These are not merely performance tiers. They are governance and resilience tiers. ### 2.6.1 Dense Cores Dense cores may carry heavier analytics, model orchestration, simulation, high-volume integration, national-scale public-good infrastructure, Registry-linked operations, and high-value technical workloads. A dense core may support national continuity, infrastructure under national control, public authority learning environments, or high-assurance compute functions. ### 2.6.2 Regional Clusters Regional clusters may support corridor logic, multicountry support, shared ecology interpretation, regional observability, failover capacity, and intermediate-scale coordination without displacing national primacy. A regional cluster is a support and coordination layer. It is not regional supremacy. ### 2.6.3 Distributed Observatory Grids Distributed observatory grids support local sensing, field intelligence, environmental observation, infrastructure signals, community-grounded data where safeguarded, and low-latency situational awareness. They give Nexus local truth. ### 2.6.4 Stackable Compute Blocks Stackable compute blocks allow modular growth. They make the estate expandable without requiring every deployment to begin as a fully mature national system. The tiered model gives Nexus technical flexibility while preserving one governed architecture. *** ## 2.7 The Core Layers of the Compute Estate The Nexus Compute estate should be understood through its core layers. ### 2.7.1 Compute and Storage Substrate This layer provides processing capacity, storage, memory, locality, redundancy, and operating continuity. ### 2.7.2 Observability and Sensor-Fusion Layer This layer ingests and fuses signals from Earth observation, GIS, IoT, OSINT, field systems, infrastructure data, community inputs where safeguarded, and other sources. ### 2.7.3 AI and Model Execution Layer This layer supports bounded machine reasoning, model execution, simulation, inference, workflow support, and AI-assisted analysis under ontology, evidence, role, and public-safe constraints. ### 2.7.4 Runtime Workflow Layer This layer hosts NXS-STU workflows, dashboards, playbooks, scenario tools, public authority learning interfaces, and decision-support preparation. ### 2.7.5 Evidence, Proof, and Correction Layer This layer preserves traceability, provenance, confidence, proof objects, review state, correction records, and supersession logic. ### 2.7.6 Communications and Connectivity Fabric This layer supports controlled movement of data, signals, status, workflow events, and synchronization across local, host, national, regional, and global environments. ### 2.7.7 Policy, Trust, and Protocol Layer This layer expresses role-bound permissions, entitlements, no-bypass controls, access classes, revocation, and audit trails under NXS-NSF policy. Earlier text also listed smart licences and role keys here; these are research outlook, not Nexus architecture. ### 2.7.8 Lifecycle and Serviceability Layer This layer supports maintenance, refresh, repair, environmental fit, updates, patches, backup, degraded-mode operation, retirement, and archival. These layers together make compute operationally whole. *** ## 2.8 Compute and the Common Rail The compute estate carries the common rail in live environments. The common rail is the shared architecture of meaning, standards, trust, Registry, protocol, observability, public-safe status, routeability, and interoperability. Compute gives the rail operational form. But compute does not own the rail. A data center does not become Nexus. A node does not become constitutional authority. A host does not become sovereign over the architecture. A platform administrator does not become protocol authority. A provider running infrastructure does not become the standards authority. Compute carries the rail only when it remains subordinate to the rail’s constitutional, institutional, standards, Registry, and protocol logic. This distinction is fundamental. Compute is powerful. It is not self-authorizing. *** ## 2.9 Compute and Sovereignty Sovereignty is one of the main reasons Nexus Compute exists. Public-purpose systems need compute architectures that respect lawful authority, domestic control, data custody, public authority capacity, local legitimacy, and national primacy. Nexus Compute must support: * domestic lawful basis; * national control where required; * public authority capacity classification; * domestic data custody; * local hosting conditions; * host obligations; * regional support without regional supremacy; * global coherence without hidden centralization; * public-safe publication discipline; * controlled cross-border data movement; * and lawful handoff boundaries. Sovereignty in Nexus Compute does not mean isolation. It means governed control. A national system may interoperate regionally and globally without surrendering domestic lawful basis. A local node may participate in the common rail without becoming externally controlled. A regional cluster may support coordination without displacing national authority. Nexus Compute is therefore the technical expression of sovereignty-compatible federation. *** ## 2.10 Connectivity Sovereignty and Communications Fabric Communications are part of the compute estate. They are not an external commodity layer. Connectivity determines whether observations move, whether workflows remain continuous, whether nodes synchronize, whether public-safe outputs can be generated, whether regional clusters can support corridors, and whether the system can continue under degraded conditions. Nexus communications fabric should support: * local operation; * controlled synchronization; * degraded-mode continuity; * intermittent connectivity; * secure data movement; * role-bound access; * edge-to-core communication; * node-to-Registry synchronization; * NXS-STU workflow continuity; * public-safe publication pathways; * and emergency hold or revocation propagation. This design rejects the assumption that connectivity is always abundant, stable, cheap, trusted, or politically neutral. In real public-purpose environments, connectivity may be partial, contested, expensive, disrupted, or sensitive. Nexus Compute must work under those conditions. *** ## 2.11 Observatory Nodes as the Field-Bearing Compute Layer Observatory Nodes are one of the most important embodiments of Nexus Compute. Here "observatory node" means NXS-OPS equipment and its environment, the physical side of observation under Nexus Observatory Protocol \[1]\[3]. They are the field-bearing layer of the sovereign estate. An Observatory Node may support: * local sensing; * environmental observation; * infrastructure monitoring; * disaster risk intelligence; * climate and resilience signals; * water, energy, food, health, and biodiversity intelligence; * geospatial intelligence; * Earth observation; * field validation; * community science where safeguarded; * public authority learning; * NXS-STU dashboards; * evidence candidate generation; * and local-to-regional observability. An Observatory Node is not merely a device. It is not merely a dashboard endpoint. It is not merely a sensor hub. It is a governed compute-and-observability environment that helps convert raw signals into structured observations under standards, evidence, confidence, public-safe, and correction rules. An Observatory Node is also bounded. It is not public warning authority; its outputs are indicative, not an official warning \[2]. It is not a public authority decision system by default. It is not mature by installation. It is not sovereign by being hosted. It is a field organ of the common rail. *** ## 2.12 From Signals to Governed Observations Compute must support the transformation of signals into governed observations. This sequence is essential. A sensor reading is not evidence by itself. An image is not interpretation by itself. A dashboard is not truth by itself. A model output is not institutional knowledge by itself. A community input is not open data by default. A governed observation should carry: * source; * timestamp; * location where appropriate and safe; * method; * uncertainty; * confidence; * provenance; * evidence class; * public-safe state; * handling class; * review state; * correction pathway; * and relationship to relevant profiles or checks. Nexus Compute must therefore support not only data ingestion, but epistemic transformation. The compute estate must help the system know what it knows, how it knows it, and what it must not infer. *** ## 2.13 AI Fabric and Governed Machine Capability Nexus Compute includes an AI fabric. But AI in Nexus is not autonomous authority. The AI fabric may support: * signal fusion; * pattern detection; * semantic classification; * simulation; * scenario generation; * anomaly detection; * workflow assistance; * report drafting; * public-safe summarization; * model-assisted observability; * domain-pack execution; * NXS-STU support; * Foundry testing; * and public authority learning tools. AI must remain governed by: * ontology; * controlled vocabulary; * Registry state; * public-safe status; * evidence quality; * role permissions; * data handling rules; * human review where required; * audit logs; * correctionability; * and non-execution boundaries. An AI output is not a Nexus determination by default. An AI dashboard is not public warning. An AI recommendation is not public authority action. An AI-generated report is not public-safe unless reviewed. The AI fabric gives Nexus capability. Governance gives that capability legitimacy. In the shared fabrics, agent populations sit in the NEIF Agent Workforce Fabric and routing in NIRF, under the boundary that "Agents do not own domain facts or institutional authority" and that routing "cannot override NXS-NSF, NXS-COR, NXS-NXQ (the software, capability and agent fabric for registries, licensing, APIs and connectors) or domain authority" \[6]. AI work in this estate is also read against external guidance such as the OECD AI Principles and the NIST AI Risk Management Framework \[20]\[21]. *** ## 2.14 NXS-STU Runtime on the Compute Estate NXS-STU runs on the compute estate. NXS-STU is the composition environment through which the estate becomes usable; execution itself belongs to the Universal Runtime fabric and the Polyglot Run Service \[1]\[6]. It hosts workflows, dashboards, simulations, playbooks, scenario environments, AI assistants, observability panels, decision-support preparation, public authority learning environments, node interfaces, and controlled rooms. The compute estate must therefore support: * workflow execution; * role-aware access; * dashboard rendering; * simulation workloads; * data fusion; * controlled-room coordination; * public-safe output generation; * audit trails; * export controls; * and lifecycle management of NXS-STU objects. NXS-STU requires compute, but NXS-STU also requires boundaries. An NXS-STU workflow is not lawful decision-making by default. An NXS-STU simulation is not forecast certainty. An NXS-STU dashboard is not a public warning. An NXS-STU controlled room is not a regulator. The compute estate must make these boundaries visible and enforceable. *** ## 2.15 Foundry Build Environments on the Compute Estate Foundry also depends on the compute estate. The build functions described in this section belong to NXS-FAC, the system for "blueprints, Builder operations, code and artifact generation, verification, builds, signing and assembly" \[1]. Foundry is where rails, packs, ontologies, schemas, policies, connectors, playbooks, agents, dashboards, simulations, Digital Public Goods, public-safe templates, and implementation packages are designed, tested, assembled, documented, and prepared for controlled release. The compute estate must support: * development environments; * test environments; * safe sandboxes; * package builds; * schema validation; * simulation testing; * conformance preparation; * security checks; * dependency management; * versioning; * release candidates; * documentation generation; * and handoff to NXS-STU, Marketplace, Digital Public Goods, or implementation pathways. Foundry build state must remain truthful. A prototype is not a release. A release candidate is not deployment authorization. A package is not public authority adoption. Compute supports build discipline by making controlled environments possible. *** ## 2.16 Evidence, Proof, and Verifiable Compute A Nexus compute estate must preserve evidence and proof. This is one of the deepest differences between ordinary compute and Nexus Compute. Nexus must be able to show: * what was observed; * what data was used; * what method was applied; * what model was run; * what version was used; * who or what initiated the workflow; * what role permission applied; * what result was produced; * what confidence or uncertainty attached; * what record was created; * what correction occurred; * and what state remains current. This requires evidence logs, provenance records, proof objects, hashes, attestations, reproducibility where appropriate, audit trails, and Registry-linked records. Verifiable compute supports trust. But proof does not replace governance. A verified computation may show that something occurred. It does not decide what the result means institutionally. Nexus Compute must preserve both proof and interpretation boundaries. In the shared fabrics this is the Evidence and Receipt Fabric, whose boundary is that "A receipt proves the recorded event within scope, not broader correctness" \[6]. *** ## 2.17 Policy, Trust, and Access Control Inside Compute Nexus Compute must include policy and trust controls inside the estate. Trust cannot be bolted on at the perimeter. The estate should express: * identity binding; * access classes; * role-bound permissions; * entitlement and permission records (earlier text listed smart licences and role keys here; these are research outlook, not Nexus architecture); * entitlement state; * validity windows; * expiry; * renewal; * revocation; * no-bypass logic; * public-safe access; * data-room controls; * API permissions; * NXS-STU role permissions; * Foundry permissions; * Marketplace permissions; * node permissions; * host permissions; * and audit trails. These controls must follow Registry truth. A user should not retain access after role expiry. A provider should not retain integration privileges after suspension. A node should not remain active in platform display after downgrade. An NXS-STU workflow should not remain available after withdrawal. Compute must enforce institutional state rather than merely store data. *** ## 2.18 No-Bypass Compute A compute estate under national control must be designed with no-bypass logic. No-bypass means technical privilege should not allow actors to sidestep governance. A platform administrator should not be able to grant recognition by changing a label. A host should not be able to self-upgrade node maturity. A provider should not be able to self-certify conformance. A user should not be able to publish public-safe outputs without review where review is required. A data-room user should not be able to export controlled materials outside entitlement. A developer should not be able to release a package as supported without release state. No-bypass compute means the easiest technical path should be the valid governance path. This is one of the strongest protections against hidden technical authority. *** ## 2.19 Data Governance in the Compute Estate Compute must support data governance as a first-order function. Nexus data may include: * public data; * observational data; * personal data; * public authority-sensitive data; * market-sensitive data; * procurement-sensitive data; * infrastructure-sensitive data; * health-sensitive data; * biosecurity-sensitive data; * community knowledge; * Indigenous knowledge; * sensitive geography; * provider data; * sponsor data; * finance-readiness data; * node telemetry; * NXS-STU workflow data; * and Registry-linked records. Compute must support: * lawful basis; * consent where required; * minimization; * access control; * retention; * deletion; * correction; * portability; * encryption; * logging; * public-safe aggregation; * sensitive geography controls; * protected knowledge controls; * and non-use boundaries. The compute estate must not become surveillance infrastructure. It must not become uncontrolled commercial intelligence. It must not expose sensitive places, communities, or systems. Data governance is part of compute under national control truth. *** ## 2.20 Cybersecurity and Resilience A Nexus compute estate must be cyber-resilient. Cybersecurity is not a supporting discipline. It is part of the trust architecture. The estate must account for: * identity security; * access control; * key management; * supply-chain security; * secure software updates; * platform hardening; * logging and monitoring; * incident response; * backup; * recovery; * segmentation; * least privilege; * data protection; * provider access controls; * AI security; * node security; * communications security; * and operational continuity. Cybersecurity also intersects with public-safe publication. Some technical details, maps, dependencies, vulnerabilities, or node information may be sensitive. A secure compute estate must support both operation and restraint. Security is not only defense. It is a condition of public trust. *** ## 2.21 Degraded-Mode Operation Nexus Compute must support degraded-mode operation. Real deployments may face: * network disruption; * power instability; * sensor failure; * cyber incidents; * hardware degradation; * communications delays; * data gaps; * restricted access; * host disruption; * emergency conditions; * and regional instability. A compute estate that assumes perfect operating conditions is not suitable for public-purpose use. Degraded-mode design should support: * local continuity; * cached workflows; * delayed synchronization; * offline or low-bandwidth modes; * local evidence preservation; * controlled fallback procedures; * status flags; * degraded confidence indicators; * safe shutdown; * emergency hold; * and recovery synchronization. Degraded-mode capability is part of resilience. It also prevents users from treating impaired outputs as fully normal. *** ## 2.22 Serviceability as a First-Order Requirement Serviceability is a first-order compute requirement. A deployment that cannot be maintained is not mature. Serviceability includes: * hardware access; * spare parts; * repair pathways; * local technical support; * remote support where appropriate; * software updates; * security patches; * documentation; * operator training; * monitoring; * replacement planning; * lifecycle records; * environmental fit; * and support escalation. Public-purpose environments often fail not because systems cannot launch, but because they cannot be maintained. Nexus Compute must be judged by lifecycle support, not launch spectacle. Serviceability is operational truth. *** ## 2.23 Lifecycle, Refresh, and Retirement Nexus Compute must support full lifecycle management. Lifecycle includes: * planning; * procurement-neutral specification; * installation; * commissioning; * configuration; * training; * activation; * operation; * monitoring; * maintenance; * refresh; * upgrade; * downgrade; * redeployment; * suspension; * decommissioning; * retirement; * archival; * and disposal where relevant. Lifecycle records should connect to Registry where status matters. A retired node should not appear active. A deprecated component should not appear supported. A suspended host environment should not retain normal status. A superseded workflow should not remain current. Lifecycle management prevents infrastructure from becoming invisible risk. *** ## 2.24 Sustainability and Power-Cooling Truth Sustainability in Nexus Compute is not a communications claim. It is an architectural property. The estate must account for: * power availability; * cooling requirements; * energy intensity; * water use where relevant; * environmental conditions; * material burden; * maintenance burden; * equipment lifecycle; * modular scaling; * local support capacity; * refresh strategy; * and responsible retirement. Power and cooling truth matters because compute is physical. A system may be computationally elegant and operationally unrealistic if it ignores energy, heat, site constraints, maintenance, or local infrastructure. Nexus Compute must be designed for the environments in which it will actually operate. Sustainability is therefore part of host truth. *** ## 2.25 Host Truth and Deployment Fit Host truth is central to Nexus Compute. A host is not an abstract attachment point. A host has: * legal context; * institutional capacity; * physical environment; * power conditions; * cooling conditions; * network conditions; * cybersecurity posture; * staffing; * governance culture; * public authority relationships; * community context; * data obligations; * continuity limits; * and service burden. A compute deployment must fit the host. It must not assume capacity that does not exist. It must not create burdens the host cannot carry. It must not allow the host to overclaim authority. It must not treat installation as maturity. Host truth requires site assessment, support planning, training, lifecycle planning, access rules, public-safe claims, and correction pathways. A host-supported compute environment is real only when it is supportable. *** ## 2.26 Local, National, Regional, and Global Compute Logic Nexus Compute must operate across layers. ### 2.26.1 Local Layer The local layer supports host truth, edge operation, observatory nodes, community safeguards, field intelligence, and local continuity. ### 2.26.2 National Layer The national layer supports domestic lawful basis, public authority interfaces, national compute estate, data custody, national programs, and sovereign control. ### 2.26.3 Regional Layer The regional layer supports corridor logic, regional clusters, shared ecology interpretation, regional comparability, and support-versus-comparable classification without displacing national primacy. ### 2.26.4 Global Layer The global layer supports canonical semantics, protocol continuity, Registry coherence, crosswalks, standards, and global public-good memory. The compute estate must allow these layers to interoperate without collapsing them. Local does not mean isolated. Regional does not mean supreme. Global does not mean centralized control. National primacy must remain visible. *** ## 2.27 Public-Sector, Industrial, and Corridor Suitability Nexus Compute must be suitable for public-sector, industrial, and corridor environments. These environments are high-consequence. They involve public trust, safety, regulation, infrastructure, continuity, and often sensitive data. Compute must therefore support: * public authority learning; * critical infrastructure observability; * industrial resilience; * corridor systems; * ports and logistics; * utilities; * disaster preparedness; * regional clusters; * institutional continuity; * cybersecurity; * data governance; * degraded-mode operation; * and public-safe outputs. This suitability is one reason the systems-family doctrine is necessary. The estate must adapt to context while preserving the common rail. *** ## 2.28 Compute and Pack-Based Deployment Nexus Compute supports pack-based deployment. Domain and sector packs may include: * ontologies; * schemas; * indicators; * playbooks; * dashboards; * connectors; * simulation modules; * public-safe templates; * evidence-quality targets; * conformance targets; * governance patterns; * and workflow logic. Compute allows packs to run in real environments. A water pack may run on a water observatory node. An energy pack may run in an energy resilience environment. A disaster risk pack may support NXS-STU workflows. A public authority learning pack may support Academy and NXS-STU sessions. A city rail pack may support local observability and workflows. But a pack is not deployment by itself. A pack installed on compute is not public authority adoption. A pack running in NXS-STU is not public warning. Pack-based deployment must remain status-aware. *** ## 2.29 Compute and Rail Deployment Compute is the estate on which rails are deployed. A rail may require: * compute substrate; * observability; * data connectors; * NXS-STU runtime; * domain packs; * governance rules; * public-safe outputs; * Registry synchronization; * protocol permissions; * host logic; * training; * serviceability; * and lawful handoff boundaries. Different rail types may require different compute forms: * rails under national public-authority control may require national dense cores; * sector rails may require institutional or regional clusters; * city rails may require municipal or local node environments; * disaster risk rails may require observatory grids and degraded-mode capacity; * public authority learning rails may require controlled NXS-STU and Academy environments; * corridor rails may require national-regional coordination. Compute does not define the rail alone. It enables the rail to operate. *** ## 2.30 Compute and Marketplace Marketplace depends on compute because extensions need runtime environments, test environments, packaging environments, and controlled distribution. Marketplace objects may include: * apps; * connectors; * packs; * agents; * dashboards; * observatory patterns; * NXS-STU workflows; * training offerings; * Digital Public Goods; * provider services; * and support packages. Compute must support Marketplace without allowing Marketplace to bypass standards. A Marketplace connector should not run outside its permitted scope. A listed object should not appear certified: "Verification is not certification" \[2]. A deprecated object should not remain active. A provider should not retain access after suspension. Compute makes Marketplace usable. Protocol and Registry keep it trustworthy. *** ## 2.31 Compute and Qualified Enterprise Providers Qualified Enterprise Providers may operate, support, integrate, or build within Nexus compute environments. Their involvement may be necessary for real-world implementation. But provider participation must be governed. A provider may support: * infrastructure deployment; * integration; * cybersecurity; * data connectors; * NXS-STU configuration; * Foundry packaging; * Marketplace services; * node operations; * maintenance; * and lawful execution pathways. But a provider does not become Nexus by operating compute. A provider does not become standards authority. A provider does not own the rail. A provider qualification is scope-limited. A provider access key is not endorsement. Compute governance must include provider neutrality, procurement neutrality, access controls, conflict rules, and public claims limits. *** ## 2.32 Compute and Public Authority Interfaces Public authorities may interact with Nexus Compute in different capacities. They may be: * learners; * observers; * consultees; * hosts; * competent authorities; * adopting authorities; * procurement authorities; * regulators; * emergency authorities; * public-warning authorities; * implementation partners. Compute must distinguish these capacities. A public authority learning environment is not adoption. A dashboard view is not approval. A simulation exercise is not emergency command. A public authority host does not endorse all Nexus outputs. A public-warning workflow may be used only by a lawful public-warning authority under lawful procedure. Compute must enforce public authority capacity through access, labels, workflow modes, public-safe outputs, and claims guidance. This protects sovereignty and public trust. *** ## 2.33 Compute and Finance-Readable Readiness Compute may support finance-readable readiness. It may host: * project-preparation data rooms; * readiness dashboards; * routeability records; * diligence packs; * risk translation workflows; * materials for financial institutions (earlier label: Investor Council materials); * readiness rooms for actors who consider a Project SPV outside the programme; * sponsor-capital mapping environments; * and controlled finance-reader outputs. But compute must not convert readiness into finance execution. A data room is not an investment offering by itself. A readiness dashboard is not a credit rating. A routeability record is not underwriting. A Project SPV concept space is not financial close. Investor access is not capital commitment. Compute must preserve finance non-execution through role labels, access restrictions, output non-effect, audit trails, and claims discipline. *** ## 2.34 Compute and National Consortium Companies / Project SPVs {% hint style="warning" %} **Finance boundary.** National Consortium Companies and Project SPVs are formed, if at all, by competent lawful actors outside the programme, under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction. See [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md). {% endhint %} Compute may support National Consortium Companies and Project SPVs where lawful execution pathways exist. The company and SPV steps are taken, if at all, by competent actors outside the programme. A National Consortium Company may use Nexus-aligned compute environments for implementation support, service delivery, data rooms, project preparation, provider coordination, or operational support. A Project SPV may use compute to support defined project functions, subject to lawful instruments, contracts, data governance, and finance rules. But these execution-facing entities do not own the public-good rail. A National Consortium Company is not the National Nexus Consortium. A Project SPV is not Nexus. A Project SPV data room is not a public-good Registry. An SPV workflow is not public authority action unless separately lawful. Compute must preserve the public-good / enterprise stack boundary in execution-facing environments. *** ## 2.35 Compute and Digital Public Goods Compute supports Digital Public Goods. Digital Public Goods may include: * software; * datasets; * schemas; * APIs; * models; * dashboards; * documentation; * public-safe templates; * training materials; * reference implementations; * and connectors. The compute estate may host, test, distribute, validate, or run these assets. But Digital Public Goods require governance. Open does not mean uncontrolled. Public does not mean public-safe for all uses. Reusable does not mean supported everywhere. A fork is not Nexus-aligned by default. Compute must support DPG versioning, security review, dependency management, contribution rules, release status, lifecycle state, and public-safe limits. *** ## 2.36 Compute and Academy Academy depends on compute for learning environments, simulations, NXS-STU training, public authority learning rooms, node-operator training, provider onboarding, domain modules, work-integrated learning, and working-group formation (earlier label: competence cells). Compute may support: * learning sandboxes; * simulation environments; * training data; * public-safe dashboards; * role-based exercises; * controlled labs; * Academy credentials; * learner records; * and practical skill development. But Academy compute environments must remain bounded. A learner environment is not operational deployment. A simulation is not public warning. A training credential is not authority. A public authority learning session is not adoption. Compute helps people learn to carry Nexus. It must not make learning look like execution. *** ## 2.37 Compute and Communities, Indigenous Knowledge, and Protected Participation Compute may support community science, local observability, environmental monitoring, place-based resilience, and protected participation. This requires heightened safeguards. Compute must protect: * community consent; * representation boundaries; * Indigenous knowledge; * local knowledge; * sensitive geography; * cultural knowledge; * protected ecological data; * personal data; * public-safe publication; * attribution; * anonymity where needed; * and correction rights. A community observation is not open data by default. A mapped location may expose sensitive geography. A community participant is not a consent proxy for all community interests. Compute must make place-based knowledge safer, not more extractive. *** ## 2.38 Compute and Public-Safe Outputs Compute generates outputs. These may include: * dashboards; * reports; * simulations; * risk summaries; * node status cards; * public-safe maps; * NXS-STU exports; * observatory notes; * readiness dashboards; * Marketplace status displays; * and Academy materials. Outputs must be public-safe where intended for broader circulation. A dashboard is not automatically public-safe. A map may be sensitive. A simulation may be misunderstood. A risk indicator may be overread. A node status card may imply maturity if poorly labeled. Compute must therefore support public-safe review, output classification, handling classes, status labels, non-effect statements, and correction pathways. *** ## 2.39 Compute and Registry Synchronization Compute must synchronize with Registry. Registry records institutional state. Compute expresses that state in systems. This synchronization may include: * member access; * provider access; * Marketplace status; * node status; * host status; * NXS-STU workflow status; * Foundry package status; * Digital Public Good status; * public authority capacity; * finance-readable status; * public-safe publication status; * smart-license state; * role-key state; * suspension; * revocation; * reinstatement; * retirement. If Registry and compute diverge, trust weakens. A suspended provider should not remain active in systems. A retired workflow should not remain accessible. A downgraded node should not display as mature. A revoked permission or entitlement should not function. Compute must be state-aware. *** ## 2.40 Compute and Correctionability Correctionability must be built into compute. Errors may occur in data, models, workflow logic, access permissions, public-safe outputs, node status, provider status, Marketplace display, NXS-STU dashboards, Foundry packages, and Registry synchronization. Compute correction may require: * data correction; * model correction; * workflow correction; * access revocation; * dashboard label update; * public output correction; * node downgrade; * provider suspension; * Marketplace delisting; * package deprecation; * audit note; * Registry update; * protocol rollback; * and public clarification. A compute estate that cannot correct itself cannot be trusted. Correctionability is not an administrative feature. It is a design requirement. *** ## 2.41 Compute and External Organizations Nexus Compute is designed to be usable by external organizations under proper pathways. A public authority can use Compute for public authority learning, observability, NXS-STU workflows, public-safe outputs, and lawful adoption pathways. A company can use Compute through provider pathways, Marketplace objects, Foundry builds, NXS-STU integrations, National Consortium Company structures, or lawful implementation pathways. A university can use Compute for Academy, [NXS-LAB](/organization/systems/nxs-lab.md) (the experiments and research programme), Digital Public Goods, research-to-practice translation, working groups (earlier label: competence cells), and observatory nodes. A sponsor can support Compute without controlling it. A community organization can participate through protected observability and community science pathways. A provider can support integration, maintenance, and deployment under qualification and claims limits. A national group can use Compute to move from concept to node, consortium, company, and SPV pathways. The company and SPV steps are taken, if at all, by competent actors outside the programme. A finance reader can use Compute-generated readiness artifacts without mistaking them for finance execution. Compute becomes usable because role boundaries are explicit. *** ## 2.42 Compute Governance Compute requires governance. Compute governance should address: * estate design; * host selection; * node classification; * public authority capacity; * provider roles; * data governance; * cybersecurity; * access control; * entitlement and permission records (earlier text listed smart licences and role keys here; these are research outlook, not Nexus architecture); * Registry synchronization; * public-safe outputs; * Marketplace integration; * Foundry release pathways; * NXS-STU workflow controls; * Digital Public Goods; * lifecycle; * serviceability; * sustainability; * correction; * suspension; * retirement; * and audit. Compute governance should be role-separated. A provider should not self-certify. A host should not self-upgrade maturity. A platform administrator should not override Registry. A sponsor should not control compute priorities by funding alone. A public authority capacity should not be inferred from access. Compute governance keeps the technical estate from becoming a hidden power structure. *** ## 2.43 Compute Failure Modes Nexus should be explicit about compute failure modes. **Generic cloud reduction** occurs when compute under national control is reduced to ordinary cloud hosting with sovereignty language. **Appliance reduction** occurs when the estate is reduced to a device or node box. **Infrastructure minimalism** occurs when compute is deployed without observability, evidence, workflow, trust, lifecycle, or correction layers. **Vendor capture** occurs when a provider’s platform becomes the practical rail. **Host overreach** occurs when hosting is narrated as ownership or sovereignty over Nexus. **Node maturity inflation** occurs when installation is treated as active or mature state. **Dashboard authority drift** occurs when compute outputs appear to decide, warn, regulate, or command. **AI autonomy drift** occurs when models act beyond ontology, evidence, role, or review boundaries. **Registry-compute mismatch** occurs when system access or display diverges from recorded state. **Data extraction failure** occurs when compute captures community, public authority, or infrastructure data beyond permitted use. **Serviceability failure** occurs when deployments cannot be maintained, patched, repaired, refreshed, or retired. **Degraded-mode failure** occurs when systems fail unsafely under imperfect connectivity, power, or host conditions. **Finance overclaim** occurs when compute-generated readiness outputs imply investment, underwriting, insurance, or capital commitment. **Public authority overclaim** occurs when learning environments or dashboards imply adoption or official action. **Correction failure** occurs when errors cannot be corrected, downgraded, withdrawn, or recorded. Compute governance exists to prevent these failures. *** ## 2.44 Strategic Value of Nexus Compute The strategic value of Nexus Compute is that it makes Nexus operationally credible. It allows Nexus to: * run governed rails; * support compute estates under national control; * deploy observatory nodes; * operate NXS-STU workflows; * build and test in Foundry; * run AI under constraints; * preserve evidence and proof; * support public authority learning; * generate public-safe outputs; * support Marketplace and Digital Public Goods; * enable domain packs; * support national and regional pathways; * operate under degraded conditions; * synchronize with Registry; * enforce role-bound access; * support correction; * and remain serviceable over time. In strategic terms, Compute is the physical and digital substrate of Nexus realization. It is how the architecture becomes real enough to use. It is how public-good governance becomes operational without becoming execution. It is how local truth, sovereign control, and global coherence can coexist in technical form. *** ## 2.45 Final Statement on Nexus Compute Nexus Compute is the systems-scale technical estate, intended to support national control, through which Nexus is designed to become operationally real. It is the compute, observability, communications, AI, runtime, evidence, trust, protocol, serviceability, sustainability, lifecycle, and correction substrate that allows the common rail to operate across public, institutional, industrial, corridor, regional, national, host, and mission-critical environments. It is not a single appliance. It is not generic cloud. It is not platform branding. It is not edge compute alone. It is not technical capacity detached from governance. It is a governed systems family. Through dense cores, regional clusters, distributed observatory grids, stackable compute blocks, NXS-STU runtime environments, Foundry build environments, AI fabric, communications fabric, evidence and proof layers, public-safe output pathways, entitlement and permission controls, lifecycle systems, and host-specific deployment configurations, Nexus Compute gives the architecture real operating substance. It remains bounded by constitutional truth. It preserves sovereign compatibility. It follows Registry state. It supports public-safe outputs. It enables routeability without executing finance. It supports public authority learning without becoming public authority. It allows providers to contribute without becoming standards authorities. It allows hosts to carry runtime environments without becoming sovereign owners. It allows national and regional systems to interoperate without fragmentation. Through Compute, Nexus is designed to become technically inhabitable as well as governed and standardized. *** ## Next steps Read **III. Edge** to understand the local observatory, sensing, node, and distributed intelligence layer carried by the compute estate. Read **IV. The Foundry pillar and the systems** to understand the design, testing, assembly, and runtime preparation environments built on top of Compute. Read **V. Programs** to understand the capability, Academy, simulation, accelerator, and adoption pathways that make compute institutionally usable. Read **VI. Marketplace** to understand how apps, connectors, packs, agents, services, Digital Public Goods, providers, and extensions become discoverable and usable under governed rules. Read **VII. Consortiums** to understand the institutional model through which compute moves into national, regional, company, and Project SPV deployment pathways. The company and SPV steps are taken, if at all, by competent actors outside the programme. Read **VIII. Campaign** to understand the activation horizon to 2030, stated as targets with no implementation record. *** ## The compute estate and the twenty canonical systems The eight layers in section 2.7 are a reading device. In the V3 constitution the same work is divided between canonical systems and shared fabrics, each the correction authority for its own records \[1]\[6]. Table 1 gives the mapping this documentation uses. *Table 1. Compute layers and their canonical owners. Remits quoted from D-V3-0003 and D-V3-0001 \[1]\[6]; mapping by this documentation, as of 2026-10-16.* | Layer (section 2.7) | Canonical owner | Remit or boundary (quoted) | | ------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Compute and storage substrate | NXS-COR | "Compute, nodes, clusters, runtimes, workload placement, infrastructure lifecycle, capacity and execution observation" | | Observability and sensor fusion | NXS-OPS, NXS-SIG, NXS-EOP, [NXS-GRX](/organization/systems/nxs-grx.md) | NXS-OPS: "Physical instruments, observatory nodes, sensors, gateways, calibration, metrology, acquisition and primary observation evidence"; NXS-GRX: "Canonical data, metadata, provenance, quality, uncertainty, graph, risk, fusion, statistical-geospatial products and data federation" | | AI and model execution | Polyglot Run Service; NEIF and NIRF fabrics; NXS-NXQ for models and agents | Run Service "owns execution control and receipts, while method and domain authority remain separately owned" | | Runtime workflow | Universal Runtime; NXS-STU for composition | "Runtime executes authorized intent. It does not grant purpose, legal authority, scientific validity or entitlement" | | Evidence, proof and correction | Evidence and Receipt Fabric | "A receipt proves the recorded event within scope, not broader correctness" | | Communications and connectivity | NXS-NET | "Network topology, connectivity, service intent, telemetry, traffic engineering, QoS/QoE, resilience and communications continuity" | | Policy, trust and protocol | NXS-NSF; UNI Identifier Fabric; Rights Control Plane | NXS-NSF: "Constitutional trust, identity authorization, mandate, delegation, purpose, sovereignty, policy, assurance, public-safe release and correction governance"; "Identifier resolution is not authorization, certification or truth" | | Lifecycle and serviceability | NXS-COR; NXS-APP; [NXS-CMD](/organization/systems/nxs-cmd.md) Command Centre | NXS-APP: "Application catalog, installation, instances, dependencies, health, upgrades, rollback and retirement"; Tower "governs who owns and operates an estate" |
The compute estate as a division of canonical systems. NXS-CMD Command Centre, the NXS-NSF policy and release gate and NXS-APP act on NXS-COR, which NXS-NET connects. NXS-OPS and NXS-SIG instruments feed NXS-NET and NXS-GRX. NXS-COR hosts the Universal Runtime and Run Service, which serve NXS-STU composition and write receipts to the Evidence and Receipt Fabric, as NXS-GRX also does.

Figure 1. The compute estate as a division of canonical systems and fabrics. Target architecture, not a record of any installed estate. Source: D-V3-0003 and D-V3-0001 [1][6], as of 2026-10-16.

Text description of Figure 1 NXS-CMD Command Centre governs the estate and NXS-NSF applies policy and release control to NXS-COR, which provides compute and nodes. NXS-NET carries connectivity to NXS-COR. NXS-OPS and NXS-SIG instruments send signals over NXS-NET and into NXS-GRX (the global data and risk intelligence engine) as governed data. NXS-COR hosts the Universal Runtime and the Polyglot Run Service, which execute work composed in NXS-STU and write receipts to the Evidence and Receipt Fabric; NXS-GRX also writes evidence there. NXS-APP (the mission app runtime, for app instances, routes and versions) installs and retires software on NXS-COR.
## How the consortium programme describes compute work The main-branch consortium programme turns compute into two bounded offerings and an annual operating function. They are programme designs at service level R0; none is recorded as delivered \[5]. * **O03, Sovereign Data, Compute and AI Capability.** Question: "What technical environment can support national work without unnecessary dependency or loss of control?" Work: inventory existing estates; assess identity, data location, interoperability, cybersecurity, capacity, workforce, model rights and exit; design a bounded landing environment; rehearse restore and transfer. Deliverables: estate assessment, data and compute architecture, approved workload plan, implementation options, workforce plan, portability package, and measured pilot evidence where a pilot is authorised. Boundary: "A blueprint is not an installed environment, and requested capacity is not allocated capacity." Systems: NXS-COR, NXS-NET, NXS-NSF, NXS-NXQ and NXS-FAC \[5]. * **O09, Annual Universe Missions and Contributed Infrastructure.** Missions that need temporary technical intensity are scoped, infrastructure offers are qualified, resources are allocated, results are preserved and temporary access is closed. Boundary: "Neither membership nor sponsorship guarantees a compute allocation." Systems: NXS-COR, NXS-NET, NXS-LAB, NXS-FAC and NXS-APP \[5]. * **Nexus Network (operating function).** "The annual Nexus Network brings qualified computing, networks and technical teams together each year", in three layers: persistent coordination (authorised institutions, resource catalogues, identity, rights and methods, retained evidence), a temporary technical environment (qualified networking and HPC, accelerators, cloud and edge capacity, secure data spaces, cyber ranges and simulation environments) and durable outputs (trained teams, tested configurations, reproducible workloads and evaluation results) \[5]. Two separations from the same source govern every compute statement: "An infrastructure offer" is not "an allocation", and offered capacity "is never counted as reserved, consumed or funded" \[5]. **Compute rule ACC-II-1.** A compute estate, node or allocation SHALL be described as installed, allocated or operating only with a recorded allocation, installation or observation record for that exact scope (source: consortium programme separations \[5]; claim registry \[4]). **Compute rule ACC-II-2.** Every compute deployment description SHALL name its canonical owner (NXS-COR, NXS-NET, NXS-NSF or the relevant fabric) and SHALL state that the sovereign deployment profile is blocked while the release hold is active (source: D-V3-0003 \[1]; release hold \[4]). ## What Nexus Compute is not * It is not an installed estate. No dense core, regional cluster, observatory grid or node is recorded as installed or operating \[4]\[5], and the fifteen hubs in the geography registry are planned coordination roles, not offices \[7]. * It is not a sovereign product. Sovereignty belongs to states and their competent authorities; the estate is intended to support national control, subject to evidence \[3]. * It is not a cloud region, data-centre brand or hardware product, and it is not a commitment of capacity: "requested capacity is not allocated capacity" \[5]. * It is not a security certification. No ISO/IEC 27001, SOC 2, FedRAMP or similar certification is claimed for any Nexus estate; frameworks cited below are references only \[9]. * It is not an emergency service or official warning channel. "Nexus is not an emergency-dispatch service" \[5]. * It is not a transfer of control to providers or hosts. Hosting is not ownership, and a provider is not a standards authority. ## International context (alignment, not endorsement) The references below are cited for comparison and alignment only. Naming them implies no partnership, endorsement or certification. * **Definitions of cloud and estate.** The NIST definition of cloud computing distinguishes service and deployment models (public, private, community and hybrid) \[10]. The estate design on this page is broader than any one model: it includes field equipment, networks, evidence and lifecycle, not only hosted capacity. * **Cybersecurity and zero trust.** The NIST Cybersecurity Framework 2.0 organizes cybersecurity outcomes as govern, identify, protect, detect, respond and recover \[11], and NIST SP 800-207 describes zero trust architecture, in which access is decided per request rather than by network location \[12]. ISO/IEC 27001 is the international standard for information security management systems \[13]. Section 2.17 (policy, trust and access control inside compute) and section 2.18 (no-bypass compute) express the same design direction; no conformity with these standards is claimed. * **Power, cooling and sustainability.** ISO/IEC 30134-2 defines power usage effectiveness for data centres \[14], and the International Energy Agency has examined the electricity demand of data centres and AI \[15]. Section 2.24 (power-cooling truth) treats energy and heat as design constraints for the same reason. * **Public shared computing.** The European High Performance Computing Joint Undertaking is one example of shared public computing capacity governed across several states \[16]; it is cited as a comparison for federated access to qualified resources, not as a partner. * **Digital cooperation and safeguards.** The Global Digital Compact, annexed to the Pact for the Future, commits states to inclusive and safe digital infrastructure and data governance \[17], and the UN Universal Safeguards for Inclusive Digital Public Infrastructure set out safeguards against exclusion and harm \[18]. A Nexus compute component may be called a digital public good only when the Digital Public Goods Standard is met with a recorded licence decision \[19]. * **Indigenous and community data.** The CARE Principles for Indigenous Data Governance (collective benefit, authority to control, responsibility and ethics) bear directly on section 2.37 \[22]. ## Terms used on this page * **Compute estate.** The whole of compute, storage, networks, field equipment, policy controls, evidence and lifecycle support carrying the rail in an operating environment; a target design. * **Dense core, regional cluster, distributed grid, stackable block.** Design tiers of the estate described in section 2.6; none is recorded as built. * **Systems family.** One constitutional substrate with several physical embodiments suited to different hosts (section 2.5). * **Degraded mode.** Operation under impaired power, connectivity or host conditions, with outputs labelled as impaired (section 2.21). * **Host truth.** The recorded capacity, obligations and limits of a host institution; hosting confers no ownership or authority. * **No-bypass.** The design rule that the easiest technical path is the valid governance path (section 2.18). ## Related pages * Up: [Acceleration](/organization/introduction/acceleration.md) * Across: [I. Order](/organization/introduction/acceleration/i.-order.md) · [III. Edge](/organization/introduction/acceleration/iii.-edge.md) · [IV. The Foundry pillar and the systems](/organization/introduction/acceleration/iv.-foundry.md) · [V. Programs](/organization/introduction/acceleration/v.-programs.md) · [VI. Marketplace](/organization/introduction/acceleration/vi.-marketplace.md) · [VII. Consortiums](/organization/introduction/acceleration/vii.-consortiums.md) · [VIII. Campaign](/organization/introduction/acceleration/viii.-campaign.md) * Counterparts: [Nexus Compute](/organization/acceleration/nexus-compute.md) · [Acceleration part](/organization/acceleration.md) · [VI. Federation](/organization/introduction/organization/vi.-federation.md) · [V. Protocol](/organization/introduction/standardization/v.-protocol.md) ## Sources 1. Nexus constitutional directive D-V3-0003, *Canonical Twenty-System Constitution and Authority Matrix* (canonical order, remits, completeness and non-ownership rules). Internal record, cited by identifier. 2. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks, Non-Execution and Lawful Handoff Constitution* (public-good rail, enterprise and sovereign execution stack, consequential action envelope, boundary formulas). Internal record, cited by identifier. 3. Nexus institutional register, *Nexus institutional architecture and participation*: owner decision of 11 October 2026 on GCRI Canada as lead contracting organization (owner-confirmed; counsel review pending), with the legal entity profile notices on operating structure, the lead contracting organization, consortium stewardship, institutional independence, platform ownership and the commercial channel (owner-confirmed; title and instruments unverified). Internal record. 4. Nexus institutional register: release hold policy (in force since 21 July 2026; permitted profiles internal development, pull-request preview, isolated test and non-certified research; blocked profiles include sovereign, marketplace and certified public-good) and claim register. Internal record. 5. Nexus institutional register, consortium programme: operating functions, conversion chain, programme offerings O01 to O10 with their questions, deliverables, entry routes, boundaries and system mappings, decision rights, service levels R0 to R5, current service level R0, separations and case routes; drawing on the consortium directives D-NEXUS-CONSORTIUM-PUBLIC-ARCHITECTURE-2 and D-NEXUS-CONSORTIUM-STAKEHOLDER-READINESS-3. Internal record. 6. Nexus constitutional directive D-V3-0001, *Master Directive V3* (shared constitutional fabrics and their boundary sentences), and the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1). Internal record, cited by identifier; the Native Master is not quoted. 7. Nexus institutional register, consortium geography: six regions and fifteen planned hubs, every hub planned; hubs are coordination roles, not offices. Internal record. 8. Public institutional site draft (not yet adopted; owner direction, not a binding record): controlled vocabulary, council vocabulary NNC, NLC and NWG with the note retiring earlier labels, programme status vocabulary and institutional boundary sentences for GRF and GRA. Draft source. 9. Nexus Documentation Standard, draft of 16 October 2026 (purpose and audiences, authority and status, naming, external frameworks and sources), the owner decisions of 16 October 2026 and the introduction audit of 16 October 2026. Internal editorial records; not published. 10. NIST (2011). *SP 800-145, The NIST Definition of Cloud Computing*. [csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/145/final). Accessed 2026-10-16. 11. NIST (2024). *The NIST Cybersecurity Framework (CSF) 2.0*. [nist.gov](https://www.nist.gov/cyberframework). Accessed 2026-10-16. 12. NIST (2020-08). *SP 800-207, Zero Trust Architecture*. [csrc.nist.gov](https://csrc.nist.gov/pubs/sp/800/207/final). Accessed 2026-10-16. 13. ISO/IEC (2022). *ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection: Information security management systems: Requirements*. (URL not verified) 14. ISO/IEC (2016). *ISO/IEC 30134-2:2016, Information technology: Data centres: Key performance indicators: Part 2: Power usage effectiveness (PUE)*. (URL not verified) 15. International Energy Agency (2025). *Energy and AI*. (URL not verified) 16. European High Performance Computing Joint Undertaking (EuroHPC JU). Official website. [eurohpc-ju.europa.eu](https://eurohpc-ju.europa.eu/). Accessed 2026-10-16. 17. United Nations General Assembly (2024). *The Pact for the Future*, A/RES/79/1, with the Global Digital Compact annexed. [docs.un.org](https://docs.un.org/en/A/RES/79/1). Accessed 2026-10-16. 18. United Nations (UNDP and Office of the Secretary-General's Envoy on Technology, with partners). *Universal Safeguards for Inclusive Digital Public Infrastructure*. [dpi-safeguards.org](https://www.dpi-safeguards.org/). Accessed 2026-10-16. 19. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/standard). Accessed 2026-10-16. 20. OECD. *OECD AI Principles* (Recommendation of the Council on Artificial Intelligence). [oecd.ai](https://oecd.ai/en/ai-principles). Accessed 2026-10-16. 21. NIST (2023). *Artificial Intelligence Risk Management Framework (AI RMF 1.0)*. [nist.gov](https://www.nist.gov/itl/ai-risk-management-framework). Accessed 2026-10-16. 22. Carroll, S. R. et al. (2020). The CARE Principles for Indigenous Data Governance. *Data Science Journal*, 19(1), 43. [datascience.codata.org](https://datascience.codata.org/articles/10.5334/dsj-2020-043). Accessed 2026-10-16. 23. GCRI (2026). *How Nexus works*: the six pillars, their eighteen handoffs and the eight-step cycle (Question, Evidence, Build, Organize, Test, Publish, Decide, Renew). [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Read 2026-10-21. 24. UN Office of the Secretary-General's Envoy on Technology and UNDP (2024). Universal DPI Safeguards Framework. New York: United Nations, September 2024. [dpi-safeguards.org](https://www.dpi-safeguards.org/). 25. GovStack Initiative (ITU, Estonia, Germany, Digital Impact Alliance) (2020–). GovStack building-block specifications. [govstack.global](https://www.govstack.global/). 26. The Global Risks Alliance (2026). *Finance and insurance readiness*: readiness evidence is not a financing decision. [globalriskalliance.com/finance-readiness](https://globalriskalliance.com/finance-readiness/). Read 2026-10-21. 27. The Global Risks Alliance (2026). *Lawful handoffs*: readiness evidence is released one to one on the owner's written direction, with no introduction and no pay tied to any transaction. [globalriskalliance.com/finance-readiness/handoff](https://globalriskalliance.com/finance-readiness/handoff/). Read 2026-10-21. 28. GCRI (2026). *Programme status*: Exploration, In formation, Constituted, Active programme, Paused, Closed, Historical record; current service level R0. [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Read 2026-10-21. 29. GCRI (2026). *Nexus Reports programme*: quarterly country editions, an annual flagship and specialist series; current approved releases: none. [therisk.global/publications/nexus-reports](https://therisk.global/publications/nexus-reports/). Read 2026-10-21. ## Editorial record * As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted (an AI agent drafted this revision). Human review: pending; no named reviewer or approver yet. * Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits. * Change: 2026-10-16, upgraded to the documentation standard draft. Record block, In brief and status section added; "source page" residue removed; "Nexus Sovereign Compute" renamed Nexus Compute and "sovereign" kept only for public-authority powers or design intent; role keys and smart licences reframed as research outlook; NXS-STU, NXS-FAC, Universal Runtime and the Evidence and Receipt Fabric reconciled with V3; retired council labels flagged; canonical-owner table, compute map, programme offerings O03 and O09 with the `Nexus Network`, rules ACC-II-1 and ACC-II-2, external context, terms, sources and related pages added; heading levels corrected; all original sections kept. * Change: 2026-10-16 r2, readable document record and status note; Nexus Standards display codes for systems; system naming; Nexus Observatory Protocol note; ownership and licensing statements rewritten without naming any company; internal paths, commit references and status codes replaced with plain words. * Change: 2026-10-21 r3, brought up to date with the published sites, Nexus Standards and the owner's rulings of October 2026: Where this fits line; a Current position section; Nexus Standards described as published ([NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) and [NS-3b](https://nexustandards.com/standards/ns-3b/), NIS-1, 348 NRS in 15 series, all PROPOSED; GCRI Canada publisher of record; governance bodies and adoption modes); the national vocabulary of National Nexus, the NNC with its six Helix councils, the NLC and the NWG; the finance boundary on every vehicle passage; the systems named as systems; all original sections kept. --- # 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/introduction/acceleration/ii.-compute.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.