# X. DATA

Nexus Agile Framework Data defines the **NAF data governance model** for public-good data, metadata, lineage, rights, and controlled access. This section explains how **DICE, Data Commons, public-safe data, controlled data, data rooms, secure rooms, clean rooms, and compute-to-data workflows** support evidence, learning, and lawful handoff context.

This section sets the operating model for **data object lifecycle**, **data rights and AI-use labels**, **metadata and lineage**, **cross-border and sovereignty controls**, and **controlled-room architecture**. It helps Nexus use data safely, publish public-safe outputs, preserve rights, and support downstream readiness without creating public authority records, unrestricted rights, or execution by implication.

### What this section covers

* **Data governance** - Defines Data Commons doctrine, data classes, metadata, lineage, and rights review.
* **Controlled access architecture** - Explains secure rooms, data rooms, clean rooms, and compute-to-data workflows.
* **Boundary discipline** - Defines public-safe data, AI-use limits, handoff limits, and no-authority rules.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [VIII. R\&D](/organization/operations/frameworks/nexus-agile-framework-naf/viii.-r-and-d.md) for research inputs and translation pathways, [IX. SOFTWARE](/organization/operations/frameworks/nexus-agile-framework-naf/ix.-software.md) for data-adjacent software and API controls, and [IV. LIFECYCLE](/organization/operations/frameworks/nexus-agile-framework-naf/iv.-lifecycle.md) for intake, review, release, correction, and archive discipline.

## 10.1 Data Commons Doctrine

### 10.1.1 Data Commons as Public-Good Infrastructure.

10.1.1.1 Data Commons within NAF shall mean the governed public-good data environment through which data signals, datasets, metadata, data dictionaries, schemas, codebooks, data pipelines, lineage records, data-use labels, AI-use labels, public-safe transformations, DRI indicators, Observatory records, Studio inputs, Reports evidence, Marketplace objects, Registry records, Grid inputs, TRL evidence notes, National Portfolio records, Nexus Universe outputs, and lawful handoff dependency packages are created, reviewed, routed, corrected, restricted, published, or archived.

10.1.1.2 Data Commons shall be implemented through DICE as the Nexus environment for Data Commons, Innovation Commons, Software Commons, Knowledge Commons, and controlled commons activity. DICE shall operate as infrastructure for public-good knowledge formation, not as a default open-data warehouse, surveillance system, commercial data broker, unrestricted data lake, public authority data system, finance data room, procurement platform, operational command system, or execution environment.

10.1.1.3 Data Commons shall be governed by public-good purpose, data minimization, purpose limitation, rights review, sensitivity classification, data sovereignty, cross-border controls, privacy, cybersecurity, protected knowledge discipline, community safeguards, Indigenous protocols where applicable, public-safe publication, role separation, access control, compute-to-data preference for restricted data, correctionability, archive discipline, and lawful handoff boundaries.

10.1.1.4 Data Commons shall be open where safe and controlled where necessary. Openness shall not be treated as the default for all data. Data may be open, public-safe, controlled public, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth-sensitive, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, handoff-recipient-only, archive-only, sealed, or deleted according to classification, rights, risk, safeguards, and lawful authority.

### 10.1.2 Public-Safe Data Defined.

10.1.2.1 Public-Safe Data means data, derived data, aggregated data, metadata, statistics, visualizations, summaries, indicators, dashboards, or reports that have been reviewed and transformed so that public release is reasonably consistent with public-good purpose, data rights, privacy, cybersecurity, protected knowledge controls, public authority boundaries, community safeguards, Indigenous protocols where applicable, sensitive location controls, dual-use controls, public-safe communication, and no-conversion rules.

10.1.2.2 Public-Safe Data may be produced through aggregation, masking, redaction, generalization, delay, suppression, synthetic transformation, summary, metadata-only release, controlled vocabulary mapping, public-safe narrative, or other approved transformation. Public-safe transformation shall be recorded with method, source class, transformation steps, limitations, residual risk, review status, correction pathway, and archive rule.

10.1.2.3 Public-Safe Data shall not be presumed to be raw data, complete data, official data, unrestricted data, open data, public authority data, legal evidence, investment data, insurance data, procurement data, consent record, operational command input, or deployment authorization. Public-safe status controls public release; it does not create universal rights or authority.

### 10.1.3 Controlled Data Defined.

10.1.3.1 Controlled Data means data that may be used within NAF only under defined access, purpose, role, room, jurisdiction, review, or output conditions. Controlled Data may include restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, confidential research data, provider data, sponsor-supported data, handoff-recipient-only data, and archive-only data.

10.1.3.2 Controlled Data shall be governed by access class, data-use label, AI-use label, sensitivity class, rights record, source record, jurisdictional context, retention rule, deletion rule, output review, no-download controls where appropriate, compute-to-data preference where appropriate, public-safe transformation rules, incident response, correction pathway, and archive or sealing rule.

10.1.3.3 Controlled Data shall not be treated as unavailable to public-good work. It may support learning, evidence, observability, Studio workflows, DRI interpretation, Reports, National Portfolios, readiness questions, and handoff dependency context through secure rooms, data rooms, clean rooms, compute-to-data workflows, metadata-only records, or public-safe summaries. Controlled Data shall not be exported, published, trained on, shared, reused, or handed off outside its recorded conditions.

### 10.1.4 Metadata as Public-Good Bridge.

10.1.4.1 Metadata shall be treated as a public-good bridge between data protection and data usefulness. Metadata may allow discovery, classification, lineage, rights management, public-safe description, Registry status, Marketplace listing, DRI indicator mapping, GRIx mapping, Studio routing, Reports evidence, Grid input, TRL note, Nexus Universe preparation, National Portfolio memory, and lawful handoff context without exposing raw data.

10.1.4.2 Metadata shall include, where appropriate, title, description, steward, source class, jurisdictional context, collection method, time coverage, spatial coverage, data class, sensitivity class, data-use label, AI-use label, rights status, license status, lineage status, quality notes, completeness notes, update cadence, public-safe status, access class, support class, correction pathway, retention rule, and archive rule.

10.1.4.3 Metadata shall not be presumed harmless. Metadata may itself expose sensitive location, identity, infrastructure, community, Indigenous, health, cyber, public authority, or protected knowledge information. Metadata shall therefore be classified and transformed where necessary.

### 10.1.5 Data as Evidence-Bearing Object.

10.1.5.1 Data under NAF shall be treated as evidence-bearing only to the extent that its source, provenance, lineage, quality, method, scope, limitations, uncertainty, bias, completeness, sensitivity, data-use restrictions, AI-use restrictions, review status, and correction pathway are recorded.

10.1.5.2 Evidence-bearing data may support Research Questions, Evidence Gaps, Method Notes, DRI indicators, Observatory signals, Studio workflows, dashboards, Reports, Grid inputs, TRL evidence notes, National Portfolio records, Nexus Universe outputs, Marketplace objects, Registry records, and handoff dependency packages. Such use shall preserve scope and limitations.

10.1.5.3 Data shall not speak for itself. A dataset, indicator, dashboard, map, model input, benchmark, or data pipeline shall not be treated as approval, rating, warning, public authority decision, finance signal, insurance signal, procurement signal, consent, deployment authorization, or execution instruction.

### 10.1.6 Data as Learning Object.

10.1.6.1 Data may function as a learning object where it is used to teach data literacy, risk literacy, DRI literacy, GRIx literacy, AI literacy, cyber literacy, privacy literacy, public-safe reporting, Studio practice, Academy modules, Risk Academy pathways, Work-Integrated Learning Paths, Foundry Quests, Bounties, Builds, Competence Cell practice, National Working Group practice, and Nexus Universe learning.

10.1.6.2 Learning use of data shall require appropriate anonymization, aggregation, synthetic transformation, public-safe transformation, secure-room access, data-room access, clean-room use, compute-to-data workflows, restricted teaching datasets, or metadata-only records where necessary.

10.1.6.3 Data used for learning shall not create data rights, AI training rights, public authority records, professional qualification, employment status, procurement qualification, consent, deployment authorization, or execution.

### 10.1.7 Data as Intelligence Object.

10.1.7.1 Data may function as an intelligence object when used to produce DRI indicators, Observatory signals, hotspot records, cascade records, dashboards, Studio scenarios, uncertainty labels, confidence labels, public-safe summaries, National Portfolio risk intelligence, public authority learning records, readiness questions, or handoff dependency context.

10.1.7.2 Intelligence use of data shall preserve uncertainty, confidence, limitations, sensitivity, source context, update cadence, public-safe status, no-warning status, no-rating status, finance and insurance boundary status, public authority boundary status, and correction pathway.

10.1.7.3 Data intelligence outputs shall not be public warnings, emergency commands, official forecasts, insurance scores, investment signals, procurement scores, public authority decisions, operational commands, deployment authorizations, or execution instructions.

### 10.1.8 Data Without Unrestricted Rights by Default.

10.1.8.1 No data object within NAF shall be treated as unrestricted by default. Data availability, data discovery, data citation, metadata listing, secure-room access, data-room access, Studio use, Report use, Dashboard use, Marketplace listing, Registry record, Grid input, TRL note, National Portfolio inclusion, Nexus Universe presentation, or handoff dependency reference shall not create ownership, license, reuse right, publication right, AI training right, extraction right, download right, transfer right, or implementation right unless separately recorded.

10.1.8.2 Data rights shall be determined by source authority, license, consent, permission, law, contract, public authority rule, community protocol, Indigenous protocol where applicable, privacy rule, cybersecurity rule, protected knowledge rule, data sovereignty rule, cross-border rule, and recorded data-use label.

10.1.8.3 The default rule is that data may be used only for the purpose, access class, room, workflow, output class, release class, and retention period recorded for that data object.

## 10.2 Data Object Lifecycle

### 10.2.1 Data Signal.

10.2.1.1 A Data Signal is any indication that data may be relevant to a NAF purpose, including research data, public authority data, open data, community data, Indigenous protocol-sensitive data where applicable, provider data, sponsor-supported data, sensor data, geospatial data, Earth observation data, Observatory data, DRI data, Studio data, Campaign data, Academy data, Foundry data, Reports data, Marketplace data, Registry data, Grid data, TRL data, Nexus Universe data, National Portfolio data, or handoff-relevant data.

10.2.1.2 Data Signals shall be recorded before use where they are material to NAF work. Records shall identify source, possible purpose, possible sensitivity, possible rights constraints, possible public-safe status, possible national relevance, and whether the signal requires intake, triage, rejection, restriction, secure-room routing, or correction.

10.2.1.3 A Data Signal shall not be treated as verified data, available data, authorized data, public-safe data, open data, official data, or handoff-ready data.

### 10.2.2 Data Intake.

10.2.2.1 Data Intake shall record the entry of a data object or data signal into NAF. Intake shall identify the data source, steward, submitter, purpose, proposed use, affected Docket item, affected portfolio, file or system location where applicable, data class, sensitivity indicators, rights status, license status, privacy status, cyber status, public authority sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, protected knowledge status, geospatial sensitivity, and initial access restrictions.

10.2.2.2 Data Intake may result in acceptance, conditional acceptance, secure-room routing, data-room routing, clean-room routing, compute-to-data routing, metadata-only record, public-safe transformation, rights review, public authority review, safeguard review, rejection, deletion, sealing, or archive.

10.2.2.3 Data Intake shall not authorize use beyond the intake purpose. Intake is a gate, not permission for unrestricted processing.

### 10.2.3 Data Classification.

10.2.3.1 Data Classification shall assign one or more data classes, access classes, sensitivity classes, jurisdictional contexts, release classes, data-use labels, AI-use labels, public-safe statuses, retention rules, and archive rules to a data object.

10.2.3.2 Classification shall consider source, content, identifiability, sensitivity, rights, license, public authority restrictions, community safeguards, Indigenous protocols where applicable, protected knowledge, youth data, health data, cyber-sensitive data, infrastructure-sensitive data, geospatial data, dual-use risk, cross-border transfer risk, AI-use risk, public-safe risk, and handoff relevance.

10.2.3.3 Classification shall be reviewable and correctable. Misclassification shall trigger correction, access change, output review, publication review, Registry update, Marketplace update, Studio restriction, handoff recall, archive update, or incident response where necessary.

### 10.2.4 Metadata Creation.

10.2.4.1 Metadata Creation shall produce the descriptive, administrative, technical, legal, rights, sensitivity, public-safe, and lifecycle records necessary for data discovery, governance, routing, review, correction, and archive.

10.2.4.2 Metadata shall be created before publication, Marketplace listing, Registry recording, Studio use, Reports publication, Grid input, TRL note, Nexus Universe presentation, National Portfolio inclusion, or handoff dependency packaging unless an approved exception is recorded.

10.2.4.3 Metadata shall be treated as governed content. Metadata may be open, public-safe, controlled, restricted, or archive-only depending on sensitivity and rights.

### 10.2.5 Lineage Capture.

10.2.5.1 Lineage Capture shall record where data came from, how it was collected, how it was transformed, who handled it, what tools processed it, what models used it, what outputs were derived from it, what versions exist, what dependencies apply, and what corrections have occurred.

10.2.5.2 Lineage records shall support evidence quality, reproducibility, public-safe reporting, AI-use governance, DRI interpretation, Observatory integrity, Studio trust, Grid inputs, TRL notes, Registry status, Marketplace descriptions, National Portfolio memory, Nexus Universe outputs, and lawful handoff dependency context.

10.2.5.3 Absence of lineage shall limit release class, support class, reuse, publication, AI use, handoff relevance, and readiness status.

### 10.2.6 Rights Review.

10.2.6.1 Rights Review shall determine whether NAF may use, store, process, transform, publish, summarize, display, share, train on, route, archive, or hand off a data object. Rights Review shall consider law, contract, license, consent, permission, public authority restrictions, privacy rights, data subject rights where applicable, community rights, Indigenous data sovereignty where applicable, protected knowledge, IP rights, confidentiality, trade secrets, national security sensitivity, and cross-border transfer restrictions.

10.2.6.2 Rights Review shall be recorded with findings, permitted uses, prohibited uses, access class, data-use label, AI-use label, release limits, retention rule, deletion rule, public-safe transformation rule, and correction pathway.

10.2.6.3 Rights Review within NAF shall not constitute legal advice by default or override competent legal, public authority, institutional, community, Indigenous, or contractual authority.

### 10.2.7 Data-Use Labeling.

10.2.7.1 Data-Use Labeling shall identify permitted and prohibited uses of a data object. Labels may include no-use pending review, metadata-only, internal review only, research use, learning use, Studio use, secure-room use, data-room use, clean-room use, compute-to-data only, public-safe summary only, controlled public use, open public use, National Portfolio use, Nexus Universe use, Registry metadata use, Marketplace metadata use, handoff-recipient-only use, archive-only use, sealed, or delete.

10.2.7.2 Data-use labels shall be machine-readable where practical and human-readable in records. They shall bind downstream routing, release class, output review, AI-use labeling, Studio use, Reports publication, Marketplace listing, Registry record, Grid input, TRL note, and handoff dependency package.

10.2.7.3 Data-use labels shall be corrected where rights, sensitivity, public-safe status, or purpose changes.

### 10.2.8 AI-Use Labeling.

10.2.8.1 AI-Use Labeling shall identify whether and how a data object may be used with AI systems. Labels may include no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, embedding permitted, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, public-safe AI output only, no external model use, no retention by model provider where applicable, and human review required.

10.2.8.2 AI-use labels shall be determined through rights, privacy, sensitivity, public-safe, cybersecurity, protected knowledge, public authority, community, Indigenous protocol where applicable, and dual-use review.

10.2.8.3 AI-use permission shall not create automated decision authority, AI safety certification, public authority decision, consent beyond scope, data ownership, publication right, or execution authority.

### 10.2.9 Access Control.

10.2.9.1 Access Control shall govern who may view, process, transform, download, export, summarize, publish, train on, route, correct, archive, or hand off a data object. Access Control shall be role-based, purpose-bound, least-privilege, time-bound where appropriate, logged where appropriate, reviewed periodically where appropriate, and corrected where necessary.

10.2.9.2 Access Control may include open access, controlled public access, internal access, restricted access, secure-room access, data-room access, clean-room access, compute-to-data access, public authority learning room access, readiness room access, capital-reader room access, insurance-reader room access, donor-reader room access, handoff-recipient-only access, archive-only access, sealed access, or deletion.

10.2.9.3 Access shall not create ownership, rights to copy, rights to export, rights to publish, rights to train AI, handoff permission, public authority approval, or deployment authorization.

### 10.2.10 Public-Safe Transformation.

10.2.10.1 Public-Safe Transformation shall convert data into outputs that may be released or shared under public-safe conditions. Transformation may include aggregation, anonymization, pseudonymization, masking, redaction, generalization, delay, suppression, synthetic transformation, uncertainty labeling, confidence labeling, narrative summary, controlled vocabulary mapping, geospatial blurring, sensitive site removal, protected knowledge exclusion, or metadata-only release.

10.2.10.2 Public-Safe Transformation shall be recorded with method, source data class, transformation steps, residual risk, limitations, review status, release class, correction pathway, and archive rule.

10.2.10.3 Public-Safe Transformation shall not create unrestricted use, official status, warning authority, public authority approval, consent, financeability, insurance approval, procurement status, deployment authorization, or execution.

### 10.2.11 Publication or Restriction.

10.2.11.1 Data may be published, summarized, listed, recorded, displayed, restricted, sealed, deleted, archived, or routed to controlled rooms according to classification, rights, public-safe status, safeguard status, data-use label, AI-use label, and review findings.

10.2.11.2 Publication may occur through Reports, repositories, Marketplace listings, Registry public fields, dashboards, Academy materials, Campaign materials, Nexus Universe materials, public-safe summaries, or National Portfolio summaries. Restriction may occur through DICE, secure rooms, data rooms, clean rooms, compute-to-data environments, internal repositories, handoff-recipient-only rooms, archive-only records, sealing, or deletion.

10.2.11.3 Publication shall not create unrestricted rights; restriction shall not erase records unless deletion or sealing is required.

### 10.2.12 Correction and Archive.

10.2.12.1 Data Correction may include metadata correction, lineage correction, rights correction, classification correction, access correction, data-use label correction, AI-use label correction, public-safe transformation correction, dataset correction, dashboard correction, Report correction, Registry update, Marketplace update, Studio restriction, Grid correction, TRL correction, handoff recall, deletion, sealing, withdrawal, recall, archive, or non-continuation.

10.2.12.2 Data Archives shall preserve data records according to access class, sensitivity, rights, retention, public-safe status, correction history, successor links, and archive-not-current notices. Archive may be open, public-safe, controlled, restricted, sealed, metadata-only, or deleted according to law, rights, safeguards, and risk.

10.2.12.3 Data correction and archive shall be treated as trust infrastructure. A corrected data record is stronger than an uncorrectable data claim.

## 10.3 Data Classes

### 10.3.1 Open Data.

10.3.1.1 Open Data means data that may be accessed, used, and shared under a stated open license or open-use condition, subject to recorded limitations, attribution requirements, public-safe conditions, and applicable law.

10.3.1.2 Open Data shall still require metadata, provenance, license, quality notes, limitations, update cadence, correction pathway, and archive rule. Open Data may still be unsuitable for AI training, operational use, public authority action, finance use, insurance use, procurement use, or deployment without additional review.

10.3.1.3 Open Data shall not create warranty, official status, certification, unrestricted downstream claims, public authority decision, financeability, insurance approval, procurement readiness, or execution.

### 10.3.2 Public-Safe Data.

10.3.2.1 Public-Safe Data means data that has been transformed or reviewed for public release under NAF public-safe controls. It may include summaries, aggregates, indicators, visualizations, public-safe datasets, public-safe metadata, public-safe maps, public-safe dashboards, and public-safe Reports.

10.3.2.2 Public-Safe Data shall carry source notes, transformation notes, limitations, residual risk, data-use label, AI-use label where applicable, public-safe status, correction pathway, and archive rule.

10.3.2.3 Public-Safe Data shall not be treated as raw data, official data, complete data, public warning, rating, approval, consent, or deployment authorization.

### 10.3.3 Restricted Data.

10.3.3.1 Restricted Data means data subject to access limits due to rights, privacy, cybersecurity, public authority restrictions, community safeguards, Indigenous protocols where applicable, protected knowledge, health sensitivity, youth sensitivity, infrastructure sensitivity, geospatial sensitivity, confidentiality, contract, or risk.

10.3.3.2 Restricted Data shall be handled through controlled access, secure rooms, data rooms, clean rooms, compute-to-data, no-download controls, output review, logging where appropriate, retention rules, correction pathways, and archive rules.

10.3.3.3 Restricted Data shall not be published, exported, trained on, shared, or handed off without recorded authority.

### 10.3.4 Public Authority-Sensitive Data.

10.3.4.1 Public Authority-Sensitive Data means data received from, derived from, relevant to, or affecting public authorities, public functions, public finance, public safety, emergency management, critical infrastructure, regulatory learning, public policy, permits, public warnings, public health, public employment, or other official contexts where misuse or overclaim may affect public authority boundaries.

10.3.4.2 Public Authority-Sensitive Data shall be handled through purpose limitation, access controls, public authority boundary notices, confidentiality controls where applicable, public-safe transformation, secure-room routing where necessary, and correction pathways.

10.3.4.3 Use of Public Authority-Sensitive Data within NAF shall not create official action, public authority approval, public warning, public record status, public finance allocation, procurement decision, regulation, permit, license, emergency command, or execution.

### 10.3.5 Community-Sensitive Data.

10.3.5.1 Community-Sensitive Data means data relating to communities, lived-risk knowledge, local vulnerabilities, local assets, community priorities, location-specific resilience conditions, social conditions, cultural context, local knowledge, community participation, or community-facing impacts where misuse may cause harm, extraction, stigmatization, misrepresentation, or consent overclaim.

10.3.5.2 Community-Sensitive Data shall be governed by non-extractive use, purpose limitation, community-facing explanation where appropriate, access control, public-safe transformation, consent boundary notices, correction pathways, and archive rules.

10.3.5.3 Community-Sensitive Data use shall not imply community consent, endorsement, project approval, land access, deployment approval, or execution.

### 10.3.6 Indigenous Protocol-Sensitive Data Where Applicable.

10.3.6.1 Indigenous Protocol-Sensitive Data means data, knowledge, location information, cultural information, ecological information, governance information, community records, or other information subject to Indigenous protocols, Indigenous data sovereignty principles, protected knowledge obligations, or community-specific permissions where applicable.

10.3.6.2 Such data shall be handled only according to recorded protocols, permissions, restrictions, access conditions, cultural safeguards, protected knowledge controls, public-safe transformation rules, correction pathways, and archive or sealing rules.

10.3.6.3 Participation in Nexus, NAF, research, Campaigns, Studio, National Portfolios, Nexus Universe, or data rooms shall not imply Indigenous consent, protocol approval, knowledge-use permission, land access, deployment authorization, or execution.

### 10.3.7 Protected Knowledge.

10.3.7.1 Protected Knowledge means knowledge that must not be openly disclosed because of cultural, community, Indigenous where applicable, security, cyber, biosecurity, ecological, health, infrastructure, legal, ethical, contractual, confidentiality, or harm-prevention considerations.

10.3.7.2 Protected Knowledge may be excluded, redacted, summarized, restricted, sealed, or processed only in secure or controlled environments. AI-use may be prohibited or restricted to secure-room AI only, with output review.

10.3.7.3 Protected Knowledge shall not be published, trained on, extracted, summarized publicly, handed off, or reused outside recorded conditions.

### 10.3.8 Youth Data.

10.3.8.1 Youth Data means data relating to minors, young participants, students, youth Campaign participants, youth learners, youth contributors, youth volunteers, or youth community participants.

10.3.8.2 Youth Data shall be subject to heightened privacy, consent, permission, access, safeguarding, public display, profiling, AI-use, retention, deletion, correction, and archive controls.

10.3.8.3 Youth participation or learning records shall not create employment status, public display permission, profiling permission, procurement qualification, consent beyond scope, or execution.

### 10.3.9 Health-Sensitive Data.

10.3.9.1 Health-Sensitive Data means data relating to individual health, public health, health systems, health infrastructure, disease, vulnerability, exposure, health services, climate-health risk, One Health, or biosecurity-sensitive contexts.

10.3.9.2 Health-Sensitive Data shall be handled with strict privacy, public health boundary, public authority boundary, biosecurity-sensitive, public-safe publication, and secure-room controls where appropriate.

10.3.9.3 Health-Sensitive Data use in NAF shall not create medical advice, public health decision, public warning, regulatory approval, consent, deployment authorization, or execution.

### 10.3.10 Cyber-Sensitive Data.

10.3.10.1 Cyber-Sensitive Data means data that may expose vulnerabilities, credentials, systems, infrastructure, configurations, access logs, exploit-adjacent information, security incidents, cyber-physical weaknesses, OT/IoT/IIoT systems, or other cyber risk.

10.3.10.2 Cyber-Sensitive Data shall be handled through secure repositories, need-to-know access, no-download controls where appropriate, embargo where appropriate, public-safe cyber summaries, vulnerability disclosure processes, incident records, correction, and archive.

10.3.10.3 Cyber-Sensitive Data shall not be published in a manner that enables harm, public panic, operational misuse, or unauthorized access.

### 10.3.11 Infrastructure-Sensitive Data.

10.3.11.1 Infrastructure-Sensitive Data means data relating to critical infrastructure, utilities, networks, telecom, transportation, energy, water, health systems, food systems, public buildings, emergency systems, industrial systems, cyber-physical systems, or other assets where disclosure may create security, safety, operational, or public authority risks.

10.3.11.2 Infrastructure-Sensitive Data shall be subject to public-safe transformation, aggregation, masking, access controls, secure-room routing, public authority boundary review, cyber review, and handoff restrictions.

10.3.11.3 Infrastructure-Sensitive Data shall not create operational command, public authority approval, infrastructure access, deployment authorization, or execution.

### 10.3.12 Geospatial-Sensitive Data.

10.3.12.1 Geospatial-Sensitive Data means data containing location information that may expose sensitive infrastructure, protected species, sacred sites, protected knowledge, vulnerable communities, private locations, security-relevant assets, emergency assets, health assets, or other sensitive places.

10.3.12.2 Geospatial-Sensitive Data shall be governed by masking, generalization, aggregation, delay, suppression, restricted access, public-safe map publishing, protected knowledge controls, Indigenous protocol controls where applicable, correction, and archive.

10.3.12.3 Geospatial-Sensitive Data shall not be treated as an official map, land-use approval, public warning, surveillance authority, operational command, deployment authorization, or execution.

### 10.3.13 Handoff-Recipient-Only Data.

10.3.13.1 Handoff-Recipient-Only Data means data that may be provided only to a competent lawful recipient under recorded conditions as part of a handoff dependency package, subject to rights, safeguards, public authority dependencies, legal dependencies, data-use restrictions, AI-use restrictions, confidentiality, and recipient responsibility.

10.3.13.2 Handoff-Recipient-Only Data shall not be released through open publication, general Marketplace listing, public dashboards, public Reports, public Registry fields, or general Nexus Universe materials. Metadata or public-safe summaries may be used where permitted.

10.3.13.3 Handoff-recipient access shall not create implementation authority, procurement status, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 10.3.14 Archive-Only Data.

10.3.14.1 Archive-Only Data means data retained for institutional memory, legal record, correction history, reproducibility record, audit, historical analysis, or non-current reference, but no longer active for general use, publication, routing, Studio use, Marketplace listing, Registry active status, Grid input, TRL note, National Portfolio active use, Nexus Universe presentation, or handoff package preparation.

10.3.14.2 Archive-Only Data shall carry archive-not-current notices, access class, retention rule, deletion rule, sealing rule where applicable, successor links, correction history, and permitted historical use.

10.3.14.3 Archive-Only Data shall not be treated as current authority, current evidence, current readiness, current public-safe status, current handoff context, or execution support.

## 10.4 Data Governance Controls

### 10.4.1 Data Minimization.

10.4.1.1 NAF shall collect, use, process, store, publish, and hand off only the data necessary for recorded public-good purposes, evidence needs, learning needs, DRI needs, Observatory needs, Studio needs, Reports needs, Marketplace needs, Registry needs, Grid and TRL needs, National Portfolio needs, Nexus Universe needs, or lawful handoff dependency needs.

10.4.1.2 Data Minimization shall apply to raw data, personal data, sensitive data, metadata, AI inputs, logs, dashboards, Reports, Campaign tools, Academy tools, Studio workflows, secure rooms, data rooms, and handoff packages.

10.4.1.3 Where metadata, public-safe summary, aggregation, synthetic data, compute-to-data, or controlled-room analysis can satisfy the purpose, raw data export shall be avoided.

### 10.4.2 Purpose Limitation.

10.4.2.1 Data shall be used only for the purposes recorded at intake, classification, rights review, data-use labeling, AI-use labeling, access approval, or handoff packaging. New purposes shall require review and updated records.

10.4.2.2 Purpose Limitation shall prevent data collected for learning from being repurposed for employment decisions, procurement decisions, finance decisions, insurance decisions, public authority decisions, surveillance, automated profiling, AI training, public ranking, or execution unless separately and lawfully authorized.

10.4.2.3 Purpose changes shall trigger rights review, data classification review, AI-use review, public-safe review, safeguard review, correction, and archive update where necessary.

### 10.4.3 Consent and Permission.

10.4.3.1 Consent and Permission shall be recorded where required for data collection, use, publication, processing, AI use, sharing, transfer, display, handoff, or archive. Consent and permission records shall specify purpose, scope, duration, withdrawal rights where applicable, access class, data-use label, AI-use label, public display conditions, correction rights, and archive rule.

10.4.3.2 Consent shall not be inferred from participation, attendance, contribution, Campaign signature, learning activity, community engagement, public authority participation, sponsor support, provider contribution, Nexus Universe participation, Studio participation, or data room access.

10.4.3.3 Withdrawal, correction, or limitation requests shall be recorded and handled according to applicable law, rights, safeguards, and archive obligations.

### 10.4.4 Access Control.

10.4.4.1 Access Control shall apply least privilege, role-based access, purpose-bound access, time-bound access where appropriate, logging where appropriate, periodic review where appropriate, and revocation when access is no longer justified.

10.4.4.2 Access shall be classified by user role, data class, room class, workflow, jurisdiction, public-safe status, sensitivity, and handoff relevance. Access may be denied, limited, monitored, reviewed, or revoked where risk, rights, or safeguards require.

10.4.4.3 Access Control failure shall be treated as a data incident where it creates unauthorized access, exposure, use, export, publication, AI use, handoff, or other boundary breach.

### 10.4.5 Cross-Border Controls.

10.4.5.1 Cross-Border Controls shall govern data movement, access, processing, hosting, publication, AI use, secure-room access, data-room access, compute-to-data, cloud use, repository use, Studio use, and handoff across jurisdictions.

10.4.5.2 Cross-Border Controls shall consider data sovereignty, data localization, privacy law, public authority restrictions, community protocols, Indigenous data sovereignty where applicable, health data restrictions, cyber-sensitive restrictions, infrastructure sensitivity, export controls, contractual restrictions, and conflict-of-law concerns.

10.4.5.3 Cross-border availability, remote access, cloud hosting, or repository access shall not create authorization for transfer, publication, AI training, public authority use, handoff, deployment, or execution.

### 10.4.6 Data Sovereignty.

10.4.6.1 Data Sovereignty shall mean that data associated with a jurisdiction, public authority, community, Indigenous institution where applicable, National Portfolio, National Node, or lawful data steward shall be governed according to applicable authority, rights, protocols, and recorded conditions.

10.4.6.2 NAF shall preserve national ownership before local delivery and shall not bypass national data pathways, public authority restrictions, National Node requirements, community safeguards, Indigenous protocols where applicable, or lawful data stewards.

10.4.6.3 Data Sovereignty shall be reflected in hosting, access, processing, publication, AI-use, secure-room routing, data-room routing, compute-to-data workflows, handoff packages, correction, and archive.

### 10.4.7 Data Localization.

10.4.7.1 Data Localization shall apply where data must remain within a jurisdiction, National Node, sovereign compute environment, public authority environment, community-controlled environment, Indigenous protocol-sensitive environment where applicable, secure room, data room, clean room, or other controlled environment.

10.4.7.2 Localization may require national repositories, national mirrors, local processing, local review, local language metadata, national access controls, compute-to-data, restricted export, public-safe summaries, or metadata-only external release.

10.4.7.3 Localization shall not create public authority approval, data ownership transfer, deployment authority, or execution. It is a control condition.

### 10.4.8 Retention.

10.4.8.1 Retention rules shall define how long data, metadata, logs, access records, AI prompts, AI outputs, Studio outputs, data-room records, secure-room records, Reports evidence, Registry records, Marketplace records, Grid inputs, TRL notes, National Portfolio records, Nexus Universe records, and handoff dependency records may be kept.

10.4.8.2 Retention shall be based on purpose, legal duty, rights, consent, public-good value, correction needs, reproducibility needs, archive value, sensitivity, public-safe status, and risk.

10.4.8.3 Retention expiration shall trigger deletion, sealing, anonymization, archive, or renewed review.

### 10.4.9 Deletion.

10.4.9.1 Deletion shall be used where data is no longer needed, rights require deletion, consent is withdrawn where applicable, data was improperly collected, data is unsafe to retain, retention has expired, or correction requires removal.

10.4.9.2 Deletion shall be recorded where legally and technically appropriate, including scope, date, reason, affected objects, downstream corrections, Registry updates, Marketplace updates, Studio restrictions, Reports corrections, Grid corrections, TRL corrections, handoff recall, and archive implications.

10.4.9.3 Deletion shall not erase necessary correction notices or accountability records where retention of minimal records is lawful and required for trust, unless sealing or complete deletion is required.

### 10.4.10 Sealing.

10.4.10.1 Sealing shall restrict access to data or records that must be preserved but not generally accessible due to legal, privacy, public authority, community, Indigenous protocol where applicable, protected knowledge, cyber, health, infrastructure, geospatial, dual-use, or safeguard reasons.

10.4.10.2 Sealed records shall carry access conditions, steward, reason, review date where applicable, permitted use, prohibited use, correction pathway, and archive rule.

10.4.10.3 Sealing shall not convert data into active evidence, public-safe data, open data, or handoff-ready data.

### 10.4.11 Archive.

10.4.11.1 Archive shall preserve data records for institutional memory, reproducibility, legal record, correction, research history, public-safe reporting history, Nexus Network memory, National Portfolio history, Nexus Universe history, or lawful handoff history.

10.4.11.2 Archive shall include metadata, status, access class, sensitivity, rights, lineage, correction history, successor links, archive-not-current notice, retention rule, deletion rule, sealing rule where applicable, and permitted historical use.

10.4.11.3 Archive status shall not create current authority, current rights, current public-safe status, current readiness, current handoff permission, or execution authority.

### 10.4.12 Incident Response.

10.4.12.1 Data Incident Response shall apply to unauthorized access, unauthorized use, unauthorized publication, unauthorized export, unauthorized AI use, misclassification, rights breach, privacy breach, cyber breach, protected knowledge exposure, community-sensitive exposure, Indigenous protocol breach where applicable, youth data breach, health data breach, infrastructure-sensitive exposure, geospatial-sensitive exposure, handoff overclaim, or execution overclaim involving data.

10.4.12.2 Incident Response may include immediate containment, access revocation, claims freeze, data freeze, technical freeze, AI-use freeze, public-safe notice, affected party notification where appropriate, Registry update, Marketplace delisting, Report correction, Studio restriction, Grid correction, TRL correction, handoff recall, deletion, sealing, archive, and corrective action.

10.4.12.3 Incident Response shall preserve truth, repair, and correction. It shall not be hidden where downstream trust, public safety, rights, safeguards, or handoff dependency context is affected.

## 10.5 Secure-Room and Compute-to-Data Architecture

### 10.5.1 Secure Room.

10.5.1.1 A Secure Room is a controlled environment for viewing, analyzing, reviewing, transforming, or summarizing sensitive data or sensitive outputs under defined access, purpose, no-download, logging, output review, public-safe, and correction controls.

10.5.1.2 Secure Rooms may be used for restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, health-sensitive data, AI-review workflows, Studio workflows, readiness reviews, or handoff dependency preparation.

10.5.1.3 Secure Room access shall not create data rights, public authority approval, procurement status, financeability, insurance approval, consent, deployment authorization, or execution.

### 10.5.2 Data Room.

10.5.2.1 A Data Room is a controlled environment for organized review of data, metadata, evidence, documents, assumptions, dependencies, diligence gaps, public authority dependencies, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, or handoff dependency materials.

10.5.2.2 Data Rooms shall apply role-based access, purpose limitation, no-download controls where appropriate, output review, viewer records where appropriate, confidentiality controls where applicable, data-use labels, AI-use labels, correction pathway, and archive rule.

10.5.2.3 Data Room access shall not create handoff permission, finance approval, insurance approval, investment interest, donor commitment, public finance allocation, procurement status, public authority approval, consent, deployment authorization, or execution.

### 10.5.3 Clean Room.

10.5.3.1 A Clean Room is a controlled environment that allows approved analysis, comparison, matching, aggregation, or computation across data sources without exposing raw data beyond permitted boundaries.

10.5.3.2 Clean Rooms shall define approved datasets, approved users, approved queries, approved outputs, privacy-preserving methods, aggregation thresholds where applicable, no raw extraction rules, logging, output review, correction pathway, and archive rule.

10.5.3.3 Clean Room results shall not create unrestricted data rights, official findings, public authority decisions, financeability, insurance approval, procurement status, consent, deployment authorization, or execution.

### 10.5.4 Protected Knowledge Room.

10.5.4.1 A Protected Knowledge Room is a controlled environment for knowledge that requires special handling due to cultural, community, Indigenous protocol where applicable, ecological, security, cyber, biosecurity, health, infrastructure, legal, contractual, or ethical restrictions.

10.5.4.2 Protected Knowledge Rooms shall define who may access knowledge, for what purpose, under what protocol, what outputs are prohibited, what outputs may be summarized, what AI use is prohibited or restricted, what publication is prohibited, what correction and withdrawal rights apply, and how records are sealed or archived.

10.5.4.3 Protected Knowledge Room participation shall not create ownership transfer, publication permission, AI training permission, consent beyond scope, public authority approval, deployment authorization, or execution.

### 10.5.5 Public Authority Learning Room.

10.5.5.1 A Public Authority Learning Room is a controlled environment in which public authorities and other participants may review evidence, data, scenarios, dashboards, Studio workflows, Reports, DRI outputs, National Portfolio materials, readiness questions, and handoff dependencies for learning purposes.

10.5.5.2 Public Authority Learning Rooms shall include no-decision notices, public authority boundary notices, confidentiality controls where required, public-safe controls, data-use labels, AI-use labels, output review, correction pathway, and archive rule.

10.5.5.3 Public Authority Learning Room participation shall not create official action, public authority approval, public warning, regulation, permit, license, public finance allocation, procurement decision, deployment authorization, or execution.

### 10.5.6 Readiness Room.

10.5.6.1 A Readiness Room is a controlled environment for reviewing evidence readiness, data readiness, technical readiness, public-safe readiness, safeguard readiness, National Portfolio readiness, Nexus Universe readiness, Grid inputs, TRL notes, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, and handoff dependency conditions.

10.5.6.2 Readiness Rooms shall maintain no-certification, no-finance, no-insurance, no-procurement, no-public-authority, no-consent, no-deployment, and no-execution notices.

10.5.6.3 Readiness Room outputs shall be readiness context, not approval, certification, financeability, insurability, procurement readiness, public authority approval, consent, deployment authorization, or execution.

### 10.5.7 Capital-Reader Room.

10.5.7.1 A Capital-Reader Room is a controlled, no-reliance, non-advisory, non-soliciting, non-transactional environment where capital readers may review bounded readiness context, assumptions, dependencies, diligence gaps, National Portfolio context, Nexus Universe outputs, handoff dependency notes, and public-good records.

10.5.7.2 Capital-Reader Rooms shall be governed by regulated-perimeter discipline, confidentiality where appropriate, competition compliance, no-solicitation, no-offering, no-investment-advice, no-reliance notices, conflict controls, output review, correction pathway, and archive rule.

10.5.7.3 Capital-Reader Room access or participation shall not create investment interest, capital commitment, financeability, bankability, valuation, rating, public finance allocation, procurement status, public authority approval, deployment authorization, or execution.

### 10.5.8 Insurance-Reader Room.

10.5.8.1 An Insurance-Reader Room is a controlled, no-reliance, non-underwriting, non-advisory environment where insurers, reinsurers, brokers where lawfully permitted, risk model readers, and related actors may review bounded insurance-readiness questions, protection-gap context, risk-layering questions, DRI context, assumptions, dependencies, and handoff notes.

10.5.8.2 Insurance-Reader Rooms shall include no-underwriting notices, no-insurance-approval notices, no-rating notices, no-reliance notices, confidentiality controls, competition controls, regulated-perimeter controls, output review, correction pathway, and archive rule.

10.5.8.3 Insurance-Reader Room participation shall not create underwriting, insurability, premium indication, coverage commitment, insurance approval, rating, procurement status, public authority approval, deployment authorization, or execution.

### 10.5.9 Donor-Reader Room.

10.5.9.1 A Donor-Reader Room is a controlled, no-commitment, non-transactional environment where donors, foundations, philanthropic actors, development actors, and public-interest funders may review public-good context, National Portfolio needs, Campaign support context, Nexus Universe outputs, evidence records, readiness questions, and handoff dependency notes.

10.5.9.2 Donor-Reader Rooms shall include no-commitment notices, no-grant-award notices, no-public-finance-allocation notices, no-procurement notices, no-control notices, conflict controls, public-safe controls, output review, correction pathway, and archive rule.

10.5.9.3 Donor-Reader Room participation shall not create donor commitment, grant approval, public finance allocation, procurement status, endorsement, public authority approval, deployment authorization, or execution.

### 10.5.10 Output Review.

10.5.10.1 Output Review shall apply to outputs generated from secure rooms, data rooms, clean rooms, protected knowledge rooms, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, compute-to-data workflows, Studio workflows, and controlled AI workflows.

10.5.10.2 Output Review shall determine whether an output may be exported, summarized, published, listed, recorded, taught, displayed, routed, included in Reports, used in Studio, added to Registry, listed in Marketplace, used as Grid input, used as TRL note, presented in Nexus Universe, included in National Portfolios, included in handoff packages, corrected, restricted, sealed, or archived.

10.5.10.3 Output Review shall not create approval, certification, public authority decision, financeability, insurance approval, procurement status, consent, deployment authorization, or execution.

### 10.5.11 No-Download Controls.

10.5.11.1 No-Download Controls shall restrict copying, exporting, downloading, screenshots where appropriate, bulk extraction, raw data export, model extraction, credential export, location export, or other data removal from controlled rooms.

10.5.11.2 No-Download Controls shall be combined with access control, logging where appropriate, output review, technical controls, user obligations, incident response, correction, and archive.

10.5.11.3 No-Download Controls reduce risk but do not eliminate responsibility. Users remain bound by purpose, confidentiality, public-safe, safeguard, data-use, AI-use, and correction obligations.

### 10.5.12 Room Archive.

10.5.12.1 Room Archive shall preserve the record of controlled-room activity, including room purpose, data objects, participants, access approvals, data-use labels, AI-use labels, outputs, output reviews, restrictions, corrections, incidents, withdrawals, recalls, and archive status, subject to privacy, confidentiality, protected knowledge, and legal controls.

10.5.12.2 Room Archive may be open only where safe and lawful; otherwise it shall be controlled, restricted, sealed, metadata-only, or deleted according to retention and rights requirements.

10.5.12.3 Room Archive shall not create current authority, public authority approval, financeability, insurance approval, procurement status, consent, deployment authorization, or execution.

## 10.6 Data Boundaries

### 10.6.1 Data Availability Is Not Data Right.

10.6.1.1 The fact that data is visible, discoverable, cited, listed, held in DICE, referenced in Reports, displayed in a dashboard, used in Studio, described in Registry, listed in Marketplace, included in Grid, referenced in a TRL note, presented in Nexus Universe, included in a National Portfolio, or referenced in a handoff dependency package shall not create a right to access, copy, download, reuse, publish, transfer, train on, analyze, commercialize, operationalize, or hand off such data.

10.6.1.2 Data rights must be separately recorded through license, permission, consent, legal authority, public authority rule, community process, Indigenous protocol where applicable, contract, or other lawful basis.

### 10.6.2 Metadata Is Not Open Data.

10.6.2.1 Metadata describing a data object shall not make the underlying data open, accessible, reusable, downloadable, publishable, transferable, AI-trainable, or handoff-ready.

10.6.2.2 Metadata may itself be restricted where it exposes sensitive source, location, identity, infrastructure, protected knowledge, community information, Indigenous protocol-sensitive information where applicable, cyber-sensitive information, health-sensitive information, or other risk.

### 10.6.3 Secure Room Is Not Public Authority Approval.

10.6.3.1 Secure Room use, Public Authority Learning Room use, Studio use, controlled-room review, or public authority participation in a room shall not create public authority approval, official action, regulation, permit, license, public warning, emergency command, public finance allocation, procurement decision, or deployment authorization.

10.6.3.2 Public authority action, where required, must be separately and lawfully recorded by the competent public authority outside NAF’s default data posture.

### 10.6.4 Data Room Access Is Not Handoff Permission.

10.6.4.1 Data Room access shall not create permission to implement, procure, finance, insure, deploy, operate, command, commercialize, publish, transfer, or execute. It allows controlled review under recorded conditions only.

10.6.4.2 Handoff permission, where applicable, must be separately reviewed through handoff dependency rules, recipient responsibility records, rights review, public authority dependencies, legal dependencies, safeguard dependencies, finance and insurance boundaries, procurement boundaries, and correction pathways.

### 10.6.5 AI Use Is Not Automated Decision Authority.

10.6.5.1 AI use on or with data within NAF shall not create automated decision authority. AI may assist retrieval, summarization, classification, evaluation, analysis, translation, code support, dashboard support, public-safe drafting, or Studio workflows only under recorded AI-use labels, human review, output classification, and correction controls.

10.6.5.2 AI outputs based on NAF data shall not be treated as public authority decisions, finance decisions, insurance decisions, procurement decisions, employment decisions, credential decisions, certification decisions, consent determinations, public warnings, deployment authorizations, or execution instructions.

### 10.6.6 Data Object Is Not Public Authority Record Unless Separately Recorded.

10.6.6.1 A data object within NAF shall not be treated as a public authority record merely because it relates to a public authority, includes public data, was reviewed by a public authority participant, appears in a Public Authority Learning Room, supports a National Portfolio, appears in Nexus Universe, or informs public-good reporting.

10.6.6.2 Public authority record status, where applicable, must arise from the competent public authority’s own lawful processes, recordkeeping systems, statutory duties, and official acts.

10.6.6.3 The final data rule of Part X is that NAF may collect, classify, transform, analyze, teach, publish, restrict, route, correct, archive, and hand off data context only through governed records, rights, labels, rooms, safeguards, public-safe controls, and lawful dependencies. No data object, metadata record, dataset, dashboard, indicator, secure-room output, data-room access, clean-room result, compute-to-data output, AI output, public-safe summary, Marketplace listing, Registry record, Grid input, TRL note, National Portfolio object, Nexus Universe output, or handoff dependency package shall become data right, public authority record, public warning, certification, procurement status, financeability, insurance approval, consent, deployment authorization, operation, command, surveillance authority, agency, employment, or execution by implication.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/nexus-agile-framework-naf/x.-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.