# V. DATA

## 5.1 Data Commons Doctrine

### 5.1.1 Data commons defined.

Data commons under DDPGF means a governed, record-bearing, rights-aware, security-aware, privacy-preserving, public-good data environment through which data objects, metadata objects, data dictionaries, schemas, codebooks, data pipelines, feature sets, benchmark datasets, DRI datasets, Observatory datasets, National Portfolio datasets, and related data products may be created, classified, reviewed, stewarded, accessed, transformed, published, restricted, corrected, archived, or lawfully handed off. A data commons shall not be treated as an uncontrolled pool of information, a public data dump, a surveillance apparatus, a public authority database by implication, a proprietary extraction channel, a procurement instrument, a finance asset, an insurance scoring system, or an execution environment.

A DDPGF data commons shall be governed through object identity, source review, rights review, sensitivity review, data-use labels, AI-use labels, lineage capture, quality assessment, access controls, public-safe transformation, repository routing, DICE routing, Registry records, Marketplace listings where appropriate, correction pathways, and archive rules. It shall support public-good research, learning, observability, risk intelligence, disaster-risk intelligence, WFEH-B analysis, public-safe reporting, Nexus Studio workflows, Nexus Foundry builds, Nexus Reports, Nexus Academy and Risk Academy learning, Nexus Universe preparation, National Portfolio formation, Grid and TRL evidence, and lawful handoff context, without converting data availability into data ownership, data rights, public authority approval, procurement eligibility, financeability, insurance approval, community consent, Indigenous consent, deployment authorization, or execution authority.

### 5.1.2 Public-safe data defined.

Public-safe data means data that has been reviewed, transformed, summarized, aggregated, generalized, masked, delayed, redacted, de-identified where appropriate, contextualized, or otherwise prepared for public or controlled-public use without exposing restricted data, personal data, protected knowledge, sensitive community knowledge, Indigenous protocol-sensitive knowledge where applicable, sensitive geospatial information, cybersecurity-sensitive information, infrastructure-sensitive information, health-sensitive information, youth data, confidential information, public authority-sensitive information, or other information that could create harm, misinterpretation, overclaim, operational risk, security risk, privacy risk, legal risk, or public authority boundary risk.

Public-safe data shall be public-safe only within recorded scope. A public-safe label shall identify the source class, transformation method, aggregation level, masking rules, limitations, uncertainty, update cadence, permitted uses, prohibited uses where applicable, citation requirements, access class, correction pathway, and archive rule. Public-safe data shall not imply that raw data is open, that all underlying rights are cleared for unrestricted reuse, that re-identification risk is impossible, that the data is complete or authoritative, that it constitutes an official public authority record, or that it may be used for high-stakes decisions, finance, insurance, procurement, emergency command, public warnings, or deployment without separate lawful authority.

### 5.1.3 Controlled data defined.

Controlled data means data that may be useful for public-good research, learning, observability, risk intelligence, national capability formation, Studio workflows, secure-room analysis, public authority learning, readiness review, or lawful handoff context, but that cannot be made openly available because of legal, contractual, ethical, security, privacy, sovereignty, community, Indigenous protocol, public authority, cybersecurity, infrastructure, health, youth, geospatial, protected knowledge, or other sensitivity constraints. 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, handoff-recipient-only data, and archive-only data.

Controlled data shall be governed by access controls, purpose limitation, data minimization, role-based permissions, secure rooms, data rooms, clean rooms, compute-to-data environments, no-download rules, output review, logging, retention rules, deletion or sealing rules where required, incident response, correction, and archive. Controlled data shall not be downgraded, exported, summarized, reused, linked, modeled, published, transferred, or handed off without review. Controlled access shall not create data rights, data ownership, public authority approval, handoff permission, financeability, insurance approval, procurement status, consent, deployment authorization, or execution authority.

### 5.1.4 Metadata as public-good bridge.

Metadata shall serve as the public-good bridge between discoverability and restriction. Where raw data or controlled data cannot be openly released, metadata may allow lawful users, reviewers, learners, public authorities, researchers, national nodes, contributors, and handoff recipients to understand that a data object exists, what it concerns, how it was sourced, how it is classified, what rights and sensitivities apply, what quality and lineage records exist, what access conditions apply, what public-safe summaries are available, and what correction or archive rules govern it. Metadata shall make data legible without making restricted data open.

Metadata shall include, where applicable, title, description, purpose, scope, source class, data class, rights status, steward, jurisdictional context, lineage summary, data-use label, AI-use label, sensitivity class, public-safe status, quality status, access class, license or use-condition class, review status, support class, Registry status, Marketplace eligibility, correction pathway, and archive rule. Metadata shall not be treated as open data, permission to access underlying data, permission to reuse underlying data, public authority record, data-quality certification, privacy compliance determination, public warning, rating, finance signal, procurement signal, or execution authority.

### 5.1.5 Data as evidence-bearing object.

Data under DDPGF shall be governed as an evidence-bearing object. Its value shall depend not only on content, but on recorded provenance, source review, rights review, sensitivity review, collection method, transformation method, lineage, quality, limitations, uncertainty, access class, data-use label, AI-use label, public-safe status, review history, correction history, and archive status. A data object shall not be treated as reliable, reusable, public-safe, AI-usable, handoff-ready, or publishable merely because it exists, was uploaded, was obtained from a known source, was used in a report, was displayed in a dashboard, or was included in a Studio workflow.

Evidence-bearing data shall support reviewable public-good work, including DRI indicators, GRIx mapping, Observatory signals, National Portfolio records, Reports, Studio workflows, Foundry builds, Academy learning, Risk Academy learning, Marketplace listings, Registry records, Grid inputs, TRL notes, and lawful handoff dependency packages. Evidence-bearing status shall not create truth-finality, legal authority, certification, public authority approval, procurement status, financeability, insurance approval, community consent, Indigenous consent, deployment authorization, or execution authority.

### 5.1.6 Data as learning object.

Data may be used as a learning object within Nexus Academy, Risk Academy, SCF, ILA, WILPs, Foundry, Competence Cells, National Working Groups, Labs, Studio, DRI literacy, GRIx literacy, Observatory literacy, public-safe reporting training, secure-room training, compute-to-data training, AI-use training, cyber and privacy training, and lawful handoff literacy. Learning uses may involve sample datasets, synthetic datasets, public-safe datasets, sandbox datasets, anonymized datasets, controlled-room datasets, notebooks, exercises, dashboards, simulations, data dictionaries, schemas, benchmark datasets, and public-safe summaries.

Data used for learning shall be classified and governed according to its sensitivity and rights. Learning use shall not create unrestricted reuse, data rights, credential rights, professional authorization, public authority competence, procurement eligibility, employment status, deployment authorization, or execution authority. Learner access to data shall be bounded by access class, purpose limitation, privacy controls, output review, and correction rules.

### 5.1.7 Data as intelligence object.

Data may become an intelligence object where it is used to generate, support, or contextualize signals, indicators, dashboards, risk intelligence, disaster-risk intelligence, WFEH-B analysis, Observatory outputs, scenario inputs, digital twin inputs, public-safe summaries, National Portfolio records, Reports, Studio workflows, Grid inputs, TRL notes, or handoff dependency notes. Intelligence use shall require method notes, confidence labels, uncertainty labels where applicable, lineage references, data-quality notes, limitations, public-safe review, sensitivity review, and correction pathways.

Data as intelligence shall not become warning authority, rating authority, forecast certainty, insurance score, investment signal, procurement signal, public authority decision, emergency command, operational directive, or deployment authorization. Intelligence outputs shall remain bounded by source quality, method quality, uncertainty, review class, public-safe status, and institutional role separation.

### 5.1.8 Data without unrestricted rights by default.

No data object shall be presumed open, reusable, exportable, AI-trainable, publishable, linkable, downloadable, transferable, or handoff-ready by default. Every data object shall require rights review, source review, sensitivity review, data-use labeling, AI-use labeling where applicable, access classification, public-safe review where publication is considered, and correction pathway. Public visibility, repository deposit, metadata publication, dashboard display, report citation, Marketplace listing, Registry record, Studio use, or Nexus Universe presentation shall not create unrestricted rights.

The default DDPGF posture shall be: open where safe and authorized; controlled where necessary; restricted where required; compute-to-data where data movement is inappropriate; public-safe summaries where raw disclosure would be unsafe; sealed or archived where continued use is unlawful, unsafe, or inconsistent with safeguards. Data governance shall preserve public-good use without data extraction.

## 5.2 Data Object Classes

### 5.2.1 Raw data.

Raw data means data in its original or near-original form as received, collected, observed, sensed, submitted, scraped where lawful, generated, measured, transferred, uploaded, or recorded before substantive cleaning, transformation, aggregation, normalization, anonymization, masking, labeling, or interpretation. Raw data may include files, tables, logs, sensor streams, survey responses, geospatial layers, satellite or Earth observation inputs, device outputs, public authority inputs, community submissions, research outputs, incident records, cyber records, health-adjacent records, infrastructure records, field observations, and system-generated data.

Raw data shall be treated as high-governance by default until reviewed. It shall require source review, rights review, sensitivity review, data-use labeling, AI-use labeling where applicable, lineage capture, access control, retention classification, and public-safe assessment before any broader use. Raw data shall not be published, used for AI training, exported, linked, displayed, handed off, or reused as if open without review. Raw data publication shall be exceptional and shall require recorded authority, rights clearance, sensitivity clearance, public-safe determination, and correction pathway.

### 5.2.2 Processed data.

Processed data means data that has been cleaned, normalized, transformed, harmonized, joined, enriched, structured, filtered, coded, categorized, converted, standardized, summarized, or otherwise modified from raw form. Processed data shall retain lineage records linking it to source data, processing steps, scripts or workflows, assumptions, exclusions, quality checks, transformations, versions, and responsible stewards.

Processed data may be more usable than raw data but shall not automatically be safer, more accurate, public-safe, open, AI-usable, or handoff-ready. Processing may introduce errors, bias, loss of context, sensitivity risks, re-identification risks, semantic drift, or overclaim risk. Processed data shall remain governed according to its data class, rights, sensitivity, public-safe status, and permitted uses.

### 5.2.3 Public-safe data.

Public-safe data means data prepared for public or controlled-public release within recorded scope through transformation, aggregation, masking, generalization, redaction, de-identification where appropriate, delay, summarization, or other risk-reduction methods. Public-safe data shall include public-safe status, transformation notes, limitations, uncertainty notes, source references, update cadence, permitted uses, prohibited uses where applicable, and correction pathway.

Public-safe data shall not be treated as raw data release, unrestricted reuse permission, public authority record, official warning, official map, official statistic, rating, certification, finance signal, procurement signal, or deployment authorization. Public-safe status shall be reviewable, correctionable, and subject to withdrawal where risks, errors, rights issues, or overclaims arise.

### 5.2.4 Aggregated data.

Aggregated data means data combined into group-level, summary-level, regional-level, temporal-level, thematic-level, sectoral-level, portfolio-level, or category-level form. Aggregation may support public-safe reporting, dashboards, DRI summaries, Observatory outputs, National Portfolio reporting, Marketplace analytics, Registry summaries, Reports, Academy learning, Studio exercises, and handoff context.

Aggregation shall be governed to prevent re-identification, sensitive inference, protected knowledge exposure, community harm, Indigenous protocol breaches where applicable, misleading interpretation, false precision, and improper ranking. Aggregated data shall include aggregation method, minimum cell-size rules where applicable, suppression rules where applicable, uncertainty notes, update cadence, and correction pathway. Aggregation shall not create official statistics, ratings, rankings, warnings, financeability, procurement status, or public authority decisions by implication.

### 5.2.5 Synthetic data.

Synthetic data means data generated artificially to resemble, simulate, approximate, augment, test, train, demonstrate, or validate workflows without necessarily disclosing underlying raw data. Synthetic data may support learning, software testing, model evaluation, Studio demonstrations, data pipeline development, public-safe examples, secure-room preparation, and low-risk sharing where properly governed.

Synthetic data shall require records describing generation method, source relationship, limitations, fidelity, privacy assumptions, intended uses, prohibited uses, bias risks, model risks, and public-safe status. Synthetic data shall not automatically be risk-free, unrestricted, representative, statistically valid, privacy-preserving, AI-trainable, production-suitable, or public-safe. Synthetic data shall not be used to make public authority decisions, finance decisions, insurance decisions, procurement decisions, deployment decisions, or high-stakes determinations without separate lawful review.

### 5.2.6 Metadata-only records.

Metadata-only records mean records that describe a data object without exposing the data itself. They may be used where underlying data is restricted, controlled, protected, confidential, sensitive, sovereign, community-sensitive, Indigenous protocol-sensitive where applicable, cyber-sensitive, health-sensitive, infrastructure-sensitive, youth-related, geospatial-sensitive, handoff-recipient-only, or archive-only. Metadata-only records may support discoverability, Registry status truth, Marketplace awareness, Reports references, public authority learning, DRI tracking, Observatory cataloguing, National Portfolio mapping, and handoff dependency awareness.

Metadata-only records shall not imply that the underlying data is open, accessible, reusable, downloadable, AI-usable, cleared for publication, or available for handoff. Any request to access underlying data shall follow the data object’s access class, rights, permissions, review requirements, secure-room rules, and correction pathway.

### 5.2.7 Data dictionaries.

Data dictionaries shall describe fields, variables, definitions, units, formats, allowable values, coding rules, missing-value rules, data types, collection notes, transformation notes, sensitivity notes, and quality notes. Data dictionaries shall support interoperability, interpretation, quality review, learning, reproducibility, DRI indicator development, GRIx mapping, Studio workflows, Reports, Registry records, Marketplace listings, and handoff packages.

A data dictionary shall not make the underlying data open, complete, authoritative, legally reusable, public-safe, or suitable for AI training by default. It shall be versioned, corrected, localized where needed, and linked to source data and schemas where applicable.

### 5.2.8 Codebooks.

Codebooks shall describe coding schemes, category meanings, survey instruments, variable labels, classification logic, coding decisions, transformations, exclusions, annotations, interpretation guidance, uncertainty notes, and limitations. Codebooks may support research, DRI, Observatory, WFEH-B analysis, public-safe reporting, learning, Studio exercises, and National Portfolio work.

Codebooks shall preserve semantic discipline and prevent drift. A codebook shall not create legal classification, public authority determination, rating, certification, procurement status, financeability, or deployment authorization. Codebook corrections shall propagate to affected datasets, reports, dashboards, models, Registry records, Marketplace listings, and handoff packages where applicable.

### 5.2.9 Schemas.

Schemas shall define the structure, fields, relationships, validation rules, data types, required elements, optional elements, controlled vocabularies, data exchange rules, API payload rules, Registry record requirements, Marketplace listing requirements, Studio workflow inputs, Grid inputs, TRL evidence notes, DRI indicators, Observatory objects, proof receipts, credential objects, and handoff package formats. Schemas shall support interoperability and public-good reuse.

Schema conformance shall not be certification, approval, public authority adoption, legal equivalence, data-quality guarantee, procurement readiness, financeability, insurability, or deployment authorization. Schemas shall be versioned, localized, mapped to external standards where appropriate, and corrected when errors, ambiguity, incompatibility, or boundary risks arise.

### 5.2.10 Data pipelines.

Data pipelines shall be governed as workflows that ingest, transform, validate, enrich, aggregate, anonymize, mask, route, publish, restrict, archive, or hand off data objects. A data pipeline may be implemented in code, notebooks, services, APIs, Studio workflows, secure-room workflows, compute-to-data workflows, or controlled infrastructure environments. Each pipeline shall record input sources, rights status, transformations, dependencies, data-use labels, AI-use labels, quality checks, access controls, output classes, public-safe review, error handling, logging, correction pathway, and archive rule.

A data pipeline shall not create data rights, public authority approval, unrestricted output rights, AI training permission, procurement status, financeability, insurance approval, deployment authorization, or execution authority. Pipeline outputs remain governed by output classification and review status.

### 5.2.11 Feature sets.

Feature sets mean structured variables, indicators, model inputs, derived attributes, or engineered data elements prepared for analysis, AI, machine learning, risk modeling, dashboards, DRI, Observatory workflows, digital twins, simulations, or Studio workflows. Feature sets shall include lineage, derivation logic, source references, feature definitions, sensitivity review, bias and harm review where applicable, AI-use label, permitted uses, prohibited uses where applicable, and correction pathway.

Feature sets shall not be used for high-stakes automated decisions, public authority determinations, finance decisions, insurance underwriting, procurement scoring, employment decisions, community consent decisions, or deployment authorization unless separately and lawfully governed outside DDPGF default posture. Feature-set availability shall not imply model validity, fairness, safety, or legal compliance.

### 5.2.12 Benchmark datasets.

Benchmark datasets shall be governed as datasets used to evaluate, compare, test, validate within scope, or monitor software, models, AI systems, data pipelines, dashboards, indicators, simulations, digital twins, or Studio workflows. Benchmark datasets shall include benchmark purpose, scope, source class, rights status, sensitivity class, representativeness notes, limitations, known biases, update cadence, evaluation protocol, permitted uses, prohibited uses where applicable, and correction pathway.

Benchmark performance shall not create general validation, AI safety certification, security certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution authority. Benchmark datasets shall be corrected or retired where they become outdated, biased, compromised, rights-defective, unsafe, or misleading.

### 5.2.13 DRI datasets.

DRI datasets shall support disaster-risk intelligence, including indicators, signals, exposure records, vulnerability records, resilience-capacity records, hazard records, cascade records, hotspot records, public-safe summaries, national contributions, and correction records. DRI datasets may draw from public, controlled, restricted, geospatial, Observatory, national, research, public authority learning, humanitarian, climate, weather, hydrology, infrastructure, and community sources.

DRI datasets shall be governed with heightened public-safe discipline. They shall not be public warnings, official alerts, emergency commands, public authority decisions, insurance scores, investment signals, procurement signals, country rankings, or deployment authorizations. DRI dataset use shall include confidence labels, uncertainty labels, limitations, public-safe communication controls, and correction pathways.

### 5.2.14 Observatory datasets.

Observatory datasets shall support Nexus Observatory functions, including observability, signal detection, sensor records, edge records, geospatial layers, Earth observation layers, digital twin inputs, degraded-mode awareness, hotspot records, multi-hazard records, system condition records, national dense Nexus core inputs, and public-safe Observatory outputs. Observatory datasets may include open, controlled, restricted, national, regional, sensor-derived, Earth observation, field, model-derived, public authority-sensitive, infrastructure-sensitive, cyber-sensitive, or geospatial-sensitive data.

Observatory datasets shall be governed to prevent surveillance overclaim, sensitive location exposure, protected knowledge exposure, community harm, public authority overclaim, and emergency-command misinterpretation. Observatory data shall not create surveillance authority, official maps, public warnings, public authority decisions, or operational command by implication.

### 5.2.15 National Portfolio datasets.

National Portfolio datasets shall support country-level Nexus work, including national context records, systems-risk maps, challenge briefs, evidence needs, Observatory needs, safeguard records, public authority learning records, readiness questions, Competence Cell workplans, Nexus Universe arena routing, National Portfolio Reports, and lawful handoff dependency packages. They may include public, controlled, national, regional, local, sectoral, WFEH-B, DRR, DRF, DRI, infrastructure, labor, learning, innovation, community, public authority learning, and handoff-context data.

National Portfolio datasets shall preserve national ownership before local delivery, data sovereignty, localization, public authority boundaries, community safeguards, Indigenous protocols where applicable, and protected knowledge controls. A National Portfolio dataset shall not create country ranking, public authority approval, public finance allocation, procurement status, national execution authorization, community consent, Indigenous consent, investment signal, insurance signal, or deployment authority.

## 5.3 Data Lifecycle

### 5.3.1 Data signal.

A data signal is an indication that a data object may exist, may be needed, may require review, may require correction, or may support a Nexus purpose. Data signals may arise from public sources, national priorities, regional clusters, Nexus Campaigns, Nexus Academy, Risk Academy, Labs, Foundry, Observatory, DRI, GRIx, Reports, Marketplace, Registry, Studio, Grid, Nexus Universe, public authority learning rooms, capital-reader rooms, insurance-reader rooms, communities, universities, providers, sponsors, national nodes, working groups, competence cells, or lawful handoff recipients.

A data signal shall create an intake possibility, not data rights, access authorization, collection authority, public authority authority, finance signal, procurement signal, consent, deployment authorization, or execution authority. Data signals shall be recorded where material and triaged according to purpose, sensitivity, rights, urgency, public-good relevance, and correction needs.

### 5.3.2 Data intake.

Data intake shall record proposed data identity, source, steward, purpose, scope, expected class, jurisdictional context, collection method, rights status, permissions, sensitivities, data-use needs, AI-use needs, public-safe relevance, Observatory relevance, DRI relevance, GRIx relevance, Studio relevance, Reports relevance, Marketplace relevance, Registry relevance, Grid or TRL relevance, National Portfolio relevance, and handoff relevance. Intake shall also identify whether the data is raw, processed, aggregated, synthetic, metadata-only, benchmark, DRI, Observatory, National Portfolio, or another class.

Data intake shall not approve use. Intake shall route the data for source review, rights review, sensitivity review, labeling, lineage capture, quality assessment, public-safe transformation where needed, repository routing, DICE routing, Registry record creation, Marketplace listing where appropriate, correction, or archive.

### 5.3.3 Source review.

Source review shall assess where the data came from, how it was collected, generated, observed, submitted, transferred, scraped where lawful, modeled, sensed, derived, or acquired, and whether the source is reliable, lawful, ethical, current, complete enough for intended use, traceable, and compatible with public-good purposes. Source review shall consider public sources, official sources, community sources, Indigenous protocol-sensitive sources where applicable, research sources, provider sources, sponsor sources, public authority learning sources, sensor sources, Earth observation sources, cyber sources, infrastructure sources, and AI-generated or synthetic sources.

Source review shall produce a source class and source notes. It shall not transform data into official truth, certification, legal compliance, public authority record, public warning, finance signal, procurement signal, or deployment authorization. Source uncertainty and source limitations shall remain attached to downstream objects.

### 5.3.4 Rights review.

Rights review shall determine whether data may be stored, processed, transformed, analyzed, displayed, published, shared, licensed, used for AI, used in Studio, listed in Marketplace, recorded in Registry, included in Reports, used in Grid or TRL notes, included in National Portfolios, or included in lawful handoff packages. Rights review shall examine ownership, licenses, terms of use, consent, permissions, public-sector data conditions, research ethics, contractual restrictions, privacy law, data protection obligations, Indigenous data governance where applicable, community protocols, protected knowledge restrictions, trade secrets, confidentiality, cross-border transfer restrictions, and downstream use constraints.

Rights clearance for one purpose shall not create clearance for all purposes. Rights review shall be specific to purpose, scope, jurisdiction, access class, data-use label, AI-use label, publication status, and handoff status. Rights review shall not create warranty, certification, procurement status, public authority approval, financeability, or execution authority.

### 5.3.5 Sensitivity review.

Sensitivity review shall classify risks associated with privacy, youth data, health-sensitive data, public authority sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, protected knowledge, cybersecurity, critical infrastructure, geospatial exposure, sensitive species, sacred sites, humanitarian sensitivity, conflict-affected contexts, disaster-affected contexts, finance boundary risks, insurance boundary risks, procurement boundary risks, and public-safe communication risks.

Sensitivity review shall determine access controls, masking, aggregation, delay, redaction, secure-room use, data-room use, clean-room use, compute-to-data requirements, output review, no-download controls, publication restrictions, handoff restrictions, retention rules, deletion or sealing needs, incident triggers, and correction pathways. Sensitivity review shall be revisited when data is linked, transformed, localized, published, routed, used for AI, used in Studio, or handed off.

### 5.3.6 Data-use labeling.

Data-use labels shall specify what uses are permitted, restricted, prohibited, review-required, secure-room-only, data-room-only, public-safe-only, metadata-only, handoff-recipient-only, archive-only, or national-node-only. Labels shall reflect rights, sensitivity, source, purpose, public-safe status, jurisdictional constraints, data sovereignty, community safeguards, Indigenous protocols where applicable, and handoff constraints.

A data-use label shall be binding within DDPGF workflows. It shall not create data ownership, public authority approval, procurement status, financeability, insurance approval, community consent, Indigenous consent, deployment authorization, or execution authority. Use outside the label shall trigger review, correction, restriction, or incident response.

### 5.3.7 AI-use labeling.

AI-use labels shall determine whether data may be used for no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning, training, agentic use prohibition, secure-room AI only, public-safe AI output only, or other approved AI-use classes. AI-use labeling shall consider rights, privacy, protected knowledge, community sensitivity, Indigenous protocol sensitivity where applicable, youth data, health data, cyber data, infrastructure data, geospatial sensitivity, bias, harm, model leakage, re-identification, and downstream misuse risks.

AI-use permission shall not imply that any AI system using the data is safe, certified, fair, legally compliant, deployable, procurement-ready, financeable, insurable, or authorized for high-stakes decisions. AI-use labels shall be updated when rights, risks, data context, model use, or regulatory constraints change.

### 5.3.8 Lineage capture.

Lineage capture shall record the origin, transformations, joins, filters, cleaning steps, code, models, scripts, workflows, assumptions, exclusions, versions, stewards, dates, dependencies, and downstream outputs associated with a data object. Lineage shall connect raw data to processed data, public-safe data, aggregated data, synthetic data, benchmark data, DRI datasets, Observatory datasets, National Portfolio datasets, dashboards, models, reports, Studio workflows, Registry records, Marketplace listings, Grid inputs, TRL notes, and handoff packages.

Lineage shall make data reviewable and correctionable. It shall not certify accuracy, completeness, legal compliance, public authority status, procurement readiness, financeability, insurance approval, deployment authorization, or execution authority. Lineage gaps shall be recorded and may restrict use.

### 5.3.9 Quality assessment.

Quality assessment shall evaluate accuracy, completeness, consistency, timeliness, validity, uniqueness, representativeness, bias, uncertainty, resolution, granularity, missingness, provenance, transformation quality, documentation quality, and fitness within recorded purpose. Quality assessment shall be proportional to intended use, sensitivity, public-safe exposure, AI-use, DRI use, Observatory use, Studio use, National Portfolio use, Reports use, Grid or TRL use, and handoff relevance.

Quality status shall be bounded and purpose-specific. It shall not create general validity, certification, official statistics, rating, public authority decision, finance signal, procurement signal, insurance signal, or deployment authorization. Quality defects shall trigger correction, limitation notices, restricted use, suspension, withdrawal, or archive where needed.

### 5.3.10 Public-safe transformation.

Public-safe transformation shall prepare data for public or controlled-public use by reducing harm, privacy risk, security risk, sensitive-location risk, protected knowledge risk, community harm risk, Indigenous protocol breach risk where applicable, cyber risk, infrastructure risk, public authority overclaim risk, and misinterpretation risk. Transformation methods may include aggregation, masking, generalization, redaction, delay, noise addition where appropriate, de-identification, summarization, separation of metadata from raw data, synthetic replacement, public-safe narrative framing, and output review.

Public-safe transformation shall be recorded with method, scope, limitations, residual risks, and correction pathway. It shall not guarantee zero risk, unrestricted reuse, public authority status, official warning, financeability, procurement status, or deployment authorization. Public-safe status may be withdrawn or corrected.

### 5.3.11 Repository routing.

Repository routing shall determine where a data object or metadata object is stored, referenced, published, restricted, mirrored, sealed, or archived. Possible destinations may include open repositories, controlled repositories, national repositories, institutional repositories, data rooms, secure rooms, clean rooms, compute-to-data environments, DICE environments, Reports repositories, Registry records, Marketplace listings, Studio environments, National Node repositories, or archive repositories.

Repository routing shall reflect rights, sensitivity, sovereignty, data localization, access class, support class, public-safe status, and handoff needs. Repository deposit shall not create open data status, data rights, unrestricted reuse, public authority status, procurement status, financeability, insurance approval, deployment authorization, or execution authority.

### 5.3.12 DICE routing.

DICE routing shall determine how data objects enter the Data, Innovation, Commons, and Exchange layer of Nexus for governed public-good use. DICE routing may connect data to software commons, innovation commons, knowledge commons, secure rooms, data rooms, clean rooms, compute-to-data workflows, GRIx, DRI, Observatory, Studio, Reports, Marketplace, Registry, Foundry, Academy, National Portfolios, Nexus Universe, Grid, TRL, and lawful handoff context.

DICE routing shall preserve access class, rights, sensitivity, data-use labels, AI-use labels, lineage, quality, support class, correction pathway, and archive rule. DICE routing shall not convert controlled data into open data, metadata into data rights, public-safe summaries into raw data releases, or handoff context into execution authority.

### 5.3.13 Registry record.

A Registry record shall preserve the status truth of a data object. It shall identify object identity, source pathway, steward, version, jurisdictional context, data class, source class, rights status, sensitivity class, data-use label, AI-use label, access class, lineage status, quality status, public-safe status, repository location or metadata-only reference where appropriate, support class, Marketplace status, Reports status, Studio status, Grid or TRL linkage, handoff linkage, correction history, withdrawal history, recall history, archive status, and boundary notices.

Registry status shall not certify data quality, legal compliance, privacy compliance, official status, public authority approval, procurement readiness, financeability, insurance approval, deployment authorization, or execution authority. Registry records shall be updated when data status changes.

### 5.3.14 Marketplace listing.

Marketplace listing may make a data object, metadata object, public-safe dataset, data dictionary, schema, codebook, data pipeline, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, or data-related tool discoverable. Listing shall require metadata review, rights review, public-safe review where visible, access class, license or use-condition class, support class, Registry status, correction pathway, and boundary notices.

Marketplace listing shall not create procurement recommendation, endorsement, data rights, unrestricted reuse, official status, public authority approval, financeability, insurance approval, provider validation, deployment authorization, or execution authority. Restricted datasets may be listed only through metadata-only or controlled-access records where appropriate.

### 5.3.15 Correction.

Data correction may address factual errors, source errors, lineage errors, transformation errors, quality defects, rights defects, sensitivity misclassification, data-use label errors, AI-use label errors, public-safe transformation defects, metadata errors, codebook errors, schema errors, dashboard errors, report errors, model-input errors, Registry errors, Marketplace errors, Studio workflow errors, Grid or TRL errors, National Portfolio errors, DRI errors, Observatory errors, or handoff errors.

Correction actions may include amendment, revised dataset, revised metadata, label change, access restriction, public-safe notice, dashboard update, report correction, model retraining restriction, Registry update, Marketplace delisting, Studio shutdown, Grid or TRL update, handoff recall, withdrawal, sealing, archive, or non-continuation. Correction shall be propagated to affected downstream objects where feasible and necessary.

### 5.3.16 Archive.

Archive shall preserve data objects, metadata records, data dictionaries, codebooks, schemas, pipelines, lineage, quality assessments, rights reviews, sensitivity reviews, data-use labels, AI-use labels, public-safe transformations, repository records, DICE routing records, Registry records, Marketplace records, Reports references, Studio workflows, Grid inputs, TRL notes, National Portfolio records, DRI records, Observatory records, handoff records, correction records, withdrawal records, recall records, and non-continuation notes. Archive shall include access class, archive-not-current notice, retention rule, deletion or sealing rule where applicable, successor link, correction history, and public-safe status.

Archived data shall not be treated as current authority, open data, public authority record, official statistic, current risk signal, procurement input, finance input, insurance score, deployment input, or execution authority unless separately and lawfully reactivated through review.

## 5.4 Data Classes

### 5.4.1 Open data.

Open data means data that has been reviewed and approved for open access and reuse under a recorded license or use condition. Open data shall still carry metadata, source notes, rights notes, quality notes, data-use labels, AI-use labels where applicable, citation expectations, correction pathway, and archive rule. Open data may support Reports, learning, dashboards, Foundry builds, public-safe research, Marketplace listings, Registry records, Studio exercises, DRI summaries, Observatory public outputs, National Portfolios, and lawful handoff context.

Open data shall not be presumed complete, authoritative, error-free, public authority-approved, AI-training-permitted, financeable, insurable, procurement-ready, deployable, or fit for all purposes. Open data remains correctionable.

### 5.4.2 Public-safe data.

Public-safe data is data prepared for public or controlled-public use within defined scope. It may derive from open, controlled, restricted, aggregated, synthetic, or transformed sources. Public-safe data shall preserve transformation notes, limitations, public-safe labels, sensitivity notes, update cadence, and correction pathway.

Public-safe data shall not release underlying raw data, waive underlying rights, create unrestricted data rights, certify accuracy, create official status, or authorize high-stakes use.

### 5.4.3 Controlled public data.

Controlled public data means data that may be viewed or used by defined public or semi-public audiences subject to conditions, restrictions, notices, or access controls. It may include data suitable for controlled dashboards, controlled Reports, public authority learning, registered participants, secure portals, or Nexus Universe controlled rooms. Controlled public data shall require user permissions, use conditions, public-safe notes, sensitivity limits, logging where appropriate, and correction pathway.

Controlled public availability shall not create open data status, unrestricted reuse, data rights, public authority approval, procurement eligibility, financeability, deployment authorization, or execution authority.

### 5.4.4 Restricted data.

Restricted data means data that may only be accessed by authorized users for defined purposes under controlled conditions. Restricted data may require secure rooms, data rooms, clean rooms, compute-to-data environments, no-download controls, output review, confidentiality terms, data-use restrictions, AI-use restrictions, retention limits, and incident response procedures.

Restricted data shall not be published, listed beyond metadata where appropriate, exported, reused, modeled, or handed off except under recorded review and authorization. Restricted data access shall not create data rights, ownership, consent, public authority approval, or handoff permission.

### 5.4.5 Public authority-sensitive data.

Public authority-sensitive data means data involving public authority processes, regulatory matters, public finance, emergency management, public health, infrastructure, public safety, permits, licenses, inspections, enforcement, official records, policy development, internal public-sector deliberation, or non-public government information. Such data shall be handled to preserve public authority independence, confidentiality, legal constraints, public-safe communication, and no-substitution discipline.

Public authority-sensitive data shall not become a public authority record of Nexus by implication. Public authority participation, data sharing, or learning-room use shall not create public authority approval, official action, public warning, emergency command, public finance allocation, procurement status, or execution authority.

### 5.4.6 Community-sensitive data.

Community-sensitive data means data that concerns communities, local conditions, lived risk, vulnerabilities, cultural practices, social dynamics, local resources, harms, grievances, displacement, conflict, disaster impact, health, safety, livelihoods, identity, or place-based knowledge, where disclosure, misuse, misinterpretation, extraction, or overexposure may cause harm. Community-sensitive data shall require non-extractive handling, purpose limitation, access control, public-safe transformation, community-facing correction where appropriate, and consent boundary discipline.

Community participation or community-sensitive data contribution shall not create community consent, project approval, public authority approval, deployment permission, or handoff permission. Community-sensitive data shall not be used to rank, profile, expose, exploit, or bypass communities.

### 5.4.7 Indigenous protocol-sensitive data where applicable.

Indigenous protocol-sensitive data means data, knowledge, observations, locations, cultural information, ecological knowledge, governance information, community records, sacred site information, protected knowledge, language materials, or other information subject to Indigenous laws, protocols, permissions, restrictions, or stewardship expectations. Such data shall be governed with heightened respect for Indigenous data sovereignty, protected knowledge, access restrictions, use permissions, cultural context, localization, benefit-sharing where applicable, and correction or withdrawal rights where appropriate.

DDPGF shall not treat Indigenous protocol-sensitive data as open, public-safe, AI-usable, publishable, transferable, or handoff-ready by default. Participation, display, learning use, report citation, metadata record, or controlled-room access shall not constitute Indigenous consent, legal permission, public authority approval, or implementation authorization.

### 5.4.8 Protected knowledge.

Protected knowledge means knowledge that must be restricted, masked, withheld, generalized, sealed, or governed through special access controls because disclosure or misuse could cause cultural, community, ecological, security, privacy, legal, economic, humanitarian, public authority, or safety harm. Protected knowledge may include Indigenous knowledge, community-protected knowledge, sensitive biodiversity information, sacred sites, critical infrastructure details, cyber-sensitive information, vulnerable population data, sensitive health information, security-sensitive methods, or confidential institutional information.

Protected knowledge shall be subject to strict purpose limitation, access controls, output review, public-safe transformation, and correction. Protected knowledge shall not be converted into public data, learning data, AI training data, report content, dashboard content, Marketplace content, or handoff content without recorded authorization and safeguards.

### 5.4.9 Youth data.

Youth data means data relating to children, minors, students, young participants, youth learners, youth contributors, or youth communities. Youth data shall require heightened privacy, consent, guardian or institutional permission where applicable, minimization, access controls, safeguarding, display restrictions, AI-use restrictions, retention limits, deletion or sealing options, and incident response.

Youth data shall not be used for profiling, ranking, social scoring, employment decisions, public display, high-stakes automated decisions, AI training, or handoff contexts unless separately and lawfully reviewed. Youth participation shall not create consent to unrestricted data use.

### 5.4.10 Health-sensitive data.

Health-sensitive data means data concerning health status, public health, disease, disability, mental health, environmental health, health services, health risk, health facilities, health access, climate-health risk, One Health, biosecurity-sensitive information, or other health-relevant information. Health-sensitive data shall be governed with privacy, ethics, public-safe communication, public authority boundary, and no-medical-decision discipline.

Health-sensitive data in DDPGF shall not create medical advice, diagnosis, public health decision, public warning, regulatory action, emergency command, or deployment authorization. Health-related public-safe outputs shall avoid overclaim and preserve correction pathways.

### 5.4.11 Cyber-sensitive data.

Cyber-sensitive data means data that could expose vulnerabilities, credentials, access patterns, security configurations, infrastructure weaknesses, exploit-adjacent information, attack surfaces, incident details, logs, threat intelligence, critical infrastructure cyber posture, OT/IoT/IIoT risks, or other information that could increase cyber risk if mishandled. Cyber-sensitive data shall require secure handling, access controls, need-to-know review, public-safe disclosure, vulnerability disclosure discipline, and incident response.

Cyber-sensitive data shall not be published in operationally harmful detail, used as attack guidance, treated as public warning authority, or handed off without controlled review. Cyber outputs shall be public-safe and correctionable.

### 5.4.12 Infrastructure-sensitive data.

Infrastructure-sensitive data means data concerning critical infrastructure, facilities, assets, networks, utilities, transport, water, energy, communications, health infrastructure, supply chains, emergency systems, physical security, vulnerabilities, dependencies, or operational details. Such data shall require sensitivity review, access control, aggregation or masking where appropriate, public authority boundary review, cyber review where applicable, and public-safe output controls.

Infrastructure-sensitive data shall not create operational command, emergency instruction, public authority approval, procurement status, deployment authorization, or execution authority. Public-safe infrastructure outputs shall avoid exposing vulnerabilities or sensitive locations.

### 5.4.13 Geospatial-sensitive data.

Geospatial-sensitive data means location data, maps, coordinates, remote sensing data, Earth observation layers, sensor locations, asset locations, community locations, sacred sites, protected species locations, infrastructure locations, disaster impact locations, or other spatial data that could cause harm if disclosed or misused. Geospatial-sensitive data shall require masking, generalization, delay, aggregation, restricted access, protected location controls, community and Indigenous protocol review where applicable, and public-safe map publication rules.

Geospatial data shall not be treated as official map, public authority record, surveillance authority, warning authority, procurement input, or deployment authorization by implication.

### 5.4.14 Handoff-recipient-only data.

Handoff-recipient-only data means data that may be included in a lawful handoff package only for a named or class-defined recipient under defined conditions. It may include evidence context, data context, method context, Studio context, Grid or TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, and correction pathways.

Handoff-recipient-only data shall not be open, Marketplace-public, unrestricted, or reusable beyond handoff terms. Receipt of such data shall not authorize execution, deployment, procurement, finance, insurance, public authority action, or community consent.

### 5.4.15 Archive-only data.

Archive-only data means data retained for institutional memory, auditability, correction history, legal retention, research traceability, historical reference, or non-current status, but not available for active use except under specific review. Archive-only data may include withdrawn data, superseded data, recalled data, deprecated data, sealed data, expired data, corrected data, non-continuing data, or historically relevant data.

Archive-only status shall indicate non-current use. Archive-only data shall not be used for current decisions, dashboards, AI training, public-safe reporting, finance, insurance, procurement, public authority action, deployment, or handoff unless separately reviewed and reclassified.

## 5.5 Data Governance Controls

### 5.5.1 Data minimization.

DDPGF shall collect, store, process, display, publish, or hand off only the data necessary for the recorded purpose and shall avoid unnecessary collection, duplication, linkage, retention, exposure, or extraction. Data minimization shall apply to raw data, processed data, metadata, public-safe data, controlled data, learning data, AI-use data, Studio data, DRI data, Observatory data, National Portfolio data, and handoff data.

Where public-good goals can be achieved through metadata, aggregation, synthetic data, public-safe summaries, secure-room output, or compute-to-data workflows, DDPGF shall prefer those lower-exposure methods over raw data movement. Data minimization shall support trust, privacy, security, public-safe reporting, protected knowledge discipline, and national sovereignty.

### 5.5.2 Purpose limitation.

Every data object shall have a recorded purpose and shall be used only within that purpose unless reviewed and reclassified. Purpose limitation shall apply to research, learning, dashboards, AI, Studio workflows, DRI, Observatory, Reports, Marketplace, Registry, Grid, TRL, National Portfolios, Nexus Universe, and lawful handoff.

A data object collected or accessed for one purpose shall not automatically be reused for another purpose. Reuse shall require review of rights, sensitivity, data-use labels, AI-use labels, public-safe status, safeguards, and downstream risks. Purpose expansion without review shall be treated as a governance incident.

### 5.5.3 Consent and permission.

Consent and permission controls shall govern data involving individuals, communities, institutions, public authorities, Indigenous knowledge holders where applicable, providers, sponsors, research participants, learners, workers, youth, or other rights-bearing actors. Consent and permission shall be specific, informed, recorded, revocable where applicable, and aligned with law, ethics, safeguards, and context.

Consent to participate in Nexus, contribute to a campaign, attend Nexus Universe, join a working group, use Academy resources, contribute to Foundry, or provide information shall not equal consent to unrestricted data use, publication, AI training, public display, handoff, procurement use, finance use, insurance use, or deployment. Consent boundaries shall be recorded and correctionable.

### 5.5.4 Access control.

Access control shall restrict data access according to role, purpose, data class, rights, sensitivity, jurisdictional context, support class, public-safe status, and workflow need. Controls may include identity verification, role-based access, attribute-based access, least privilege, multi-factor authentication where appropriate, secure rooms, data rooms, clean rooms, compute-to-data environments, no-download rules, logging, access review, access expiry, and revocation.

Access shall be granted only for recorded purposes. Access to data shall not create ownership, reuse rights, publication rights, handoff permission, public authority approval, financeability, procurement status, deployment authorization, or execution authority.

### 5.5.5 Cross-border controls.

Cross-border controls shall govern data transfer, access, storage, processing, publication, remote viewing, cloud hosting, compute-to-data use, repository deposit, Studio use, AI use, and handoff across jurisdictions. Controls shall consider data protection law, data sovereignty, localization requirements, public authority constraints, community protocols, Indigenous data governance where applicable, contractual restrictions, export controls, cyber risk, and conflict-of-law issues.

Where cross-border movement is inappropriate, DDPGF shall prefer metadata-only records, national repositories, sovereign compute, secure rooms, data rooms, clean rooms, compute-to-data workflows, public-safe summaries, or localized outputs. Cross-border access shall not imply unrestricted transfer rights or legal equivalence.

### 5.5.6 Data sovereignty.

Data sovereignty shall mean that data associated with a jurisdiction, people, public authority, community, Indigenous institution where applicable, national node, or lawful steward shall be governed with respect for applicable law, rights, protocols, localization needs, public authority boundaries, and national ownership before local delivery. DDPGF shall not use global, regional, sponsor, provider, or platform convenience to bypass national, community, Indigenous, public authority, or legal data governance requirements.

Data sovereignty shall apply to hosting, access, processing, metadata, AI use, Studio use, dashboards, Reports, Marketplace listings, Registry records, National Portfolios, Nexus Universe outputs, and handoff packages. Sovereignty controls shall not be used as a pretext for secrecy, exclusion, capture, or avoidance of correction, but shall preserve lawful and legitimate stewardship.

### 5.5.7 Data localization.

Data localization shall govern when data must be stored, processed, accessed, or retained within a jurisdiction, national node, sovereign environment, approved repository, public authority environment, community-approved environment, Indigenous protocol-sensitive environment where applicable, or controlled room. Localization may be required by law, contract, public authority policy, community protocol, Indigenous protocol, sensitivity class, cyber risk, infrastructure sensitivity, or handoff conditions.

Localization shall be recorded and enforced through repository routing, access control, compute-to-data, secure rooms, national mirrors, and archive rules. Localization shall not create public authority approval, deployment authorization, procurement status, financeability, or execution authority.

### 5.5.8 Retention.

Retention controls shall specify how long data, metadata, lineage, logs, access records, review records, consent records, correction records, Registry records, Marketplace records, Reports references, Studio records, Grid inputs, TRL notes, and handoff records shall be kept. Retention shall consider legal obligations, public-good traceability, correctionability, audit needs, privacy, data minimization, youth protections, protected knowledge, public authority sensitivity, and archive value.

Retention shall not justify indefinite exposure or unnecessary use. Data shall be deleted, sealed, restricted, archived, or made non-continuing when continued active retention is no longer justified.

### 5.5.9 Deletion.

Deletion controls shall govern removal of data where required by law, rights, consent withdrawal, retention expiry, error, duplication, sensitivity risk, protected knowledge concerns, youth safeguards, privacy, security, or incident response. Deletion shall be recorded where appropriate, subject to legal holds, audit needs, correction records, and archive exceptions where lawful.

Deletion shall not be used to hide misuse, erase accountability, suppress correction, avoid incident review, or bypass public-good traceability where retention is lawful and required. Where full deletion is not possible because of archives, backups, reports, or downstream objects, sealing, restriction, or correction notices shall be used.

### 5.5.10 Sealing.

Sealing shall restrict access to data that must be preserved but not actively used or disclosed. Sealed data may include protected knowledge, youth data, health-sensitive data, public authority-sensitive data, confidential data, incident data, withdrawn data, disputed data, legally sensitive data, or data subject to review. Sealed status shall include access restrictions, reason for sealing, review authority, retention rule, correction pathway, and conditions for unsealing.

Sealed data shall not be used for public reporting, AI training, dashboards, Marketplace listing beyond metadata where appropriate, Studio workflows, Grid inputs, TRL notes, handoff, or execution unless unsealed or otherwise authorized through review.

### 5.5.11 Archive.

Archive controls shall preserve data and data governance records for institutional memory, traceability, correction, legal retention, research reproducibility, and public-good accountability. Archive shall include access class, archive-not-current notice, rights status, sensitivity class, public-safe status, correction history, successor links, retention rule, deletion or sealing conditions, and permitted historical uses.

Archived data shall be protected against misuse and overclaim. Archive shall not create current authority, public authority record status, open data status, public warning, ranking, finance signal, procurement signal, deployment authorization, or execution authority.

### 5.5.12 Incident response.

Data incident response shall address unauthorized access, unauthorized disclosure, improper reuse, misclassification, rights violation, privacy incident, youth data incident, health data incident, cyber-sensitive data incident, infrastructure-sensitive data incident, protected knowledge incident, Indigenous protocol-sensitive data incident where applicable, community-sensitive data incident, public authority boundary incident, AI-use incident, public-safe publication incident, Marketplace listing incident, Registry status incident, Studio output incident, handoff overclaim, or execution overclaim.

Incident response may include containment, access suspension, data freeze, claims freeze, technical freeze, notification where required, public-safe notice where appropriate, Registry update, Marketplace delisting, Reports correction, Studio shutdown, Grid or TRL update, handoff recall, deletion, sealing, archive, correction, and non-continuation. Incident response shall preserve accountability and trust without creating unnecessary public harm.

## 5.6 Data Boundary Rules

### 5.6.1 Data availability is not data right.

The existence, visibility, listing, citation, repository deposit, dashboard display, metadata record, Registry record, Marketplace listing, Reports reference, Studio availability, Grid input, TRL note, Nexus Universe presentation, or handoff reference to a data object shall not create a right to access, download, reuse, copy, scrape, link, publish, train AI on, transfer, commercialize, rely upon, or operationalize that data. Data rights shall arise only from applicable law, license, consent, permission, contract, public authority authorization, community protocol, Indigenous protocol where applicable, or other recorded lawful basis.

### 5.6.2 Metadata is not open data.

Metadata describing a data object shall not make the underlying data open, accessible, reusable, downloadable, AI-usable, public-safe, handoff-ready, or lawful for downstream use. Metadata may support discovery, review, routing, public-safe awareness, and Registry status truth, but access to underlying data shall remain governed by data class, rights, permissions, sensitivity, data-use labels, AI-use labels, access controls, and correction rules.

### 5.6.3 Dataset citation is not permission to reuse.

Citation of a dataset in a report, dashboard, notebook, public-safe summary, Registry record, Marketplace listing, Studio workflow, Grid input, TRL note, National Portfolio object, Nexus Universe output, or handoff package shall not constitute permission to reuse the dataset. Citation supports traceability and attribution; it does not waive rights, remove restrictions, grant access, approve AI use, authorize publication, or create public authority, finance, insurance, procurement, deployment, or execution authority.

### 5.6.4 Public-safe data is not raw data release.

Public-safe data shall not be treated as release of the underlying raw data, controlled data, restricted data, protected knowledge, sensitive geospatial data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, cyber-sensitive data, infrastructure-sensitive data, youth data, or health-sensitive data. Public-safe outputs are bounded transformations and may be corrected, withdrawn, restricted, or archived where risks or errors arise.

### 5.6.5 Data-room access is not handoff permission.

Access to a data room, secure room, clean room, compute-to-data environment, public authority learning room, readiness room, capital-reader room, insurance-reader room, donor-reader room, Studio room, or protected knowledge room shall not create handoff permission, data export rights, publication rights, procurement status, financeability, insurance approval, public authority approval, deployment authorization, or execution authority. Room access shall be purpose-limited, logged where appropriate, output-reviewed, and governed by access class and data-use labels.

### 5.6.6 Data object is not public authority record unless separately recorded.

No data object under DDPGF shall be treated as an official public authority record, public authority decision, public warning, emergency alert, permit record, license record, regulatory record, public finance allocation, procurement record, official statistic, official map, or emergency command unless a competent public authority separately and lawfully records that status outside DDPGF default posture. Public authority participation, data sharing, learning-room use, dashboard review, Reports citation, National Portfolio inclusion, Nexus Universe attendance, or handoff receipt shall not convert a DDPGF data object into public authority action.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/v.-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.