# XVII. DATA

This section defines how Nexus Acceleration classifies, governs, protects, and reviews data across research, public-safe reporting, secure compute, and lawful continuation.

It covers privacy, sovereignty, access control, secure environments, cybersecurity, AI use, dual-use safeguards, vendor risk, and technical incident correction.

It keeps data, AI, and infrastructure usable only when rights, limits, custody, review, and public-safe boundaries are recorded before movement.

### Summary

* Data must be classified, stewarded, access-controlled, and handled within recorded rights and limits.
* Privacy, sovereign data, sensitive infrastructure, and protected knowledge require stricter custody, transfer, and publication controls.
* Secure compute, clean rooms, and reviewed outputs reduce exposure while preserving analysis.
* AI use requires authorization, provenance, human review, automated claim controls, and correction paths.
* Cyber, vendor, dual-use, and publication incidents require containment, correction, archive, and renewal.

### Related pages

* [CHARTER](/organization/acceleration/charter.md)
* [XVI. SAFEGUARDS](/organization/acceleration/charter/xvi.-safeguards.md)
* [XV. AUTHORITIES](/organization/acceleration/charter/xv.-authorities.md)
* [XVIII. CLAIMS](/organization/acceleration/charter/xviii.-claims.md)
* [XIX. GOVERNANCE](/organization/acceleration/charter/xix.-governance.md)
* [XIV. FINANCE](/organization/acceleration/charter/xiv.-finance.md)

### 17.1 Data Classification

#### 17.1.1 Primary Definition of Data Classification

17.1.1.1 Data Classification means the structured, recorded, risk-based, rights-sensitive, public-safe, correctionable process by which data, datasets, records, derived outputs, logs, metadata, model inputs, observability inputs, geospatial layers, social data, public authority materials, partner-provided data, community input, Indigenous knowledge or data where applicable, protected knowledge, and other information assets used in Nexus Acceleration are assigned to appropriate handling classes before collection, receipt, access, processing, analysis, sharing, publication, retention, archive, or deletion.

17.1.1.2 Data Classification shall include, at minimum, classes for Public, Controlled Public, Internal, Restricted, Confidential, Sovereign-Sensitive, Rights-Bearing, Protected Knowledge, Indigenous-Sensitive where applicable, Public Authority-Sensitive, Infrastructure-Sensitive, Cyber-Sensitive, Health-Sensitive, Geospatial-Sensitive, Community-Sensitive, Market-Sensitive, Partner-Confidential, No-Publication, Delayed Publication, Redacted Publication, Compute-to-Data Required, and Archive-Restricted data.

17.1.1.3 Classification shall be based on source, rights, permissions, identifiability, sensitivity, legal status, jurisdiction, sovereignty, public authority relevance, community relevance, Indigenous protocol relevance where applicable, protected knowledge status, health status, cyber status, infrastructure status, geospatial precision, public safety implications, publication risk, transfer risk, partner restrictions, consent limitations, data quality, provenance, and foreseeable misuse.

17.1.1.4 Data Classification shall occur before data is used for evidence packs, observability records, AI workflows, digital twins, simulations, dashboards, public authority learning records, readiness notes, public-safe reports, public-interest records, Docket items, Nexus Universe outputs, Nexus Rail routing, Handoff Dependency Notes, repositories, or public communications.

17.1.1.5 Where classification is uncertain, the data shall be treated under the more restrictive classification until a competent steward, safeguard reviewer, data reviewer, public authority boundary reviewer, Indigenous protocol reviewer where applicable, legal reviewer, or other appropriate review pathway determines otherwise.

17.1.1.6 Data Classification is the first control that prevents public-good acceleration from becoming unlawful use, unsafe disclosure, extraction, overclaim, or public harm.

***

#### 17.1.2 Data Handling Requirements

17.1.2.1 Data Handling Requirements mean the mandatory rules governing data collection, receipt, intake, storage, access, transfer, processing, compute-to-data use, AI use, analysis, sharing, publication, retention, deletion, return, archive, correction, and incident response across Nexus Acceleration.

17.1.2.2 Data shall be handled only for a recorded public-good purpose, lawful purpose, research purpose, observability purpose, evidence purpose, public authority learning purpose, safeguard purpose, readiness translation purpose, public-safe reporting purpose, routing purpose, archive purpose, or lawful continuation purpose consistent with the data source, rights, permissions, classification, safeguards, and applicable law.

17.1.2.3 Data Handling Requirements shall address source authority, lawful basis where required, consent or permission where required, data minimization, collection limits, access control, storage location, encryption where appropriate, transfer controls, compute-to-data controls, no-download controls where required, logging, monitoring, retention, deletion, return, archive, publication class, public-safe review, and correction pathway.

17.1.2.4 Data shall not be collected, copied, combined, enriched, modeled, mapped, published, shared, transferred, exported, uploaded, used in AI systems, used in readiness notes, routed to public authority learning, routed to handoff materials, or released to partners unless such use is consistent with classification, permitted use, safeguard controls, jurisdictional limits, and public-safe boundaries.

17.1.2.5 Data Handling shall distinguish raw data, derived data, aggregated data, anonymized data, synthetic data, metadata, logs, model outputs, public-safe summaries, restricted outputs, and archive materials. A less sensitive form shall not be assumed safe merely because it is derived, summarized, anonymized, aggregated, synthetic, or transformed.

17.1.2.6 Data Handling Requirements shall apply equally to temporary Nexus Universe stacks, partner-provided environments, public authority learning rooms, cloud systems, sovereign compute, secure enclaves, clean rooms, repositories, dashboards, digital twins, simulations, and National Node environments.

17.1.2.7 Data Handling makes data useful only by keeping its use lawful, bounded, reviewable, and safe.

***

#### 17.1.3 Access Control Requirements

17.1.3.1 Access Control Requirements mean the mandatory rules for granting, limiting, logging, reviewing, revoking, and separating access to data, systems, repositories, dashboards, secure rooms, clean rooms, cloud environments, compute environments, public authority records, partner data, community records, protected knowledge, and restricted outputs.

17.1.3.2 Access shall be based on least privilege, need-to-know, role-based permissions, purpose limitation, time-bound access, classification, safeguard requirements, jurisdictional restrictions, participant role, conflict status, and review status.

17.1.3.3 Access controls shall distinguish researchers, GCRI reviewers, GRF claims and public-safe reviewers, GRA readiness reviewers, National Node stewards, National Working Group participants, Competence Cell contributors, public authority learners, community participants, Indigenous participants where applicable, partners, sponsors, providers, technical mentors, partner engineers, volunteers, media actors, capital readers, insurers, donors, public finance readers, and handoff actors.

17.1.3.4 Restricted data shall not be accessible to sponsors, providers, capital readers, insurers, donors, media actors, public finance readers, public authority participants, volunteers, or other participants merely because they are present in a Nexus activity, support a Nexus pathway, contribute infrastructure, or participate in Nexus Universe.

17.1.3.5 Access permissions shall be recorded with user identity or role, authority basis, data class, permitted use, systems accessed, start date, end date, steward, approval pathway, logging requirements, confidentiality conditions, export restrictions, no-download rules where applicable, and revocation conditions.

17.1.3.6 Access shall be reviewed periodically and revoked when the purpose ends, participant role changes, risk changes, conflict arises, agreement expires, incident occurs, public-safe class changes, or continued access is no longer lawful, necessary, or appropriate.

17.1.3.7 Access logs shall be preserved according to classification and retention rules and shall be available for incident review, correction, audit-support, access closure, and archive.

17.1.3.8 Access control preserves the public-good firewall between contribution, participation, review, public authority learning, finance-readiness, and lawful data use.

***

#### 17.1.4 Data Retention Rules

17.1.4.1 Data Retention Rules mean the rules governing how long datasets, derived outputs, metadata, logs, evidence records, public-safe summaries, compute-use records, model cards, system cards, public authority learning records, safeguard records, partner-provided data, community records, Indigenous-sensitive records where applicable, readiness records, archive records, and correction records may be retained.

17.1.4.2 Retention shall be based on lawful basis, source permission, agreement terms, research need, evidence need, audit-support need, public-safe reporting need, correctionability need, archive value, public authority boundary requirements, partner restrictions, data subject rights where applicable, community safeguards, Indigenous protocols where applicable, public safety considerations, and classification.

17.1.4.3 Raw data shall not be retained longer than necessary for the authorized purpose unless lawful retention, evidence integrity, archive, correctionability, or agreement terms justify retention under appropriate controls.

17.1.4.4 Derived outputs shall be separately classified and retained according to their own sensitivity, provenance, reproducibility value, publication status, correction value, and potential for reidentification, misuse, public authority overclaim, finance overclaim, or protected knowledge exposure.

17.1.4.5 Logs, access records, compute-use records, data handling records, correction logs, incident records, and archive records may be retained where necessary to prove lawful handling, support correction, preserve institutional memory, or investigate incidents, subject to access limits and legal constraints.

17.1.4.6 Partner-provided data, public authority data, community-sensitive data, Indigenous-sensitive data where applicable, health-sensitive data, cyber-sensitive data, and geospatial-sensitive data shall follow the most restrictive applicable retention requirement, including deletion, return, archive restriction, or no-retention rules where required.

17.1.4.7 Retention rules shall be documented in Dataset Records and reviewed when agreements, laws, classifications, risks, public-safe status, or continuation pathways change.

17.1.4.8 Data Retention Rules preserve memory without turning temporary access into permanent possession.

***

#### 17.1.5 Data Deletion and Return Rules

17.1.5.1 Data Deletion and Return Rules mean the mandatory rules requiring deletion, return, destruction, access closure, de-identification, withdrawal, or restricted archive of data where authorized use has ended, access has been revoked, an agreement requires return, public-safe risk has changed, classification has changed, consent or permission has been withdrawn where applicable, retention is no longer lawful or necessary, an incident requires containment, or a steward determines that continued possession creates unacceptable risk.

17.1.5.2 Deletion or return shall apply to raw data, copied data, working files, temporary files, exports, downloads, cache files, logs where deletion is lawful and appropriate, derived datasets where required, partner data, public authority data, community data, Indigenous-sensitive data where applicable, protected knowledge, health-sensitive data, cyber-sensitive data, geospatial-sensitive data, and AI workflow materials.

17.1.5.3 Deletion and return shall be recorded with dataset identity, location, custodian, steward, deletion or return reason, method, date, systems affected, residual copies, derived outputs, archive status, verification method, exceptions, and correction pathway.

17.1.5.4 Where complete deletion is not technically or legally possible because of backups, logs, legal holds, audit records, archive obligations, or correction records, the residual material shall be restricted, access-controlled, retention-limited, and identified in the deletion or return record.

17.1.5.5 Returned data shall not be retained, reused, summarized, modeled, published, or routed unless the applicable agreement, permission, classification, and public-safe review permit such use.

17.1.5.6 Deletion and return shall include access closure, credential revocation, link removal, repository restriction, dashboard withdrawal, compute environment closure, cloud bucket closure, and confirmation that partner engineers, mentors, volunteers, researchers, reviewers, and other participants no longer retain unauthorized access.

17.1.5.7 Data Deletion and Return Rules ensure that Nexus Acceleration does not keep data merely because it once had access.

***

#### 17.1.6 Data Archive Rules

17.1.6.1 Data Archive Rules mean the rules governing preservation of selected datasets, metadata, evidence records, access logs, derived outputs, correction records, restricted data, data handling records, public-safe outputs, Data Handling Notes, Compute-Use Records, Dataset Records, model and system cards, public authority learning records, safeguard records, and institutional memory under appropriate classification.

17.1.6.2 Archive may be used where preservation is necessary for evidence integrity, reproducibility, correctionability, public-safe reporting history, legal or agreement obligations, incident review, institutional memory, National Node continuity, Nexus Universe cycle learning, public authority learning continuity, or future lawful review.

17.1.6.3 Archive shall not mean public release. Archive may be public, controlled, restricted, confidential, sovereign-sensitive, no-publication, protected knowledge, Indigenous-sensitive where applicable, public authority-sensitive, cyber-sensitive, health-sensitive, geospatial-sensitive, partner-confidential, or archive-restricted.

17.1.6.4 Archive records shall identify source, rights, classification, steward, custodian, storage location, access conditions, permitted uses, prohibited uses, retention period, deletion or review date, correction links, supersession status, withdrawal status, legal hold status where applicable, and public-safe publication status.

17.1.6.5 Sensitive archived materials shall be protected through access controls, encryption where appropriate, restricted repositories, clean rooms, no-download rules where needed, audit logs, role separation, and periodic review.

17.1.6.6 Archive shall preserve correction history, supersession history, withdrawal history, and incident history so that future users do not rely on outdated, withdrawn, unsafe, or superseded data.

17.1.6.7 Data Archive Rules allow institutional memory without converting restricted data into open institutional property.

***

#### 17.1.7 Data Stewardship

17.1.7.1 Data Stewardship means the assigned responsibility for data classification, lawful use, rights review, access control, custody oversight, safeguard compliance, data quality, provenance, correction, retention, deletion, return, archive, publication review, incident response, and public-safe boundary discipline across Nexus Acceleration.

17.1.7.2 Each dataset or data pathway shall have a designated data steward or stewardship pathway responsible for ensuring that data is classified, Dataset Records are maintained, access is controlled, permitted uses are respected, retention is managed, deletion or return occurs where required, archive is classified, and publication is public-safe.

17.1.7.3 Data stewards shall coordinate with GCRI where evidence, methods, technical records, compute, AI, software, observability, digital twin, simulation, cyber, geospatial, or data handling matters arise; with GRF where public-safe publication, claims, public narrative, community meaning, or public authority boundary language is involved; with GRA where readiness, finance-facing, insurance-facing, donor-facing, public finance, SPV-readiness, or handoff materials use data; and with National Nodes where national routing, sovereignty, local law, public authority, or community safeguards arise.

17.1.7.4 Data stewards shall ensure that data is not used beyond permitted purpose, not transferred beyond permitted boundaries, not published beyond public-safe classification, not routed to unauthorized actors, and not retained beyond lawful or necessary limits.

17.1.7.5 Data stewards shall maintain correction pathways for errors in classification, provenance, quality, rights, sensitivity, permitted use, public-safe status, access logs, derived outputs, and Dataset Records.

17.1.7.6 Data Stewardship may require stop-the-line action where data use creates privacy risk, protected knowledge exposure, public authority overclaim, public safety risk, cyber risk, geospatial risk, Indigenous safeguard concern where applicable, unlawful transfer risk, sponsor/provider misuse, readiness overclaim, or publication risk.

17.1.7.7 Data Stewardship is the accountable human and institutional discipline that prevents data from moving without responsibility.

***

#### 17.1.8 Data Custody

17.1.8.1 Data Custody means the recorded control, possession, hosting, storage, processing, or operational arrangement for data used in Nexus Acceleration, including the host, steward, owner where known, controller where applicable, processor where applicable, custodian, permitted users, storage location, jurisdiction, compute environment, access conditions, transfer conditions, security conditions, and closure conditions.

17.1.8.2 Data Custody may rest with GCRI, a National Node, a university, public authority, partner, cloud provider, secure-room provider, data platform, research institution, community institution, Indigenous institution where applicable, National Consortium Company, Project SPV, or other lawful custodian, provided that custody is recorded and role-separated.

17.1.8.3 Custody shall not imply ownership, unrestricted use, public release rights, publication permission, transfer rights, AI training rights, finance-readiness use rights, public authority use rights, or handoff rights. Custody is a control arrangement, not a rights expansion.

17.1.8.4 Data Custody records shall identify custody holder, storage environment, jurisdiction, security controls, access conditions, permitted processing, prohibited processing, data transfer restrictions, compute-to-data requirements, retention obligations, deletion or return obligations, archive classification, and incident responsibilities.

17.1.8.5 Where data is hosted in partner infrastructure, cloud environments, secure enclaves, confidential computing environments, clean rooms, or temporary Nexus Universe stacks, custody records shall identify account structure, administrator rights, partner engineer access, logs, data exposure, data export controls, teardown obligations, credential closure, and post-cycle data closure.

17.1.8.6 Custody shall be reviewed when data moves, roles change, hosting changes, agreements change, access expands, classification changes, public-safe status changes, or a handoff pathway is considered.

17.1.8.7 Data Custody makes visible who holds data, where it sits, who may touch it, and how it must close.

***

#### 17.1.9 Dataset Records

17.1.9.1 Dataset Records shall be required for datasets and material data collections used in Nexus Acceleration, including research datasets, observability datasets, geospatial datasets, public authority datasets, partner-provided datasets, community-derived datasets, Indigenous-sensitive datasets where applicable, health-sensitive datasets, cyber datasets, infrastructure datasets, social datasets, simulation inputs, digital twin inputs, AI evaluation datasets, benchmark datasets, logs, and derived datasets where relevant.

17.1.9.2 Each Dataset Record shall include source, source authority, rights, permissions, restrictions, consent or lawful basis where required, data owner or controller where known, steward, custodian, provenance, collection method, receipt date, version, format, classification, sensitivity, jurisdiction, sovereignty considerations, data quality, completeness, bias, limitations, permitted use, prohibited use, access conditions, transfer limits, compute-to-data requirements, retention period, deletion or return requirements, archive class, publication class, public-safe limits, correction pathway, and incident pathway.

17.1.9.3 Dataset Records shall identify whether the dataset includes personal data, rights-bearing data, health-sensitive data, sensitive social data, sensitive geospatial data, public authority-sensitive data, infrastructure-sensitive data, cyber-sensitive data, protected knowledge, Indigenous-sensitive information where applicable, partner-confidential information, market-sensitive information, or no-publication materials.

17.1.9.4 Dataset Records shall identify downstream use limits, including whether the dataset may be used for AI training, AI evaluation, modeling, simulation, digital twins, benchmarking, public-safe summaries, readiness notes, public authority learning, publication, repository release, Docket items, Nexus Rail routing, or handoff packages.

17.1.9.5 Dataset Records shall be updated when data is corrected, supplemented, restricted, reclassified, derived, aggregated, anonymized, published, withdrawn, deleted, returned, archived, superseded, or involved in an incident.

17.1.9.6 Dataset Records shall be sufficient for bounded interpretation, reproducibility review where appropriate, public-safe review, access review, safeguard review, readiness review, routing, archive, deletion, and future correction.

17.1.9.7 Dataset Records are the memory and control surface for lawful data use.

***

#### 17.1.10 Data Classification Summary Clause

17.1.10.1 Data may support Nexus Acceleration only when it is classified, stewarded, access-controlled, lawfully handled, custody-recorded, retention-managed, deletion-ready, archive-governed, correctionable, and public-safe.

17.1.10.2 Data Classification assigns data to public, controlled, restricted, confidential, sovereign-sensitive, rights-bearing, protected knowledge, public authority-sensitive, infrastructure-sensitive, cyber-sensitive, health-sensitive, geospatial-sensitive, or no-publication classes. Data Handling Requirements govern collection, receipt, storage, access, transfer, processing, compute-to-data use, sharing, publication, retention, deletion, archive, and correction. Access Control Requirements require least privilege, need-to-know, role-based access, time-bound permissions, logging, review, revocation, and separation between researchers, partners, public authorities, volunteers, reviewers, and communities. Data Retention Rules govern datasets, derived outputs, logs, evidence records, public-safe summaries, compute-use records, model and system cards, public authority learning records, safeguard records, and partner-provided data. Data Deletion and Return Rules apply where authorized use has ended, access has been revoked, agreements require return, public-safe risk has changed, or retention is no longer lawful or necessary. Data Archive Rules preserve selected datasets, metadata, evidence records, access logs, derived outputs, correction records, restricted data, and institutional memory under appropriate classification. Data Stewardship assigns responsibility for classification, access, lawful use, safeguard compliance, correction, retention, deletion, archive, and public-safe publication review. Data Custody records control, possession, hosting, steward, owner, processor, permitted users, storage location, and access conditions. Dataset Records include source, rights, permissions, sensitivity, steward, custody, provenance, quality, limitations, permitted use, retention, deletion, publication class, and correction pathway.

17.1.10.3 No Data Classification record, Data Handling record, Access Control record, Data Retention record, Deletion record, Return record, Archive record, Data Stewardship action, Data Custody record, Dataset Record, data source, dataset, derived output, log, metadata, evidence record, public-safe summary, compute-use record, model card, system card, observability record, public authority learning record, safeguard record, readiness note, Docket item, ARL status, Nexus Rail routing, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Handoff Dependency Note, public communication, correction notice, withdrawal notice, restricted archive, or dataset publication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, standards conformance, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.1.10.4 The controlling Data Classification Formula is that data may be received, classified, stewarded, accessed, processed, retained, deleted, archived, corrected, and used to support evidence; but access is not ownership, custody is not permission, classification is not publication, retention is not entitlement, deletion is not erasure of accountability, archive is not open release, dataset records are not validation, public-safe summaries are not unrestricted disclosure, and Nexus Acceleration shall treat data as usable only when its rights, risks, limits, and safeguards are recorded before movement.

### 17.2 Privacy, Rights-Bearing Data, Health-Sensitive Data, Infrastructure-Sensitive Data, Public Authority Data, Community-Sensitive Data, Protected Knowledge Data, and Sensitive Operational Data

#### 17.2.1 Privacy Scope

17.2.1.1 Privacy Scope means the full set of privacy, confidentiality, identifiability, data protection, access, publication, correction, retention, deletion, archive, and safeguard obligations applicable to personal information, identifiable data, pseudonymous data, sensitive data, participant information, researcher data, volunteer data, community data, public authority data, partner data, user data, access records, derived analytical outputs, inferred attributes, model outputs, dashboards, geospatial outputs, public-safe summaries, and any other information that may relate to or affect a person, household, group, community, organization, public authority, or rights-bearing context.

17.2.1.2 Privacy Scope shall apply to data collected, received, observed, inferred, generated, processed, analyzed, stored, transferred, published, summarized, archived, deleted, returned, or routed through Nexus Acceleration, Nexus Universe, Nexus Network, National Nexus Nodes, National Working Groups, Nexus Competence Cells, public authority learning rooms, community participation pathways, readiness reviews, Docket pathways, Nexus Rail routing, GCRI-supported technical work, GRF-supported public-safe review, GRA-supported readiness review, and lawful handoff dependency mapping.

17.2.1.3 Privacy Scope shall include personal identifiers, contact information, demographic information, location information, health information, participation records, accessibility records, community-risk records, interview data, survey data, workshop data, employment or affiliation data, researcher and volunteer data, user activity data, room access logs, platform logs, system logs, public authority participant information, media participation information, correction request information, and protected participation records.

17.2.1.4 Privacy Scope shall also apply to pseudonymous, aggregated, anonymized, synthetic, derived, modeled, inferred, or transformed outputs where reidentification, sensitive inference, small-population exposure, community identification, public authority sensitivity, participant harm, protected knowledge exposure, or public-safe misinterpretation remains possible.

17.2.1.5 Privacy controls shall be applied before public-safe publication, readiness translation, public authority learning use, dashboard release, map release, repository release, media use, sponsor or provider reference, partner communication, donor or public finance reference, or handoff package inclusion.

17.2.1.6 Privacy Scope confirms that privacy protection is not limited to raw personal data; it extends to the ways data, context, inference, participation, and publication can affect people and communities.

***

#### 17.2.2 Rights-Bearing Data

17.2.2.1 Rights-Bearing Data means data connected to individuals, communities, Indigenous peoples where applicable, vulnerable groups, workers, patients, students, residents, affected stakeholders, service users, displaced persons, persons with disabilities, youth, elders, public authority personnel, public-interest participants, research participants, or other rights-protected contexts requiring heightened care because misuse, disclosure, inference, classification, routing, or publication may affect rights, dignity, safety, access, equality, trust, participation, or legal interests.

17.2.2.2 Rights-Bearing Data may include personal data, sensitive personal data, health data, demographic data, disability data, gender data, ethnicity or race data where lawful and relevant, migration data, household data, livelihood data, education data, employment data, service-access data, mobility data, location data, participation records, correction requests, public authority learning inputs, community-sensitive data, Indigenous-sensitive data where applicable, protected knowledge records, and derived outputs capable of affecting people or groups.

17.2.2.3 Rights-Bearing Data shall be classified, minimized, purpose-limited, access-controlled, retention-managed, publication-limited, correctionable, and reviewed for lawful basis, safeguard requirements, public-safe use, and potential adverse effects before use.

17.2.2.4 Rights-Bearing Data shall not be used to profile, rank, target, surveil, stigmatize, exclude, exploit, tokenize, market to, finance against, insure against, procure against, or make unsupported claims about individuals, communities, workers, patients, students, residents, vulnerable groups, Indigenous peoples where applicable, or affected stakeholders.

17.2.2.5 Rights-Bearing Data used in AI workflows, observability, digital twins, simulations, public authority learning, readiness notes, insurance-readiness, donor-readiness, public finance relevance, public-safe reports, or handoff dependency records shall be subject to heightened review for bias, inference risk, reidentification risk, consent boundaries, representation boundaries, public authority boundaries, public-safe publication limits, and correction pathways.

17.2.2.6 Rights-Bearing Data shall be handled as data attached to people and rights, not merely as material for analysis.

***

#### 17.2.3 Health-Sensitive Data

17.2.3.1 Health-Sensitive Data means personal health information, public health data, health system data, epidemiological data, health vulnerability records, health facility data, patient-related data, health workforce data, health service access data, disease-risk data, environmental health data, mental health-sensitive data, disability-related health data, emergency health data, health-related WEFH-B outputs, and any derived or inferred data that may reveal, affect, or be interpreted as health-related information about individuals, households, communities, facilities, populations, or systems.

17.2.3.2 Health-Sensitive Data shall be treated as a heightened class requiring lawful basis, source authority, access limitation, data minimization, purpose limitation, retention discipline, publication controls, ethics or institutional review where applicable, privacy review, public-safe review, and safeguard review.

17.2.3.3 Health-Sensitive Data shall not be published, mapped, modeled, visualized, routed, or summarized in a manner that identifies individuals, stigmatizes communities, exposes health facilities, reveals small-population vulnerabilities, creates public panic, creates false reassurance, misstates public health risk, or is confused with official public health guidance or public authority decision-making.

17.2.3.4 Health-Sensitive Data used in WEFH-B systems acceleration, disaster risk intelligence, public authority learning, digital twins, simulations, readiness notes, public finance relevance notes, insurance-readiness questions, or public-safe reports shall include limitations, uncertainty, public authority boundaries, health authority boundaries, public-safe publication limits, and correction triggers.

17.2.3.5 Health-Sensitive Data involving public authorities, hospitals, clinics, emergency medical services, public health agencies, health ministries, community health organizations, or humanitarian actors shall comply with applicable institutional review, legal constraints, confidentiality requirements, public authority boundaries, and public-safe release controls.

17.2.3.6 Health-Sensitive Data shall not create diagnosis, public health determination, official health warning, health system rating, clinical recommendation, public authority approval, funding recommendation, insurance conclusion, or deployment authorization by implication.

17.2.3.7 Health-Sensitive Data may support learning only when health privacy, public safety, institutional review, and public-safe interpretation are protected.

***

#### 17.2.4 Infrastructure-Sensitive Data

17.2.4.1 Infrastructure-Sensitive Data means data concerning critical infrastructure, network topology, cyber vulnerabilities, power systems, water systems, telecom systems, transport systems, health facilities, ports, logistics, food systems, fuel systems, industrial systems, cyber-physical assets, operational technology, public safety systems, emergency communications, energy interconnections, sensor networks, control systems, building systems, cloud architecture, data centers, edge deployments, and other infrastructure whose disclosure, misuse, mapping, or analysis could create security, public safety, operational, cyber, market, or public authority risk.

17.2.4.2 Infrastructure-Sensitive Data may include locations, configurations, dependencies, failure modes, capacity, vulnerabilities, incident reports, outage information, stress test outputs, simulation outputs, digital twin layers, telemetry, maintenance status, access points, routing information, network diagrams, vendor configurations, security controls, and interdependency maps.

17.2.4.3 Infrastructure-Sensitive Data shall be subject to access controls, least privilege, need-to-know review, cyber review, public safety review, sensitive geospatial review, public authority boundary review, partner confidentiality review where relevant, publication controls, and secure archive rules.

17.2.4.4 Infrastructure-Sensitive Data shall not be publicly released at a level of detail that could expose vulnerabilities, facilitate disruption, enable targeting, reveal security weaknesses, identify critical dependencies, create panic, create false reassurance, compromise public authorities, or harm infrastructure operators or communities.

17.2.4.5 Infrastructure-Sensitive Data used in digital twins, simulations, cyber ranges, observability records, public authority learning, readiness notes, public-safe reports, Nexus Universe demonstrations, or handoff dependency records shall be redacted, aggregated, generalized, delayed, restricted, or withheld where needed.

17.2.4.6 Infrastructure-Sensitive Data shall not create security certification, resilience certification, operational approval, public authority approval, procurement preference, vendor validation, deployment authorization, emergency command, public warning, or financeability by implication.

17.2.4.7 Infrastructure-Sensitive Data may strengthen resilience learning only if it does not expose the systems it is intended to help protect.

***

#### 17.2.5 Public Authority Data

17.2.5.1 Public Authority Data means data received from, generated with, concerning, or materially involving public authorities, public agencies, regulators, municipalities, ministries, state or provincial bodies, federal or national bodies, Tribal or Indigenous governments where applicable, public-sector institutions, public utilities, public finance bodies, emergency management bodies, public health bodies, public safety bodies, public procurement bodies, and other competent public institutions.

17.2.5.2 Public Authority Data shall be handled according to legal authority, source conditions, non-confidential use limits, confidentiality requirements, public records considerations, public authority procedure, public-safe classification, public authority boundary language, retention conditions, disclosure restrictions, and non-decision boundaries.

17.2.5.3 Public Authority Data shall be classified before use as public, controlled public, restricted, confidential, public authority-sensitive, procurement-sensitive, public finance-sensitive, public safety-sensitive, cyber-sensitive, health-sensitive, infrastructure-sensitive, sovereign-sensitive, no-publication, or other appropriate class.

17.2.5.4 Public Authority Data received for learning purposes shall not be used to imply official position, public authority approval, regulatory decision, procurement status, public finance allocation, funding commitment, official warning, emergency command, legal authorization, or public authority endorsement.

17.2.5.5 Non-confidential use cases received from public authorities shall remain bounded by their stated purpose. If public authority input contains confidential, restricted, procurement-sensitive, public safety-sensitive, classified, security-sensitive, or otherwise restricted information, it shall be paused, restricted, returned, redacted, or routed through lawful and competent channels as required.

17.2.5.6 Public Authority Data shall not be disclosed to sponsors, providers, capital readers, insurers, donors, public finance readers, media actors, researchers, volunteers, communities, or partners beyond the authorized access class and purpose.

17.2.5.7 Public Authority Data may support public authority learning only where Nexus remains non-decisional and the competent public authority remains the sole source of official action.

***

#### 17.2.6 Community-Sensitive Data

17.2.6.1 Community-Sensitive Data means data about local vulnerabilities, informal systems, lived-risk knowledge, demographic sensitivity, community assets, protected locations, social conditions, service gaps, local infrastructure dependencies, public trust, community safety, health vulnerability, livelihood risk, accessibility barriers, displacement, housing, mobility, community participation, correction requests, protected participation, or other community context requiring careful handling.

17.2.6.2 Community-Sensitive Data may arise from community participation, workshops, interviews, surveys, public-interest feedback, local institutions, public authority learning, observability, public datasets, humanitarian data, maps, social media, research studies, partner data, or derived analysis.

17.2.6.3 Community-Sensitive Data shall be handled with non-extraction discipline, representation boundaries, consent boundaries, participation protection, access controls, public-safe classification, sensitive social data review, sensitive geospatial review where relevant, and correction pathways.

17.2.6.4 Community-Sensitive Data shall not be used to stigmatize communities, expose vulnerability, identify informal support systems, reveal protected places, create public panic, create false reassurance, imply community consent, support sponsor or provider marketing, support procurement advantage, or convert vulnerability into finance-facing narratives without safeguards.

17.2.6.5 Community-Sensitive Data shall be anonymized, aggregated, paraphrased, generalized, redacted, delayed, restricted, or withheld where direct use could create harm, exposure, retaliation, misinterpretation, extraction, or consent overclaim.

17.2.6.6 Community-Sensitive Data used in public-safe reports, readiness notes, public authority learning records, donor-readiness notes, public finance relevance notes, insurance-readiness question maps, or Handoff Dependency Notes shall state limitations, safeguard dependencies, representation boundaries, consent boundaries, and prohibited claims.

17.2.6.7 Community-Sensitive Data belongs within a safeguard architecture before it belongs in any output.

***

#### 17.2.7 Protected Knowledge Data

17.2.7.1 Protected Knowledge Data means data, records, notes, maps, stories, ecological information, cultural information, Indigenous knowledge where applicable, sacred or sensitive site information, protected community knowledge, security-sensitive knowledge, non-public local context, heritage information, oral histories, traditional practices, community-held methods, biodiversity knowledge, land and water knowledge, or other knowledge requiring controlled handling, restricted access, publication limits, attribution boundaries, consent or protocol conditions, and non-extraction discipline.

17.2.7.2 Protected Knowledge Data shall not be treated as ordinary data, open data, public-domain context, research material, AI training material, model input, geospatial layer, dashboard content, public-safe narrative, donor relevance, public finance relevance, finance-readiness input, public authority learning material, or handoff support unless its use is specifically permitted under applicable safeguards.

17.2.7.3 Protected Knowledge Data shall be classified at the point of intake or discovery and shall be subject to Protected Knowledge Review, Indigenous Data and Knowledge Safeguards where applicable, nation-specific or community-specific protocols where applicable, sensitive geospatial review where relevant, access restrictions, publication controls, and archive restrictions.

17.2.7.4 Protected Knowledge Data may require no-publication classification, restricted archive, community review, Indigenous protocol review where applicable, redaction, aggregation, paraphrase, delayed release, access logging, compute-to-data controls, no-download controls, return, deletion, or exclusion from derived outputs.

17.2.7.5 Protected Knowledge Data shall not be used in sponsor materials, provider materials, public media, finance-readiness, public finance relevance, donor-readiness, procurement materials, public authority materials, or handoff packages in a manner that extracts legitimacy, exposes knowledge, implies consent, or creates external benefit without safeguards and lawful permission where required.

17.2.7.6 Misuse, exposure, misclassification, or unauthorized publication of Protected Knowledge Data shall be treated as a high-priority safeguard incident requiring pause, restriction, correction, review, repair, and archive.

17.2.7.7 Protected Knowledge Data remains protected even when it is useful.

***

#### 17.2.8 Sensitive Operational Data

17.2.8.1 Sensitive Operational Data means access logs, credentials, secrets, keys, tokens, system configurations, security telemetry, incident reports, vulnerability reports, room access records, participant access records, infrastructure configurations, cloud settings, repository permissions, network diagrams, monitoring data, audit logs, build logs, deployment logs, teardown records, data-room logs, secure-room logs, compute-use logs, partner engineer access records, and live operations records.

17.2.8.2 Sensitive Operational Data shall be classified, access-controlled, retained according to operational, legal, security, incident, correction, and archive needs, and protected against unauthorized access, disclosure, publication, export, copying, or reuse.

17.2.8.3 Credentials, secrets, keys, tokens, and privileged access information shall never be included in public materials, general evidence records, public-safe reports, readiness notes, partner materials, sponsor materials, provider materials, media materials, public authority learning records, or handoff packages.

17.2.8.4 Operational logs and security telemetry may support incident review, access closure, audit-support, compute-use records, evidence integrity, cyber review, and correction, but shall not be disclosed beyond need-to-know access and applicable classification.

17.2.8.5 Sensitive Operational Data shall be subject to secure development controls, repository security, least privilege, credential rotation, secret scanning, access logging, incident response, vulnerability disclosure controls, and post-cycle teardown requirements.

17.2.8.6 Sensitive Operational Data involving partner infrastructure, temporary Nexus Universe stacks, cloud accounts, secure rooms, clean rooms, public authority rooms, data rooms, or National Node environments shall include custody records, access records, closure records, and incident responsibilities.

17.2.8.7 Sensitive Operational Data protects the machinery of Nexus Acceleration and shall not be converted into public evidence unless safely summarized and reviewed.

***

#### 17.2.9 Privacy and Sensitive Data Incident

17.2.9.1 Privacy and Sensitive Data Incident means any actual, suspected, or potential event involving unauthorized access, exposure, disclosure, misuse, overcollection, excessive retention, unlawful retention, unlawful transfer, unsafe publication, reidentification, sensitive inference, misclassification, loss, alteration, deletion failure, access control failure, credential exposure, rights-bearing data misuse, health-sensitive data misuse, infrastructure-sensitive data exposure, public authority data misuse, community-sensitive data misuse, protected knowledge exposure, or sensitive operational data compromise.

17.2.9.2 Privacy and Sensitive Data Incidents may involve raw data, derived outputs, anonymized or aggregated data with reidentification risk, public-safe summaries, dashboards, maps, AI outputs, digital twin outputs, simulations, logs, repositories, data rooms, cloud systems, secure rooms, partner environments, public authority learning materials, readiness notes, Handoff Packages, public communications, sponsor or provider materials, media materials, or archive records.

17.2.9.3 Incident intake shall identify affected data, classification, source, custodian, steward, affected persons or communities where known and safe, affected public authority where relevant, affected system, access pathway, exposure scope, public-safe risk, legal risk, rights risk, safeguard risk, reidentification risk, sensitive inference risk, publication status, containment action, notice obligations, correction pathway, and archive status.

17.2.9.4 Response measures may include access suspension, credential rotation, data quarantine, deletion, return, repository restriction, dashboard suspension, map withdrawal, public-safe report withdrawal, publication hold, redaction, correction, legal review, privacy review, cyber review, public authority notice where appropriate, participant notice where appropriate, community notice where appropriate, Indigenous notice where applicable, sponsor/provider correction, public repair where required, and archive.

17.2.9.5 Reidentification or sensitive inference risk shall be treated as a data incident where an output that appears anonymized, aggregated, synthetic, modeled, or summarized may reasonably reveal, infer, expose, stigmatize, or target individuals, communities, facilities, protected sites, or vulnerable groups.

17.2.9.6 Privacy and Sensitive Data Incidents shall not be minimized because no raw dataset was released if derived outputs, maps, models, summaries, or public materials created meaningful exposure or inference risk.

17.2.9.7 Privacy and Sensitive Data Incidents require containment first, explanation second, correction always, and renewal after review.

***

#### 17.2.10 Privacy and Sensitive Data Summary Clause

17.2.10.1 Privacy and sensitive data controls are not administrative overhead; they are core conditions for lawful, ethical, trustworthy, rights-sensitive, safeguard-aware, and public-good acceleration.

17.2.10.2 Privacy Scope covers personal information, identifiable data, pseudonymous data, sensitive data, participant information, researcher data, volunteer data, community data, public authority data, and derived analytical outputs. Rights-Bearing Data is data connected to individuals, communities, Indigenous peoples, vulnerable groups, workers, patients, students, residents, affected stakeholders, or other rights-protected contexts requiring heightened care. Health-Sensitive Data includes personal health information, public health data, health system data, epidemiological data, health vulnerability records, and health-related WEFH-B outputs. Infrastructure-Sensitive Data concerns critical infrastructure, network topology, cyber vulnerabilities, power, water, telecom, transport, health facilities, ports, logistics, industrial systems, and cyber-physical assets. Public Authority Data is data received from or concerning public authorities and is subject to legal authority, non-confidential use limits, public-safe classification, retention, disclosure restrictions, and non-decision boundaries. Community-Sensitive Data includes local vulnerabilities, informal systems, lived-risk knowledge, demographic sensitivity, community assets, protected locations, social conditions, and participation records requiring careful handling. Protected Knowledge Data includes Indigenous knowledge, cultural knowledge, ecological knowledge, sacred or sensitive sites, protected community knowledge, security-sensitive knowledge, and non-public local context. Sensitive Operational Data includes access logs, credentials, system configurations, incident reports, security telemetry, room access records, infrastructure configurations, and live operations records. Privacy and Sensitive Data Incidents include unauthorized access, exposure, misuse, overcollection, unlawful retention, unsafe publication, reidentification, sensitive inference, and misclassification of sensitive data.

17.2.10.3 No Privacy Scope record, Rights-Bearing Data record, Health-Sensitive Data record, Infrastructure-Sensitive Data record, Public Authority Data record, Community-Sensitive Data record, Protected Knowledge Data record, Sensitive Operational Data record, Privacy and Sensitive Data Incident record, privacy review, data protection review, cyber review, public authority data review, community-sensitive data review, protected knowledge review, access log, credential record, system configuration, incident report, security telemetry record, public-safe summary, readiness note, public authority learning record, evidence record, Dataset Record, Data Handling Record, Data Custody Record, Data Stewardship action, deletion record, return record, archive record, correction notice, public repair, withdrawal notice, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, Handoff Dependency Note, or public communication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, privacy compliance certification, security certification, health determination, infrastructure resilience certification, standards conformance, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.2.10.4 The controlling Privacy and Sensitive Data Formula is that data may describe people, systems, authorities, communities, infrastructure, health, protected knowledge, and operations; but description is not permission, sensitivity is not optional, anonymization is not automatic safety, public authority data is not official action, community data is not consent, health data is not public health determination, infrastructure data is not public release material, operational data is not public evidence, and Nexus Acceleration shall use sensitive data only when privacy, rights, safeguards, custody, access, classification, correction, and public-safe limits are strong enough to protect what the data can affect.

### 17.3 Sovereign Data, Localization, Cross-Border Transfers, National Data Controls, Data Residency, Jurisdictional Limits, and Data Transfer Review

#### 17.3.1 Sovereign Data Definition

17.3.1.1 Sovereign Data means data, datasets, records, metadata, derived outputs, logs, models, data products, public authority materials, community-sensitive materials, Indigenous-sensitive materials where applicable, protected knowledge, geospatial layers, infrastructure data, health data, public safety data, cyber data, or operational data that are subject to national, public authority, Indigenous, community, institutional, sectoral, contractual, legal, cultural, or public-interest sovereignty concerns requiring localized control, restricted access, special governance, compute-to-data treatment, public-safe limits, or jurisdiction-specific stewardship.

17.3.1.2 Sovereign Data may include national public authority data, public-sector data, government-provided data, public finance data, public health data, emergency management data, infrastructure data, regulated-sector data, national security-sensitive data, Indigenous data where applicable, protected knowledge, community-held data, localized observability records, National Node records, sensitive geospatial data, health-sensitive data, and any derived output whose use, transfer, publication, or routing may affect sovereign interests, national ownership, public authority competence, Indigenous rights or protocols, community safeguards, or applicable law.

17.3.1.3 Sovereign Data shall not be treated as ordinary project data merely because it is technically accessible, publicly obtainable, partner-hosted, cloud-hosted, anonymized, aggregated, derived, synthetic, summarized, or useful for public-good analysis.

17.3.1.4 Sovereign Data classification shall identify the relevant sovereignty concern, including country, jurisdiction, public authority, Indigenous nation or governance body where applicable, community context, institutional source, sectoral rule, data residency requirement, localization requirement, access limit, transfer limit, publication limit, retention condition, deletion condition, archive condition, and review pathway.

17.3.1.5 Where uncertainty exists as to whether data is Sovereign Data, the more restrictive classification shall apply until National Node review, public authority boundary review, Indigenous protocol review where applicable, legal review, data stewardship review, or other competent review determines the appropriate status.

17.3.1.6 Sovereign Data is governed first by sovereignty, lawful authority, rights, safeguards, and jurisdiction, and only then by technical usefulness.

***

#### 17.3.2 Localization Requirements

17.3.2.1 Localization Requirements mean the rules requiring data to remain within a specified country, region, public authority environment, Indigenous or community-governed context where applicable, institutional system, approved sovereign cloud, sovereign compute environment, secure enclave, clean room, National Node environment, or other approved location or control environment.

17.3.2.2 Localization Requirements may arise from law, regulation, public authority condition, national security concern, data protection rule, health data rule, public-sector data rule, procurement rule, contract, partner agreement, funder requirement, ethics review, institutional policy, Indigenous protocol where applicable, community safeguard, protected knowledge restriction, public safety need, or data stewardship determination.

17.3.2.3 Data subject to Localization Requirements shall not be transferred, copied, cached, backed up, exported, mirrored, published, accessed remotely, processed in another jurisdiction, used in cross-border AI workflows, placed in foreign cloud regions, routed to external partners, or included in globally accessible repositories unless the relevant review and authorization permit such action.

17.3.2.4 Localization may require local storage, local processing, local access controls, local encryption key management, sovereign cloud, sovereign compute, compute-to-data, clean-room review, local institutional custody, National Node custody, public authority custody, Indigenous-governed custody where applicable, restricted archive, and local deletion or return procedures.

17.3.2.5 Localization Requirements shall be recorded in Dataset Records, Data Custody Records, Data Handling Records, Compute-Use Records, Data Transfer Review records, public-safe publication records, and Handoff Dependency Notes where relevant.

17.3.2.6 Where Localization Requirements conflict with global analysis, Nexus Universe participation, partner infrastructure, cloud optimization, public-safe reporting, publication ambition, readiness translation, or handoff convenience, Localization Requirements shall control.

17.3.2.7 Localization Requirements preserve lawful control before global movement.

***

#### 17.3.3 Cross-Border Transfer Rules

17.3.3.1 Cross-Border Transfer Rules mean the rules requiring legal, technical, privacy, security, public authority, sovereignty, contractual, Indigenous protocol where applicable, community safeguard, export control, sanctions, data protection, and public-safe review before data, metadata, logs, derived outputs, models, system outputs, AI outputs, maps, dashboards, public authority records, protected knowledge, sensitive operational data, or related records cross jurisdictions.

17.3.3.2 Cross-border transfer includes copying, uploading, downloading, remote access, cloud migration, cloud-region change, backup replication, repository access, data-room access, partner access, public authority sharing, AI model training, API exchange, dashboard publication, map publication, transfer to a researcher in another jurisdiction, transfer to a partner engineer, transfer to a sponsor or provider, transfer to a public authority, transfer to a National Node, transfer to a Regional Nexus pathway, and transfer into archive storage outside the original jurisdiction.

17.3.3.3 Before cross-border transfer, the relevant Data Transfer Review shall identify source jurisdiction, destination jurisdiction, storage location, processing location, access location, applicable law, data class, sovereignty concerns, public authority constraints, Indigenous protocol constraints where applicable, community safeguards, privacy risks, cyber risks, geospatial risks, protected knowledge risks, export control risks, sanctions risks, contractual restrictions, retention requirements, deletion requirements, and public-safe publication implications.

17.3.3.4 Cross-border transfer shall not occur merely because a participant, partner, sponsor, provider, cloud platform, research collaborator, public authority, capital reader, donor, insurer, or Nexus institution has technical access or analytical interest.

17.3.3.5 Cross-border transfer shall use the least risky lawful pathway, including redaction, aggregation, anonymization where sufficient, synthetic substitution, secure enclave access, no-download review, compute-to-data, sovereign compute, controlled API, encrypted transfer, access logging, or no-transfer decision.

17.3.3.6 Cross-border transfer shall be denied, restricted, delayed, rerouted, localized, or archived where transfer would violate law, sovereignty, protocol, contract, public authority condition, protected knowledge limits, public safety conditions, sanctions, export controls, privacy duties, or public-safe safeguards.

17.3.3.7 Cross-Border Transfer Rules ensure that global collaboration does not become uncontrolled jurisdictional leakage.

***

#### 17.3.4 National Data Controls

17.3.4.1 National Data Controls mean the rules requiring country-relevant data to respect National Nexus Nodes, national law, national public authority boundaries, national safeguards, public authority competence, national data policies, national public-safe reporting constraints, national continuation pathways, national records, national data residency conditions, national sovereignty concerns, and lawful national routing.

17.3.4.2 Country-relevant data shall include data concerning national public authorities, national resilience priorities, national infrastructure, national public services, national communities, national health systems, national disaster risks, national WEFH-B systems, national public finance relevance, national security-sensitive matters, national digital infrastructure, national public safety, national observability, national Nexus Universe tracks, and national handoff pathways.

17.3.4.3 National Data Controls shall require National Node routing or review where data use, transfer, publication, readiness translation, public authority learning, public-safe reporting, Nexus Universe output, or handoff dependency mapping may affect national ownership, public authority boundaries, community safeguards, Indigenous protocols where applicable, public-safe meaning, local law, or lawful continuation.

17.3.4.4 National Data Controls shall prevent global, regional, sponsor, provider, university, capital, donor, public finance, media, or external expert actors from bypassing national data pathways or using country-relevant data without appropriate national routing, classification, custody, access control, and safeguard review.

17.3.4.5 National Data Controls shall not be used to suppress legitimate public-interest correction, hide public-safe risks, block lawful review, or centralize national ownership in a manner that excludes affected communities, Indigenous actors where applicable, rights-sensitive participants, or safeguard reviewers.

17.3.4.6 National Data Control records shall identify the country relevance, National Node pathway, steward, custodian, public authority dependency, public-safe class, access class, transfer limits, publication limits, community safeguards, Indigenous safeguards where applicable, correction pathway, and archive status.

17.3.4.7 National Data Controls make national ownership operational in data governance, not merely declaratory.

***

#### 17.3.5 Data Residency

17.3.5.1 Data Residency means the physical, cloud, legal, contractual, operational, backup, processing, access, archive, deletion, and control location where data is stored, processed, accessed, backed up, replicated, cached, logged, archived, deleted, returned, or otherwise handled.

17.3.5.2 Data Residency shall be recorded for datasets, public authority data, sovereign data, health-sensitive data, infrastructure-sensitive data, community-sensitive data, Indigenous-sensitive data where applicable, protected knowledge, sensitive geospatial data, sensitive operational data, partner-provided data, Nexus Universe temporary stack data, cloud-hosted data, secure-room data, clean-room data, and archive records.

17.3.5.3 Data Residency records shall identify storage country, cloud region, physical location where known, processing location, backup location, access location, administrator location where relevant, encryption key location where relevant, custody holder, data steward, service provider, permitted users, transfer restrictions, deletion conditions, return conditions, archive status, and jurisdictional review status.

17.3.5.4 Data Residency shall not be assumed from the identity of the cloud provider, partner, institution, or nominal project location. Actual storage, backup, access, processing, support, and administrator pathways shall be considered where relevant.

17.3.5.5 A change in cloud region, storage location, backup architecture, administrator access, partner support location, compute environment, archive location, or processing location may constitute a transfer requiring Data Transfer Review.

17.3.5.6 Data Residency errors shall be treated as data governance incidents where data was stored, processed, accessed, backed up, or archived in an unauthorized or unreviewed jurisdiction or environment.

17.3.5.7 Data Residency makes the location of data legally, operationally, and ethically visible.

***

#### 17.3.6 Jurisdictional Limits

17.3.6.1 Jurisdictional Limits mean the legal, contractual, public authority, Indigenous protocol where applicable, community safeguard, sanctions, export control, privacy, cyber, procurement, sectoral, institutional, data residency, data localization, public safety, health, infrastructure, and protected knowledge restrictions that limit data movement, processing, access, publication, routing, archive, deletion, or handoff.

17.3.6.2 Jurisdictional Limits may arise from national law, local law, public authority restrictions, public-sector data rules, data protection laws, health data rules, cybersecurity laws, sectoral regulations, sanctions regimes, export control rules, grant or donor terms, public finance conditions, procurement rules, university policies, hospital policies, Indigenous protocols where applicable, community agreements, partner contracts, data licenses, confidentiality agreements, or ethics approvals.

17.3.6.3 Nexus Acceleration shall identify Jurisdictional Limits before data is transferred, processed, combined, enriched, published, routed, archived, used in AI workflows, used in public authority learning, used in readiness notes, used in public finance materials, used in insurance-readiness question maps, used in Nexus Universe, or included in Handoff Packages.

17.3.6.4 Jurisdictional Limits shall override analytical convenience, technical capability, global collaboration, sponsor or provider contribution, public authority interest, capital-reader interest, donor interest, public finance relevance, media interest, research value, public-safe publication ambition, or handoff ambition.

17.3.6.5 Where Jurisdictional Limits are unclear, the data shall be restricted and legal, public authority, National Node, Indigenous protocol where applicable, or data stewardship review shall be obtained before further movement.

17.3.6.6 Jurisdictional Limits records shall identify the restriction, source of restriction, affected data, affected pathway, permitted actions, prohibited actions, review status, correction pathway, and archive status.

17.3.6.7 Jurisdictional Limits ensure that Nexus Acceleration remains lawful in each place where data has meaning, location, source, or effect.

***

#### 17.3.7 Data Transfer Review

17.3.7.1 Data Transfer Review means the required review of proposed sharing, publication, cloud migration, cloud-region change, partner access, sponsor access, provider access, public authority access, researcher access, cross-border compute, API exchange, model training, model evaluation, derivative outputs, dashboard release, map release, repository release, backup replication, archival storage, deletion, return, or handoff-related movement involving data or data-derived outputs.

17.3.7.2 Data Transfer Review shall be required before transferring public authority data, sovereign data, rights-bearing data, health-sensitive data, infrastructure-sensitive data, community-sensitive data, protected knowledge data, Indigenous-sensitive data where applicable, sensitive geospatial data, sensitive social data, cyber-sensitive data, partner-confidential data, market-sensitive data, or sensitive operational data.

17.3.7.3 Each Data Transfer Review shall identify data source, data class, Dataset Record, steward, custodian, current location, proposed destination, proposed access users, proposed purpose, legal basis where required, permissions, contract terms, jurisdictional limits, public authority conditions, Indigenous protocol conditions where applicable, community safeguards, privacy risks, security controls, export control risks, sanctions risks, public-safe implications, retention impacts, deletion or return requirements, archive impacts, and correction pathway.

17.3.7.4 Data Transfer Review shall consider whether transfer can be avoided through compute-to-data, sovereign compute, local analysis, aggregation, anonymization where sufficient, redaction, synthetic data, secure enclave access, clean-room review, controlled API access, public-safe summary substitution, or no-transfer decision.

17.3.7.5 Transfer shall not proceed until required approvals, permissions, reviews, agreements, access controls, logging, security controls, and public-safe restrictions are in place.

17.3.7.6 Data Transfer Review shall be updated where data class changes, access scope changes, destination changes, purpose changes, law changes, public authority conditions change, Indigenous protocol conditions change where applicable, partner access changes, publication scope changes, or incident risk changes.

17.3.7.7 Data Transfer Review is the gate that keeps data movement from becoming accidental legal, ethical, or sovereignty breach.

***

#### 17.3.8 Sovereign Compute and Compute-to-Data Preference

17.3.8.1 Sovereign Compute and Compute-to-Data Preference means that, where data transfer creates sovereignty, privacy, public authority, protected knowledge, Indigenous protocol where applicable, health, infrastructure, cyber, national security, community safeguard, jurisdictional, or public-safe concerns, Nexus Acceleration shall prefer keeping data in place and bringing approved compute, approved models, approved code, approved analysts, or approved workflows to the data instead of exporting the data to external environments.

17.3.8.2 Sovereign compute may include nationally controlled compute, approved sovereign cloud, public authority compute, National Node compute, institutional compute, secure enclave, confidential computing environment, clean room, local data room, or other approved environment subject to jurisdiction, custody, access, logging, and output controls.

17.3.8.3 Compute-to-data shall be preferred for sensitive, restricted, sovereign, public authority, protected knowledge, Indigenous-sensitive where applicable, health-sensitive, cyber-sensitive, infrastructure-sensitive, community-sensitive, or geospatial-sensitive datasets where data export would create avoidable risk.

17.3.8.4 Compute-to-data workflows shall define approved users, approved workloads, approved tools, approved outputs, no-download rules, logging, monitoring, access controls, output review, retention limits, deletion or return requirements, and closure conditions.

17.3.8.5 Output review shall be required to ensure that results, summaries, models, embeddings, maps, indicators, dashboards, public-safe reports, readiness notes, or derived outputs do not leak restricted data, enable reidentification, expose protected knowledge, reveal sensitive locations, disclose public authority-sensitive information, or evade transfer restrictions.

17.3.8.6 Sovereign compute and compute-to-data shall not be used to bypass law, protocols, consent requirements, public authority conditions, or publication limits. Keeping data in place does not by itself authorize processing.

17.3.8.7 Sovereign Compute and Compute-to-Data Preference allows Nexus Acceleration to learn from sensitive data without treating transfer as the default.

***

#### 17.3.9 Transfer Incident and Correction

17.3.9.1 Transfer Incident means any actual, suspected, or potential unauthorized cross-border movement, improper cloud region use, unapproved partner access, unapproved sponsor or provider access, unauthorized public authority access, localization breach, residency error, unapproved backup replication, unauthorized repository access, unapproved model training, unapproved derivative output transfer, unapproved dashboard or map publication, jurisdictional overreach, export control concern, sanctions concern, public authority data misuse, protected knowledge transfer, Indigenous-sensitive data transfer where applicable, or data transfer outside the approved classification, permission, review, or custody pathway.

17.3.9.2 Transfer Incidents may occur through manual download, email attachment, shared drive access, API access, cloud sync, backup replication, support access, remote administration, logging, model training, embedding creation, map publication, dashboard access, repository release, partner engineering support, public authority sharing, public-safe report release, archive migration, or temporary Nexus Universe stack teardown.

17.3.9.3 Transfer Incident intake shall identify affected data, classification, source jurisdiction, unauthorized destination, access pathway, users involved, public exposure, legal risk, sovereignty risk, privacy risk, protected knowledge risk, public authority risk, Indigenous safeguard risk where applicable, cyber risk, geospatial risk, contract risk, export control risk, sanctions risk, containment action, notice obligations, correction pathway, and archive status.

17.3.9.4 Correction measures may include immediate access suspension, credential revocation, data quarantine, deletion, return, cloud region correction, backup deletion where lawful and feasible, repository restriction, dashboard suspension, map withdrawal, model or derivative output restriction, partner access closure, public authority notice where appropriate, participant or community notice where appropriate, Indigenous notice where applicable, legal review, sanctions or export control review, public-safe clarification, public repair where required, and archive.

17.3.9.5 Transfer Incidents shall be escalated where the transfer involves Sovereign Data, public authority data, health-sensitive data, Indigenous-sensitive data where applicable, protected knowledge, sensitive geospatial data, infrastructure-sensitive data, cyber-sensitive data, export-controlled data, sanctions-relevant parties, or public-safe risk.

17.3.9.6 Transfer Incident records shall preserve enough detail for accountability and future prevention while protecting sensitive incident details, participant identity, public authority-sensitive information, cyber-sensitive information, protected knowledge, and legal privilege where applicable.

17.3.9.7 Transfer Incident Correction proves that data sovereignty is enforceable, not merely declaratory.

***

#### 17.3.10 Sovereign Data Summary Clause

17.3.10.1 Nexus Acceleration may be global in purpose, collaborative in method, and cross-border in aspiration, but it shall remain lawful, legitimate, and public-good only where it respects data sovereignty, localization, jurisdictional limits, national data controls, public authority competence, Indigenous protocols where applicable, community safeguards, and data transfer discipline.

17.3.10.2 Sovereign Data is data subject to national, public authority, Indigenous, community, institutional, sectoral, or legal sovereignty concerns requiring localized control, restricted access, or special governance. Localization Requirements govern data that must remain within a country, region, public authority environment, Indigenous or community-governed context, institutional system, or approved sovereign compute environment. Cross-Border Transfer Rules require legal, technical, privacy, security, public authority, sovereign, contractual, and safeguard review before data crosses jurisdictions. National Data Controls require country-relevant data to respect National Nexus Nodes, national law, national public authority boundaries, national safeguards, and national continuation pathways. Data Residency is the physical, cloud, legal, or operational location where data is stored, processed, accessed, backed up, archived, or deleted. Jurisdictional Limits restrict data use where laws, contracts, public authority restrictions, Indigenous protocols, sanctions, export controls, privacy requirements, or sectoral rules restrict movement or processing. Data Transfer Review is required for proposed sharing, publication, cloud migration, partner access, cross-border compute, model training, derivative outputs, and archival storage. Sovereign Compute and Compute-to-Data are preferred approaches where data transfer creates sovereignty, privacy, public authority, protected knowledge, or national security concerns. Transfer Incidents include unauthorized cross-border movement, improper cloud region use, unapproved partner access, localization breach, residency error, or jurisdictional overreach, and require correction.

17.3.10.3 No Sovereign Data record, Localization Requirement, Cross-Border Transfer Rule, National Data Control, Data Residency record, Jurisdictional Limit, Data Transfer Review, Sovereign Compute record, Compute-to-Data workflow, Transfer Incident record, correction record, deletion record, return record, archive record, Dataset Record, Data Custody Record, Data Stewardship action, public authority data record, Indigenous-sensitive data record where applicable, protected knowledge record, public-safe summary, readiness note, public authority learning record, Handoff Dependency Note, Nexus Universe output, National Node routing, Regional Nexus routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, public communication, correction notice, withdrawal notice, restricted archive, or transfer approval record shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, unrestricted transfer right, export authorization by implication, sanctions clearance by implication, privacy compliance certification, security certification, standards conformance, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.3.10.4 The controlling Sovereign Data Formula is that Nexus may learn globally, compute locally, route nationally, collaborate regionally, publish public-safe summaries, and prepare lawful continuation; but global purpose is not global data entitlement, technical access is not transfer authority, cloud convenience is not residency compliance, cross-border collaboration is not cross-border permission, national data is not external commodity, protected knowledge is not exportable context, public authority data is not Nexus property, compute-to-data is not processing permission by itself, and Nexus Acceleration shall move data only where sovereignty, localization, jurisdiction, law, safeguards, custody, and public-safe review permit.

### 17.4 Compute-to-Data, Secure Enclaves, Clean Rooms, Controlled Rooms, Confidential Computing, No-Download Environments, Approved Workloads, and Output Review

#### 17.4.1 Compute-to-Data Definition

17.4.1.1 Compute-to-Data means the preferred Nexus Acceleration method for analyzing restricted, sovereign-sensitive, rights-bearing, public authority-sensitive, community-sensitive, protected knowledge, Indigenous-sensitive where applicable, health-sensitive, infrastructure-sensitive, cyber-sensitive, geospatial-sensitive, market-sensitive, partner-confidential, or otherwise restricted data by bringing approved compute, approved code, approved models, approved tools, approved analysts, or approved workflows to the data without moving, exporting, copying, downloading, or externally transferring raw data.

17.4.1.2 Compute-to-Data shall be used where raw data movement would create avoidable sovereignty risk, privacy risk, public authority risk, protected knowledge risk, Indigenous protocol risk where applicable, community safeguard risk, health risk, cyber risk, infrastructure risk, geospatial risk, public safety risk, export-control risk, sanctions risk, contractual risk, partner confidentiality risk, or public-safe publication risk.

17.4.1.3 Compute-to-Data may occur in sovereign compute environments, National Node environments, public authority environments, institutional environments, secure enclaves, clean rooms, controlled rooms, confidential computing environments, local data rooms, approved cloud regions, no-download environments, or other approved technical and governance environments.

17.4.1.4 Compute-to-Data shall not itself authorize processing. It is a handling method, not a substitute for lawful basis, permission, ethics review, institutional review, community review, Indigenous protocol review where applicable, public authority authorization where required, data transfer review, access approval, or public-safe output review.

17.4.1.5 Compute-to-Data records shall identify data class, data steward, custodian, environment, authorized users, approved workloads, approved tools, permitted outputs, prohibited outputs, access controls, logging, monitoring, output review, retention, deletion, closure conditions, and correction pathway.

17.4.1.6 Compute-to-Data protects sensitive data by making raw-data movement exceptional rather than default.

***

#### 17.4.2 Secure Enclaves

17.4.2.1 Secure Enclaves mean protected technical environments established for the controlled access, analysis, computation, review, and output generation of restricted or sensitive data under strict access controls, isolation, monitoring, logging, approved workloads, restricted export, secure computation, output review, and closure conditions.

17.4.2.2 Secure Enclaves may be used for public authority data, sovereign data, health-sensitive data, infrastructure-sensitive data, cyber-sensitive data, protected knowledge data, Indigenous-sensitive data where applicable, community-sensitive data, sensitive geospatial data, sensitive social data, partner-confidential data, market-sensitive data, or sensitive operational data.

17.4.2.3 A Secure Enclave shall have a recorded steward, custodian, environment owner, authorized user list, access approval pathway, data classification, permitted workloads, prohibited actions, logging requirements, monitoring requirements, export restrictions, retention rules, incident pathway, output review process, and closure procedure.

17.4.2.4 Secure Enclave controls may include network isolation, identity verification, multi-factor authentication, least-privilege access, role separation, time-bound access, no-download configuration, clipboard restrictions, screenshot restrictions, restricted internet access, controlled package installation, approved code execution, audit logging, encryption, key controls, and supervised output export.

17.4.2.5 Secure Enclave access shall not be granted by virtue of sponsor status, provider status, partner status, capital-reader status, public authority attendance, Working Group participation, Nexus Universe participation, or general institutional role. Access shall be based only on recorded need, authorization, classification, and safeguard review.

17.4.2.6 Secure Enclave outputs shall not leave the enclave until reviewed for privacy, re-identification, sensitive inference, protected knowledge, Indigenous protocol where applicable, sensitive geospatial exposure, cyber exposure, public authority sensitivity, public safety, benchmark misuse, finance or procurement overclaim, and public-safe classification.

17.4.2.7 Secure Enclaves allow sensitive analysis only by making access, computation, and output release controlled events.

***

#### 17.4.3 Clean Rooms

17.4.3.1 Clean Rooms mean controlled collaboration environments established for limited review, comparison, analysis, or discussion of sensitive information, market-sensitive information, public authority-sensitive materials, partner-confidential information, procurement-sensitive information, restricted datasets, public finance-sensitive materials, insurance-sensitive questions, or other information requiring purpose limits, information barriers, access controls, logging, confidentiality, and output review.

17.4.3.2 Clean Rooms may be technical, legal, public authority, finance-readiness, insurance-readiness, donor-readiness, public finance, procurement-sensitive, data, cyber, research, or community-safeguard environments, provided that the clean-room purpose, permitted participants, information categories, prohibited discussions, access controls, and output rules are recorded.

17.4.3.3 Clean Rooms shall not be used to facilitate collusion, market coordination, bid coordination, pricing discussion, underwriting coordination, investment coordination, procurement manipulation, public authority overclaim, provider preference, sponsor influence, or unauthorized information exchange.

17.4.3.4 Clean Room records shall identify the purpose, convening body, steward, participant classes, access basis, information categories, confidentiality obligations, competition controls where relevant, public authority boundaries where relevant, no-reliance language where relevant, prohibited topics, output limits, review requirements, and archive status.

17.4.3.5 Clean Room participants shall receive boundary reminders before access, including restrictions on copying, downloading, photographing, screenshotting, forwarding, quoting, publicizing, using for procurement advantage, using for market advantage, using for finance solicitation, or using for public authority implication.

17.4.3.6 Clean Room outputs shall be limited to approved summaries, question maps, dependency notes, public-safe records, or controlled findings that do not disclose restricted information beyond the permitted purpose.

17.4.3.7 Clean Rooms enable structured learning only when they prevent sensitive information from becoming uncontrolled advantage.

***

#### 17.4.4 Controlled Rooms

17.4.4.1 Controlled Rooms mean physical, virtual, or hybrid spaces with restricted access, monitored use, confidentiality obligations, approved materials, approved participants, no-download rules where required, no-recording rules where required, output review, access closure, and record discipline for Nexus Acceleration activities involving sensitive data, sensitive information, restricted participation, public authority learning, community safeguards, protected knowledge, readiness review, or secure computation.

17.4.4.2 Controlled Rooms may include secure research rooms, public authority learning rooms, capital-reader rooms, insurance-reader rooms, donor or public finance reader rooms, community safeguard rooms, Indigenous protocol rooms where applicable, restricted technical rooms, cyber rooms, data rooms, build rooms, operational rooms, clean rooms, and secure enclaves.

17.4.4.3 Each Controlled Room shall have a recorded purpose, access criteria, participant list, steward, moderator where applicable, materials list, data classification, confidentiality conditions, boundary reminders, permitted uses, prohibited uses, output rules, recording rules, note-taking rules, access logs, closure conditions, and correction pathway.

17.4.4.4 Controlled Room rules may prohibit downloads, screenshots, photographs, recordings, uncontrolled notes, external sharing, copying, use in marketing, use in procurement, use in finance solicitation, use in public authority claims, use in media, and use in handoff materials unless separately reviewed and authorized.

17.4.4.5 Controlled Room participation shall not imply approval, endorsement, public authority action, finance interest, insurance interest, donor commitment, public finance allocation, procurement status, community consent, Indigenous consent where applicable, readiness, certification, validation, or authorization.

17.4.4.6 Controlled Room access shall be closed when the purpose ends, participant role changes, review period ends, incident occurs, access is revoked, agreement expires, or continued access is no longer necessary or lawful.

17.4.4.7 Controlled Rooms make sensitive participation and analysis possible without turning sensitive access into uncontrolled circulation.

***

#### 17.4.5 Confidential Computing

17.4.5.1 Confidential Computing means the use of technical controls designed to protect data during processing, including encrypted processing, trusted execution environments, secure hardware-backed isolation, confidential virtual machines, protected memory, attestation where available, key management, workload restrictions, access logs, output controls, and closure procedures.

17.4.5.2 Confidential Computing may be used where data sensitivity, sovereignty, public authority restrictions, health sensitivity, cyber sensitivity, infrastructure sensitivity, protected knowledge, Indigenous sensitivity where applicable, community sensitivity, or partner confidentiality requires additional protection during computation.

17.4.5.3 Confidential Computing records shall identify environment, provider, jurisdiction, data class, workload, users, attestation status where available, key management model, administrator access, logging, monitoring, permitted processing, prohibited processing, output review, retention, deletion, and incident pathway.

17.4.5.4 Key management shall be documented, including who controls keys, where keys are held, whether keys are rotated, how access is revoked, how secrets are protected, and how closure is confirmed.

17.4.5.5 Confidential Computing shall not be used as a claims device. Use of confidential computing does not create privacy certification, security certification, compliance certification, public authority approval, data transfer authorization, sovereign approval, or permission to publish outputs.

17.4.5.6 Confidential Computing outputs shall remain subject to output review because technical protection during processing does not eliminate risks of re-identification, sensitive inference, protected knowledge exposure, public authority overclaim, benchmark misuse, or public-safe harm.

17.4.5.7 Confidential Computing strengthens secure analysis only when paired with governance, records, output review, and correction.

***

#### 17.4.6 No-Download Environments

17.4.6.1 No-Download Environments mean systems, rooms, platforms, secure enclaves, clean rooms, controlled rooms, dashboards, data rooms, repositories, or compute environments where authorized users may view, query, analyze, compute against, or generate approved outputs from approved materials, but may not export raw data, restricted files, logs, screenshots, copies, extracts, credentials, code where restricted, results, model outputs, maps, derived outputs, or other materials except through approved output review.

17.4.6.2 No-Download Environments may be required for sovereign data, public authority data, health-sensitive data, protected knowledge, Indigenous-sensitive data where applicable, community-sensitive data, sensitive geospatial data, infrastructure-sensitive data, cyber-sensitive data, partner-confidential data, market-sensitive data, sensitive operational data, and public finance or procurement-sensitive materials.

17.4.6.3 No-Download controls may include disabled downloads, disabled copy-paste, disabled printing, screenshot prevention where feasible, watermarking, session recording where lawful and appropriate, access logging, query logging, restricted exports, controlled notebooks, approved output folders, supervised review queues, and automatic access expiration.

17.4.6.4 Users shall not attempt to evade No-Download controls through photography, screen capture, manual transcription of restricted content, copying into external tools, prompt injection into external AI systems, unauthorized API calls, uncontrolled note-taking, external storage, or derivative reconstruction.

17.4.6.5 Any output leaving a No-Download Environment shall pass through approved output review and shall be classified before release.

17.4.6.6 No-Download Environment records shall identify materials covered, users, permitted uses, prohibited actions, output process, logs, violations, closure conditions, and archive status.

17.4.6.7 No-Download Environments protect sensitive information by ensuring that viewing is not exporting.

***

#### 17.4.7 Approved Workloads

17.4.7.1 Approved Workloads mean recorded, pre-authorized computational, analytical, research, modeling, AI, observability, simulation, digital twin, benchmark, dashboard, query, or review activities permitted to run inside a compute-to-data environment, secure enclave, clean room, controlled room, confidential computing environment, no-download environment, sovereign compute environment, or other restricted environment.

17.4.7.2 Each Approved Workload record shall identify authorized users, steward, purpose, research question, public-good rationale, data sources, data classification, code, tools, models, libraries, compute environment, runtime limits, permitted inputs, permitted outputs, output types, review requirements, logging requirements, public-safe class, retention conditions, deletion conditions, and archive status.

17.4.7.3 Approved Workload records shall identify prohibited actions, including unauthorized data export, unauthorized model training, unauthorized external API calls, unauthorized internet access, unapproved package installation, credential extraction, screenshot capture, unrestricted logging of sensitive data, re-identification attempts, sensitive inference beyond scope, vulnerability probing outside authorization, public authority overclaim, finance overclaim, procurement overclaim, and publication without review.

17.4.7.4 Workloads involving AI, machine learning, digital twins, simulations, geospatial analysis, cyber analysis, health data, public authority data, protected knowledge, Indigenous-sensitive data where applicable, sensitive social data, or infrastructure-sensitive data shall include additional review conditions appropriate to their risk.

17.4.7.5 Approved Workloads shall not expand by implication. A workload approved for one dataset, purpose, environment, user group, or output type shall not authorize other datasets, purposes, environments, users, output types, or downstream uses.

17.4.7.6 Workload changes shall require amendment, including changes to data source, code, model, tool, user, runtime, output, destination, public-safe use, or transfer pathway.

17.4.7.7 Approved Workloads make computation reviewable before sensitive data is touched.

***

#### 17.4.8 Output Review

17.4.8.1 Output Review means the mandatory review of any result, summary, table, model output, AI output, benchmark result, map, dashboard, visualization, log extract, derived dataset, code artifact, model weight, embedding, feature, technical note, public-safe summary, readiness note, public authority learning material, Docket item, Nexus Universe output, repository artifact, or Handoff Dependency Note proposed to leave a secure environment, compute-to-data environment, secure enclave, clean room, controlled room, confidential computing environment, or no-download environment.

17.4.8.2 Output Review shall assess privacy risk, re-identification risk, sensitive inference risk, rights-bearing data exposure, health-sensitive exposure, community-sensitive exposure, Indigenous-sensitive exposure where applicable, protected knowledge exposure, sensitive geospatial exposure, cyber-sensitive exposure, infrastructure-sensitive exposure, public authority-sensitive exposure, market-sensitive exposure, partner-confidential exposure, benchmark misuse, public authority overclaim, finance overclaim, procurement overclaim, emergency-language risk, consent overclaim, representation overclaim, and public-safe publication status.

17.4.8.3 Output Review may require redaction, aggregation, suppression, generalization, paraphrase, masking, delayed release, restricted circulation, no-publication classification, controlled public release, additional review, participant notice where appropriate, community review where appropriate, Indigenous protocol review where applicable, legal review, privacy review, cyber review, public authority boundary review, GRF claims review, GCRI technical review, GRA readiness review, or withdrawal.

17.4.8.4 Output Review shall distinguish outputs suitable for internal continuation, controlled review, public-safe publication, readiness translation, public authority learning, repository release, Docket review, Nexus Rail routing, archive, or lawful handoff dependency mapping.

17.4.8.5 No output shall be released merely because it is technically generated, analytically useful, visually compelling, sponsor-supported, provider-supported, public authority-relevant, finance-relevant, media-relevant, or time-sensitive.

17.4.8.6 Output Review records shall identify source environment, workload, data class, output type, reviewer, review criteria, restrictions, redactions, approved use, prohibited use, release destination, public-safe class, correction pathway, and archive status.

17.4.8.7 Output Review is the point at which secure analysis becomes safe communication or remains restricted.

***

#### 17.4.9 Secure Room Incident

17.4.9.1 Secure Room Incident means any actual, suspected, or potential event involving unauthorized access, prohibited download, output leakage, screenshot capture, photography, copying, uncontrolled note-taking, data inference, re-identification attempt, unapproved workload, credential misuse, key misuse, unauthorized model training, unauthorized external API call, unapproved package installation, restricted information disclosure, partner engineer over-access, access logging failure, output review failure, no-download control failure, confidential computing control failure, clean-room rule breach, controlled-room rule breach, or access closure failure.

17.4.9.2 Secure Room Incidents may occur in secure enclaves, clean rooms, controlled rooms, confidential computing environments, no-download environments, data rooms, public authority learning rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance reader rooms, community safeguard rooms, Indigenous protocol rooms where applicable, National Node environments, partner environments, cloud environments, and temporary Nexus Universe stacks.

17.4.9.3 Secure Room Incident intake shall identify the environment, affected data, classification, users involved, access pathway, incident type, time, affected outputs, logs, public exposure, transfer risk, privacy risk, protected knowledge risk, Indigenous safeguard risk where applicable, community risk, public authority risk, cyber risk, geospatial risk, finance or procurement risk where relevant, containment action, notice obligations, correction pathway, and archive status.

17.4.9.4 Response measures may include session termination, access suspension, credential revocation, key rotation, data quarantine, output quarantine, download deletion, screenshot or copy remediation where possible, repository restriction, dashboard suspension, map withdrawal, workload suspension, environment shutdown, partner access closure, public authority notice where appropriate, participant or community notice where appropriate, Indigenous notice where applicable, legal review, cyber review, privacy review, public-safe review, public repair where required, and archive.

17.4.9.5 Secure Room Incidents shall be escalated where they involve sovereign data, public authority data, health-sensitive data, protected knowledge, Indigenous-sensitive data where applicable, sensitive geospatial data, infrastructure-sensitive data, cyber-sensitive data, sensitive operational data, export-controlled data, sanctions risk, public safety risk, or public-facing exposure.

17.4.9.6 Secure Room Incident records shall preserve logs and evidence needed for review while protecting sensitive incident details, affected data, participant identity, public authority-sensitive information, cyber-sensitive information, protected knowledge, and legal privilege where applicable.

17.4.9.7 Secure Room Incidents prove why secure-room discipline must be enforceable, not merely descriptive.

***

#### 17.4.10 Compute-to-Data Summary Clause

17.4.10.1 Compute-to-Data and secure-room discipline allow high-value research, observability, AI analysis, digital twins, simulations, public authority learning, readiness translation, and Nexus Universe work while protecting the data, communities, institutions, public authorities, rights holders, partners, and public trust that make such work possible.

17.4.10.2 Compute-to-Data is the preferred method for analyzing restricted, sovereign-sensitive, rights-bearing, public authority, community-sensitive, protected knowledge, health-sensitive, infrastructure-sensitive, or cyber-sensitive data without moving raw data. Secure Enclaves are protected technical environments with strict access controls, isolation, logging, approved workloads, restricted export, secure computation, and output review. Clean Rooms are controlled collaboration environments for sensitive information, market-sensitive information, public authority-sensitive materials, or restricted datasets under purpose limits and access controls. Controlled Rooms are physical, virtual, or hybrid spaces with restricted access, monitored use, no-download rules, confidentiality obligations, output review, and access closure. Confidential Computing uses encrypted processing, key management, attestation where available, workload restrictions, access logs, and output restrictions. No-Download Environments allow users to analyze approved materials but not export raw data, restricted files, logs, screenshots, outputs, or derivatives except through approved output review. Approved Workloads identify authorized users, purpose, code, tools, compute environment, data sources, output types, review requirements, runtime limits, and prohibited actions. Output Review governs results leaving secure environments, including privacy, re-identification, sensitive geospatial, protected knowledge, cyber, public authority, benchmark, and public-safe review. Secure Room Incidents include unauthorized access, prohibited download, output leakage, screenshot capture, data inference, unapproved workload, credential misuse, or failure of output review.

17.4.10.3 No Compute-to-Data record, Secure Enclave record, Clean Room record, Controlled Room record, Confidential Computing record, No-Download Environment record, Approved Workload record, Output Review record, Secure Room Incident record, secure room access, enclave access, clean-room participation, controlled-room participation, confidential computing workflow, no-download access, approved code run, approved model run, workload approval, output approval, public-safe summary, readiness note, public authority learning record, benchmark output, dashboard, map, digital twin output, simulation output, repository artifact, Handoff Dependency Note, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, correction notice, withdrawal notice, restricted archive, or public communication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, unrestricted transfer right, privacy compliance certification, security certification, confidential-computing certification, benchmark validation, standards conformance, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.4.10.4 The controlling Compute-to-Data Formula is that data may stay in place, compute may come to data, secure rooms may permit controlled analysis, clean rooms may permit bounded collaboration, confidential computing may protect processing, no-download environments may prevent export, approved workloads may constrain computation, and output review may decide what may leave; but compute-to-data is not processing permission, enclave access is not data ownership, clean-room access is not market permission, controlled-room participation is not approval, confidential computing is not compliance certification, no-download viewing is not export authority, workload approval is not publication approval, output review is not validation, and Nexus Acceleration shall learn from sensitive data only when the raw data, derived outputs, people, communities, institutions, and public authorities remain protected before, during, and after computation.

### 17.5 Cybersecurity, Zero Trust, Identity, Access, Privileged Access, Secrets, Logging, Monitoring, Incident Response, Security Operations, and Access Closure

#### 17.5.1 Cybersecurity Baseline

17.5.1.1 Cybersecurity Baseline means the minimum security control environment required for Nexus Acceleration, Nexus Universe, Nexus Network, National Nexus Nodes, National Working Groups, Nexus Competence Cells, repositories, data rooms, secure rooms, clean rooms, controlled rooms, cloud environments, sovereign compute environments, partner systems, public authority learning rooms, temporary stack operations, dashboards, APIs, observability systems, AI workflows, digital twins, simulations, public-good software, and all related technical infrastructure.

17.5.1.2 The Cybersecurity Baseline shall include identity controls, access controls, zero trust principles, privileged access controls, secrets management, endpoint security, repository security, secure configuration, logging, monitoring, vulnerability management, incident response, access closure, data protection, network segmentation where appropriate, encryption where appropriate, backup and recovery where appropriate, dependency review, secure development, public-safe release review, and teardown controls.

17.5.1.3 The Cybersecurity Baseline shall apply to permanent Nexus Network infrastructure and temporary Nexus Universe stack infrastructure, including contributed compute, cloud credits, partner-provided tools, network systems, AI platforms, data platforms, telemetry systems, public-good repositories, build-crew systems, volunteer systems, and partner engineering environments.

17.5.1.4 No partner, sponsor, provider, volunteer, researcher, public authority participant, capital reader, insurer, donor, public finance reader, media actor, National Working Group participant, Competence Cell contributor, or temporary-stack operator shall receive access to systems, data, repositories, credentials, dashboards, logs, environments, or operational tools except through recorded security controls, role-specific need, time-bound authorization, and access logging.

17.5.1.5 Cybersecurity controls shall be proportionate to classification, sensitivity, threat, role, data type, public authority relevance, sovereignty, protected knowledge status, cyber risk, infrastructure risk, public safety risk, and operational exposure. Where uncertainty exists, the more restrictive control shall apply until security review determines otherwise.

17.5.1.6 The Cybersecurity Baseline shall not be represented as security certification, compliance certification, vendor validation, public authority approval, procurement qualification, operational authorization, deployment approval, or market claim. It is an internal and ecosystem control baseline for lawful, trustworthy, and public-good technical work.

17.5.1.7 Cybersecurity is not a supporting administrative function; it is a core condition of Nexus Acceleration’s ability to hold data, convene infrastructure, protect participants, and produce credible records.

***

#### 17.5.2 Zero Trust Principle

17.5.2.1 Zero Trust Principle means that no user, device, workload, partner, sponsor, provider, researcher, volunteer, reviewer, public authority participant, capital reader, insurer, donor, public finance reader, media actor, room, node, repository, cloud environment, API, model, service account, system, network, or temporary stack component shall be trusted by default.

17.5.2.2 All access shall be authenticated, authorized, limited, monitored, logged, reviewed, revocable, and bound to a recorded purpose. Trust shall be continuously earned through identity, role, device posture where applicable, authorization, classification, workload approval, environment controls, logging, monitoring, and behavior consistent with approved use.

17.5.2.3 Zero Trust shall require least privilege, need-to-know access, role-based access, time-bound permissions, separation of duties, environment segmentation where appropriate, secure defaults, continuous monitoring, access recertification, and rapid revocation where risk changes.

17.5.2.4 Zero Trust shall apply equally to internal participants and external contributors. Sponsor support, provider contribution, partner status, public authority attendance, researcher reputation, technical seniority, founder status, volunteer status, national role, or institutional affiliation shall not create default trust or automatic access.

17.5.2.5 Zero Trust shall extend to workloads and systems. Approved users shall not run unapproved code, unapproved models, unapproved scripts, unapproved external APIs, unapproved packages, unapproved data exports, unapproved scans, unapproved benchmarks, or unapproved integrations merely because they have access to an environment.

17.5.2.6 Zero Trust shall require that access be terminated when purpose ends, role changes, risk changes, support period ends, research run closes, event cycle ends, incident occurs, contribution expires, or access is no longer lawful, necessary, or appropriate.

17.5.2.7 Zero Trust protects Nexus Acceleration by assuming that every access pathway must be justified, bounded, observed, and capable of closure.

***

#### 17.5.3 Identity Management

17.5.3.1 Identity Management means the rules for establishing, verifying, assigning, managing, reviewing, suspending, and closing identities for persons, organizations, service accounts, workloads, devices, systems, repositories, rooms, APIs, and technical environments participating in Nexus Acceleration.

17.5.3.2 Identity Management shall apply to researchers, fellows, volunteers, partners, sponsors, providers, public authorities, reviewers, GCRI contributors, GRF reviewers, GRA reviewers, technical mentors, partner engineers, Working Group members, Competence Cell contributors, National Node personnel, National Council participants, room participants, media participants, capital readers, insurers, donors, public finance readers, build-crew personnel, operations personnel, data stewards, repository maintainers, cloud administrators, and temporary stack operators.

17.5.3.3 Each identity shall be associated with a recorded role, affiliation where appropriate, authorization basis, conflict status where relevant, access purpose, access class, permitted environments, permitted data classes, access duration, responsible steward, authentication method, review schedule, and closure condition.

17.5.3.4 Shared accounts shall be prohibited except where specifically approved for a narrow operational purpose with compensating controls, logging, and accountability. Service accounts shall have named stewards, limited permissions, rotation requirements, monitoring, and closure conditions.

17.5.3.5 Identity Management shall include onboarding controls, role verification, affiliation disclosure where relevant, conflict disclosure where relevant, acceptable-use acknowledgment, confidentiality acknowledgment where required, security training where appropriate, public-safe boundary acknowledgment where relevant, and no-overclaim acknowledgment where relevant.

17.5.3.6 Identity changes shall be recorded where a person’s role changes from participant to reviewer, reviewer to operator, partner engineer to support user, volunteer to staff, public authority learner to observer, or any other role change affecting access, conflict status, confidentiality, or boundary discipline.

17.5.3.7 Identity Management ensures that every action in Nexus Acceleration can be attributed to an authorized role and every role can be closed when its purpose ends.

***

#### 17.5.4 Access Management

17.5.4.1 Access Management means the authorization, limitation, recertification, monitoring, modification, suspension, and termination of access to Nexus Acceleration systems, data, repositories, rooms, dashboards, cloud environments, secure enclaves, clean rooms, controlled rooms, public authority learning rooms, data rooms, APIs, logs, models, software, and operational tools.

17.5.4.2 Access Management shall require role-based access, least privilege, need-to-know justification, time-bound permissions, access approvals, separation of duties, access logging, periodic recertification, access termination, and emergency revocation capability.

17.5.4.3 Access requests shall identify requester, identity, role, affiliation, purpose, requested data or system, data class, environment, duration, approving steward, conditions, restrictions, prohibited actions, logging requirements, and closure date.

17.5.4.4 Access to restricted data, public authority data, health-sensitive data, infrastructure-sensitive data, cyber-sensitive data, community-sensitive data, protected knowledge, Indigenous-sensitive data where applicable, sensitive geospatial data, sensitive social data, sensitive operational data, partner-confidential data, market-sensitive data, or no-publication materials shall require heightened review and shall not be granted through general participation status.

17.5.4.5 Separation of duties shall be used where appropriate to prevent one person or role from controlling intake, access approval, technical operation, output review, publication, correction, and archive for sensitive pathways without review.

17.5.4.6 Access recertification shall occur periodically and upon role change, event closure, research run completion, support period completion, incident, data classification change, custody change, public-safe status change, or handoff consideration.

17.5.4.7 Access Management ensures that participation never becomes uncontrolled system reach.

***

#### 17.5.5 Privileged Access

17.5.5.1 Privileged Access means elevated administrative, security, infrastructure, repository, cloud, data, secrets, key management, logging, monitoring, deployment, configuration, or environment control access granted to administrators, engineers, security staff, data stewards, cloud operators, repository maintainers, system owners, temporary stack operators, secure-room operators, incident responders, and other authorized technical personnel.

17.5.5.2 Privileged Access shall be exceptional, justified, recorded, time-bound where feasible, role-specific, least-privilege, monitored, logged, and subject to enhanced review. Privileged Access shall not be granted merely because a person is senior, a founder, a partner engineer, a sponsor representative, a provider employee, a trusted volunteer, a public authority participant, or a technical expert.

17.5.5.3 Privileged Access records shall identify the privileged user, role, access scope, systems covered, data exposure risk, approval basis, start date, end date, monitoring requirements, logging requirements, emergency access status, credential type, secrets exposure risk, review date, revocation condition, and archive status.

17.5.5.4 Privileged Access shall be separated from ordinary research, review, sponsor, provider, capital-reader, media, public authority learning, and community participation roles. Persons with privileged access shall be subject to conflict controls where their operational role could influence evidence, benchmark records, readiness notes, public-safe outputs, or routing decisions.

17.5.5.5 Privileged Access shall use strong authentication, secure administrative channels, privileged account management where available, session logging where appropriate, change logging, approval workflows, and rapid revocation.

17.5.5.6 Emergency Privileged Access may be granted for incident response, outage response, security containment, data protection, public safety, or teardown, but shall be documented after use, reviewed, and revoked when the emergency purpose ends.

17.5.5.7 Privileged Access is necessary for operation but dangerous without record, oversight, and closure.

***

#### 17.5.6 Secrets Management

17.5.6.1 Secrets Management means the secure creation, storage, use, rotation, revocation, monitoring, and closure of API keys, tokens, passwords, credentials, certificates, encryption keys, signing keys, private keys, environment variables, service-account credentials, database credentials, repository credentials, cloud credentials, room access secrets, integration secrets, and emergency access credentials.

17.5.6.2 Secrets shall not be stored in source code, public repositories, unencrypted files, shared documents, chat messages, screenshots, notebooks, public-safe reports, readiness notes, public authority learning records, partner materials, sponsor materials, provider materials, media materials, or uncontrolled local devices.

17.5.6.3 Secrets shall be stored in approved secret-management systems or otherwise protected through appropriate security controls, encryption, access restrictions, logging, and role separation. Access to secrets shall be limited to authorized users and workloads with a recorded need.

17.5.6.4 Secrets Management records shall identify secret type, steward, system, permitted use, access users or workloads, rotation schedule, expiration, storage location, key custody where relevant, emergency access conditions, revocation trigger, and incident pathway.

17.5.6.5 Secrets shall be rotated or revoked when access periods end, roles change, contributors exit, partner support ends, public authority learning rooms close, Nexus Universe temporary stacks tear down, incidents occur, exposure is suspected, repositories are compromised, logs reveal leakage, or continued use is no longer necessary.

17.5.6.6 Emergency access secrets shall be time-bound, controlled, monitored, logged, reviewed after use, and revoked or rotated as soon as the emergency purpose ends.

17.5.6.7 Secrets Management ensures that technical access cannot persist invisibly after the authorization behind it has ended.

***

#### 17.5.7 Logging and Monitoring

17.5.7.1 Logging and Monitoring means the required recording, observation, review, alerting, and retention of access, workload activity, data-room actions, secure-room actions, clean-room actions, repository activity, administrative changes, data exports, output releases, security events, system health, authentication events, authorization events, privileged actions, configuration changes, cloud activity, API activity, model or workload activity, and incident indicators.

17.5.7.2 Logging shall apply to systems, repositories, cloud environments, secure enclaves, clean rooms, controlled rooms, no-download environments, data rooms, public authority learning rooms, dashboards, observability systems, AI workflows, digital twins, simulations, APIs, partner environments, temporary stacks, and archive systems according to risk and classification.

17.5.7.3 Logs shall capture, where appropriate, user identity, role, timestamp, system, action, data accessed, workload executed, output generated, export attempted, administrative change, access change, credential event, error, security alert, and review outcome.

17.5.7.4 Monitoring shall be used to detect unauthorized access, suspicious activity, excessive access, prohibited downloads, credential misuse, privilege escalation, unusual data movement, repository secrets, unapproved workloads, output leakage, access from unexpected locations, insecure configurations, system failures, and incident indicators.

17.5.7.5 Logging and Monitoring records shall be classified, protected, retained, and archived according to sensitivity. Logs may contain personal data, operational data, public authority-sensitive data, partner-confidential data, cyber-sensitive information, or security-sensitive information and shall not be treated as ordinary public records.

17.5.7.6 Monitoring shall not be used for unauthorized surveillance, profiling, retaliation, public authority substitution, labor misuse, community targeting, or non-security purposes inconsistent with the recorded purpose and applicable law.

17.5.7.7 Logging and Monitoring make security review possible, but the logs themselves must also be protected.

***

#### 17.5.8 Incident Response and Security Operations

17.5.8.1 Incident Response and Security Operations mean the processes for detection, triage, containment, investigation, escalation, notification, correction, recovery, post-incident review, archive, and renewal of cybersecurity events, access misuse, credential exposure, data exposure, system failure, repository compromise, cloud misconfiguration, malware, vulnerability discovery, output leakage, no-download breach, partner-system issue, public authority data incident, sensitive operational data incident, or other technical security concern.

17.5.8.2 Incident Response shall include intake, severity classification, affected systems, affected data, affected users, affected public authorities where relevant, affected communities where relevant, containment action, evidence preservation, access suspension, credential rotation, system isolation, data quarantine, notification assessment, correction action, recovery plan, post-incident review, and archive.

17.5.8.3 Security Operations shall include security monitoring, vulnerability management, configuration review, patching, dependency review, repository scanning, secrets scanning, access review, privileged access review, cloud security review, endpoint controls where applicable, backup and recovery review, secure-room operations, and teardown verification.

17.5.8.4 Incidents shall be escalated to GCRI where technical systems, software, evidence records, compute, AI, cyber, repository, benchmark, observability, or data handling matters are implicated; to GRF where public-safe reporting, claims, public trust, public authority overclaim, sponsor/provider public claims, or public narrative is implicated; to GRA where readiness materials, finance-facing records, insurance-facing records, donor or public finance materials, or handoff dependency records are implicated; to National Nodes where national data, public authority context, local law, community safeguards, or national continuity are implicated; and to legal, privacy, cyber, public authority, Indigenous protocol, or safeguard review where required.

17.5.8.5 Notifications shall be made only through appropriate lawful, contractual, institutional, public authority, participant, partner, community, Indigenous where applicable, or public-safe pathways, and shall avoid disclosing additional sensitive information.

17.5.8.6 Post-incident review shall identify root cause, affected records, correction actions, access closure, data closure, public-safe implications, lessons learned, renewal actions, template changes, training needs, and archive classification.

17.5.8.7 Incident Response and Security Operations protect Nexus Acceleration by making security failure actionable, correctable, and institutionally remembered.

***

#### 17.5.9 Access Closure

17.5.9.1 Access Closure means the required termination, revocation, disabling, deletion, expiration, credential rotation, session closure, key rotation, repository removal, room-access closure, dashboard access closure, data-room closure, cloud-account closure, partner access closure, volunteer access closure, public authority room access closure, secure-enclave closure, API access closure, and audit confirmation required after events, support periods, research runs, volunteer assignments, partner contributions, role changes, incident response, withdrawal, suspension, termination, non-renewal, archive, or teardown.

17.5.9.2 Access Closure shall apply to persons, service accounts, API keys, credentials, tokens, certificates, SSH keys, cloud accounts, repository permissions, dashboards, data rooms, secure rooms, clean rooms, controlled rooms, logs, notebooks, environments, virtual machines, containers, storage buckets, model registries, collaboration tools, communication tools, and partner systems.

17.5.9.3 Access Closure records shall identify account or access pathway, user or workload, role, system, data class, closure trigger, closure action, closure date, credential rotation status, residual access, residual data, steward, verification method, exceptions, and archive status.

17.5.9.4 Access shall close when a Nexus Universe event ends, a research run closes, a Working Group assignment ends, a Competence Cell role ends, a partner contribution ends, a sponsor support period ends, a provider support period ends, a public authority learning room closes, a volunteer assignment ends, a staff role changes, a conflict arises, an incident occurs, a data agreement expires, an archive pathway replaces active use, or continued access is no longer required.

17.5.9.5 Access Closure shall include review of local downloads, synchronized folders, shared links, notebooks, copied data, temporary files, caches, logs, browser sessions, personal devices where applicable, and partner engineer access where risk requires.

17.5.9.6 Access Closure failures shall be treated as security incidents where access persists beyond purpose, authorization, role, agreement, event, or lawful basis.

17.5.9.7 Access Closure is the proof that temporary trust has ended.

***

#### 17.5.10 Cybersecurity Summary Clause

17.5.10.1 Nexus Acceleration’s public-good legitimacy depends on security controls strong enough to protect people, data, infrastructure, partners, public authorities, communities, protected knowledge, research integrity, operational continuity, and public trust.

17.5.10.2 The Cybersecurity Baseline establishes security requirements for Nexus Acceleration, Nexus Universe, Nexus Network, National Nodes, repositories, data rooms, cloud environments, partner systems, and temporary stack operations. The Zero Trust Principle confirms that no user, device, workload, partner, room, node, or system is trusted by default and that all access must be authenticated, authorized, limited, monitored, and revocable. Identity Management governs researchers, volunteers, partners, public authorities, reviewers, technical mentors, Working Group members, Competence Cells, and operations personnel. Access Management requires role-based access, least privilege, time-bound permissions, access approvals, recertification, separation of duties, and access termination. Privileged Access rules govern administrators, engineers, security staff, data stewards, cloud operators, repository maintainers, and temporary stack operators. Secrets Management governs API keys, tokens, credentials, certificates, encryption keys, environment variables, service accounts, and emergency access. Logging and Monitoring cover access, workload activity, data-room actions, repository activity, administrative changes, security events, data exports, and system health. Incident Response and Security Operations govern detection, triage, containment, investigation, escalation, notification, correction, recovery, post-incident review, and archive. Access Closure is required after events, support periods, research runs, volunteer assignments, partner contributions, role changes, incident response, withdrawal, or teardown.

17.5.10.3 No Cybersecurity Baseline record, Zero Trust control, Identity Management record, Access Management record, Privileged Access record, Secrets Management record, Logging or Monitoring record, Incident Response record, Security Operations record, Access Closure record, access approval, privileged account, service account, security review, vulnerability review, repository scan, cloud security review, incident archive, post-incident review, correction notice, restricted archive, secure-room access, cloud access, repository access, dashboard access, public authority learning room access, data-room access, partner access, sponsor access, provider access, volunteer access, National Node access, Nexus Universe temporary stack access, or public communication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, privacy compliance certification, security certification, cyber compliance certification, vendor validation, standards conformance, operational authorization, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.5.10.4 The controlling Cybersecurity Formula is that systems may be built, identities may be issued, access may be granted, privileges may be elevated, secrets may be used, logs may be collected, systems may be monitored, incidents may be contained, operations may recover, and access may close; but access is not trust, privilege is not authority, contribution is not control, logging is not surveillance permission, monitoring is not public authority function, incident response is not security certification, closure is not erasure of accountability, and Nexus Acceleration shall remain credible only where every technical pathway can be authenticated, authorized, limited, observed, corrected, and closed.

### 17.6 AI Use, AI Output Review, Agentic Systems, Human Review, Provenance, Prompt and Workflow Logs Where Appropriate, Automated Claim Prevention, and AI Boundary Incidents

#### 17.6.1 AI Use Scope

17.6.1.1 AI Use Scope means the permitted, bounded, provenance-aware, human-reviewed, safeguard-bound, claims-safe, and correctionable use of artificial intelligence, machine learning, foundation models, generative AI, retrieval systems, agentic systems, decision-support systems, analytics systems, coding assistants, translation tools, summarization tools, observability tools, simulation tools, digital twin systems, anomaly-detection systems, workflow automation tools, and related AI-enabled capabilities within Nexus Acceleration.

17.6.1.2 Permitted AI use may include research support, evidence synthesis, literature organization, data preparation, coding support, documentation support, translation support, accessibility support, public-safe summary drafting, controlled vocabulary support, ontology support, knowledge graph support, observability signal organization, simulation assistance, digital twin support, benchmark assistance, workflow automation, repository assistance, technical troubleshooting, quality review support, and drafting support for records subject to human review.

17.6.1.3 AI may support Nexus Acceleration only as a tool for bounded assistance. AI shall not be treated as a decision-maker, certifier, public authority, finance actor, insurer, procurement reviewer, community representative, Indigenous representative, safeguard authority, legal authority, ethics authority, or execution actor.

17.6.1.4 AI use shall be classified according to task risk, data sensitivity, model type, tool capability, output class, downstream use, public-safe risk, public authority relevance, finance relevance, procurement relevance, cyber risk, privacy risk, protected knowledge risk, Indigenous protocol risk where applicable, and human review need.

17.6.1.5 AI use involving restricted data, rights-bearing data, health-sensitive data, public authority data, protected knowledge, Indigenous-sensitive data where applicable, community-sensitive data, sensitive geospatial data, sensitive social data, cyber-sensitive data, infrastructure-sensitive data, partner-confidential data, market-sensitive data, or sensitive operational data shall require heightened authorization, controlled environment, access logging, output review, and publication limits.

17.6.1.6 AI use shall not convert generated text, model output, automated analysis, synthetic output, classification, recommendation, translation, benchmark interpretation, risk summary, public-safe summary, readiness note, or routing suggestion into an institutional record until competent human review and record classification occur.

17.6.1.7 AI is permitted in Nexus Acceleration only as bounded intelligence support, never as unreviewed institutional authority.

***

#### 17.6.2 AI Use Authorization

17.6.2.1 AI Use Authorization means the recorded approval, limitation, classification, and control of AI use based on data sensitivity, task risk, model type, system capability, tool access, human review need, output class, partner system involvement, publication risk, jurisdictional conditions, and safeguard requirements.

17.6.2.2 AI Use Authorization shall identify the intended task, user or role, model or system where appropriate, provider or environment where appropriate, data class, source materials, permitted inputs, prohibited inputs, permitted outputs, prohibited outputs, tool-use permissions, external connectivity, logging requirements, retention conditions, human reviewer, public-safe classification, and correction pathway.

17.6.2.3 AI use involving public, non-sensitive, low-risk materials may be authorized through general controls where output is reviewed before record use. AI use involving controlled, restricted, confidential, sovereign-sensitive, rights-bearing, health-sensitive, public authority-sensitive, infrastructure-sensitive, cyber-sensitive, geospatial-sensitive, community-sensitive, protected knowledge, Indigenous-sensitive where applicable, or no-publication materials shall require specific authorization and controlled handling.

17.6.2.4 AI tools shall not receive restricted data, protected knowledge, public authority-sensitive data, health-sensitive data, personal data, sensitive geospatial data, sensitive operational data, source code secrets, credentials, confidential partner materials, or non-public Nexus records unless the tool, environment, access control, legal basis, data handling record, and output review are approved for that data class.

17.6.2.5 Partner-provided AI systems, sponsor-provided AI systems, provider tools, cloud AI services, external APIs, open models, local models, secure models, and internal models shall be evaluated for data retention, training use, logging, access by provider personnel, model improvement use, jurisdiction, security, confidentiality, output risks, and contractual restrictions before use with non-public materials.

17.6.2.6 AI Use Authorization shall be updated where the task changes, data changes, model changes, tool capability changes, external connectivity changes, output class changes, publication pathway changes, public authority relevance changes, finance relevance changes, or incident risk changes.

17.6.2.7 AI Use Authorization ensures that AI enters Nexus Acceleration through recordable permission, not convenience.

***

#### 17.6.3 AI Output Review

17.6.3.1 AI Output Review means the mandatory human and safeguard review of AI-generated or AI-assisted outputs before such outputs are used as Nexus records, public-safe summaries, evidence summaries, technical reports, readiness notes, public authority learning materials, benchmark interpretations, Docket items, Nexus Rail routing notes, Nexus Universe outputs, public communications, repository materials, translations, accessibility materials, or handoff dependency records.

17.6.3.2 AI Output Review shall assess accuracy, hallucination, unsupported claims, source fidelity, missing context, uncertainty, bias, discriminatory effect, privacy risk, re-identification risk, sensitive inference, protected knowledge exposure, Indigenous-sensitive information where applicable, sensitive data leakage, cyber misuse, infrastructure exposure, sensitive geospatial exposure, public authority overclaim, finance overclaim, procurement overclaim, insurance overclaim, donor commitment overclaim, public finance overclaim, consent overclaim, representation overclaim, public warning implication, and deployment implication.

17.6.3.3 AI Output Review shall verify that any factual statement, technical statement, benchmark statement, public authority statement, finance statement, legal statement, safeguard statement, community statement, Indigenous statement where applicable, or public-safe statement is supported by an appropriate record, source, reviewer, or limitation statement.

17.6.3.4 AI Output Review shall identify whether the output is acceptable, requires correction, requires source verification, requires redaction, requires restricted circulation, requires additional review, requires public-safe revision, requires technical review, requires GCRI review, requires GRF claims review, requires GRA readiness review, requires safeguard review, requires legal review, requires National Node review, requires Indigenous protocol review where applicable, or must be withdrawn.

17.6.3.5 AI outputs shall not be used to create claims of certification, validation, approval, readiness, financeability, insurability, donor support, public finance allocation, public authority decision, procurement status, consent, representation, deployment authorization, or execution authority.

17.6.3.6 AI Output Review records shall identify the AI system or class where appropriate, source materials, output version, reviewer, review date, corrections made, limitations, public-safe class, prohibited uses, and archive status.

17.6.3.7 AI Output Review is the control that prevents generated fluency from becoming institutional fact.

***

#### 17.6.4 Agentic Systems

17.6.4.1 Agentic Systems mean AI systems capable of tool use, multi-step actions, autonomous or semi-autonomous workflows, code execution, API access, file access, repository interaction, browser interaction, database querying, system interaction, workflow orchestration, environment modification, task planning, data transformation, or action execution beyond a single passive response.

17.6.4.2 Agentic Systems may be used only where sandboxing, permissions, access limits, logging, monitoring, approved tools, approved workloads, human oversight, stop-the-line triggers, and rollback or containment mechanisms are defined and recorded.

17.6.4.3 Agentic Systems shall not receive autonomous authority to approve records, publish materials, release outputs, transfer data, access restricted data, send external communications, alter public materials, modify repositories, change permissions, contact public authorities, contact communities, contact Indigenous actors where applicable, contact sponsors or providers, initiate finance-facing communications, initiate procurement communications, execute transactions, create accounts, rotate secrets, deploy systems, or take operational action unless specifically authorized under a controlled workflow with human oversight.

17.6.4.4 Agentic workflows shall be assigned permitted tools, prohibited tools, data classes, execution environment, network access status, file-system access status, API access status, code execution limits, runtime limits, output destinations, logging requirements, and human approval checkpoints.

17.6.4.5 Agentic Systems shall operate in sandboxed or least-privilege environments wherever feasible. Production systems, public authority environments, restricted repositories, sensitive datasets, secure rooms, partner systems, and live operations shall not be exposed to agentic systems without specific risk review and authorization.

17.6.4.6 Agentic Systems shall be monitored for tool misuse, prompt injection, data exfiltration, unauthorized external calls, unsafe code execution, hallucinated actions, privilege escalation, policy bypass, malicious instructions, unapproved publication, and output leakage.

17.6.4.7 Agentic Systems are permitted only when their capacity to act is narrower than the human responsibility governing them.

***

#### 17.6.5 Human Review

17.6.5.1 Human Review means the required review by a competent person, steward, reviewer, technical reviewer, public-safe reviewer, readiness reviewer, safeguard reviewer, data steward, National Node reviewer, or other authorized human reviewer before AI outputs become Nexus records, public-safe summaries, readiness notes, public authority learning materials, benchmark interpretations, translations, public communications, routing notes, repository materials, Docket items, Nexus Universe outputs, or claims-bearing outputs.

17.6.5.2 Human Review shall confirm that the AI output is accurate enough for its use, bounded by available evidence, free from unsupported claims, appropriately uncertain, properly classified, public-safe, consistent with controlled vocabulary, consistent with role boundaries, and compliant with applicable safeguards.

17.6.5.3 Human Review shall be heightened where outputs involve technical claims, public authority learning, finance-readiness, insurance-readiness, donor-readiness, public finance relevance, public-safe reporting, community participation, Indigenous participation where applicable, health-sensitive data, protected knowledge, sensitive geospatial information, cyber-sensitive information, infrastructure-sensitive information, public communications, or lawful handoff dependencies.

17.6.5.4 Human Review shall not be nominal. The reviewer shall have access to sufficient source materials, output context, limitations, intended use, data classification, and prohibited claims to determine whether the output may proceed.

17.6.5.5 Human reviewers shall correct, reject, restrict, reroute, or escalate AI outputs where output quality, claims discipline, data leakage, bias, safeguard risk, public-safe risk, public authority confusion, finance overclaim, consent overclaim, or other boundary risk exists.

17.6.5.6 Human Review records shall identify reviewer, role, review scope, output reviewed, source basis, review findings, corrections, limitations, approval for use if any, prohibited uses, public-safe class, and correction pathway.

17.6.5.7 Human Review preserves the rule that AI may assist institutional work but shall not become institutional judgment.

***

#### 17.6.6 Provenance

17.6.6.1 Provenance means the recorded source, method, model, system, workflow, reviewer, date, limitation, classification, and correction basis for AI outputs used in Nexus Acceleration.

17.6.6.2 Provenance for AI outputs shall include, where appropriate and safe, source materials used, Dataset Records, retrieval sources, model or system used, model version or system version where available, tool chain, prompts or workflow logs where appropriate, configuration, compute environment, human reviewer, review date, output version, limitations, public-safe classification, access class, and correction pathway.

17.6.6.3 Provenance shall be sufficient to allow bounded interpretation, source verification, reproducibility review where feasible, public-safe review, correction, incident response, archive, and future review.

17.6.6.4 Provenance records shall protect sensitive prompts, confidential source materials, protected knowledge, personal data, public authority-sensitive information, partner-confidential information, secrets, credentials, cyber-sensitive information, and other restricted information. Provenance does not require unsafe disclosure of sensitive logs.

17.6.6.5 AI outputs without adequate provenance shall not be used for claims-bearing outputs, public-safe reports, readiness notes, public authority learning materials, benchmark interpretations, public communications, or handoff dependency records unless the absence of provenance is recorded as a limitation and the output is independently verified or restricted.

17.6.6.6 Provenance shall distinguish AI-generated content, AI-assisted content, human-authored content, human-reviewed AI content, retrieved source content, synthetic content, simulated content, translated content, and corrected content.

17.6.6.7 Provenance makes AI outputs traceable enough to correct.

***

#### 17.6.7 Prompt and Workflow Logs Where Appropriate

17.6.7.1 Prompt and Workflow Logs Where Appropriate means the preservation, restriction, classification, review, and archive of prompts, workflow logs, tool-use traces, configuration records, retrieval records, model settings, code execution logs, agent action traces, output versions, and human review notes where needed for reproducibility, accountability, incident response, public-safe review, correction, audit-support, or institutional memory.

17.6.7.2 Prompt and workflow logs shall be preserved where AI use involves restricted or sensitive data, public authority learning, readiness notes, public-safe reports, benchmark interpretation, agentic workflows, code execution, repository changes, data transformations, public communications, translations, high-impact summaries, or lawful handoff dependency records.

17.6.7.3 Prompt and workflow logs may be restricted or minimized where they contain personal data, protected knowledge, Indigenous-sensitive information where applicable, confidential public authority context, partner-confidential materials, secrets, credentials, cyber-sensitive details, sensitive geospatial data, sensitive social data, or other information that should not be broadly exposed.

17.6.7.4 Prompt and workflow logs shall identify, where appropriate, the user or workflow, date, task, source materials, prompt or instruction summary, tool calls, data accessed, outputs generated, edits made, human reviewer, classification, retention period, deletion or archive conditions, and incident pathway.

17.6.7.5 Prompt and workflow logs shall not be used for unauthorized surveillance, labor misuse, participant profiling, public authority substitution, community targeting, or purposes inconsistent with the recorded AI use authorization.

17.6.7.6 Where prompt or workflow logging is not appropriate because it would capture excessive sensitive data, create additional risk, violate legal or contractual constraints, or conflict with protected knowledge safeguards, a record of non-logging rationale and alternative accountability controls shall be maintained.

17.6.7.7 Prompt and workflow logs are accountability records, not public materials.

***

#### 17.6.8 Automated Claim Prevention

17.6.8.1 Automated Claim Prevention means the technical, procedural, review, vocabulary, template, and publication controls preventing AI systems from generating, approving, publishing, routing, amplifying, or embedding unsupported claims of certification, validation, approval, readiness, financeability, insurability, public warning, endorsement, consent, representation, procurement status, public authority approval, donor commitment, public finance allocation, deployment authorization, handoff authorization, or execution authority.

17.6.8.2 Automated Claim Prevention shall apply to AI drafting, AI summarization, AI translation, AI public-safe reporting assistance, AI readiness note drafting, AI benchmark interpretation, AI public authority learning materials, AI community summaries, AI sponsor/provider materials, AI media materials, AI website content, AI repository documentation, AI chat interfaces, AI dashboards, AI agents, and AI workflow automation.

17.6.8.3 Controls may include controlled vocabulary, prohibited claim lists, template constraints, mandatory disclaimers, output filters, human approval checkpoints, publication holds, claims review, role-boundary prompts, restricted terms, automated detection of overclaim language, and stop-the-line escalation for high-risk outputs.

17.6.8.4 AI systems shall not autonomously label an object as certified, validated, approved, financeable, insurable, procurement-ready, consented, endorsed, official, authorized, deployed, Nexus-ready, standards-conformant, or implementation-ready unless such status is separately and lawfully recorded and the AI output is human-reviewed for public-safe use.

17.6.8.5 AI translation or localization shall preserve boundary language and shall not translate bounded terms into stronger authority terms, approval terms, finance terms, official-position terms, consent terms, or deployment terms.

17.6.8.6 Automated Claim Prevention failures shall be treated as AI Boundary Incidents where outputs generate or publish claims capable of misleading public audiences, public authorities, communities, sponsors, providers, capital readers, insurers, donors, procurement actors, or handoff actors.

17.6.8.7 Automated Claim Prevention protects Nexus Acceleration from machine-generated overclaim at scale.

***

#### 17.6.9 AI Boundary Incidents

17.6.9.1 AI Boundary Incident means any actual, suspected, or potential event involving hallucinated claims, unsupported factual statements, unsafe publication, data leakage, protected knowledge exposure, Indigenous-sensitive information exposure where applicable, privacy breach, sensitive geospatial exposure, cyber-sensitive disclosure, infrastructure-sensitive disclosure, unauthorized tool use, autonomous action beyond permission, unapproved code execution, unapproved data transfer, prompt injection, model misuse, synthetic misrepresentation, deepfake or misleading synthetic content, unauthorized public-facing output, translation distortion, benchmark misuse, public authority overclaim, finance overclaim, procurement overclaim, consent overclaim, or deployment overclaim arising from AI use.

17.6.9.2 AI Boundary Incidents may occur in drafting, summarization, coding, data analysis, observability workflows, simulations, digital twins, public authority learning, readiness translation, public-safe reporting, translation, repository work, public communications, agentic workflows, dashboards, partner systems, sponsor materials, provider materials, media materials, or handoff dependency records.

17.6.9.3 AI Boundary Incident intake shall identify the AI system or workflow where appropriate, user or role, source materials, output, affected record, affected audience, data class, tool actions, public exposure, claim risk, privacy risk, protected knowledge risk, cyber risk, public authority risk, finance or procurement risk, consent or representation risk, containment action, review pathway, correction action, notice need, and archive status.

17.6.9.4 Response measures may include output withdrawal, publication hold, restricted circulation, access suspension, workflow suspension, tool disablement, prompt or template correction, human review, source verification, redaction, public-safe clarification, public notice where required, participant or community notice where appropriate, Indigenous notice where applicable, public authority notice where appropriate, sponsor/provider correction, model or system restriction, incident review, and archive.

17.6.9.5 Autonomous action beyond permission shall require immediate containment where an AI system accessed data, called an API, modified a repository, sent a message, changed a record, executed code, exported an output, created an account, altered permissions, or interacted with systems outside approved scope.

17.6.9.6 Synthetic misrepresentation shall include AI-generated text, images, audio, video, data, maps, dashboards, personas, community statements, public authority statements, or evidence artifacts that are presented or reasonably understood as real, official, consented, verified, or human-authored when they are not.

17.6.9.7 AI Boundary Incidents shall be archived with lessons learned, updated AI authorizations, revised prompts, revised templates, revised automated claim prevention controls, revised access controls, and renewed training where required.

***

#### 17.6.10 AI Use Summary Clause

17.6.10.1 AI may strengthen Nexus Acceleration only when it is provenance-aware, human-reviewed, safeguard-bound, claims-safe, access-controlled, output-reviewed, non-autonomous beyond permission, and correctionable.

17.6.10.2 AI Use Scope permits AI across research support, evidence synthesis, observability, simulations, digital twins, translation, coding, documentation, public-safe summaries, workflow automation, and technical assistance. AI Use Authorization governs AI use based on data sensitivity, task risk, model type, human review need, output class, partner system involvement, and publication risk. AI Output Review requires review for accuracy, hallucination, bias, uncertainty, privacy, protected knowledge, sensitive data leakage, cyber misuse, public authority overclaim, finance overclaim, and consent overclaim. Agentic Systems are AI systems capable of tool use, multi-step actions, autonomous workflows, code execution, API access, or system interaction and require sandboxing, permissions, logging, and human oversight. Human Review is required before AI outputs become records, public-safe summaries, readiness notes, public authority learning materials, benchmark interpretations, or claims-bearing outputs. Provenance for AI outputs includes source materials, model or system used where appropriate, prompts or workflow logs where appropriate, human reviewer, date, limitations, and classification. Prompt and Workflow Logs shall be preserved where needed for reproducibility, accountability, incident response, or public-safe review. Automated Claim Prevention prevents AI systems from generating or publishing unsupported claims of certification, approval, readiness, financeability, insurability, public warning, endorsement, consent, or deployment authorization. AI Boundary Incidents include hallucinated claims, unsafe publication, data leakage, unauthorized tool use, autonomous action beyond permission, synthetic misrepresentation, or improper public-facing output.

17.6.10.3 No AI Use Authorization, AI Output Review, Agentic System record, Human Review record, Provenance record, Prompt Log, Workflow Log, Automated Claim Prevention control, AI Boundary Incident record, AI-generated output, AI-assisted output, AI translation, AI summary, AI code, AI benchmark interpretation, AI dashboard, AI model output, AI workflow, AI agent action, AI routing suggestion, AI public-safe summary, AI readiness note, AI public authority learning material, AI repository artifact, AI correction notice, AI incident archive, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, Handoff Dependency Note, public communication, restricted archive, or publication record shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, privacy compliance certification, security certification, AI safety certification, benchmark validation, standards conformance, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.6.10.4 The controlling AI Use Formula is that AI may assist, summarize, translate, code, classify, simulate, observe, draft, route, and automate bounded workflows; but AI output is not truth, fluency is not evidence, generation is not approval, translation is not legal transformation, agentic action is not authority, logs are not public materials, provenance is not validation, human review is not certification, automated claims are not institutional decisions, and Nexus Acceleration shall use AI only where humans, records, safeguards, provenance, access limits, and correction pathways remain stronger than the automation.

### 17.7 Model Cards, System Cards, Benchmark Records, AI Claims Boundaries, Non-Generalization, Uncertainty, Red-Team Notes Where Appropriate, and Correction

#### 17.7.1 Model Card Requirement

17.7.1.1 Model Card Requirement means the requirement that each AI model, machine-learning model, foundation model, fine-tuned model, domain model, classification model, forecasting model, simulation-assist model, geospatial model, risk-intelligence model, language model, vision model, agent-support model, or other model materially used in Nexus Acceleration be accompanied, where appropriate, by a structured Model Card sufficient to support bounded interpretation, authorized use, human review, safeguard review, public-safe review, correction, and archive.

17.7.1.2 A Model Card shall identify, as applicable, the model name or class, version or release where known, steward, provider or source where appropriate, purpose, intended use, prohibited use, data context, training or source context where available and appropriate, evaluation basis, known limitations, uncertainty, risk profile, safeguard conditions, data sensitivity conditions, access conditions, human review requirements, output review requirements, public-safe classification, correction pathway, and archive status.

17.7.1.3 A Model Card shall distinguish intended Nexus uses from prohibited or unsupported uses. A model approved for summarization shall not be treated as approved for risk scoring. A model approved for coding assistance shall not be treated as approved for public authority learning. A model approved for internal drafting shall not be treated as approved for public-safe publication. A model approved for research assistance shall not be treated as approved for deployment, decision-making, or automation of authority.

17.7.1.4 A Model Card shall identify whether the model may be used with public data, controlled data, restricted data, rights-bearing data, health-sensitive data, public authority-sensitive data, infrastructure-sensitive data, cyber-sensitive data, community-sensitive data, protected knowledge, Indigenous-sensitive data where applicable, sensitive geospatial data, partner-confidential data, market-sensitive data, or no-publication data.

17.7.1.5 A Model Card shall include limitations and uncertainty statements sufficient to prevent overclaim, including known failure modes, hallucination risk, bias risk, incompleteness, limited evaluation conditions, domain limitations, language limitations, geographic limitations, temporal limitations, data limitations, reproducibility limits, and human review requirements.

17.7.1.6 A Model Card shall not constitute certification, validation, safety approval, compliance approval, public authority fitness, provider endorsement, market approval, procurement qualification, deployment suitability, financeability, insurability, or execution authorization.

17.7.1.7 Model Cards make AI use interpretable by recording what a model is for, what it is not for, what is known, what is uncertain, and how misuse must be corrected.

***

#### 17.7.2 System Card Requirement

17.7.2.1 System Card Requirement means the requirement that integrated systems, agentic workflows, digital twins, telecom systems, AI-RAN/O-RAN test environments, simulations, observability systems, secure rooms, clean rooms, controlled rooms, confidential computing environments, cyber-physical systems, data rooms, dashboards, public-good software systems, temporary Nexus Universe stack environments, or other complex technical systems materially used in Nexus Acceleration be accompanied, where appropriate, by a structured System Card.

17.7.2.2 A System Card shall identify the system name or class, steward, owner or operator where relevant, purpose, components, data flows, compute environment, access controls, security controls, approved users, approved workloads, dependencies, interfaces, APIs, models used, tools used, human oversight, logging, monitoring, output review, public-safe classification, known limitations, failure modes, safeguard conditions, teardown requirements, correction pathway, and archive status.

17.7.2.3 For agentic workflows, the System Card shall identify permitted tools, prohibited tools, action limits, approval checkpoints, sandboxing conditions, external connectivity, file-system access, repository access, API access, code execution limits, autonomous action limits, stop-the-line triggers, rollback conditions, and human oversight requirements.

17.7.2.4 For digital twins, simulations, telecom systems, cyber-physical systems, or observability systems, the System Card shall identify assumptions, system boundaries, data sources, resolution, update cadence, model limits, sensitive geospatial controls, infrastructure sensitivity, public authority relevance, public safety limits, uncertainty, and prohibited interpretations.

17.7.2.5 For secure rooms, clean rooms, controlled rooms, or confidential computing environments, the System Card shall identify access rules, no-download controls, output review procedures, logging, key management where applicable, participant classes, information barriers, closure conditions, and incident pathways.

17.7.2.6 A System Card shall not be used to imply that the system is certified, secure by declaration, deployment-ready, procurement-ready, public-authority-approved, operationally authorized, standards-conformant, financeable, insurable, or validated beyond the recorded conditions.

17.7.2.7 System Cards make complex environments legible without turning complexity into authority.

***

#### 17.7.3 Benchmark Record Requirement

17.7.3.1 Benchmark Record Requirement means the requirement that AI performance, technical performance, system performance, infrastructure performance, cyber performance, compute performance, model performance, telecom performance, simulation performance, digital twin performance, observability performance, software performance, or comparative performance results used in Nexus Acceleration be recorded in a bounded Benchmark Record before being cited, summarized, compared, routed, published, or used in readiness translation.

17.7.3.2 A Benchmark Record shall identify the workload, data, environment, configuration, hardware, software, model or system version, tools, dependencies, metric, test conditions, evaluator, date, runtime, limitations, uncertainty, reproducibility status, data sensitivity, conflict disclosures, sponsor or provider involvement, public-safe classification, permitted uses, prohibited uses, and correction pathway.

17.7.3.3 A Benchmark Record shall identify whether the benchmark is single-run, repeated-run, exploratory, demonstration, controlled test, comparative test, stress test, red-team test, simulation output, field-adjacent test, lab test, secure-room test, provider-supported test, or partner-supported test.

17.7.3.4 A Benchmark Record shall state what can be reproduced, what cannot be reproduced, what depends on restricted data, what depends on partner infrastructure, what depends on specific configuration, what depends on temporary Nexus Universe conditions, what depends on hardware availability, what depends on private tools, and what remains uncertain.

17.7.3.5 Comparative Benchmark Records shall include conflict disclosures, test design limits, non-generalization language, public-safe review, provider-neutrality review, and prohibition on unsupported marketing, procurement, public authority, finance, insurance, safety, superiority, or deployment claims.

17.7.3.6 Benchmark Records shall not rank, validate, certify, approve, endorse, recommend, procure, prefer, finance, insure, or authorize a model, product, provider, system, method, project, or deployment unless a separate competent lawful process expressly does so.

17.7.3.7 Benchmark Records make performance claims bounded by conditions rather than converted into market conclusions.

***

#### 17.7.4 AI Claims Boundaries

17.7.4.1 AI Claims Boundaries mean the rules preventing unsupported, overbroad, misleading, public-facing, partner-facing, sponsor-facing, provider-facing, public authority-facing, finance-facing, procurement-facing, or handoff-facing claims concerning intelligence, autonomy, reliability, accuracy, safety, security, compliance, fairness, robustness, superiority, readiness, deployment suitability, public authority fitness, financeability, insurability, procurement eligibility, or public-good status of AI models, systems, outputs, benchmarks, simulations, digital twins, or agentic workflows.

17.7.4.2 Nexus Acceleration shall not state or imply that an AI model or system is intelligent, autonomous, reliable, safe, compliant, fair, unbiased, secure, superior, best-in-class, public-authority-ready, finance-ready, insurance-ready, procurement-ready, deployment-ready, Nexus-ready, standards-conformant, or validated unless the statement is specifically supported by a bounded record, reviewed, limited to recorded conditions, and permitted for the intended audience.

17.7.4.3 AI outputs shall not be described as truth, proof, verification, validation, determination, diagnosis, official intelligence, public warning, compliance finding, policy conclusion, public authority decision, investment conclusion, insurance conclusion, procurement conclusion, community conclusion, or deployment conclusion.

17.7.4.4 Claims concerning AI safety, fairness, reliability, cyber resilience, privacy protection, public authority usefulness, community relevance, accessibility, or finance readability shall include recorded basis, scope, limitations, uncertainty, review status, data context, and prohibited interpretations.

17.7.4.5 Public materials shall not use benchmark results, model cards, system cards, red-team notes, public authority attendance, sponsor support, provider contribution, researcher participation, or Nexus Universe visibility to imply AI validation, market legitimacy, public authority approval, procurement advantage, or deployment suitability.

17.7.4.6 AI Claims Boundaries shall be enforced through templates, controlled vocabulary, automated claim prevention, human review, GRF public-safe claims review, GCRI technical review where technical claims appear, GRA review where readiness language appears, and correction where overclaim occurs.

17.7.4.7 AI Claims Boundaries protect Nexus Acceleration from mistaking persuasive AI language for institutional truth.

***

#### 17.7.5 Non-Generalization Rule

17.7.5.1 Non-Generalization Rule means that AI, model, system, benchmark, simulation, digital twin, observability, telecom, cyber, infrastructure, compute, or technical results may not be generalized beyond the specific recorded conditions, data, workload, environment, assumptions, configuration, users, time period, toolchain, limitations, and review status under which the result was produced.

17.7.5.2 A result produced under one dataset shall not be generalized to other datasets. A result produced under one jurisdiction shall not be generalized to other jurisdictions. A result produced under one community context shall not be generalized to other communities. A result produced under one infrastructure environment shall not be generalized to other infrastructure environments. A result produced under one provider configuration shall not be generalized to other configurations. A result produced during Nexus Universe shall not be generalized to production operations.

17.7.5.3 Benchmark, model, system, or simulation results shall include non-generalization statements identifying the recorded conditions and warning against use beyond those conditions.

17.7.5.4 Non-Generalization shall apply especially to results involving small samples, restricted data, partner-provided infrastructure, pre-production technology, synthetic data, simulations, digital twins, AI outputs, public authority learning, community input, Indigenous-sensitive context where applicable, health-sensitive data, sensitive geospatial data, cyber testing, and infrastructure stress tests.

17.7.5.5 No result shall be used as a claim of universal performance, provider superiority, public authority readiness, financeability, insurability, safety, fairness, compliance, procurement eligibility, or deployment readiness unless separately supported by appropriate review and lawful authority.

17.7.5.6 Non-Generalization failures shall require correction, restriction, withdrawal, public-safe clarification, sponsor/provider correction, media correction, readiness note correction, or archive where results have been overstated.

17.7.5.7 The Non-Generalization Rule preserves the difference between what was observed and what may be claimed.

***

#### 17.7.6 Uncertainty Statements

17.7.6.1 Uncertainty Statements shall be required for models, forecasts, simulations, classifications, risk intelligence, public authority learning materials, readiness translations, insurance-readiness question maps, finance-readiness notes, donor-readiness notes, public finance relevance notes, digital twin outputs, observability summaries, geospatial intelligence outputs, benchmark records, public-safe reports, and other outputs where uncertainty materially affects interpretation.

17.7.6.2 An Uncertainty Statement shall identify, as applicable, data limitations, model limitations, assumptions, confidence limits, missing evidence, measurement error, sample limits, temporal limits, geographic limits, contextual limits, bias risks, sensitivity to inputs, reproducibility limits, scenario dependence, unresolved risks, competing interpretations, and conditions under which the output may change.

17.7.6.3 Uncertainty Statements shall be understandable to the intended audience. Public-safe uncertainty language shall not be so technical that it hides the limits of the output from communities, public authorities, public-interest participants, media, capital readers, donors, or other audiences.

17.7.6.4 Uncertainty shall not be omitted because the output is important, urgent, public-facing, sponsor-supported, provider-supported, media-visible, finance-relevant, public authority-relevant, or institutionally attractive.

17.7.6.5 Uncertainty Statements shall avoid both false certainty and false equivalence. They shall accurately describe what is known, what is unknown, what is plausible, what is unsupported, and what requires further review.

17.7.6.6 Outputs lacking sufficient uncertainty language shall be corrected, restricted, withdrawn, or relabeled before public-safe publication, readiness translation, public authority learning use, or handoff dependency inclusion.

17.7.6.7 Uncertainty Statements are the discipline that keeps learning honest while evidence is still incomplete.

***

#### 17.7.7 Red-Team Notes Where Appropriate

17.7.7.1 Red-Team Notes mean structured records of adversarial testing, misuse review, failure-mode analysis, stress testing, abuse-case analysis, safety probing, cyber review, prompt-injection testing, data leakage testing, model behavior testing, public authority overclaim testing, finance overclaim testing, emergency-language testing, public-safe publication testing, or other high-impact review conducted where AI, cyber, dual-use, public safety, public authority, infrastructure, protected knowledge, or high-impact systems require adversarial assessment.

17.7.7.2 Red-Team Notes shall be required or considered where systems involve agentic AI, autonomous workflows, code execution, external APIs, restricted data, public authority data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, sensitive geospatial data, public-facing outputs, public safety implications, dual-use capabilities, public authority learning, public warnings language, finance-facing materials, or deployment-adjacent pathways.

17.7.7.3 A Red-Team Note shall identify the system or output reviewed, test purpose, reviewer or reviewer class, test scope, methods used, misuse cases, failure modes, vulnerabilities found, limitations, data exposure risks, public-safe risks, boundary risks, remediation actions, unresolved concerns, retest needs, publication limits, and archive classification.

17.7.7.4 Red-Team Notes may be restricted where they contain security-sensitive information, cyber vulnerabilities, model exploit details, protected knowledge risks, public authority-sensitive information, infrastructure-sensitive information, or abuse instructions.

17.7.7.5 Red-Team Notes shall not be used publicly to imply that a system is safe, secure, compliant, certified, validated, public-authority-ready, deployment-ready, or free of vulnerabilities. Red-team activity identifies and reduces risk; it does not eliminate risk.

17.7.7.6 Where red-team review identifies serious risks, relevant outputs, workflows, systems, public materials, or handoff pathways shall be corrected, restricted, withdrawn, retested, rerouted, or archived until the risk is addressed or properly bounded.

17.7.7.7 Red-Team Notes make failure visible before failure becomes public harm.

***

#### 17.7.8 Model and System Correction

17.7.8.1 Model and System Correction means the required correction, withdrawal, downgrade, supersession, restricted publication, public-safe clarification, access restriction, retraining where appropriate, retesting where appropriate, revision, incident response, or archive of model cards, system cards, benchmark records, AI claims, outputs, simulations, dashboards, digital twin outputs, public authority learning materials, readiness notes, repository artifacts, or public communications when they become inaccurate, unsafe, misleading, incomplete, overclaimed, unsupported, superseded, or inconsistent with updated evidence or safeguards.

17.7.8.2 Model and System Correction shall be required where a model card omits material limitations, a system card misstates dependencies, a benchmark record overstates performance, an AI claim exceeds evidence, uncertainty is omitted, non-generalization language is missing, red-team findings are unresolved, data leakage occurs, public authority meaning is overclaimed, finance meaning is overclaimed, community or Indigenous consent is implied, or public-safe publication becomes unsafe.

17.7.8.3 Correction measures may include revised model card, revised system card, revised benchmark record, revised limitation language, revised uncertainty statement, corrected public-safe summary, benchmark withdrawal, downgrade of status, supersession note, restricted circulation, repository update, public notice where required, sponsor/provider correction, media correction, public authority clarification, readiness note correction, handoff package correction, or archive.

17.7.8.4 Model and System Correction shall identify affected record, issue, source of issue, affected outputs, affected audience, public exposure, risk class, correction action, reviewer, effective date, prohibited future uses, and archive link.

17.7.8.5 Where an output was used downstream, correction shall identify dependent records, summaries, readiness notes, public authority learning materials, public-safe reports, Docket items, ARL records, Nexus Rail routing notes, and handoff dependency records that require review or correction.

17.7.8.6 Correction shall not be delayed because the model or system is high-profile, sponsor-supported, provider-supported, public authority-visible, media-visible, finance-facing, or strategically important.

17.7.8.7 Model and System Correction keeps technical memory aligned with truth, not reputation.

***

#### 17.7.9 AI Claims Misuse

17.7.9.1 AI Claims Misuse means any misuse of model cards, system cards, benchmark records, red-team notes, AI outputs, simulation outputs, digital twin outputs, public-safe summaries, readiness notes, public authority learning records, Nexus Universe outputs, repository materials, sponsor materials, provider materials, media materials, public authority materials, finance-facing materials, donor materials, public finance materials, procurement materials, Handoff Dependency Notes, or public communications to imply unsupported intelligence, autonomy, reliability, safety, compliance, fairness, superiority, readiness, validation, certification, endorsement, public authority approval, financeability, insurability, procurement eligibility, public safety approval, deployment approval, or execution authority.

17.7.9.2 AI Claims Misuse may include marketing overclaim, provider validation claim, sponsor endorsement implication, benchmark superiority claim, public authority implication, finance implication, public finance implication, insurance implication, public safety implication, emergency-warning implication, community consent implication, Indigenous consent implication where applicable, standards-conformance implication, deployment approval implication, or handoff authorization implication.

17.7.9.3 AI Claims Misuse may occur through selective quotation, omission of limitations, omission of uncertainty, omission of benchmark conditions, omission of conflict disclosures, omission of non-generalization, mistranslation, simplified public narrative, media amplification, partner communications, sponsor communications, provider communications, investor communications, donor communications, procurement materials, or public authority references.

17.7.9.4 AI Claims Misuse shall require correction, withdrawal, public-safe clarification, restricted circulation, public repair where required, sponsor/provider notice, media correction where relevant, public authority notice where relevant, readiness note correction where relevant, handoff package correction where relevant, and archive.

17.7.9.5 AI Claims Misuse records shall identify the claim, source material, affected model or system record, audience, public exposure, overclaim type, correction action, notice action, repair action, responsible steward, and archive status.

17.7.9.6 AI Claims Misuse shall be treated as a boundary incident even where the underlying benchmark, model card, system card, or AI output was technically accurate but used beyond its recorded limits.

17.7.9.7 AI Claims Misuse is prohibited because technical records become harmful when converted into unbounded institutional, market, or authority claims.

***

#### 17.7.10 Model/System Record Summary Clause

17.7.10.1 Model cards, system cards, benchmark records, AI claims boundaries, non-generalization rules, uncertainty statements, red-team notes, and correction pathways make AI outputs and technical systems interpretable without making them authoritative.

17.7.10.2 Model Card Requirements require records for AI models, including purpose, intended use, data context, evaluation, limitations, risks, safeguards, uncertainty, prohibited uses, and correction pathway. System Card Requirements apply to integrated systems, agentic workflows, digital twins, telecom systems, simulations, secure rooms, cyber-physical systems, and temporary stack environments. Benchmark Record Requirements apply to AI and technical performance results, including workload, data, environment, configuration, hardware, software, metric, limitations, reproducibility, and non-generalization. AI Claims Boundaries prevent unsupported claims of intelligence, autonomy, reliability, safety, compliance, fairness, superiority, readiness, deployment suitability, or public authority fitness. The Non-Generalization Rule prevents AI, model, system, benchmark, or simulation results from being generalized beyond specific recorded conditions, data, workload, environment, assumptions, and limitations. Uncertainty Statements are required for models, forecasts, simulations, classifications, risk intelligence, public authority learning materials, and readiness translations. Red-Team Notes are required where AI, cyber, dual-use, public safety, public authority, or high-impact systems require adversarial testing, misuse review, or failure-mode analysis. Model and System Correction requires correction, withdrawal, downgrade, supersession, restricted publication, or archive when model cards, system cards, benchmarks, claims, or outputs become inaccurate, unsafe, misleading, or incomplete. AI Claims Misuse includes marketing overclaim, provider validation, public authority implication, finance implication, public safety implication, or deployment approval implication.

17.7.10.3 No Model Card, System Card, Benchmark Record, AI Claims Boundary record, Non-Generalization statement, Uncertainty Statement, Red-Team Note, Model and System Correction record, AI Claims Misuse record, model evaluation, system evaluation, benchmark result, red-team result, simulation result, digital twin result, AI output, public-safe summary, readiness note, public authority learning material, repository artifact, dashboard, map, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, Handoff Dependency Note, correction notice, withdrawal notice, restricted archive, public communication, sponsor material, provider material, media material, public authority material, finance-facing material, donor material, public finance material, or procurement material shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, AI safety certification, benchmark validation, security certification, standards conformance, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.7.10.4 The controlling Model/System Record Formula is that models may be described, systems may be mapped, benchmarks may be recorded, AI claims may be bounded, results may be non-generalized, uncertainty may be stated, red-team notes may reveal failure, corrections may revise the record, and misuse may be repaired; but model cards are not certification, system cards are not approval, benchmarks are not superiority, red-team notes are not safety guarantees, uncertainty is not weakness, correction is not failure, non-generalization is not optional, and Nexus Acceleration shall treat AI and technical systems as interpretable only within the records, limits, safeguards, and corrections that make their outputs safe to understand.

### 17.8 Dual-Use, Misuse, Security-Sensitive, Geospatial, Cyber-Physical, Critical Infrastructure, Telecom, AI-RAN/O-RAN, Public Safety, Biological-Sensitive, and Harmful Capability Controls

#### 17.8.1 Dual-Use Control Principle

17.8.1.1 Dual-Use Control means the rule that technologies, data, methods, models, outputs, simulations, digital twins, observability records, geospatial products, cyber materials, telecom testbed outputs, AI-RAN/O-RAN outputs, biological-sensitive materials, critical infrastructure records, public authority learning materials, public-safe reports, readiness notes, benchmark records, repository artifacts, and Nexus Universe outputs with both beneficial and harmful potential shall be reviewed for misuse, security, public safety, legal, jurisdictional, ethical, safeguard, and public-safe publication risk before use, release, routing, archive, or handoff dependency mapping.

17.8.1.2 Dual-use potential shall be assessed where an output or capability may support resilience, disaster risk reduction, public authority learning, research, observability, infrastructure protection, health protection, biodiversity protection, cyber defense, telecom resilience, WEFH-B systems learning, or public-good innovation, while also being capable of enabling harm, targeting, surveillance, cyber abuse, infrastructure disruption, unsafe automation, panic, biological misuse, protected knowledge exposure, sensitive location exposure, public authority confusion, or harmful operational use.

17.8.1.3 Dual-Use Control shall apply regardless of whether the harmful potential is intended, accidental, foreseeable through misuse, foreseeable through publication, foreseeable through aggregation, foreseeable through model inference, foreseeable through geospatial precision, foreseeable through cyber detail, foreseeable through operational specificity, or foreseeable through downstream actor misuse.

17.8.1.4 Dual-Use Control may require restriction, redaction, aggregation, delayed publication, no-publication classification, controlled-room review, secure-room review, public authority boundary review, cyber review, geospatial review, biological-sensitive review, legal review, export-control review, sanctions review, public-safe claims review, or archive.

17.8.1.5 Beneficial purpose shall not override dual-use review. Public-good intent, sponsor support, provider contribution, research importance, public authority interest, Nexus Universe visibility, media interest, readiness value, donor relevance, public finance relevance, or urgency shall not justify unsafe release or uncontrolled movement of harmful capability.

17.8.1.6 Dual-Use Control is the discipline by which Nexus Acceleration accelerates public-good capability without accelerating avoidable harm.

***

#### 17.8.2 Misuse Review

17.8.2.1 Misuse Review means the structured review of outputs, records, datasets, tools, models, code, maps, diagrams, simulations, digital twins, benchmark results, cyber findings, telecom outputs, biological-sensitive materials, public authority learning materials, and public-safe reports that could enable harm, targeting, cyber abuse, infrastructure disruption, sensitive surveillance, dangerous automation, biological misuse, public safety risk, public panic, public authority confusion, or protected knowledge exploitation.

17.8.2.2 Misuse Review shall identify who could misuse the output, what harm could result, what details are enabling, whether the output is necessary for public-good purpose, whether safer substitutes exist, whether precision can be reduced, whether publication can be delayed, whether access can be restricted, whether aggregation or redaction is required, and whether the output should be withheld.

17.8.2.3 Misuse Review shall be required where outputs include vulnerability details, exploit paths, attack surfaces, infrastructure dependencies, precise sensitive locations, operational procedures, security controls, emergency system information, public safety assets, telecom configurations, AI-RAN/O-RAN optimization details, drone or robotics operational details, biological-sensitive information, pathogen-related context, protected ecological information, or high-impact AI workflow capabilities.

17.8.2.4 Misuse Review records shall identify the output, source, data class, harmful use scenario, affected persons or systems, enabling details, public-safe risk, cyber risk, geospatial risk, public authority risk, biological-sensitive risk where applicable, infrastructure risk, publication decision, restrictions, redactions, permitted audience, prohibited use, correction pathway, and archive status.

17.8.2.5 Misuse Review may result in public release, controlled release, redacted release, delayed release, restricted circulation, secure-room-only access, public authority-only routing where lawful, National Node-only routing, archive-only retention, withdrawal, or non-continuation.

17.8.2.6 Misuse Review shall not be used to suppress legitimate public-interest correction, hide institutional error, avoid accountability, or block public-safe reporting of material risks where safe reporting can be achieved.

17.8.2.7 Misuse Review makes the harmful pathway visible before publication makes it available.

***

#### 17.8.3 Security-Sensitive Information

17.8.3.1 Security-Sensitive Information means information concerning vulnerabilities, system architecture, credentials, secrets, keys, tokens, exploit paths, attack methods, defensive gaps, critical infrastructure dependencies, sensitive maps, sensitive geospatial layers, operational procedures, security controls, monitoring systems, incident details, threat-relevant details, telecom configurations, cloud configurations, repository weaknesses, access pathways, secure-room configurations, public authority-sensitive materials, or other information that could enable harm if exposed.

17.8.3.2 Security-Sensitive Information shall be classified, access-controlled, need-to-know limited, publication-reviewed, and archived under appropriate restrictions. It shall not be included in public-safe summaries, media materials, sponsor materials, provider materials, readiness notes, public authority learning materials, repository releases, benchmark records, or handoff packages unless the level of detail is public-safe and reviewed.

17.8.3.3 Security-Sensitive Information controls may include redaction, aggregation, removal of procedural detail, removal of exploit detail, removal of precise locations, delayed publication, restricted distribution, secure-room review, vulnerability disclosure pathway, public authority notice where appropriate, operator notice where appropriate, cyber review, legal review, and archive restriction.

17.8.3.4 Credentials, secrets, keys, tokens, private exploit materials, active vulnerability details, uncontrolled proof-of-concept exploit code, sensitive incident logs, sensitive system diagrams, and operational access details shall not be publicly disclosed through Nexus Acceleration.

17.8.3.5 Security-Sensitive Information may support public-good learning only when the information is handled in a manner that does not create a new attack path, targeting path, surveillance path, panic risk, or public safety risk.

17.8.3.6 Misclassification, exposure, or unsafe publication of Security-Sensitive Information shall be treated as a security and safeguard incident requiring containment, restriction, correction, notice where appropriate, and archive.

17.8.3.7 Security-Sensitive Information remains sensitive even when it is evidence.

***

#### 17.8.4 Geospatial Risk Controls

17.8.4.1 Geospatial Risk Controls mean the rules governing maps, coordinates, imagery, spatial layers, Earth observation outputs, remote sensing records, digital twin layers, infrastructure locations, protected sites, critical assets, vulnerable communities, biodiversity locations, ecological resources, emergency assets, public safety facilities, health facilities, shelters, schools, ports, utilities, telecom assets, transportation routes, water systems, energy systems, culturally sensitive locations, Indigenous-sensitive locations where applicable, and security-sensitive places.

17.8.4.2 Geospatial Risk Controls shall assess whether spatial precision, resolution, labels, overlays, routes, facility names, exposure layers, vulnerability layers, or interdependency layers could enable targeting, stigmatization, exploitation, poaching, surveillance, sabotage, public panic, protected knowledge exposure, community harm, or public safety risk.

17.8.4.3 Geospatial outputs shall be reviewed before publication, dashboard release, public-safe reporting, public authority learning use, readiness translation, media use, Nexus Universe display, repository release, or handoff dependency inclusion.

17.8.4.4 Controls may include coordinate removal, location masking, spatial aggregation, map blurring, scale reduction, generalized boundaries, delayed release, redaction, no-publication classification, controlled room review, watermarking, access logging, and restricted archive.

17.8.4.5 Geospatial outputs involving critical infrastructure, vulnerable communities, protected ecological sites, health facilities, public safety facilities, Indigenous or culturally sensitive sites where applicable, disaster-affected locations, cyber-physical assets, or security-sensitive locations shall be treated as high-risk unless review determines otherwise.

17.8.4.6 Geospatial accuracy shall not be equated with publication permission. A map may be technically accurate and still unsafe.

17.8.4.7 Geospatial Risk Controls protect people, places, ecosystems, infrastructure, and public trust from harm caused by excessive spatial specificity.

***

#### 17.8.5 Cyber-Physical and Critical Infrastructure Controls

17.8.5.1 Cyber-Physical and Critical Infrastructure Controls mean the rules governing Nexus Acceleration work involving energy, water, telecom, transport, ports, logistics, health facilities, food systems, public safety systems, industrial systems, built environment, operational technology, sensors, control systems, robotics, drones, edge systems, AI-RAN/O-RAN, private wireless, cyber ranges, simulations, digital twins, and other cyber-physical or critical infrastructure contexts.

17.8.5.2 Cyber-physical and critical infrastructure work shall prefer simulation, sandboxing, testbeds, digital twins, synthetic data, controlled data, non-operational environments, isolated environments, read-only access, and non-interference methods where operational systems, public safety, public authority functions, or essential services could be affected.

17.8.5.3 Nexus Acceleration shall not interfere with live operations, change operational configurations, direct infrastructure operators, command systems, manipulate traffic, alter public services, disrupt control systems, bypass safety procedures, conduct unauthorized scanning, or perform testing against operational environments without separate lawful authorization by competent actors and recorded safeguards.

17.8.5.4 Controls shall include isolation, access limits, approved workloads, safety review, cyber review, operator coordination where appropriate, public authority boundary review where relevant, vulnerability disclosure controls, logging, rollback conditions, emergency stop procedures, no-operational-interference statements, and public-safe output review.

17.8.5.5 Vulnerabilities or operational weaknesses identified in critical infrastructure contexts shall be handled through responsible disclosure, affected-operator notice where appropriate, public authority notice where required, restricted records, public-safe summaries, and correction pathways.

17.8.5.6 Cyber-physical and critical infrastructure outputs shall not create operational approval, resilience certification, safety certification, public authority approval, procurement preference, provider validation, deployment authorization, emergency command, public warning, or financeability by implication.

17.8.5.7 Cyber-Physical and Critical Infrastructure Controls ensure that learning about essential systems does not create risk to those systems.

***

#### 17.8.6 Telecom and AI-RAN/O-RAN Controls

17.8.6.1 Telecom and AI-RAN/O-RAN Controls mean the rules governing telecommunications, private wireless, edge connectivity, AI-RAN, O-RAN, radio systems, spectrum-sensitive systems, network optimization, emergency connectivity, degraded-mode communications, telecom testbeds, edge intelligence, network telemetry, network slicing, sensor connectivity, and related public-good research activities.

17.8.6.2 Telecom, AI-RAN, and O-RAN work shall be conducted only through lawful spectrum use, approved testbeds, authorized equipment, bounded configurations, access controls, safety constraints, cyber controls, public authority boundary controls, provider-neutrality controls, and public-safe output review.

17.8.6.3 Nexus Acceleration shall not create telecom regulatory approval, spectrum authorization, equipment certification, network deployment approval, public safety communications approval, operational authorization, public authority command, emergency communications authority, or provider preference by reason of research, testing, simulation, benchmark, or Nexus Universe demonstration.

17.8.6.4 AI-RAN and O-RAN activities involving optimization, automation, edge intelligence, sensing, traffic management, degraded-mode learning, public safety learning, or network resilience shall include approved workload records, system cards where appropriate, cyber review, data classification, telemetry controls, operator coordination where appropriate, and no-operational-interference boundaries.

17.8.6.5 Network telemetry, radio data, user data, device data, location data, infrastructure data, spectrum data, logs, and performance results shall be reviewed for privacy, cyber, infrastructure, public safety, public authority, provider-neutrality, benchmark, and publication risk before use or release.

17.8.6.6 Comparative or provider-specific telecom outputs shall include configuration limits, testbed limits, reproducibility limits, conflict disclosures, non-generalization language, and prohibitions on unsupported marketing, procurement, superiority, public authority, finance, safety, or deployment claims.

17.8.6.7 Telecom and AI-RAN/O-RAN Controls allow advanced connectivity learning only where legal authority, public safety, cyber protection, provider neutrality, and no-deployment boundaries are preserved.

***

#### 17.8.7 Public Safety Controls

17.8.7.1 Public Safety Controls mean the safeguards governing outputs, records, dashboards, simulations, digital twins, observability summaries, DRI materials, geospatial materials, public communications, public authority learning records, readiness notes, Nexus Universe outputs, or public-safe reports that may affect emergency response, public warning, crowd behavior, evacuation interpretation, critical services, public health, public trust, public panic, false reassurance, infrastructure behavior, or public authority perception.

17.8.7.2 Public Safety Controls shall require review of materials using or implying warning, alert, emergency, threat, risk level, evacuation, command, response, crisis, intelligence, public safety, operational instruction, public health guidance, public authority direction, or similar terms.

17.8.7.3 Nexus Acceleration shall not issue official public warnings, emergency alerts, evacuation instructions, operational commands, public health directives, public safety orders, intelligence determinations, threat ratings, or public authority decisions.

17.8.7.4 Public-facing risk communications shall be public-safe, non-alarming, non-misleading, uncertainty-aware, boundary-clear, accessible, translated where feasible, culturally sensitive where relevant, and clear that competent public authorities retain official warning and command functions.

17.8.7.5 Public Safety Controls may require public authority boundary review, emergency-language review, public-safe claims review, community review, geospatial review, health review, cyber review, restriction, delayed publication, or no-publication classification.

17.8.7.6 Public Safety Control failures, including false warning implication, false reassurance, public panic risk, unauthorized emergency claim, public authority confusion, sensitive vulnerability disclosure, or public health misinterpretation, shall be treated as safeguard incidents requiring correction and repair.

17.8.7.7 Public Safety Controls protect learning from being mistaken for command.

***

#### 17.8.8 Biological-Sensitive Controls

17.8.8.1 Biological-Sensitive Controls mean the safeguards governing health, biosecurity, pathogen-related, ecological, species, vector, environmental, biodiversity, zoonotic, invasive species, agricultural biosecurity, public health, laboratory, genomic, ecological-risk, or biological-context information that could create misuse, panic, privacy risk, protected knowledge risk, ecological harm, public authority confusion, stigma, targeting, or unsafe public interpretation.

17.8.8.2 Biological-sensitive information may include disease-risk patterns, vector locations, sensitive species locations, protected ecological knowledge, pathogen-related context, public health vulnerability, laboratory information, biosecurity practices, environmental exposure data, agricultural vulnerability, biodiversity location data, ecological monitoring outputs, and WEFH-B health or biodiversity outputs.

17.8.8.3 Biological-Sensitive Controls shall require review for misuse potential, public health sensitivity, privacy, sensitive geospatial exposure, protected ecological knowledge, Indigenous or community protected knowledge where applicable, public authority boundaries, public-safe publication, and public panic or false reassurance risk.

17.8.8.4 Nexus Acceleration shall not publish operational biological misuse-enabling details, sensitive pathogen-related procedural information, protected ecological locations, sensitive species locations, public health-sensitive small-area data, or public safety-sensitive biological information unless lawful, public-safe, reviewed, and appropriately restricted.

17.8.8.5 Biological-sensitive outputs shall not be treated as public health determinations, official disease intelligence, biological safety certification, ecological approval, public authority approval, emergency warning, regulatory determination, financeability, insurance conclusion, or deployment authorization.

17.8.8.6 Biological-Sensitive Controls may require aggregation, redaction, delayed release, public authority boundary review, health review, ecological review, protected knowledge review, Indigenous protocol review where applicable, restricted archive, or no-publication classification.

17.8.8.7 Biological-Sensitive Controls allow learning about living systems without exposing living systems or communities to preventable harm.

***

#### 17.8.9 Harmful Capability Incident

17.8.9.1 Harmful Capability Incident means any actual, suspected, or potential event involving unsafe release, misuse-enabling detail, dual-use exposure, cyber vulnerability disclosure error, sensitive geospatial exposure, infrastructure exposure, telecom exposure, AI-RAN/O-RAN misuse-enabling output, biological-sensitive exposure, public safety overclaim, public warning confusion, dangerous automation, unauthorized operational testing, harmful agentic action, protected knowledge exposure, public authority overclaim, or publication that materially increases harmful capability.

17.8.9.2 Harmful Capability Incidents may arise from research outputs, benchmark records, model cards, system cards, red-team notes, cyber findings, repository releases, maps, dashboards, digital twins, simulations, public authority learning records, public-safe reports, readiness notes, sponsor materials, provider materials, media materials, Nexus Universe demonstrations, partner communications, or handoff dependency records.

17.8.9.3 Harmful Capability Incident intake shall identify the affected output, capability exposed, harmful use scenario, affected systems or communities where safe, public exposure, access pathway, data class, cyber risk, geospatial risk, infrastructure risk, telecom risk, biological-sensitive risk, public safety risk, public authority risk, sponsor/provider risk, containment need, notice obligations, correction pathway, and archive status.

17.8.9.4 Response measures may include publication hold, withdrawal, restricted circulation, repository takedown or restriction, map removal, dashboard suspension, redaction, aggregation, output replacement, secure-room restriction, access closure, credential rotation where relevant, vulnerability disclosure, public authority notice where appropriate or required, operator notice where appropriate, partner notice, public-safe clarification, public repair where required, and archive.

17.8.9.5 Harmful Capability Incidents shall be escalated urgently where continued availability could enable cyber abuse, infrastructure disruption, targeting, public safety harm, biological misuse, sensitive surveillance, operational interference, panic, or public authority confusion.

17.8.9.6 Harmful Capability Incident records shall preserve lessons for future review while restricting details that could compound harm.

17.8.9.7 Harmful Capability Incidents demonstrate that acceleration must be reversible when capability becomes unsafe.

***

#### 17.8.10 Dual-Use Summary Clause

17.8.10.1 Nexus Acceleration must accelerate beneficial capability without accelerating harmful capability, misuse, unsafe disclosure, public safety risk, security exposure, protected knowledge exposure, public authority confusion, or deployment overclaim.

17.8.10.2 Dual-Use Control requires technologies or outputs with both beneficial and harmful potential to be reviewed for misuse, security, public safety, legal, and public-safe publication risk. Misuse Review applies to outputs that could enable harm, targeting, cyber abuse, infrastructure disruption, sensitive surveillance, dangerous automation, biological misuse, or public safety risk. Security-Sensitive Information controls apply to vulnerabilities, system architecture, credentials, exploit paths, critical infrastructure dependencies, sensitive maps, operational procedures, and threat-relevant details. Geospatial Risk Controls apply to sensitive locations, protected sites, critical infrastructure, vulnerable communities, ecological resources, emergency assets, and public safety facilities. Cyber-Physical and Critical Infrastructure Controls require isolation, simulation preference, no operational interference, vulnerability disclosure, public authority boundaries, and access limits. Telecom and AI-RAN/O-RAN Controls govern testbeds, edge systems, radio systems, network optimization, private wireless, lawful spectrum use, and public safety boundaries. Public Safety Controls apply to outputs that may affect emergency response, public warning, crowd behavior, evacuation interpretation, critical services, public health, or public trust. Biological-Sensitive Controls apply to health, biosecurity, pathogen-related, ecological, species, vector, or environmental information that could create misuse, panic, privacy, or protected knowledge risk. Harmful Capability Incidents include unsafe release, misuse-enabling detail, dual-use exposure, cyber vulnerability disclosure error, sensitive geospatial exposure, or public safety overclaim.

17.8.10.3 No Dual-Use Control record, Misuse Review, Security-Sensitive Information record, Geospatial Risk Control record, Cyber-Physical or Critical Infrastructure Control record, Telecom or AI-RAN/O-RAN Control record, Public Safety Control record, Biological-Sensitive Control record, Harmful Capability Incident record, redaction, restriction, withdrawal, vulnerability disclosure record, public-safe summary, readiness note, public authority learning record, benchmark record, model card, system card, red-team note, map, dashboard, digital twin output, simulation output, telecom testbed output, AI-RAN/O-RAN output, cyber output, biological-sensitive output, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, Handoff Dependency Note, correction notice, public repair, withdrawal notice, restricted archive, or public communication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, security certification, safety certification, biological safety determination, telecom approval, spectrum authorization, infrastructure resilience certification, standards conformance, operational authorization, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.8.10.4 The controlling Dual-Use Formula is that Nexus may study hazards, model systems, test infrastructure, improve observability, strengthen telecom resilience, support cyber defense, map risks, analyze biological-sensitive systems, and produce public-good learning; but usefulness is not publishability, precision is not safety, capability is not authorization, simulation is not deployment, vulnerability knowledge is not public content, geospatial accuracy is not release permission, public safety learning is not public warning, biological sensitivity is not public disclosure, and Nexus Acceleration shall move powerful knowledge only when misuse, security, public safety, legal, safeguard, and public-safe controls are strong enough to prevent beneficial acceleration from becoming harmful acceleration.

### 17.9 Technical Vendor, Platform, Cloud, Tooling, Lock-In, Supply Chain, Export Control, Sanctions, Third-Party Risk, Dependency Risk, and Resilience Review

#### 17.9.1 Vendor and Platform Risk

17.9.1.1 Vendor and Platform Risk means the operational, legal, privacy, cyber, data, sovereignty, public authority, public-safe, continuity, cost, lock-in, supply-chain, sanctions, export-control, reputational, and claims-boundary risk created by reliance on technology providers, cloud services, software platforms, AI systems, data tools, hardware partners, telecom partners, cybersecurity providers, repository services, observability platforms, workflow tools, model providers, infrastructure providers, secure-room providers, and other external technical systems or contributors used in Nexus Acceleration.

17.9.1.2 Vendor and Platform Risk Review shall be required where a vendor, platform, provider, sponsor, technical contributor, cloud service, hardware system, telecom system, AI tool, repository service, data tool, or third-party service may access, store, process, transmit, host, secure, log, observe, model, analyze, or influence Nexus data, records, software, workflows, outputs, public-safe summaries, readiness notes, public authority learning materials, Nexus Universe stack operations, or lawful handoff dependency records.

17.9.1.3 Vendor and Platform Risk Review shall identify the vendor or platform, service scope, data exposure, access model, custody role, subprocessors where known, jurisdiction, data residency, security controls, logging, retention, deletion, service continuity, portability, contractual limits, confidentiality, intellectual property conditions, model training or data use terms where relevant, export-control implications, sanctions implications, lock-in risk, teardown obligations, and correction pathway.

17.9.1.4 Vendor participation, sponsor support, provider contribution, cloud credit, donated tool, platform access, technical mentorship, or infrastructure support shall not reduce the need for risk review. Contribution value shall not create trust, preference, validation, procurement status, public authority approval, financeability, insurability, or execution authority.

17.9.1.5 Vendor and Platform Risk Review shall be heightened where the vendor or platform handles sovereign data, public authority data, health-sensitive data, infrastructure-sensitive data, cyber-sensitive data, community-sensitive data, protected knowledge, Indigenous-sensitive data where applicable, sensitive geospatial data, sensitive operational data, AI workflows, agentic systems, public-facing outputs, or temporary Nexus Universe stack operations.

17.9.1.6 Vendor and Platform Risk Review may result in approval for bounded use, restricted use, clean-room use, compute-to-data use, no-download use, additional contractual controls, additional security review, local hosting, substitution, portability requirement, no-publication restriction, non-use, or withdrawal.

17.9.1.7 Vendor and Platform Risk Review protects Nexus Acceleration from confusing technical capability with acceptable dependency.

***

#### 17.9.2 Cloud and Tooling Risk

17.9.2.1 Cloud and Tooling Risk means the risk arising from cloud services, managed platforms, developer tools, AI tools, workflow tools, repository systems, collaboration systems, observability systems, data platforms, dashboards, notebook environments, container platforms, API services, model registries, artifact stores, identity tools, and automation systems used in Nexus Acceleration.

17.9.2.2 Cloud and Tooling Risk includes configuration errors, insecure defaults, excessive permissions, unclear data residency, cross-border processing, backup replication, service dependency, cost exposure, billing overrun, access control failure, logging gaps, monitoring gaps, secrets exposure, provider lock-in, tool discontinuity, export limits, teardown complexity, data deletion uncertainty, support access, third-party subprocessors, and public-safe publication risk.

17.9.2.3 Cloud and Tooling Risk Review shall identify cloud region, account structure, administrator roles, access controls, identity integration, logging, encryption where appropriate, backup behavior, retention, data export paths, AI model training terms where relevant, provider support access, cost controls, budget alerts, teardown procedure, and closure verification.

17.9.2.4 Temporary Nexus Universe cloud and tooling environments shall be designed with lifecycle controls, including pre-cycle provisioning, approved workload mapping, account ownership, access expiration, cost monitoring, data closure, credential closure, log preservation, teardown, archive, and post-cycle review.

17.9.2.5 Cloud and tooling services used for restricted, sovereign-sensitive, public authority-sensitive, health-sensitive, infrastructure-sensitive, cyber-sensitive, community-sensitive, protected knowledge, or Indigenous-sensitive data where applicable shall require data residency review, access review, security review, transfer review, and output review before use.

17.9.2.6 Cloud and Tooling Risk shall not be obscured by donated credits, sponsor status, provider convenience, developer familiarity, research urgency, public authority interest, or Nexus Universe operational pressure.

17.9.2.7 Cloud and Tooling Risk Review makes invisible platform dependencies visible before they become lock-in, leakage, cost exposure, or teardown failure.

***

#### 17.9.3 Lock-In Review

17.9.3.1 Lock-In Review means the required review of technical, contractual, data, workflow, cloud, licensing, platform, AI model, API, hardware, telecom, repository, tooling, or partner-support dependencies that may restrict portability, public-good continuity, national ownership, open technical baselines, provider neutrality, interoperability, future correction, public-safe publication, archive, post-cycle reuse, or future lawful handoff.

17.9.3.2 Lock-In Review shall be required where Nexus Acceleration depends on proprietary tools, closed platforms, provider-specific APIs, non-portable data formats, vendor-specific model services, cloud-specific services, proprietary hardware, telecom equipment, partner-only configurations, restricted licenses, non-exportable logs, partner-controlled dashboards, unavailable source code, or undocumented operational knowledge.

17.9.3.3 Lock-In Review shall identify the dependency, affected output, affected data, affected workflow, affected National Node, affected Nexus Universe track, portability constraints, open alternative availability, exportability, documentation quality, license restrictions, cost of migration, post-cycle continuity risk, national ownership risk, provider-neutrality risk, and lawful handoff implications.

17.9.3.4 Lock-In Review shall distinguish acceptable temporary dependency from unacceptable structural dependency. Temporary use of a platform for research or Nexus Universe support may be acceptable where records, outputs, data closure, portability, and public-good continuity are protected; structural dependency may be unacceptable where it captures the public-good stack, national pathway, public authority learning, or lawful handoff route.

17.9.3.5 Lock-In Review may require open technical baselines, exportable formats, documented APIs, interoperable schemas, escrowed documentation where appropriate, alternative provider pathways, multi-cloud design, portable repositories, post-cycle migration, public-good reference implementation, or non-use.

17.9.3.6 No contributor shall use technical support, proprietary access, discounted access, donated credits, platform familiarity, or advanced capability to create preferred-provider status, procurement advantage, National Node dependency, public authority dependency, or handoff lock-in.

17.9.3.7 Lock-In Review protects the public-good stack from becoming captive to the tools that helped build it.

***

#### 17.9.4 Supply Chain Security

17.9.4.1 Supply Chain Security means the review and control of software dependencies, hardware provenance, firmware, containers, packages, APIs, models, datasets, partner systems, cloud services, repository services, development tools, build pipelines, deployment tools, AI services, telecom systems, secure-room systems, and other third-party components used in Nexus Acceleration.

17.9.4.2 Supply Chain Security Review shall assess source, provenance, integrity, license, maintenance status, known vulnerabilities, update cadence, dependency depth, transitive dependencies, container images, package registries, model provenance, dataset provenance, firmware source, hardware custody, API reliability, vendor support, and third-party risk.

17.9.4.3 Software dependencies shall be reviewed for security vulnerabilities, license compatibility, malicious packages, typosquatting, abandoned packages, excessive permissions, secrets exposure, dependency confusion, insecure defaults, and incompatibility with public-good release or restricted-use requirements.

17.9.4.4 Hardware, firmware, telecom, edge, sensor, accelerator, and infrastructure components shall be reviewed for provenance, custody, firmware integrity, update pathway, support access, physical security, safety, teardown, return, sanitization, and operational restrictions.

17.9.4.5 AI models and datasets shall be reviewed for provenance, licensing, permitted use, training data concerns where known, model behavior risks, evaluation limits, bias concerns, security risks, data leakage risks, public-safe output risk, and prohibited use conditions.

17.9.4.6 Supply Chain Security Review may require dependency pinning, software bills of materials where appropriate, vulnerability scanning, container scanning, repository controls, model cards, dataset records, vendor attestations where appropriate, restricted use, patching, replacement, withdrawal, or archive.

17.9.4.7 Supply Chain Security ensures that Nexus Acceleration’s public-good outputs are not built on invisible, insecure, unlawful, or uncorrectable dependencies.

***

#### 17.9.5 Export Control Review

17.9.5.1 Export Control Review means the required review of advanced compute, AI systems, model weights, cyber tools, encryption, telecom systems, AI-RAN/O-RAN systems, geospatial data, drones, sensors, robotics, biological-sensitive data, infrastructure-sensitive technical information, restricted technical data, software, hardware, firmware, algorithms, datasets, training materials, and cross-border collaborations for applicable export-control, deemed-export, re-export, transfer, access, and technical-assistance restrictions.

17.9.5.2 Export Control Review shall be required before providing controlled technology, restricted technical information, advanced compute access, AI model access, cyber tooling, encryption tools, drone or sensor technical data, telecom configurations, geospatial datasets, biological-sensitive information, or infrastructure-sensitive information to persons, entities, jurisdictions, partners, researchers, public authorities, National Nodes, sponsors, providers, or collaborators where export-control risk may arise.

17.9.5.3 Export Control Review shall identify technology type, data type, jurisdiction, user nationality or location where lawfully relevant, destination, access method, transfer method, partner or recipient, potential controlled classification, license requirements, exemptions, restrictions, sanctions overlap, public authority considerations, cloud-region implications, remote access implications, and correction pathway.

17.9.5.4 Nexus Acceleration shall not assume that public-good purpose, research purpose, nonprofit context, public authority interest, or Nexus Universe participation removes export-control obligations.

17.9.5.5 Export Control Review may require access denial, restricted access, license review, legal review, technical restriction, redaction, local-only processing, compute-to-data, no-download access, public-safe summary substitution, delayed release, or non-use.

17.9.5.6 Export Control Review records shall be restricted where they contain sensitive technical details, legal analysis, national security-sensitive information, or partner-sensitive information.

17.9.5.7 Export Control Review preserves the rule that global public-good collaboration must remain lawful before it can be useful.

***

#### 17.9.6 Sanctions Review

17.9.6.1 Sanctions Review means the review of participants, contributors, partners, sponsors, providers, public authorities, jurisdictions, data sources, funding sources, technology access, cloud access, compute access, software access, hardware transfers, services, cross-border collaborations, donations, travel support, public authority learning, National Node activity, Nexus Universe participation, and lawful handoff pathways for sanctions, restricted party, denied party, prohibited transaction, embargo, anti-corruption, anti-terror financing, and related legal restrictions.

17.9.6.2 Sanctions Review shall be required where Nexus Acceleration involves cross-border participation, technology transfer, compute access, cloud access, funding, in-kind contributions, public authority interaction, partner support, data sharing, travel support, equipment transfer, publication collaboration, sponsor support, provider access, or engagement with jurisdictions, entities, individuals, or sectors that may create sanctions or restricted party risk.

17.9.6.3 Sanctions Review shall identify relevant parties, affiliations where known, jurisdiction, transaction or activity, technology involved, data involved, funding or in-kind support, services provided, access granted, public authority context, potential sanctions regime, restricted party risk, prohibited transaction risk, licensing requirement, escalation need, and correction pathway.

17.9.6.4 Nexus Acceleration shall not provide access, services, technology, funding, travel support, equipment, data, compute, cloud resources, technical assistance, or collaboration pathways where sanctions or restricted party restrictions prohibit or materially restrict such activity unless competent legal authorization is obtained.

17.9.6.5 Sanctions Review shall be updated where participant status, jurisdiction, ownership, control, funding source, technology access, public authority context, or applicable law changes.

17.9.6.6 Sanctions Review records shall be access-controlled and shall not be used for discriminatory exclusion beyond lawful and risk-based requirements.

17.9.6.7 Sanctions Review ensures that inclusion, collaboration, and public-good purpose remain inside lawful boundaries.

***

#### 17.9.7 Third-Party Risk

17.9.7.1 Third-Party Risk means the operational, legal, privacy, cyber, data, financial, reputational, supply-chain, continuity, public authority, public-safe, sovereignty, export-control, sanctions, and dependency risk created by reliance on external actors, systems, services, platforms, infrastructure, tools, datasets, models, contributors, contractors, vendors, sponsors, providers, universities, laboratories, public authorities, community institutions, or other third parties.

17.9.7.2 Third-Party Risk Review shall identify the third party, role, access, data exposure, system dependency, legal relationship, contractual terms, confidentiality duties, public-safe role, financial or in-kind contribution, conflicts, influence risks, security posture where relevant, supply-chain dependencies, jurisdiction, sanctions or export-control risk, continuity risk, and exit conditions.

17.9.7.3 Third-Party Risk shall include risk that an external actor may misuse Nexus status, overclaim validation, influence outputs, create provider preference, capture public authority learning, access restricted data, create lock-in, fail to perform, create security exposure, discontinue service, impose restrictive terms, or prevent correction, deletion, archive, or teardown.

17.9.7.4 Third-party access shall be limited to recorded purpose, role, need-to-know, time period, access class, confidentiality terms, security controls, conflict controls, and correction obligations.

17.9.7.5 Third-Party Risk Review may require due diligence, conflict disclosure, contribution records, access limits, contractual controls, security review, data processing terms, public-safe claims controls, exit plan, substitution plan, insurance or liability review where appropriate, or non-use.

17.9.7.6 Third-Party Risk shall be renewed when scope changes, access changes, data class changes, public visibility changes, contribution status changes, incident occurs, legal environment changes, or continuation or handoff is considered.

17.9.7.7 Third-Party Risk Review prevents public-good work from becoming dependent on actors whose risks are not visible.

***

#### 17.9.8 Dependency Risk

17.9.8.1 Dependency Risk means the risk arising from reliance on essential vendors, cloud regions, datasets, platforms, partner support, proprietary tools, licenses, APIs, infrastructure components, models, repositories, hardware, telecom systems, security tools, data rooms, secure rooms, workflow tools, public authority inputs, National Node pathways, community inputs, or reviewer availability.

17.9.8.2 Dependency Risk Records shall be required for dependencies that materially affect research production, data access, evidence integrity, reproducibility, public-safe reporting, Nexus Universe operations, National Node continuation, public authority learning, readiness translation, lawful handoff dependency mapping, or archive.

17.9.8.3 Each Dependency Risk Record shall identify dependency, owner or provider, affected outputs, affected workflows, criticality, substitutability, portability, cost exposure, access conditions, license terms, data residency implications, security implications, continuity risk, teardown implications, correction implications, handoff implications, and mitigation plan.

17.9.8.4 Dependency Risk may include single-cloud dependency, single-vendor dependency, proprietary API dependency, partner-engineer dependency, undocumented workflow dependency, closed model dependency, dataset dependency, restricted-license dependency, key-person dependency, public authority dependency, community review dependency, or National Node dependency.

17.9.8.5 Dependency Risk Records shall distinguish dependencies that are acceptable for temporary experimentation from dependencies that are unacceptable for public-good continuity, national ownership, public authority learning, public-safe reporting, or lawful handoff.

17.9.8.6 Dependency mitigation may include documentation, open technical baselines, alternative providers, exportable formats, local copies where lawful, synthetic substitutes, public-good reference implementations, multi-cloud options, backup reviewers, workflow automation with human review, and exit plans.

17.9.8.7 Dependency Risk Records ensure that what Nexus Acceleration depends on can be seen, managed, corrected, and exited.

***

#### 17.9.9 Resilience Review

17.9.9.1 Resilience Review means the review of continuity, failover, degraded-mode operation, backup, recovery, portability, documentation, archive, access closure, data closure, credential closure, partner exit, post-cycle teardown, and operational recovery for systems, platforms, datasets, repositories, cloud environments, secure rooms, temporary Nexus Universe stacks, public-good software, dashboards, public authority learning rooms, and National Node pathways.

17.9.9.2 Resilience Review shall identify critical services, failure modes, single points of failure, backup status, recovery process, recovery time needs, degraded-mode options, alternative tools, alternative cloud regions where lawful, local processing options, access closure plan, data closure plan, credential rotation plan, archive plan, documentation status, and responsible stewards.

17.9.9.3 Resilience Review shall be required before high-dependency Nexus Universe operations, secure-room operations, public authority learning rooms, public-safe publication systems, observability dashboards, readiness rooms, repository releases, and handoff dependency pathways.

17.9.9.4 Resilience Review shall include teardown resilience. Temporary systems shall be designed not only to operate, but also to close, return, delete, archive, restrict, and transfer lessons without leaving unauthorized access, residual data, uncontrolled credentials, undocumented dependencies, or abandoned infrastructure.

17.9.9.5 Resilience Review shall include degraded-mode planning for connectivity loss, cloud outage, platform failure, credential compromise, partner withdrawal, compute unavailability, repository compromise, event disruption, public authority room disruption, or data access interruption.

17.9.9.6 Resilience Review shall not create resilience certification, uptime guarantee, public authority readiness, operational approval, financeability, insurability, procurement qualification, or deployment authorization.

17.9.9.7 Resilience Review makes Nexus Acceleration capable of continuing, correcting, and closing under stress.

***

#### 17.9.10 Vendor and Dependency Summary Clause

17.9.10.1 Technical excellence requires visibility into vendor, platform, cloud, tooling, lock-in, supply-chain, export-control, sanctions, third-party, dependency, and resilience risk before technical capacity is converted into Nexus Acceleration outputs.

17.9.10.2 Vendor and Platform Risk Review applies to technology providers, cloud services, software platforms, AI systems, data tools, hardware partners, telecom partners, and repository services. Cloud and Tooling Risk includes configuration errors, data residency, service dependency, cost exposure, access control, logging gaps, provider lock-in, and teardown complexity. Lock-In Review applies to dependencies that may restrict portability, public-good continuity, national ownership, open technical baselines, provider neutrality, or future lawful handoff. Supply Chain Security Review applies to software dependencies, hardware provenance, firmware, containers, packages, APIs, models, datasets, partner systems, and third-party services. Export Control Review applies to advanced compute, AI, cyber tools, encryption, telecom systems, geospatial data, drones, sensors, biological-sensitive data, and restricted technical information. Sanctions Review applies to participants, contributors, partners, jurisdictions, data sources, funding, technology access, and cross-border collaborations. Third-Party Risk is the operational, legal, privacy, cyber, data, financial, reputational, supply-chain, and continuity risk created by reliance on external actors or systems. Dependency Risk Records are required for essential vendors, cloud regions, datasets, platforms, partner support, proprietary tools, licenses, APIs, and infrastructure components. Resilience Review applies to continuity, failover, degraded-mode operation, backup, recovery, portability, documentation, archive, and post-cycle teardown.

17.9.10.3 No Vendor and Platform Risk Review, Cloud and Tooling Risk Review, Lock-In Review, Supply Chain Security Review, Export Control Review, Sanctions Review, Third-Party Risk Review, Dependency Risk Record, Resilience Review, vendor record, platform record, cloud record, tooling record, supply-chain record, dependency record, partner contribution record, sponsor support record, provider contribution record, cloud credit record, hardware contribution record, software access record, repository service record, AI tool record, telecom partner record, export-control note, sanctions note, resilience note, continuity plan, teardown plan, archive record, public-safe summary, readiness note, public authority learning record, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Docket item, ARL status, Nexus Rail routing, Handoff Dependency Note, correction notice, withdrawal notice, restricted archive, or public communication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, vendor validation, platform endorsement, cloud endorsement, supply-chain certification, export authorization by implication, sanctions clearance by implication, security certification, resilience certification, standards conformance, operational authorization, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.9.10.4 The controlling Vendor and Dependency Formula is that Nexus may use vendors, platforms, clouds, tools, models, datasets, hardware, telecom systems, repositories, partners, and third parties to accelerate public-good work; but contribution is not control, access is not trust, cloud convenience is not residency compliance, proprietary capability is not public-good continuity, dependency is not neutrality, supply-chain presence is not security, sanctions screening is not unlimited authorization, export review is not export permission by implication, resilience review is not uptime guarantee, and Nexus Acceleration shall rely on external systems only where their risks, limits, exits, and safeguards are visible before reliance becomes capture.

### 17.10 Data, AI, Cyber, Privacy, Secure Infrastructure, Dual-Use, Misuse, Technical, Access, and Publication Incidents and Correction

#### 17.10.1 Incident Definition

17.10.1.1 Incident means any actual, suspected, potential, attempted, detected, reported, or later-discovered event, omission, failure, misuse, exposure, misclassification, unauthorized action, unsafe release, technical failure, access failure, publication failure, workflow failure, boundary failure, safeguard failure, or correction failure affecting data, AI, cybersecurity, privacy, protected knowledge, secure infrastructure, dual-use controls, misuse risk, technical integrity, access control, publication safety, public-safe meaning, public authority boundaries, finance boundaries, procurement boundaries, community safeguards, Indigenous safeguards where applicable, or lawful routing within Nexus Acceleration.

17.10.1.2 Incidents may arise from human action, system action, automated action, agentic AI action, partner action, sponsor action, provider action, public authority room activity, researcher activity, volunteer activity, reviewer activity, National Node activity, Working Group activity, Competence Cell activity, repository activity, cloud environment activity, secure-room activity, clean-room activity, public communication, publication, translation, dashboard release, map release, readiness note, Handoff Dependency Note, Nexus Universe output, or archive process.

17.10.1.3 Incidents shall include, without limitation, data incidents, AI incidents, cyber incidents, privacy incidents, protected knowledge incidents, secure infrastructure incidents, dual-use incidents, misuse incidents, technical incidents, access incidents, publication incidents, transfer incidents, public narrative incidents, public authority boundary incidents, finance boundary incidents, procurement boundary incidents, community safeguard incidents, Indigenous safeguard incidents where applicable, and harmful capability incidents.

17.10.1.4 An Incident shall not require proven harm before being recorded, triaged, contained, escalated, corrected, withdrawn, superseded, restricted, repaired, archived, or renewed. Reasonable suspicion of harm, exposure, overclaim, unsafe publication, unauthorized access, misuse risk, or boundary failure shall be sufficient to trigger intake and review.

17.10.1.5 Incidents shall be treated as correctionability events. Each Incident shall be recorded with sufficient detail to support containment, accountability, public-safe correction, lessons learned, archive, and renewal without exposing sensitive information unnecessarily.

17.10.1.6 Incident discipline is the operating proof that Nexus Acceleration’s controls are enforceable rather than aspirational.

***

#### 17.10.2 Data Incident

17.10.2.1 Data Incident means any actual, suspected, or potential event involving unauthorized access, unauthorized use, loss, exposure, disclosure, improper transfer, improper copying, improper cloud-region use, misclassification, unlawful retention, retention beyond purpose, dataset misuse, re-identification, sensitive inference, improper deletion failure, improper return failure, archive error, access logging failure, data custody failure, data stewardship failure, or data handling outside the applicable Dataset Record, Data Handling Record, Data Custody Record, Data Transfer Review, retention rule, deletion rule, public-safe class, or safeguard condition.

17.10.2.2 Data Incidents may involve raw data, derived data, metadata, logs, evidence records, public authority data, sovereign data, health-sensitive data, infrastructure-sensitive data, community-sensitive data, protected knowledge data, Indigenous-sensitive data where applicable, sensitive geospatial data, sensitive social data, cyber-sensitive data, partner-confidential data, market-sensitive data, sensitive operational data, AI inputs, AI outputs, benchmark datasets, digital twin inputs, observability records, dashboards, maps, public-safe summaries, readiness notes, or handoff dependency records.

17.10.2.3 Data Incidents include use of data for an unapproved purpose, provision of data to an unapproved participant, transfer of data to an unapproved jurisdiction, inclusion of restricted data in public materials, release of derived outputs enabling re-identification, failure to delete or return data when required, retention after authorization ends, use of data in AI tools without authorization, and publication of data beyond its public-safe class.

17.10.2.4 Data Incident intake shall identify the affected dataset, source, steward, custodian, classification, affected records, access pathway, unauthorized or improper action, users or systems involved, public exposure, jurisdictional implications, privacy implications, sovereignty implications, public authority implications, protected knowledge implications, community implications, Indigenous implications where applicable, containment actions, notice obligations, correction pathway, and archive status.

17.10.2.5 Data Incident correction may include access suspension, credential rotation, data quarantine, deletion, return, transfer correction, cloud-region correction, dataset reclassification, public-safe withdrawal, dashboard suspension, map withdrawal, output redaction, public repair where required, participant or community notice where appropriate, public authority notice where appropriate, Indigenous notice where applicable, and archive.

17.10.2.6 A Data Incident shall be treated as material where it affects restricted, sovereign-sensitive, rights-bearing, health-sensitive, public authority-sensitive, infrastructure-sensitive, cyber-sensitive, community-sensitive, protected knowledge, Indigenous-sensitive, sensitive geospatial, sensitive social, or no-publication data.

17.10.2.7 Data Incidents confirm that data governance must control not only collection, but every later movement, inference, output, retention, and correction.

***

#### 17.10.3 AI Incident

17.10.3.1 AI Incident means any actual, suspected, or potential event involving hallucinated claims, unsupported factual statements, model misuse, unsafe AI outputs, unauthorized agentic action, data leakage, protected knowledge exposure, Indigenous-sensitive information exposure where applicable, privacy breach, sensitive data leakage, synthetic misrepresentation, bias harm, discriminatory output, automated overclaim, prompt injection, tool misuse, unapproved code execution, unapproved API access, unauthorized data transfer, unapproved publication, incorrect translation, benchmark misuse, or AI-generated public-facing output that creates public-safe, legal, ethical, technical, authority, finance, procurement, consent, or safeguard risk.

17.10.3.2 AI Incidents may occur through drafting, summarization, coding, translation, documentation, evidence synthesis, observability workflows, simulations, digital twins, public-safe reporting, readiness translation, public authority learning materials, public communications, repository work, dashboards, agentic systems, partner AI tools, sponsor or provider materials, media materials, Handoff Dependency Notes, or Nexus Universe outputs.

17.10.3.3 AI Incidents include AI outputs that falsely claim certification, approval, endorsement, financeability, insurability, public authority decision, procurement status, community consent, Indigenous consent where applicable, public warning, deployment authorization, or execution authority.

17.10.3.4 AI Incident intake shall identify the AI system or workflow where appropriate, user or role, AI Use Authorization, source materials, output, affected record, affected audience, model or tool actions, data class, tool access, public exposure, claim risk, privacy risk, protected knowledge risk, cyber risk, public authority risk, finance or procurement risk, consent or representation risk, containment action, review pathway, correction action, notice need, and archive status.

17.10.3.5 AI Incident correction may include output withdrawal, publication hold, restricted circulation, access suspension, workflow suspension, agent disablement, tool disablement, prompt or template correction, source verification, human review, redaction, public-safe clarification, public notice where required, sponsor or provider correction, participant or community notice where appropriate, Indigenous notice where applicable, public authority notice where appropriate, model or system restriction, and archive.

17.10.3.6 AI Incidents involving autonomous action beyond permission shall require immediate containment where an AI system accessed data, called an API, modified a repository, sent a message, changed a record, executed code, exported an output, created an account, altered permissions, or interacted with systems outside approved scope.

17.10.3.7 AI Incidents show that AI usefulness is acceptable only where AI errors, overreach, and automation can be detected, contained, corrected, and remembered.

***

#### 17.10.4 Cyber Incident

17.10.4.1 Cyber Incident means any actual, suspected, or potential event involving unauthorized access, attempted unauthorized access, credential compromise, secret exposure, malware, phishing, social engineering, vulnerability exposure, exploited vulnerability, misconfiguration, denial of service, repository compromise, cloud environment breach, insecure dependency, package compromise, unauthorized privilege escalation, unauthorized administrative action, logging failure, monitoring failure, endpoint compromise, network compromise, API abuse, data-room breach, secure-room breach, cyber-physical system concern, or other event affecting confidentiality, integrity, availability, accountability, or security of Nexus Acceleration systems.

17.10.4.2 Cyber Incidents may affect repositories, cloud accounts, data rooms, secure enclaves, clean rooms, controlled rooms, no-download environments, dashboards, APIs, public-good software, observability systems, AI workflows, model registries, artifact stores, National Node environments, partner systems, public authority learning environments, Nexus Universe temporary stacks, build-crew systems, volunteer systems, and operational systems.

17.10.4.3 Cyber Incident intake shall identify affected system, affected data, affected users, affected credentials, attack or failure vector, time of detection, severity, classification, public exposure, data exposure, operational impact, public authority impact where relevant, community impact where relevant, partner impact, containment actions, evidence preservation, notification considerations, correction pathway, and archive status.

17.10.4.4 Cyber Incident response shall include triage, containment, evidence preservation, access suspension where needed, credential rotation, key rotation, system isolation, repository restriction, cloud configuration correction, dependency patching, vulnerability remediation, monitoring enhancement, participant or partner notice where appropriate, public authority notice where required or appropriate, public-safe communication review, recovery, post-incident review, and archive.

17.10.4.5 Cyber Incidents involving public authority data, sovereign data, health-sensitive data, infrastructure-sensitive data, cyber-sensitive data, protected knowledge, Indigenous-sensitive data where applicable, sensitive operational data, public-facing systems, public-good repositories, or temporary Nexus Universe stack operations shall be escalated for heightened review.

17.10.4.6 Cyber Incident records shall protect security-sensitive information, affected credentials, exploit details, vulnerability details, public authority-sensitive information, partner-confidential information, and legal privilege where applicable.

17.10.4.7 Cyber Incidents require containment first, public-safe communication second, correction always, and renewal before recurrence.

***

#### 17.10.5 Privacy and Protected Knowledge Incident

17.10.5.1 Privacy and Protected Knowledge Incident means any actual, suspected, or potential event involving privacy breach, personal data exposure, participant confidentiality failure, protected participation breach, health-sensitive data misuse, community-sensitive data exposure, Indigenous knowledge misuse where applicable, protected knowledge exposure, cultural knowledge misuse, ecological knowledge exposure, sacred or sensitive site exposure, sensitive social data misuse, sensitive geospatial disclosure, unauthorized attribution, unsafe quotation, unsafe image use, consent overclaim, representation overclaim, or publication beyond the applicable safeguard condition.

17.10.5.2 Privacy and Protected Knowledge Incidents may arise through public-safe reports, dashboards, maps, digital twins, simulations, AI outputs, translations, media materials, partner materials, sponsor materials, provider materials, readiness notes, public authority learning records, donor or public finance materials, Handoff Dependency Notes, repositories, workshops, meeting records, participant rosters, correction records, or archive records.

17.10.5.3 Such incidents include exposing personal identity where anonymity was required, publishing community input beyond permitted use, disclosing protected knowledge as public context, revealing Indigenous-sensitive information without protocol review where applicable, using health-sensitive information in public-facing materials without review, mapping sensitive locations, misusing participant stories, or using protected participation as public proof.

17.10.5.4 Incident intake shall identify the affected person, participant class, community, Indigenous nation or community where applicable, knowledge type, data type, affected material, exposure pathway, public audience, consent or representation issue, safeguard condition, public-safe risk, harm risk, containment action, notice pathway, repair pathway, and archive status.

17.10.5.5 Correction may include immediate restriction, withdrawal, redaction, anonymization, removal of images or quotes, map removal, dashboard suspension, repository restriction, participant notice, community notice where appropriate, Indigenous notice where applicable, apology where appropriate, public repair where required, revised participation records, revised safeguard notes, access closure, and archive.

17.10.5.6 Privacy and Protected Knowledge Incidents shall not be minimized as communications issues where human dignity, rights, trust, cultural authority, protected knowledge, or participant safety are implicated.

17.10.5.7 Privacy and Protected Knowledge Incident discipline protects the people, communities, and knowledge systems that make public-good work possible.

***

#### 17.10.6 Secure Infrastructure Incident

17.10.6.1 Secure Infrastructure Incident means any actual, suspected, or potential event involving secure room breach, secure enclave breach, no-download violation, controlled-room rule breach, clean-room misuse, confidential computing control failure, key management failure, output review failure, partner-system exposure, access closure failure, unauthorized screenshot, prohibited download, uncontrolled note-taking, unapproved workload, credential misuse, data inference, unauthorized external API call, unapproved package installation, restricted output leakage, room access logging failure, or failure to close temporary stack access.

17.10.6.2 Secure Infrastructure Incidents may occur in secure enclaves, clean rooms, controlled rooms, no-download environments, confidential computing environments, public authority learning rooms, capital-reader rooms, insurance-reader rooms, donor or public finance reader rooms, community safeguard rooms, Indigenous protocol rooms where applicable, National Node environments, partner environments, cloud environments, and Nexus Universe temporary stacks.

17.10.6.3 Secure Infrastructure Incident intake shall identify environment, affected data, affected users, access pathway, incident type, logs, outputs affected, public exposure, transfer risk, privacy risk, protected knowledge risk, public authority risk, cyber risk, geospatial risk, finance or procurement risk where relevant, containment action, notice obligations, correction pathway, and archive status.

17.10.6.4 Response measures may include session termination, access suspension, credential revocation, key rotation, data quarantine, output quarantine, repository restriction, dashboard suspension, map withdrawal, workload suspension, environment shutdown, partner access closure, output withdrawal, public-safe review, legal review, privacy review, cyber review, public authority notice where appropriate, participant or community notice where appropriate, Indigenous notice where applicable, and archive.

17.10.6.5 Secure Infrastructure Incidents involving no-download violations, output leakage, screenshot capture, or data inference shall be treated as potential data transfer incidents until review determines otherwise.

17.10.6.6 Secure Infrastructure Incident records shall preserve evidence needed for review while restricting details that could expose vulnerabilities, protected knowledge, public authority-sensitive information, cyber-sensitive information, or legal privilege.

17.10.6.7 Secure Infrastructure Incident discipline ensures that secure environments remain trustworthy because their rules can be enforced.

***

#### 17.10.7 Dual-Use and Misuse Incident

17.10.7.1 Dual-Use and Misuse Incident means any actual, suspected, or potential event involving harmful capability exposure, misuse-enabling detail, unsafe publication, cyber misuse, cyber vulnerability disclosure error, sensitive geospatial disclosure, public safety risk, biological-sensitive risk, infrastructure exposure, telecom exposure, AI-RAN/O-RAN misuse-enabling output, dangerous operational detail, sensitive surveillance pathway, public warning confusion, public safety overclaim, protected knowledge exposure, or publication that materially increases harmful capability.

17.10.7.2 Dual-Use and Misuse Incidents may arise from research outputs, datasets, maps, dashboards, model cards, system cards, benchmark records, red-team notes, vulnerability notes, cyber findings, telecom testbed outputs, AI-RAN/O-RAN outputs, biological-sensitive records, digital twins, simulations, observability records, public authority learning materials, public-safe reports, readiness notes, repository releases, media materials, partner materials, sponsor materials, provider materials, Nexus Universe demonstrations, or Handoff Dependency Notes.

17.10.7.3 Such incidents include publication of exploit-enabling details, exposure of critical infrastructure dependencies, release of sensitive coordinates, disclosure of protected ecological sites, publication of operational security procedures, release of dangerous automation instructions, disclosure of biological-sensitive information, or framing learning outputs as official public warnings or operational instructions.

17.10.7.4 Incident intake shall identify affected output, capability exposed, harmful use scenario, affected systems or communities where safe, public exposure, access pathway, data class, cyber risk, geospatial risk, infrastructure risk, telecom risk, biological-sensitive risk, public safety risk, public authority risk, sponsor or provider risk, containment need, notice obligations, correction pathway, and archive status.

17.10.7.5 Response measures may include publication hold, withdrawal, restricted circulation, repository restriction, map removal, dashboard suspension, redaction, aggregation, output replacement, secure-room restriction, access closure, vulnerability disclosure, public authority notice where appropriate or required, operator notice where appropriate, partner notice, public-safe clarification, public repair where required, and archive.

17.10.7.6 Dual-Use and Misuse Incidents shall be escalated urgently where continued availability could enable cyber abuse, infrastructure disruption, targeting, public safety harm, biological misuse, sensitive surveillance, operational interference, panic, false reassurance, or public authority confusion.

17.10.7.7 Dual-Use and Misuse Incident discipline protects beneficial capability from becoming harmful capability through release, framing, or misuse.

***

#### 17.10.8 Technical and Publication Incident

17.10.8.1 Technical and Publication Incident means any actual, suspected, or potential event involving benchmark misuse, unsafe public release, incorrect technical claim, misleading model card, misleading system card, unsupported public summary, erroneous public-safe classification, inaccurate evidence record, incomplete method note, faulty reproducibility statement, unsafe technical report, mistranslation, inaccessible publication, wrong version release, repository release error, dashboard publication error, map publication error, public authority overclaim, finance overclaim, procurement overclaim, public warning implication, consent overclaim, or deployment approval implication.

17.10.8.2 Technical and Publication Incidents may arise where outputs are accurate in part but framed beyond their record, where limitations are omitted, where uncertainty is omitted, where benchmark conditions are omitted, where non-generalization is missing, where public-safe classification is wrong, where system dependencies are misstated, where public authority attendance is overstated, where partner support is represented as validation, or where sponsor or provider materials reuse outputs improperly.

17.10.8.3 Technical and Publication Incident intake shall identify affected material, source record, publication channel, audience, technical issue, claims issue, public-safe classification issue, affected records, downstream dependencies, sponsor or provider use where relevant, public authority implication where relevant, finance or procurement implication where relevant, community or Indigenous implication where applicable, correction pathway, withdrawal need, public repair need, and archive status.

17.10.8.4 Correction may include revised technical claim, revised benchmark record, revised model card, revised system card, revised uncertainty statement, revised non-generalization language, corrected public-safe summary, repository correction, version supersession, dashboard revision, map revision, translation correction, accessibility remediation, withdrawal, public-safe clarification, public notice where required, sponsor/provider correction, media correction, public authority clarification, readiness note correction, handoff package correction, and archive.

17.10.8.5 Where technical or publication errors have downstream effects, dependent evidence packs, readiness notes, public authority learning materials, public-safe reports, Docket items, ARL records, Nexus Rail routing notes, Nexus Universe outputs, and Handoff Dependency Notes shall be reviewed and corrected where necessary.

17.10.8.6 Technical and Publication Incidents shall not be concealed because correction may appear reputationally inconvenient. Corrected technical records are more credible than uncorrected overclaims.

17.10.8.7 Technical and Publication Incident discipline keeps public knowledge aligned with bounded evidence.

***

#### 17.10.9 Incident Response, Correction, and Archive

17.10.9.1 Incident Response, Correction, and Archive means the mandatory process for triage, severity classification, containment, escalation, legal review where needed, safeguard review where needed, technical review where needed, public authority boundary review where needed, readiness boundary review where needed, notification where required or appropriate, correction, withdrawal, restriction, supersession, public repair, lessons learned, archive, and renewal following an Incident.

17.10.9.2 Each Incident shall be assigned an intake record, incident class, severity level, steward, containment status, affected records, affected systems, affected participants or communities where safe, affected public authority where relevant, affected partner where relevant, affected data class, public exposure status, escalation pathway, correction pathway, notice pathway, archive class, and renewal requirement.

17.10.9.3 Triage shall determine whether immediate action is required, including access suspension, publication hold, output withdrawal, data quarantine, credential rotation, system isolation, map removal, dashboard suspension, repository restriction, partner access closure, secure-room closure, public-safe clarification, or stop-the-line escalation.

17.10.9.4 Escalation may be made to GCRI for technical, evidence, AI, data, cyber, compute, repository, benchmark, observability, simulation, digital twin, or software issues; to GRF for public-safe claims, public narrative, legitimacy, participation, public authority boundary, community boundary, and correction issues; to GRA for readiness, finance-facing, insurance-facing, donor, public finance, SPV-readiness, regulated-perimeter, no-reliance, and handoff dependency issues; to National Nodes for national ownership, public authority, local law, sovereign data, community safeguard, and national continuation issues; and to legal, privacy, ethics, cyber, export-control, sanctions, Indigenous protocol, accessibility, or public authority review where required.

17.10.9.5 Notification shall be assessed according to law, contract, protocol, public authority requirement, participant protection, community safeguard, Indigenous protocol where applicable, public safety, privacy, data protection, cyber incident requirements, partner obligations, and public-safe repair needs.

17.10.9.6 Correction may include revised records, revised claims, revised public-safe summaries, revised readiness notes, corrected Dataset Records, corrected Model Cards, corrected System Cards, corrected Benchmark Records, restricted circulation, access closure, public notice, targeted notice, participant notice, community-facing correction, Indigenous notice where applicable, sponsor/provider correction, media correction, public authority clarification, public repair, withdrawal, supersession, downgrade, non-continuation, or archive.

17.10.9.7 Archive shall preserve incident facts, decisions, corrections, withdrawals, supersessions, notice decisions, public repair actions, lessons learned, renewed controls, and future prevention measures under the appropriate access classification, while protecting sensitive details.

17.10.9.8 Incident Response, Correction, and Archive shall feed renewal of templates, workflows, access controls, AI controls, data handling rules, publication rules, public-safe language, partner rules, training, and next-cycle Nexus Universe operations.

17.10.9.9 Incident closure shall not occur until containment, correction, notice assessment, archive, and renewal decisions have been recorded or expressly deferred with reasons.

17.10.9.10 Incident discipline transforms failure into correction, correction into memory, and memory into stronger public-good infrastructure.

***

#### 17.10.10 Final Data and Secure Infrastructure Clause

17.10.10.1 Nexus Acceleration’s technical ambition is legitimate only when data, privacy, cybersecurity, AI, secure infrastructure, dual-use, misuse, access, technical integrity, and publication controls are enforceable, recorded, correctionable, public-safe, and capable of slowing, restricting, withdrawing, repairing, or stopping unsafe technical movement.

17.10.10.2 Incidents are any actual or suspected events affecting data, AI, cyber, privacy, secure infrastructure, dual-use controls, misuse risk, technical integrity, access control, or publication safety. Data Incidents include unauthorized access, loss, exposure, improper transfer, misclassification, unlawful retention, dataset misuse, re-identification, and improper deletion failure. AI Incidents include hallucinated claims, model misuse, unsafe outputs, unauthorized agentic action, data leakage, synthetic misrepresentation, bias harm, and automated overclaim. Cyber Incidents include unauthorized access, credential compromise, malware, vulnerability exposure, misconfiguration, denial of service, repository compromise, and cloud environment breach. Privacy and Protected Knowledge Incidents include privacy breach, protected knowledge exposure, Indigenous knowledge misuse where applicable, community-sensitive data exposure, health-sensitive data misuse, and participant confidentiality failure. Secure Infrastructure Incidents include secure room breach, no-download violation, enclave failure, clean-room misuse, output review failure, partner-system exposure, and access closure failure. Dual-Use and Misuse Incidents include harmful capability exposure, cyber misuse, sensitive geospatial disclosure, public safety risk, biological-sensitive risk, and dangerous operational detail. Technical and Publication Incidents include benchmark misuse, unsafe public release, incorrect technical claim, misleading system card, unsupported public summary, and erroneous public-safe classification. Incident Response, Correction, and Archive require triage, containment, escalation, legal and safeguard review, notification where required, correction, withdrawal, supersession, public repair, lessons learned, and archive.

17.10.10.3 No Incident record, Data Incident record, AI Incident record, Cyber Incident record, Privacy and Protected Knowledge Incident record, Secure Infrastructure Incident record, Dual-Use or Misuse Incident record, Technical or Publication Incident record, Incident Response record, Correction record, Archive record, containment action, escalation action, legal review, safeguard review, technical review, public authority boundary review, readiness boundary review, notification, withdrawal, restriction, supersession, public repair, lessons learned record, renewed control, revised template, access closure, data quarantine, credential rotation, system isolation, repository restriction, dashboard suspension, map withdrawal, public-safe clarification, corrected public-safe summary, corrected readiness note, corrected Benchmark Record, corrected Model Card, corrected System Card, Dataset Record correction, Docket item, ARL status, Nexus Rail routing, Nexus Universe output, National Node routing, National Working Group output, Competence Cell review, GCRI-supported evidence record, GRF-supported public-safe review, GRA-supported readiness review, Handoff Dependency Note, correction notice, withdrawal notice, restricted archive, or public communication shall create certification, validation, recognition standing, maturity status, governance authority by default, public authority approval, procurement status, preferred-provider status, financeability, bankability, investability, creditworthiness, insurability, underwriting acceptance, insurance approval, donor commitment, public finance allocation, budget allocation, sovereign commitment, official warning, emergency command, community consent, Indigenous consent, social license, representation authority, benefit agreement, data ownership transfer, unrestricted data license, privacy compliance certification, security certification, AI safety certification, cyber compliance certification, biological safety determination, telecom approval, spectrum authorization, infrastructure resilience certification, benchmark validation, standards conformance, operational authorization, deployment authorization, project approval, handoff authorization, transaction, or execution authority by implication.

17.10.10.4 The controlling Final Data and Secure Infrastructure Formula is that Nexus may classify data, protect privacy, secure systems, govern AI, operate secure rooms, control dual-use risk, review vendors, restrict access, publish public-safe outputs, detect incidents, contain failures, correct records, withdraw unsafe materials, repair public meaning, archive lessons, and renew controls; but technical ambition is not permission, data access is not data entitlement, AI output is not institutional judgment, cybersecurity is not certification, secure infrastructure is not unrestricted trust, dual-use knowledge is not public content, publication is not validation, correction is not optional, archive is not erasure, and Nexus Acceleration shall remain legitimate only where every data, AI, cyber, privacy, access, secure infrastructure, dual-use, technical, and publication pathway can be bounded before use, reviewed before release, corrected after error, and stopped before harm.

### Next steps

* Review [XVI. SAFEGUARDS](/organization/acceleration/charter/xvi.-safeguards.md) for protected participation, protected knowledge, ethics review, and public narrative controls.
* Review [XVIII. CLAIMS](/organization/acceleration/charter/xviii.-claims.md) and [XV. AUTHORITIES](/organization/acceleration/charter/xv.-authorities.md) for publication limits, authority boundaries, and no-overclaim rules.
* Review [XIX. GOVERNANCE](/organization/acceleration/charter/xix.-governance.md) and [XIV. FINANCE](/organization/acceleration/charter/xiv.-finance.md) for control paths, readiness boundaries, and institutional handoff discipline.


---

# 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/charter/xvii.-data.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.