# XVIII. INFRA

## 18.1 Distributed Infrastructure Doctrine

### 18.1.1 Cloud as distributed resource layer.

Cloud infrastructure under the Distributed Digital Public Goods Framework shall be treated as a distributed resource layer for hosting, computing, storing, testing, reviewing, publishing, securing, routing, and preserving digital public-good objects where cloud use is lawful, proportionate, secure, cost-aware, jurisdictionally appropriate, and aligned with DDPGF public-good discipline. Cloud environments may support repositories, software services, APIs, dashboards, Nexus Marketplace services, Nexus Registry records, Nexus Reports publication workflows, Nexus Academy and Risk Academy learning objects, Nexus Studio workflows, data rooms, secure rooms, compute-to-data workflows, model evaluation environments, DRI dashboards, GRIx services, Observatory data flows, National Portfolio records, Nexus Universe digital infrastructure, and lawful handoff context.

Cloud use shall not create provider dependency by default. Each cloud-supported object shall record provider context, service class, jurisdictional context, data residency posture, support class, security controls, cost and continuity assumptions, portability constraints, backup approach, exit path, correction pathway, and boundary notices. Cloud availability shall not mean public authority approval, procurement selection, provider validation, deployment authorization, service-level warranty, financeability, insurability, or execution authority.

### 18.1.2 Edge as local capability layer.

Edge infrastructure under DDPGF shall be treated as a local capability layer for bringing computation, storage, sensing, observability, public-safe processing, low-latency workflows, degraded-mode capacity, field-adjacent analysis, and national or community-relevant digital public-good functions closer to place-based contexts. Edge nodes may support Observatory signals, sensor networks, WFEH-B monitoring, DRI workflows, public-safe dashboards, local data preprocessing, digital twin inputs, AI inference under controls, low-bandwidth access, offline packages, secure-room extensions, National Node workflows, and Nexus Universe arena demonstrations.

Edge use shall be governed by location sensitivity, public-safe controls, cyber-physical risk, data sovereignty, public authority boundaries, community safeguards, protected knowledge controls, physical security, maintenance responsibility, provider neutrality, and lawful handoff discipline. Edge infrastructure shall not imply surveillance authority, operational command, public authority decision-making, emergency warning authority, deployment authorization, or local execution authority by default.

### 18.1.3 Sovereign compute as jurisdiction-sensitive capability.

Sovereign compute under DDPGF shall refer to compute environments designed or selected to respect jurisdictional, national, public authority-sensitive, data sovereignty, data localization, protected knowledge, community safeguard, cross-border transfer, security, and lawful access constraints. Sovereign compute may support national repositories, National Node infrastructure, public authority learning rooms, controlled datasets, compute-to-data workflows, secure enclaves, AI evaluation, DRI datasets, Observatory data, National Portfolio records, Nexus Studio workflows, and handoff-recipient-only packages requiring heightened jurisdictional control.

Sovereign compute shall be recorded as a jurisdiction-sensitive capability, not as public authority approval. Its use shall not imply that a public authority has approved the workload, that data may be transferred or reused without restriction, that the provider is validated, that the system is certified, or that deployment is authorized. Sovereign compute records shall identify hosting context, data residency status, access model, lawful access risks, provider dependencies, security controls, continuity arrangements, and teardown rules.

### 18.1.4 Federated storage as resilience layer.

Federated storage under DDPGF shall support resilience, public-good continuity, national ownership, repository independence, correctionability, and distributed access by allowing digital public-good objects and metadata to be preserved across appropriate global, regional, national, institutional, controlled, secure, public, and archive repositories. Federated storage may include Git repositories, data repositories, model repositories, Zenodo-style publication repositories, national repositories, controlled repositories, archive mirrors, secure storage, metadata-only indexes, Marketplace metadata, Registry status records, and National Portfolio stores.

Federated storage shall preserve version truth, access class, license class, data-use labels, AI-use labels, public-safe status, sensitivity class, correction records, withdrawal records, recall records, archive labels, and boundary notices. Federation shall not mean unrestricted access, uncontrolled replication, cross-border transfer permission, loss of national ownership, standards equivalence, public authority approval, or operational authority. Where an object is mirrored, the mirror shall not override Registry status truth.

### 18.1.5 Compute-to-data as restricted-data default.

Compute-to-data shall be the preferred default for restricted, sovereign-sensitive, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, health-sensitive, youth-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, Observatory, DRI, National Portfolio, and handoff-recipient-only data where analysis is required but raw data export would create avoidable risk. Compute-to-data workflows shall bring approved workloads, approved users, approved queries, and approved tools to the data under controlled conditions rather than moving raw data to uncontrolled environments.

Compute-to-data shall require workload approval, user approval, query controls, output review, privacy-preserving analytics where appropriate, confidential computing where appropriate, secure enclave use where appropriate, logging, audit records, no raw data extraction by default, incident response, and archive rules. Compute-to-data shall not create open data status, data rights, AI training permission, cross-border transfer authorization, protected knowledge permission, handoff permission, public authority approval, deployment authorization, or execution authority.

### 18.1.6 Network resilience as public-good condition.

Network resilience shall be treated as a public-good condition for digital-public-good continuity, especially where DDPGF objects support disaster risk reduction, disaster risk intelligence, WFEH-B systems, public-safe reporting, national capacity formation, learning continuity, secure collaboration, Observatory operations, Nexus Universe operations, and lawful handoff preparation. Network resilience may include redundancy, failover, multi-region routing, low-bandwidth modes, offline modes, degraded-mode awareness, secure connectivity, edge connectivity, private wireless relevance, AI-RAN and O-RAN interface records, telecom dependency records, and continuity planning.

Network resilience shall not create telecommunications authority, spectrum authority, public warning authority, operational command, emergency response authority, public authority decision-making, provider validation, service guarantee, deployment authorization, or execution authority. Network resilience records shall identify dependencies, limitations, provider relationships, regulatory dependencies, continuity assumptions, and correction pathways.

### 18.1.7 Infrastructure without provider lock-in by default.

DDPGF infrastructure shall be designed to avoid unnecessary provider lock-in, proprietary capture, hidden dependency, non-portable architecture, opaque pricing dependency, inaccessible data formats, closed APIs, restrictive licenses, exclusive hosting, sponsor capture, provider capture, or downstream implementation constraint inconsistent with public-good purpose. Provider-specific services may be used where justified by capability, security, cost, availability, jurisdiction, support, or national context, but such use shall be recorded, reviewable, portable where feasible, and bounded by provider-neutrality controls.

Infrastructure records shall identify portability strategy, exit path, backup path, interoperability profile, alternative hosting options where feasible, dependency risks, data export constraints, license constraints, support class, and correction path. Provider contribution, hosted access, cloud credits, compute support, infrastructure sponsorship, or technical assistance shall not create provider validation, preferred status, procurement advantage, technical endorsement, or handoff routing control.

### 18.1.8 Infrastructure without operational authority by implication.

Infrastructure under DDPGF shall support public-good workflows, learning, review, evidence formation, digital object stewardship, secure collaboration, public-safe publication, National Portfolio preparation, Nexus Universe participation, Registry memory, Marketplace discovery, Studio demonstration, Grid and TRL review, and lawful handoff context. It shall not create operational authority by implication.

No cloud environment, edge node, compute cluster, HPC environment, sovereign compute environment, storage system, data room, secure enclave, network configuration, sensor network, Observatory node, Studio runtime, backup mirror, archive mirror, or National Node infrastructure shall be treated as authorizing deployment, operational command, public authority decision, emergency response, public warning, procurement, finance, insurance, provider selection, community implementation, Indigenous-context implementation, or enterprise execution unless separate competent authority and lawful handoff records exist.

## 18.2 Infrastructure Object Classes

### 18.2.1 Cloud environments.

A **Cloud Environment** shall mean a hosted compute, storage, networking, application, data, model, repository, dashboard, API, Studio, Marketplace, Registry, Reports, Academy, Campaign, Observatory, or secure-room environment provided through cloud infrastructure. Cloud Environment records shall identify provider, region, jurisdictional context, service class, data residency posture, access controls, security controls, monitoring, logging, backup, cost and support assumptions, portability constraints, and teardown plan.

A Cloud Environment shall not validate the provider, approve the workload, create public authority status, create data rights, create procurement status, guarantee service, or authorize deployment by default.

### 18.2.2 Edge nodes.

An **Edge Node** shall mean a local or near-local compute, storage, sensing, preprocessing, caching, inference, dashboard, Observatory, DRI, Studio, or National Node capability deployed closer to a community, field context, facility, sensor network, public-good site, event site, or national context. Edge Node records shall identify location sensitivity, steward, host, provider, access controls, data flows, cyber controls, physical security, connectivity, degraded-mode behavior, maintenance responsibility, public-safe constraints, and teardown conditions.

An Edge Node shall not create surveillance authority, operational command, public authority action, emergency warning authority, local consent, deployment approval, or execution authority by default.

### 18.2.3 Compute clusters.

A **Compute Cluster** shall mean a coordinated group of compute resources used for analysis, simulation, model evaluation, data processing, public-good software testing, dashboard generation, AI workflow review, digital twin processing, DRI processing, Observatory workflows, or National Portfolio analysis. Compute Cluster records shall identify workload class, user class, access model, data class, AI-use class, security controls, dependency records, cost and support records, monitoring, logging, output review, and archive rules.

Compute Cluster availability shall not create data rights, AI training permission, public authority approval, production readiness, deployment authorization, financeability, insurability, or execution authority.

### 18.2.4 HPC environments.

An **HPC Environment** shall mean a high-performance computing environment used for frontier analysis, simulation, risk modeling, climate or Earth systems workflows, digital twins, AI evaluation, optimization, large-scale data processing, complex scenario testing, or research translation. HPC Environment records shall identify workload approval, data classification, compute allocation, access control, queue discipline, cost and support assumptions, reproducibility approach, output review, security controls, and archive rules.

HPC use shall not imply scientific validation, model certification, public authority approval, financeability, procurement status, deployment authorization, or operational execution. HPC outputs remain bounded by assumptions, methods, data limitations, review status, and public-safe controls.

### 18.2.5 Sovereign compute environments.

A **Sovereign Compute Environment** shall mean a compute environment selected or configured to address jurisdictional, national, public authority-sensitive, data residency, cross-border transfer, lawful access, protected knowledge, community safeguard, or national continuity requirements. Sovereign Compute Environment records shall identify hosting jurisdiction, data residency, legal dependencies, access authority, provider dependencies, encryption and key management where applicable, logging, retention, transfer controls, and continuity plan.

Sovereign compute status shall not mean public authority approval, public ownership, regulatory compliance determination, unrestricted national use, provider validation, deployment authorization, or execution authority.

### 18.2.6 Storage systems.

A **Storage System** shall mean an infrastructure object used to store software, data, metadata, models, reports, learning objects, credentials, logs, archives, Registry records, Marketplace metadata, Studio outputs, secure-room records, data-room records, DRI records, Observatory records, National Portfolio records, Nexus Universe records, or handoff packages. Storage System records shall identify access class, encryption where appropriate, jurisdiction, retention, deletion, sealing, backup, replication, archive, incident response, and correction pathway.

Storage availability shall not create access rights, open data status, reuse permission, public authority record status, handoff permission, or deployment authorization.

### 18.2.7 Data rooms.

A **Data Room** as infrastructure object shall mean a controlled environment for viewing, querying, reviewing, documenting, or preparing data objects and data-related evidence. Data Room infrastructure records shall identify room class, data class, user class, access controls, no-download controls, compute-to-data status, output review, logging, audit trails, retention, deletion, sealing, archive, and incident response.

Data Room infrastructure shall not create data rights, AI training rights, cross-border transfer permission, handoff permission, public authority approval, financeability, procurement status, or execution authority.

### 18.2.8 Secure enclaves.

A **Secure Enclave** shall mean an isolated compute or processing environment used to protect data, models, code, keys, workloads, or outputs during controlled analysis or review. Secure Enclave records shall identify enclave purpose, workload class, data class, access model, dependency profile, key management, logging, output controls, teardown rules, and incident response. Secure enclaves may support compute-to-data, confidential computing, secure model evaluation, protected knowledge review, or handoff-recipient-only analysis.

Secure enclave use shall not create security certification, public authority approval, unrestricted data access, deployment authorization, or provider validation.

### 18.2.9 Network configurations.

A **Network Configuration** shall mean a recorded configuration of connectivity, routing, access, segmentation, firewalling, private networks, edge connectivity, API connectivity, secure-room connectivity, data-room connectivity, Observatory connectivity, Studio connectivity, or National Node connectivity. Network Configuration records shall identify purpose, environment, access rules, segmentation, dependencies, provider context, security controls, monitoring, incident response, and public-safe disclosure limits.

Network Configuration records shall be treated as potentially cyber-sensitive. They shall not be published openly where doing so would create exploitation risk, and they shall not create operational command or deployment authority.

### 18.2.10 Sensor networks.

A **Sensor Network** shall mean a set of sensors, edge devices, telemetry sources, IoT devices, environmental monitors, geospatial inputs, infrastructure monitors, WFEH-B monitors, Observatory feeds, or other signal-generating systems connected to DDPGF workflows. Sensor Network records shall identify sensor class, location sensitivity, data class, ownership or stewardship, access controls, public-safe transformation, cyber controls, calibration status where applicable, data quality, retention, and correction pathway.

Sensor network records shall not create surveillance authority, public warning authority, operational command, public authority approval, community consent, Indigenous consent, or deployment authorization by default.

### 18.2.11 Observatory nodes.

An **Observatory Node** shall mean an infrastructure and workflow object used to collect, receive, process, review, transform, summarize, or route observability signals within Nexus Observatory and related DDPGF workflows. Observatory Nodes may connect to sensors, edge nodes, data rooms, DRI workflows, dashboards, Studio workflows, National Portfolios, Reports, Registry records, Marketplace listings, and Nexus Universe outputs.

Observatory Node records shall identify signal class, data class, public-safe status, sensitivity, cyber controls, degraded-mode status, national context, correction pathway, and boundary notices. Observatory Nodes shall not create surveillance authority, public warning authority, public authority decision, or operational command.

### 18.2.12 Studio runtime environments.

A **Studio Runtime Environment** shall mean the controlled infrastructure supporting Nexus Studio workflows, including dashboards, digital twins, simulations, AI workflows, data workflows, public authority learning workflows, readiness workflows, handoff demonstration workflows, secure review workflows, and public-safe output workflows. Studio Runtime Environment records shall identify access class, user roles, tool permissions, no-write-back rules, no-command rules, no-download rules where applicable, data export controls, AI-use controls, logging, shutdown triggers, output review, and archive rules.

Studio runtime infrastructure shall not authorize deployment, operational command, public authority decision, procurement, finance, insurance, underwriting, community implementation, Indigenous-context implementation, or execution.

## 18.3 Infrastructure Governance

### 18.3.1 Environment intake.

Infrastructure environment intake shall record the purpose, object class, workload class, steward, host, provider, jurisdiction, data class, AI-use class, access class, security needs, privacy needs, public-safe needs, safeguard needs, network needs, storage needs, compute needs, support needs, cost assumptions, continuity needs, teardown expectations, and correction pathway of any proposed cloud, edge, compute, HPC, sovereign compute, storage, data-room, secure enclave, network, sensor, Observatory, or Studio environment.

No infrastructure environment shall proceed merely because capacity is available, donated, sponsored, technically attractive, or provider-supported. Intake shall determine whether the environment is appropriate, necessary, proportionate, provider-neutral, secure, privacy-aware, jurisdictionally suitable, and aligned with DDPGF non-execution boundaries.

### 18.3.2 Provider-neutrality review.

Provider-neutrality review shall assess whether the proposed infrastructure arrangement creates provider capture, vendor preference, hidden lock-in, procurement implication, sponsor influence, proprietary dependency, non-portable architecture, opaque pricing exposure, unsupported dependency, unmanageable exit risk, or public-good enclosure. The review shall record provider contribution, provider role, provider dependencies, alternative options where feasible, portability plan, support class, and boundary notices.

Provider-neutrality review shall not prohibit all provider-specific choices. It shall ensure that choices are transparent, justified, bounded, correctable, and not misrepresented as validation, endorsement, procurement selection, or technical superiority.

### 18.3.3 Security review.

Infrastructure security review shall assess identity and access management, authentication, least privilege, secrets management, repository security, network segmentation, encryption where appropriate, logging, monitoring, dependency exposure, vulnerability management, incident response, backup security, secure enclave design, data-room controls, secure-room controls, AI workflow risks, and public-safe cyber disclosure. Security review shall be proportional to environment risk and lifecycle state.

Security review shall not create security certification, compliance determination, deployment approval, service guarantee, procurement readiness, or public authority approval.

### 18.3.4 Data residency review.

Data residency review shall assess where data is stored, processed, backed up, mirrored, logged, accessed, exported, archived, or deleted. It shall consider public authority-sensitive data, national data, cross-border transfer constraints, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, health data, youth data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, DRI data, Observatory data, National Portfolio data, and handoff-recipient-only data.

Data residency review shall determine whether cloud, edge, sovereign compute, federated storage, compute-to-data, secure enclave, data room, or national repository patterns are required. Data residency approval shall not create unrestricted access, data rights, public authority approval, handoff permission, or deployment authorization.

### 18.3.5 Cost and support record.

Every infrastructure environment shall have a cost and support record identifying known cost drivers, provider charges, credits, sponsorship, in-kind support, support class, maintenance responsibility, renewal risks, funding dependencies, scaling risks, discontinuation risks, exit costs, and archive costs. Cost and support records shall be used for transparency, continuity planning, anti-capture review, and public-good sustainability.

A cost and support record shall not create financeability, budget approval, donor commitment, investment commitment, public finance allocation, procurement approval, warranty, service-level agreement, or execution obligation.

### 18.3.6 Access model.

The infrastructure access model shall define who may access the environment, under what role, for what purpose, for how long, at what permission level, with what authentication, with what logging, with what export rights, and under what revocation conditions. Access models shall distinguish stewards, maintainers, reviewers, contributors, learners, public authority learning participants, providers, sponsors, capital readers, insurers, donors, community participants, National Nodes, Working Groups, Competence Cells, Studio users, data-room users, secure-room users, and handoff recipients.

Access shall not be granted by status, reputation, sponsorship, provider contribution, public authority affiliation, or capital-reader presence alone. Access shall be need-based, purpose-limited, least-privilege, recorded, and correctable.

### 18.3.7 Logging.

Infrastructure logging shall capture access, administrative actions, configuration changes, workload execution, query execution, model execution, API calls, export attempts, permission changes, security events, incidents, shutdowns, corrections, and archive actions appropriate to the environment. Logging shall support auditability, incident response, correction, security review, privacy review, and institutional memory.

Logging shall be privacy-aware and purpose-limited. It shall not be used for unauthorized surveillance, worker monitoring, learner ranking, social scoring, public authority profiling, commercial exploitation, or unrelated analytics by default.

### 18.3.8 Monitoring.

Infrastructure monitoring shall assess availability, performance, security events, access anomalies, dependency failures, cost anomalies, storage capacity, compute capacity, backup status, restore status, API health, data-room health, secure-room health, Studio workflow health, Observatory node health, and degraded-mode conditions. Monitoring shall support resilience, security, continuity, correction, and timely intervention.

Monitoring shall not create service-level warranty, operational command, public authority warning, emergency response authority, or deployment authorization. Monitoring records shall be classified for sensitivity and public-safe disclosure.

### 18.3.9 Continuity planning.

Infrastructure continuity planning shall identify how essential DDPGF objects and services will remain available, recoverable, or archivable during outages, disasters, cyber incidents, provider disruptions, repository failures, funding interruptions, maintainer transitions, access disruptions, or jurisdictional constraints. Continuity planning may include backups, failover, mirrors, offline packages, low-bandwidth versions, degraded-mode operation, national repository mirrors, sovereign compute, secure archives, and non-continuation plans.

Continuity planning shall not create guaranteed service, public authority continuity, regulated critical infrastructure status, or execution obligation.

### 18.3.10 Teardown and archive.

Infrastructure environments shall have teardown and archive rules before use where feasible. Teardown rules shall address data export, data deletion, data sealing, archive transfer, credential revocation, key rotation, repository closure, environment destruction, cost termination, provider disengagement, log retention, incident review, support transition, Registry update, Marketplace update, Reports correction, Studio closure, Grid or TRL update, and handoff recall where applicable.

Teardown and archive shall prevent abandoned infrastructure, unmanaged data, lingering access, hidden provider dependency, unsupported objects, and stale reliance. Archived infrastructure records shall preserve memory without authorizing current use.

## 18.4 Sovereign and National Infrastructure

### 18.4.1 National hosting context.

National hosting context shall record whether infrastructure is hosted within a national jurisdiction, by a national institution, by a National Node, by a national repository, by a public authority-sensitive environment, by a domestic provider, by a sovereign compute provider, by a regional cluster, or through another national arrangement. The record shall identify hosting purpose, data classes, access classes, legal dependencies, provider dependencies, support class, continuity model, and cross-border implications.

National hosting context shall not imply public authority approval, national endorsement, procurement status, public ownership, regulatory compliance determination, or deployment authorization unless separately recorded by a competent authority.

### 18.4.2 Data localization.

Data localization shall apply where data must be stored, processed, backed up, or accessed within a specified jurisdiction or controlled environment because of law, public authority sensitivity, national policy, data sovereignty, community safeguards, Indigenous protocols where applicable, protected knowledge, health data, youth data, cyber sensitivity, infrastructure sensitivity, or handoff requirements. Localization records shall identify what data is localized, where it is localized, who may access it, what transfers are prohibited or permitted, and what outputs may leave the environment after review.

Data localization shall not automatically create data rights, national approval, public authority approval, open access, or deployment authority.

### 18.4.3 Public authority-sensitive workloads.

Public authority-sensitive workloads shall include compute, storage, analysis, dashboards, Studio workflows, data rooms, secure rooms, AI review, public-safe reporting, DRI workflows, Observatory workflows, or handoff context involving public authority data, policy-sensitive materials, regulatory learning, public finance learning, emergency management learning, procurement-sensitive context, or public authority operational dependencies. Such workloads shall be classified, access-controlled, logged, output-reviewed, and boundary-noticed.

Public authority-sensitive workload handling shall not create public authority decision, official approval, policy adoption, public warning, emergency command, public finance allocation, procurement decision, or regulatory status.

### 18.4.4 National repository mirrors.

National repository mirrors may preserve nationally relevant software, data, metadata, reports, learning objects, schemas, models, dashboards, public-safe summaries, Registry snapshots, Marketplace metadata, National Portfolio records, DRI summaries, Observatory records, and handoff context within national or jurisdictionally appropriate environments. National mirrors shall preserve version labels, correction notices, withdrawal records, recall records, license terms, access classes, and boundary notices.

A national mirror shall not override the original object steward, Registry status truth, license terms, public-safe limits, or correction records. Mirror availability shall not imply national endorsement or public authority approval.

### 18.4.5 National Node infrastructure.

National Node infrastructure shall support national localization, national learning, National Portfolio records, National Working Group workflows, Competence Cell workflows, Nexus Academy pathways, Risk Academy pathways, Campaigns, Foundry routing, Studio workflows, public authority learning, DRI and Observatory contributions, Marketplace and Registry interfaces, and lawful handoff context. National Node infrastructure shall be governed by national ownership, role separation, public-good stack discipline, data sovereignty, provider neutrality, and correctionability.

National Node infrastructure shall not be treated as a public authority, procurement body, finance actor, insurer, certifier, standards authority, operator, contractor, or execution vehicle by default.

### 18.4.6 Regional cluster infrastructure.

Regional cluster infrastructure may support coordination among National Nodes, regional repositories, regional Observatory hubs, regional DRI workflows, regional learning objects, regional Studio workflows, Nexus Universe preparation, public-safe regional reports, cross-border risk learning, and shared public-good digital assets. Regional cluster infrastructure shall support national ownership and shall not override national pathways.

Regional infrastructure shall not create regional supremacy, supranational authority, public authority approval, procurement authority, finance authority, execution authority, or cross-border data transfer permission by default.

### 18.4.7 National dense Nexus Core infrastructure.

National dense Nexus Core infrastructure shall refer to concentrated national capability environments that connect National Portfolios, Competence Cells, National Working Groups, National Nodes, Nexus Studio, DICE, GRIx, DRI, Observatory, Academy, Foundry, Marketplace, Registry, Reports, Campaigns, and Nexus Universe preparation into a denser public-good operating environment. Such infrastructure may support intensive build cycles, secure review, public authority learning, data rooms, compute-to-data workflows, dashboards, and lawful handoff preparation.

National dense Nexus Core infrastructure shall remain non-executing by default. It shall not create deployment authority, operational command, public authority action, procurement approval, financeability, insurability, or enterprise execution.

### 18.4.8 Sovereign access controls.

Sovereign access controls shall define who may access sovereign or national infrastructure, under what legal, institutional, technical, and procedural conditions. Controls may include national identity requirements, institutional authorization, role-based access, data residency constraints, local key management, secure-room conditions, public authority-sensitive restrictions, export controls, logging, and revocation rules.

Sovereign access controls shall not create discriminatory exclusion, hidden capture, public authority overclaim, unrestricted national access, provider preference, or bypass of privacy and safeguard duties.

### 18.4.9 Cross-border transfer controls.

Cross-border transfer controls shall govern movement or access of data, models, logs, reports, dashboards, metadata, credentials, public authority-sensitive materials, protected knowledge, community-sensitive data, health data, youth data, cyber-sensitive information, infrastructure-sensitive information, and handoff packages across jurisdictions. Controls shall identify transfer basis, permitted recipients, prohibited transfers, output restrictions, localization requirements, secure-room requirements, compute-to-data alternatives, and audit requirements.

Cross-border transfer controls shall be applied even where technical access is possible. Technical access shall not equal lawful transfer.

### 18.4.10 National continuity records.

National continuity records shall document how national DDPGF infrastructure, objects, repositories, learning systems, dashboards, public-safe summaries, National Portfolio records, DRI records, Observatory records, Studio workflows, secure rooms, data rooms, and handoff contexts remain available, recoverable, correctable, or archivable during disruption. Records shall identify backup, mirror, offline, low-bandwidth, degraded-mode, restore, support, maintainer, provider, funding, and archive arrangements.

National continuity records shall not create service guarantee, public authority continuity guarantee, public finance commitment, procurement status, or execution obligation.

## 18.5 Resilience and Continuity

### 18.5.1 Redundancy.

DDPGF infrastructure shall use redundancy where appropriate to avoid single points of failure in repositories, storage, Registry records, Marketplace metadata, Reports, Studio workflows, secure rooms, data rooms, compute environments, APIs, dashboards, learning systems, National Portfolio records, DRI records, Observatory records, and archives. Redundancy may include replicated systems, mirrored repositories, alternate providers, backup storage, regional mirrors, national mirrors, and offline packages.

Redundancy shall be recorded with scope, limits, failover conditions, support status, cost assumptions, and correction pathway. Redundancy shall not create uptime warranty or operational guarantee.

### 18.5.2 Failover.

Failover shall support continuity where primary infrastructure becomes unavailable, degraded, compromised, unaffordable, non-compliant, or unsuitable. Failover records shall identify trigger conditions, alternate environment, data synchronization status, access control continuity, DNS or routing dependencies, security controls, support responsibility, test history, and restoration path.

Failover readiness shall not imply deployment authorization, public authority emergency authority, service-level guarantee, or regulated critical infrastructure status.

### 18.5.3 Backup.

Backup shall preserve digital public-good objects and infrastructure records according to object class, sensitivity, retention rules, data sovereignty, access class, encryption needs, and archive requirements. Backup may apply to repositories, datasets, metadata, models, reports, credentials, logs, Registry records, Marketplace listings, learning objects, Studio workflows, secure-room records, data-room records, and handoff packages.

Backup shall not preserve unauthorized data, exposed secrets, protected knowledge, or restricted records in uncontrolled form. Backup access shall be controlled and logged where appropriate.

### 18.5.4 Restore testing.

Restore testing shall verify that backups can be restored within recorded scope and that restored objects preserve version labels, access class, license terms, public-safe status, sensitivity class, correction notices, withdrawal status, recall status, and archive labels. Restore testing shall be performed proportionally based on object criticality, national relevance, repository importance, security risk, and continuity needs.

Restore testing shall be evidence of recoverability within scope, not a service guarantee, certification, or public authority assurance.

### 18.5.5 Offline mode.

Offline mode shall support access to appropriate public-safe and non-command materials during connectivity interruptions, disaster contexts, low-bandwidth contexts, fieldwork, training, or national localization. Offline objects may include reports, public-safe guides, learning objects, documentation, schemas, checklists, data dictionaries, low-risk dashboards, and correction notices. Offline objects shall include version labels, expiration notes, update instructions, and boundary notices.

Offline mode shall not authorize operational command, emergency warning, public authority decision, deployment, procurement, finance, insurance, or execution.

### 18.5.6 Low-bandwidth mode.

Low-bandwidth mode shall enable access to appropriate DDPGF objects through lightweight formats, compressed resources, text-first pages, reduced media, static files, mobile-friendly interfaces, public-safe summaries, and accessible downloads where lawful. Low-bandwidth mode shall support inclusion, rural access, disaster-affected access, national participation, and learning continuity.

Low-bandwidth simplification shall not remove material limitations, safety notices, license terms, public-safe controls, correction notices, or boundary rules.

### 18.5.7 Degraded-mode awareness.

Degraded-mode awareness shall identify when systems, dashboards, APIs, repositories, Studio workflows, data rooms, secure rooms, Marketplace services, Registry services, Reports, Observatory nodes, DRI workflows, or National Node infrastructure operate with reduced data, stale data, limited access, reduced features, suspended exports, delayed review, lower confidence, or partial availability. Degraded-mode status shall be visible where users could otherwise misinterpret outputs.

Degraded mode shall not authorize lower review standards, unsafe publication, uncontrolled access, or operational reliance.

### 18.5.8 Incident response.

Infrastructure incident response shall address outages, cyber incidents, data incidents, privacy incidents, access incidents, provider failures, repository compromise, backup failure, restore failure, network failure, secure-room breach, data-room misuse, compute-to-data misuse, sensor network compromise, Studio misuse, API abuse, or protected knowledge exposure. Response shall include containment, access suspension, technical freeze, data freeze, claims freeze, Registry update, Marketplace action, Report correction, Studio shutdown, handoff recall, archive, and reinstatement where appropriate.

Incident response shall be recorded, public-safe, and correctionable.

### 18.5.9 Disaster recovery.

Disaster recovery shall identify how infrastructure supporting DDPGF objects can be restored after significant disruption. Disaster recovery planning shall include recovery priorities, dependencies, responsible stewards, provider contacts, backup locations, data sovereignty constraints, access restoration, credential restoration, security validation, public-safe notices, degraded-mode alternatives, and archive protection.

Disaster recovery shall not create emergency response authority, public warning authority, operational command, service warranty, or public authority continuity guarantee.

### 18.5.10 Continuity archive.

A continuity archive shall preserve the records necessary to understand, restore, correct, or retire infrastructure after disruption or discontinuation. It may include architecture notes, configuration summaries, dependency records, access records, backup records, restore records, incident records, support records, cost records, provider records, teardown records, and archive records. Sensitive details shall be controlled.

Continuity archive shall preserve institutional memory without creating current operational authority or current support obligations.

## 18.6 Infrastructure Boundary Rules

### 18.6.1 Cloud contribution is not provider validation.

Cloud credits, hosting, compute support, technical assistance, infrastructure sponsorship, managed services, training, documentation, or provider participation shall not validate the provider, certify provider services, create preferred-provider status, create procurement recommendation, create technical superiority, create financeability, create public authority approval, or authorize deployment. Provider contributions shall be recorded with provider-neutrality controls and support boundaries.

### 18.6.2 Hosted environment is not public authority approval.

Hosting an object, workflow, data room, secure room, public authority learning room, dashboard, Registry record, Marketplace listing, Studio workflow, National Portfolio object, or Nexus Universe object in a national, sovereign, public authority-sensitive, or cloud environment shall not create public authority approval, official adoption, permit, license, public finance allocation, procurement decision, regulatory status, emergency command, public warning, or governmental endorsement.

### 18.6.3 Compute access is not data right.

Access to compute, cloud resources, HPC environments, secure enclaves, compute-to-data workflows, data rooms, Studio environments, APIs, model environments, or dashboards shall not create rights to underlying data, raw data extraction, data reuse, AI training, transfer, publication, commercialization, handoff, or operational deployment. Data rights must be separately recorded through license, permission, access class, and data-use records.

### 18.6.4 Infrastructure readiness is not deployment authorization.

Infrastructure readiness, environment readiness, cloud readiness, edge readiness, network readiness, compute readiness, storage readiness, data-room readiness, secure-room readiness, Studio runtime readiness, Observatory node readiness, or National Node readiness shall not authorize deployment, production use, operational command, public authority action, procurement, finance, insurance, provider selection, community implementation, Indigenous-context implementation, or enterprise execution.

### 18.6.5 Support status is not service-level warranty.

Support status for infrastructure, environments, repositories, dashboards, APIs, data rooms, secure rooms, compute clusters, Studio workflows, Marketplace systems, Registry systems, Observatory nodes, or National Node infrastructure shall not create service-level agreement, uptime warranty, operational guarantee, incident-response guarantee, support entitlement, procurement eligibility, deployment support obligation, financeability, insurability, or execution obligation unless separately and lawfully contracted or recorded.

### 18.6.6 Sovereign hosting is not public authority decision by default.

Sovereign hosting, national hosting, data localization, national repository mirroring, national compute, sovereign compute, or National Node infrastructure shall not constitute public authority decision, public authority approval, official adoption, regulatory compliance determination, public finance allocation, procurement decision, national endorsement, permit, license, emergency command, or execution authority by default. Sovereign hosting is an infrastructure and jurisdictional-control posture; public authority action requires a separate competent public authority process.


---

# 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/distributed-digital-public-goods-framework-ddpgf/xviii.-infra.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.