# XII. COMPUTE

Nexus Agile Framework Compute defines the **NAF compute and infrastructure model** for cloud, edge computing, high-performance computing, sovereign compute, verifiable compute, networks, and infrastructure resilience. This section explains how **secure enclaves, compute-to-data workflows, observability infrastructure, AI-RAN and O-RAN patterns, private wireless, and continuity controls** support public-good systems.

This section sets the operating model for **compute object classes**, **network and telecom capability patterns**, **provider-neutral infrastructure governance**, **data residency and sovereign compute controls**, and **resilience and continuity planning**. It helps Nexus run infrastructure safely, preserve portability, strengthen observability, and support lawful handoff without creating provider validation, public authority approval, deployment authorization, or execution by implication.

### What this section covers

* **Compute governance** - Defines cloud, edge, HPC, sovereign compute, and verifiable compute controls.
* **Infrastructure patterns** - Explains secure enclaves, compute-to-data, observability, AI-RAN, O-RAN, and private wireless records.
* **Continuity and boundaries** - Defines network resilience, disaster recovery, support limits, and no-deployment rules.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [IX. SOFTWARE](/organization/operations/frameworks/nexus-agile-framework-naf/ix.-software.md) for repository, API, and release controls, [X. DATA](/organization/operations/frameworks/nexus-agile-framework-naf/x.-data.md) for compute-to-data and controlled-room data boundaries, and [XI. AI](/organization/operations/frameworks/nexus-agile-framework-naf/xi.-ai.md) for AI workflows, AI-use labels, and human oversight.

## 12.1 Compute and Infrastructure Doctrine

### 12.1.1 Compute as Public-Good Capability Layer.

12.1.1.1 Compute within NAF shall mean the cloud, edge, high-performance, sovereign, secure, distributed, verifiable, networked, storage, runtime, simulation, observability, Studio, Core Build, and compute-to-data environments that enable Nexus public-good work to process data, run software, support AI workflows, execute simulations, host dashboards, support DRI and Observatory functions, operate Studio workflows, maintain repositories, support National Portfolios, prepare Nexus Universe outputs, and generate lawful handoff dependency context.

12.1.1.2 Compute shall be treated as a public-good capability layer when it supports evidence, learning, public-safe reporting, public-good software, open technical baselines, research, DRI, GRIx, DICE, Observatory workflows, Studio workflows, Nexus Grid inputs, TRL evidence notes, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Academy, Risk Academy, Nexus Foundry, Nexus Campaigns, Nexus Universe, Nexus Rails, Nexus Network, National Nodes, Competence Cells, and lawful handoff preparation.

12.1.1.3 Compute shall be governed as infrastructure for public-good capability formation, not as a hidden authority layer. Compute availability, hosting, runtime access, dashboard operation, AI processing, simulation capability, storage access, edge deployment, network access, or provider support shall not create certification, public authority approval, procurement status, financeability, insurance approval, data rights, operational command, deployment authorization, or execution.

12.1.1.4 Compute shall be designed for openness where safe, control where necessary, interoperability where feasible, portability where practicable, resilience where required, sovereignty where applicable, security by design, privacy by design, correctionability, archive, and lawful handoff without lock-in, capture, or no-conversion breach.

### 12.1.2 Cloud as Distributed Resource Layer.

12.1.2.1 Cloud environments may be used as distributed resource layers for storage, compute, AI workflows, data processing, software testing, repositories, APIs, dashboards, Studio workflows, Academy platforms, Campaign tools, Marketplace services, Registry services, Reports infrastructure, DICE environments, DRI dashboards, Observatory processing, Nexus Universe operations, National Node support, and handoff dependency preparation.

12.1.2.2 Cloud use shall be recorded with provider, region, jurisdiction, service class, data residency, access model, cost and support status, security posture, privacy posture, dependency status, portability status, exit path, backup status, continuity status, logging status, monitoring status, incident pathway, correction pathway, teardown rule, and archive rule.

12.1.2.3 Cloud support shall remain provider-neutral by default. Cloud credits, hosting, technical support, architecture assistance, or infrastructure contribution shall be recorded as support only and shall not validate the provider, create procurement preference, create vendor endorsement, bind future architecture, or convert public-good work into provider-controlled delivery.

### 12.1.3 Edge as Local Capability Layer.

12.1.3.1 Edge environments may support local data processing, sensor workflows, Observatory nodes, DRI signals, degraded-mode operation, low-latency workflows, digital twin inputs, AI-RAN and O-RAN testing contexts, private wireless contexts, WFEH-B monitoring, disaster-resilience applications, public authority learning, community-relevant observability, National Node capability, and Nexus Universe demonstrations.

12.1.3.2 Edge use shall be governed by local jurisdiction, national ownership, public authority boundaries, data sovereignty, data minimization, geospatial sensitivity, cyber-physical sensitivity, infrastructure sensitivity, sensor governance, privacy controls, local safeguard review, security controls, connectivity limits, support class, correction pathway, and archive rule.

12.1.3.3 Edge capability shall not imply deployment authorization. Edge prototypes, edge tests, sensor-linked dashboards, local AI workflows, private wireless demonstrations, or degraded-mode pilots shall remain bounded by records, review gates, lawful authority, public authority dependencies, data rights, community safeguards, Indigenous protocols where applicable, and handoff discipline.

### 12.1.4 Sovereign Compute as Jurisdiction-Sensitive Capability.

12.1.4.1 Sovereign Compute shall mean compute environments, hosting arrangements, access controls, storage systems, processing workflows, secure enclaves, national repositories, national mirrors, National Node infrastructure, or compute-to-data environments designed to preserve jurisdiction-sensitive data, public authority-sensitive workloads, national ownership, data localization, cross-border restrictions, privacy obligations, public-good continuity, and lawful national control.

12.1.4.2 Sovereign Compute shall be used where required or appropriate for public authority-sensitive data, national data, restricted data, community-sensitive data, Indigenous protocol-sensitive data where applicable, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, protected knowledge, DRI indicators, Observatory records, National Portfolio records, secure-room workflows, data-room workflows, and handoff-recipient-only materials.

12.1.4.3 Sovereign Compute shall not imply public authority approval by itself. Sovereign hosting, national infrastructure, national cloud region, local data residency, National Node hosting, or public authority-facing compute shall not create official action, public authority decision, procurement approval, public finance allocation, certification, deployment authorization, or execution unless separately and lawfully recorded by competent actors.

### 12.1.5 HPC as Frontier R\&D and Simulation Support.

12.1.5.1 High-Performance Computing may support frontier R\&D, climate and weather modeling support, hydrological modeling support, geospatial analysis, disaster-risk simulation, digital twins, AI evaluation, model training where lawfully permitted, agentic workflow testing, cyber-physical simulation, infrastructure stress testing, WFEH-B systems modeling, advanced manufacturing analysis, quantum-relevant research, biosecurity-sensitive modeling under controls, and Nexus Core Build operations.

12.1.5.2 HPC use shall be governed by workload classification, data rights, AI-use labels, export-control sensitivity where applicable, dual-use sensitivity, public-safe controls, cyber controls, access controls, queue records, cost and support records, reproducibility records, environment records, storage rules, output review, correction pathway, teardown rule, and archive rule.

12.1.5.3 HPC results shall remain bounded evidence. HPC simulation, model training, benchmark performance, digital twin analysis, stress testing, or large-scale computation shall not create scientific certainty, public warning, public authority decision, certification, financeability, insurance approval, procurement readiness, deployment authorization, or execution.

### 12.1.6 Verifiable Compute as Trust-Enhancing Record Layer.

12.1.6.1 Verifiable Compute shall mean technical and record-based mechanisms that help demonstrate what computation was run, in what environment, by whom or by what authorized workflow, on what inputs, under what permissions, with what code or model version, with what outputs, and under what integrity, reproducibility, logging, attestation, proof, audit, or receipt conditions.

12.1.6.2 Verifiable Compute may include signed execution records, reproducibility packages, checksum records, container hashes, code version records, model version records, dataset version records, proof receipts, environment manifests, workflow logs, secure enclave attestations, confidential computing attestations where available, provenance records, and output review records.

12.1.6.3 Verifiable Compute shall enhance trust but shall not replace judgment, review, public-safe transformation, safeguard review, security review, privacy review, public authority processes, finance diligence, procurement diligence, consent, deployment authorization, or execution authority.

### 12.1.7 Compute-to-Data as Restricted-Data Default Where Appropriate.

12.1.7.1 Compute-to-Data shall be the preferred pattern where raw data should not be exported, copied, downloaded, transferred, published, or exposed due to rights, privacy, public authority sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, protected knowledge, health sensitivity, cyber sensitivity, infrastructure sensitivity, geospatial sensitivity, data sovereignty, or cross-border restrictions.

12.1.7.2 Compute-to-Data environments shall bring approved workloads, approved models, approved queries, approved users, approved code, approved tools, and approved output review to the data environment rather than moving the raw data to uncontrolled environments.

12.1.7.3 Compute-to-Data shall require workload approval, user approval, access control, query controls, no raw extraction, logging where appropriate, output review, public-safe transformation where required, AI-use controls, correction pathway, incident response, and archive rule.

12.1.7.4 Compute-to-Data results shall not create data rights, public authority approval, handoff permission, financeability, insurance approval, procurement status, deployment authorization, or execution.

### 12.1.8 Infrastructure Without Provider Lock-In by Default.

12.1.8.1 NAF infrastructure shall be designed to avoid unnecessary provider lock-in, platform capture, hidden exclusivity, sponsor capture, cloud capture, proprietary dependency capture, data enclosure, AI-service enclosure, telecom-provider capture, or infrastructure dependency that undermines public-good continuity, national ownership, interoperability, portability, correctionability, archive, or lawful handoff neutrality.

12.1.8.2 Provider-specific services may be used where they are technically justified, recorded, reversible where practicable, dependency-mapped, exit-planned, license-reviewed, security-reviewed, cost-reviewed, support-reviewed, and compatible with public-good firewall discipline.

12.1.8.3 Provider contribution shall be welcomed where useful and controlled where necessary. Infrastructure support shall not give a provider control over Dockets, priorities, standards-interface claims, Registry status, Marketplace visibility, National Portfolios, Nexus Universe participation, public authority learning, finance-readiness, procurement pathways, handoff routing, or public narrative.

## 12.2 Infrastructure Object Classes

### 12.2.1 Cloud Environments.

12.2.1.1 Cloud Environments are hosted compute, storage, networking, database, AI, analytics, container, serverless, repository, identity, security, monitoring, dashboard, and application environments used to support NAF work.

12.2.1.2 Cloud Environment records shall identify provider, region, jurisdiction, account structure, ownership or stewardship, access model, service types, data residency, data classes, AI-use classes, security controls, privacy controls, cost and support record, dependency record, backup rule, continuity rule, teardown rule, correction pathway, and archive rule.

12.2.1.3 Cloud Environment use shall not create provider validation, procurement recommendation, public authority approval, data right, service-level warranty, deployment authorization, or execution.

### 12.2.2 Edge Nodes.

12.2.2.1 Edge Nodes are local compute, storage, network, sensor, AI, inference, gateway, or observability environments operating near data sources, communities, infrastructure, field operations, disaster-risk contexts, WFEH-B systems, private wireless systems, or National Node environments.

12.2.2.2 Edge Node records shall identify location class, steward, jurisdiction, data classes, sensor inputs, network dependencies, compute capacity, security controls, privacy controls, geospatial sensitivity, connectivity mode, degraded-mode capability, support class, incident pathway, correction pathway, teardown rule, and archive rule.

12.2.2.3 Edge Node records shall not imply surveillance authority, public authority approval, community consent, infrastructure access, deployment authorization, or execution.

### 12.2.3 Compute Clusters.

12.2.3.1 Compute Clusters are grouped compute resources used for software builds, data processing, AI evaluation, simulation, batch processing, dashboards, Studio workflows, Observatory processing, DRI workflows, and Nexus Core Build tasks.

12.2.3.2 Compute Cluster records shall include architecture, steward, resource class, workload class, access model, queue rules where applicable, data residency, security controls, logging, monitoring, cost and support status, dependency records, workload restrictions, correction pathway, teardown rule, and archive rule.

12.2.3.3 Cluster access shall not create unrestricted data rights, production approval, provider validation, service warranty, deployment authorization, or execution.

### 12.2.4 HPC Environments.

12.2.4.1 HPC Environments are high-performance computing systems used for large-scale research, simulation, AI workloads, climate and weather-related modeling support, hydrology, digital twins, disaster-risk modeling, cyber-physical testing, geospatial workloads, frontier science infrastructure, and Nexus Universe Core Build support.

12.2.4.2 HPC Environment records shall identify operator, facility, jurisdiction, access pathway, workload class, data class, AI-use class, queue rules, storage rules, software environment, reproducibility package, security controls, privacy controls, output review, cost and support record, incident pathway, correction pathway, teardown rule, and archive rule.

12.2.4.3 HPC access, results, or demonstrations shall not create public authority approval, scientific certainty, operational command, certification, procurement status, financeability, insurance approval, deployment authorization, or execution.

### 12.2.5 Sovereign Compute Environments.

12.2.5.1 Sovereign Compute Environments are compute environments designed to satisfy national, jurisdictional, public authority, data sovereignty, data localization, protected knowledge, or cross-border control requirements.

12.2.5.2 Sovereign Compute records shall identify jurisdiction, steward, national pathway, public authority dependencies where applicable, data residency controls, access controls, cross-border restrictions, localization rules, sovereign support arrangements, security controls, privacy controls, continuity rules, correction pathway, and archive rule.

12.2.5.3 Sovereign Compute status shall not imply public authority approval, national endorsement, procurement approval, public finance allocation, deployment authorization, or execution.

### 12.2.6 Storage Systems.

12.2.6.1 Storage Systems include object storage, file storage, databases, repositories, data lakes, metadata stores, model stores, artifact stores, logs, backups, archives, national mirrors, secure repositories, and controlled-room storage.

12.2.6.2 Storage records shall identify steward, location, jurisdiction, data classes, access class, encryption status where appropriate, retention rule, deletion rule, sealing rule, backup rule, restore testing status, archive rule, incident pathway, correction pathway, and teardown rule.

12.2.6.3 Storage availability shall not create data rights, open data status, public authority record status, handoff permission, service warranty, deployment authorization, or execution.

### 12.2.7 Secure Enclaves.

12.2.7.1 Secure Enclaves are protected compute environments used to process restricted, sensitive, sovereign, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, or handoff-recipient-only data under heightened controls.

12.2.7.2 Secure Enclave records shall identify enclave type, access controls, approved workloads, approved users, data classes, AI-use labels, no-download controls, logging where appropriate, output review, attestation where available, incident pathway, correction pathway, and archive rule.

12.2.7.3 Secure Enclave use shall not create public authority approval, data right, financeability, insurance approval, procurement status, deployment authorization, or execution.

### 12.2.8 Network Configurations.

12.2.8.1 Network Configurations include architectures, diagrams, routing rules, segmentation records, firewall rules, identity integrations, private connectivity, VPNs, zero-trust access, wireless configurations, AI-RAN contexts, O-RAN contexts, private wireless contexts, edge network patterns, Observatory connectivity, Studio connectivity, and Core Build connectivity.

12.2.8.2 Network Configuration records shall be classified for cyber and infrastructure sensitivity. Public-safe versions shall be used where publication could expose security risk.

12.2.8.3 Network Configuration records shall not be operational commands, provider validation, public authority approval, deployment authorization, or execution instructions.

### 12.2.9 Sensor Networks.

12.2.9.1 Sensor Networks include physical or digital sensor arrangements used for observability, DRI signals, WFEH-B monitoring, climate and environment monitoring, infrastructure monitoring, geospatial inputs, edge workflows, Studio simulations, National Portfolio records, or Nexus Universe demonstrations.

12.2.9.2 Sensor Network records shall identify purpose, steward, location class, data class, calibration status where applicable, privacy implications, geospatial sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, public authority dependencies, cyber controls, connectivity, data-use labels, AI-use labels, correction pathway, and archive rule.

12.2.9.3 Sensor Network use shall not create surveillance authority, public warning authority, public authority approval, community consent, operational command, deployment authorization, or execution.

### 12.2.10 Observatory Nodes.

12.2.10.1 Observatory Nodes are infrastructure objects supporting Nexus Observatory functions, including signal collection, data routing, DRI inputs, dashboards, sensor integration, geospatial workflows, edge processing, digital twin inputs, degraded-mode awareness, public-safe observability outputs, and National Portfolio observability records.

12.2.10.2 Observatory Node records shall identify jurisdiction, steward, data sources, signal classes, infrastructure dependencies, network dependencies, data-use labels, AI-use labels, public-safe status, geospatial controls, cyber controls, public authority boundaries, support class, correction pathway, and archive rule.

12.2.10.3 Observatory Node status shall not imply surveillance authority, public warning authority, public authority approval, emergency command, deployment authorization, or execution.

### 12.2.11 Studio Runtime Environments.

12.2.11.1 Studio Runtime Environments are controlled compute environments used for dashboards, digital twins, simulations, scenarios, AI workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader rooms, insurance-reader rooms, donor-reader rooms, Nexus Universe demonstrations, and handoff demonstrations.

12.2.11.2 Studio Runtime records shall include purpose, steward, users, data classes, AI-use labels, software objects, model objects, access controls, no-command rules, no-write-back rules, output review, logging where appropriate, shutdown triggers, support class, correction pathway, and archive rule.

12.2.11.3 Studio Runtime use shall not create public authority decision, finance approval, insurance approval, procurement status, deployment authorization, operational command, or execution.

### 12.2.12 Core Build Environments.

12.2.12.1 Core Build Environments are temporary or continuing compute, network, software, data, AI, dashboard, repository, Studio, observability, and collaboration environments used to support Nexus Core Build, Nexus Universe, Foundry build streams, National Portfolio preparation, Competence Cell work, and annual surge capability.

12.2.12.2 Core Build Environment records shall identify build period, steward, participating teams, access classes, infrastructure providers, support classes, repository links, data classes, AI-use classes, network architecture, security controls, public-safe controls, output routing, Registry links, Marketplace links, Reports links, Grid links, TRL links, handoff dependency links, teardown rule, and archive rule.

12.2.12.3 Core Build Environment intensity shall not imply execution. Temporary stack shall produce permanent record; annual surge shall support year-round development; technical excellence shall remain bounded by public-good records, review, release, correction, archive, and lawful handoff discipline.

## 12.3 Network and Telecom Capability Patterns

### 12.3.1 AI-RAN Records.

12.3.1.1 AI-RAN Records shall document artificial-intelligence-enabled radio access network concepts, test contexts, edge inference patterns, network optimization patterns, observability uses, resilience uses, private wireless use cases, public authority learning contexts, and handoff dependencies relevant to NAF work.

12.3.1.2 AI-RAN Records shall include architecture notes, data flows, AI-use labels, spectrum dependencies, cyber risks, interoperability notes, provider-neutrality notes, public authority dependencies, test environment, limitations, support class, correction pathway, and archive rule.

12.3.1.3 AI-RAN Records shall not create telecom authorization, spectrum right, provider validation, network deployment approval, public authority approval, procurement status, financeability, or execution.

### 12.3.2 O-RAN Records.

12.3.2.1 O-RAN Records shall document open radio access network concepts, interfaces, interoperability questions, testing profiles, vendor-neutral patterns, security considerations, edge dependencies, public-good use cases, National Portfolio relevance, and handoff dependencies.

12.3.2.2 O-RAN Records shall distinguish standards-interface awareness from standards authority, testing profile from certification, demonstration from deployment, and provider contribution from provider validation.

12.3.2.3 O-RAN Records shall not create conformance certification, telecom approval, procurement recommendation, public authority approval, deployment authorization, or execution.

### 12.3.3 Private Wireless Records.

12.3.3.1 Private Wireless Records shall document local wireless network contexts used or considered for campuses, disaster-resilience environments, WFEH-B systems, ports, industrial sites, public authority learning, Observatory nodes, edge environments, Nexus Universe venues, Core Build environments, or handoff contexts.

12.3.3.2 Private Wireless Records shall include spectrum dependencies, site dependencies, host dependencies, provider-neutrality notes, cyber controls, data flows, edge compute patterns, public authority dependencies, operational boundaries, safeguard issues, correction pathway, and archive rule.

12.3.3.3 Private Wireless Records shall not create spectrum authorization, site access, public authority approval, procurement approval, provider validation, deployment authorization, or execution.

### 12.3.4 Edge Network Records.

12.3.4.1 Edge Network Records shall document connectivity between edge nodes, sensors, local compute, cloud environments, Studio environments, Observatory nodes, DRI dashboards, National Nodes, and Core Build environments.

12.3.4.2 Edge Network Records shall include topology class, data flow, access control, latency needs, bandwidth needs, degraded-mode behavior, offline mode, cyber controls, geospatial sensitivity, infrastructure sensitivity, support class, correction pathway, and archive rule.

12.3.4.3 Edge Network Records shall not create operational command, network deployment authorization, provider validation, public authority approval, or execution.

### 12.3.5 5G and 6G-Relevant Interface Records.

12.3.5.1 5G and 6G-Relevant Interface Records shall document future-network relevance for AI-RAN, O-RAN, private wireless, low-latency sensing, edge AI, digital twins, robotics, drones, IoT, OT, IIoT, disaster resilience, WFEH-B systems, Observatory nodes, and Nexus Core Build environments.

12.3.5.2 Such records shall identify use case, interface question, standards-interface note, spectrum dependency, provider-neutrality condition, security risk, public authority dependency, testbed status, limitations, correction pathway, and archive rule.

12.3.5.3 5G or 6G relevance shall not create standards conformance, telecom authorization, provider validation, procurement status, public authority approval, deployment authorization, or execution.

### 12.3.6 Spectrum Dependency Notes.

12.3.6.1 Spectrum Dependency Notes shall record whether a wireless, telecom, sensor, private network, drone, robotics, edge, AI-RAN, O-RAN, Observatory, or Core Build use case depends on spectrum access, licensing, regulatory approval, coordination, site permissions, or public authority action.

12.3.6.2 Spectrum Dependency Notes shall identify competent authority dependencies, jurisdictional context, assumptions, limitations, public authority boundary notices, provider-neutrality notes, handoff implications, correction pathway, and archive rule.

12.3.6.3 Spectrum Dependency Notes shall not be spectrum authorization, regulatory approval, public authority action, procurement support, deployment authorization, or execution.

### 12.3.7 Interoperability Profiles.

12.3.7.1 Interoperability Profiles shall document how compute, network, software, data, AI, APIs, sensors, dashboards, Studio workflows, Observatory nodes, DRI systems, Registry systems, Marketplace systems, National Nodes, and handoff-recipient systems may connect or exchange information within defined scope.

12.3.7.2 Interoperability Profiles shall include interface description, protocol object, schema object, API contract, data-use label, AI-use label, authentication method, authorization method, versioning, testing profile, limitations, standards-interface record, correction pathway, and archive rule.

12.3.7.3 Interoperability Profiles shall not create certification, standards conformance, provider validation, public authority approval, data rights, deployment authorization, or execution.

### 12.3.8 Provider-Neutrality Notes.

12.3.8.1 Provider-Neutrality Notes shall identify where cloud, telecom, compute, AI, storage, network, sensor, dashboard, software, or infrastructure work includes provider participation, provider dependencies, provider credits, provider tools, provider APIs, provider reference architectures, provider services, or provider support.

12.3.8.2 Provider-Neutrality Notes shall record contribution type, dependency level, portability, exit path, comparable alternatives where appropriate, conflicts, public claims limits, procurement-neutrality controls, sponsorship controls, support class, correction pathway, and archive rule.

12.3.8.3 Provider-Neutrality Notes shall prevent provider contribution from becoming provider validation, procurement preference, endorsement, lock-in, hidden exclusivity, public authority influence, finance signal, or execution control.

### 12.3.9 Network Resilience Records.

12.3.9.1 Network Resilience Records shall document redundancy, failover, backup connectivity, offline mode, low-bandwidth mode, degraded-mode operation, secure remote access, network segmentation, incident response, disaster recovery, continuity plans, and recovery testing for NAF compute and infrastructure environments.

12.3.9.2 Network Resilience Records may support public-good continuity, Nexus Universe readiness, National Node continuity, Observatory continuity, DRI continuity, Studio continuity, Reports continuity, Marketplace continuity, Registry continuity, and handoff dependency context.

12.3.9.3 Network Resilience Records shall not create service-level warranty, infrastructure certification, public authority approval, deployment authorization, emergency command, or execution.

### 12.3.10 Degraded-Mode Awareness Records.

12.3.10.1 Degraded-Mode Awareness Records shall document how infrastructure, software, data, AI, Observatory, DRI, Studio, Campaign, Academy, Reports, Marketplace, Registry, Nexus Universe, National Node, and handoff workflows behave under disrupted connectivity, reduced compute, partial data availability, cyber incident, disaster conditions, cloud outage, network outage, edge isolation, power limitation, or public authority-sensitive crisis-learning conditions.

12.3.10.2 Degraded-Mode Awareness Records shall identify what remains available, what is disabled, what becomes read-only, what requires manual review, what public-safe limits apply, what data risks increase, what AI use is suspended, what handoff pathways are paused, and what correction or archive actions apply.

12.3.10.3 Degraded-mode planning shall not create emergency command authority, service guarantee, public warning authority, deployment authorization, or execution.

## 12.4 Infrastructure Governance

### 12.4.1 Environment Intake.

12.4.1.1 Environment Intake shall record the proposed entry or creation of any cloud environment, edge node, compute cluster, HPC environment, sovereign compute environment, storage system, secure enclave, network configuration, sensor network, Observatory node, Studio runtime environment, Core Build environment, or handoff-relevant infrastructure into NAF.

12.4.1.2 Environment Intake shall identify purpose, steward, provider, host, jurisdiction, data classes, AI-use classes, user classes, access model, network dependencies, public authority dependencies, cost and support status, provider-neutrality issues, security needs, privacy needs, data residency needs, continuity needs, teardown rule, correction pathway, and archive rule.

12.4.1.3 Environment Intake shall not authorize production use, public authority use, procurement, finance, deployment, or execution by itself.

### 12.4.2 Provider-Neutrality Review.

12.4.2.1 Provider-Neutrality Review shall determine whether an infrastructure object creates undue dependence, hidden exclusivity, sponsor influence, provider control, procurement bias, standards-interface overclaim, data enclosure, AI-service enclosure, or lock-in inconsistent with public-good operation.

12.4.2.2 Provider-Neutrality Review shall record provider contribution, dependency level, portability, exit plan, comparable alternatives where appropriate, licensing, service terms, data handling terms, support limits, conflicts, public claims controls, correction pathway, and archive rule.

12.4.2.3 Provider-Neutrality Review shall not prohibit provider use; it shall prevent provider use from becoming provider control.

### 12.4.3 Security Review.

12.4.3.1 Security Review shall assess identity and access management, least privilege, network segmentation, encryption where appropriate, secrets management, logging where appropriate, monitoring, vulnerability management, dependency risk, secure configuration, incident response, backup, restore testing, secure enclave needs, secure-room needs, cyber-sensitive data handling, and public-safe disclosure risk.

12.4.3.2 Security Review shall be proportionate to risk, release class, support class, data class, AI-use class, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, geospatial sensitivity, and handoff relevance.

12.4.3.3 Security Review shall not create security certification, legal compliance determination, service warranty, deployment authorization, or execution.

### 12.4.4 Data Residency Review.

12.4.4.1 Data Residency Review shall determine whether data, metadata, logs, backups, model artifacts, prompts, outputs, secure-room records, Studio records, Observatory records, DRI records, National Portfolio records, Nexus Universe records, or handoff packages may be stored, processed, mirrored, accessed, or transferred across jurisdictions.

12.4.4.2 Data Residency Review shall consider data sovereignty, data localization, privacy law, public authority restrictions, community safeguards, Indigenous protocol-sensitive controls where applicable, protected knowledge, health data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, provider terms, cross-border controls, and conflict-of-law issues.

12.4.4.3 Data Residency Review shall not create data rights, public authority approval, legal advice by default, deployment authorization, or execution.

### 12.4.5 Cost and Support Record.

12.4.5.1 Cost and Support Records shall document infrastructure costs, credits, donated services, sponsored support, provider support, internal support, support class, funding dependencies, renewal dates, usage limits, cost risks, continuity risks, end-of-support risks, and exit options.

12.4.5.2 Cost and Support Records may support sustainability, budgeting, public-good continuity, National Node planning, Nexus Universe planning, Foundry planning, and handoff dependency context.

12.4.5.3 Cost and Support Records shall not create financeability, funding commitment, donor commitment, public finance allocation, procurement approval, service warranty, or execution.

### 12.4.6 Access Model.

12.4.6.1 Access Model records shall define who may access infrastructure, under what role, for what purpose, in what environment, with what permissions, under what authentication, with what logging where appropriate, for what duration, and subject to what review.

12.4.6.2 Access Models shall implement least privilege, role separation, data-use labels, AI-use labels, secure-room restrictions, no-download controls where appropriate, no-command rules where appropriate, no-write-back rules where applicable, public authority boundary controls, finance and procurement boundary controls, and handoff controls.

12.4.6.3 Access Model failure shall trigger incident response, access recertification, correction, suspension, withdrawal, or archive where necessary.

### 12.4.7 Logging.

12.4.7.1 Logging may be used to support security, access review, audit, reproducibility, verifiable compute, incident response, correction, cost monitoring, output review, and archive.

12.4.7.2 Logging shall be governed by privacy, data minimization, purpose limitation, retention, access control, data residency, youth protection, protected knowledge, public authority sensitivity, cyber sensitivity, and cross-border controls.

12.4.7.3 Logging shall not become surveillance, worker ranking, learner ranking, social scoring, community profiling, public authority profiling, or unrelated monitoring.

### 12.4.8 Monitoring.

12.4.8.1 Monitoring shall be used to assess infrastructure health, uptime where applicable, performance, security events, capacity, cost, backups, network status, degraded-mode status, storage limits, access anomalies, AI workload anomalies, and incident indicators.

12.4.8.2 Monitoring shall include escalation triggers, incident pathways, correction pathways, support class linkage, status records, public-safe notices where applicable, and archive linkage.

12.4.8.3 Monitoring shall not create service-level warranty, public warning authority, operational command, public authority action, deployment authorization, or execution.

### 12.4.9 Continuity Planning.

12.4.9.1 Continuity Planning shall define how infrastructure objects remain available, recover, degrade safely, fail over, back up, restore, restrict functions, suspend AI use, preserve records, protect sensitive data, and maintain public-good memory during outage, incident, disaster, cyber event, provider failure, funding interruption, network disruption, or Nexus Universe surge.

12.4.9.2 Continuity Planning shall include redundancy, failover, backup, restore testing, offline mode, low-bandwidth mode, degraded-mode awareness, manual fallback, support responsibilities, incident response, public-safe notices, correction, and archive.

12.4.9.3 Continuity Planning shall not create service guarantee, emergency command authority, public authority approval, deployment authorization, or execution.

### 12.4.10 Teardown and Archive.

12.4.10.1 Teardown shall be used when infrastructure is temporary, expired, unsafe, unsupported, superseded, withdrawn, recalled, non-continuing, no longer needed, or no longer permitted. Teardown shall address access revocation, data export where permitted, data deletion where required, data sealing where required, backup retention, key revocation, credential revocation, provider offboarding, cost closure, dependency updates, public-safe notices where appropriate, and archive records.

12.4.10.2 Archive shall preserve environment records, configuration records, support records, cost records, access records where retained lawfully, incident records, correction records, release records, dependency records, continuity records, teardown records, and archive-not-current notices.

12.4.10.3 Teardown and Archive shall not erase accountability. They shall preserve institutional memory while preventing obsolete infrastructure from being treated as current capability.

## 12.5 Resilience and Continuity

### 12.5.1 Redundancy.

12.5.1.1 Redundancy shall be used where infrastructure failure would materially affect public-good continuity, evidence preservation, public-safe reporting, National Portfolio memory, Nexus Universe operations, DRI workflows, Observatory workflows, Studio workflows, Registry status truth, Marketplace discovery, Reports publication, or handoff dependency records.

12.5.1.2 Redundancy may include multi-region storage, replicated repositories, backup compute, alternative providers, National Node mirrors, local copies, offline packages, low-bandwidth pathways, and manual fallback.

12.5.1.3 Redundancy shall not create service warranty, uptime guarantee, public authority approval, or deployment authorization.

### 12.5.2 Failover.

12.5.2.1 Failover shall define how systems move from primary to secondary infrastructure during outage, incident, disaster, provider failure, network disruption, or Core Build surge.

12.5.2.2 Failover records shall identify triggers, responsible roles, data consistency rules, access rules, security controls, public-safe implications, AI-use implications, handoff implications, correction pathway, and archive rule.

12.5.2.3 Failover capability shall not create service-level guarantee, emergency command, operational authority, deployment authorization, or execution.

### 12.5.3 Backup.

12.5.3.1 Backup shall preserve data, metadata, software, repositories, models, documentation, Registry records, Marketplace records, Reports, Studio workflows, DRI records, Observatory records, Grid inputs, TRL notes, National Portfolio records, Nexus Universe records, and handoff dependency records according to data class, rights, retention, sensitivity, and archive rules.

12.5.3.2 Backup shall be secure, access-controlled, tested where appropriate, data-residency-aware, deletion-aware, sealing-aware, and correction-aware.

12.5.3.3 Backup shall not override deletion duties, sealing duties, data sovereignty, cross-border restrictions, protected knowledge controls, or consent withdrawal where applicable.

### 12.5.4 Restore Testing.

12.5.4.1 Restore Testing shall verify whether backups and continuity records can restore systems, data, repositories, models, dashboards, workflows, and records within stated scope and conditions.

12.5.4.2 Restore Testing shall record test date, scope, environment, result, limitations, failed components, corrective actions, residual risks, and archive update.

12.5.4.3 Restore Testing shall not create service warranty, security certification, production approval, public authority approval, deployment authorization, or execution.

### 12.5.5 Offline Mode.

12.5.5.1 Offline Mode shall support continued public-good learning, evidence review, data collection, field work, community engagement, Academy work, Foundry work, Observatory work, DRI work, Studio preparation, or National Portfolio work where connectivity is unavailable or unsafe.

12.5.5.2 Offline Mode shall define what data may be stored locally, how it is secured, what functions are disabled, what AI use is prohibited, what sync rules apply, what conflict rules apply, what public-safe limits apply, and what correction pathway applies.

12.5.5.3 Offline Mode shall not authorize uncontrolled collection, surveillance, operational command, public warning, deployment, or execution.

### 12.5.6 Low-Bandwidth Mode.

12.5.6.1 Low-Bandwidth Mode shall support accessibility, inclusion, field resilience, disaster conditions, rural and remote participation, low-connectivity National Nodes, and continuity of essential public-good workflows.

12.5.6.2 Low-Bandwidth Mode may include compressed datasets, text-first interfaces, offline packages, delayed sync, simplified dashboards, static Reports, metadata-only views, and reduced AI workflows.

12.5.6.3 Low-Bandwidth Mode shall preserve security, privacy, data-use labels, AI-use labels, public-safe controls, correction pathways, and archive rules.

### 12.5.7 Degraded-Mode Awareness.

12.5.7.1 Degraded-Mode Awareness shall identify which functions remain safe and useful when infrastructure is degraded. It shall define read-only states, manual review states, AI-disabled states, restricted publication states, data-room-only states, public-safe-only states, handoff-paused states, and archive-protection states.

12.5.7.2 Degraded-mode outputs shall carry limitations and shall not overstate confidence, completeness, readiness, public authority relevance, finance-readiness, procurement relevance, or operational usefulness.

12.5.7.3 Degraded-Mode Awareness shall not create emergency command, public warning authority, service warranty, deployment authorization, or execution.

### 12.5.8 Incident Response.

12.5.8.1 Infrastructure Incident Response shall apply to outage, unauthorized access, credential exposure, data breach, cyber incident, AI workload incident, provider outage, network failure, storage failure, backup failure, restore failure, denial of service, insecure configuration, infrastructure misrouting, public authority boundary incident, finance boundary incident, procurement boundary incident, protected knowledge exposure, or handoff overclaim involving compute infrastructure.

12.5.8.2 Incident Response may include containment, access revocation, credential rotation, data freeze, AI-use freeze, technical freeze, claims freeze, public-safe notice, Registry update, Marketplace action, Reports correction, Studio restriction, Grid correction, TRL correction, Nexus Universe correction, handoff recall, teardown, sealing, deletion, archive, and corrective action.

12.5.8.3 Infrastructure Incident Response shall prioritize safety, rights, public-good integrity, correctionability, public-safe communication, and role separation.

### 12.5.9 Disaster Recovery.

12.5.9.1 Disaster Recovery shall define how compute, storage, networks, repositories, dashboards, records, Studio environments, Observatory nodes, DRI systems, Marketplace systems, Registry systems, Reports systems, Academy systems, Campaign systems, Foundry systems, Nexus Universe systems, National Node systems, and handoff records recover after disruption.

12.5.9.2 Disaster Recovery shall include recovery objectives where appropriate, priority systems, backup locations, restore procedures, communication paths, support roles, public-safe notices, degraded-mode procedures, manual fallback, correction records, and archive records.

12.5.9.3 Disaster Recovery shall not imply emergency command authority, public authority approval, public warning authority, service guarantee, deployment authorization, or execution.

### 12.5.10 Continuity Archive.

12.5.10.1 Continuity Archive shall preserve records necessary to understand infrastructure continuity, including architecture records, dependency records, provider records, support records, backup records, restore records, incident records, failover records, degraded-mode records, disaster recovery records, teardown records, correction records, and archive-not-current notices.

12.5.10.2 Continuity Archive shall support institutional memory, Nexus Network preservation, National Node continuity, Nexus Universe cycle learning, correction, and lawful handoff context.

12.5.10.3 Continuity Archive shall not be treated as current operational status unless separately updated and recorded.

## 12.6 Compute and Infrastructure Boundaries

### 12.6.1 Cloud Contribution Is Not Provider Validation.

12.6.1.1 Cloud credits, hosting, compute donations, technical support, architecture assistance, tooling access, marketplace credits, AI service credits, or infrastructure support from a provider shall be recorded as contribution only.

12.6.1.2 Provider contribution shall not validate the provider, approve its technology, create procurement preference, create supplier status, create standards conformance, create financeability, create insurance approval, create public authority approval, authorize deployment, or create execution authority.

### 12.6.2 Hosted Environment Is Not Public Authority Approval.

12.6.2.1 Hosting an environment in a jurisdiction, public cloud region, sovereign cloud, public authority-facing environment, National Node environment, Nexus Universe environment, or secure-room context shall not create public authority approval, public authority record status, permit, license, public finance allocation, procurement decision, public warning authority, or emergency command.

12.6.2.2 Public authority action must be separately and lawfully recorded by competent public authority actors outside NAF’s default compute posture.

### 12.6.3 Compute Access Is Not Data Right.

12.6.3.1 Access to compute, cloud resources, HPC resources, secure enclaves, Studio environments, data rooms, secure rooms, edge nodes, repositories, dashboards, or APIs shall not create a right to access, copy, download, export, reuse, publish, train on, transfer, commercialize, or hand off data.

12.6.3.2 Data rights remain governed by data-use labels, AI-use labels, rights review, consent or permission where required, law, contract, public authority restrictions, community safeguards, Indigenous protocols where applicable, privacy, cybersecurity, protected knowledge rules, and handoff dependency records.

### 12.6.4 Infrastructure Readiness Is Not Deployment Authorization.

12.6.4.1 Infrastructure readiness, successful testing, connectivity, cloud availability, HPC availability, edge readiness, private wireless readiness, network resilience, secure-room readiness, Studio readiness, Core Build readiness, Grid input, TRL note, Nexus Universe demonstration, or handoff dependency package shall not authorize deployment.

12.6.4.2 Deployment requires separate lawful authority, operational accountability, security review, privacy review, data rights, public authority approvals where required, procurement approvals where required, finance and insurance decisions where relevant, community processes where required, Indigenous processes where applicable, and recipient responsibility.

### 12.6.5 Support Status Is Not Service-Level Warranty.

12.6.5.1 Infrastructure Support Status shall describe available support, expected support, time-limited support, maintainer support, provider support, community support, National Node support, Studio support, Foundry support, handoff-recipient support, deprecated support, archived support, or non-continuing status.

12.6.5.2 Support Status shall not create warranty, uptime guarantee, service-level agreement, security guarantee, operational guarantee, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution unless separately and lawfully contracted outside NAF.

### 12.6.6 Sovereign Hosting Is Not Public Authority Decision by Default.

12.6.6.1 Sovereign hosting, national hosting, local data residency, national repository mirroring, National Node infrastructure, public authority-facing compute, or jurisdiction-sensitive compute shall not by itself create public authority decision, national endorsement, legal compliance determination, procurement approval, public finance allocation, certification, deployment authorization, or execution.

12.6.6.2 Sovereign hosting is a control condition and public-good capability pattern. It preserves jurisdictional sensitivity, data sovereignty, national ownership, and lawful routing; it does not replace competent public authority action.

12.6.6.3 The final compute rule of Part XII is that NAF may use cloud, edge, HPC, sovereign compute, secure enclaves, networks, storage, sensor infrastructure, Observatory nodes, Studio runtimes, Core Build environments, AI-RAN and O-RAN records, private wireless patterns, verifiable compute, and compute-to-data workflows only through governed records, provider-neutrality controls, access models, security review, data residency review, continuity planning, incident response, correctionability, teardown, archive, and no-conversion discipline. No compute resource, hosted environment, cloud contribution, edge node, HPC run, sovereign compute environment, network profile, spectrum dependency note, secure enclave, Studio runtime, Core Build environment, Observatory node, DRI dashboard, verifiable compute record, infrastructure readiness status, support class, Grid input, TRL note, Nexus Universe demonstration, National Portfolio object, or handoff dependency package shall become provider validation, data right, certification, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, operation, command, agency, employment, service warranty, or execution by implication.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/operations/frameworks/nexus-agile-framework-naf/xii.-compute.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.