# VII. ESTATE

## 31. Foundry and Nexus Sovereign Compute

### Summary

This page defines the Nexus Foundry estate for sovereign compute, compute architecture, edge systems, AI and agentic systems, cybersecurity, secure infrastructure, and data architecture. It shows how compute, storage, sensing, secure environments, and verifiable intelligence stay bounded, reviewable, and aligned to public-good use.

Use this page with [NEXUS FOUNDRY](/organization/acceleration/nexus-foundry.md), [VI. NETWORKS](/organization/acceleration/nexus-foundry/vi.-networks.md), and [VIII. ARCHITECTURE](/organization/acceleration/nexus-foundry/viii.-architecture.md) to connect sovereign infrastructure with systems design. For delivery and operations, continue into [IX. PRODUCTION](/organization/acceleration/nexus-foundry/ix.-production.md), [X. OPERATIONS](/organization/acceleration/nexus-foundry/x.-operations.md), and the [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md).

### Key takeaways

* Sovereign compute is governed infrastructure, not implied authority.
* Edge, AI, cybersecurity, and data layers share one record-based control model.
* Release, teardown, quotas, and zero-trust controls prevent drift, capture, and overclaim.

### In this page

* [31. Foundry and Nexus Sovereign Compute](#31-foundry-and-nexus-sovereign-compute)
* [32. Foundry Compute Architecture](#32-foundry-compute-architecture)
* [33. Foundry Edge Architecture](#33-foundry-edge-architecture)
* [34. Foundry AI and Agentic Systems Architecture](#34-foundry-ai-and-agentic-systems-architecture)
* [35. Foundry Cybersecurity and Secure Infrastructure](#35-foundry-cybersecurity-and-secure-infrastructure)
* [36. Foundry Data Architecture](#36-foundry-data-architecture)

### Related pathways

* [NEXUS FOUNDRY](/organization/acceleration/nexus-foundry.md)
* [VI. NETWORKS](/organization/acceleration/nexus-foundry/vi.-networks.md)
* [VIII. ARCHITECTURE](/organization/acceleration/nexus-foundry/viii.-architecture.md)
* [IX. PRODUCTION](/organization/acceleration/nexus-foundry/ix.-production.md)
* [X. OPERATIONS](/organization/acceleration/nexus-foundry/x.-operations.md)
* [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md)
* [XIII. READINESS](/organization/acceleration/nexus-foundry/xiii.-readiness.md)

### 31.1 Compute as Governed Technical Estate

**31.1.1 Compute Estate Identity.** **Nexus Sovereign Compute** within Nexus Foundry shall mean the governed technical estate through which Foundry work may be built, tested, simulated, evaluated, secured, localized, released, supported, corrected, retired, and archived across cloud, high-performance computing, sovereign compute, edge compute, secure rooms, data rooms, clean rooms, confidential computing environments, compute-to-data environments, AI compute environments, observability environments, Studio environments, and controlled release environments. Compute shall be treated as critical public-good infrastructure, not merely as capacity, hosting, vendor service, cloud credit, technical convenience, or event infrastructure.

**31.1.2 Compute as Stewarded Estate, Not Ownership Claim.** Foundry use of compute shall not imply ownership of infrastructure, control of provider platforms, public authority mandate, national data authority, operational command, surveillance authority, emergency authority, or execution authority. Compute may be provisioned, contributed, sponsored, hosted, leased, federated, donated, temporarily assembled, nationally operated, regionally supported, or enterprise-supported, but its use within Foundry shall remain subject to records, access controls, data controls, security controls, support status, provider-neutrality rules, public-good firewall rules, and correction pathways.

**31.1.3 Compute Governance Purpose.** Compute governance shall ensure that Foundry compute is used for lawful, bounded, reviewable, supportable, secure, privacy-aware, sovereign-sensitive, public-safe, and correctionable purposes. It shall prevent infrastructure sprawl, hidden provider dependency, data exposure, uncontrolled AI training, uncontrolled agentic action, public authority confusion, finance or procurement implication, operational misuse, protected knowledge exposure, and execution by implication.

**31.1.4 Compute Estate Classes.** The Foundry compute estate may include build compute, simulation compute, evidence compute, AI compute, secure compute, sovereign compute, edge compute, release compute, teardown compute, archive compute, Studio runtime compute, Observatory compute, DRI compute, GRIx compute, Marketplace support compute, Registry support compute, National Node compute, Nexus Universe Core Build compute, and Frontier Labs compute. Each class shall have a record, purpose, access class, data class, support class, security posture, teardown rule, and prohibited uses.

**31.1.5 Compute Access Rule.** Access to compute shall be role-based, need-based, record-based, time-bounded where appropriate, least-privilege, monitored where appropriate, and proportionate to risk. Access shall not be granted merely because an actor is a sponsor, provider, partner, public authority participant, capital reader, university participant, contributor, council member, Guild member, or Nexus Universe participant.

**31.1.6 Compute Provider Neutrality.** Provider-supplied compute, cloud credits, AI infrastructure, telecommunications infrastructure, edge infrastructure, sovereign cloud, hardware, GPUs, storage, networking, or technical support shall not validate the provider, create preferred-provider status, create procurement advantage, create Marketplace recognition, create Registry approval, create financeability, or establish execution authority. Provider dependencies shall be disclosed and managed.

**31.1.7 Compute Public-Good Firewall.** Compute used for public-good Foundry work shall not be silently converted into private enterprise advantage, proprietary lock-in, exclusive access, hidden data capture, sponsor control, provider control, or enterprise-stack execution. Enterprise use of Foundry-related compute patterns shall require separate lawful terms, licenses, contracts, data rights, support arrangements, and handoff boundaries.

**31.1.8 Compute Formula.** Foundry compute shall operate according to the formula: **allocate compute by record; classify data before processing; restrict access by role; disclose provider dependencies; separate public-good work from enterprise execution; monitor and correct misuse; tear down what should not persist; never let compute access become authority.**

***

### 31.2 Foundry Build Compute

**31.2.1 Build Compute Identity.** **Foundry Build Compute** shall mean compute capacity used to create, assemble, test, integrate, document, package, and prepare Foundry Objects, including software, schemas, APIs, connectors, agents, dashboards, Packs, evidence tools, Observatory modules, Studio packages, Marketplace preparation objects, Registry tooling, support tools, correction tools, and archive tools.

**31.2.2 Build Compute Purpose.** Build Compute shall support the practical production of Foundry work. It may be used for code compilation, repository operations, continuous integration, test execution, package assembly, container builds, documentation generation, schema validation, dashboard build pipelines, connector testing, API testing, dependency review, software bill-of-materials preparation, release-candidate packaging, and reproducibility checks.

**31.2.3 Build Compute Record.** Material Build Compute use shall have a Build Compute Record identifying project or object, compute environment, provider or host, purpose, access roles, data class, repository relationship, dependencies, secrets handling, build artifacts, test records, support status, retention period, teardown rule, correction pathway, and prohibited uses.

**31.2.4 Build Compute Access.** Build Compute access shall be granted only to contributors, maintainers, reviewers, build stewards, release stewards, or support stewards with appropriate role readiness and need. Build permissions shall not create release authority, Registry status authority, Marketplace listing authority, Studio runtime authority, TRL authority, deployment authority, or execution authority.

**31.2.5 Build Artifacts.** Build artifacts shall be classified before release, publication, Marketplace listing, Registry reference, Studio use, or handoff. An artifact produced by Build Compute shall not be treated as released merely because it was built successfully, passed tests, or is technically executable.

**31.2.6 Dependency and Secrets Control.** Build Compute shall manage dependencies, secrets, credentials, keys, tokens, container images, libraries, model weights, configuration files, and infrastructure templates under secure controls. Exposure of secrets or unsafe dependencies shall trigger correction and incident review.

**31.2.7 Build Compute Without Deployment.** Build Compute shall not authorize deployment. A built object, container, package, dashboard, connector, API, agent, or deployment unit shall remain subject to release review, support review, public-safe review, security review, Registry recording, Marketplace review, Studio review, TRL review, and lawful handoff review where applicable.

**31.2.8 Build Compute Correction.** Build Compute records and artifacts shall be corrected where dependencies are unsafe, build configuration is wrong, artifacts are mislabeled, secrets are exposed, support status is overstated, or build success is used as deployment or approval claim.

**31.2.9 Build Compute Formula.** Build Compute shall follow the formula: **build in controlled environments; record dependencies; protect secrets; test artifacts; classify before release; correct build misuse; never treat successful build as deployment authorization.**

***

### 31.3 Simulation Compute

**31.3.1 Simulation Compute Identity.** **Simulation Compute** shall mean compute capacity used to run scenarios, digital twins, stress tests, systems models, climate and disaster-risk simulations, infrastructure resilience simulations, cyber-physical simulations, AI workflow simulations, telecom and edge simulations, WEFH-B systems simulations, public authority learning simulations, readiness simulations, Studio simulations, and Nexus Universe / Core Build simulation environments.

**31.3.2 Simulation Compute Purpose.** Simulation Compute shall help Foundry test assumptions, explore uncertainty, examine dependencies, evaluate methods, generate evidence candidates, support public authority learning, inform GRIx and DRI context, support Observatory modules, prepare Studio runtime patterns, and identify readiness or safeguard questions. It shall not create forecast certainty, public warning, public authority decision, finance signal, insurance determination, procurement priority, deployment instruction, or operational command.

**31.3.3 Simulation Compute Record.** Each material simulation use shall have a Simulation Compute Record identifying simulation purpose, model or method, compute environment, data sources, assumptions, parameters, scenario limits, user roles, output class, uncertainty treatment, sensitivity classification, public-safe restrictions, review requirements, retention rule, teardown rule, correction pathway, and prohibited claims.

**31.3.4 Simulation Data Controls.** Simulation Compute involving sensitive data, geospatially sensitive data, infrastructure-sensitive data, public authority-sensitive data, community-sensitive data, Indigenous-sensitive knowledge where applicable, health-sensitive data, cyber-sensitive data, or protected knowledge shall operate under access controls, output review, aggregation, masking, compute-to-data, or secure-room controls where appropriate.

**31.3.5 Simulation Output Boundary.** Simulation outputs shall be interpreted only within recorded assumptions, data, models, parameters, environments, uncertainty, and limitations. Simulation outputs shall not be represented as prediction, warning, rating, public authority classification, insurance outcome, investment conclusion, procurement conclusion, consent basis, deployment approval, or execution mandate.

**31.3.6 Simulation Compute and Studio.** Simulation Compute used within Nexus Studio shall be governed by Studio runtime records, user classes, data classes, tool permissions, output review, public-safe boundaries, support status, shutdown conditions, and correction pathways. Studio simulation does not create lawful decision authority.

**31.3.7 Simulation Compute Teardown.** Simulation environments shall be torn down, restricted, or archived where continuation is not justified, data sensitivity requires closure, support lapses, assumptions become stale, outputs become misleading, or public-safe risk increases.

**31.3.8 Simulation Compute Correction.** Simulation Compute records and outputs shall be corrected where assumptions are wrong, data changes, model behavior is misunderstood, uncertainty is understated, visualization misleads, sensitive output is exposed, or simulation is used as warning, rating, finance, procurement, consent, deployment, or execution signal.

**31.3.9 Simulation Compute Formula.** Simulation Compute shall follow the formula: **run scenarios under recorded assumptions; show uncertainty; restrict sensitive outputs; review public meaning; tear down stale environments; never convert simulation into warning, rating, decision, or command.**

***

### 31.4 Evidence Compute

**31.4.1 Evidence Compute Identity.** **Evidence Compute** shall mean compute capacity used to collect, clean, transform, classify, analyze, validate, reproduce, review, annotate, benchmark, package, and preserve evidence for Foundry Objects, Evidence Packs, Observatory outputs, DRI outputs, GRIx context, National Portfolios, public-safe reports, TRL inputs, readiness mappings, safeguard records, and handoff dependency packages.

**31.4.2 Evidence Compute Purpose.** Evidence Compute shall improve provenance, traceability, reproducibility, uncertainty awareness, data quality, methodological clarity, public-safe interpretation, and correctionability. It shall convert raw or fragmented information into evidence-bearing records without converting evidence into approval.

**31.4.3 Evidence Compute Record.** Each material Evidence Compute use shall have an Evidence Compute Record identifying evidence object, data sources, method, compute environment, access class, data class, transformations, validation steps, uncertainty, reviewer, output class, limitations, public-safe status, retention rule, correction pathway, archive rule, and prohibited interpretations.

**31.4.4 Provenance and Reproducibility.** Evidence Compute shall preserve source provenance, method version, code or workflow version where applicable, data version, transformation logs, parameter settings, uncertainty notes, reviewer notes, and output lineage. Reproducibility shall be pursued where feasible and lawfully permitted, but sensitive data controls may limit full public reproducibility.

**31.4.5 Evidence Compute and Restricted Data.** Evidence Compute involving restricted, sovereign-sensitive, public authority-sensitive, rights-bearing, community-protected, Indigenous-protected where applicable, health-sensitive, cyber-sensitive, infrastructure-sensitive, or high-risk data shall use controlled environments, compute-to-data, output review, secure-room restrictions, aggregation, pseudonymization, anonymization, or sealing where appropriate.

**31.4.6 Evidence Output Boundary.** Evidence outputs shall not create certification, validation, public authority approval, procurement status, financeability, insurability, consent, deployment authorization, or execution authority. Evidence may support review, but competent status must arise from the relevant record.

**31.4.7 Evidence Compute Quality Review.** Evidence Compute outputs shall be reviewed for data quality, method suitability, bias, uncertainty, representativeness, limitations, public-safe wording, safeguard classification, and downstream use risk. Evidence gaps shall be recorded rather than hidden.

**31.4.8 Evidence Compute Correction.** Evidence Compute records and outputs shall be corrected where source provenance is wrong, transformation is flawed, data quality is inadequate, uncertainty is understated, outputs are overclaimed, or evidence is misused as approval, certification, finance, procurement, consent, deployment, or execution.

**31.4.9 Evidence Compute Formula.** Evidence Compute shall follow the formula: **preserve provenance; document method; classify data; compute under controls; review evidence quality; state limits; correct evidence drift; never let evidence become approval beyond record.**

***

### 31.5 AI Compute

**31.5.1 AI Compute Identity.** **AI Compute** shall mean compute capacity used for AI-related Foundry work, including model evaluation, retrieval, summarization, classification, simulation, agent testing, workflow automation, public-safe drafting assistance, evidence review assistance, Observatory analysis, GRIx and DRI analysis, Studio agents, benchmark testing, safety testing, and controlled AI-enabled production. AI Compute shall be governed as high-risk technical capacity where outputs may be persuasive, misleading, or action-like.

**31.5.2 AI Compute Purpose.** AI Compute may support Foundry productivity, evidence processing, language access, accessibility, technical analysis, simulation, dashboard interpretation, data classification, code assistance, agentic workflow testing, public-safe drafting, and review support. It shall not replace human review where required, public authority decisions, finance decisions, procurement decisions, safeguard decisions, consent processes, deployment decisions, or execution.

**31.5.3 AI Compute Record.** Each material AI Compute use shall have an AI Compute Record identifying model or system, provider where applicable, version, task class, data inputs, data class, prompt or workflow class, tool permissions, agent permissions, human-review points, output review, evaluation method, known limitations, retention rule, public-safe restrictions, correction pathway, and prohibited uses.

**31.5.4 AI Data Boundary.** Sensitive, restricted, sovereign, public authority, community, Indigenous where applicable, health, cyber, infrastructure, confidential, or protected knowledge data shall not be used in AI Compute unless lawful basis, access permissions, data controls, model-use terms, output review, retention controls, and protection requirements are recorded. AI use shall not silently create model-training rights.

**31.5.5 AI Agent Controls.** AI Compute involving agents or tool-enabled systems shall include sandboxing, least-privilege tool access, human authorization points, prohibited actions, output review, credential controls, logging where appropriate, termination conditions, escalation rules, and shutdown procedures. Agents shall not make or imply official decisions.

**31.5.6 AI Output Boundary.** AI outputs shall be treated as draft, analysis, assistance, signal, or candidate material unless reviewed and adopted through the relevant process. AI-generated text, classifications, summaries, recommendations, labels, dashboards, or code shall not create approval, public warning, finance advice, procurement recommendation, consent, deployment authorization, or execution authority.

**31.5.7 AI Provider Neutrality.** Use of AI compute from a provider shall not validate the provider, certify the model, approve AI safety, create procurement preference, or establish preferred infrastructure status. Provider dependencies, model limitations, data-use terms, and exit risks shall be disclosed where material.

**31.5.8 AI Compute Correction.** AI Compute records and outputs shall be corrected where outputs hallucinate, misclassify, overclaim, leak data, violate restrictions, exceed permissions, weaken public-safe language, create false certainty, or are used as authority. Correction may include output withdrawal, model restriction, prompt update, tool removal, runtime pause, public-safe correction, or archive.

**31.5.9 AI Compute Formula.** AI Compute shall follow the formula: **classify data before model use; restrict tools; keep humans in review; record limitations; prevent provider capture; correct hallucination and overclaim; never let AI output become authority or execution.**

***

### 31.6 Secure Compute

**31.6.1 Secure Compute Identity.** **Secure Compute** shall mean compute environments and controls used for sensitive Foundry work, including secure rooms, clean rooms, data rooms, compute-to-data environments, confidential computing, encrypted environments, restricted repositories, restricted dashboards, no-download workspaces, cyber labs, secure Studio environments, and controlled output-review environments.

**31.6.2 Secure Compute Purpose.** Secure Compute shall allow Foundry to work with sensitive data, protected knowledge, public authority-sensitive material, cyber-sensitive material, infrastructure-sensitive material, community-sensitive information, Indigenous-sensitive knowledge where applicable, health-sensitive information, confidential provider or partner information, and high-risk AI or cyber workflows without unnecessary data movement or exposure.

**31.6.3 Secure Compute Record.** Each Secure Compute environment shall have a Secure Compute Record identifying environment, purpose, data classes, access roles, access approvals, security controls, encryption where applicable, logging where appropriate, no-download rules, output-review rules, allowed workloads, prohibited workloads, retention, teardown, incident pathway, correction pathway, and archive rule.

**31.6.4 Secure Compute Access.** Access shall require role readiness, need, authorization, confidentiality conditions, training, conflict checks where relevant, and environment-specific controls. Secure Compute access shall be time-bounded where appropriate and reviewed periodically.

**31.6.5 Output Review.** Outputs from Secure Compute shall be reviewed before export, publication, dashboard display, Marketplace context, Registry display, Studio use, public authority learning, capital-reader review, insurance-reader review, donor-reader review, public finance review, community-facing communication, Indigenous-facing communication where applicable, or handoff.

**31.6.6 No Raw Extraction Rule.** Raw data, protected knowledge, sensitive geospatial layers, secrets, vulnerability details, public authority-sensitive materials, community-sensitive materials, Indigenous-sensitive knowledge where applicable, or confidential materials shall not be extracted from Secure Compute unless expressly authorized by record and review.

**31.6.7 Secure Compute Without Assurance Overclaim.** Secure Compute use shall not create cybersecurity certification, privacy certification, legal compliance certification, public authority approval, procurement suitability, financeability, insurability, or deployment authorization. It is a control environment, not a universal guarantee.

**31.6.8 Secure Compute Incidents.** Unauthorized access, data leakage, output leakage, credential misuse, logging failure, no-download breach, protected knowledge exposure, AI prompt leakage, cyber anomaly, or secure-room protocol breach shall trigger incident response, correction, notice where required, access review, control update, and archive.

**31.6.9 Secure Compute Formula.** Secure Compute shall follow the formula: **restrict sensitive work; control access; review outputs; prevent raw extraction; log where appropriate; respond to incidents; tear down when no longer justified; never treat secure environment as approval.**

***

### 31.7 Sovereign Compute

**31.7.1 Sovereign Compute Identity.** **Sovereign Compute** shall mean compute capacity, hosting, storage, networking, processing, AI infrastructure, data environments, and related technical controls designed or selected to respect national law, data residency, public authority requirements, public-sector sensitivities, sovereignty considerations, critical infrastructure needs, protected knowledge conditions, Indigenous data sovereignty where applicable, and national public-good priorities.

**31.7.2 Sovereign Compute Purpose.** Sovereign Compute shall enable national Foundry pathways to process sensitive or country-relevant work in a manner consistent with national data controls, public authority expectations, security requirements, lawful access rules, jurisdictional restrictions, public-safe publication controls, and national ownership. It shall not create government approval or public authority status by implication.

**31.7.3 Sovereign Compute Record.** Each Sovereign Compute environment shall have a Sovereign Compute Record identifying jurisdiction, host, provider if any, legal and data-residency basis, data classes, access roles, national pathway, public authority dependencies, security controls, cross-border restrictions, support status, exit plan, teardown rule, correction pathway, and prohibited claims.

**31.7.4 National Routing.** Country-relevant Foundry work using Sovereign Compute shall be routed through the relevant National Nexus Node, National Nexus Consortium, National Working Group, national data-control process, or national public authority learning pathway where appropriate. Sovereign Compute shall not be used to bypass national ownership.

**31.7.5 Sovereign Compute Provider Neutrality.** Use of a sovereign cloud, national provider, public-sector cloud, telecom operator, host, data center, HPC facility, or AI infrastructure provider shall not validate the provider, create procurement preference, or imply public authority approval. Provider dependencies and exit risks shall be recorded.

**31.7.6 Cross-Border Controls.** Sovereign Compute shall define what may cross borders, what must remain in-country, what may be exported only as reviewed outputs, what must remain aggregated, and what cannot be exported. Cross-border analysis shall comply with the most restrictive applicable controls.

**31.7.7 Sovereign AI Compute.** AI Compute in sovereign contexts shall preserve data-use restrictions, model-use terms, public authority sensitivity, training restrictions, output review, and national data sovereignty. Sensitive national data shall not be used to train or improve external models unless separately and lawfully authorized.

**31.7.8 Sovereign Compute Boundary.** Sovereign Compute use shall not constitute national approval, government endorsement, regulatory approval, procurement approval, public finance allocation, lawful deployment authorization, community consent, Indigenous consent where applicable, or execution authority.

**31.7.9 Sovereign Compute Formula.** Sovereign Compute shall follow the formula: **respect jurisdiction; keep sensitive data where required; route nationally; disclose providers; control cross-border outputs; preserve exit options; never convert sovereign hosting into public authority approval.**

***

### 31.8 Edge Compute

**31.8.1 Edge Compute Identity.** **Edge Compute** shall mean compute capacity deployed or used close to sensors, devices, infrastructure, communities, field environments, telecom systems, private wireless systems, O-RAN / AI-RAN environments, disaster-risk contexts, observability points, national dense Nexus cores, regional clusters, hubs, hotspots, or other distributed environments. Edge Compute shall be governed because proximity to real-world systems can create operational, privacy, cyber, public-safe, and execution risks.

**31.8.2 Edge Compute Purpose.** Edge Compute may support local sensing, preprocessing, aggregation, anomaly detection, dashboard preparation, degraded-mode awareness, simulation, Studio demonstration, Observatory inputs, DRI inputs, GRIx context, field learning, public authority learning, and national portfolio evidence. It shall not create operational command, surveillance authority, public warning, infrastructure control, or deployment authority by implication.

**31.8.3 Edge Compute Record.** Each material Edge Compute environment shall have an Edge Compute Record identifying location or location class, host, provider if any, connected systems, sensors or inputs, data classes, processing purpose, access roles, connectivity assumptions, cyber controls, privacy controls, public-safe restrictions, national pathway, community or Indigenous considerations where applicable, support status, teardown rule, correction pathway, and prohibited uses.

**31.8.4 Edge Data Minimization.** Edge Compute shall prefer data minimization, local processing, aggregation, output review, and restricted export where raw data is sensitive, location-sensitive, infrastructure-sensitive, community-sensitive, Indigenous-sensitive where applicable, public authority-sensitive, or cyber-sensitive.

**31.8.5 Edge and Operational Boundary.** Edge Compute shall not control infrastructure, issue public warnings, direct emergency response, operate telecom systems, activate field devices, surveil communities, execute public authority functions, or trigger automated action unless a separate competent lawful pathway authorizes such use outside default Foundry operations.

**31.8.6 Edge Cyber Controls.** Edge Compute shall include cyber controls proportionate to exposure, including device identity, access control, secure configuration, update management, secrets protection, physical security where relevant, network segmentation, monitoring where appropriate, incident reporting, and teardown procedures.

**31.8.7 Edge Community and Place Safeguards.** Edge Compute in or near communities, Indigenous territories where applicable, critical infrastructure, or sensitive geographies shall respect local safeguards, protected knowledge, privacy, consent requirements where applicable, public-safe limits, and national routing. Sensor presence shall not imply consent.

**31.8.8 Edge Compute Correction.** Edge Compute shall be corrected, restricted, disconnected, torn down, or archived where data risk increases, cyber risk appears, public-safe risk appears, community concerns arise, Indigenous protocol concerns arise where applicable, host conditions change, support lapses, or edge outputs are used as warnings, surveillance, ratings, deployment, or execution signals.

**31.8.9 Edge Compute Formula.** Edge Compute shall follow the formula: **process near source; minimize data movement; protect place and people; secure devices; separate sensing from command; tear down unsafe edge; never let edge proximity become operational authority.**

***

### 31.9 Release Compute

**31.9.1 Release Compute Identity.** **Release Compute** shall mean compute environments used to package, sign, publish, list, register, distribute, mirror, deploy-to-controlled-environment, or otherwise make Foundry Objects available under recorded release conditions. Release Compute shall be governed because release surfaces can create reliance, visibility, and status overclaim.

**31.9.2 Release Compute Purpose.** Release Compute may support artifact publication, package registry operation, container registry operation, documentation publishing, Marketplace listing support, Registry status display, Studio package distribution, dashboard publication, public-safe report hosting, versioning, signatures, checksums, dependency manifests, software bills of materials, and archive-ready release bundles.

**31.9.3 Release Compute Record.** Each Release Compute environment shall have a Release Compute Record identifying release surface, object classes, release authority, release class, publication controls, signing or integrity controls where applicable, access controls, support status, rollback pathway, correction pathway, withdrawal pathway, archive rule, and prohibited claims.

**31.9.4 Release Authorization Separation.** Release Compute access shall not equal release authorization. A person or system able to upload, publish, sign, list, register, or distribute an artifact shall do so only according to recorded release authority and review. Technical permission shall not become institutional authority.

**31.9.5 Release Integrity Controls.** Release Compute shall preserve version integrity, artifact integrity, checksum or signature integrity where applicable, dependency manifests, release notes, support status, correction links, public-safe limitations, license terms, and archive references.

**31.9.6 Release Visibility Boundary.** Publication through Release Compute shall not create recognition, certification, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, Studio runtime activation, data access authorization, or execution authority. Release status shall remain bounded by the Release Status Record.

**31.9.7 Rollback and Withdrawal.** Release Compute shall support rollback, suspension, withdrawal, delisting, Registry correction, Studio pause, public-safe notice, and archive where a release is wrong, unsafe, unsupported, overclaimed, vulnerable, mislicensed, or misused.

**31.9.8 Release Compute Correction.** Release Compute records and outputs shall be corrected where wrong version is published, support status is wrong, public-safe text is missing, signatures fail, artifacts are corrupted, dependencies are unsafe, or release visibility is used as approval, deployment, or execution claim.

**31.9.9 Release Compute Formula.** Release Compute shall follow the formula: **publish only by release record; preserve artifact integrity; display support and limits; enable rollback; correct and withdraw quickly; never let publication become deployment or approval.**

***

### 31.10 Teardown Compute

**31.10.1 Teardown Compute Identity.** **Teardown Compute** shall mean compute capacity, procedures, and records used to shut down, dismantle, decommission, revoke, delete, seal, archive, restrict, or retire Foundry compute environments, temporary infrastructure, Studio runtime environments, Core Build environments, Nexus Universe compute, secure rooms, edge environments, simulation environments, AI environments, data rooms, release environments, and experimental infrastructure.

**31.10.2 Teardown Purpose.** Teardown Compute shall prevent temporary work from becoming unmanaged infrastructure, stale runtime, unsupported dashboard, exposed data store, uncontrolled AI agent, abandoned cloud resource, unmonitored connector, persistent public authority confusion, provider lock-in, data leakage, security exposure, or execution by drift.

**31.10.3 Teardown Record.** Each material teardown shall have a Teardown Compute Record identifying environment, object, reason for teardown, data disposition, artifact disposition, access revocation, credential revocation, logs or audit records where appropriate, output archive, support impact, user notice, public-safe notice where needed, residual risk, verification, correction pathway, and archive reference.

**31.10.4 Teardown Triggers.** Teardown may be triggered by end of Core Build, end of Nexus Universe arena, experiment closure, Studio runtime pause, security incident, support lapse, data permission expiry, public-safe risk, provider termination, cost or quota exhaustion, non-continuation, retirement, correction, handoff completion, or archive decision.

**31.10.5 Access and Credential Revocation.** Teardown shall include revocation or rotation of credentials, keys, tokens, service accounts, API access, model access, data-room access, secure-room access, edge device access, dashboard access, repository access, and automation permissions where applicable.

**31.10.6 Data Disposition.** Teardown shall identify what data is deleted, sealed, retained, archived, returned, aggregated, anonymized, pseudonymized, or transferred under lawful authority. Teardown shall not delete records required for accountability, correction, legal retention, public-safe notice, or institutional memory unless lawful deletion is required.

**31.10.7 Teardown Verification.** Material teardown shall be verified. Verification may include confirming resource shutdown, data deletion or sealing, access revocation, artifact archive, log retention where appropriate, public notice where needed, and dependency updates.

**31.10.8 Teardown Without Erasure of Responsibility.** Teardown shall not erase correction obligations, public-safe notice duties, support duties already created by record, handoff recall obligations, incident response duties, or archive obligations.

**31.10.9 Teardown Compute Formula.** Teardown Compute shall follow the formula: **close environments deliberately; revoke access; dispose data lawfully; archive evidence; notify where needed; verify shutdown; never let temporary compute become permanent unmanaged authority.**

***

### 31.11 Compute Records and Quotas

**31.11.1 Compute Records Principle.** Material compute use shall be record-bearing. Compute Records shall preserve who used compute, for what purpose, under what authority, in what environment, with what data, under what access controls, within what quota, producing what outputs, subject to what support, correction, retention, teardown, and archive rules.

**31.11.2 Compute Record Elements.** A Compute Record may include compute identifier, compute class, project or object, environment, provider or host, jurisdiction, user roles, access approvals, data class, workload class, AI/model class where applicable, tool permissions, quota, cost center or allocation source where applicable, sponsor/provider support where relevant, output class, support status, security controls, retention, teardown rule, correction pathway, and prohibited uses.

**31.11.3 Quota Principle.** Compute quotas shall allocate scarce compute responsibly. Quotas may govern CPU, GPU, memory, storage, network, API calls, model tokens, inference volume, training jobs, simulation runs, secure-room sessions, edge processing, data export, dashboard refreshes, and release pipeline capacity. Quotas shall prevent resource capture, uncontrolled cost, unfair access, provider dependence, and unmanaged workload growth.

**31.11.4 Quota Allocation Criteria.** Quota allocation may consider public-good value, national relevance, Nexus Universe timing, Core Build need, evidence need, simulation need, secure compute need, AI risk, support capacity, safeguard requirements, role readiness, review status, urgency, correction needs, and lifecycle stage. Quotas shall not be controlled by sponsor funding, provider preference, political influence, prestige, or visibility alone.

**31.11.5 Quota Records.** A Compute Quota Record shall identify allocation, requester, object or pathway, compute class, quota amount, duration, conditions, data class, allowed workloads, prohibited workloads, sponsor/provider support if any, review requirement, renewal rule, exhaustion rule, correction pathway, and archive rule.

**31.11.6 Quota Without Entitlement.** A quota allocation shall not create ownership, indefinite access, priority status, provider validation, procurement status, financeability, deployment authorization, execution authority, or entitlement to continuation. Quotas may be reduced, suspended, revoked, reallocated, or allowed to expire.

**31.11.7 Compute Monitoring and Review.** Compute use may be monitored for quota compliance, security, cost, data restrictions, AI safety, tool permissions, output risks, support burden, and misuse where appropriate and lawful. Monitoring shall respect privacy, confidentiality, protected knowledge, and national data controls.

**31.11.8 Compute Record Correction.** Compute Records and Quota Records shall be corrected where access was wrong, workload was misclassified, data class was wrong, quota was misused, provider support was misrepresented, outputs were overclaimed, or compute use exceeded authorization.

**31.11.9 Compute Records and Quotas Formula.** Compute Records and Quotas shall follow the formula: **record compute before material use; allocate by public-good need; limit by quota; monitor proportionately; revoke when misused; archive compute history; never treat quota as entitlement or authority.**

***

### 31.12 Compute Without Infrastructure Capture

**31.12.1 Anti-Capture Principle.** Foundry compute shall be governed to prevent **Infrastructure Capture**. Infrastructure Capture occurs where a provider, sponsor, host, donor, public authority, enterprise actor, technical faction, region, country, or platform gains improper influence over Foundry priorities, architecture, data, access, review, release, Marketplace visibility, Registry status, Studio runtime, TRL progression, readiness language, handoff routing, or public narratives by controlling or supplying compute.

**31.12.2 Capture Pathways.** Infrastructure Capture may arise through cloud credits, GPU access, proprietary AI models, exclusive hosting, data center control, telecom access, edge devices, secure-room facilities, sovereign cloud branding, event infrastructure, sponsor-funded compute, proprietary APIs, storage dependencies, model dependencies, dashboard dependencies, or operational support tied to public claims.

**31.12.3 Provider Support Without Control.** Providers may contribute compute, infrastructure, engineering support, credits, tools, devices, models, hosting, or technical expertise. Such support shall not control architecture, object status, review outcome, benchmark interpretation, public-safe language, Marketplace listing, Registry status, Studio authorization, TRL status, procurement interpretation, finance interpretation, or handoff routing.

**31.12.4 Sponsor Support Without Control.** Sponsors may support compute financially or in kind. Sponsor support shall not create naming control, agenda control, review control, data access, privileged release access, provider preference, public narrative control, Marketplace preference, Registry influence, Studio access, national routing influence, or execution entitlement.

**31.12.5 Exit and Portability.** Foundry compute architecture shall prefer portability, open technical baselines, documented dependencies, export controls, migration plans, interface standards, containerization where appropriate, provider-neutral abstractions, reproducibility where feasible, and exit pathways. Where provider-specific capabilities are used, dependency and exit risks shall be recorded.

**31.12.6 Multi-Environment Discipline.** Where feasible, Foundry shall avoid single-provider dependency for critical public-good functions. Multi-cloud, sovereign cloud, public-sector cloud, university HPC, edge, local, secure-room, and portable architectures may be used to balance resilience, sovereignty, cost, capability, and public-good independence.

**31.12.7 Compute Branding Controls.** Public references to compute providers, hosts, sponsors, hardware vendors, cloud platforms, AI models, telecom operators, or data centers shall be claims-safe. Branding shall not imply provider validation, Nexus endorsement, public authority approval, procurement preference, financeability, insurability, deployment readiness, or execution authority.

**31.12.8 Compute Capture Incident.** A Compute Capture Incident shall arise where compute support or infrastructure dependency is used to influence Foundry decisions improperly, overclaim provider status, obtain privileged data access, create exclusive dependency, distort public narratives, bypass national routing, weaken safeguards, or imply execution authority. Such incident shall trigger correction, boundary review, access review, dependency review, public-safe correction, or infrastructure migration where needed.

**31.12.9 Compute Capture Correction.** Correction may include dependency disclosure, architecture redesign, provider-neutral alternative creation, quota reallocation, access restriction, sponsor claim correction, provider claim correction, Marketplace correction, Registry correction, Studio restriction, public-safe notice, handoff recall, or migration to a more appropriate compute environment.

**31.12.10 Final Compute Formula.** The controlling Nexus Sovereign Compute Formula is that **compute is a governed technical estate for building, simulation, evidence, AI, secure processing, sovereign processing, edge processing, release, teardown, records, and quotas; compute access is not authority; provider support is not validation; sponsor support is not control; sovereign hosting is not public authority approval; edge proximity is not operational command; release compute is not deployment authorization; teardown prevents drift; quotas prevent capture; and every material compute surface must remain recorded, bounded, secure, portable where possible, correctionable, and separated from procurement, finance, consent, deployment, and execution by implication.**

## 32. Foundry Compute Architecture

### 32.1 Dense Cores

**32.1.1 Dense Core Identity.** **Dense Cores** shall be high-capability compute, networking, storage, data, simulation, AI, observability, secure-room, Studio, release, and support environments within Nexus Foundry used to concentrate technical capacity for defined Foundry purposes. A Dense Core may support Nexus Core Build, Frontier Labs, simulation, AI evaluation, Observatory acceleration, DRI and GRIx processing, public-good software production, Studio runtime preparation, Marketplace and Registry infrastructure, secure evidence workflows, and high-intensity annual-cycle production.

**32.1.2 Dense Core Function.** Dense Cores shall provide the concentrated technical substrate for workloads requiring greater performance, coordination, reliability, security, repeatability, or temporary surge capacity than ordinary distributed environments can provide. Dense Cores may support model evaluation, digital twins, geospatial processing, network simulation, critical-infrastructure simulation, AI agent testing, dashboard generation, secure computation, build pipelines, release pipelines, and controlled demonstration environments.

**32.1.3 Dense Core Governance.** Each Dense Core shall have a Dense Core Record identifying location or location class, host, provider or facility where applicable, purpose, compute classes, storage classes, networking capability, access roles, data classes, security controls, support status, quota rules, public-safe restrictions, teardown rules, archive pathway, and prohibited claims.

**32.1.4 Dense Core Access.** Access to Dense Core resources shall be role-based, need-based, time-bounded where appropriate, quota-controlled, and tied to recorded work. Dense Core access shall not be granted because of sponsorship, provider affiliation, institutional prestige, public authority attendance, capital-reader interest, media visibility, or Nexus Universe presence.

**32.1.5 Dense Core and Nexus Core Build.** Dense Cores may be used to support Nexus Core Build as temporary high-intensity technical infrastructure during preparation, build, arena, testing, simulation, public-safe review, release preparation, and post-cycle archive. Temporary intensity shall not create permanent unmanaged infrastructure or execution authority.

**32.1.6 Dense Core Boundary.** Dense Core presence, access, testing, successful build, successful simulation, dashboard display, AI evaluation, or release package generation shall not create certification, public authority approval, procurement status, financeability, insurability, provider validation, community consent, Indigenous consent where applicable, deployment authorization, or execution authority.

**32.1.7 Dense Core Correction.** Dense Core records shall be corrected where access was misassigned, data was misclassified, provider dependency was omitted, quota was captured, security controls failed, outputs were overclaimed, teardown was incomplete, or Dense Core capability was used to imply authority beyond record.

**32.1.8 Dense Core Formula.** Dense Cores shall follow the formula: **concentrate compute for public-good production; govern access by record; disclose dependencies; control outputs; tear down temporary capacity; never convert technical intensity into institutional authority.**

***

### 32.2 Regional Clusters

**32.2.1 Regional Cluster Identity.** **Regional Clusters** shall be region-level compute, data, observability, simulation, learning, and support environments used to support cross-national Nexus work across shared hazards, corridors, infrastructure systems, WEFH-B systems, climate and disaster-risk zones, digital infrastructure, supply chains, and regional Nexus Universe preparation. Regional Clusters shall translate and support national work without becoming regional governments, supranational authorities, or execution vehicles.

**32.2.2 Regional Cluster Function.** Regional Clusters may support cross-border modeling, regional Observatory Packs, DRI and GRIx context, regional dashboards, simulation environments, regional Academy pathways, regional Competence Cells, public-safe regional reporting, Core Build preparation, and National Node support. They shall coordinate regional capability while preserving national data controls, national safeguards, national public authority boundaries, and national ownership.

**32.2.3 Regional Cluster Record.** Each Regional Cluster shall have a Regional Cluster Compute Record identifying participating countries, host or hosts, compute resources, data classes, cross-border restrictions, national dependencies, public authority sensitivities, community and Indigenous protocol considerations where applicable, access roles, support status, public-safe limits, correction pathway, teardown rule, and archive rule.

**32.2.4 Regional Non-Supremacy.** Regional Cluster infrastructure shall not override National Dense Nexus Cores, National Nexus Nodes, national data rules, public authority processes, national safeguards, procurement processes, finance processes, community permissions, Indigenous protocols where applicable, or lawful national implementation pathways. Regional compute shall support national capability; it shall not replace national authority.

**32.2.5 Cross-Border Data Controls.** Regional Cluster workloads involving cross-border data shall apply the most restrictive applicable national, contractual, public authority, community, Indigenous where applicable, privacy, cyber, and safeguard controls. Regional outputs shall avoid country ranking, public warning, insurance signaling, investment signaling, procurement implication, or public authority classification unless separately and lawfully created by competent actors.

**32.2.6 Regional Cluster Continuity.** Regional Clusters may preserve continuity across annual cycles, regional Nexus Universe arenas, and regional programs, but they shall remain support environments. Their persistence shall be reviewed for public-good value, support capacity, provider-neutrality, national relevance, security posture, and correction history.

**32.2.7 Regional Cluster Correction.** Regional Cluster records shall be corrected where national routing was bypassed, cross-border controls failed, public-safe language stigmatized countries or communities, provider dependency became capture, or regional outputs were used as warnings, ratings, finance, insurance, procurement, consent, deployment, or execution signals.

**32.2.8 Regional Cluster Formula.** Regional Clusters shall follow the formula: **cluster regional capability; respect national control; apply most-restrictive safeguards; compare without ranking; support without supremacy; correct cross-border drift.**

***

### 32.3 National Dense Nexus Cores

**32.3.1 National Dense Nexus Core Identity.** A **National Dense Nexus Core** shall be the country-level high-capability compute and systems-build environment used to support national Foundry work, National Portfolio production, national Observatory needs, national public authority learning, national data controls, secure national workflows, Nexus Universe national preparation, Core Build requests, Studio preparation, Marketplace and Registry national context, and lawful handoff dependency preparation.

**32.3.2 National Dense Nexus Core Function.** A National Dense Nexus Core may provide national compute for secure data processing, national simulations, national dashboards, AI evaluation under national controls, geospatial processing, infrastructure modeling, national readiness mapping, public-safe reporting, National Working Group support, Competence Cell support, and controlled demonstration environments.

**32.3.3 National Core Record.** Each National Dense Nexus Core shall have a National Dense Nexus Core Record identifying country, host, legal and data-residency basis, provider or facility where applicable, compute classes, data classes, public authority dependencies, access roles, national safeguards, community and Indigenous protocol considerations where applicable, cross-border restrictions, support status, quota rules, correction pathway, teardown rule, and archive rule.

**32.3.4 National Ownership.** National Dense Nexus Cores shall preserve national ownership before local delivery. Global, regional, sponsor, provider, university, public authority-adjacent, capital-reader, or enterprise actors may support National Dense Nexus Cores only through recorded national pathways. Support shall not create control.

**32.3.5 National Public Authority Boundary.** Public authority use or observation of a National Dense Nexus Core shall not create official approval, warning, classification, policy adoption, procurement action, public finance allocation, emergency command, or regulatory comfort unless the competent public authority separately and lawfully acts.

**32.3.6 National Data and Sovereignty.** National Dense Nexus Cores shall apply national data controls, data residency, sovereign data requirements, privacy controls, cyber controls, protected knowledge rules, Indigenous data sovereignty considerations where applicable, community safeguards, and public-safe output review. Sensitive data shall not be exported or exposed by default.

**32.3.7 National Core Handoff.** Outputs from a National Dense Nexus Core may support lawful handoff dependency packages to National Consortium Companies or Project SPVs, but shall not authorize execution. Handoff requires separate review, recipient responsibility, legal pathways, public authority dependencies, procurement dependencies, finance and insurance dependencies, data and cyber conditions, safeguards, and consent where required.

**32.3.8 National Dense Nexus Core Formula.** National Dense Nexus Cores shall follow the formula: **anchor compute nationally; protect national data; support national portfolios; route through national records; prepare dependencies; never convert national compute into national approval or execution.**

***

### 32.4 Observatory Node Grids

**32.4.1 Observatory Node Grid Identity.** **Observatory Node Grids** shall be distributed compute, data, sensing, dashboard, indicator, and observability environments that support Nexus Observatory functions across nodes, hubs, clusters, hotspots, regional clusters, national dense cores, edge environments, and public-safe reporting pathways. They shall enable structured observation without becoming official warning systems, surveillance systems, public authority classifications, insurance ratings, investment signals, procurement tools, or operational commands.

**32.4.2 Node Grid Function.** Observatory Node Grids may support ingestion, preprocessing, indicator computation, dashboard generation, geospatial layering, Earth observation workflows, sensor integration, DRI outputs, GRIx context, resilience indicators, infrastructure stress signals, digital twin inputs, national observability packs, and public authority learning materials.

**32.4.3 Node Grid Record.** Each Observatory Node Grid shall have an Observatory Node Grid Record identifying node classes, data sources, sensors or feeds, jurisdictions, compute environment, data classes, sensitivity classifications, public-safe classifications, indicator methods, update cadence, access roles, output restrictions, national routing, correction pathway, teardown rule, and archive rule.

**32.4.4 Observatory Without Warning.** Observatory Node Grid outputs shall not constitute official public warning, emergency alert, threat bulletin, public authority classification, regulatory notice, insurance determination, investment signal, procurement priority, or operational command. They may inform learning and route evidence needs within recorded limits.

**32.4.5 Geospatial and Sensor Safeguards.** Node Grids involving geospatial data, sensors, edge feeds, infrastructure signals, community-sensitive data, Indigenous-sensitive locations or knowledge where applicable, cyber-sensitive data, or public authority-sensitive feeds shall apply heightened access, aggregation, masking, delay, output review, and public-safe controls where required.

**32.4.6 National and Regional Routing.** Country-relevant node outputs shall be routed through National Nexus Nodes or national pathways where appropriate. Regional aggregation shall not bypass national data controls or safeguards.

**32.4.7 Observatory Node Grid Correction.** Node Grid records shall be corrected where indicators are wrong, data is stale, feeds fail, sensitivity is misclassified, dashboards mislead, public-safe boundaries fail, or outputs are used as warnings, ratings, finance, insurance, procurement, consent, deployment, or execution signals.

**32.4.8 Observatory Node Grid Formula.** Observatory Node Grids shall follow the formula: **sense with safeguards; compute indicators with provenance; display uncertainty; route nationally; correct signals; never convert observability into official warning or command.**

***

### 32.5 Edge Environments

**32.5.1 Edge Environment Identity.** **Edge Environments** shall be distributed compute and sensing environments located close to devices, communities, infrastructure, telecom systems, private wireless systems, O-RAN / AI-RAN environments, field conditions, disaster-risk contexts, national dense cores, regional clusters, Observatory nodes, hubs, hotspots, or Studio demonstration environments. Edge Environments shall be governed because proximity to real-world conditions can create surveillance, operational, cyber, privacy, public-safe, and execution risks.

**32.5.2 Edge Environment Function.** Edge Environments may support local preprocessing, low-latency sensing, degraded-mode awareness, local dashboards, anomaly detection, local simulation, secure local processing, compute-to-data, public authority learning demonstrations, National Portfolio evidence, Observatory signals, and field-oriented experimentation under controlled conditions.

**32.5.3 Edge Environment Record.** Each Edge Environment shall have an Edge Environment Record identifying location or location class, host, connected systems, sensors, data classes, processing purpose, access roles, network connections, cyber controls, privacy controls, physical security, national pathway, community and Indigenous considerations where applicable, support status, teardown rule, correction pathway, and prohibited uses.

**32.5.4 Edge Data Minimization.** Edge Environments shall prefer local processing, aggregation, minimization, filtering, and reviewed outputs where raw data is sensitive, location-sensitive, community-sensitive, Indigenous-sensitive where applicable, infrastructure-sensitive, health-sensitive, public authority-sensitive, or cyber-sensitive.

**32.5.5 Edge Operational Boundary.** Edge Environments shall not control infrastructure, operate public systems, issue warnings, direct emergency response, surveil communities, make public authority decisions, automate field interventions, or execute projects unless a separate competent lawful pathway authorizes such activity outside the default Foundry perimeter.

**32.5.6 Edge Security.** Edge Environments shall apply cyber controls proportionate to exposure, including device identity, secure configuration, update management, secrets protection, network segmentation, access control, monitoring where appropriate, incident reporting, teardown procedures, and physical protection where relevant.

**32.5.7 Edge Correction and Teardown.** Edge Environments shall be corrected, restricted, disconnected, torn down, or archived where cyber risk appears, data risk increases, public-safe risk appears, community concerns arise, Indigenous protocol concerns arise where applicable, support lapses, host conditions change, or edge outputs are used as warnings, surveillance, ratings, finance, procurement, consent, deployment, or execution signals.

**32.5.8 Edge Environment Formula.** Edge Environments shall follow the formula: **compute near source; minimize exposure; protect place and people; secure devices; separate sensing from command; tear down unsafe edge; never let edge proximity become operational authority.**

***

### 32.6 Cloud Burst Capacity

**32.6.1 Cloud Burst Identity.** **Cloud Burst Capacity** shall mean temporary, elastic, externally provisioned or federated cloud compute used to supplement Dense Cores, National Dense Nexus Cores, Regional Clusters, Studio environments, simulation environments, AI compute, release compute, or Core Build workloads during peak demand, annual surge, testing, simulation, public-safe reporting, or emergency workload preparation within Foundry limits.

**32.6.2 Cloud Burst Purpose.** Cloud Burst Capacity may support temporary scale for builds, simulations, AI evaluation, dashboard rendering, geospatial processing, dataset transformation, release pipelines, Nexus Universe surge workloads, and public-safe reporting. It shall not become uncontrolled permanent infrastructure, provider lock-in, sponsor-controlled capacity, or execution surface by drift.

**32.6.3 Cloud Burst Record.** Each material Cloud Burst use shall have a Cloud Burst Record identifying provider or host, workload, duration, data class, jurisdiction, access roles, quota, security controls, data transfer limits, cost or allocation source where applicable, sponsor/provider support if any, output class, teardown rule, correction pathway, and archive rule.

**32.6.4 Data and Jurisdiction Controls.** Cloud Burst shall not be used for restricted, sovereign-sensitive, public authority-sensitive, community-sensitive, Indigenous-sensitive where applicable, cyber-sensitive, infrastructure-sensitive, health-sensitive, or protected knowledge workloads unless lawful data controls, residency requirements, provider terms, encryption, access, output review, and retention rules are recorded.

**32.6.5 Cloud Burst Provider Neutrality.** Use of cloud burst capacity from a provider shall not validate the provider, create preferred status, establish procurement preference, imply Marketplace recognition, or confer public authority approval. Provider dependencies and exit risks shall be documented.

**32.6.6 Cloud Burst Teardown.** Cloud Burst environments shall have defined teardown, data deletion or sealing, credential revocation, artifact retention, cost closure, and archive procedures. Temporary capacity shall not remain active because teardown was neglected.

**32.6.7 Cloud Burst Correction.** Cloud Burst records shall be corrected where workloads exceeded authorization, data class was wrong, cost or quota was captured, provider dependency was hidden, teardown failed, or outputs were used as approval, finance, procurement, deployment, or execution claims.

**32.6.8 Cloud Burst Formula.** Cloud Burst Capacity shall follow the formula: **scale temporarily; classify data before burst; record provider and jurisdiction; cap by quota; tear down after use; never let elastic compute become provider capture or execution authority.**

***

### 32.7 GPU and HPC Capacity

**32.7.1 GPU and HPC Identity.** **GPU and HPC Capacity** shall mean specialized high-performance compute resources used for workloads requiring accelerated computation, parallel processing, large-scale simulation, AI model evaluation, geospatial processing, digital twins, network modeling, climate and disaster-risk analysis, optimization, benchmarking, and high-throughput evidence processing. GPU and HPC Capacity shall be treated as scarce, high-value, capture-sensitive public-good technical capacity.

**32.7.2 GPU and HPC Purpose.** GPU and HPC resources may support simulation, AI evaluation, agent testing, model benchmarking, data transformation, evidence computation, Observatory workflows, DRI and GRIx analysis, national dense core workloads, regional cluster workloads, Nexus Universe surge workloads, and Frontier Labs experimentation.

**32.7.3 GPU/HPC Record.** Each material GPU/HPC allocation shall have a GPU/HPC Record identifying workload, compute type, provider or facility, jurisdiction, quota, allocation duration, data class, model class where applicable, access roles, evaluation criteria, output class, security controls, support status, teardown rule, correction pathway, and prohibited claims.

**32.7.4 Scarcity and Fair Allocation.** GPU and HPC allocation shall be governed by public-good value, evidence need, national relevance, support capacity, risk, urgency, Nexus Universe timing, Core Build requirements, safeguard conditions, and correction needs. Allocation shall not be controlled by sponsor funding, provider preference, institutional prestige, media visibility, or private advantage.

**32.7.5 AI and Model Controls.** GPU/HPC use for AI shall specify whether workloads involve training, fine-tuning, inference, retrieval, evaluation, simulation, red-team testing, or benchmarking. Sensitive data shall not be used for training or fine-tuning external models unless separately and lawfully authorized.

**32.7.6 Benchmark Boundary.** GPU/HPC benchmarking shall be reported only within recorded conditions. Benchmark results shall not validate providers, certify models, establish procurement preference, prove general safety, create financeability, or authorize deployment.

**32.7.7 GPU/HPC Provider Neutrality.** GPU/HPC contributions from providers, universities, public labs, sponsors, cloud platforms, hardware vendors, or data centers shall not create provider validation, procurement preference, Marketplace advantage, Registry approval, or execution entitlement.

**32.7.8 GPU/HPC Correction.** GPU/HPC records shall be corrected where allocation was captured, data was misclassified, benchmark claims overreached, model terms were violated, outputs were unsafe, or compute results were used as maturity, certification, procurement, finance, insurance, deployment, or execution claims.

**32.7.9 GPU/HPC Formula.** GPU and HPC Capacity shall follow the formula: **allocate scarce compute by public-good need; protect data and models; disclose providers; bound benchmarks; correct overclaim; never let high performance become high authority.**

***

### 32.8 Secure Enclaves and Confidential Computing

**32.8.1 Secure Enclave Identity.** **Secure Enclaves and Confidential Computing** shall mean protected compute environments used to process sensitive Foundry workloads under enhanced technical and procedural controls, including hardware-backed isolation, encrypted processing where applicable, secure rooms, clean rooms, controlled output review, no-download environments, restricted execution environments, and confidential collaboration spaces.

**32.8.2 Secure Enclave Purpose.** Secure Enclaves may support workloads involving restricted datasets, public authority-sensitive information, sovereign-sensitive data, cyber-sensitive information, infrastructure-sensitive data, protected knowledge, Indigenous-sensitive knowledge where applicable, community-sensitive information, health-sensitive data, confidential provider or partner information, and high-risk AI or cyber workflows.

**32.8.3 Secure Enclave Record.** Each Secure Enclave shall have a Secure Enclave Record identifying environment, host, technical controls, data classes, access roles, approved workloads, prohibited workloads, encryption or isolation controls, logging where appropriate, output review procedures, no-download rules, retention, teardown, incident pathway, correction pathway, and archive rule.

**32.8.4 Access and Output Control.** Access to Secure Enclaves shall require training, authorization, confidentiality, role readiness, need, and environment-specific approval. Outputs shall be reviewed before export, publication, Marketplace context, Registry display, Studio use, public authority learning, readiness review, capital-reader review, insurance-reader review, community-facing communication, Indigenous-facing communication where applicable, or handoff.

**32.8.5 Confidential Computing Boundary.** Use of confidential computing shall not create legal compliance certification, cybersecurity certification, privacy certification, public authority approval, procurement readiness, financeability, insurability, consent, deployment authorization, or operational guarantee. It is a control measure, not universal assurance.

**32.8.6 Protected Knowledge.** Secure Enclaves shall not be used to normalize extraction of protected knowledge. Protected knowledge, Indigenous knowledge where applicable, community-sensitive knowledge, and restricted information may require non-use, non-publication, non-export, or non-modeling even where secure computation is technically possible.

**32.8.7 Secure Enclave Incident.** Unauthorized access, output leakage, enclave misconfiguration, credential exposure, prohibited workload execution, data spill, AI prompt leakage, or confidentiality breach shall trigger incident response, access review, correction, notice where required, and archive.

**32.8.8 Secure Enclave Formula.** Secure Enclaves and Confidential Computing shall follow the formula: **isolate sensitive workloads; restrict access; review outputs; protect knowledge; respond to incidents; tear down when no longer justified; never treat secure processing as approval or permission.**

***

### 32.9 Compute-to-Data Environments

**32.9.1 Compute-to-Data Identity.** **Compute-to-Data Environments** shall be controlled environments where computation is brought to data rather than exporting data to external users, systems, models, or environments. Compute-to-Data shall be a preferred pattern for restricted, sovereign-sensitive, public authority-sensitive, rights-bearing, community-protected, Indigenous-protected where applicable, health-sensitive, cyber-sensitive, infrastructure-sensitive, and high-risk data.

**32.9.2 Compute-to-Data Purpose.** Compute-to-Data shall reduce unnecessary data movement, preserve sovereignty, protect sensitive knowledge, support lawful analysis, enable output review, and allow Foundry to create evidence, simulations, dashboards, AI analyses, Observatory outputs, readiness mappings, and public-safe summaries without exposing raw data.

**32.9.3 Compute-to-Data Record.** Each Compute-to-Data environment shall have a Compute-to-Data Record identifying data source, steward, jurisdiction, data class, approved workloads, approved users, compute tools, model permissions where applicable, prohibited workloads, output review rules, export restrictions, retention, deletion or sealing rule, incident pathway, correction pathway, and archive rule.

**32.9.4 Approved Workloads.** Approved workloads may include aggregation, feature extraction, evidence analysis, simulation, statistical analysis, geospatial processing, model evaluation, dashboard preparation, AI-assisted review, and public-safe summary generation, subject to data steward approval and safeguard controls. Training or fine-tuning AI models on restricted data shall require explicit lawful authorization.

**32.9.5 Output Review.** Outputs from Compute-to-Data Environments shall be reviewed for privacy, re-identification risk, protected knowledge exposure, community sensitivity, Indigenous protocol sensitivity where applicable, public authority sensitivity, security exposure, geospatial sensitivity, public-safe meaning, and downstream misuse risk before export or publication.

**32.9.6 No Raw Data Extraction.** Raw data extraction shall be prohibited unless separately and lawfully authorized by competent data stewards and recorded. Technical ability to extract shall not create permission to extract.

**32.9.7 Compute-to-Data Without Consent Overclaim.** Compute-to-Data controls do not create consent, rights waiver, protected knowledge permission, public authority approval, legal compliance certification, procurement status, financeability, insurance approval, deployment authorization, or execution authority. They reduce risk; they do not replace lawful permissions.

**32.9.8 Compute-to-Data Correction.** Compute-to-Data records shall be corrected where workload approval was wrong, output review failed, re-identification risk appears, export controls fail, data steward authority changes, model use exceeded permission, or outputs are misused as approval, finance, procurement, consent, deployment, or execution claims.

**32.9.9 Compute-to-Data Formula.** Compute-to-Data shall follow the formula: **bring computation to sensitive data; approve workloads; review outputs; prohibit raw extraction; respect data stewards; correct leakage; never treat controlled computation as consent or authority.**

***

### 32.10 Degraded-Mode Continuity

**32.10.1 Degraded-Mode Continuity Identity.** **Degraded-Mode Continuity** shall mean the ability of Foundry compute environments, Observatory Node Grids, National Dense Nexus Cores, Regional Clusters, Edge Environments, Studio environments, Marketplace, Registry, and release systems to continue essential public-good functions under partial outage, degraded connectivity, provider failure, cyber incident, disaster conditions, power constraints, data unavailability, or restricted-access conditions.

**32.10.2 Continuity Purpose.** Degraded-Mode Continuity shall preserve safety, records, correction pathways, access controls, public-safe notices, archive integrity, national ownership, and essential support functions when normal compute capacity is unavailable. It shall not convert Foundry into emergency command, public warning authority, public authority substitute, or operational control center.

**32.10.3 Continuity Record.** Each material compute environment shall have a Continuity Record identifying essential functions, degraded functions, unavailable functions, fallback pathways, data availability limits, access limits, security controls, public-safe notice needs, recovery priorities, national routing implications, support responsibilities, correction pathway, and archive rule.

**32.10.4 Degraded-Mode Classes.** Degraded modes may include read-only mode, offline archive mode, local-only mode, national-only mode, secure-room-only mode, no-publication mode, no-AI mode, no-agent mode, no-dashboard-refresh mode, no-raw-data mode, limited-release mode, limited-Marketplace mode, limited-Registry mode, Studio-suspended mode, or emergency-support-only mode.

**32.10.5 Public-Safe Degraded Communication.** Degraded-mode notices shall state what is unavailable, what is stale, what is unsupported, what is paused, what remains accessible, and what should not be relied upon. Notices shall not create public warning or emergency instruction unless issued by competent public authority.

**32.10.6 Continuity and Security.** Degraded operation shall not weaken access control, data protection, cyber controls, protected knowledge safeguards, Indigenous protocol safeguards where applicable, public-safe review, or no-conversion language. Operating in degraded mode shall not justify unsafe publication or uncontrolled access.

**32.10.7 Recovery and Reconciliation.** After degraded operation, records shall be reconciled, logs reviewed where appropriate, data consistency checked, queued corrections processed, support statuses updated, public notices closed or updated, and archive records completed.

**32.10.8 Degraded-Mode Correction.** Continuity records shall be corrected where degraded procedures failed, users relied on stale outputs, public-safe notices were unclear, access controls weakened, data was exposed, or degraded mode was used as authority, warning, deployment, or execution justification.

**32.10.9 Degraded-Mode Formula.** Degraded-Mode Continuity shall follow the formula: **preserve records and safety first; reduce functions before reducing safeguards; notify limits; reconcile after recovery; never let outage response become public authority or execution.**

***

### 32.11 Compute Allocation and Scarcity Rules

**32.11.1 Allocation Principle.** **Compute Allocation and Scarcity Rules** shall govern how Foundry allocates limited Dense Core, Regional Cluster, National Dense Core, GPU, HPC, AI, secure, edge, cloud burst, release, and Studio compute capacity. Allocation shall serve public-good value, evidence needs, national relevance, safeguard requirements, correction needs, support capacity, and lifecycle discipline.

**32.11.2 Scarcity Recognition.** Compute is scarce not only because of cost, but because of energy, carbon, access, security, provider dependency, jurisdiction, data sensitivity, human reviewer capacity, support capacity, and opportunity cost. Allocation shall therefore consider whether a workload should run, where it should run, at what scale, for how long, under what safeguards, and whether lower-cost or lower-risk alternatives exist.

**32.11.3 Allocation Criteria.** Compute may be allocated based on public-good priority, Nexus Universe timing, Core Build need, National Portfolio relevance, public authority learning value, evidence value, Observatory value, readiness-question value, safeguard urgency, correction urgency, security need, support capacity, reproducibility need, role readiness, and lawful data controls.

**32.11.4 Prohibited Allocation Bases.** Compute shall not be allocated based solely on sponsor funding, provider interest, investor interest, public-stage visibility, seniority, institutional prestige, political influence, media attention, partner pressure, or private commercial advantage. Sponsored compute shall remain subject to public-good allocation rules.

**32.11.5 Quotas and Time Bounds.** Compute allocations shall use quotas, time bounds, workload classes, priority classes, review triggers, renewal rules, exhaustion rules, and teardown requirements. Quotas may apply to CPU, GPU, memory, storage, network, model tokens, API calls, simulation runs, secure-room sessions, dashboard refreshes, edge processing, and release pipeline capacity.

**32.11.6 Allocation Record.** A Compute Allocation Record shall identify requester, object, pathway, compute class, allocation basis, quota, duration, data class, allowed workloads, prohibited workloads, provider or sponsor support if any, review conditions, renewal rule, exhaustion rule, correction pathway, teardown rule, and archive rule.

**32.11.7 Allocation Review and Revocation.** Compute allocations may be reviewed, reduced, suspended, revoked, or reallocated where workload purpose changes, data class changes, risk increases, support capacity lapses, quota is misused, provider capture appears, public-safe risk appears, or public-good priority changes.

**32.11.8 Scarcity and Equity.** Allocation shall consider equitable access across National Nodes, regions, domains, contributor groups, public-interest work, and capability formation needs while preserving risk controls. Equity shall not override safeguards, security, data controls, or role readiness.

**32.11.9 Allocation Formula.** Compute Allocation and Scarcity Rules shall follow the formula: **allocate scarce compute by public-good need; cap use by quota; prioritize safeguarded evidence and national value; prevent capture; revoke misuse; archive allocation history.**

***

### 32.12 Compute Closure and Archive

**32.12.1 Closure and Archive Principle.** **Compute Closure and Archive** shall ensure that compute environments do not persist beyond their purpose, expose data after use, retain unnecessary access, create unmanaged costs, preserve stale dashboards, leave active AI agents, maintain unsupported connectors, or drift into execution infrastructure. Closure shall be deliberate; archive shall preserve accountability.

**32.12.2 Closure Triggers.** Closure may be triggered by project completion, Nexus Universe cycle completion, Core Build completion, experiment closure, support lapse, data permission expiry, security concern, correction, public-safe concern, national non-continuation, handoff completion, provider termination, budget or quota exhaustion, retirement, or archive decision.

**32.12.3 Closure Record.** A Compute Closure Record shall identify environment, object, closure reason, data disposition, artifact disposition, access revocation, credential rotation or revocation, output archive, logs retained where appropriate, support impact, public notice needs, handoff implications, residual risks, verification, correction pathway, and archive reference.

**32.12.4 Data Disposition.** Closure shall determine whether data is deleted, sealed, returned, retained, aggregated, anonymized, pseudonymized, archived, or transferred under lawful authority. Closure shall not destroy required accountability records unless lawful deletion is required.

**32.12.5 Access Revocation.** Closure shall revoke or rotate credentials, API keys, tokens, service accounts, SSH keys, model access, data-room access, secure-room access, Studio access, dashboard access, edge access, and repository access where applicable.

**32.12.6 Artifact Archive.** Build artifacts, simulation outputs, evidence outputs, model outputs, dashboards, release packages, logs where appropriate, test records, support notes, correction records, and public-safe outputs shall be archived according to sensitivity, retention, public-safe, and national rules.

**32.12.7 Closure Verification.** Material compute closure shall be verified. Verification shall confirm resource shutdown, data disposition, credential revocation, access closure, cost closure, archive completion, notice completion where required, and residual-risk handling.

**32.12.8 No Current Authority From Compute Archive.** Archived compute environments, outputs, dashboards, simulations, AI results, release artifacts, or Studio packages shall not be cited as current, supported, authorized, deployable, decision-ready, public-warning-ready, finance-ready, procurement-ready, consented, or execution-ready unless reinstated by current review and record.

**32.12.9 Compute Closure and Archive Formula.** Compute Closure and Archive shall follow the formula: **close what should not persist; revoke access; dispose data lawfully; preserve accountability; archive outputs with limits; verify closure; never let old compute become current authority.**

***

### 32.13 Verifiable Compute

**32.13.1 Verifiable Compute Identity.** **Verifiable Compute** shall mean the record-bearing, reproducibility-aware, provenance-preserving, integrity-protected, reviewable, and correctionable use of compute within Nexus Foundry. It shall help users understand what was computed, where, by whom or what process, using which data, methods, code, models, parameters, tools, dependencies, permissions, and outputs, under what limits.

**32.13.2 Verifiable Compute Purpose.** Verifiable Compute shall strengthen evidence trust, auditability within limits, reproducibility where feasible, provenance, dependency transparency, AI accountability, simulation integrity, release integrity, support integrity, public-safe reporting, Registry status truth, Marketplace metadata, Studio runtime control, and lawful handoff dependency clarity. It shall not create audit assurance, certification, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, or execution authority.

**32.13.3 Verifiable Compute Record.** A Verifiable Compute Record shall identify workload, compute environment, data sources, data versions, code or workflow versions where applicable, model versions, parameters, dependencies, access roles, tool permissions, execution timestamp or period, output identifiers, integrity checks, review status, limitations, correction pathway, retention rule, and prohibited interpretations.

**32.13.4 Provenance and Lineage.** Verifiable Compute shall preserve lineage from source data to transformed data, model input, workflow execution, intermediate artifact where appropriate, output, review, release, Registry record, Marketplace listing, Studio package, or handoff dependency package. Where full lineage cannot be disclosed publicly, controlled lineage records shall be preserved.

**32.13.5 Reproducibility With Safeguards.** Reproducibility shall be pursued where lawful, safe, and feasible. Reproducibility may be restricted by privacy, sovereignty, protected knowledge, Indigenous protocols where applicable, cybersecurity, public authority sensitivity, proprietary constraints, or public-safe concerns. Restricted reproducibility shall be documented.

**32.13.6 Integrity Controls.** Verifiable Compute may use checksums, signatures, manifests, software bills of materials, model cards, system cards, benchmark cards, run logs, access logs where appropriate, environment snapshots, container hashes, workflow identifiers, or other integrity controls proportionate to risk.

**32.13.7 Verifiable Compute and Correction.** Compute records shall be corrected where provenance is incomplete, run conditions are wrong, model versions are misidentified, parameters are missing, dependencies are unsafe, outputs are overclaimed, or verification artifacts are misused as certification.

**32.13.8 Verifiable Compute Boundary.** Verifiability shall mean that compute is reviewable within recorded limits. It shall not mean that the result is true for all purposes, legally approved, public authority accepted, financeable, insurable, procurement-ready, consented, deployable, or executable.

**32.13.9 Verifiable Compute Formula.** Verifiable Compute shall follow the formula: **record the run; preserve lineage; protect integrity; disclose limits; reproduce where safe; correct provenance gaps; never let verifiability become certification or approval.**

***

### 32.14 Verifiable Intelligence

**32.14.1 Verifiable Intelligence Identity.** **Verifiable Intelligence** shall mean the record-bearing, provenance-grounded, method-bounded, uncertainty-aware, human-reviewable, correctionable, and public-safe generation of intelligence outputs from data, models, AI systems, simulations, Observatory signals, DRI outputs, GRIx context, dashboards, public authority learning materials, readiness mappings, and Studio workflows. It shall be intelligence that can be traced, reviewed, bounded, corrected, and archived.

**32.14.2 Verifiable Intelligence Purpose.** Verifiable Intelligence shall improve the trustworthiness of Foundry outputs by ensuring that claims, summaries, classifications, risk signals, scenario interpretations, AI-assisted analyses, dashboard insights, readiness questions, public-safe reports, and handoff dependency notes are grounded in source records, methods, uncertainty, limitations, human review where required, and correction pathways.

**32.14.3 Intelligence Record.** A Verifiable Intelligence Record shall identify intelligence output, source records, data sources, models or methods used, AI systems used where applicable, prompts or workflow class where relevant, assumptions, uncertainty, confidence limits, reviewer, public-safe status, sensitivity class, intended audience, prohibited uses, correction pathway, and archive rule.

**32.14.4 AI-Assisted Intelligence.** AI-assisted intelligence shall identify model dependencies, retrieval sources, tool permissions, human review points, known limitations, hallucination controls, and output restrictions. AI assistance shall not become autonomous authority. Human review shall be required where outputs affect public-safe reporting, public authority learning, readiness mapping, safeguards, Marketplace displays, Registry displays, Studio outputs, or handoff packages.

**32.14.5 Intelligence Without Official Classification.** Verifiable Intelligence shall not create official public warnings, public authority classifications, regulatory findings, threat bulletins, insurance determinations, investment signals, procurement evaluations, consent determinations, deployment instructions, or operational commands unless a competent lawful actor separately creates such output within its own authority.

**32.14.6 Uncertainty and Limits.** Intelligence outputs shall state uncertainty, assumptions, evidence gaps, method limits, time limits, geography limits, data limits, model limits, public-safe limits, and decision boundaries. False precision shall be treated as an intelligence quality failure.

**32.14.7 Intelligence Correction.** Verifiable Intelligence records shall be corrected where sources change, methods fail, AI outputs hallucinate, uncertainty is understated, public-safe language is unsafe, classification is overclaimed, dashboard interpretation is wrong, readiness language implies finance, or users treat intelligence as authority.

**32.14.8 Intelligence Archive.** Superseded, corrected, withdrawn, restricted, or retired intelligence outputs shall be archived with source lineage and correction history. Archived intelligence shall not be treated as current intelligence unless reinstated by record.

**32.14.9 Verifiable Intelligence Formula.** Verifiable Intelligence shall follow the formula: **ground intelligence in records; identify methods and models; state uncertainty; require human review where risk demands; correct wrong outputs; archive memory; never let intelligence become official authority or execution.**

***

### 32.15 Data Resilience and Zero Trust Paradigm

**32.15.1 Data Resilience and Zero Trust Identity.** **Data Resilience and the Zero Trust Paradigm** shall be the security, continuity, access, identity, verification, segmentation, least-privilege, recovery, and correction framework governing Foundry compute architecture. It shall assume that systems, networks, identities, data flows, tools, AI agents, providers, connectors, dashboards, edge devices, and human workflows may fail, drift, be misconfigured, be compromised, be misunderstood, or be overclaimed unless continuously bounded and verified.

**32.15.2 Data Resilience Purpose.** Data resilience shall ensure that Foundry data, evidence records, Registry records, Marketplace records, Studio records, Observatory records, DRI and GRIx records, public-safe materials, support records, correction records, archive records, national records, and handoff dependency packages remain available, accurate, protected, recoverable, versioned, and interpretable through disruption, attack, error, provider failure, national pathway disruption, or lifecycle transition.

**32.15.3 Zero Trust Purpose.** Zero Trust shall ensure that no user, device, workload, provider, agent, model, connector, API, dashboard, repository, edge node, Studio runtime, secure room, or network path is trusted by default. Access shall be explicitly authorized, continuously bounded, proportionate to role, conditioned on data class, reviewed for risk, and revoked when no longer justified.

**32.15.4 Zero Trust Controls.** Foundry compute architecture should apply identity verification, strong authentication, least privilege, role-based and attribute-based access, segmentation, workload identity, device trust assessment where appropriate, secrets management, encryption, logging where appropriate, continuous monitoring where lawful and proportionate, anomaly detection, output review, policy-as-code where appropriate, and rapid revocation.

**32.15.5 Data Resilience Controls.** Data resilience may include backups, replication where lawful, immutable records where appropriate, versioning, checksums, controlled archives, geographically appropriate redundancy, national data residency compliance, recovery testing, degraded-mode continuity, restoration procedures, incident playbooks, archive validation, and correction reconciliation after recovery.

**32.15.6 AI and Agent Zero Trust.** AI agents, copilots, automation workflows, retrieval systems, classifiers, summarizers, and Studio agents shall be treated as untrusted by default. They shall receive minimal tool permissions, limited data access, human review points, sandboxing, prompt-injection controls, output controls, shutdown conditions, and correction pathways.

**32.15.7 Provider and Connector Zero Trust.** Providers, platforms, connectors, APIs, cloud services, telemetry feeds, models, repositories, package registries, and dashboards shall be treated as dependency risks to be disclosed, monitored, limited, and replaceable where possible. Provider support shall not create trust without controls.

**32.15.8 Resilience Without Surveillance Overclaim.** Data resilience and Zero Trust controls shall not become unrestricted surveillance, hidden monitoring, public authority intelligence gathering, workplace surveillance, community surveillance, or operational command. Monitoring shall be lawful, proportionate, documented, purpose-bound, and sensitive to privacy, protected knowledge, community safeguards, and Indigenous protocols where applicable.

**32.15.9 Incident, Recovery, and Correction.** Data resilience and Zero Trust failures shall trigger incident response, access review, credential rotation, segmentation review, data restoration, public-safe notice where needed, Registry correction, Marketplace correction, Studio correction, national record correction, handoff recall where needed, archive update, and recurrence controls.

**32.15.10 Final Compute Architecture Formula.** The controlling Foundry Compute Architecture Formula is that **Dense Cores concentrate capability; Regional Clusters translate and support; National Dense Nexus Cores preserve national ownership; Observatory Node Grids structure sensing; Edge Environments process near source; Cloud Burst provides temporary scale; GPU and HPC capacity serves scarce high-intensity workloads; Secure Enclaves and Compute-to-Data protect sensitive data; Degraded-Mode Continuity preserves essential functions under failure; allocation rules prevent capture; closure and archive prevent drift; Verifiable Compute makes runs traceable; Verifiable Intelligence makes outputs reviewable; and Data Resilience with Zero Trust ensures that no compute, data, user, model, provider, connector, dashboard, agent, or environment becomes trusted, authoritative, deployable, or executable by implication.**

## 33. Foundry Edge Architecture

### 33.1 Edge as Local Reality Interface

**33.1.1 Edge Architecture Identity.** **Foundry Edge Architecture** shall be the local reality interface through which Nexus Foundry may receive, structure, test, validate, contextualize, safeguard, and route place-based signals from local sensing environments, Observatory Nodes, edge telemetry, Earth observation interfaces, GIS and geospatial layers, IoT, OT, in-situ instrumentation, community-grounded inputs, local verification pathways, and degraded-mode continuity systems. Edge Architecture shall connect Foundry’s public-good production system to real-world conditions without converting sensing, telemetry, maps, dashboards, community inputs, or local observations into public authority decisions, public warnings, surveillance authority, consent, deployment authorization, operational command, or execution.

**33.1.2 Edge as Interface, Not Authority.** Edge shall be understood as an interface with local reality, not as a decision authority over local reality. It may help Foundry understand what is changing, where uncertainty exists, where observability gaps remain, where infrastructure dependencies appear, where community context matters, where Indigenous protocols may be implicated, where public authority learning is needed, and where national routing or safeguard review is required. Edge shall not decide what a public authority must do, what a community has consented to, what an operator must operate, what a provider may deploy, what a Project SPV may execute, or what a capital reader should finance.

**33.1.3 Edge Public-Good Purpose.** Edge Architecture shall support public-good observability, evidence formation, local validation, degraded-mode awareness, national portfolio formation, DRI and GRIx context, Observatory Packs, public authority learning, community-safe reporting, resilience indicators, infrastructure dependency awareness, AI and digital-twin testing, field-to-network synchronization, and lawful handoff dependency mapping. It shall not be used to create covert surveillance, provider-controlled sensing, sponsor-controlled narratives, unreviewed public warnings, automated operational control, or extraction of protected knowledge.

**33.1.4 Edge Components.** Foundry Edge Architecture may include physical sensors, environmental monitors, telecom and private wireless interfaces, AI-RAN/O-RAN-related observability points, IoT devices, OT interfaces, local compute devices, secure edge gateways, geospatial layers, Earth observation pipelines, local dashboards, community input channels, field validation protocols, data collection forms, mobile tools, national observability interfaces, and controlled edge-to-network synchronization pathways.

**33.1.5 Edge Records.** Material Edge Architecture shall be record-bearing. Edge Records shall identify local context, system or geography, device or input class, data class, access class, public-safe class, national pathway, community safeguard conditions, Indigenous protocol considerations where applicable, public authority sensitivity, provider dependencies, telemetry limits, verification methods, synchronization rules, drift controls, degraded-mode rules, correction pathway, archive rule, and prohibited interpretations.

**33.1.6 Edge and National Routing.** Country-relevant edge systems and outputs shall be routed through National Nexus Nodes, National Dense Nexus Cores, National Working Groups, national data controls, public authority learning pathways, national safeguards, community pathways, Indigenous protocols where applicable, and national public-safe review where required. Edge proximity shall not bypass national ownership.

**33.1.7 Edge Safeguard Priority.** Edge work shall be treated as safeguard-sensitive because it can touch people, places, infrastructure, devices, local knowledge, protected knowledge, sensitive geographies, public authority information, cyber-physical systems, and community trust. The closer Foundry moves to local reality, the stronger the requirement for safeguards, access discipline, output review, consent-boundary clarity, correction, and archive.

**33.1.8 Edge Formula.** Foundry Edge Architecture shall operate according to the formula: **sense locally; classify before use; validate before claim; synchronize with records; protect people and place; preserve national routing; correct drift; never let edge signals become public warning, public authority decision, surveillance, consent, deployment, or execution by implication.**

***

### 33.2 Observatory Nodes

**33.2.1 Observatory Node Identity.** **Observatory Nodes** shall be localized or domain-specific observability points within the Nexus Observatory and Foundry Edge Architecture. They may collect, receive, compute, aggregate, validate, contextualize, or route signals relevant to risk, resilience, infrastructure, climate, disaster risk, WEFH-B systems, cyber-physical systems, telecom, AI, geospatial conditions, public authority learning, and national portfolio formation. They shall be observability nodes, not public warning authorities or operational command nodes.

**33.2.2 Observatory Node Function.** Observatory Nodes may support local sensing, indicator computation, dashboard inputs, DRI evidence, GRIx attention structures, National Portfolio objects, public-safe summaries, Nexus Universe preparation, Core Build evidence, edge validation, degraded-mode awareness, and lawful handoff dependency identification. They may help identify what requires review; they shall not determine official status.

**33.2.3 Observatory Node Record.** Each Observatory Node shall have an Observatory Node Record identifying node type, location or location class, domain, host, national pathway, data sources, sensing methods, compute environment, access roles, data classes, public-safe class, public authority sensitivity, community safeguard requirements, Indigenous protocol considerations where applicable, provider dependencies, update cadence, verification method, output limits, correction pathway, teardown rule, and archive rule.

**33.2.4 Node Classes.** Observatory Nodes may include environmental nodes, climate nodes, disaster-risk nodes, infrastructure nodes, cyber nodes, telecom and edge nodes, AI systems nodes, geospatial nodes, Earth observation nodes, public authority learning nodes, community-grounded nodes, national dense core nodes, regional cluster nodes, secure-room nodes, and Studio demonstration nodes. Each node class shall carry appropriate controls.

**33.2.5 Node Output Boundary.** Observatory Node outputs shall not constitute official public warnings, emergency alerts, regulatory classifications, public safety directives, insurance determinations, investment signals, procurement priorities, public finance allocations, community consent, Indigenous consent where applicable, deployment authorization, operational control, or execution. Outputs shall remain evidence, observability, learning, attention, or dependency records unless a competent lawful actor separately acts.

**33.2.6 Node Public-Safe Display.** Node outputs proposed for display shall be reviewed for public-safe meaning, uncertainty, false precision, warning-like design, rating-like design, geospatial sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, public authority confusion, and potential misuse by finance, insurance, procurement, or execution actors.

**33.2.7 Node Correction and Teardown.** Observatory Nodes shall be corrected, restricted, paused, disconnected, torn down, or archived where data quality fails, sensors drift, telemetry becomes stale, outputs mislead, public-safe risk appears, provider dependency becomes capture, safeguards fail, or node outputs are used as warnings, ratings, finance signals, procurement signals, consent, deployment, or execution authority.

**33.2.8 Observatory Node Formula.** Observatory Nodes shall follow the formula: **observe under mandate; record source and method; show uncertainty; route outputs nationally where relevant; publish only public-safe results; correct node drift; never convert observability into official authority.**

***

### 33.3 Local Sensing Environments

**33.3.1 Local Sensing Environment Identity.** **Local Sensing Environments** shall be bounded physical, digital, cyber-physical, geospatial, community, infrastructure, or ecological contexts in which Foundry may receive or process local signals through sensors, devices, public datasets, partner systems, provider systems, community inputs, public authority inputs, Earth observation, or field validation. These environments shall be governed because local sensing can affect privacy, trust, safety, public meaning, protected knowledge, and cyber-physical systems.

**33.3.2 Sensing Environment Purpose.** Local Sensing Environments may support evidence formation, Observatory Node operation, national portfolio inputs, infrastructure dependency awareness, climate and disaster-risk observability, degraded-mode awareness, AI and digital-twin validation, public authority learning, public-safe reporting, readiness mapping, and safeguard identification. They shall not be used as unbounded data extraction zones.

**33.3.3 Sensing Environment Record.** Each material Local Sensing Environment shall have a Sensing Environment Record identifying location or location class, purpose, host, data sources, sensing instruments, data classes, public-safe class, access roles, collection limits, retention rules, local safeguards, community considerations, Indigenous protocol considerations where applicable, public authority dependencies, provider dependencies, output review, correction pathway, teardown rule, and archive rule.

**33.3.4 Sensing Sources.** Local sensing may include environmental sensors, weather stations, water sensors, energy systems, telecom and network telemetry, IoT devices, OT signals, satellite and aerial imagery, ground observations, mobile inputs, field reports, public authority datasets, community observations, public datasets, and controlled partner inputs. Each source shall be classified before use.

**33.3.5 Consent and Permission Boundary.** Presence of sensors, public data, partner data, or community inputs shall not create consent for all uses. Collection permission, data use permission, public display permission, model training permission, protected knowledge permission, Indigenous knowledge permission where applicable, and handoff permission are separate and must be recorded where required.

**33.3.6 Local Sensing Minimization.** Sensing shall be proportionate to purpose. Foundry shall prefer minimization, aggregation, local processing, masking, delayed display, and output review where raw signals could expose people, communities, sensitive infrastructure, protected knowledge, Indigenous-sensitive places or knowledge where applicable, or public authority-sensitive information.

**33.3.7 Local Sensing and Public Authority Boundary.** Sensing environments connected to public authority systems, emergency systems, critical infrastructure, utilities, health systems, transport systems, telecom systems, or public facilities shall preserve public authority and operator boundaries. Foundry shall not act as public authority, operator, emergency manager, or infrastructure controller by receiving signals.

**33.3.8 Local Sensing Formula.** Local Sensing Environments shall follow the formula: **define the place; define the purpose; classify the signal; minimize collection; preserve permissions; review outputs; correct misuse; never let sensing become surveillance, public authority action, or execution.**

***

### 33.4 Edge Telemetry

**33.4.1 Edge Telemetry Identity.** **Edge Telemetry** shall mean time-stamped, event-based, streamed, periodic, sampled, aggregated, or derived signals generated by edge devices, sensors, infrastructure interfaces, applications, dashboards, network systems, AI workflows, Observatory Nodes, Studio environments, or local validation tools. Telemetry shall be treated as evidence-sensitive and context-dependent, not as self-executing truth.

**33.4.2 Telemetry Purpose.** Edge Telemetry may support monitoring of system conditions, anomaly detection, degraded-mode awareness, evidence formation, dashboard updates, DRI and GRIx context, simulation calibration, AI workflow evaluation, public authority learning, national portfolio records, support diagnostics, correction triggers, and archive memory. It shall not by itself create warning, rating, command, or decision.

**33.4.3 Telemetry Record.** Each material telemetry stream or telemetry class shall have a Telemetry Record identifying source, device or system class, data fields, frequency, latency, sampling method, transformation method, data class, sensitivity class, public-safe class, access roles, retention rule, aggregation rule, output review, synchronization pathway, correction trigger, archive rule, and prohibited uses.

**33.4.4 Telemetry Quality Controls.** Telemetry shall be reviewed for accuracy, calibration, timestamp integrity, missingness, drift, bias, device failure, network failure, spoofing risk, cyber risk, transformation error, aggregation error, and interpretation limits. Telemetry gaps shall be recorded, not hidden.

**33.4.5 Telemetry and Automation Boundary.** Telemetry shall not trigger automated public warning, public authority action, procurement action, finance action, insurance action, consent determination, infrastructure control, field intervention, emergency response, or execution unless a separate competent lawful system outside default Foundry authority is expressly authorized and controlled by the appropriate actor.

**33.4.6 Telemetry Public-Safe Controls.** Public display of telemetry shall be reviewed for false precision, panic risk, stigma, warning-like interpretation, market or insurance sensitivity, security sensitivity, community risk, Indigenous protocol sensitivity where applicable, and public authority confusion. Aggregation, delay, masking, or non-public handling may be required.

**33.4.7 Telemetry Security.** Telemetry systems shall apply controls proportionate to risk, including device identity, authentication, integrity checking where appropriate, secure transport, access control, secrets management, tamper awareness, anomaly detection where appropriate, and incident response.

**33.4.8 Telemetry Correction.** Telemetry Records and outputs shall be corrected where sensors drift, calibration fails, timestamps are wrong, devices are compromised, transformations are flawed, dashboards overclaim, synchronization fails, or telemetry is used as warning, rating, finance, insurance, procurement, consent, deployment, or execution signal.

**33.4.9 Edge Telemetry Formula.** Edge Telemetry shall follow the formula: **treat signals as evidence candidates; preserve provenance and timing; check drift and integrity; restrict automation; display carefully; correct telemetry failure; never let telemetry become command by default.**

***

### 33.5 Earth Observation Interfaces

**33.5.1 Earth Observation Interface Identity.** **Earth Observation Interfaces** shall be Foundry Edge Architecture pathways for using satellite imagery, aerial imagery, remote sensing products, radar, thermal data, spectral data, climate data, land-use data, water data, environmental signals, infrastructure observations, and related geospatial products in support of observability, evidence formation, DRI, GRIx, National Portfolios, public authority learning, simulations, dashboards, public-safe reporting, and lawful handoff dependency mapping.

**33.5.2 Earth Observation Purpose.** Earth Observation Interfaces may help identify exposure, vulnerability, hazard patterns, land-use changes, water stress, vegetation stress, infrastructure conditions, disaster impacts, environmental degradation, settlement patterns, energy and logistics dependencies, and other systems conditions. They shall support learning and evidence, not official determination by implication.

**33.5.3 Earth Observation Record.** Each material Earth Observation use shall have an Earth Observation Record identifying source, sensor or product class, spatial resolution, temporal resolution, geography, data license, provider dependency, processing method, uncertainty, limitations, sensitivity class, public-safe class, national pathway, safeguard conditions, output review, correction pathway, archive rule, and prohibited interpretations.

**33.5.4 Earth Observation Sensitivity.** Earth observation may expose sensitive infrastructure, community locations, Indigenous territories or protected places where applicable, conflict-sensitive areas, protected ecosystems, private property, health or humanitarian conditions, public authority-sensitive information, or security-sensitive patterns. Such outputs shall be classified and controlled before publication or handoff.

**33.5.5 Earth Observation Without Official Classification.** Earth observation outputs shall not by themselves classify land, infrastructure, communities, public authorities, companies, countries, protected areas, hazard status, damage status, eligibility, compliance, or public priority unless a competent lawful actor separately creates such classification.

**33.5.6 Public-Safe Mapping.** Earth observation maps shall be reviewed for uncertainty, resolution limits, false precision, stigmatizing display, sensitive location exposure, public warning implication, finance or insurance interpretation, procurement implication, and public authority confusion. Map legends, colors, labels, and summaries shall be claims-safe.

**33.5.7 Earth Observation and National Routing.** Country-specific Earth observation outputs shall be routed through national pathways where they affect national portfolios, public authority learning, public-safe reporting, community context, Indigenous protocols where applicable, infrastructure, procurement, finance, insurance, or handoff.

**33.5.8 Earth Observation Correction.** Earth Observation Records and outputs shall be corrected where source data is wrong, processing misclassifies features, resolution limits are ignored, imagery becomes stale, sensitive locations are exposed, or outputs are used as official classification, warning, rating, finance, insurance, procurement, consent, deployment, or execution authority.

**33.5.9 Earth Observation Formula.** Earth Observation Interfaces shall follow the formula: **observe from above; ground in method and uncertainty; protect sensitive places; route nationally; publish only public-safe maps; never let imagery become official classification or command.**

***

### 33.6 GIS and Geospatial Layers

**33.6.1 GIS and Geospatial Layer Identity.** **GIS and Geospatial Layers** shall be structured spatial data, maps, overlays, spatial indices, routing layers, hazard layers, exposure layers, infrastructure layers, environmental layers, demographic layers, community context layers, protected knowledge sensitivity layers, Indigenous protocol-sensitive layers where applicable, and dashboard layers used by Foundry to understand place-based systems within recorded limits.

**33.6.2 Geospatial Purpose.** GIS and Geospatial Layers may support National Portfolio formation, Observatory dashboards, DRI analysis, GRIx attention structures, simulation, digital twins, infrastructure dependency mapping, public authority learning, community-safe reporting, readiness mapping, Studio workflows, Marketplace context, Registry context, and handoff dependency mapping.

**33.6.3 Geospatial Layer Record.** Each material Geospatial Layer shall have a Geospatial Layer Record identifying layer name, source, version, geography, spatial resolution, temporal currency, attributes, license or terms, sensitivity class, public-safe class, access class, national pathway, community and Indigenous protocol considerations where applicable, uncertainty, limitations, correction pathway, archive rule, and prohibited uses.

**33.6.4 Layer Stacking Risk.** Combining layers may create new sensitivity or inference risk even where individual layers are public or low-risk. Layer stacking may reveal protected locations, vulnerable communities, infrastructure weaknesses, security-sensitive patterns, public authority-sensitive information, or finance/insurance-relevant interpretations. Layer combinations shall be reviewed.

**33.6.5 Geospatial Public-Safe Rules.** Public-facing GIS outputs shall avoid false precision, harmful labeling, stigmatizing places, exposing protected knowledge, revealing sensitive infrastructure, implying public warning, implying public authority classification, implying insurance or investment scoring, or implying procurement priority. Public versions may require aggregation, masking, generalization, delay, or suppression.

**33.6.6 National and Community Context.** Geospatial layers shall be interpreted with national, local, community, and Indigenous context where applicable. Spatial data shall not erase local knowledge, legal realities, land rights, customary governance, accessibility needs, or lived-risk context.

**33.6.7 Geospatial Use Boundary.** GIS layers shall not authorize entry, deployment, land use, public authority action, procurement, finance, insurance, community engagement, Indigenous engagement where applicable, infrastructure intervention, emergency response, or execution. They provide spatial context within record.

**33.6.8 Geospatial Correction.** Geospatial records and outputs shall be corrected where layers are stale, attributes are wrong, resolution is misrepresented, public-safe risks appear, sensitive locations are exposed, layer stacking creates harm, or maps are used as warnings, ratings, finance, insurance, procurement, consent, deployment, or execution signals.

**33.6.9 GIS and Geospatial Formula.** GIS and Geospatial Layers shall follow the formula: **map with provenance; classify sensitivity; review layer combinations; generalize when needed; route nationally; correct map drift; never let spatial display become authority.**

***

### 33.7 IoT, OT, and In-Situ Instrumentation

**33.7.1 IoT, OT, and In-Situ Instrumentation Identity.** **IoT, OT, and In-Situ Instrumentation** shall mean connected devices, sensors, industrial systems interfaces, operational technology signals, field instruments, local measurement systems, telemetry devices, gateways, probes, controllers, and related cyber-physical interfaces that may provide Foundry with local evidence or observability inputs. These instruments shall be governed with heightened care because they may be connected to real-world systems.

**33.7.2 Instrumentation Purpose.** IoT, OT, and in-situ instrumentation may support environmental monitoring, infrastructure condition awareness, degraded-mode awareness, water-energy-food-health-biodiversity observability, telecom and edge systems awareness, local validation, field testing, national portfolio evidence, public authority learning, and simulation calibration. They shall not be used to control systems by default.

**33.7.3 Instrumentation Record.** Each material instrumentation deployment or interface shall have an Instrumentation Record identifying device or system class, host, location or location class, owner or steward where applicable, connected systems, data fields, collection purpose, control capability if any, access roles, cyber controls, safety controls, privacy controls, public-safe limits, national pathway, community and Indigenous considerations where applicable, correction pathway, teardown rule, and archive rule.

**33.7.4 OT Control Boundary.** Foundry shall not control OT systems, industrial equipment, utilities, telecom systems, transport systems, health systems, public safety systems, emergency systems, or critical infrastructure by default. Read-only observability shall be separated from control capability. Any control capability must be disabled, sandboxed, or separately and lawfully authorized outside default Foundry operations.

**33.7.5 Device Security.** Instrumentation shall include cyber controls proportionate to risk, including device identity, secure configuration, patch management where feasible, network segmentation, access control, secrets protection, tamper awareness, physical security where relevant, incident reporting, and teardown procedures.

**33.7.6 Instrumentation Data Controls.** Data from devices and OT systems may reveal sensitive infrastructure, operational patterns, vulnerabilities, personal data, community-sensitive information, Indigenous-sensitive information where applicable, or public authority-sensitive information. Such data shall be classified, minimized, aggregated, and reviewed before publication or handoff.

**33.7.7 Instrumentation Provider Boundary.** Provider-supplied devices, sensors, gateways, platforms, cloud services, AI models, or instrumentation support shall not validate the provider, create procurement preference, approve technology, establish Marketplace priority, or create deployment authority. Dependencies shall be disclosed.

**33.7.8 Instrumentation Correction and Teardown.** Instrumentation shall be corrected, disconnected, restricted, patched, physically removed, or archived where security risk appears, data risk increases, sensor drift occurs, support lapses, host permission changes, community concern arises, Indigenous protocol concern arises where applicable, or instrumentation is used as surveillance, command, deployment, or execution authority.

**33.7.9 IoT, OT, and In-Situ Formula.** IoT, OT, and In-Situ Instrumentation shall follow the formula: **measure without controlling; separate read from write; secure devices; minimize sensitive data; disclose providers; tear down when needed; never let instrumentation become operational authority.**

***

### 33.8 Community-Grounded Inputs Where Safeguarded

**33.8.1 Community-Grounded Input Identity.** **Community-Grounded Inputs** shall be place-based, lived-risk, experiential, accessibility, cultural, local knowledge, public-interest, civil society, humanitarian, youth, environmental, rights-based, community, and Indigenous inputs where applicable that may help Foundry understand local reality, risk exposure, vulnerability, resilience, public-safe meaning, implementation constraints, safeguard needs, and national portfolio context. Such inputs shall be used only where safeguarded, bounded, non-extractive, and record-based.

**33.8.2 Community-Grounded Purpose.** Community-grounded inputs may reveal conditions that technical systems miss, including lived vulnerability, access barriers, language needs, trust conditions, informal infrastructure dependencies, local coping mechanisms, protected knowledge risks, unintended consequences, public-safe communication risks, and implementation harms. They shall improve evidence and safeguards, not be mined as free data or converted into consent.

**33.8.3 Community Input Record.** Each material community-grounded input pathway shall have a Community Input Record identifying participant class, purpose, collection method, use limits, attribution rules, privacy conditions, protected knowledge rules, Indigenous protocol rules where applicable, consent boundaries, data class, public-safe class, national pathway, safeguard conditions, correction pathway, archive rule, and prohibited claims.

**33.8.4 Participation Without Consent.** Community participation, civil society participation, public-interest participation, youth participation, affected stakeholder participation, or Indigenous participation where applicable shall not create community consent, Indigenous consent, social license, rights waiver, protected knowledge permission, implementation authorization, public acceptance, or representation authority unless separately and lawfully recorded.

**33.8.5 Non-Extractive Use.** Community-grounded inputs shall be gathered and used in a manner that is transparent, respectful, accessible, proportionate, safe, and bounded. Foundry shall not collect more than needed, expose sensitive contributors, publish local vulnerabilities without review, use protected knowledge beyond scope, or convert participation into promotional legitimacy.

**33.8.6 Indigenous Protocol Sensitivity.** Where Indigenous peoples, governments, institutions, territories, rights, data, knowledge, cultural heritage, sacred places, or protected knowledge are implicated, Foundry shall respect distinct legal, governance, cultural, data sovereignty, and protocol requirements. Indigenous knowledge shall not be treated as general community data.

**33.8.7 Community Public-Safe Review.** Public-safe outputs involving communities or Indigenous contexts where applicable shall be reviewed for stigma, harm, accuracy, accessibility, translation, local meaning, consent implication, protected knowledge exposure, and public authority confusion.

**33.8.8 Community Input Correction.** Community Input Records and outputs shall be corrected where participation is misrepresented, consent is implied without record, protected knowledge is exposed, translation changes meaning, accessibility fails, public-safe wording stigmatizes, or inputs are used as approval, finance, procurement, deployment, or execution authority.

**33.8.9 Community-Grounded Formula.** Community-Grounded Inputs shall follow the formula: **listen locally; protect contributors; limit use; preserve consent boundaries; respect Indigenous protocols where applicable; review public meaning; correct tokenization and overclaim.**

***

### 33.9 Local Validation and Verification Pathways

**33.9.1 Local Validation and Verification Identity.** **Local Validation and Verification Pathways** shall be structured processes through which Foundry may compare edge signals, telemetry, maps, models, dashboards, simulations, community inputs, public authority inputs, and Observatory outputs against local context, field knowledge, national records, ground observations, expert review, and safeguard checks. Validation and verification shall increase confidence within limits; they shall not create approval, certification, public authority status, consent, deployment authorization, or execution.

**33.9.2 Validation Purpose.** Local validation may help determine whether a signal is plausible, whether a sensor is drifting, whether a map is accurate enough for the stated purpose, whether a dashboard is interpretable, whether an Earth observation output matches local reality, whether a DRI or GRIx signal needs correction, whether community context changes interpretation, and whether public-safe language is appropriate.

**33.9.3 Verification Purpose.** Local verification may help confirm provenance, measurement conditions, device status, geospatial alignment, data currency, field observations, public authority records, infrastructure conditions, local assumptions, or output consistency. Verification shall be recorded with limits.

**33.9.4 Validation and Verification Record.** Each material local validation or verification pathway shall have a record identifying item reviewed, geography, method, participants, data sources, local inputs, public authority inputs if any, community inputs if any, Indigenous protocol considerations where applicable, evidence basis, findings, uncertainty, limitations, correction required, public-safe implications, national routing, archive rule, and prohibited claims.

**33.9.5 Multi-Source Validation.** Foundry should prefer multi-source validation where feasible, combining telemetry, Earth observation, GIS layers, public datasets, national records, local expert review, community-grounded inputs, and field checks. Single-source signals shall be treated cautiously, especially where high-stakes interpretations may follow.

**33.9.6 Validation Without Certification.** A locally validated output shall not be described as certified, approved, official, field-ready, deployable, financeable, insurable, procurement-ready, consented, or execution-ready unless a separate competent process creates such status. Validation supports confidence; it does not create authority.

**33.9.7 Verification of Sensitive Inputs.** Verification involving sensitive infrastructure, cyber systems, protected knowledge, Indigenous-sensitive knowledge where applicable, community-sensitive information, public authority-sensitive information, or health-sensitive data shall be handled under appropriate access and public-safe controls.

**33.9.8 Validation Correction.** Validation and verification records shall be corrected where local evidence changes, verification was incomplete, local contributors were misrepresented, public authority records were misunderstood, Indigenous protocols were missed where applicable, or validation is used as certification, approval, finance, procurement, consent, deployment, or execution claim.

**33.9.9 Local Validation Formula.** Local Validation and Verification Pathways shall follow the formula: **compare signals with local reality; use multiple sources where feasible; record uncertainty; correct mismatches; route nationally; never let validation become certification, consent, or execution.**

***

### 33.10 Edge-to-Network Synchronization

**33.10.1 Edge-to-Network Synchronization Identity.** **Edge-to-Network Synchronization** shall be the controlled process by which edge records, telemetry, local sensing outputs, Observatory Node outputs, GIS layers, Earth observation outputs, local validation records, community-grounded inputs, and degraded-mode records are transmitted, reconciled, aggregated, routed, versioned, corrected, or archived across the Nexus Network, National Dense Nexus Cores, Regional Clusters, Dense Cores, Marketplace, Registry, Studio, and Foundry records.

**33.10.2 Synchronization Purpose.** Synchronization shall ensure that local reality enters Foundry without losing provenance, context, national routing, data controls, safeguards, uncertainty, support status, public-safe limits, and correction pathways. It shall prevent isolated edge signals from becoming fragmented, stale, overclaimed, or disconnected from institutional memory.

**33.10.3 Synchronization Record.** Each material synchronization pathway shall have a Synchronization Record identifying source edge environment, destination environment, data or output classes, synchronization frequency, transformation method, aggregation method, versioning method, conflict-resolution method, access controls, national routing, public-safe restrictions, failure mode, correction pathway, archive rule, and prohibited uses.

**33.10.4 Synchronization Classes.** Synchronization may be real-time, near-real-time, batch, manual, delayed, aggregated, anonymized, pseudonymized, secure-room-only, national-only, regional-summary, public-safe-summary, Registry-linked, Marketplace-contextual, Studio-controlled, or archive-only. The class shall match risk.

**33.10.5 Conflict and Reconciliation.** Synchronization shall identify and resolve conflicts between edge telemetry, local validation, Earth observation, GIS layers, public authority records, community inputs, Indigenous protocol-sensitive inputs where applicable, and prior Registry or Observatory records. Conflicts shall be recorded rather than hidden.

**33.10.6 Synchronization Failure.** Where synchronization fails, outputs shall be marked stale, partial, delayed, unavailable, degraded, or under review. Failure shall not justify unreviewed publication, automated warning, public authority action, finance or insurance inference, procurement inference, deployment, or execution.

**33.10.7 Synchronization Security.** Synchronization shall preserve security through authentication, authorization, encryption where appropriate, integrity controls, access logs where appropriate, secrets protection, segmentation, and incident response. Synchronization channels shall be treated as potential attack surfaces.

**33.10.8 Synchronization Correction.** Synchronization records shall be corrected where data is lost, transformed incorrectly, misrouted, duplicated, stale, decontextualized, publicly exposed, or used as warning, rating, finance, insurance, procurement, consent, deployment, or execution signal.

**33.10.9 Edge-to-Network Formula.** Edge-to-Network Synchronization shall follow the formula: **move local records with provenance; aggregate only with controls; reconcile conflicts; mark stale states; secure channels; correct synchronization drift; never let synchronization become authority.**

***

### 33.11 Edge Drift, Degraded-Mode, and Continuity Controls

**33.11.1 Edge Drift Principle.** **Edge Drift** shall mean the condition in which edge devices, sensors, telemetry streams, GIS layers, local models, dashboards, community input pathways, validation methods, AI edge workflows, synchronization rules, or public-safe interpretations become inaccurate, stale, miscalibrated, unsupported, misaligned with local context, or inconsistent with current records. Edge Drift shall be monitored, recorded, corrected, restricted, or archived.

**33.11.2 Drift Sources.** Edge Drift may arise from sensor degradation, calibration failure, device movement, connectivity loss, model drift, local environmental change, land-use change, infrastructure change, community change, public authority change, data-source change, provider API change, cyber compromise, synchronization failure, translation error, public-safe language drift, or national context change.

**33.11.3 Drift Record.** A Drift Record shall identify affected edge object, drift type, detected source, evidence, affected outputs, affected users, public-safe risk, national routing implications, safeguard implications, support implications, correction action, notice needs, archive implications, and recurrence controls.

**33.11.4 Degraded-Mode Edge Operation.** Edge systems may operate in degraded mode when connectivity, power, sensor availability, compute capacity, data access, synchronization, security posture, or support capacity is reduced. Degraded mode shall reduce function before reducing safeguards. If public-safe interpretation cannot be preserved, public display shall be paused, restricted, or marked degraded.

**33.11.5 Edge Continuity Controls.** Continuity controls may include local buffering, offline records, delayed synchronization, local-only processing, national-only mode, read-only dashboards, no-publication mode, manual validation, fallback communication, secure recovery, credential rotation, and post-recovery reconciliation.

**33.11.6 Degraded-Mode Boundary.** Degraded-mode operation shall not create emergency command, public warning authority, operational control, public authority substitution, surveillance authority, procurement action, finance action, insurance action, consent determination, deployment authorization, or execution. Where emergency public communications are required, competent public authorities must act through their own lawful processes.

**33.11.7 Edge Recovery.** After degraded-mode operation, records shall be reconciled, telemetry gaps marked, outputs reviewed, stale dashboards updated or restricted, public-safe notices revised, Registry and Observatory records updated, synchronization conflicts resolved, and archive records completed.

**33.11.8 Edge Drift Correction.** Edge systems shall be corrected, recalibrated, restricted, disconnected, replaced, torn down, or archived where drift cannot be corrected, support is unavailable, public-safe risk is too high, or outputs are repeatedly misused.

**33.11.9 Edge Drift and Continuity Formula.** Edge Drift, Degraded-Mode, and Continuity Controls shall follow the formula: **monitor drift; mark degraded states; preserve safeguards under failure; reduce function before meaning; reconcile after recovery; correct or retire unsafe edge; never let degraded edge become authority.**

***

### 33.12 Edge Output Without Decision Authority

**33.12.1 No-Decision Principle.** Edge outputs shall not have decision authority by default. Edge telemetry, sensor readings, Observatory Node outputs, Earth observation products, GIS layers, IoT and OT signals, local validation records, community-grounded inputs, degraded-mode records, dashboards, anomaly detections, AI-assisted interpretations, and synchronized network outputs shall support evidence, attention, learning, routing, and correction; they shall not decide.

**33.12.2 No Public Warning Rule.** Edge outputs shall not constitute official public warnings, emergency alerts, evacuation notices, hazard advisories, threat bulletins, public safety directives, or emergency commands unless a competent public authority separately and lawfully issues such communication through its own channels.

**33.12.3 No Public Authority Classification Rule.** Edge outputs shall not classify places, communities, infrastructure, public authorities, companies, providers, systems, hazards, damage, eligibility, compliance, or risk status for official public authority purposes unless a competent public authority separately and lawfully creates such classification.

**33.12.4 No Finance, Insurance, or Procurement Rule.** Edge outputs shall not create investment signals, bankability indications, risk pricing, insurance determinations, underwriting conclusions, donor priorities, public finance allocations, procurement priorities, supplier qualifications, technical compliance findings, or vendor rankings. They may inform questions, not decisions.

**33.12.5 No Consent Rule.** Edge outputs and community-grounded inputs shall not create community consent, Indigenous consent where applicable, social license, rights waiver, protected knowledge permission, data consent, public acceptance, or implementation authorization. Consent and permissions require separate lawful processes.

**33.12.6 No Deployment or Execution Rule.** Edge outputs shall not authorize deployment, field intervention, infrastructure operation, OT control, emergency response, public authority action, Project SPV action, National Consortium Company action, operational command, or execution. Technical ability to act from edge signals shall not create authority to act.

**33.12.7 Mandatory Boundary Language.** Edge outputs intended for users shall include boundary language proportionate to risk, stating the output’s source, time, uncertainty, limitations, public-safe status, support status, correction pathway, and prohibited interpretations. High-risk edge outputs shall be controlled, delayed, aggregated, restricted, or withheld where boundary language is insufficient.

**33.12.8 Edge Output Review.** Edge outputs shall be reviewed before use in public-safe reports, Marketplace context, Registry context, Studio runtime, public authority learning, readiness mapping, finance-reader rooms, insurance-reader rooms, donor-reader rooms, public finance rooms, National Portfolio records, or handoff packages where risk requires.

**33.12.9 Edge Output Overclaim Incident.** An Edge Output Overclaim Incident shall arise where edge outputs are used as warning, rating, public authority classification, finance signal, insurance determination, procurement evaluation, consent, deployment authorization, operational command, or execution authority. Such incident shall trigger correction, restriction, public-safe clarification, recipient notice, dashboard redesign, synchronization correction, or archive annotation.

**33.12.10 Final Foundry Edge Formula.** The controlling Foundry Edge Architecture Formula is that **Edge connects Foundry to local reality through Observatory Nodes, sensing environments, telemetry, Earth observation, GIS layers, IoT, OT, in-situ instrumentation, safeguarded community inputs, local validation, synchronization, drift controls, degraded-mode continuity, and public-safe output rules; but Edge is evidence and observability infrastructure, not public warning, public authority classification, surveillance authority, finance signal, insurance determination, procurement evaluation, consent, deployment authorization, operational command, or execution authority; every edge signal must remain classified, recorded, validated where needed, nationally routed where relevant, safeguarded, synchronized, corrected, and archived so that local reality strengthens Foundry without becoming false authority by implication.**

## 34. Foundry AI and Agentic Systems Architecture

### 34.1 AI Use Scope

**34.1.1 AI Architecture Identity.** **Foundry AI and Agentic Systems Architecture** shall be the governed architecture through which Nexus Foundry may use AI models, machine-learning systems, retrieval systems, classifiers, summarizers, copilots, workflow assistants, agents, model-evaluation tools, simulation assistants, public-safe drafting assistants, Observatory assistants, readiness-mapping assistants, Studio agents, and other AI-enabled components for bounded public-good production. AI shall support evidence, learning, review, simulation, accessibility, translation, drafting, testing, pattern recognition, workflow assistance, and correction; it shall not become autonomous authority, public authority substitute, finance actor, procurement actor, consent mechanism, deployment authority, operational controller, or execution vehicle.

**34.1.2 AI Use Scope.** Foundry may use AI for controlled purposes including:\
34.1.2(a) evidence triage, summarization, classification, extraction, comparison, and gap detection;\
34.1.2(b) public-good software development assistance, code review support, documentation support, test generation, and dependency analysis;\
34.1.2(c) Observatory, DRI, GRIx, geospatial, dashboard, and telemetry interpretation support;\
34.1.2(d) simulation support, scenario preparation, model comparison, and uncertainty articulation;\
34.1.2(e) public-safe drafting, translation, accessibility adaptation, plain-language support, and claims-boundary checking;\
34.1.2(f) readiness-question mapping, dependency extraction, handoff package drafting, and no-reliance language checking;\
34.1.2(g) Marketplace metadata preparation, Registry record support, Studio workflow preparation, and support-status summarization;\
34.1.2(h) correction detection, overclaim detection, version comparison, archive classification, and public notice preparation;\
34.1.2(i) Academy training support, contributor guidance, role-readiness learning, and supervised practice.

**34.1.3 Prohibited or Restricted AI Uses.** AI shall not be used by default for autonomous public warnings, emergency commands, official public authority classifications, regulatory decisions, procurement recommendations, investment recommendations, insurance determinations, donor allocations, public finance allocations, consent determinations, protected knowledge decisions, operational control, infrastructure actuation, field interventions, surveillance, or execution. Any high-risk AI use outside ordinary support shall require separate authorization, safeguards review, human review, public-safe review, and lawful authority where applicable.

**34.1.4 AI as Assistance, Not Status.** AI outputs shall be treated as draft, candidate, signal, assistance, analysis, comparison, or workflow support unless reviewed and adopted by the competent Foundry process. AI-generated outputs shall not create release status, Registry status, Marketplace eligibility, Studio authorization, TRL status, public-safe publication approval, readiness status, handoff status, national routing status, public authority status, consent, deployment authorization, or execution authority.

**34.1.5 AI Risk Classes.** Foundry AI use shall be classified by risk, including low-risk internal drafting assistance, moderate-risk evidence or workflow assistance, high-risk public-facing or public authority-facing assistance, restricted data assistance, AI agent assistance, cyber-sensitive assistance, dual-use assistance, protected knowledge assistance, Indigenous-sensitive assistance where applicable, finance-facing readiness assistance, procurement-sensitive assistance, and handoff-adjacent assistance.

**34.1.6 AI and Public-Good Boundary.** AI used in Foundry shall preserve the public-good firewall. AI shall not be used to privatize public-good records, enclose open technical baselines, create hidden provider dependency, extract protected knowledge, convert sponsor or provider materials into preferred status, generate sales claims, or produce enterprise-stack execution by implication.

**34.1.7 AI Scope Record.** Material AI use shall be recorded where it affects evidence, public-safe materials, Marketplace listings, Registry records, Studio workflows, TRL inputs, readiness mappings, National Portfolio records, safeguard reviews, public authority learning, handoff packages, or public communications. The record shall identify task, model or system, data class, workflow class, human-review requirement, output class, limitations, correction pathway, and prohibited uses.

**34.1.8 AI Use Formula.** Foundry AI use shall follow the formula: **use AI to assist bounded work; classify risk before use; protect data and knowledge; require human review where meaning matters; record material outputs; correct hallucination and overclaim; never let AI assistance become authority, consent, deployment, or execution.**

***

### 34.2 AI Workflow Authorization

**34.2.1 Authorization Principle.** AI workflows shall be authorized before material use. Authorization shall determine whether the AI workflow may operate, for what purpose, with what model or system, on what data, under what access limits, with what tools, with what human review, with what output restrictions, with what logging where appropriate, and with what correction pathway.

**34.2.2 Workflow Classes.** AI workflow classes may include drafting workflow, summarization workflow, evidence extraction workflow, classification workflow, translation workflow, accessibility workflow, code-assistance workflow, testing workflow, simulation-support workflow, dashboard-interpretation workflow, Observatory workflow, GRIx workflow, DRI workflow, readiness workflow, Marketplace workflow, Registry workflow, Studio workflow, TRL-support workflow, safeguard-support workflow, public-safe review-support workflow, handoff-support workflow, and correction workflow.

**34.2.3 AI Workflow Authorization Record.** Each material AI workflow shall have an AI Workflow Authorization Record identifying workflow name, purpose, model or system, provider where applicable, permitted tasks, prohibited tasks, data classes, access roles, tool permissions, agent permissions, human-review points, output-review requirements, storage or retention rules, prompt or workflow logging rules where appropriate, public-safe restrictions, shutdown triggers, correction pathway, archive rule, and prohibited claims.

**34.2.4 Authorization Criteria.** Authorization shall consider public-good purpose, necessity, data sensitivity, model limitations, provider terms, privacy, cyber risk, protected knowledge risk, Indigenous protocol sensitivity where applicable, public authority sensitivity, finance or procurement sensitivity, hallucination risk, automation risk, tool-use risk, bias or fairness risk, output reliance risk, support burden, and correctionability.

**34.2.5 Unauthorized AI Workflow Rule.** AI workflows shall not be used materially where authorization is absent, expired, suspended, withdrawn, or exceeded. Informal experimentation may be permitted only in low-risk, non-sensitive, non-public, non-status-bearing contexts and shall not enter Foundry records, public materials, or handoff packages without review.

**34.2.6 Workflow Changes.** Material changes to model, system prompt, tools, permissions, data class, user class, output class, public-facing use, public authority-facing use, finance-facing use, procurement-sensitive use, Studio runtime, or handoff use shall require reauthorization or amendment.

**34.2.7 Workflow Shutdown.** AI workflows shall include shutdown or pause triggers, including hallucination pattern, data leakage, prompt injection, unauthorized tool use, public-safe failure, overclaim generation, bias concern, protected knowledge exposure, cyber issue, provider terms change, support lapse, or role-boundary failure.

**34.2.8 Authorization Without Approval Overclaim.** Authorization of an AI workflow shall not certify the workflow, validate the model, approve deployment, establish legal compliance, create procurement status, create financeability, approve public authority use, grant consent, or authorize execution. It means only that the workflow may operate under recorded Foundry conditions.

**34.2.9 AI Workflow Authorization Formula.** AI workflow authorization shall follow the formula: **authorize purpose before use; bind data and tools to role; require review; reauthorize material changes; pause unsafe workflows; never treat workflow authorization as certification or deployment approval.**

***

### 34.3 Model Registry

**34.3.1 Model Registry Identity.** The **Model Registry** shall be the controlled record surface through which Foundry records AI models, model versions, model providers, model dependencies, model-use permissions, approved workflows, data restrictions, evaluation records, system cards, model cards, limitations, correction history, suspension status, retirement status, and archive status. The Model Registry shall make AI system use traceable; it shall not validate models universally.

**34.3.2 Model Registry Function.** The Model Registry shall help Foundry determine which models may be used for which tasks, with what data classes, under what tool permissions, with what review requirements, with what output limits, and under what correction or shutdown rules. It shall preserve AI provenance across evidence, public-safe materials, Studio runtime, Marketplace, Registry, Observatory, readiness, and handoff outputs.

**34.3.3 Model Registry Record.** A Model Registry Record shall include model identifier, model name, provider or host, version, deployment mode, access method, approved workflow classes, prohibited workflow classes, permitted data classes, prohibited data classes, model-use terms, training or retention implications, evaluation status, model card reference, system card reference where applicable, known limitations, bias or fairness notes, security notes, support status, correction history, suspension or retirement status, and prohibited claims.

**34.3.4 Model Classes.** The Model Registry may record foundation models, domain models, retrieval models, embedding models, classification models, summarization models, translation models, code models, simulation-support models, geospatial models, vision models, multimodal models, agent controllers, evaluator models, guardrail models, red-team models, and locally hosted or sovereign models.

**34.3.5 Model Use Restrictions.** A registered model may be approved for some uses and prohibited for others. A model acceptable for general drafting may be prohibited for restricted data, public authority-facing outputs, finance-facing outputs, procurement-sensitive outputs, protected knowledge, Indigenous-sensitive knowledge where applicable, cyber-sensitive outputs, or autonomous agentic workflows.

**34.3.6 Provider and Hosting Disclosure.** Model Registry shall disclose provider, hosting mode, jurisdictional considerations, data-use terms, retention implications, fine-tuning or training restrictions, model-update behavior, dependency risks, and exit risks where material. Use of a provider model shall not validate the provider.

**34.3.7 Model Suspension and Retirement.** A model may be suspended, restricted, deprecated, retired, or archived where behavior changes, provider terms change, safety concerns arise, data-use concerns arise, hallucination risk becomes unacceptable, security risks appear, bias or fairness concerns arise, support lapses, or workflows overclaim.

**34.3.8 Model Registry Without Certification.** Model Registry presence shall not certify the model, approve AI safety, establish legal compliance, create procurement eligibility, create financeability, authorize public authority use, authorize deployment, or validate the provider.

**34.3.9 Model Registry Formula.** The Model Registry shall follow the formula: **record the model; bind it to approved workflows; disclose limitations and provider terms; restrict sensitive uses; suspend when risk changes; never let registry presence become model certification.**

***

### 34.4 Model Cards

**34.4.1 Model Card Identity.** A **Model Card** shall be a structured record describing an AI model’s intended use, known limitations, evaluation basis, data constraints, risk profile, appropriate workflows, prohibited workflows, public-safe limits, and correction history within Foundry. Model Cards shall translate model information into operational boundaries for users and stewards.

**34.4.2 Model Card Elements.** A Foundry Model Card shall include model name, version, provider or host, model type, intended Foundry uses, prohibited uses, data-use restrictions, training or retention implications, evaluation results where available, benchmark limits, known failure modes, hallucination risks, bias or fairness concerns, security concerns, public-safe limitations, human-review requirements, workflow relationships, correction history, support status, and archive status.

**34.4.3 Foundry-Specific Use Context.** Model Cards shall state how the model may be used in Foundry contexts, including whether it may support evidence review, summarization, translation, public-safe drafting, code assistance, AI agent workflows, Studio runtime, Observatory analysis, GRIx or DRI outputs, readiness mapping, Marketplace metadata, Registry preparation, or handoff packages.

**34.4.4 Prohibited Use Clarity.** Model Cards shall expressly identify prohibited uses where relevant, including public warnings, public authority classifications, legal determinations, investment advice, insurance determinations, procurement recommendations, donor decisions, public finance allocations, consent determinations, protected knowledge extraction, cyber-offensive assistance, infrastructure control, autonomous deployment, or execution.

**34.4.5 Evaluation Limits.** Model Cards shall not overstate evaluation. Benchmark performance, internal tests, Frontier Labs tests, Studio tests, or user experience shall be described within recorded conditions. Evaluation results shall not be represented as certification, legal compliance, procurement readiness, public authority approval, or safe deployment.

**34.4.6 Model Card Review.** Model Cards shall be reviewed for accuracy, public-safe language, data-use clarity, workflow alignment, limitation clarity, provider-dependency disclosure, AI safety concerns, cyber concerns, protected knowledge concerns, Indigenous protocol sensitivity where applicable, and no-conversion language.

**34.4.7 Model Card Correction.** Model Cards shall be corrected where model behavior changes, provider terms change, evaluation changes, limitations are discovered, public-safe concerns arise, hallucination patterns emerge, or the model is misused as authority.

**34.4.8 Model Card Formula.** Model Cards shall follow the formula: **state what the model is; state where it may help; state where it must not be used; disclose limits; update when behavior changes; never let a model card become AI certification.**

***

### 34.5 System Cards

**34.5.1 System Card Identity.** A **System Card** shall be a structured record describing an AI-enabled system or workflow as deployed or prepared within Foundry, including its models, tools, prompts or workflow classes, permissions, data flows, human-review points, outputs, limitations, safeguards, support status, correction pathway, shutdown conditions, and archive state. System Cards shall govern AI systems in context, not merely models in isolation.

**34.5.2 System Card Elements.** A System Card shall include system name, version, purpose, owner or steward, workflow class, model dependencies, tool dependencies, data inputs, data classes, access roles, tool permissions, agent permissions, human-review points, output-review requirements, public-safe limits, safeguard controls, security controls, logging rules where appropriate, support status, shutdown triggers, correction history, and prohibited interpretations.

**34.5.3 System Context.** System Cards shall describe the actual Foundry context in which the AI system operates, including whether it supports Studio runtime, Observatory workflows, public-safe drafting, readiness mapping, Marketplace preparation, Registry support, National Portfolio support, Academy training, support workflows, correction workflows, or handoff package preparation.

**34.5.4 System Risk Classification.** System Cards shall classify risks arising from the system’s combined components, including model behavior, tool access, data sensitivity, agent autonomy, user class, output audience, public-safe exposure, public authority sensitivity, finance or procurement sensitivity, cyber risk, dual-use risk, protected knowledge risk, and execution implication.

**34.5.5 Human Review and Escalation.** System Cards shall identify where human review is required, what role must review, what outputs require escalation, what conditions trigger pause, and which outputs may never be automatically published, routed, or acted upon.

**34.5.6 System Card Without Deployment Approval.** A System Card shall not authorize deployment, public authority use, procurement use, finance use, insurance use, public release, Studio activation, data access, or execution by itself. It records and bounds the system; other competent records govern use.

**34.5.7 System Card Correction.** System Cards shall be corrected where workflow changes, tools change, permissions change, model behavior changes, user classes change, output class changes, public-safe exposure changes, risks are discovered, or the system is misused.

**34.5.8 System Card Formula.** System Cards shall follow the formula: **describe the system in context; bind models to tools and data; identify human review; define shutdown; correct system drift; never treat system documentation as deployment authority.**

***

### 34.6 Agent Configuration

**34.6.1 Agent Configuration Identity.** **Agent Configuration** shall be the recorded definition of an AI agent’s purpose, role, model dependencies, memory or context permissions, data access, tools, actions, autonomy level, human authorization points, output limits, escalation rules, shutdown triggers, support status, and correction pathway. Agent configuration shall determine what the agent may assist with; it shall not create authority to decide or act.

**34.6.2 Agent Types.** Foundry agents may include research agents, evidence agents, summarization agents, public-safe drafting agents, code agents, testing agents, Observatory agents, GRIx agents, DRI agents, readiness agents, Marketplace agents, Registry agents, Studio agents, support agents, correction agents, archive agents, training agents, and workflow routing agents. Each shall be configured for bounded tasks.

**34.6.3 Agent Configuration Record.** An Agent Configuration Record shall include agent identifier, name, purpose, workflow class, model dependencies, tool permissions, data permissions, memory or context rules, autonomy level, allowed actions, prohibited actions, human approval points, output-review requirements, public-safe limits, logging rules where appropriate, shutdown triggers, support status, correction pathway, archive rule, and prohibited claims.

**34.6.4 Autonomy Levels.** Agent autonomy levels shall be defined and recorded. Levels may include suggestion-only, draft-only, retrieval-only, classification-only, review-support, tool-assisted with human approval, limited automation with review, controlled Studio runtime, secure-room-only, and prohibited autonomous action. High-autonomy operation shall be exceptional and heavily controlled.

**34.6.5 Agent Memory and Context.** Agent memory, persistent context, retrieval access, uploaded materials, user history, National Portfolio context, Registry context, Marketplace context, Studio context, and secure-room context shall be governed by access, data classification, privacy, confidentiality, protected knowledge, Indigenous protocol sensitivity where applicable, and retention rules. Agents shall not accumulate sensitive memory without authorization.

**34.6.6 Agent Action Boundary.** Agents shall not send official communications, publish public materials, issue warnings, approve releases, change Registry status, list Marketplace items, activate Studio runtime, assign TRL status, grant access, make finance or procurement recommendations, determine consent, operate infrastructure, or hand off packages without recorded human authorization and competent process.

**34.6.7 Agent Configuration Changes.** Material changes to agent purpose, model, tools, data access, memory, autonomy, output class, user class, public-facing role, or sensitive-data role shall require configuration review and record update.

**34.6.8 Agent Configuration Formula.** Agent Configuration shall follow the formula: **define the agent narrowly; restrict tools and data; require human approval for material actions; record memory rules; shut down on drift; never allow an agent to become hidden authority.**

***

### 34.7 Tool Permissions and Sandboxing

**34.7.1 Tool Permission Principle.** AI systems and agents shall receive only the tool permissions necessary for their authorized workflow. Tool permissions shall be least-privilege, time-bounded where appropriate, revocable, auditable where appropriate, and separated by role, environment, data class, risk class, and output class.

**34.7.2 Tool Categories.** Tools may include search tools, repository tools, code execution tools, data analysis tools, document tools, spreadsheet tools, dashboard tools, geospatial tools, simulation tools, model-evaluation tools, communication tools, ticketing tools, Registry tools, Marketplace tools, Studio tools, secure-room tools, cloud tools, compute orchestration tools, and archive tools. Each category shall have permission limits.

**34.7.3 Tool Permission Record.** A Tool Permission Record shall identify system or agent, tool, permission level, allowed actions, prohibited actions, data classes, environment, duration, human approval requirements, logging rules where appropriate, revocation triggers, emergency stop, correction pathway, and archive rule.

**34.7.4 Sandboxing Requirement.** AI systems with code execution, workflow automation, data transformation, connector access, cloud access, agentic tool use, cyber-sensitive tools, or external communication capability shall operate in sandboxed or controlled environments proportionate to risk. Sandboxing shall limit blast radius, data exposure, credential access, network access, file access, and tool scope.

**34.7.5 Prohibited Default Tool Actions.** AI tools shall not by default delete records, grant access, change Registry status, approve Marketplace listings, activate Studio runtime, send external communications, issue public notices, execute contracts, transfer data, run uncontrolled infrastructure commands, modify production systems, or trigger deployment.

**34.7.6 Credential and Secret Controls.** Agents shall not receive unrestricted credentials, secrets, keys, tokens, service accounts, private certificates, provider credentials, public authority credentials, or secure-room access. Secrets shall be managed through appropriate systems and shall not be exposed in prompts, logs, outputs, or public records.

**34.7.7 Tool Misuse Detection.** Tool use shall be reviewed where risk warrants. Misuse includes unauthorized access, unintended data transfer, unsafe code execution, prompt injection success, tool loop behavior, hidden external communication, overbroad file access, Registry or Marketplace manipulation, Studio runtime overreach, or infrastructure action beyond authorization.

**34.7.8 Tool Permission Correction.** Tool permissions shall be revoked, reduced, corrected, rotated, sandboxed further, or suspended where misuse occurs, risk changes, support lapses, data class changes, workflow changes, or agent behavior becomes unsafe.

**34.7.9 Tool Permission Formula.** Tool permissions and sandboxing shall follow the formula: **grant the smallest tool; isolate risky execution; protect secrets; require human approval for material actions; revoke on misuse; never let tool access become decision or execution authority.**

***

### 34.8 Prompt and Workflow Logs Where Appropriate

**34.8.1 Logging Principle.** Prompt and workflow logs shall be used where appropriate to preserve provenance, support review, enable correction, investigate incidents, understand AI behavior, maintain public-safe integrity, and support verifiable intelligence. Logging shall be proportionate, lawful, privacy-aware, confidentiality-aware, security-aware, and sensitive to protected knowledge, Indigenous protocols where applicable, and national data controls.

**34.8.2 Log Classes.** Logs may include prompt logs, system prompt versions, workflow logs, retrieval logs, tool-use logs, model output logs, human review logs, output revision logs, approval logs, rejection logs, escalation logs, correction logs, shutdown logs, and archive logs. Not all logs shall be public or broadly accessible.

**34.8.3 Logging Record.** A Logging Record or logging section in an AI Workflow Authorization Record shall identify what is logged, why it is logged, who may access logs, retention period, redaction rules, sensitivity class, privacy protections, protected knowledge controls, secure-room controls where applicable, correction pathway, and deletion or archive rule.

**34.8.4 Sensitive Logging Controls.** Logs may contain personal information, confidential information, protected knowledge, Indigenous-sensitive knowledge where applicable, public authority-sensitive information, cyber-sensitive information, infrastructure-sensitive information, trade secrets, legal-sensitive information, or model-vulnerability information. Such logs shall be restricted, redacted, sealed, aggregated, or not retained where appropriate.

**34.8.5 Logging for Public-Safe Outputs.** AI workflows contributing to public-safe materials, public authority learning materials, Marketplace listings, Registry records, Studio outputs, readiness mappings, TRL records, or handoff packages should preserve sufficient workflow trace to support correction and accountability, subject to sensitivity controls.

**34.8.6 Logging Without Surveillance.** Logging shall not become unrestricted surveillance of contributors, communities, Indigenous participants where applicable, public authority participants, or users. Logs shall be purpose-bound and proportionate. Monitoring rules shall be transparent where appropriate.

**34.8.7 Log Correction and Sealing.** Logs shall be corrected, annotated, restricted, sealed, redacted, deleted where lawfully required, or archived where they contain errors, sensitive exposure, over-retention, unauthorized content, or public-safe risk. Log correction shall preserve accountability where lawful.

**34.8.8 Prompt and Workflow Logging Formula.** Prompt and workflow logs shall follow the formula: **log enough to verify and correct; protect sensitive content; restrict access; avoid surveillance; retain only as justified; never let logs become public authority, finance, procurement, consent, or execution records by implication.**

***

### 34.9 Human Review and Output Review

**34.9.1 Human Review Principle.** Human review shall be required where AI outputs affect meaning, status, public communication, public authority learning, readiness mapping, safeguards, Marketplace visibility, Registry status, Studio runtime, TRL inputs, National Portfolio records, handoff packages, or any context where reliance or harm may arise. AI shall assist human judgment; it shall not replace competent review.

**34.9.2 Output Review Principle.** Output review shall evaluate whether AI-generated or AI-assisted outputs are accurate, source-grounded, complete enough, properly bounded, public-safe, role-consistent, data-compliant, safeguard-compliant, accessible, non-overclaiming, and suitable for the intended audience and pathway.

**34.9.3 Review Classes.** AI output review may include evidence review, source review, technical review, code review, data review, public-safe review, translation review, accessibility review, safeguard review, Indigenous protocol review where applicable, privacy review, cyber review, public authority boundary review, readiness boundary review, Marketplace review, Registry review, Studio review, TRL review, handoff review, and archive review.

**34.9.4 Human Review Record.** A Human Review Record shall identify output, AI system or workflow, reviewer, review class, criteria, source materials, findings, required changes, accepted portions, rejected portions, uncertainty, limitations, public-safe status, correction pathway, and prohibited interpretations.

**34.9.5 High-Risk Output Controls.** High-risk AI outputs shall not be published, routed, displayed, handed off, used in public authority learning, used in readiness rooms, used in capital-reader rooms, used in insurance-reader rooms, used in public finance rooms, used in community-facing materials, used in Indigenous-facing materials where applicable, or used in Studio runtime without review appropriate to risk.

**34.9.6 AI Draft Labeling.** Where useful, AI-assisted outputs shall be marked internally as draft, candidate, machine-assisted, unreviewed, reviewed, rejected, corrected, or adopted. External labeling shall be used where required or public-safe appropriate, without creating unnecessary confusion or false authority.

**34.9.7 Reviewer Independence and Conflict.** Reviewers shall disclose conflicts where AI output affects providers, sponsors, public authorities, finance readers, procurement-sensitive matters, national routing, community or Indigenous matters where applicable, or enterprise handoff. Provider-generated AI outputs shall not be self-validated by the provider where independent review is required.

**34.9.8 Review Correction.** Human Review Records shall be corrected where review missed hallucination, source error, public-safe overclaim, data leak, bias, safeguard issue, tool misuse, public authority overclaim, readiness overclaim, or execution implication.

**34.9.9 Human Review Formula.** Human and output review shall follow the formula: **AI may draft; humans review; records adopt; high-risk outputs require stronger review; conflicts are disclosed; errors are corrected; no AI output becomes status by itself.**

***

### 34.10 AI Boundary Incidents and Correction

**34.10.1 AI Boundary Incident Defined.** An **AI Boundary Incident** shall arise where an AI system, agent, workflow, model output, prompt, tool use, automated classification, dashboard interpretation, Studio runtime, Marketplace metadata, Registry support output, readiness output, public-safe draft, or handoff material crosses or appears to cross a Foundry boundary, including authority, data, public-safe, safeguard, public authority, finance, procurement, consent, deployment, or execution boundaries.

**34.10.2 Incident Categories.** AI Boundary Incidents may include hallucination incident, source fabrication incident, data leakage incident, prompt injection incident, tool misuse incident, unauthorized access incident, unauthorized automation incident, public-safe overclaim incident, public authority substitution incident, finance advice incident, procurement recommendation incident, insurance determination incident, donor or public finance implication incident, consent implication incident, protected knowledge exposure incident, Indigenous protocol incident where applicable, cyber-sensitive disclosure incident, Studio runtime incident, Registry status incident, Marketplace listing incident, TRL overclaim incident, handoff overclaim incident, and execution implication incident.

**34.10.3 AI Incident Record.** An AI Boundary Incident Record shall identify system, workflow, model, user or role where appropriate, output, tool action, affected data, affected records, incident category, severity, source, affected audiences, public-safe risk, data risk, safeguard risk, public authority risk, finance/procurement risk, consent risk, execution risk, immediate containment, correction action, notice requirement, recurrence controls, and archive reference.

**34.10.4 Immediate Containment.** Depending on severity, containment may include stopping the workflow, disabling the agent, revoking tool permissions, freezing outputs, restricting access, withdrawing public materials, pausing Studio runtime, correcting Marketplace or Registry entries, notifying affected users, sealing logs, rotating credentials, or escalating to safeguard, public-safe, technical, legal-boundary, public authority, or national routing review.

**34.10.5 Correction Actions.** AI correction may include output correction, source correction, prompt correction, workflow correction, model restriction, model suspension, tool-permission reduction, sandbox strengthening, human-review strengthening, public-safe clarification, data deletion or sealing, Registry correction, Marketplace correction, Studio correction, TRL correction, handoff recall, public notice, targeted notice, training update, and archive annotation.

**34.10.6 Non-Retaliation.** Persons reporting AI boundary incidents in good faith shall be protected. Correction shall not be used to punish contributors for identifying hallucination, overclaim, data risk, public-safe risk, sponsor/provider influence, public authority confusion, or unsafe automation.

**34.10.7 Recurrence Controls.** Material AI incidents shall update Model Cards, System Cards, Agent Configuration Records, Workflow Authorization Records, Tool Permission Records, prompt templates, output-review criteria, public-safe templates, Marketplace rules, Registry rules, Studio rules, TRL rules, handoff templates, Academy training, and support procedures.

**34.10.8 AI Incident Archive.** AI Boundary Incident Records shall be archived with appropriate access controls. Sensitive incidents involving data leaks, cyber risks, protected knowledge, Indigenous-sensitive matters where applicable, public authority-sensitive information, or security vulnerabilities shall be restricted.

**34.10.9 AI Boundary Incident Formula.** AI incidents shall follow the formula: **contain first; compare output to record; correct system and meaning; notify where reliance risk exists; reduce permissions where needed; update training and controls; archive the lesson.**

***

### 34.11 Automated Claim Prevention

**34.11.1 Automated Claim Prevention Principle.** AI systems shall be designed and reviewed to prevent automatic generation, amplification, publication, or routing of claims that exceed Foundry records. Automated Claim Prevention shall prevent AI from creating false authority, inflated maturity, public warning language, finance language, procurement language, consent language, provider validation, sponsor endorsement, public authority approval, deployment authorization, or execution implication.

**34.11.2 Claim Classes to Prevent.** AI workflows shall prevent or flag claims including approved, certified, recognized, validated, compliant, financeable, bankable, investable, insurable, underwritten, donor-approved, public-finance-approved, procurement-ready, preferred provider, government-approved, regulator-approved, officially classified, warning issued, consented, community-approved, Indigenous-approved where applicable, deployment-ready, operationally ready, execution-ready, Nexus-approved, GCRI-validated, GRF-recognized, GRA-ready, Marketplace-approved, Registry-approved, Studio-authorized, and TRL-certified unless an exact record supports the exact phrase.

**34.11.3 Automated Claim Controls.** Controls may include claims dictionaries, prohibited-term lists, controlled vocabulary, no-conversion templates, output classifiers, public-safe review prompts, record-checking workflows, source-grounding requirements, human review gates, high-risk phrase alerts, public authority phrase alerts, finance phrase alerts, procurement phrase alerts, consent phrase alerts, deployment phrase alerts, and automated refusal or escalation for unsupported claims.

**34.11.4 Record-Checking Requirement.** AI systems generating status-bearing text shall check source records where feasible. If no record supports a claim, the AI output shall avoid the claim, use bounded language, or escalate for human review. Absence of evidence shall not be filled by plausible wording.

**34.11.5 Public-Safe Language Templates.** AI workflows shall use public-safe language templates for Marketplace descriptions, Registry entries, Studio descriptions, public reports, readiness notes, public authority learning materials, National Portfolio summaries, and handoff packages. Templates shall preserve no-conversion language and correction pathways.

**34.11.6 Sponsor and Provider Claims.** AI shall not generate sponsor or provider claims implying endorsement, validation, preferential status, technical superiority, procurement advantage, public authority approval, financeability, or deployment readiness unless supported by a competent record and reviewed.

**34.11.7 Automated Claim Correction.** Unsupported AI-generated claims shall be corrected, withdrawn, annotated, or publicly clarified where needed. Repeated claim-generation failure shall trigger prompt revision, model restriction, output filter strengthening, human-review escalation, or workflow suspension.

**34.11.8 Automated Claim Prevention Formula.** Automated Claim Prevention shall follow the formula: **forbid unsupported status words; require record-grounding; flag high-risk claims; preserve no-conversion templates; escalate uncertainty; correct false claims; never let fluent AI language create authority.**

***

### 34.12 AI Without Autonomous Public Authority, Finance, Procurement, Consent, or Execution Effect

**34.12.1 No Autonomous Authority Principle.** AI and agentic systems shall not have autonomous public authority, finance, procurement, consent, deployment, or execution effect within Nexus Foundry. AI may assist; AI shall not decide. AI may draft; AI shall not approve. AI may route for review; AI shall not authorize. AI may detect signals; AI shall not warn the public by itself. AI may map dependencies; AI shall not finance, insure, procure, consent, deploy, or execute.

**34.12.2 No Public Authority Effect.** AI outputs shall not create official public authority decisions, public warnings, emergency alerts, regulatory classifications, permitting status, policy adoption, public finance decisions, procurement decisions, compliance findings, or emergency commands. Public authorities may independently use or consider information through their own lawful processes, but AI outputs shall remain non-decision Foundry materials unless separately adopted by competent authority.

**34.12.3 No Finance or Insurance Effect.** AI outputs shall not create investment advice, bankability, financeability, valuation, creditworthiness, donor approval, grant allocation, public finance allocation, guarantee eligibility, insurance readiness, underwriting, premium assessment, risk pricing, or insurability. AI may help frame readiness questions under no-reliance conditions only.

**34.12.4 No Procurement Effect.** AI outputs shall not create procurement recommendation, supplier ranking, technical compliance finding, vendor qualification, preferred-provider status, shortlist status, award status, sole-source justification, or purchasing instruction. Procurement actors must conduct separate lawful processes.

**34.12.5 No Consent Effect.** AI outputs shall not create community consent, Indigenous consent where applicable, social license, protected knowledge permission, rights waiver, data consent, public acceptance, or implementation authorization. AI shall not infer consent from participation, silence, social media, public data, attendance, or community inputs.

**34.12.6 No Deployment or Execution Effect.** AI outputs, agents, workflows, Studio packages, dashboards, simulations, edge telemetry interpretations, or readiness maps shall not authorize deployment, operational use, infrastructure control, field intervention, emergency response, Project SPV action, National Consortium Company action, contract execution, data transfer, or any real-world execution by default.

**34.12.7 Human Accountability.** Where AI contributes to material Foundry outputs, accountable human roles shall remain identifiable through records. Human accountability shall not mean blind approval of AI output; it shall mean review, adoption, rejection, correction, and escalation by competent roles.

**34.12.8 No Hidden Automation.** AI shall not be hidden inside workflows in a way that causes users to believe a human, council, public authority, reviewer, investor, insurer, donor, National Node, Marketplace steward, Registry steward, Studio steward, or Foundry steward made a decision when the output was automated or unreviewed.

**34.12.9 Mandatory AI Boundary Language.** High-risk AI-enabled outputs shall include boundary language proportionate to risk, stating that the output is AI-assisted where appropriate, reviewed or unreviewed as applicable, limited to recorded sources and methods, correctionable, and not public authority action, finance advice, procurement recommendation, consent, deployment authorization, or execution.

**34.12.10 Final AI and Agentic Systems Formula.** The controlling Foundry AI and Agentic Systems Formula is that **AI may assist Foundry in evidence, drafting, coding, simulation, observability, readiness mapping, Marketplace preparation, Registry support, Studio workflows, public-safe communication, correction, and archive; but AI workflows must be authorized, models registered, Model Cards and System Cards maintained, agents configured narrowly, tools sandboxed, prompts and workflow logs preserved where appropriate, outputs human-reviewed where risk requires, boundary incidents corrected, unsupported claims prevented, and no AI system may autonomously create public authority effect, finance effect, procurement effect, consent effect, deployment effect, or execution effect by implication.**

## 35. Foundry Cybersecurity and Secure Infrastructure

### 35.1 Zero Trust Baseline

**35.1.1 Zero Trust Baseline Identity.** The **Zero Trust Baseline** shall be the default cybersecurity and secure-infrastructure posture for Nexus Foundry. It shall assume that no user, device, workload, model, agent, connector, repository, dashboard, dataset, provider system, sponsor system, public authority interface, National Node environment, Studio runtime, Marketplace surface, Registry surface, Edge environment, Observatory Node, or compute environment is trusted merely because it is internal, familiar, affiliated, previously approved, physically present, institutionally prestigious, sponsor-supported, provider-supplied, or nationally hosted.

**35.1.2 Zero Trust Purpose.** Zero Trust shall protect Foundry’s public-good production system from unauthorized access, privilege drift, data leakage, cyber compromise, AI tool misuse, provider capture, sponsor influence, lateral movement, insecure integrations, public authority-sensitive exposure, protected knowledge exposure, Indigenous-sensitive knowledge exposure where applicable, infrastructure-sensitive disclosure, and execution by technical permission. Zero Trust shall make trust conditional, recorded, bounded, reviewable, revocable, and correctionable.

**35.1.3 Core Zero Trust Rules.** Foundry shall apply the following baseline rules:\
35.1.3(a) verify identity before access;\
35.1.3(b) authorize by role, need, data class, environment, and purpose;\
35.1.3(c) grant least privilege;\
35.1.3(d) segment systems and workloads;\
35.1.3(e) protect secrets and credentials;\
35.1.3(f) monitor proportionately where lawful and appropriate;\
35.1.3(g) review access periodically;\
35.1.3(h) revoke access when purpose ends;\
35.1.3(i) treat AI agents and automation as untrusted until bounded;\
35.1.3(j) preserve correction and incident pathways.

**35.1.4 Zero Trust Across Foundry Surfaces.** Zero Trust shall apply to repositories, data rooms, secure rooms, clean rooms, no-download rooms, cloud environments, sovereign compute, edge environments, National Dense Nexus Cores, Regional Clusters, Dense Cores, release pipelines, Studio runtime, Marketplace listing workflows, Registry records, Observatory Node Grids, Academy environments, Nexus Universe Core Build infrastructure, Frontier Labs, and lawful handoff preparation environments.

**35.1.5 Zero Trust and Role Separation.** Zero Trust shall reinforce role separation. A contributor shall not automatically receive maintainer access. A maintainer shall not automatically receive release authority. A reviewer shall not automatically receive privileged infrastructure access. A public authority learner shall not receive operational access. A provider contributor shall not receive validation authority. A sponsor shall not receive data access. A capital reader shall not receive confidential technical or national data access unless separately authorized.

**35.1.6 Zero Trust and Public-Good Firewall.** Zero Trust shall preserve the public-good firewall by preventing public-good infrastructure from becoming a private enterprise control surface, sponsor information channel, provider dependency trap, privileged commercial observability system, or unrecorded execution layer. Technical access shall not become institutional authority.

**35.1.7 Zero Trust Without Surveillance Overclaim.** Zero Trust controls shall not become unrestricted surveillance of contributors, participants, communities, Indigenous actors where applicable, public authority learners, or users. Logging, monitoring, and access review shall be lawful, proportionate, purpose-bound, documented, privacy-aware, and sensitive to protected knowledge and national data controls.

**35.1.8 Zero Trust Baseline Formula.** The Zero Trust Baseline shall follow the formula: **trust nothing by default; verify identity; authorize by role and purpose; restrict by data class; monitor proportionately; revoke when purpose ends; correct drift; never let technical access become authority, consent, deployment, or execution.**

***

### 35.2 Identity and Access Management

**35.2.1 Identity and Access Management Identity.** **Identity and Access Management** shall be the Foundry control system for identifying users, service accounts, systems, agents, devices, workloads, repositories, connectors, dashboards, Studio runtime participants, Marketplace and Registry users, National Node participants, public authority learners, provider contributors, sponsor participants, and external collaborators. IAM shall ensure that access is known, bounded, appropriate, revocable, and recorded.

**35.2.2 Identity Classes.** Foundry identity classes may include individual contributor, maintainer, reviewer, release steward, support steward, correction steward, archive steward, Guild participant, Competence Cell participant, National Working Group participant, National Node participant, public authority learner, provider contributor, sponsor participant, partner participant, capital reader, insurer reader, donor reader, public finance reader, Academy participant, Studio user, secure-room user, service account, AI agent identity, workload identity, device identity, connector identity, and administrative identity.

**35.2.3 IAM Record.** An IAM Record shall identify identity, role, organization or affiliation where relevant, access class, data class, environment, authorization basis, approver or steward, training prerequisites, confidentiality obligations, conflicts where relevant, start date, review date, expiry date where applicable, revocation triggers, correction pathway, and archive rule.

**35.2.4 Access Classes.** Access may be public, controlled-public, registered, contributor, reviewer, maintainer, steward, national, regional, global, secure-room, no-download, clean-room, compute-to-data, Studio runtime, Marketplace steward, Registry steward, release steward, administrator, emergency-restricted, suspended, or archived. Each access class shall be defined by record and shall not imply other access classes.

**35.2.5 Least Privilege.** Access shall be limited to what the identity needs for its recorded task. Broad access shall be exceptional, time-bounded where feasible, reviewed more frequently, and subject to stronger logging and conflict controls where appropriate.

**35.2.6 Authentication and Verification.** IAM shall require authentication proportionate to risk. Higher-risk environments shall require stronger identity verification, multi-factor authentication where appropriate, device or workload trust where appropriate, and additional authorization before access to sensitive data, privileged functions, secure rooms, release systems, or administrative controls.

**35.2.7 Access Review.** Access shall be reviewed when roles change, projects close, Core Build cycles end, Nexus Universe cycles close, employment or affiliation changes, training expires, conflicts arise, incidents occur, support responsibilities end, handoff packages close, or data sensitivity changes.

**35.2.8 Identity and Authority Boundary.** IAM access shall not create authority to approve, certify, release, publish, list, register, activate Studio runtime, assign TRL status, grant public authority status, make finance or procurement decisions, grant consent, deploy, or execute. IAM governs technical access only.

**35.2.9 IAM Correction.** IAM records shall be corrected where identity is wrong, role is overstated, access persists beyond need, data class is misassigned, affiliation changes, conflict is undisclosed, service account is orphaned, agent identity exceeds scope, or access is used to imply authority.

**35.2.10 IAM Formula.** Identity and Access Management shall follow the formula: **identify every actor and workload; grant least privilege; bind access to role and time; review continuously; revoke promptly; never let access become institutional authority.**

***

### 35.3 Privileged Access Management

**35.3.1 Privileged Access Management Identity.** **Privileged Access Management** shall govern elevated permissions that can alter systems, access sensitive data, modify records, change release states, configure Studio runtime, administer Marketplace or Registry systems, manage secrets, control compute environments, alter network controls, change security settings, or affect public-safe publication and handoff pathways. Privileged access shall be exceptional and tightly controlled.

**35.3.2 Privileged Roles.** Privileged roles may include infrastructure administrator, security administrator, repository administrator, release administrator, Registry administrator, Marketplace administrator, Studio administrator, secure-room administrator, data-room administrator, identity administrator, secrets administrator, compute administrator, cloud administrator, edge administrator, Observatory administrator, incident responder, and emergency access steward.

**35.3.3 Privileged Access Record.** A Privileged Access Record shall identify privileged identity, role, system, permission set, authorization basis, approving steward, duration, justification, data and system scope, logging requirement where appropriate, break-glass conditions, review frequency, revocation trigger, correction pathway, and archive rule.

**35.3.4 Separation of Duties.** Privileged functions shall be separated where risk requires. The same person or system should not unilaterally build, approve, release, publish, list, register, activate runtime, and archive high-risk objects without review. Provider contributors shall not administer environments that validate or release their own provider-dependent objects without independent controls.

**35.3.5 Just-in-Time and Time-Bound Access.** Privileged access should be time-bound, just-in-time, or task-bound where feasible. Persistent privileged access shall require stronger justification, stronger monitoring where appropriate, periodic review, and rapid revocation.

**35.3.6 Break-Glass Access.** Break-glass access may be used only for defined emergency, security, continuity, access recovery, or incident-response needs. Break-glass use shall be logged where appropriate, reviewed after use, corrected if misused, and never used to bypass review or create status.

**35.3.7 Privileged Actions Boundary.** Privileged access enables technical administration; it does not create institutional permission to approve release, alter truth records, create public authority effect, finance effect, procurement effect, consent effect, deployment effect, or execution effect beyond recorded process.

**35.3.8 Privileged Access Incident.** A Privileged Access Incident shall arise where elevated permissions are misused, retained beyond need, granted without authority, used to bypass review, used to alter records improperly, used to access sensitive data without need, or used to imply institutional authority.

**35.3.9 PAM Correction.** Privileged access shall be revoked, reduced, rotated, reviewed, suspended, or escalated where misuse, drift, conflict, incident, role change, orphaned account, provider-capture risk, sponsor-control risk, or public-good firewall risk appears.

**35.3.10 PAM Formula.** Privileged Access Management shall follow the formula: **elevate only by need; separate duties; time-bound privilege; log and review where appropriate; revoke quickly; never let administrative power become substantive authority.**

***

### 35.4 Secrets Management

**35.4.1 Secrets Management Identity.** **Secrets Management** shall govern the creation, storage, use, rotation, revocation, recovery, deletion, and auditability where appropriate of credentials, keys, tokens, passwords, certificates, service-account secrets, API keys, cloud credentials, model keys, repository tokens, database credentials, secure-room credentials, signing keys, encryption keys, webhook secrets, and other sensitive authentication materials used by Foundry.

**35.4.2 Secrets Management Purpose.** Secrets Management shall prevent unauthorized access, data leakage, supply-chain compromise, AI tool misuse, repository compromise, cloud compromise, edge compromise, Marketplace or Registry manipulation, Studio runtime compromise, release compromise, and public-good infrastructure capture.

**35.4.3 Secrets Record.** A Secrets Record shall identify secret class, owner or steward, purpose, system, access roles, storage location class, rotation schedule where applicable, expiry where applicable, emergency revocation pathway, exposure response, dependency relationship, archive or deletion rule, and prohibited handling. The secret value itself shall not be exposed in ordinary records.

**35.4.4 Storage and Handling.** Secrets shall be stored in approved secret-management systems or controlled environments. Secrets shall not be placed in prompts, public documents, code repositories, logs, dashboards, issue trackers, shared documents, public-safe reports, Marketplace listings, Registry entries, Studio outputs, or handoff packages.

**35.4.5 Least-Privilege Secrets.** Secrets shall be scoped to the minimum required systems, environments, data, actions, and duration. Shared secrets shall be avoided where possible. Service accounts and agent identities shall use narrowly scoped credentials.

**35.4.6 Rotation and Revocation.** Secrets shall be rotated or revoked when exposure is suspected, access changes, roles end, Core Build environments close, Nexus Universe cycles end, providers change, systems are decommissioned, privileged users depart, agents are disabled, or incidents occur.

**35.4.7 AI and Secrets.** AI systems and agents shall not receive secrets unless specifically authorized through controlled tool interfaces or secure systems. Secrets shall not be copied into prompts, training data, memory, logs, or AI-generated outputs. AI workflows shall be designed to reject or redact accidental secret exposure where feasible.

**35.4.8 Secrets Exposure Incident.** Any suspected exposure of a secret shall trigger containment, revocation, rotation, incident review, affected-system review, output review, public-safe notice where required, correction, and archive.

**35.4.9 Secrets Correction.** Secrets Records shall be corrected where ownership changes, scope is wrong, rotation is missed, storage is unsafe, logs contain secrets, AI workflows expose secrets, or secrets remain active after purpose ends.

**35.4.10 Secrets Management Formula.** Secrets Management shall follow the formula: **store secrets only in controlled systems; scope narrowly; never expose in prompts or records; rotate when risk changes; revoke after use; treat every leak as incident.**

***

### 35.5 Logging and Monitoring

**35.5.1 Logging and Monitoring Identity.** **Logging and Monitoring** shall be the controlled capture, review, alerting, retention, restriction, correction, and archive of system activity, access events, privileged actions, security events, data-room activity, secure-room activity, AI workflow activity, tool use, release actions, Registry changes, Marketplace changes, Studio runtime events, edge events, Observatory events, and incident-related activity where appropriate and lawful.

**35.5.2 Logging Purpose.** Logging shall support accountability, security, incident response, correction, provenance, release integrity, Registry truth, Marketplace integrity, Studio safety, data protection, AI boundary review, access review, and archive. Logging shall be proportionate and shall not become unrestricted surveillance.

**35.5.3 Log Classes.** Logs may include authentication logs, authorization logs, privileged-action logs, repository logs, release logs, Registry change logs, Marketplace change logs, Studio runtime logs, tool-use logs, AI workflow logs, secure-room logs, data export logs, edge telemetry logs, compute logs, network logs, vulnerability logs, incident logs, correction logs, and archive logs.

**35.5.4 Logging Record.** A Logging Record shall identify log type, purpose, system, sensitivity, retention period, access roles, monitoring rules, alert triggers, redaction rules, protected knowledge controls, public authority-sensitive controls, Indigenous protocol sensitivity where applicable, deletion or archive rule, correction pathway, and prohibited uses.

**35.5.5 Monitoring Proportionality.** Monitoring shall be proportionate to risk. High-risk systems may require more active monitoring, including privileged access, release systems, secure rooms, AI agent workflows, public-facing dashboards, edge environments, Registry and Marketplace systems, Studio runtime, and sensitive data workflows.

**35.5.6 Privacy and Sensitive Content.** Logs may contain personal information, confidential information, public authority-sensitive information, protected knowledge, Indigenous-sensitive knowledge where applicable, cyber-sensitive information, infrastructure-sensitive information, model vulnerabilities, or secrets. Such logs shall be restricted, redacted, sealed, aggregated, or deleted where required.

**35.5.7 Alerting and Escalation.** Monitoring may trigger alerts for unauthorized access, privilege escalation, secrets exposure, suspicious downloads, abnormal tool use, AI agent overreach, data export anomalies, release manipulation, Registry or Marketplace changes, Studio runtime anomalies, edge telemetry anomalies, and secure-room breaches. Alerts shall be routed to appropriate incident pathways.

**35.5.8 Logs Without Status Effect.** Logs support investigation and correction; they do not by themselves create approval, fault determination, certification, public authority classification, procurement status, finance effect, consent status, deployment authorization, or execution effect. Findings require competent review.

**35.5.9 Logging Correction.** Logs and monitoring rules shall be corrected where logging is too broad, too weak, inaccurate, over-retained, missing critical events, exposing sensitive content, creating surveillance risk, or failing to support incident response.

**35.5.10 Logging and Monitoring Formula.** Logging and Monitoring shall follow the formula: **log what matters; protect what logs reveal; monitor proportionately; alert on risk; review before judgment; correct logging gaps; never let monitoring become surveillance or authority.**

***

### 35.6 Vulnerability Management

**35.6.1 Vulnerability Management Identity.** **Vulnerability Management** shall be the Foundry process for identifying, recording, triaging, prioritizing, remediating, validating, communicating, and archiving vulnerabilities affecting software, infrastructure, dependencies, cloud environments, edge devices, AI systems, agents, connectors, APIs, dashboards, Studio runtime packages, Marketplace systems, Registry systems, release pipelines, secure rooms, data rooms, and compute environments.

**35.6.2 Vulnerability Classes.** Vulnerabilities may include software defects, dependency vulnerabilities, configuration errors, exposed secrets, access-control weaknesses, privilege escalation pathways, injection risks, AI prompt-injection risks, model extraction risks, data leakage risks, connector weaknesses, dashboard exposure risks, edge-device vulnerabilities, OT interface risks, secure-room control failures, release integrity failures, and supply-chain risks.

**35.6.3 Vulnerability Record.** A Vulnerability Record shall identify affected object or system, vulnerability class, severity, source, affected versions, affected data classes, exploitability where appropriate, public-safe disclosure limits, remediation owner, mitigation, timeline, compensating controls, validation method, notice requirement, correction pathway, archive rule, and prohibited claims.

**35.6.4 Triage and Prioritization.** Vulnerability prioritization shall consider severity, exploitability, exposed data, public authority sensitivity, protected knowledge risk, Indigenous-sensitive knowledge risk where applicable, infrastructure risk, public-facing exposure, AI tool risk, release status, support status, Marketplace listing, Registry presence, Studio runtime, national context, and handoff proximity.

**35.6.5 Remediation and Validation.** Remediation may include patching, dependency update, configuration change, access restriction, credential rotation, connector suspension, dashboard restriction, Studio pause, Marketplace suspension, Registry correction, release withdrawal, data sealing, edge disconnection, or handoff recall. Remediation shall be validated where risk requires.

**35.6.6 Coordinated Disclosure.** Vulnerability disclosure shall be public-safe and security-aware. Details that enable harm shall be controlled. Public or targeted notices may be required where users, National Nodes, Studio users, Marketplace users, handoff recipients, public authorities, or affected stakeholders face material risk.

**35.6.7 Vulnerability Without Certification.** Completion of vulnerability remediation shall not create cybersecurity certification, legal compliance certification, procurement suitability, financeability, insurability, public authority approval, deployment authorization, or security guarantee. It means the recorded vulnerability was addressed within stated limits.

**35.6.8 Vulnerability Correction.** Vulnerability Records shall be corrected where severity changes, affected systems expand, remediation fails, disclosure was incomplete, public-safe language was unsafe, or vulnerability status is misused as security certification.

**35.6.9 Vulnerability Management Formula.** Vulnerability Management shall follow the formula: **find weaknesses; record severity; restrict exposure; remediate; validate; disclose safely; archive lessons; never convert patching into universal assurance.**

***

### 35.7 Secure Rooms

**35.7.1 Secure Room Identity.** **Secure Rooms** shall be controlled Foundry environments for sensitive work requiring heightened access controls, confidentiality, data protection, output review, cyber controls, public-safe restrictions, protected knowledge safeguards, public authority-sensitive handling, Indigenous protocol-sensitive handling where applicable, or restricted collaboration. Secure Rooms may be physical, virtual, hybrid, compute-based, data-based, Studio-based, or meeting-based.

**35.7.2 Secure Room Purpose.** Secure Rooms may support restricted evidence review, public authority-sensitive learning, protected knowledge handling, Indigenous-sensitive knowledge handling where applicable, cyber-sensitive review, infrastructure-sensitive review, secure AI evaluation, secure data analysis, compute-to-data workflows, handoff dependency review, vulnerability review, readiness review, and public-safe preparation.

**35.7.3 Secure Room Record.** Each Secure Room shall have a Secure Room Record identifying purpose, room class, data and information classes, access roles, authorization basis, confidentiality conditions, permitted materials, prohibited materials, permitted tools, prohibited tools, output-review rules, logging rules where appropriate, retention rules, teardown rules, incident pathway, correction pathway, archive rule, and prohibited claims.

**35.7.4 Secure Room Access.** Access shall require role readiness, need, training, confidentiality agreement where appropriate, conflict disclosure where relevant, identity verification, authorization, and room-specific rules. Access shall not be granted because of status, seniority, sponsorship, provider contribution, investor interest, or public authority attendance alone.

**35.7.5 Secure Room Output Review.** Materials leaving a Secure Room shall be reviewed for data leakage, protected knowledge exposure, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, privacy, Indigenous protocol sensitivity where applicable, public-safe meaning, and downstream overclaim risk. No raw extraction shall occur without record.

**35.7.6 Secure Room Boundary.** Secure Room access shall not create approval, public authority status, finance status, procurement status, consent, deployment authorization, data ownership, protected knowledge permission, or execution authority. Secure handling is not substantive approval.

**35.7.7 Secure Room Incident.** Unauthorized access, unauthorized recording, prohibited download, data spill, credential exposure, protected knowledge exposure, public authority-sensitive disclosure, AI prompt leakage, cyber-sensitive disclosure, or output-review failure shall trigger incident response, access closure, correction, notice where required, and archive.

**35.7.8 Secure Room Teardown.** Secure Rooms shall be closed or renewed by record. Closure shall address access revocation, data disposition, output archive, log retention where appropriate, credential rotation, participant notice, and residual risk.

**35.7.9 Secure Room Formula.** Secure Rooms shall follow the formula: **restrict entry; restrict tools; protect sensitive materials; review outputs; close deliberately; never treat secure participation as approval or authority.**

***

### 35.8 Clean Rooms

**35.8.1 Clean Room Identity.** **Clean Rooms** shall be controlled environments where data, models, code, evidence, or sensitive materials from different actors may be analyzed, compared, aggregated, evaluated, or transformed under rules that limit raw data exposure, cross-party misuse, protected knowledge exposure, proprietary leakage, public authority-sensitive disclosure, or unauthorized export.

**35.8.2 Clean Room Purpose.** Clean Rooms may support privacy-preserving evidence analysis, provider-neutral comparisons, public authority learning, cross-institutional research, national data analysis, DRI and GRIx development, Observatory preparation, AI evaluation, secure benchmarking, readiness question mapping, and handoff dependency analysis where raw sharing would be unsafe or unauthorized.

**35.8.3 Clean Room Record.** Each Clean Room shall have a Clean Room Record identifying parties, purpose, data classes, permitted inputs, prohibited inputs, approved workloads, permitted outputs, output-review rules, access roles, confidentiality conditions, IP and license conditions, provider-neutrality rules, retention, deletion or sealing rules, incident pathway, correction pathway, archive rule, and prohibited claims.

**35.8.4 Clean Room Output Controls.** Outputs shall be aggregated, redacted, masked, delayed, generalized, or restricted where needed to prevent re-identification, proprietary leakage, protected knowledge exposure, Indigenous-sensitive exposure where applicable, public authority-sensitive exposure, cyber-sensitive disclosure, or provider validation overclaim.

**35.8.5 Clean Room and Provider Neutrality.** Clean Rooms used for provider comparison, benchmark preparation, or technical evaluation shall be designed to avoid provider self-validation, hidden sponsor influence, selective disclosure, benchmark overclaim, or procurement implication. Clean Room results shall be described only within recorded conditions.

**35.8.6 Clean Room Without Certification.** Clean Room analysis shall not create certification, audit assurance, legal compliance, public authority approval, procurement ranking, financeability, insurability, provider validation, consent, deployment authorization, or execution authority.

**35.8.7 Clean Room Incident.** Raw data exposure, output leakage, re-identification risk, prohibited query, unauthorized export, participant misuse, provider overclaim, public-safe failure, or confidentiality breach shall trigger incident response, output restriction, correction, notice where required, and archive.

**35.8.8 Clean Room Formula.** Clean Rooms shall follow the formula: **bring parties into controlled analysis; limit raw exposure; review outputs; prevent re-identification and benchmark overclaim; correct leakage; never let clean-room analysis become certification or procurement signal.**

***

### 35.9 No-Download Environments

**35.9.1 No-Download Environment Identity.** **No-Download Environments** shall be controlled environments in which users may view, query, analyze, annotate, review, or compute on restricted materials without downloading, copying, exporting, screenshotting where prohibited, synchronizing, printing, or otherwise extracting raw or sensitive content unless separately authorized by record.

**35.9.2 No-Download Purpose.** No-Download Environments shall protect restricted data, sovereign-sensitive data, public authority-sensitive materials, confidential partner materials, provider-sensitive materials, protected knowledge, Indigenous-sensitive knowledge where applicable, community-sensitive information, cyber-sensitive information, infrastructure-sensitive information, health-sensitive information, and high-risk evidence materials while allowing bounded work.

**35.9.3 No-Download Record.** Each No-Download Environment shall have a No-Download Record identifying material class, purpose, access roles, allowed actions, prohibited actions, technical controls, output-review rules, screenshot or recording rules, clipboard rules, local storage rules, printing rules, logging where appropriate, retention, teardown, incident pathway, correction pathway, and archive rule.

**35.9.4 Allowed Outputs.** Allowed outputs may include reviewed summaries, aggregate tables, redacted notes, classification labels, public-safe extracts, approved evidence summaries, approved dashboard outputs, approved handoff notes, or approved correction notes. Raw extraction shall be prohibited unless separately authorized.

**35.9.5 AI in No-Download Environments.** AI tools used in No-Download Environments shall be authorized, sandboxed, and prevented from exporting restricted content into external prompts, model training, persistent memory, logs, or outputs. AI-generated summaries shall undergo output review where sensitivity requires.

**35.9.6 No-Download Boundary.** No-download access shall not create ownership, reuse rights, publication rights, model-training rights, public authority status, procurement status, financeability, consent, deployment authorization, or execution authority. Viewing is not permission to use beyond scope.

**35.9.7 No-Download Incident.** Unauthorized download, copy, screenshot, recording, print, sync, AI extraction, output leakage, or raw data export shall trigger incident response, access closure, credential review, correction, notice where required, and archive.

**35.9.8 No-Download Correction.** No-Download Records shall be corrected where controls fail, output review is incomplete, users misunderstand restrictions, AI tools leak content, access persists beyond need, or no-download access is used as authorization overclaim.

**35.9.9 No-Download Formula.** No-Download Environments shall follow the formula: **allow bounded viewing and analysis; block raw extraction; review outputs; restrict AI export; close access when purpose ends; never let viewing become permission or authority.**

***

### 35.10 Security Incident Response and Access Closure

**35.10.1 Incident Response Identity.** **Security Incident Response and Access Closure** shall be the Foundry process for detecting, containing, analyzing, correcting, notifying, recovering from, learning from, and archiving cybersecurity and secure-infrastructure incidents, including unauthorized access, data exposure, secrets leakage, privilege misuse, vulnerability exploitation, AI tool misuse, secure-room breach, clean-room breach, no-download breach, edge compromise, Studio incident, Marketplace manipulation, Registry manipulation, release compromise, and compute environment compromise.

**35.10.2 Security Incident Record.** A Security Incident Record shall identify incident type, affected systems, affected data, affected identities, affected records, discovery source, timeline, severity, containment actions, access closures, secrets rotation, public-safe risk, public authority risk, national routing implications, safeguard implications, notice requirements, recovery actions, correction actions, recurrence controls, and archive status.

**35.10.3 Incident Severity.** Incident severity shall consider confidentiality, integrity, availability, public-safe impact, data sensitivity, protected knowledge exposure, Indigenous-sensitive knowledge exposure where applicable, public authority-sensitive exposure, cyber-sensitive exposure, infrastructure impact, AI boundary risk, Marketplace and Registry status impact, Studio impact, national impact, and handoff impact.

**35.10.4 Immediate Containment.** Containment may include access closure, account suspension, privileged access revocation, secret rotation, environment isolation, network segmentation, data sealing, Studio pause, Marketplace suspension, Registry freeze, release withdrawal, connector shutdown, agent shutdown, edge disconnection, secure-room closure, clean-room closure, no-download restriction, and public-safe communication hold.

**35.10.5 Access Closure.** Access Closure shall revoke or suspend access that is no longer justified, is implicated in an incident, exceeds role, presents conflict risk, relates to expired purpose, or threatens public-good firewall integrity. Closure shall include human accounts, service accounts, agent identities, API keys, tokens, certificates, cloud roles, secure-room access, data-room access, Studio access, Marketplace/Registry admin access, and edge access where applicable.

**35.10.6 Notification and Public-Safe Communication.** Notices shall be issued where required by law, contract, public-safe duty, affected-user reliance, national pathway, public authority sensitivity, community safeguard, Indigenous protocol where applicable, Marketplace or Registry status, Studio use, or handoff recipient reliance. Notices shall be accurate, non-alarmist where appropriate, and not overclaim official public authority meaning.

**35.10.7 Recovery and Validation.** Recovery shall include restoring systems, validating integrity, reviewing logs where appropriate, checking data state, confirming access closure, rotating credentials, patching vulnerabilities, updating records, reconciling Registry and Marketplace status, resuming Studio only by record, and archiving evidence.

**35.10.8 Incident Correction.** Incident response shall correct both technical conditions and public meaning. Correction may include public-safe clarification, Registry correction, Marketplace correction, Studio correction, release correction, support-status change, handoff recall, training update, control redesign, and archive annotation.

**35.10.9 Security Incident Response Formula.** Security Incident Response and Access Closure shall follow the formula: **detect; contain; close access; rotate secrets; assess harm; notify where required; recover; correct records and meaning; archive lessons; never hide incidents to protect reputation.**

***

### 35.11 Cyber Range and Simulation Separation

**35.11.1 Cyber Range Identity.** **Cyber Range and Simulation Separation** shall govern controlled cybersecurity training, testing, adversarial simulation, incident rehearsal, AI red-team practice, secure infrastructure testing, vulnerability validation, and resilience exercises within bounded environments that are separated from production, public authority systems, enterprise execution systems, critical infrastructure, and uncontrolled real-world targets.

**35.11.2 Cyber Range Purpose.** Cyber ranges may support Academy training, contributor training, secure infrastructure training, AI and agent testing, incident rehearsal, vulnerability management, secure-room procedure testing, edge security testing, OT-safety learning, Studio safety testing, and public authority learning demonstrations. They shall develop capability without enabling harmful use.

**35.11.3 Cyber Range Record.** Each Cyber Range or simulation environment shall have a Cyber Range Record identifying purpose, participants, scope, target systems, allowed activities, prohibited activities, tool restrictions, data restrictions, network isolation, safety controls, logging where appropriate, output restrictions, public-safe limits, teardown rules, incident pathway, correction pathway, and archive rule.

**35.11.4 Separation From Production.** Cyber ranges and simulations shall be separated from production systems, live public authority systems, real critical infrastructure, real user data, unrestricted networks, public dashboards, Marketplace production, Registry production, Studio production, and release pipelines unless a separate tightly controlled test authorization exists.

**35.11.5 Prohibited Activities.** Cyber range activities shall not include unauthorized access, real-world exploitation, uncontrolled malware deployment, credential theft, data exfiltration, public target testing, public authority system testing, provider system testing, or OT control attempts unless separately and lawfully authorized by competent owners under controlled conditions.

**35.11.6 Dual-Use Controls.** Cyber range materials, tools, outputs, and lessons shall be handled with dual-use awareness. Public materials shall not disclose harmful capabilities, exploit details, sensitive vulnerabilities, operational tactics, or infrastructure weaknesses in a way that increases risk.

**35.11.7 Simulation Without Security Certification.** Performance in a cyber range shall not certify security competence, system security, legal compliance, procurement suitability, insurance acceptance, public authority approval, deployment authorization, or operational readiness. It supports learning and evidence within limits.

**35.11.8 Cyber Range Incident.** Escape from range, unsafe tool use, unauthorized target access, data exposure, harmful output disclosure, participant misuse, AI misuse, or simulation confusion with production shall trigger incident response, containment, correction, access restriction, and archive.

**35.11.9 Cyber Range Formula.** Cyber Range and Simulation Separation shall follow the formula: **train in isolated environments; define allowed actions; prohibit real-world harm; control dual-use outputs; separate from production; correct range misuse; never let simulation become live operation.**

***

### 35.12 Security Archive and Lessons Learned

**35.12.1 Security Archive Identity.** **Security Archive and Lessons Learned** shall preserve cybersecurity and secure-infrastructure records, incident records, access closure records, vulnerability records, secure-room records, clean-room records, no-download records, cyber range records, logging rules, monitoring changes, secrets rotation records, control corrections, public-safe notices, handoff recalls, and lifecycle lessons in a manner that supports accountability, learning, renewal, and future prevention.

**35.12.2 Archive Purpose.** Security Archive shall prevent repeated errors, hidden drift, institutional forgetting, unsafe reactivation, unmanaged access, repeated overclaim, stale vulnerability assumptions, repeated AI tool misuse, repeated provider dependency, repeated secure-room failure, and repeated public-safe communication failure. It shall preserve learning without exposing sensitive details.

**35.12.3 Security Archive Record.** A Security Archive Record shall identify record class, affected system, prior status, archive reason, sensitivity class, access restrictions, correction history, notice history, lessons learned, recurrence controls, successor controls, retention rule, deletion or sealing rule where applicable, reinstatement conditions, and prohibited claims.

**35.12.4 Sensitive Archive Controls.** Security archive materials may contain vulnerabilities, exploit details, incident timelines, personal information, protected knowledge, Indigenous-sensitive knowledge where applicable, public authority-sensitive information, infrastructure-sensitive information, provider-sensitive information, secrets history, and legal-sensitive materials. Archive access shall be restricted accordingly.

**35.12.5 Lessons Learned.** Lessons learned may update Zero Trust rules, IAM rules, PAM rules, secrets management, logging and monitoring, vulnerability management, secure-room procedures, clean-room procedures, no-download controls, AI workflow authorization, tool permission rules, Cyber Range rules, Academy training, Marketplace controls, Registry controls, Studio controls, release controls, edge controls, and handoff templates.

**35.12.6 Public-Safe Lessons.** Where security lessons are shared publicly, they shall be public-safe, non-exploit-enabling, non-stigmatizing, accurate, and bounded. Public learning shall not expose vulnerabilities, blame communities, imply public authority findings, or create market, procurement, finance, insurance, or execution signals.

**35.12.7 Reinstatement From Security Archive.** A security control, environment, workflow, connector, agent, release pipeline, Studio package, Marketplace listing, Registry record, or edge environment that was archived or restricted for security reasons may be reinstated only after review showing that the security reason has been addressed, access controls are current, support exists, and correction records are complete.

**35.12.8 Archive Correction.** Security Archive records shall remain correctable where metadata is wrong, sensitivity changes, public display creates overclaim, vulnerability status changes, legal requirements change, retention requirements change, or future users may misunderstand archived records as current security approval.

**35.12.9 Final Cybersecurity and Secure Infrastructure Formula.** The controlling Cybersecurity and Secure Infrastructure Formula is that **Foundry security begins from Zero Trust; identity and access are explicit, least-privilege, reviewable, and revocable; privileged access is exceptional and separated; secrets are controlled and never exposed; logging and monitoring are proportionate and protected; vulnerabilities are recorded, remediated, and disclosed safely; secure rooms, clean rooms, and no-download environments restrict sensitive work; incidents trigger containment, access closure, correction, notice, recovery, and archive; cyber ranges remain separated from production; and security archive preserves lessons without converting security practice into certification, public authority approval, procurement status, financeability, consent, deployment authorization, or execution authority.**

## 36. Foundry Data Architecture

### 36.1 Data Classification

**36.1.1 Data Classification Identity.** **Foundry Data Classification** shall be the controlled framework through which Nexus Foundry identifies, labels, governs, restricts, processes, shares, publishes, archives, corrects, and retires data used in Foundry work. Data classification shall apply before data is used for evidence, AI, simulation, observability, dashboards, GRIx, DRI, Studio runtime, Marketplace context, Registry records, National Portfolios, public authority learning, readiness mapping, public-safe publication, or lawful handoff dependency packaging.

**36.1.2 Classification Purpose.** Data classification shall prevent Foundry from treating all data as equally usable, publishable, transferable, reusable, model-trainable, or handoff-ready. Classification shall protect privacy, sovereignty, public authority sensitivity, protected knowledge, Indigenous knowledge and data where applicable, community-sensitive information, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, confidential provider or partner information, and public-safe meaning.

**36.1.3 Classification Classes.** Foundry data may be classified as public, public-safe, controlled-public, internal, restricted, confidential, sovereign-sensitive, national-sensitive, public authority-sensitive, community-sensitive, Indigenous-sensitive where applicable, protected knowledge, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, finance-reader-sensitive, procurement-sensitive, legal-sensitive, export-controlled or sanctions-sensitive where applicable, no-download, secure-room-only, compute-to-data-only, archive-only, sealed, or deletion-required.

**36.1.4 Classification Record.** A Data Classification Record shall identify dataset or data object, source, steward, jurisdiction, data class, sensitivity class, permitted uses, prohibited uses, access class, processing class, transfer class, output-review requirement, retention rule, deletion or sealing rule, public-safe status, national routing requirement, safeguard requirement, correction pathway, archive rule, and prohibited claims.

**36.1.5 Classification Before Use.** No material data shall be used in Foundry production until its classification is known or a temporary restrictive classification is applied. Where classification is uncertain, the most restrictive reasonable classification shall govern until review resolves the uncertainty.

**36.1.6 Classification and AI.** Data classification shall determine whether data may be used with AI models, retrieval systems, embeddings, summarizers, classifiers, agents, Studio workflows, model evaluation, fine-tuning, training, or public-safe drafting. Sensitive data shall not be entered into external AI systems, persistent memory, training workflows, or unapproved tools unless separately authorized by record.

**36.1.7 Classification and Public Display.** Public display of data, dashboards, maps, summaries, indicators, public-safe reports, Marketplace descriptions, Registry records, Studio demonstrations, or Nexus Universe materials shall require public-safe classification and output review where risk exists.

**36.1.8 Classification Correction.** Data Classification Records shall be corrected where data sensitivity changes, source terms change, national law changes, public authority sensitivity appears, community or Indigenous sensitivity is identified, re-identification risk appears, geospatial sensitivity increases, public-safe risk emerges, or data is misused beyond classification.

**36.1.9 Data Classification Formula.** Data classification shall follow the formula: **classify before use; apply the most restrictive rule under uncertainty; bind access and processing to class; review outputs; correct misclassification; never let data availability become data permission.**

***

### 36.2 Dataset Records

**36.2.1 Dataset Record Principle.** A **Dataset Record** shall be the Foundry status and provenance record for a dataset, data stream, derived dataset, data extract, telemetry collection, geospatial layer, model input set, benchmark set, evidence dataset, Observatory dataset, DRI dataset, GRIx dataset, Studio dataset, Marketplace dataset reference, Registry dataset reference, or handoff-related data object.

**36.2.2 Dataset Record Elements.** A Dataset Record shall include dataset identifier, name, source, source steward, collection method, version, date range, geography, jurisdiction, data class, sensitivity class, access class, license or terms, lawful basis or permission where applicable, data residency rule, permitted uses, prohibited uses, processing history, transformation history, quality notes, uncertainty notes, known limitations, output-review requirement, retention rule, deletion or sealing rule, correction history, archive rule, and prohibited interpretations.

**36.2.3 Dataset Object Classes.** Dataset Records may apply to raw datasets, cleaned datasets, derived datasets, aggregated datasets, synthetic datasets, benchmark datasets, telemetry datasets, Earth observation datasets, GIS layers, sensor datasets, survey datasets, community-input datasets, public authority datasets, health datasets, cyber datasets, infrastructure datasets, protected knowledge datasets, Indigenous-sensitive datasets where applicable, and AI evaluation datasets.

**36.2.4 Dataset Versioning.** Dataset Records shall preserve version lineage. Material changes to content, schema, source, cleaning method, transformation, aggregation, geography, time period, sensitivity, access status, license, or permitted use shall require version update, supersession, correction, restriction, or archive.

**36.2.5 Dataset Without Use Authority.** A Dataset Record shall not by itself authorize use, export, publication, AI training, dashboard display, Marketplace listing, Registry display, public authority use, finance-reader use, procurement use, handoff, deployment, or execution. Use must follow classification, custody, permissions, access, output review, and lawful pathway requirements.

**36.2.6 Dataset Quality Notes.** Dataset Records shall identify quality issues, missingness, bias, representativeness limits, uncertainty, collection limitations, time lag, spatial resolution, known errors, and contexts where use would be unsafe or misleading. Evidence gaps shall be recorded rather than hidden.

**36.2.7 Dataset Support and Maintenance.** Dataset Records shall identify whether the dataset is static, maintained, periodically refreshed, experimental, restricted, deprecated, withdrawn, sealed, archived, or deletion-required. Stale datasets shall not be displayed as current.

**36.2.8 Dataset Record Correction.** Dataset Records shall be corrected where source information is wrong, terms are wrong, classification is wrong, version lineage is missing, quality notes are incomplete, permissions change, or downstream users misunderstand dataset status.

**36.2.9 Dataset Record Formula.** Dataset Records shall follow the formula: **identify the dataset; record source and terms; classify sensitivity; version changes; state limits; restrict use; correct errors; archive non-current data.**

***

### 36.3 Data Provenance

**36.3.1 Data Provenance Principle.** **Data Provenance** shall preserve the origin, chain, transformation, permission, classification, quality, and use history of data within Foundry. Provenance shall allow Foundry to understand where data came from, how it was changed, who stewarded it, what permissions apply, what risks attach, and what outputs depend on it.

**36.3.2 Provenance Scope.** Provenance shall apply to raw data, derived data, transformed data, aggregated data, synthetic data, AI-generated data, telemetry, geospatial layers, Earth observation products, public authority data, community-grounded inputs, Indigenous-sensitive data where applicable, protected knowledge, benchmark sets, evidence datasets, simulation inputs, dashboard inputs, Studio inputs, Marketplace references, Registry records, and handoff package inputs.

**36.3.3 Provenance Record.** A Data Provenance Record shall identify source, collection method, collection date or period, collector or provider, steward, legal or permission basis where applicable, license or terms, jurisdiction, transformations, tools used, compute environment, quality checks, validation steps, limitations, output lineage, downstream records, correction history, and archive linkage.

**36.3.4 Transformation Lineage.** Foundry shall preserve lineage for cleaning, normalization, aggregation, masking, anonymization, pseudonymization, feature extraction, geospatial processing, model input preparation, simulation preparation, AI embedding, dashboard transformation, and public-safe summarization where material.

**36.3.5 Provenance and Trust.** Provenance shall not mean data is automatically true, complete, representative, lawful for all uses, public-safe, or approved. Provenance supports review. It shall not replace evidence review, data quality review, safeguard review, public-safe review, national routing, or lawful permission.

**36.3.6 Provenance and AI Outputs.** AI-generated or AI-assisted outputs shall preserve source references, retrieval context, model or workflow class, human review state, uncertainty, and limitations where material. AI outputs without sufficient provenance shall not be used as evidence-bearing records.

**36.3.7 Provenance Gaps.** Where provenance is incomplete, uncertain, contested, or restricted, the Data Provenance Record shall state the gap and restrict use accordingly. Unknown provenance shall not be filled by assumption.

**36.3.8 Provenance Correction.** Provenance records shall be corrected where source identity changes, permissions were misunderstood, transformations were wrong, AI outputs were ungrounded, source quality changes, or downstream outputs relied on inaccurate provenance.

**36.3.9 Data Provenance Formula.** Data provenance shall follow the formula: **trace source; record permission; document transformation; link outputs; identify gaps; restrict uncertain provenance; correct lineage errors; never treat provenance as universal approval.**

***

### 36.4 Data Custody

**36.4.1 Data Custody Principle.** **Data Custody** shall identify who holds, controls, stewards, protects, permits, restricts, transfers, deletes, seals, or archives data within Foundry. Custody shall be distinguished from ownership, authorship, access, use permission, publication permission, model-training permission, public authority authority, consent, and execution authority.

**36.4.2 Custody Roles.** Data custody roles may include data steward, source steward, national data steward, public authority data steward, community data steward, Indigenous data steward where applicable, protected knowledge steward, technical custodian, secure-room custodian, compute-to-data custodian, archive custodian, output-review custodian, and handoff custodian.

**36.4.3 Custody Record.** A Data Custody Record shall identify dataset or data object, custodian, steward, owner where applicable, jurisdiction, custody basis, permitted custody actions, prohibited custody actions, access approval process, transfer approval process, output-review process, retention rule, deletion or sealing rule, incident pathway, correction pathway, archive rule, and prohibited interpretations.

**36.4.4 Custody Without Ownership.** Custody shall not create ownership, unrestricted use rights, intellectual property rights, model-training rights, publication rights, transfer rights, public authority rights, finance-reader rights, procurement rights, consent rights, deployment rights, or execution rights. Custody is responsibility, not universal permission.

**36.4.5 Custody Transfer.** Custody transfer shall require record, authorization, classification review, data residency review, transfer review, safeguard review, public-safe review where relevant, and archive linkage. Informal sharing, email transfer, repository upload, dashboard access, or model ingestion shall not constitute lawful custody transfer.

**36.4.6 Custody and National Routing.** Country-relevant or sovereign-sensitive data custody shall respect national routing, national law, national data controls, public authority dependencies, community safeguards, Indigenous data governance where applicable, and cross-border restrictions.

**36.4.7 Custody and Handoff.** Handoff packages shall state whether any data custody transfers, remains with source steward, remains compute-to-data only, is excluded, is sealed, is deleted, or is available only under separate agreement. Handoff of a Foundry object shall not imply handoff of data custody.

**36.4.8 Custody Correction.** Custody records shall be corrected where custodian is wrong, custody basis changes, transfer occurred without record, access rights were overstated, data was copied outside custody rules, or custody is used to imply ownership or consent.

**36.4.9 Data Custody Formula.** Data custody shall follow the formula: **identify the steward; define custody actions; separate custody from ownership; transfer only by record; protect national and community rules; correct custody drift.**

***

### 36.5 Data Residency

**36.5.1 Data Residency Principle.** **Data Residency** shall govern where data may be stored, processed, backed up, replicated, cached, logged, embedded, indexed, transferred, archived, sealed, or deleted. Residency shall be determined by law, contract, national data controls, public authority conditions, data classification, community safeguards, Indigenous data sovereignty where applicable, protected knowledge rules, cyber requirements, and public-good purpose.

**36.5.2 Residency Classes.** Residency classes may include unrestricted, jurisdiction-restricted, national-only, regional-only, public authority-controlled, sovereign-compute-only, secure-room-only, compute-to-data-only, no-cross-border-transfer, no-external-model-use, no-replication, no-backup-outside-jurisdiction, archive-in-country, sealed-in-country, deletion-required, and source-steward-controlled.

**36.5.3 Residency Record.** A Data Residency Record shall identify data object, jurisdiction, residency class, storage location, processing location, backup location, logging location, model-use location where applicable, cross-border restriction, provider location, cloud region, sovereign compute requirement, archive location, transfer conditions, correction pathway, and prohibited uses.

**36.5.4 Residency Before Processing.** Residency shall be checked before data is moved into cloud, AI systems, Studio runtime, Marketplace support systems, Registry systems, dashboards, simulation environments, compute-to-data environments, clean rooms, secure rooms, edge environments, or release pipelines.

**36.5.5 Provider and Cloud Controls.** Use of provider infrastructure shall be reviewed for data location, subcontractors, support access, telemetry, logging, model retention, backups, legal access regimes, export risk, service terms, and exit options. Provider hosting shall not create public authority approval or national compliance by implication.

**36.5.6 Residency and AI.** AI workflows shall respect residency. Data shall not be sent to external models, cross-border inference services, embedding services, logging systems, or provider retention systems where residency rules prohibit such use.

**36.5.7 Residency Violations.** Storage, processing, backup, logging, indexing, embedding, model use, or transfer outside permitted residency shall be treated as a data incident requiring containment, correction, notice where required, deletion or sealing, record update, and recurrence controls.

**36.5.8 Residency Correction.** Residency records shall be corrected where law changes, provider region changes, processing location changes, backup behavior changes, logging behavior changes, model-use terms change, or data was moved contrary to residency requirements.

**36.5.9 Data Residency Formula.** Data residency shall follow the formula: **know where data lives; process only where allowed; control cloud and AI paths; restrict replication; correct unauthorized movement; never treat hosting as lawful permission.**

***

### 36.6 Data Commons and Localization

**36.6.1 Data Commons Identity.** **Data Commons** within Foundry shall mean governed public-good data structures, schemas, metadata, indicators, documentation, templates, reference datasets, open technical baselines, and shared data methods designed to improve reuse, interoperability, public-good learning, national portfolio formation, Observatory work, DRI and GRIx work, public-safe reporting, and readiness mapping.

**36.6.2 Data Commons Purpose.** Data Commons shall reduce fragmentation while preserving data rights, national ownership, localization, data classification, custody, public-safe limits, and correctionability. The commons shall not mean unrestricted data pooling, loss of sovereignty, loss of custody, compulsory sharing, extraction of protected knowledge, or public-good enclosure by private actors.

**36.6.3 Commons Classes.** Data Commons may include open schemas, controlled vocabularies, public-good indicators, metadata templates, public-safe datasets, documentation baselines, synthetic datasets, benchmark templates, data quality methods, interoperability profiles, localization profiles, National Portfolio data templates, Observatory data templates, DRI templates, GRIx context templates, and archive templates.

**36.6.4 Commons Record.** Each Data Commons object shall have a Commons Record identifying object, version, license or terms, source, data class, permitted uses, prohibited uses, localization pathway, national adaptation status, public-safe status, support status, correction pathway, archive rule, and anti-enclosure conditions.

**36.6.5 Localization Principle.** Localization shall adapt commons objects to national, regional, legal, linguistic, community, Indigenous protocol-sensitive where applicable, sectoral, infrastructure, public authority, and data availability contexts without silently forking the common rail. Localization shall preserve lineage, version, controlled vocabulary, correction links, and no-conversion language.

**36.6.6 Commons Without Enclosure.** Public-good data commons objects shall not be enclosed by providers, sponsors, enterprise actors, platforms, or proprietary systems. Enterprise use may be permitted under applicable licenses and terms, but shall not privatize the public-good baseline or prevent public-good correction.

**36.6.7 Commons Without Approval.** Inclusion in a Data Commons shall not certify data quality, approve use for all contexts, authorize public authority use, permit procurement use, create financeability, authorize AI training, grant consent, or permit deployment. Commons objects remain bounded by classification and terms.

**36.6.8 Commons Correction.** Data Commons records shall be corrected where schemas are wrong, indicators are misleading, localization fails, public-safe status changes, terms change, support lapses, or commons objects are used as certification, approval, finance, procurement, consent, deployment, or execution authority.

**36.6.9 Data Commons and Localization Formula.** Data Commons and Localization shall follow the formula: **share structure before raw data; localize with lineage; protect custody and rights; prevent enclosure; correct shared baselines; never let commons become unrestricted permission.**

***

### 36.7 Cross-Border Transfer Review

**36.7.1 Cross-Border Transfer Principle.** **Cross-Border Transfer Review** shall govern any movement, replication, access, processing, backup, logging, embedding, model inference, publication, dashboard display, handoff, or archive of data across national borders or across legally meaningful jurisdictions. Transfer review shall occur before movement where risk exists.

**36.7.2 Transfer Scope.** Cross-border transfer may include file transfer, database replication, cloud processing, cross-region backup, remote access, API access, dashboard access, AI inference, embedding generation, model training, telemetry synchronization, secure-room access, clean-room analysis, Marketplace display, Registry display, Studio runtime, public authority learning materials, finance-reader materials, insurance-reader materials, public-safe publication, and handoff packages.

**36.7.3 Transfer Review Record.** A Cross-Border Transfer Review Record shall identify data object, origin jurisdiction, destination jurisdiction, transfer type, data class, lawful basis or permission where applicable, residency rule, custody rule, recipient, processor or provider, permitted uses, prohibited uses, safeguards, output-review requirement, retention rule, onward-transfer restriction, correction pathway, archive rule, and prohibited claims.

**36.7.4 Most-Restrictive Rule.** Where multiple laws, contracts, public authority conditions, community safeguards, Indigenous protocols where applicable, data steward rules, or Foundry rules apply, the most restrictive applicable rule shall govern unless a competent lawful process resolves the conflict.

**36.7.5 Remote Access as Transfer.** Remote access may constitute transfer or exposure even if data is not downloaded. Viewing, querying, embedding, AI inference, dashboard access, or API access across borders shall be reviewed where classification requires.

**36.7.6 Cross-Border AI Controls.** Sending data to external AI models, embedding services, hosted inference, model evaluation platforms, or AI logging systems located outside the permitted jurisdiction shall be reviewed as a cross-border transfer where applicable. AI convenience shall not override transfer rules.

**36.7.7 Transfer Without Approval Overclaim.** Approval of a cross-border transfer shall not create approval for publication, AI training, Marketplace display, Registry display, public authority use, finance-reader use, procurement use, handoff, deployment, or execution. Transfer permission is purpose-specific.

**36.7.8 Transfer Incident and Correction.** Unauthorized or mistaken cross-border transfer shall trigger containment, access closure, deletion or sealing where appropriate, notice where required, public-safe review, record correction, recurrence controls, and archive.

**36.7.9 Cross-Border Transfer Formula.** Cross-border transfer shall follow the formula: **treat movement and remote access as controlled; review before transfer; apply the most restrictive rule; limit onward use; correct unauthorized movement; never let transfer permission become universal use permission.**

***

### 36.8 Retention, Deletion, Sealing, and Archive

**36.8.1 Lifecycle Principle.** **Retention, Deletion, Sealing, and Archive** shall govern how Foundry data is kept, removed, restricted, preserved, or made non-current over time. Data shall not remain active merely because storage is cheap, technically convenient, useful for future AI, or institutionally interesting. Lifecycle status shall be record-based.

**36.8.2 Retention Rule.** Data shall be retained only for recorded purpose, legal requirement, accountability, correction, reproducibility where lawful, public-safe reporting, auditability within limits, archive memory, support, or handoff dependency needs. Retention shall be proportionate to data class and risk.

**36.8.3 Deletion Rule.** Data shall be deleted where required by law, contract, data steward instruction, consent withdrawal where applicable, retention expiry, incident correction, non-continuation, support closure, or safeguard condition. Deletion shall be verified where material.

**36.8.4 Sealing Rule.** Data shall be sealed where it must be preserved for accountability, legal, public-safe, archive, correction, or institutional memory reasons but should not remain actively accessible. Sealed data shall have restricted access, future-use limits, and review conditions.

**36.8.5 Archive Rule.** Data archive shall preserve non-current data, records, provenance, correction history, public-safe status, access restrictions, and institutional memory while preventing archived data from being used as current evidence or authority without reinstatement review.

**36.8.6 Lifecycle Record.** A Data Lifecycle Record shall identify data object, retention period, legal or policy basis, active-use status, deletion trigger, sealing trigger, archive class, access restrictions, public display status, reinstatement conditions, deletion verification where applicable, correction pathway, and prohibited uses.

**36.8.7 AI and Derived Data Lifecycle.** Embeddings, model inputs, model outputs, derived datasets, cached prompts, workflow logs, synthetic data, and AI-assisted summaries shall follow retention, deletion, sealing, and archive rules. Deleting raw data may require review of derivative artifacts.

**36.8.8 No Current Authority From Archive.** Archived or sealed data shall not be used as current evidence, public-safe material, dashboard source, Marketplace support, Registry support, Studio source, readiness basis, public authority learning basis, or handoff basis unless reinstated by current review and record.

**36.8.9 Lifecycle Correction.** Lifecycle records shall be corrected where retention exceeds purpose, deletion is missed, sealing is incomplete, archive access is too broad, derivative data is forgotten, or archived data is used as current authority.

**36.8.10 Retention, Deletion, Sealing, and Archive Formula.** Data lifecycle shall follow the formula: **retain only with reason; delete when required; seal when preservation must be restricted; archive with non-current status; review before reinstatement; never let old data become current authority by inertia.**

***

### 36.9 Output Review

**36.9.1 Output Review Principle.** **Data Output Review** shall govern any output derived from data before it is exported, published, displayed, shared, synchronized, entered into Marketplace, displayed in Registry, used in Studio, included in public authority learning, used in readiness rooms, used in capital-reader or insurance-reader rooms, provided to National Portfolios, included in public-safe materials, or attached to handoff packages.

**36.9.2 Output Classes.** Data outputs may include summaries, tables, charts, dashboards, maps, indicators, model inputs, model outputs, AI summaries, embeddings, transformed datasets, aggregate datasets, public-safe reports, public notices, evidence packs, simulation outputs, benchmark outputs, readiness maps, safeguard records, Marketplace metadata, Registry status records, Studio outputs, and handoff dependency notes.

**36.9.3 Output Review Record.** An Output Review Record shall identify source data, output type, audience, purpose, data class, sensitivity class, public-safe class, aggregation level, re-identification risk, protected knowledge risk, Indigenous protocol sensitivity where applicable, public authority sensitivity, cyber sensitivity, infrastructure sensitivity, finance/procurement sensitivity, review findings, permitted release, restrictions, correction pathway, archive rule, and prohibited interpretations.

**36.9.4 Review Criteria.** Output review shall assess privacy, re-identification risk, aggregation adequacy, geospatial sensitivity, protected knowledge exposure, Indigenous-sensitive exposure where applicable, community harm, public authority confusion, cyber or infrastructure exposure, false precision, misleading visualization, stale data, unsupported inference, public-safe risk, finance or procurement implication, consent implication, deployment implication, and execution implication.

**36.9.5 Output Suppression and Redaction.** Outputs shall be redacted, aggregated, delayed, generalized, masked, restricted, suppressed, or withheld where safe release is not possible. Public-good purpose shall not justify unsafe exposure.

**36.9.6 Output Without Authority.** A reviewed output shall not create public authority decision, public warning, official classification, certification, procurement status, financeability, insurability, consent, deployment authorization, or execution authority unless a separate competent process creates that status.

**36.9.7 Output Review and AI.** AI-generated or AI-assisted outputs shall undergo output review where data sensitivity, public-safe meaning, authority boundary, readiness boundary, or handoff implications exist. AI fluency shall not substitute for review.

**36.9.8 Output Review Correction.** Output Review Records shall be corrected where released outputs expose sensitive information, understate uncertainty, misstate source data, create public authority confusion, imply consent, imply finance or procurement status, or are used as deployment or execution authority.

**36.9.9 Output Review Formula.** Output review shall follow the formula: **review before export; assess re-identification and public meaning; suppress unsafe outputs; state limits; correct releases; never let data output become decision authority.**

***

### 36.10 Data Incident Correction

**36.10.1 Data Incident Defined.** A **Data Incident** shall arise where data is accessed, used, transferred, disclosed, published, retained, deleted, sealed, classified, transformed, synchronized, modeled, embedded, exported, handed off, or archived in a manner inconsistent with Foundry classification, custody, residency, permission, safeguard, public-safe, security, retention, or lawful-use rules.

**36.10.2 Incident Categories.** Data Incidents may include unauthorized access, unauthorized transfer, cross-border transfer error, misclassification, custody breach, residency breach, output leakage, re-identification risk, raw data extraction, protected knowledge exposure, Indigenous knowledge or data protocol breach where applicable, community-sensitive exposure, health data exposure, cyber data exposure, infrastructure-sensitive exposure, public authority-sensitive exposure, AI model-use breach, retention overrun, deletion failure, sealing failure, archive exposure, and handoff misuse.

**36.10.3 Data Incident Record.** A Data Incident Record shall identify incident category, affected data, source, classification, custody, residency, affected systems, affected actors, affected jurisdictions, affected communities or rights-bearing contexts where relevant, public authority sensitivity, severity, containment actions, correction actions, notice requirements, recurrence controls, archive status, and prohibited claims.

**36.10.4 Immediate Containment.** Containment may include access closure, data sealing, transfer halt, deletion, output withdrawal, dashboard suspension, Marketplace correction, Registry correction, Studio pause, AI workflow suspension, model output withdrawal, secure-room closure, handoff recall, credential rotation, and notification where required.

**36.10.5 Correction Actions.** Data correction may include classification correction, custody correction, residency correction, provenance correction, dataset record correction, output correction, public-safe correction, access correction, deletion verification, sealing verification, archive restriction, public notice, targeted notice, retraining, policy update, and control redesign.

**36.10.6 Notice and Public Repair.** Notice shall be issued where required by law, contract, public-safe duty, national pathway, public authority sensitivity, community safeguard, Indigenous protocol where applicable, affected-user reliance, Marketplace or Registry visibility, Studio use, or handoff reliance. Public repair shall avoid exposing additional sensitive information.

**36.10.7 Non-Retaliation.** Persons reporting Data Incidents in good faith shall be protected. Correction shall not be used to suppress community concerns, Indigenous protocol concerns where applicable, public authority concerns, contributor concerns, or safeguard warnings.

**36.10.8 Data Incident Archive.** Data Incident Records shall be archived with appropriate sensitivity controls. Lessons shall feed classification, custody, residency, output review, AI workflow, secure-room, clean-room, no-download, Marketplace, Registry, Studio, National Node, and handoff improvements.

**36.10.9 Data Incident Correction Formula.** Data incident correction shall follow the formula: **contain exposure; close access; correct records; notify where required; repair public meaning; update controls; archive the lesson; never hide data incidents to protect reputation.**

***

### 36.11 Sovereign, Community-Sensitive, Indigenous, Health, Infrastructure, and Public Authority Data Controls

**36.11.1 Special Data Controls Principle.** **Special Data Controls** shall apply to data classes whose misuse may harm sovereignty, people, rights, communities, Indigenous peoples and institutions where applicable, health, infrastructure, public authority functions, national security, public safety, protected knowledge, or public trust. These controls shall apply in addition to ordinary classification, custody, residency, output review, security, and archive rules.

**36.11.2 Sovereign Data Controls.** Sovereign data shall be handled according to national law, national data controls, public authority conditions, residency restrictions, cross-border transfer rules, sovereign compute requirements, national routing, and source-steward permissions. Sovereign data shall not be moved, processed, published, modeled, or handed off outside its allowed pathway.

**36.11.3 Community-Sensitive Data Controls.** Community-sensitive data shall be handled to avoid stigma, extraction, re-identification, vulnerability exposure, local harm, political misuse, public-safe misunderstanding, or conversion of participation into consent. Community data shall be minimized, protected, contextualized, and published only where safe and permitted.

**36.11.4 Indigenous Data and Knowledge Controls.** Where Indigenous peoples, governments, institutions, territories, rights, cultural heritage, data, knowledge, protected places, or protocols are implicated, Foundry shall respect distinct legal, governance, cultural, data sovereignty, permission, attribution, access, publication, archive, and benefit-sharing considerations where applicable. Indigenous knowledge shall not be treated as general public data, general community data, or unrestricted research input.

**36.11.5 Health Data Controls.** Health-sensitive data shall be handled with privacy, confidentiality, de-identification, access, residency, ethical, public-safe, and output-review controls appropriate to its sensitivity. Health data shall not be used for AI training, public dashboards, finance-reader materials, insurance-reader materials, public authority learning, or handoff unless lawful and specifically recorded.

**36.11.6 Infrastructure Data Controls.** Infrastructure-sensitive data, including energy, water, telecom, transport, ports, cyber, compute, public safety, health infrastructure, logistics, and industrial systems data, shall be protected against vulnerability exposure, operational misuse, surveillance misuse, public panic, procurement misuse, insurance misuse, or adversarial use. Public outputs may require aggregation, masking, delay, or suppression.

**36.11.7 Public Authority Data Controls.** Public authority-sensitive data shall be handled according to the conditions set by the public authority or applicable law. Public authority data shall not be used to imply public authority approval, public warning, regulatory comfort, official classification, procurement action, public finance allocation, or emergency command.

**36.11.8 Special Data Handoff Controls.** Handoff packages involving special data classes shall identify what data is included, excluded, sealed, deleted, retained, compute-to-data-only, subject to permission, subject to public authority process, subject to community or Indigenous protocol where applicable, or subject to separate agreement. Handoff shall not transfer data rights by implication.

**36.11.9 Special Data Incident Response.** Incidents involving special data classes shall trigger heightened containment, access closure, notice review, public-safe review, national routing, safeguard review, legal review where needed, community or Indigenous protocol review where applicable, handoff recall where needed, and archive restriction.

**36.11.10 Special Data Controls Formula.** Special data controls shall follow the formula: **treat sensitive data as rights-bearing and context-bearing; restrict access; prefer compute-to-data where needed; review outputs; respect sovereignty and protocols; correct exposure; never convert special data into public claim, consent, deployment, or execution authority.**

***

### 36.12 Data Architecture Summary Clause

**36.12.1 Summary Doctrine.** Foundry Data Architecture shall ensure that all data used in Nexus Foundry is classified, recorded, provenanced, stewarded, located, localized, transferred, retained, deleted, sealed, archived, reviewed, corrected, and safeguarded according to its status, sensitivity, jurisdiction, source, public-safe meaning, and lawful-use limits. Data shall be a governed public-good input, not an unrestricted resource.

**36.12.2 Classification and Records Summary.** Data classification shall determine access, processing, output review, residency, AI use, public display, transfer, retention, and archive. Dataset Records shall preserve source, version, terms, quality, sensitivity, permissions, lineage, support, correction, and archive. Data availability shall not mean data permission.

**36.12.3 Provenance and Custody Summary.** Provenance shall trace origin, permission, transformation, lineage, and downstream use. Custody shall identify responsibility for holding and protecting data without creating ownership or unrestricted use. Custody transfer shall occur only by record.

**36.12.4 Residency and Transfer Summary.** Data residency shall determine where data may be stored, processed, backed up, logged, embedded, indexed, modeled, archived, or sealed. Cross-border transfer review shall apply to movement, remote access, AI inference, embedding, synchronization, publication, and handoff where classification requires. The most restrictive applicable rule shall govern.

**36.12.5 Commons and Localization Summary.** Data Commons shall support interoperability, shared schemas, metadata, indicators, public-good methods, and reusable public-safe structures without creating unrestricted pooling or private enclosure. Localization shall adapt data structures to national, regional, legal, linguistic, community, Indigenous protocol-sensitive where applicable, public authority, and sector contexts without silently forking the common rail.

**36.12.6 Lifecycle and Output Summary.** Retention, deletion, sealing, and archive shall prevent data from remaining active beyond purpose. Output review shall assess re-identification, protected knowledge exposure, public authority sensitivity, geospatial sensitivity, public-safe risk, finance or procurement implication, consent implication, deployment implication, and execution implication before release or handoff.

**36.12.7 Incident and Special Data Summary.** Data incidents shall be contained, corrected, noticed where required, publicly repaired where needed, and archived for learning. Sovereign, community-sensitive, Indigenous, health, infrastructure, and public authority data shall receive heightened controls, including national routing, compute-to-data preference where appropriate, output restrictions, protocol sensitivity, and handoff limitations.

**36.12.8 No-Conversion Summary.** Data classification, Dataset Records, provenance, custody, residency, commons inclusion, transfer approval, output review, public-safe release, Marketplace display, Registry presence, Studio use, public authority learning, readiness mapping, or handoff package inclusion shall not create certification, public authority approval, procurement status, financeability, insurability, consent, deployment authorization, data ownership, unrestricted data rights, or execution authority.

**36.12.9 Final Data Architecture Formula.** The controlling Foundry Data Architecture Formula is that **data must be classified before use, recorded before reliance, provenanced before evidence, stewarded before transfer, located before processing, localized without forking, transferred only by review, retained only by purpose, deleted or sealed when required, archived without current authority, output-reviewed before exposure, corrected when misused, and specially protected when sovereign, community-sensitive, Indigenous, health, infrastructure, or public authority-sensitive; data strengthens Foundry only when governed by records, safeguards, public-safe limits, national ownership, and correctionability, and never by availability alone.**

### Next steps

* Read [VIII. ARCHITECTURE](/organization/acceleration/nexus-foundry/viii.-architecture.md) to move from estate doctrine into systems design.
* Use [IX. PRODUCTION](/organization/acceleration/nexus-foundry/ix.-production.md), [X. OPERATIONS](/organization/acceleration/nexus-foundry/x.-operations.md), and [XI. PORTFOLIO](/organization/acceleration/nexus-foundry/xi.-portfolio.md) to connect infrastructure with delivery and operating practice.
* Apply delivery controls through the [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md).
* Prepare transition with [XII. EVIDENCE](/organization/acceleration/nexus-foundry/xii.-evidence.md), [XIII. READINESS](/organization/acceleration/nexus-foundry/xiii.-readiness.md), and [XVIII. HANDOFF](/organization/acceleration/nexus-foundry/xviii.-handoff.md).


---

# 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/acceleration/nexus-foundry/vii.-estate.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.