# X. DATA

This section defines data in Nexus as governed public-good infrastructure.

It explains how data is classified, accessed, transformed, reviewed, published, restricted, corrected, archived, and handed off. It also sets the core boundary rule: data may support learning, evidence, intelligence, and coordination, but it does not become public authority action, procurement, finance, insurance, consent, deployment authorization, or execution by implication.

## 10.1 Data Commons Doctrine

### 10.1.1 Data, Innovation, Commons, and Evidence Governance Layer

Decentralized Innovation Commons (DICE) is the data, innovation, commons, and evidence governance layer of Nexus Ecosystem. It governs how data, metadata, datasets, data products, data rooms, clean rooms, secure rooms, compute-to-data workflows, public-safe summaries, AI-use inputs, Observatory signals, DRI indicators, GRIx mappings, Studio workflows, Reports, Academy objects, Campaign objects, Grid and TRL records, National Portfolio objects, Nexus Universe outputs, Marketplace listings, Registry records, and handoff packages are created, classified, accessed, used, reviewed, transformed, published, restricted, corrected, archived, or handed off.

DICE exists because data is not neutral raw material. Data may carry rights, omissions, power, bias, uncertainty, privacy risk, cybersecurity risk, public authority sensitivity, geospatial sensitivity, protected knowledge, community context, Indigenous protocol obligations where applicable, commercial restrictions, sovereign data controls, cross-border transfer limits, AI-use restrictions, and downstream reliance risk. Nexus therefore treats data as governed infrastructure, not as an extractive input.

DICE supports innovation by making data usable under disciplined conditions. It supports commons by making public-good data and metadata discoverable where safe. It supports evidence by requiring provenance, lineage, source context, quality, uncertainty, review, public-safe transformation, and correction. It supports lawful handoff by ensuring data conditions travel with the object and are not stripped away when an output becomes useful to downstream actors.

DICE may operate across open, controlled, restricted, secure-room-only, data-room-only, clean-room-only, compute-to-data-only, National Node-only, protected-knowledge-controlled, public-authority-learning-only, handoff-recipient-only, archive-only, sealed, or non-continuing data states. Its purpose is not to make all data open. Its purpose is to make data governance precise enough that openness, control, restriction, learning, intelligence, publication, and handoff can each occur without collapsing into one another.

DICE does not create data ownership, unrestricted access, AI-training rights, publication rights, public authority approval, procurement status, financeability, insurability, certification, consent, deployment authorization, or execution authority by default. It creates the governance layer that allows data to move responsibly where movement is lawful, safe, recorded, and bounded.

### 10.1.2 Data Commons Defined

A Data Commons is a governed public-good environment in which data objects, metadata objects, schemas, ontologies, data dictionaries, data products, data-quality records, lineage records, access rules, public-safe summaries, DICE records, GRIx mappings, DRI indicators, Observatory inputs, Studio-ready datasets, Reports-ready datasets, Academy datasets, National Portfolio datasets, Nexus Universe datasets, and handoff-relevant data packages may be organized for shared learning, reuse, review, and public-good production.

A Data Commons is not an unrestricted data lake. It is not a mass-upload repository, surveillance layer, commercial data marketplace, unbounded AI-training corpus, procurement platform, public authority database, consent system, or execution system. Its public-good value depends on governance: identity, metadata, rights, access class, sensitivity class, data-use label, AI-use label, jurisdictional context, review status, public-safe status, support class, correction pathway, and archive rule.

A Data Commons may include:

1. open data objects, where lawful and public-safe release is permitted;
2. controlled data objects, where access is limited to defined participants, reviewers, learners, rooms, institutions, or pathways;
3. restricted data objects, where privacy, cyber, public authority, protected knowledge, geospatial, legal, commercial, sovereign, or safeguard concerns require stronger controls;
4. metadata-first objects, where metadata can be made discoverable even where source data remains restricted;
5. public-safe data products, where raw or sensitive data has been transformed into safe summaries, aggregates, indicators, or learning objects;
6. compute-to-data objects, where permitted computation occurs without raw data export;
7. handoff-context data objects, where data conditions are transferred to competent recipients without transferring unrestricted rights.

A Data Commons should be commons-based in governance and public-good purpose, not commons-washed in language. Data enters the commons only within lawful, recorded, rights-respecting, consent-aware where applicable, privacy-preserving, secure, public-safe, and correctionable conditions. The commons is a disciplined sharing architecture, not a default claim that all data belongs to everyone.

### 10.1.3 Public-Safe Data Defined

Public-safe data is data or a data-derived object that has been reviewed, transformed, classified, and released in a manner suitable for public or broader controlled communication without creating unacceptable risk of harm, privacy exposure, protected knowledge exposure, public authority confusion, cybersecurity risk, geospatial risk, community harm, Indigenous protocol breach where applicable, public panic, false reassurance, finance or insurance overclaim, procurement implication, consent overclaim, or execution overclaim.

Public-safe data may include aggregated indicators, de-identified summaries, generalized geospatial layers, masked records, public-safe dashboards, public-safe DRI summaries, public-safe Observatory outputs, public-safe National Portfolio summaries, public-safe Reports tables, public-safe Academy datasets, public-safe Campaign metrics, public-safe Nexus Universe outputs, or public-safe Marketplace descriptions.

Public-safe data should identify:

1. source data class and source restrictions;
2. transformation method;
3. aggregation, masking, redaction, generalization, or de-identification steps;
4. public-safe reviewer or review pathway;
5. residual risk;
6. uncertainty and limitation language;
7. permitted audience;
8. prohibited use;
9. update and correction pathway;
10. archive treatment.

Public-safe data is not necessarily open data. Some public-safe outputs may be suitable for public communication; others may be suitable only for controlled participants, public authority learning rooms, media-safe rooms, Academy pathways, National Nodes, or handoff recipients. Public-safe status is also not permanent. New information, linkage risk, geospatial sensitivity, AI re-identification risk, legal change, community concern, Indigenous protocol concern where applicable, or public-safe reporting issue may require correction, restriction, withdrawal, recall, or archive.

Public-safe data informs responsibly. It does not become public warning, public authority action, certification, procurement status, financeability, insurability, consent, deployment authorization, or execution authority.

### 10.1.4 Controlled Data Defined

Controlled data is data that may be used within Nexus only under defined access, role, purpose, security, privacy, public-safe, data-use, AI-use, jurisdictional, safeguard, and correction conditions. Controlled data is not fully open, but it is not necessarily inaccessible. It exists between unrestricted public release and strict non-use.

Controlled data may include:

1. participant-limited datasets;
2. National Node datasets;
3. public authority learning datasets;
4. data-room materials;
5. secure-room materials;
6. clean-room materials;
7. compute-to-data datasets;
8. geospatial-sensitive datasets;
9. infrastructure-sensitive datasets;
10. cyber-sensitive datasets;
11. community-sensitive datasets;
12. health-sensitive or youth-sensitive datasets;
13. Indigenous protocol-sensitive datasets where applicable;
14. protected knowledge datasets;
15. provider-contributed or sponsor-supported restricted datasets;
16. handoff-recipient-only datasets.

A Controlled Data Record should identify the data steward, access class, approved users, approved purpose, prohibited purpose, retention rule, output review rule, download rule, export rule, cross-border transfer rule, AI-use rule, publication rule, public-safe transformation rule, correction pathway, incident pathway, and archive rule.

Controlled data should not be copied into open repositories, used for AI training, displayed in public dashboards, exported across borders, included in Reports, listed in Marketplace, used in Campaigns, included in Nexus Universe materials, or handed off unless the applicable controls permit that specific use. Access to controlled data is not unrestricted permission. Use is always purpose-bound and record-bound.

Controlled data allows Nexus to learn from sensitive information without pretending sensitivity has disappeared.

### 10.1.5 Metadata as Public-Good Bridge

Metadata is the public-good bridge between data that may be openly known, data that may be controlled, and data that must remain restricted. It allows the ecosystem to understand that data exists, what it is about, who stewards it, what rights and restrictions apply, what quality and uncertainty conditions exist, what review has occurred, what public-safe outputs may be available, and how the data may be requested, studied, transformed, or handed off without exposing the underlying data improperly.

Metadata may describe:

1. dataset identity and title;
2. steward and source pathway;
3. subject matter and scope;
4. geography and time period;
5. data class and sensitivity class;
6. rights and license conditions;
7. access and release class;
8. data-use label;
9. AI-use label;
10. quality, lineage, provenance, uncertainty, and limitations;
11. update cadence and support status;
12. public-safe summary availability;
13. DICE, GRIx, DRI, Observatory, Studio, Reports, Academy, Marketplace, Registry, Grid, National Portfolio, Nexus Universe, or handoff relationships;
14. correction and archive pathway.

Metadata can be more open than source data where safe, but metadata can also be sensitive. The fact that a dataset exists, its location, its steward, its subject, its geography, or its relationship to a public authority, community, Indigenous institution where applicable, critical infrastructure, health system, protected site, or cyber system may itself require control.

Metadata should never be treated as decorative. It is the bridge that lets Nexus build commons without forcing unsafe disclosure. It makes data discoverable, governable, and correctable while preserving lawful boundaries.

### 10.1.6 Data as Evidence-Bearing Object

Data as an evidence-bearing object means that data within Nexus must carry provenance, lineage, method context, quality context, uncertainty, limitations, sensitivity, review status, and correction pathway. Data is not evidence merely because it exists. It becomes evidence-bearing when its source, collection method, transformation history, scope, gaps, assumptions, rights, restrictions, and intended use are recorded.

A data object used as evidence should identify:

1. source and provenance;
2. collection or generation method;
3. lineage and transformation history;
4. data quality, missingness, bias, uncertainty, and confidence;
5. spatial, temporal, sectoral, and population scope;
6. rights, permissions, license, and consent conditions where applicable;
7. privacy, cyber, geospatial, protected knowledge, public authority, community, and Indigenous protocol sensitivity where applicable;
8. data-use and AI-use labels;
9. review status;
10. public-safe transformation status;
11. correction and archive rules.

Evidence-bearing data may support Reports, DRI indicators, GRIx mappings, Observatory outputs, Studio workflows, dashboards, digital twins, simulations, Academy materials, Campaign summaries, Grid and TRL records, National Portfolio objects, Nexus Universe outputs, Marketplace listings, Registry records, and handoff packages. Its evidentiary meaning remains bounded by purpose and scope.

Data evidence is not universal truth. A dataset may be sufficient for exploratory learning but insufficient for public-safe reporting. It may be sufficient for Studio demonstration but insufficient for handoff. It may be sufficient for handoff context but insufficient for deployment. Evidence-bearing status supports interpretation; it does not create certification, public authority action, procurement, finance, insurance, consent, deployment, or execution.

### 10.1.7 Data as Learning Object

Data as a learning object means that datasets, metadata, synthetic datasets, public-safe datasets, example datasets, data dictionaries, notebooks, dashboards, quality records, DICE records, GRIx mappings, DRI indicators, Observatory outputs, and Studio workflows may be used to build capability through Nexus Academy, Risk Academy, WILPs, Foundry contributor learning, Studio learning, public authority learning, data and AI literacy, public-safe reporting learning, finance-readiness literacy, insurance-readiness literacy, and handoff literacy.

A data learning object should identify:

1. learning purpose;
2. learner class;
3. data class and sensitivity;
4. whether data is real, synthetic, anonymized, aggregated, masked, public-safe, controlled, restricted, or compute-to-data-only;
5. permitted exercises;
6. prohibited uses;
7. AI-use restrictions;
8. public-safe output rules;
9. accessibility and localization status;
10. correction and archive pathway.

Learning use must not be treated as unrestricted data use. A learner may access a dataset for a controlled exercise without acquiring the right to publish it, train AI on it, download it, transfer it, combine it with other data, use it commercially, submit it to a public authority, include it in procurement materials, or hand it off. Where sensitive data is not needed for learning, synthetic or public-safe substitute data should be preferred.

Data learning objects build capability. They do not license professionals, certify competence externally, grant data rights, authorize AI training, create public authority action, create financeability, create insurance approval, grant consent, deploy systems, or execute projects.

### 10.1.8 Data as Intelligence Object

Data as an intelligence object means that data may be organized, analyzed, transformed, and interpreted to support disaster-risk intelligence, systems-risk awareness, Observatory signals, DRI indicators, GRIx mappings, degraded-mode awareness, WFEH-B analysis, digital twin needs, Studio scenarios, public authority learning, National Portfolio preparation, Nexus Universe outputs, Reports, Campaigns, Grid and TRL context, finance-readiness questions, insurance-readiness questions, and lawful handoff dependencies.

An intelligence data object should identify:

1. intelligence question;
2. source data and metadata;
3. method and transformation logic;
4. uncertainty, confidence, limitations, and gaps;
5. public-safe status;
6. sensitivity and access class;
7. interpretation limits;
8. public authority boundary language;
9. finance and insurance boundary language where relevant;
10. correction, update, and archive pathway.

Data intelligence must distinguish signal from decision. A risk signal is not a public warning. An indicator is not an official classification. A hotspot is not a public authority designation. A dashboard is not emergency command. A finance-relevant indicator is not investment advice. An insurance-relevant signal is not underwriting. A National Portfolio intelligence object is not government approval. A handoff-relevant data object is not execution authority.

Data as intelligence is powerful because it supports better questions and better preparedness. It remains legitimate only when interpretation limits, public-safe rules, and no-conversion boundaries travel with the object.

### 10.1.9 Data Without Unrestricted Rights by Default

Nexus operates under the doctrine of data without unrestricted rights by default. No data object is presumed to be freely accessible, reusable, publishable, transferable, downloadable, commercializable, AI-trainable, handoff-transferable, or deployable merely because it appears within Nexus, supports a public-good purpose, is referenced in metadata, is used in a dashboard, is summarized in a Report, is stored in a repository, is discussed in a room, is included in Nexus Universe, is listed in Marketplace, or is recorded in Registry.

Data rights must be specific, recorded, and attached to the data object. A data object should distinguish:

1. right to know metadata;
2. right to view;
3. right to query;
4. right to compute-to-data;
5. right to download;
6. right to transform;
7. right to publish;
8. right to combine;
9. right to train AI;
10. right to share with participants;
11. right to transfer across borders;
12. right to hand off to a recipient;
13. right to commercialize or use in enterprise context;
14. right to archive;
15. duty to delete, seal, restrict, or recall.

Public-good purpose does not override privacy, data protection, intellectual property, contract, consent, Indigenous protocol where applicable, protected knowledge, public authority sensitivity, cyber sensitivity, health sensitivity, youth protection, sovereign data rules, cross-border transfer limits, or other legal and ethical controls.

The default rule is controlled meaning: data can be used only within the rights, access, purpose, and pathway recorded for it. Anything beyond that requires separate permission or authority.

### 10.1.10 Data Without AI-Use Permission by Default

Nexus operates under the doctrine of data without AI-use permission by default. Data access does not imply permission to use the data for AI training, fine-tuning, embedding, retrieval augmentation, automated classification, generative output, agentic workflow, model evaluation, synthetic data generation, public-facing AI tool operation, or downstream AI product development.

AI-use permission must be separately recorded through an AI-Use Label or equivalent data-use instrument. Where AI use is permitted, the record should identify:

1. permitted AI-use class;
2. prohibited AI-use class;
3. model or system class where relevant;
4. whether training, fine-tuning, embedding, retrieval, summarization, classification, generation, simulation, or agentic use is allowed;
5. whether outputs may be published, taught, listed, reported, demonstrated, or handed off;
6. whether human review is required;
7. whether secure-room, data-room, clean-room, or compute-to-data conditions apply;
8. whether protected knowledge, personal data, health data, youth data, community data, Indigenous protocol-sensitive data where applicable, cyber-sensitive data, geospatial-sensitive data, or public authority-sensitive data is excluded;
9. correction, deletion, model-output recall, and archive rules.

The absence of an AI-use permission means no AI use beyond ordinary non-AI handling unless a competent steward records otherwise. Public availability does not mean AI-training permission. A dataset used for a report does not become a model-training corpus. A data-room review does not authorize extraction into AI tools. A community contribution does not authorize AI training. Indigenous participation where applicable does not authorize protected knowledge ingestion. Handoff context does not transfer AI-use rights unless expressly recorded.

The final DICE and Data Commons Doctrine rule is: data is governed evidence, learning, and intelligence infrastructure; commons means lawful, recorded, rights-respecting, public-safe sharing, not unrestricted extraction; metadata bridges openness and control; data rights and AI-use permissions must be explicit; no data object becomes open, publishable, AI-trainable, financeable, insurable, public-authority-approved, consented, deployable, or executable by implication.

## 10.2 Data Object Classes

### 10.2.1 Raw Data

Raw data is data in its original or near-original collected, received, captured, sensed, submitted, extracted, observed, logged, generated, or imported form before substantial cleaning, transformation, aggregation, normalization, public-safe conversion, modeling, or publication. Raw data may come from sensors, surveys, administrative records, public authority sources, research sources, community inputs, Indigenous knowledge contexts where applicable, geospatial sources, Earth observation, cyber telemetry, infrastructure logs, health systems, WFEH-B systems, provider systems, Studio workflows, Observatory nodes, DRI pipelines, Campaign inputs, National Portfolio processes, Nexus Universe rooms, or handoff-recipient materials.

Raw data carries the highest governance burden because it may include personal information, sensitive attributes, location data, protected knowledge, confidential institutional information, cyber-sensitive details, infrastructure-sensitive details, public authority-sensitive records, commercial restrictions, data-quality defects, missingness, bias, uncertainty, or context that can be lost when separated from its source. Raw data should therefore be treated as controlled or restricted by default unless a competent steward records that it is lawful, safe, and appropriate for open use.

A Raw Data Record should identify:

1. source and steward, including who provided, collected, generated, or controls the data;
2. collection or generation method, including sensor, survey, administrative process, observation, model output, system log, public record, research process, community process, or other source pathway;
3. rights and lawful basis, including license, permission, consent where applicable, contract, public authority basis, research basis, or restriction;
4. sensitivity and access class, including privacy, cyber, health, youth, geospatial, infrastructure, community, Indigenous protocol where applicable, protected knowledge, public authority, sovereign, legal, or security sensitivity;
5. data-use and AI-use labels, including whether viewing, querying, transformation, publication, AI training, embedding, summarization, classification, simulation, handoff, or cross-border transfer is permitted;
6. quality and limitation notes, including completeness, missingness, uncertainty, bias, timeliness, spatial resolution, temporal resolution, and known defects;
7. correction, restriction, deletion, sealing, recall, and archive rules.

Raw data should not be placed in open repositories, used in public dashboards, included in public Reports, used for AI training, displayed at Nexus Universe, listed in Marketplace, transferred to handoff recipients, or reused in Academy materials unless the relevant rights, reviews, transformations, public-safe controls, and access conditions allow that specific use. Raw data is evidence potential, not public-good release by default.

### 10.2.2 Processed Data

Processed data is data that has been cleaned, normalized, transformed, validated, enriched, joined, filtered, structured, geocoded, labeled, encoded, classified, deduplicated, quality-checked, or otherwise modified from raw form for a defined Nexus purpose. Processed data may support DICE objects, DRI indicators, GRIx mappings, Observatory outputs, Studio workflows, dashboards, digital twins, simulations, Reports, Academy modules, Campaign summaries, Grid or TRL records, Marketplace listings, Registry records, National Portfolio objects, Nexus Universe outputs, or handoff packages.

Processed data should preserve lineage. Transformation must not erase the source, rights, sensitivity, uncertainty, missingness, bias, or limitations of the raw data. Processing may improve usability, but it may also introduce assumptions, errors, exclusions, or interpretation changes. Nexus therefore treats processed data as a new governed data object connected to its source objects and transformation method.

A Processed Data Record should identify:

1. source data objects and versions;
2. processing method, including cleaning, normalization, transformation, linkage, aggregation, enrichment, geocoding, labeling, classification, or feature generation;
3. processing environment, including open, controlled, secure-room, data-room, clean-room, compute-to-data, National Node, Studio, or handoff-recipient environment;
4. quality changes, including errors corrected, records excluded, fields changed, assumptions applied, uncertainty introduced, and known limitations;
5. rights and restrictions carried forward, including license, consent limits, data-use limits, AI-use limits, privacy restrictions, public authority restrictions, protected knowledge restrictions, and jurisdictional conditions;
6. review status, including data review, method review, public-safe review, AI review where applicable, and safeguard review where relevant;
7. correction and archive relationship, including source correction propagation and downstream object correction.

Processed data is not automatically safer than raw data. De-identification may be incomplete. Aggregation may still reveal sensitive locations. Normalization may hide bias. Labeling may encode contested assumptions. Processing improves structure; it does not create unrestricted rights, public-safe status, certification, public authority approval, consent, deployment authorization, or execution authority.

### 10.2.3 Public-Safe Data

Public-safe data is data or data-derived material that has passed a public-safe transformation and review pathway for a defined audience and release class. Public-safe data may be produced through aggregation, masking, redaction, de-identification, synthetic substitution, geospatial generalization, uncertainty labeling, limitation language, sensitive-field removal, protected knowledge exclusion, public authority boundary review, and no-conversion language.

Public-safe data may include public-facing tables, maps, indicators, dashboards, summaries, charts, teaching datasets, public-safe DRI extracts, public-safe Observatory summaries, public-safe National Portfolio summaries, Campaign metrics, Nexus Universe public materials, Marketplace descriptions, Reports figures, and handoff-facing summaries. Its purpose is to communicate data-derived knowledge without exposing sensitive source data or creating unsafe reliance.

A Public-Safe Data Record should identify:

1. source data and source access class;
2. public-safe transformation method;
3. removed, masked, generalized, or restricted fields;
4. audience and release class;
5. residual risk, including re-identification, geospatial exposure, community harm, public authority confusion, finance or insurance overclaim, and consent overclaim;
6. required limitation and uncertainty language;
7. review pathway, including public-safe, data, privacy, cyber, safeguard, community, Indigenous protocol where applicable, and public authority boundary review where relevant;
8. correction, withdrawal, recall, and archive pathway.

Public-safe data is not automatically open data. It may be public-safe only for a specific summary, chart, room, classroom, report, dashboard, or audience. Public-safe status may change if new linkage risks arise, source data is corrected, public authority context changes, community concerns arise, Indigenous protocol concerns arise where applicable, or downstream misuse appears.

Public-safe data informs responsibly. It does not become public warning, official determination, procurement recommendation, finance signal, insurance rating, consent record, deployment authorization, or execution instruction.

### 10.2.4 Aggregated Data

Aggregated data is data combined or summarized across records, persons, places, institutions, systems, time periods, sectors, hazards, indicators, or categories so that individual-level or source-level detail is reduced. Aggregation may support public-safe reporting, dashboards, DRI indicators, Observatory outputs, National Portfolio summaries, Reports, Academy materials, Campaign metrics, Grid context, Nexus Universe outputs, and handoff context.

Aggregation may reduce sensitivity but does not eliminate risk by default. Aggregated data can still expose small populations, vulnerable groups, sensitive locations, Indigenous lands or knowledge contexts where applicable, health patterns, infrastructure vulnerabilities, cyber posture, public authority capacity, commercial information, or community-sensitive conditions. Aggregation must therefore be governed by threshold rules, suppression rules, geospatial generalization, uncertainty labeling, and public-safe review.

An Aggregated Data Record should identify:

1. source data objects;
2. aggregation method, including grouping variables, thresholds, time period, geography, categories, weighting, and suppression rules;
3. minimum cell-size or disclosure-control rules where relevant;
4. geospatial treatment, including masking, displacement, generalization, or restricted-resolution display;
5. bias and missingness implications;
6. public-safe status and audience;
7. data-use and AI-use restrictions;
8. correction propagation from source data and to downstream objects.

Aggregation is not anonymization by default. It is not consent. It is not permission to publish. It is not permission to train AI. Aggregated data must still carry its rights, limitations, access class, public-safe status, and correction pathway.

### 10.2.5 Synthetic Data

Synthetic data is artificially generated data designed to resemble, simulate, teach, test, benchmark, demonstrate, or approximate real-world data patterns without directly exposing raw source records. Synthetic data may support Academy learning, software testing, dashboard demonstrations, Studio workflows, model evaluation, API examples, DICE exercises, GRIx mapping, DRI training, public-safe reporting demonstrations, Nexus Universe demonstrations, and handoff preparation.

Synthetic data can be useful because it may reduce exposure of sensitive source data. It does not eliminate risk by default. Synthetic data may still leak patterns from source data, reproduce bias, create false realism, mislead users, imply representativeness, or be misused as real evidence. It must be labeled clearly and governed as a data object.

A Synthetic Data Record should identify:

1. generation method, including rule-based generation, simulation, model-generated data, anonymized derivative generation, or manually constructed examples;
2. source relationship, including whether real data informed the structure and what restrictions carry forward;
3. intended use, including testing, teaching, demonstration, benchmarking, public-safe illustration, or handoff training;
4. prohibited use, including real-world inference, public authority decision, finance decision, insurance decision, procurement decision, operational deployment, or evidence claim beyond scope;
5. bias, realism, and limitation notes;
6. AI-use permissions and restrictions;
7. review, correction, and archive pathway.

Synthetic data is not automatically public-safe, unrestricted, or evidence-bearing. It may be a learning object, test object, or demonstration object. It must not be represented as real observation unless explicitly and truthfully described as such. Synthetic data helps protect source data; it does not create authority.

### 10.2.6 Metadata-Only Records

Metadata-only records are records that describe data objects without exposing the underlying data. They may identify title, steward, source pathway, subject matter, geography, time period, data class, access class, sensitivity class, data-use label, AI-use label, quality summary, public-safe summary availability, update cadence, review status, Registry status, Marketplace discoverability, National Portfolio relationship, Nexus Universe relationship, and handoff relevance.

Metadata-only records are essential where source data cannot be opened but its existence, governance, and possible public-good relevance should be known. They allow discovery, review routing, data access requests, public-safe reporting planning, Studio planning, Academy planning, Foundry planning, Grid routing, Registry status truth, Marketplace controlled discovery, and handoff dependency mapping without exposing restricted data.

A Metadata-Only Record should identify:

1. what may be known publicly or by controlled users;
2. what source data remains restricted;
3. who controls access;
4. what access request pathway applies;
5. what public-safe derivative exists, if any;
6. what AI-use restrictions apply;
7. what jurisdictional, privacy, cyber, community, Indigenous protocol where applicable, protected knowledge, or public authority restrictions apply;
8. correction and archive pathway.

Metadata itself may be sensitive. The existence of a dataset, its location, steward, geography, public authority relationship, infrastructure relationship, or community relationship may require control. Metadata-only does not mean harmless. It means source data is not exposed.

### 10.2.7 Data Dictionaries

Data dictionaries are structured metadata objects that define fields, variables, columns, codes, units, formats, permissible values, missing-value meanings, sensitivity labels, data types, quality notes, lineage notes, and interpretation rules for a data object or data object family.

Data dictionaries make data usable, reviewable, interoperable, teachable, and correctable. They support DICE, GRIx, DRI, Observatory, Studio, Reports, Academy, Marketplace, Registry, Grid, National Portfolios, Nexus Universe, and handoff packages by explaining what data fields mean and how they may be safely interpreted.

A Data Dictionary Record should identify:

1. dataset or object family covered;
2. field names and definitions;
3. data types, units, formats, and allowed values;
4. missingness codes and quality notes;
5. sensitivity labels by field;
6. data-use and AI-use restrictions by field where relevant;
7. controlled vocabulary or ontology links;
8. localization or translation status;
9. review status and steward;
10. correction and archive pathway.

A data dictionary does not make the underlying data open, accurate, complete, public-safe, AI-trainable, or authorized for handoff. It is an interpretive object. If the dictionary is wrong, every downstream use may be wrong. Data dictionaries therefore require versioning and correction discipline.

### 10.2.8 Codebooks

Codebooks are data interpretation objects that define codes, categories, labels, survey responses, qualitative codes, classification rules, ontology mappings, risk categories, DRI categories, GRIx categories, public authority learning categories, safeguard categories, consent boundary categories, or other coded values used in data objects.

Codebooks may support survey data, administrative data, qualitative research, community inputs, public authority learning records, DRI datasets, GRIx mappings, Observatory datasets, Campaign data, Academy assessments, National Portfolio objects, Nexus Universe room records, and handoff packages.

A Codebook Record should identify:

1. coded dataset or object;
2. code values and meanings;
3. classification method;
4. coder or steward;
5. inter-coder or review process where applicable;
6. controlled vocabulary or ontology relationship;
7. cultural, linguistic, legal, community, or Indigenous protocol context where applicable;
8. sensitivity and public-safe implications;
9. bias, ambiguity, and limitation notes;
10. correction, recoding, supersession, and archive pathway.

Codebooks are powerful because they shape what data appears to mean. They can also encode bias, erase local context, flatten protected knowledge, or create false categories. A codebook must not be treated as neutral simply because it is structured.

A codebook does not create official classification, public authority determination, certification, finance or insurance rating, procurement category, consent status, deployment authorization, or execution authority. It records meaning within scope.

### 10.2.9 Schemas

Schemas are structural data objects that define how data, metadata, records, APIs, Registry entries, Marketplace listings, Studio workflows, Grid records, TRL records, National Portfolio objects, Nexus Universe outputs, proof receipts, ledgers, registers, and handoff packages must be represented.

Schemas may specify fields, data types, required values, validation rules, controlled vocabularies, ontology relationships, sensitivity labels, access labels, public-safe labels, data-use labels, AI-use labels, version fields, correction fields, archive fields, localization fields, and interoperability rules.

A Schema Record should identify:

1. schema purpose and object class;
2. version and steward;
3. required and optional fields;
4. validation rules;
5. controlled vocabulary and ontology dependencies;
6. sensitivity and access fields;
7. public-safe and no-conversion fields;
8. data-use and AI-use fields;
9. interoperability and API relationships;
10. correction, migration, deprecation, and archive pathway.

A schema structures data; it does not validate the truth of the data entered. Schema conformance is not evidence sufficiency, public-safe approval, certification, procurement status, financeability, insurability, public authority action, consent, deployment authorization, or execution authority.

Schema discipline makes object movement possible. Review discipline makes object meaning trustworthy.

### 10.2.10 Data Pipelines

Data pipelines are governed workflow objects that move, transform, validate, enrich, aggregate, anonymize, classify, label, route, publish, restrict, or hand off data across systems, rooms, repositories, dashboards, Studio workflows, Observatory nodes, DRI workflows, GRIx mappings, Reports, Academy pathways, Marketplace listings, Registry records, Grid records, National Portfolios, Nexus Universe outputs, or lawful recipients.

A data pipeline may include ingestion, validation, transformation, metadata generation, quality checks, DICE controls, AI-assisted classification, feature generation, aggregation, public-safe transformation, secure-room processing, clean-room computation, compute-to-data execution, output review, Registry update, Marketplace update, or handoff packaging.

A Data Pipeline Record should identify:

1. pipeline purpose and source systems;
2. input data objects and access classes;
3. processing steps and transformation methods;
4. runtime environment, including open, controlled, secure room, data room, clean room, compute-to-data, Studio, National Node, or handoff-recipient environment;
5. permissions and controls, including authentication, authorization, logging, no-download, no-write-back, output review, and cross-border transfer controls;
6. AI-use, including whether AI assists classification, transformation, summarization, generation, or review;
7. outputs and release classes;
8. quality checks, failure handling, incident pathway, correction pathway, rollback, archive, and non-continuation rules.

Data pipelines can create hidden authority if they automatically publish, update dashboards, trigger reports, route status, or package handoff materials. Pipeline outputs should require review gates where public-safe, public authority, finance, insurance, procurement, consent, or handoff implications arise. Automation is not authority.

### 10.2.11 Feature Sets

Feature sets are structured variables or derived attributes prepared for modeling, analysis, dashboards, DRI indicators, AI workflows, digital twins, simulations, risk scoring, Observatory outputs, Grid reviews, or handoff-context evaluation. Feature sets may be generated from raw data, processed data, aggregated data, synthetic data, geospatial data, sensor data, metadata, or qualitative coding.

Feature sets are high-risk because they transform data into model-ready or decision-adjacent form. A feature may encode assumptions, proxies, bias, sensitivity, protected attributes, community context, Indigenous protocol-sensitive knowledge where applicable, or public authority implications. Feature engineering must therefore be governed as a substantive act, not a technical detail.

A Feature Set Record should identify:

1. source data objects;
2. features included and excluded;
3. feature definitions and calculation methods;
4. sensitivity, proxy, bias, and fairness considerations;
5. data-use and AI-use permissions;
6. model, dashboard, DRI, Studio, Grid, or handoff relationship;
7. quality, missingness, uncertainty, and limitation notes;
8. review status, including data, AI, public-safe, safeguard, and public authority boundary review where relevant;
9. correction, deprecation, withdrawal, recall, and archive pathway.

A feature set is not a model certification. It is not a risk rating, public authority classification, finance score, insurance score, procurement priority, consent record, deployment authorization, or execution instruction. It is a governed input that must remain interpretable and correctable.

### 10.2.12 Benchmark Datasets

Benchmark datasets are data objects used to evaluate, compare, test, calibrate, demonstrate, or review software, models, AI workflows, dashboards, DRI indicators, GRIx mappings, data pipelines, Studio workflows, digital twins, simulations, or public-good technical baselines.

Benchmark datasets may be open, controlled, synthetic, restricted, secure-room-only, data-room-only, clean-room-only, National Node-specific, public-safe, or handoff-recipient-only. Their value depends on clear scope and limitation. A benchmark that is narrow, biased, outdated, synthetic, localized, incomplete, or context-specific should not be represented as universal.

A Benchmark Dataset Record should identify:

1. benchmark purpose;
2. source and construction method;
3. coverage and exclusions;
4. ground truth or reference standard where applicable;
5. metrics supported and metrics not supported;
6. bias, missingness, uncertainty, and limitation notes;
7. data-use and AI-use permissions, including whether model training, fine-tuning, evaluation, publication, or redistribution is permitted;
8. access class and sensitivity class;
9. review status;
10. correction, versioning, supersession, withdrawal, recall, and archive rules.

Benchmark performance is not certification. A model performing well on a benchmark is not safe for deployment. A dashboard passing benchmark tests is not public authority-ready. A software tool matching benchmark expectations is not procurement-ready. Benchmarks are evidence inputs, not authority.

### 10.2.13 DRI Datasets

DRI datasets are data objects used to support disaster-risk intelligence, systemic-risk awareness, hazard, exposure, vulnerability, capacity, resilience, degraded-mode, cascade, WFEH-B, infrastructure, cyber-physical, climate, nature, protection-gap, public authority learning, finance-readiness, insurance-readiness, National Portfolio, Nexus Universe, Studio, Reports, Grid, or handoff-context workflows.

DRI datasets may include hazard data, exposure data, vulnerability data, resilience data, infrastructure data, WFEH-B data, geospatial data, sensor data, Earth observation data, public service data, logistics data, climate and weather data, biodiversity data, cyber-physical telemetry, public authority learning inputs, public-safe community context, and finance or insurance-relevant dependency data.

A DRI Dataset Record should identify:

1. risk-intelligence purpose;
2. hazard, exposure, vulnerability, capacity, resilience, or dependency category;
3. source, provenance, and lineage;
4. geography and time period;
5. quality, uncertainty, confidence, missingness, and bias;
6. public-safe status;
7. data-use and AI-use labels;
8. geospatial, infrastructure, privacy, cyber, community, Indigenous protocol where applicable, protected knowledge, public authority, finance, or insurance sensitivity;
9. DRI indicator relationship and GRIx mapping relationship;
10. Studio, Observatory, Reports, Grid, National Portfolio, Nexus Universe, and handoff relationships;
11. correction and archive pathway.

A DRI dataset is not a public warning. It is not official hazard designation, public authority classification, insurance rating, investment signal, procurement priority, consent record, deployment authorization, or execution instruction. It supports risk intelligence within recorded limits.

### 10.2.14 Observatory Datasets

Observatory datasets are data objects used by Nexus Observatory to collect, organize, interpret, route, summarize, or display signals related to systems risk, WFEH-B conditions, climate and nature stress, infrastructure resilience, digital infrastructure, cyber-physical systems, sensor and edge signals, Earth observation, geospatial layers, DRI indicators, GRIx mappings, degraded-mode awareness, digital twin needs, National Portfolios, Nexus Universe preparation, Studio workflows, Reports, Campaigns, Grid, and handoff context.

Observatory datasets may come from sensors, remote sensing, field observations, public datasets, partner datasets, National Node datasets, public authority learning sources, community inputs where appropriate, providers, research bodies, secure rooms, data rooms, clean rooms, compute-to-data workflows, or derived public-safe outputs.

An Observatory Dataset Record should identify:

1. signal purpose and signal class;
2. node, hub, regional cluster, or National Dense Nexus Core relationship;
3. source and steward;
4. collection method and update cadence;
5. geography, resolution, and temporal coverage;
6. sensitivity, including geospatial, infrastructure, cyber, privacy, community, Indigenous protocol where applicable, protected knowledge, ecological, public authority, or sovereign sensitivity;
7. public-safe transformation rules;
8. data-use and AI-use labels;
9. Studio, DRI, GRIx, Reports, Grid, National Portfolio, Nexus Universe, and handoff relationships;
10. correction, withdrawal, recall, and archive pathway.

Observatory datasets must not turn observation into surveillance. Sensor visibility, map layers, or signal records do not create public warning authority, emergency command, public authority decision, procurement priority, financeability, insurability, consent, deployment authorization, or execution authority.

### 10.2.15 National Portfolio Datasets

National Portfolio datasets are data objects that support country-level Nexus public-good memory, national systems-risk understanding, National Challenge Briefs, Evidence Need Records, DICE records, GRIx localization, DRI localization, Observatory needs, Studio workflow candidates, Academy pathways, Campaign candidates, Foundry builds, Grid and TRL context, public authority learning, safeguard records, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance learning, Nexus Universe preparation, lawful handoff dependencies, correction, and archive.

National Portfolio datasets may be open, controlled, restricted, National Node-only, public-authority-learning-only, secure-room-only, data-room-only, clean-room-only, protected-knowledge-controlled, public-safe-summary-only, handoff-recipient-only, archive-only, or non-continuing. They should be governed according to national ownership, national data sovereignty, public authority boundaries, language and localization needs, community safeguards, Indigenous protocols where applicable, and national lawful handoff pathways.

A National Portfolio Dataset Record should identify:

1. country and National Node relationship;
2. National Nexus Consortium, National Council, Working Group, or Competence Cell relationship where applicable;
3. national purpose, including risk mapping, evidence need, public authority learning, Academy, Foundry, Campaign, Studio, Nexus Universe, Grid, or handoff context;
4. source, steward, provenance, and jurisdictional context;
5. data sovereignty, privacy, cyber, public authority, community, Indigenous protocol where applicable, protected knowledge, and cross-border transfer conditions;
6. public-safe status and localization status;
7. data-use and AI-use labels;
8. finance-readiness, insurance-readiness, donor-readiness, or public finance learning relationship where applicable;
9. correction, recall, archive, and national continuation pathway.

A National Portfolio dataset is not government approval, public authority action, procurement status, financeability, insurability, consent, deployment authorization, or execution authority. It is country-level public-good memory and preparation infrastructure. It helps a nation see, learn, prepare, and route context without bypassing competent national actors.

The final Data Object Classes rule is: raw data requires the strongest caution; processed data requires lineage; public-safe data requires transformation and review; aggregated data still carries risk; synthetic data must not pretend to be real; metadata-only records enable safe discovery; dictionaries, codebooks, and schemas preserve meaning; pipelines move data under controls; feature sets govern model-ready inputs; benchmarks support evaluation without certification; DRI and Observatory datasets support intelligence without warning authority; National Portfolio datasets preserve country-level memory without national approval or execution by implication.

## 10.3 Data Lifecycle

### 10.3.1 Data Signal

A data signal is the earliest indication that a data object, data need, data gap, data source, data risk, metadata need, public-safe data opportunity, DICE object, DRI dataset, Observatory dataset, National Portfolio dataset, Studio data workflow, Reports data dependency, Academy data object, Campaign data object, Grid or TRL data dependency, Nexus Universe data object, or handoff-related data package may require Nexus attention.

A data signal may arise from Observatory nodes, DRI workflows, GRIx mappings, public authority learning rooms, National Nodes, National Portfolios, Working Groups, Competence Cells, Nexus Labs, Nexus Foundry, Nexus Studio, Nexus Academy, Risk Academy, Nexus Campaigns, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Grid, Nexus Universe, community safeguard rooms, protected knowledge rooms, secure rooms, data rooms, clean rooms, providers, sponsors, universities, public authorities acting separately, capital readers, insurers, donors, or lawful handoff recipients.

A data signal should identify, at minimum:

1. the apparent data subject or need, including risk, system, technology, geography, community, institution, workflow, model, report, dashboard, or handoff dependency;
2. the apparent source pathway, including whether the signal comes from observation, public source, private source, public authority learning context, community context, provider contribution, sponsor-supported pathway, research pathway, Studio workflow, National Portfolio pathway, Nexus Universe cycle, or handoff discussion;
3. the possible data class, including raw, processed, public-safe, aggregated, synthetic, metadata-only, DRI, Observatory, National Portfolio, benchmark, feature set, data dictionary, codebook, schema, or data pipeline object;
4. the immediate risk indicators, including privacy, cyber, geospatial, infrastructure, public authority, health, youth, community, Indigenous protocol where applicable, protected knowledge, sovereign, legal, finance, insurance, procurement, consent, public-safe, or AI-use concerns;
5. the next routing need, including intake, restriction, secure-room handling, data-room handling, public-safe review, rights review, DICE routing, National Node routing, or correction routing.

A data signal is not data approval. It is not permission to collect, access, process, publish, train AI, list, register, transfer, hand off, deploy, or execute. It is a trigger for disciplined intake and classification.

### 10.3.2 Data Intake

Data intake is the lifecycle state in which a data signal, dataset, metadata record, data product, data dictionary, codebook, schema, data pipeline, feature set, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, or handoff data object enters a governed Nexus pathway for preliminary handling.

Data intake should occur before data is placed into repositories, used in software, displayed in dashboards, processed through AI tools, routed to Studio, converted into Reports, used in Academy materials, listed in Marketplace, recorded in Registry, classified through Grid or TRL, presented at Nexus Universe, included in National Portfolios, or transferred through handoff packages.

A Data Intake Record should identify:

1. data object identity, including provisional identifier, title, source, steward, and submitting pathway;
2. intake pathway, including DICE, Observatory, DRI, GRIx, Studio, Labs, Foundry, Academy, Reports, Campaigns, Grid, Marketplace, Registry, National Node, Nexus Universe, public authority learning room, secure room, data room, clean room, or handoff pathway;
3. data type and format, including file type, database, API, sensor feed, geospatial layer, model output, notebook output, dashboard input, report table, or metadata-only record;
4. initial access class, including open, controlled, restricted, secure-room-only, data-room-only, clean-room-only, compute-to-data-only, National Node-only, protected-knowledge-controlled, handoff-recipient-only, archive-only, sealed, or non-public;
5. known rights and restrictions, including license, contract, consent, public authority basis, provider terms, sponsor terms, community terms, Indigenous protocol where applicable, protected knowledge conditions, privacy, cyber, data sovereignty, cross-border transfer, and AI-use limits;
6. immediate handling instructions, including quarantine, no-download, no-AI-use, no-publication, no-sharing, no-cross-border-transfer, no-linkage, no-dashboard-display, no-Marketplace-listing, no-handoff, or secure-room routing.

Data intake does not authorize use. It creates a controlled record so that use can be assessed. Data that cannot be safely classified at intake should default to restriction until source, rights, sensitivity, data-use, AI-use, and public-safe conditions are reviewed.

### 10.3.3 Source Review

Source review examines where data came from, how it was collected or generated, who provided it, what authority or permission applies, what context may be missing, what biases may exist, and what source-related restrictions or risks must travel with the data.

Source review should determine whether the source is:

1. publicly available, and if so, under what license, terms, scraping limits, attribution duties, reuse limits, AI-use limits, and public-safe conditions;
2. institutionally provided, and if so, under what agreement, role, confidentiality condition, data-sharing condition, or support record;
3. public authority-related, and if so, whether the source relates to public authority learning, official records, public law restrictions, public finance, emergency authority, regulatory procedure, procurement, or public communications;
4. community-sourced, and if so, whether participation, consent boundaries, non-extraction controls, dignity safeguards, and public-safe limits are recorded;
5. Indigenous protocol-sensitive where applicable, and if so, whether governance, custodianship, rights, protected knowledge, data sovereignty, consent, and access restrictions are properly recorded;
6. provider-contributed, and if so, whether provider contribution is recorded without provider validation;
7. sponsor-supported, and if so, whether sponsor support is recorded without sponsor control;
8. machine-generated or model-generated, and if so, whether model source, synthetic status, uncertainty, limitations, and AI-use restrictions are recorded;
9. sensor, edge, geospatial, Earth observation, cyber, or infrastructure-derived, and if so, whether technical provenance, collection conditions, resolution, sensitivity, and public-safe limits are recorded.

A Source Review Record should state what is known, what is unknown, what must be verified, what restrictions apply, and whether the data may proceed to rights review, sensitivity review, DICE routing, secure-room handling, public-safe transformation, or archive.

Source review is not source endorsement. It establishes provenance and risk context. It does not create data rights, AI-use permission, public authority approval, consent, publication rights, deployment authorization, or execution authority.

### 10.3.4 Rights Review

Rights review determines what legal, contractual, institutional, community, Indigenous protocol where applicable, privacy, public authority, license, intellectual property, database, data protection, confidentiality, export, cross-border transfer, and use rights apply to a data object.

Rights review should distinguish separate rights rather than treating data access as a single permission. A Rights Review Record should determine whether the data may be:

1. viewed;
2. stored;
3. indexed;
4. queried;
5. cleaned or transformed;
6. linked with other data;
7. aggregated;
8. de-identified or masked;
9. used in dashboards;
10. used in Reports;
11. used in Academy or Campaign materials;
12. used in Studio;
13. used in DRI, GRIx, Observatory, Grid, Marketplace, or Registry workflows;
14. used for AI retrieval, classification, summarization, embedding, training, fine-tuning, simulation, or agentic workflows;
15. transferred across borders;
16. shared with participants;
17. published;
18. licensed onward;
19. handed off to a recipient;
20. archived, sealed, deleted, or recalled.

Rights review should identify the source of each right, any conditions, any prohibited uses, any expiration, any withdrawal rights, any attribution duties, any audit duties, any consent requirements, and any data subject, community, Indigenous, institutional, or public authority rights that must be respected.

Rights review does not convert controlled data into open data. It prevents misuse by making permissions explicit. Where rights are unclear, the most restrictive reasonable handling should apply until clarification is recorded.

### 10.3.5 Sensitivity Review

Sensitivity review classifies the risks that may arise from data access, use, disclosure, linkage, aggregation, publication, AI use, geospatial display, public-safe reporting, Marketplace discovery, Registry display, Studio workflow, National Portfolio inclusion, Nexus Universe presentation, handoff, correction, or archive.

Sensitivity review should identify whether the data is or may be:

1. personal-data-sensitive;
2. health-sensitive;
3. youth-sensitive;
4. vulnerable-population-sensitive;
5. community-sensitive;
6. Indigenous protocol-sensitive where applicable;
7. protected-knowledge-sensitive;
8. cultural-heritage-sensitive;
9. ecological-sensitive;
10. geospatial-sensitive;
11. infrastructure-sensitive;
12. cyber-sensitive;
13. public authority-sensitive;
14. sovereign-sensitive;
15. finance-sensitive;
16. insurance-sensitive;
17. procurement-sensitive;
18. legal-sensitive;
19. security-sensitive;
20. dual-use-sensitive;
21. export-control-sensitive where applicable;
22. archive-sensitive;
23. sealed or non-public.

Sensitivity review should consider both direct exposure and inference risk. Data may appear harmless alone but become sensitive when linked with other datasets, mapped at high resolution, processed by AI, included in dashboards, used in public reporting, routed to capital or insurance rooms, included in handoff materials, or displayed at Nexus Universe.

A Sensitivity Review Record should identify sensitivity class, access class, public-safe restrictions, output review requirements, secure-room or data-room needs, AI-use restrictions, cross-border transfer restrictions, correction triggers, incident pathway, and archive rule.

Sensitivity classification does not prohibit all use. It determines lawful and safe conditions of use. Where ambiguity exists, the more restrictive control should govern until review supports a narrower classification.

### 10.3.6 Data-Use Labeling

Data-use labeling assigns a recorded label to the data object describing what uses are permitted, restricted, prohibited, conditional, review-required, room-required, public-safe-transformation-required, handoff-limited, archive-only, or non-continuing.

Data-use labels should be specific enough to prevent broad inference. A data-use label may state that data is:

1. open for public use;
2. public-safe summary only;
3. controlled participant access;
4. internal Nexus use only;
5. National Node-only;
6. public authority learning only;
7. secure-room-only;
8. data-room-only;
9. clean-room-only;
10. compute-to-data-only;
11. dashboard-display permitted only in public-safe aggregate;
12. Reports use permitted only after public-safe review;
13. Academy use permitted only with synthetic or masked version;
14. Marketplace metadata-only;
15. Registry metadata-only;
16. handoff-recipient-only;
17. no download;
18. no cross-border transfer;
19. no publication;
20. no linkage;
21. archive-only;
22. deletion or sealing required;
23. non-continuing.

A Data-Use Label should travel with the data and all derived objects unless a lawful and recorded transformation changes the label. The label should appear in metadata, repositories, DICE records, Studio records, Reports records, Marketplace records, Registry records, Grid records, National Portfolio records, Nexus Universe records, and handoff packages where relevant.

Data-use labeling does not create permission beyond its terms. It constrains interpretation and prevents data from being treated as generally available merely because it has entered the ecosystem.

### 10.3.7 AI-Use Labeling

AI-use labeling assigns a recorded label to the data object describing whether and how data may be used with AI systems. It is separate from general data-use labeling because data that may be viewed or analyzed by humans may still be prohibited from AI training, embedding, retrieval augmentation, automated classification, summarization, simulation, generation, model evaluation, agentic workflow, or downstream AI product development.

AI-use labels may include:

1. no AI use permitted;
2. AI-assisted metadata generation permitted;
3. AI-assisted summarization permitted after review;
4. AI-assisted classification permitted under controlled conditions;
5. AI-assisted translation permitted with human review;
6. retrieval use permitted without retention;
7. embedding permitted in controlled environment;
8. model evaluation permitted;
9. simulation use permitted;
10. synthetic data generation permitted;
11. training prohibited;
12. fine-tuning prohibited;
13. agentic use prohibited;
14. public AI tools prohibited;
15. secure-room-only AI use;
16. data-room-only AI use;
17. clean-room-only AI use;
18. compute-to-data-only AI use;
19. protected knowledge excluded from AI use;
20. personal data excluded from AI use;
21. public-safe outputs only;
22. AI-use under suspension or correction.

An AI-Use Label should identify permitted model classes, prohibited model classes, approved environments, human review requirements, output review requirements, retention rules, logging rules, prompt-injection controls, data leakage controls, protected knowledge controls, deletion or recall obligations, and downstream restriction propagation.

No AI-use permission should be inferred from data access. The default is no AI use unless an AI-use label permits the specific use. This rule protects data subjects, communities, Indigenous institutions where applicable, protected knowledge, public authorities, data stewards, and Nexus from unauthorized AI extraction.

### 10.3.8 Lineage Capture

Lineage capture records the history of a data object from source through processing, transformation, review, public-safe conversion, repository routing, DICE routing, Registry status, Marketplace listing, Studio workflow, Report, Academy object, Campaign object, Grid input, National Portfolio object, Nexus Universe output, handoff package, correction, and archive.

Lineage capture should identify:

1. source data object or source pathway;
2. source version;
3. intake record;
4. rights review record;
5. sensitivity review record;
6. data-use label;
7. AI-use label;
8. processing steps;
9. transformation methods;
10. aggregation, masking, de-identification, geospatial generalization, or synthetic generation steps;
11. tools, software, models, notebooks, APIs, pipelines, or AI systems used;
12. reviewers and review dates;
13. derived objects;
14. downstream objects and dependencies;
15. corrections, withdrawals, recalls, supersessions, and archive status.

Lineage is essential because data meaning changes as data moves. A dashboard may depend on processed data, which depends on raw data, which depends on a source license, which depends on consent, which may later be withdrawn or restricted. Without lineage, correction cannot propagate and public-safe status cannot be trusted.

Lineage capture does not validate the data. It records the path by which data became an object. That path supports evidence, correction, and accountability without creating authority by implication.

### 10.3.9 Quality Assessment

Quality assessment evaluates whether a data object is fit for a defined Nexus purpose. Data quality is purpose-relative. A dataset may be sufficient for exploratory learning but insufficient for public-safe reporting; sufficient for a Studio demonstration but insufficient for handoff; sufficient for a DRI signal but insufficient for public authority action; sufficient for a report table but insufficient for model training.

Quality assessment should consider:

1. completeness;
2. accuracy;
3. consistency;
4. timeliness;
5. provenance;
6. representativeness;
7. missingness;
8. bias;
9. uncertainty;
10. spatial resolution;
11. temporal resolution;
12. measurement error;
13. collection method limitations;
14. transformation error;
15. interoperability;
16. documentation quality;
17. metadata completeness;
18. public-safe adequacy;
19. review sufficiency;
20. correction readiness.

A Quality Assessment Record should identify the data object, purpose assessed, methods used, findings, limitations, quality class where used, confidence, unresolved issues, recommended use, prohibited use, required corrections, review needs, and archive implications.

Quality assessment is not certification. It does not mean the data is true for all purposes, legally usable for all purposes, AI-trainable, public-safe, finance-relevant, insurance-relevant, public-authority-ready, consented, deployment-ready, or executable. It indicates whether the data is adequate for a recorded Nexus use and what limitations apply.

### 10.3.10 Public-Safe Transformation

Public-safe transformation converts raw, processed, controlled, restricted, geospatial, sensitive, community, Indigenous protocol-sensitive where applicable, public authority-sensitive, cyber-sensitive, infrastructure-sensitive, finance-sensitive, insurance-sensitive, or otherwise risky data into a form suitable for a defined public-safe or controlled communication purpose.

Public-safe transformation may include:

1. aggregation;
2. masking;
3. redaction;
4. de-identification;
5. suppression;
6. geospatial generalization;
7. spatial displacement;
8. time-window generalization;
9. field removal;
10. uncertainty and limitation labeling;
11. synthetic substitution;
12. protected knowledge exclusion;
13. public authority boundary language;
14. finance and insurance boundary language;
15. consent boundary language;
16. no-warning, no-procurement, no-certification, no-deployment, and no-execution notices.

A Public-Safe Transformation Record should identify source data, transformation method, target audience, release class, residual risk, reviewer class, fields removed or modified, limitations, permitted outputs, prohibited outputs, public-safe status, correction pathway, withdrawal pathway, recall pathway, and archive rule.

Public-safe transformation does not make all underlying data open. It creates a specific transformed object for a defined use. If the source data is corrected, rights change, linkage risk changes, public authority context changes, or safeguard concerns arise, the transformed output may require correction, restriction, withdrawal, recall, or archive.

### 10.3.11 Repository Routing

Repository routing determines where a data object, metadata-only record, data dictionary, codebook, schema, processed dataset, public-safe dataset, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, or handoff data package should be stored, mirrored, accessed, versioned, corrected, and archived.

Repository routing may direct data to:

1. open public repository;
2. controlled Nexus repository;
3. restricted repository;
4. National Node repository;
5. sovereign data repository;
6. secure-room repository;
7. data-room repository;
8. clean-room environment;
9. compute-to-data environment;
10. protected knowledge repository;
11. public authority learning repository;
12. Studio repository;
13. Reports repository;
14. Academy repository;
15. Registry metadata repository;
16. Marketplace metadata record;
17. handoff-recipient repository;
18. archive repository;
19. sealed or non-public storage;
20. deletion or non-continuation pathway.

Repository routing should follow rights review, sensitivity review, data-use labeling, AI-use labeling, and jurisdictional context. Repository convenience must not override data sovereignty, privacy, cyber, protected knowledge, community, Indigenous protocol where applicable, public authority, legal, or public-safe controls.

A Repository Routing Record should identify selected repository, rationale, access class, data-use limits, AI-use limits, cross-border conditions, mirroring conditions, retention conditions, correction and recall pathway, and archive rule.

Repository placement is not permission. A dataset in a repository remains governed by its labels and records.

### 10.3.12 DICE Routing

DICE routing determines how a data object moves through the data, innovation, commons, and evidence governance layer. It connects data lifecycle state to the correct DICE pathway: rights review, sensitivity review, metadata creation, public-safe transformation, data commons inclusion, Studio routing, Reports routing, Academy routing, Observatory routing, DRI routing, GRIx routing, Grid routing, Marketplace routing, Registry routing, National Portfolio routing, Nexus Universe routing, handoff routing, correction routing, or archive routing.

DICE routing should identify:

1. whether the object may enter a Data Commons and under what access class;
2. whether only metadata may be discoverable;
3. whether public-safe transformation is required;
4. whether secure-room, data-room, clean-room, or compute-to-data handling is required;
5. whether the object may be used for AI and under what label;
6. whether the object may support Reports, Academy, Studio, Campaigns, Foundry, Grid, Registry, Marketplace, National Portfolios, Nexus Universe, or handoff packages;
7. whether the object must be restricted, sealed, deleted, archived, or marked non-continuing;
8. what correction propagation rules apply.

DICE routing is the governance bridge between data availability and data use. It prevents data from moving because it is technically easy rather than because it is lawful, safe, and appropriate.

DICE routing does not approve external action. It routes data through Nexus public-good pathways while preserving rights, restrictions, and no-conversion boundaries.

### 10.3.13 Registry Record

A Registry Record for data records the data object’s identity, lifecycle state, access class, data-use label, AI-use label, rights status, sensitivity class, public-safe status, source review, rights review, quality assessment, lineage, support status, repository routing, Marketplace relationship, Studio relationship, Reports relationship, Grid relationship, National Portfolio relationship, Nexus Universe relationship, handoff relationship, correction history, and archive state.

A Data Registry Record should identify:

1. data object identifier;
2. title and description;
3. source pathway;
4. steward;
5. data class;
6. version;
7. jurisdictional context;
8. access class;
9. data-use label;
10. AI-use label;
11. rights review status;
12. sensitivity review status;
13. quality assessment status;
14. public-safe transformation status;
15. repository location or metadata-only location;
16. support and update status;
17. linked objects;
18. correction, withdrawal, recall, supersession, archive, and non-continuation status.

Registry recording creates status truth. It does not make the data open, accurate for all purposes, AI-trainable, certified, public-authority-approved, financeable, insurable, consented, deployable, or executable. It states what the data’s current Nexus status is and what boundaries apply.

### 10.3.14 Marketplace Listing

Marketplace listing for data allows a data object, metadata-only record, public-safe dataset, data dictionary, codebook, schema, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, or handoff data context to become discoverable under Marketplace governance.

A data Marketplace listing should identify:

1. listed object identity and version;
2. Registry status;
3. data class;
4. steward;
5. access class;
6. data-use label;
7. AI-use label;
8. sensitivity class;
9. license or rights summary;
10. public-safe status;
11. quality assessment summary;
12. update and support status;
13. allowed discovery pathway;
14. access request pathway where applicable;
15. prohibited uses;
16. correction and delisting pathway.

Marketplace listing may be public, controlled, metadata-only, National Node-only, public-authority-learning-only, secure-room-aware, data-room-aware, handoff-awareness-only, or archive-listed. A listing should not expose sensitive metadata where metadata itself is restricted.

Marketplace listing is discovery, not permission. A data listing is not a license to download, reuse, train AI, publish, combine, commercialize, hand off, or deploy. It is not procurement, certification, finance, insurance, public authority action, consent, or execution.

### 10.3.15 Correction

Correction is the data lifecycle process for addressing errors, rights issues, sensitivity issues, quality defects, lineage gaps, metadata errors, data-use label errors, AI-use label errors, public-safe transformation errors, repository routing errors, Registry errors, Marketplace listing errors, Studio workflow errors, Reports errors, Academy errors, Campaign errors, Grid errors, National Portfolio errors, Nexus Universe errors, or handoff package errors affecting a data object.

Data correction may include:

1. metadata correction;
2. source correction;
3. rights correction;
4. sensitivity reclassification;
5. data-use label correction;
6. AI-use label correction;
7. quality correction;
8. lineage correction;
9. transformation correction;
10. public-safe output correction;
11. repository access correction;
12. Registry status correction;
13. Marketplace delisting or listing correction;
14. Studio workflow correction;
15. Reports correction;
16. Grid or TRL correction;
17. National Portfolio correction;
18. Nexus Universe correction;
19. handoff package correction;
20. withdrawal, recall, sealing, deletion where required, archive, or non-continuation.

A Data Correction Record should identify affected data object, affected derived objects, prior state, corrected state, trigger, severity, rights implications, sensitivity implications, public-safe implications, AI-use implications, affected repositories, affected users, affected rooms, affected handoff recipients, notification duties, public repair needs, and archive treatment.

Data correction must propagate. If source data changes, dashboards, reports, models, feature sets, DRI indicators, Observatory outputs, Studio workflows, Grid records, Marketplace listings, Registry records, National Portfolio objects, Nexus Universe outputs, and handoff packages may all require review. Correction is the mechanism that prevents old data meaning from persisting after truth changes.

### 10.3.16 Archive

Archive is the data lifecycle process through which a data object or data-derived object is preserved, restricted, sealed, deleted where required, superseded, withdrawn, recalled, marked non-current, or marked non-continuing after it is no longer active for its prior Nexus purpose.

A data object may be archived because:

1. the data is superseded by a newer version;
2. rights expire or are withdrawn;
3. consent is withdrawn where applicable;
4. public-safe status changes;
5. sensitivity increases;
6. data quality is no longer sufficient;
7. source is corrected or discredited;
8. support or update cadence ends;
9. repository routing changes;
10. AI-use conditions change;
11. public authority context changes;
12. community or Indigenous protocol concern arises where applicable;
13. protected knowledge restrictions require sealing;
14. cyber or privacy risk requires restriction;
15. handoff package is completed, recalled, or non-continuing;
16. Nexus Universe or National Portfolio cycle closes;
17. legal deletion, sealing, or retention rule applies.

A Data Archive Record should identify archived data object, prior lifecycle state, archive date, archive steward, archive reason, access class after archive, use restrictions, citation restrictions, data-use restrictions, AI-use restrictions, deletion or sealing requirement, successor object where applicable, affected derived objects, handoff-recipient notice where required, correction history, and non-current authority notice.

Archive preserves memory without current authority. Archived data is not current, not automatically reusable, not AI-trainable, not public-safe beyond its archive rule, not handoff-ready, not financeable, not insurable, not public-authority-approved, not consented for new use, not deployment-authorized, and not executable.

The final Data Lifecycle rule is: data moves from signal to intake, source review, rights review, sensitivity review, labeling, lineage, quality assessment, public-safe transformation, repository routing, DICE routing, Registry status, Marketplace discovery, correction, and archive only by record; data availability never equals unrestricted rights; data access never equals AI-use permission; data lifecycle state never creates certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 10.4 Data Classes

### 10.4.1 Open Data

Open data is data that may be accessed, used, reused, copied, shared, cited, analyzed, taught, displayed, transformed, and redistributed under a recorded open license or public-use condition, subject to the object’s metadata, attribution duties, data-use label, AI-use label, public-safe status, quality limitations, jurisdictional context, correction pathway, and archive rule.

Open data within Nexus is not simply data that can be found online. It must have sufficient rights clarity, source review, sensitivity review, public-safe review where needed, metadata, lineage, quality context, and license or terms to support open use within the recorded scope. Data that is publicly visible but legally restricted, technically scraped without permission, privacy-sensitive, geospatially risky, public authority-sensitive, protected-knowledge-sensitive, or unclear in licensing should not be treated as open merely because it is accessible.

An Open Data Record should identify:

1. source and steward;
2. license or terms of use;
3. permitted uses, including viewing, downloading, copying, transforming, teaching, reporting, redistribution, or other uses;
4. prohibited or conditional uses, including AI training, commercial reuse, cross-border transfer, high-resolution geospatial display, or combination with sensitive data where applicable;
5. metadata and lineage;
6. quality, uncertainty, and limitation notes;
7. public-safe status;
8. correction, withdrawal, supersession, and archive pathway.

Open data does not create public authority action, certification, procurement status, financeability, insurability, consent, deployment authorization, or execution authority. Open data may be usable; it is not automatically authoritative for every use.

### 10.4.2 Public-Safe Data

Public-safe data is data or data-derived material that may be communicated, displayed, taught, published, summarized, visualized, or listed for a defined audience without creating unacceptable risk of harm, privacy exposure, public authority confusion, protected knowledge exposure, community harm, Indigenous protocol breach where applicable, cybersecurity risk, geospatial risk, finance or insurance overclaim, procurement implication, consent overclaim, or execution overclaim.

Public-safe data may be produced from open, controlled, restricted, raw, processed, aggregated, synthetic, or metadata-only sources. Its status depends on transformation and review, not on source convenience. Public-safe data may include generalized maps, aggregated indicators, masked tables, public-safe dashboards, DRI summaries, Observatory summaries, National Portfolio summaries, Reports figures, Academy datasets, Campaign metrics, Marketplace descriptions, Registry public views, Nexus Universe materials, and handoff-safe summaries.

A Public-Safe Data Record should identify:

1. source data class;
2. transformation method;
3. audience and release class;
4. fields removed, masked, aggregated, generalized, or redacted;
5. remaining limitations and uncertainty;
6. public-safe reviewer or pathway;
7. required no-conversion language;
8. correction, withdrawal, recall, and archive pathway.

Public-safe data is not automatically open data. It may be public-safe only for a specific release, context, audience, summary, room, dashboard, report, or learning object. Public-safe status does not make the data a public warning, public authority decision, certification, procurement recommendation, finance signal, insurance rating, consent record, deployment authorization, or execution instruction.

### 10.4.3 Controlled Public Data

Controlled public data is data that may have some public origin, public relevance, public-facing purpose, or public-safe derivative form but still requires controls for access, reuse, aggregation, display, AI use, republication, combination, localization, geospatial resolution, public authority interpretation, community safeguarding, or handoff. Controlled public data recognizes that public availability and unrestricted use are not the same thing.

Controlled public data may include:

1. public datasets subject to restrictive terms of use;
2. public authority datasets requiring contextual interpretation;
3. public maps requiring geospatial generalization;
4. public reports converted into structured data;
5. public-facing dashboards with limited download rights;
6. public social, media, or web data with privacy and ethics risks;
7. public-safe data that may be displayed but not reused freely;
8. public data that becomes sensitive when linked, aggregated, or AI-processed.

A Controlled Public Data Record should identify:

1. public source and terms;
2. what public access exists;
3. what reuse remains controlled;
4. whether AI use is permitted, restricted, or prohibited;
5. whether aggregation, linkage, republication, or geospatial display is restricted;
6. public-safe language requirements;
7. review, correction, and archive pathway.

Controlled public data should not be treated as open data merely because it is visible. It may support learning, Reports, Studio, DRI, Observatory, Academy, Campaigns, Marketplace metadata, Registry status, National Portfolios, Nexus Universe outputs, or handoff context only within recorded limits.

### 10.4.4 Restricted Data

Restricted data is data that requires heightened controls because access, disclosure, processing, aggregation, AI use, publication, visualization, transfer, handoff, or archive could create legal, privacy, cybersecurity, public authority, community, Indigenous protocol, protected knowledge, health, youth, geospatial, infrastructure, financial, insurance, procurement, security, or safety risk.

Restricted data may include personal data, health-sensitive data, youth data, protected knowledge, Indigenous protocol-sensitive data where applicable, community-sensitive data, geospatial-sensitive data, cyber-sensitive data, infrastructure-sensitive data, public authority-sensitive data, sovereign-sensitive data, confidential provider data, confidential sponsor-related data, handoff-recipient-only data, legal-sensitive data, dual-use-sensitive data, and data subject to deletion, sealing, or non-disclosure obligations.

A Restricted Data Record should identify:

1. restriction basis;
2. approved users and roles;
3. approved purposes;
4. prohibited uses;
5. storage and repository requirements;
6. secure-room, data-room, clean-room, or compute-to-data requirements;
7. download, export, cross-border transfer, publication, AI-use, and linkage restrictions;
8. logging, monitoring, retention, deletion, sealing, correction, recall, and archive requirements.

Restricted data may still support public-good work where controls allow. It may produce public-safe derivatives, metadata-only records, learning substitutes, synthetic datasets, aggregate summaries, or handoff-context notes. Restriction does not mean uselessness; it means use must be governed.

### 10.4.5 Public Authority-Sensitive Data

Public authority-sensitive data is data connected to public authorities, public-sector functions, regulatory processes, public finance, emergency management, public services, public infrastructure, administrative records, public utilities, public procurement, enforcement, permits, licenses, public warnings, crisis operations, policy development, or governmental decision-making in a manner that requires special controls.

Public authority-sensitive data may include draft public-sector materials, non-public administrative datasets, public finance data, emergency management information, regulator-facing materials, public utility data, public procurement-sensitive data, infrastructure operations data, public authority learning room materials, official records under restricted use, or data whose public release could be mistaken for official action.

A Public Authority-Sensitive Data Record should identify:

1. public authority relationship;
2. whether the data is official, draft, learning-only, non-decision, confidential, public, or restricted;
3. public authority permissions and restrictions;
4. public-safe language requirements;
5. no-public-authority-action notices;
6. procurement, public finance, emergency, regulatory, or policy boundary conditions;
7. access, publication, AI-use, cross-border transfer, handoff, correction, and archive controls.

Public authority-sensitive data must not be used to imply government approval, public warning, emergency command, regulatory classification, procurement decision, public finance allocation, policy adoption, compliance determination, or public authority endorsement unless a competent public authority separately records that action through its own lawful process.

### 10.4.6 Community-Sensitive Data

Community-sensitive data is data relating to communities, local institutions, affected populations, place-based conditions, vulnerability, resilience, lived-risk knowledge, local infrastructure, access needs, cultural practices, social conditions, humanitarian context, local environmental conditions, local harm, or community participation in a way that could expose people, stigmatize communities, enable extraction, distort local meaning, create safety risks, or imply consent where no consent exists.

Community-sensitive data may arise through consultations, Campaigns, public-safe reporting, community safeguard rooms, National Portfolios, Observatory signals, DRI workflows, Studio workflows, Academy pathways, Reports, Nexus Universe sessions, public authority learning, or handoff preparation.

A Community-Sensitive Data Record should identify:

1. community context and source pathway;
2. participation basis and consent boundary;
3. permitted uses and prohibited uses;
4. public-safe transformation requirements;
5. privacy, dignity, non-extraction, accessibility, language, and safeguarding requirements;
6. whether community review or contextual validation is required before release;
7. AI-use restrictions;
8. handoff and publication restrictions;
9. correction, withdrawal, public repair, and archive pathway.

Community participation is not consent. Community-sensitive data must not be used to authorize implementation, public authority action, procurement, finance, insurance, deployment, or execution. It may inform learning and context only under recorded safeguards.

### 10.4.7 Indigenous Protocol-Sensitive Data Where Applicable

Indigenous protocol-sensitive data is data relating to Indigenous peoples, Nations, communities, lands, waters, territories, cultural heritage, ecological knowledge, traditional knowledge, language, identity, governance, rights, histories, sacred sites, cultural practices, biodiversity knowledge, climate and nature knowledge, health, youth, community conditions, or protected knowledge where Indigenous protocols, laws, governance, custodianship, consent, data sovereignty, or knowledge protection may apply.

Where applicable, Indigenous protocol-sensitive data must be governed through the appropriate Indigenous governance context and not merely through ordinary data-access controls. It may require restrictions on collection, storage, interpretation, publication, mapping, AI use, translation, transfer, commercialization, handoff, archive, deletion, or return.

An Indigenous Protocol-Sensitive Data Record should identify, where lawful and appropriate:

1. Indigenous context and relevant governance pathway;
2. custodian, steward, or authority relationship;
3. protocol, consent, access, use, and publication conditions;
4. protected knowledge restrictions;
5. data sovereignty and localization requirements;
6. AI-use prohibitions or conditions;
7. mapping, geospatial, ecological, cultural, and language safeguards;
8. community review or approval requirements where applicable;
9. handoff restrictions;
10. correction, withdrawal, deletion, return, sealing, public repair, and archive pathway.

Indigenous participation is not rights waiver. Discussion is not permission. Metadata is not unrestricted disclosure. Public-good purpose does not override Indigenous governance, custodianship, consent, protected knowledge, or data sovereignty. Where uncertainty exists, the most protective treatment should apply until proper governance is recorded.

### 10.4.8 Protected Knowledge

Protected knowledge is knowledge, data, metadata, context, practice, location, method, story, cultural material, ecological insight, community-held information, Indigenous knowledge where applicable, sensitive environmental knowledge, local resilience knowledge, humanitarian context, security-relevant information, or other knowledge that requires protection against exposure, extraction, misuse, commodification, AI ingestion, inappropriate publication, geospatial disclosure, or unauthorized handoff.

Protected knowledge may appear in text, maps, interviews, datasets, reports, images, recordings, metadata, dashboards, digital twins, simulations, models, Academy materials, Campaign materials, Observatory records, DRI datasets, National Portfolio records, Nexus Universe outputs, or handoff packages.

A Protected Knowledge Record should identify:

1. knowledge class and protection basis;
2. steward, custodian, or governance pathway;
3. permitted uses and prohibited uses;
4. access class and room requirements;
5. public-safe transformation requirements;
6. AI-use restrictions, including default exclusion from AI training unless expressly permitted;
7. publication, translation, mapping, commercialization, and handoff restrictions;
8. correction, withdrawal, deletion, sealing, return, archive, and public repair pathway.

Protected knowledge should be excluded from open release, public dashboards, public maps, public reports, Marketplace listings, AI training, unrestricted Academy use, and handoff packages unless specific authority and controls exist. Protection is not an obstacle to public good; it is a condition of legitimacy.

### 10.4.9 Youth Data

Youth data is data relating to children, minors, students, youth participants, youth organizations, school or training contexts, youth learning records, youth Campaign participation, youth volunteer activity, youth WILP participation, youth location, youth health, youth identity, youth communications, or youth contribution records.

Youth data requires heightened safeguards because youth participants may have reduced legal capacity, heightened vulnerability, special privacy protections, educational protections, safeguarding requirements, consent requirements, guardian involvement requirements, and public display risks.

A Youth Data Record should identify:

1. youth data class and age-related context where lawful and appropriate;
2. lawful basis, consent, guardian, institutional, educational, or safeguarding requirement;
3. access restrictions;
4. public display restrictions;
5. learning record restrictions;
6. AI-use restrictions;
7. communications and contact restrictions;
8. retention, deletion, correction, withdrawal, and archive requirements;
9. safeguarding escalation pathway.

Youth data should not be displayed publicly, used in open datasets, used for AI training, included in public dashboards, transferred to handoff recipients, or used in Campaign visibility without specific recorded authority and safeguards. Recognition of youth contribution must be balanced against privacy and safety.

Youth participation supports capability formation; it does not create unrestricted data rights or consent for future use.

### 10.4.10 Health-Sensitive Data

Health-sensitive data is data relating to health status, healthcare access, health systems, disease, disability, mental health, public health, health facilities, health workers, health service capacity, health infrastructure, clinical information, population health indicators, humanitarian health conditions, emergency health response, or health-related vulnerability.

Health-sensitive data may support WFEH-B analysis, DRI indicators, Observatory signals, public authority learning, Studio simulations, Reports, National Portfolios, Nexus Universe outputs, Academy learning, Campaigns, finance-readiness questions, insurance-readiness questions, or lawful handoff context. It requires strict governance because misuse can harm individuals, communities, facilities, public health systems, and public trust.

A Health-Sensitive Data Record should identify:

1. health data type and source;
2. privacy, consent, ethics, institutional, legal, and public health restrictions;
3. aggregation, de-identification, masking, and public-safe transformation requirements;
4. AI-use restrictions;
5. public authority boundary conditions;
6. geospatial and facility-level sensitivity;
7. access, cross-border transfer, retention, deletion, correction, and archive rules;
8. handoff restrictions.

Health-sensitive data must not be used to issue public warnings, clinical advice, public authority decisions, insurance decisions, procurement decisions, deployment authorization, or execution through Nexus default pathways. It may support learning, analysis, public-safe summaries, and handoff context only within recorded restrictions.

### 10.4.11 Cyber-Sensitive Data

Cyber-sensitive data is data that could expose vulnerabilities, attack paths, system configurations, credentials, security posture, incident details, network architecture, logs, telemetry, threat indicators, exploit information, access controls, software weaknesses, infrastructure dependencies, or operational security risks.

Cyber-sensitive data may arise from software reviews, repositories, dependency scans, secret scans, SBOM records, vulnerability disclosures, incident reports, secure-room workflows, Observatory telemetry, infrastructure monitoring, Studio workflows, data-room materials, public authority learning contexts, provider contributions, National Portfolio records, Nexus Universe technical arenas, or handoff packages.

A Cyber-Sensitive Data Record should identify:

1. cyber data class;
2. affected systems or object classes;
3. sensitivity and exploitability risk;
4. approved users and rooms;
5. publication restrictions and embargo rules;
6. AI-use restrictions;
7. logging, storage, encryption, and access controls;
8. incident, vulnerability disclosure, correction, recall, and archive pathway;
9. handoff-recipient notification requirements where applicable.

Cyber-sensitive data should not be published, mapped, listed, or included in public-safe summaries in a way that enables attack or exposes vulnerable systems. Public-safe cyber reporting may be possible, but exploit-sensitive details must remain controlled. Cyber data is not public authority warning, security certification, insurance approval, procurement status, deployment authorization, or execution authority.

### 10.4.12 Infrastructure-Sensitive Data

Infrastructure-sensitive data is data relating to critical infrastructure, essential services, facilities, networks, utilities, telecom systems, AI-RAN/O-RAN/private wireless systems, energy systems, water systems, food systems, health systems, transport systems, ports, logistics, cyber-physical systems, data centers, cloud or compute infrastructure, emergency systems, public buildings, industrial systems, or other assets whose exposure could create security, safety, operational, public authority, or exploitation risk.

Infrastructure-sensitive data may include asset locations, capacities, dependencies, vulnerabilities, degraded-mode status, maintenance conditions, outage patterns, network topology, geospatial layers, operational constraints, resilience gaps, or handoff dependencies.

An Infrastructure-Sensitive Data Record should identify:

1. infrastructure class;
2. geographic and operational sensitivity;
3. public authority or operator relationship;
4. access and room requirements;
5. aggregation, masking, and geospatial generalization rules;
6. AI-use restrictions;
7. public-safe summary rules;
8. handoff restrictions;
9. correction, incident, recall, and archive pathway.

Infrastructure-sensitive data can support resilience learning and readiness, but uncontrolled exposure can create harm. It must not be used to issue emergency commands, public warnings, operational instructions, procurement decisions, finance or insurance determinations, deployment authorizations, or execution actions through Nexus default pathways.

### 10.4.13 Geospatial-Sensitive Data

Geospatial-sensitive data is data whose location, spatial resolution, mapping, coordinates, boundaries, layers, imagery, routes, proximity, or spatial relationships may create privacy, security, community, Indigenous protocol, protected knowledge, ecological, infrastructure, public authority, humanitarian, or exploitation risk.

Geospatial-sensitive data may include precise locations of vulnerable populations, protected sites, sacred sites, Indigenous lands or knowledge contexts where applicable, health facilities, shelters, critical infrastructure, biodiversity resources, water sources, supply chains, cyber-physical assets, degraded-mode systems, hazard exposure, or security-sensitive facilities.

A Geospatial-Sensitive Data Record should identify:

1. location sensitivity basis;
2. resolution and accuracy;
3. permitted display scale;
4. masking, aggregation, displacement, redaction, or generalization rules;
5. public-safe mapping requirements;
6. AI-use and geospatial inference restrictions;
7. community, Indigenous protocol where applicable, protected knowledge, ecological, and public authority safeguards;
8. publication, Marketplace, Registry, Studio, Reports, Nexus Universe, and handoff restrictions;
9. correction, withdrawal, recall, and archive pathway.

A map is not harmless because it is visual. Geospatial precision can expose people, places, systems, and knowledge. Geospatial-sensitive data must not be treated as open merely because satellite imagery, maps, or coordinates are technically accessible. Public-safe geospatial outputs should generalize enough to inform without exposing.

### 10.4.14 Handoff-Recipient-Only Data

Handoff-recipient-only data is data that may be transferred or made available only to a recorded lawful recipient under a Handoff Record, recipient responsibility notice, access terms, data-use label, AI-use label, correction pathway, recall pathway, and archive rule. It is not generally available within Nexus and is not available to the public, ordinary participants, Marketplace users, or unrelated Nexus pathways.

Handoff-recipient-only data may include technical packages, datasets, dependency records, secure-room exports, data-room materials, public authority dependency notes, provider materials, operator materials, finance-readiness materials, insurance-readiness materials, safeguard records, consent boundary records, National Portfolio context, Nexus Universe continuation materials, or Project SPV and National Consortium Company context.

A Handoff-Recipient-Only Data Record should identify:

1. recipient identity or recipient class;
2. handoff purpose;
3. included data objects and versions;
4. recipient permissions and restrictions;
5. data-use and AI-use limits;
6. confidentiality, security, privacy, sovereignty, protected knowledge, community, and Indigenous protocol restrictions where applicable;
7. public authority, procurement, finance, insurance, consent, deployment, and execution boundary notices;
8. correction, recall, notification, return, deletion, archive, and non-continuation rules.

Handoff-recipient-only data transfers context, not authority. Receipt of data does not approve the recipient, authorize deployment, transfer consent, create procurement, create finance, create insurance, certify an object, or execute a project. The recipient must decide and act under its own lawful authority.

### 10.4.15 Archive-Only Data

Archive-only data is data preserved for institutional memory, evidence history, correction history, audit, accountability, research history, lifecycle continuity, or legal retention, but not available for current use except under its archive rule. Archive-only data may be superseded, withdrawn, recalled, support-expired, rights-expired, non-continuing, restricted, sealed, or no longer public-safe for active use.

Archive-only data may include prior dataset versions, withdrawn reports data, recalled handoff data, deprecated benchmark datasets, obsolete DRI datasets, old Observatory feeds, closed National Portfolio datasets, Nexus Universe cycle data, Campaign metrics, Studio output data, Grid and TRL records, and correction records.

An Archive-Only Data Record should identify:

1. prior lifecycle state;
2. archive reason;
3. archive date and steward;
4. access class after archive;
5. permitted historical uses;
6. prohibited current uses;
7. citation restrictions;
8. data-use and AI-use restrictions;
9. privacy, cyber, protected knowledge, community, Indigenous protocol where applicable, geospatial, public authority, legal, and security controls;
10. successor data object where applicable;
11. deletion, sealing, return, correction, or recall requirements.

Archive-only data must not be treated as current, open, AI-trainable, public-safe, handoff-ready, finance-relevant, insurance-relevant, public-authority-approved, consented, deployment-authorized, or executable. It preserves memory without current power.

The final Data Classes rule is: open data requires rights clarity; public-safe data requires review; controlled public data remains bounded; restricted data requires heightened controls; public authority, community, Indigenous protocol, protected knowledge, youth, health, cyber, infrastructure, and geospatial data require special safeguards; handoff-recipient-only data travels only by record; archive-only data preserves memory without current authority; no data class creates certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 10.5 Data Governance Controls

### 10.5.1 Data Minimization

Data minimization is the DICE control requiring Nexus data work to use only the data necessary for the recorded purpose, pathway, review, public-safe output, learning object, Studio workflow, DRI indicator, Observatory signal, Grid or TRL input, Report, Campaign, Marketplace listing, Registry record, National Portfolio object, Nexus Universe output, or lawful handoff context.

Data minimization applies at every stage of the data lifecycle. It governs collection, intake, storage, processing, linkage, AI use, dashboard display, geospatial resolution, publication, teaching, handoff, correction, and archive. The control prevents Nexus from accumulating excessive data merely because it may be useful later, technically easy to collect, attractive for AI use, convenient for dashboards, or helpful for future funding, procurement, insurance, or public authority conversations.

A Data Minimization Record or equivalent metadata field should identify:

1. minimum necessary data, including the fields, records, geography, time period, resolution, population, system layer, or metadata needed for the recorded purpose;
2. excluded data, including personal data, youth data, health-sensitive data, protected knowledge, Indigenous protocol-sensitive data where applicable, precise geospatial data, cyber-sensitive data, infrastructure-sensitive data, public authority-sensitive data, or raw data not required for the purpose;
3. substitute data, including aggregated, masked, synthetic, public-safe, metadata-only, or compute-to-data alternatives where they can meet the purpose with less exposure;
4. collection limit, including a rule against collecting additional fields or source materials without renewed review;
5. retention and archive effect, including whether minimized data can be deleted, sealed, restricted, or archived after the purpose is complete.

Data minimization does not weaken Nexus intelligence. It strengthens it by reducing unnecessary risk, improving purpose discipline, making public-safe release easier, and preserving trust. Nexus should prefer the least intrusive, least sensitive, least extractive, and most public-safe data form that can support the recorded Nexus purpose.

Data minimization does not authorize use. It limits use. A minimized dataset still requires rights review, sensitivity review, data-use labeling, AI-use labeling, access control, correction, and archive discipline.

### 10.5.2 Purpose Limitation

Purpose limitation is the DICE control requiring every data object to be used only for the purpose recorded in its metadata, Data-Use Label, AI-Use Label, Docket, repository record, DICE record, Studio workflow, Reports pathway, Academy pathway, Campaign pathway, Grid pathway, Registry record, Marketplace listing, National Portfolio record, Nexus Universe record, or Handoff Record.

Purpose limitation prevents data collected or received for one context from being silently repurposed for another. Data used for public authority learning should not become procurement material by implication. Data used for Academy learning should not become AI-training data by implication. Data used for a Studio demonstration should not become deployment input by implication. Data used in a National Portfolio should not become government approval by implication. Data provided by a community should not become implementation consent by implication. Indigenous protocol-sensitive data where applicable should not become publishable, AI-trainable, or handoff-transferable by implication.

A Purpose Limitation Record should identify:

1. approved purpose, including learning, evidence, observability, DRI, GRIx, DICE, Studio, Reports, Academy, Campaign, Foundry, Grid, Registry, Marketplace, National Portfolio, Nexus Universe, public authority learning, finance-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, handoff context, correction, or archive;
2. prohibited purposes, including public authority action, procurement, finance execution, insurance underwriting, donor allocation, AI training, commercial reuse, public warning, deployment, operational command, or execution unless separately authorized;
3. purpose-change pathway, including the review, permission, consent, public-safe, rights, and correction steps required before a new use may occur;
4. downstream propagation, ensuring that all derived objects carry the original purpose limits unless lawfully changed.

Purpose limitation means that lawful access is not a blank check. A data object may be valid for one use and prohibited for another. The same dataset may support a public-safe Report but not an AI model; a Studio workflow but not a public dashboard; a handoff package but not Marketplace discovery.

### 10.5.3 Consent and Permission

Consent and permission are DICE controls requiring the appropriate legal, contractual, institutional, community, Indigenous protocol where applicable, data subject, custodian, steward, public authority, or rights-holder basis before data is collected, accessed, used, transformed, displayed, published, transferred, AI-processed, handed off, archived, sealed, deleted, or reused.

Consent and permission are not interchangeable. A license may permit software or data reuse but not community disclosure. A public authority may permit learning use but not public release. A community participant may share context without consenting to implementation. An Indigenous institution where applicable may allow discussion under protocol without permitting publication, mapping, AI ingestion, commercialization, handoff, or archive. A data subject may consent to one use but not another. A provider may contribute data under terms that do not validate the provider. A sponsor may support a dataset without controlling its interpretation.

A Consent and Permission Record should identify:

1. basis of permission, including consent, license, contract, public authority permission, research approval, data-sharing agreement, community process, Indigenous governance process where applicable, data steward authorization, or lawful public source;
2. scope, including permitted data, permitted users, permitted purposes, permitted duration, permitted geography, permitted publication, permitted AI use, permitted handoff, and permitted archive;
3. limits, including prohibited publication, prohibited AI training, prohibited geospatial display, prohibited combination, prohibited cross-border transfer, prohibited commercial use, prohibited handoff, or prohibited public-safe summary where applicable;
4. withdrawal or change process, including how permission may be withdrawn, narrowed, corrected, superseded, or archived;
5. record propagation, ensuring that downstream objects carry the permission limits.

Consent is not created by participation unless the applicable process lawfully and specifically records it. Permission is not created by access unless the permission instrument says so. Nexus must treat consent and permission as specific, recorded, revocable or time-bound where applicable, and separate from visibility, contribution, attendance, signature, support, public authority presence, or handoff discussion.

### 10.5.4 Access Control

Access control is the DICE control that governs who may view, query, download, process, transform, publish, teach, display, map, model, AI-process, list, register, hand off, correct, archive, delete, seal, or administer a data object.

Access control should be role-based, purpose-based, need-to-know, least-privilege, time-bounded where appropriate, and tied to the data object’s access class, sensitivity class, data-use label, AI-use label, jurisdictional context, public-safe status, support class, correction pathway, and archive rule.

Access control may include:

1. role controls, including steward, maintainer, reviewer, learner, public authority learner, National Node participant, Working Group member, Competence Cell member, Studio participant, Reports contributor, Marketplace administrator, Registry administrator, Grid reviewer, Nexus Universe participant, handoff recipient, or archive custodian;
2. room controls, including secure room, data room, clean room, protected knowledge room, public authority learning room, AI review room, cyber review room, community safeguard room, media-safe room, readiness room, or handoff room;
3. technical controls, including authentication, authorization, least privilege, logging, monitoring, encryption, key management, no-download controls, no-copy controls, no-export controls, output review, watermarking, access expiry, revocation, and incident detection;
4. administrative controls, including approval workflow, access register, conflict disclosure, confidentiality terms, training requirements, access review cadence, and access termination.

Access does not create ownership, reuse rights, AI-use rights, publication rights, procurement rights, finance rights, insurance rights, public authority rights, consent rights, deployment rights, or execution rights. Access control governs entry; use remains governed by the data object’s recorded purpose and labels.

### 10.5.5 Cross-Border Controls

Cross-border controls are DICE controls governing whether data, metadata, derived objects, AI inputs, AI outputs, reports, dashboards, Studio workflows, repositories, Marketplace listings, Registry records, National Portfolio objects, Nexus Universe outputs, handoff packages, backups, logs, or archives may move across national borders, regional boundaries, cloud regions, institutional jurisdictions, public authority contexts, data sovereignty zones, or handoff-recipient jurisdictions.

Cross-border controls are required because data movement can change legal obligations, privacy risk, public authority sensitivity, Indigenous protocol obligations where applicable, protected knowledge exposure, cyber risk, procurement sensitivity, finance or insurance context, and public-safe meaning.

A Cross-Border Control Record should identify:

1. source jurisdiction and destination jurisdiction;
2. data class and sensitivity class;
3. legal basis for transfer;
4. data sovereignty and localization conditions;
5. public authority restrictions;
6. community and Indigenous protocol restrictions where applicable;
7. protected knowledge restrictions;
8. AI-use and cloud-region restrictions;
9. security controls, including encryption, access control, logging, transfer method, key management, and recipient obligations;
10. permitted transfer form, including raw data, processed data, public-safe data, metadata-only record, aggregated data, synthetic data, secure-room output, data-room package, compute-to-data output, or handoff-recipient-only package;
11. correction, recall, deletion, sealing, and archive obligations.

Where cross-border legality or safety is uncertain, data should remain in the more restrictive location, use compute-to-data where possible, or be transformed into public-safe or metadata-only outputs. Cross-border transfer does not create authority. It is a controlled movement of data under conditions, not permission for downstream action.

### 10.5.6 Data Sovereignty

Data sovereignty is the DICE control recognizing that data may be subject to the laws, governance, rights, institutional authority, community authority, Indigenous governance where applicable, public authority context, national interest, public-sector mandate, or stewardship expectations of the jurisdiction, community, institution, or rights holder from which it arises or to which it relates.

Data sovereignty in Nexus applies especially to National Portfolio datasets, National Node repositories, public authority-sensitive data, health-sensitive data, youth data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, geospatial-sensitive data, infrastructure-sensitive data, cyber-sensitive data, Observatory datasets, DRI datasets, and handoff-recipient-only data.

A Data Sovereignty Record should identify:

1. sovereignty context, including country, region, National Node, public authority, community, Indigenous governance pathway where applicable, data steward, or custodian;
2. required storage or processing location;
3. access limitations;
4. cross-border restrictions;
5. local review requirements;
6. language, localization, and public-safe requirements;
7. public authority learning boundaries;
8. handoff-recipient obligations;
9. correction, deletion, return, sealing, archive, and non-continuation rules.

Data sovereignty does not mean every dataset is owned by a state or that no data may move. It means data movement and use must respect the authority, rights, duties, and safeguards attached to the data’s context. Nexus should preserve national ownership before local delivery and should not let global, regional, sponsor, provider, capital, donor, or enterprise convenience override lawful data sovereignty conditions.

### 10.5.7 Data Localization

Data localization is the DICE control requiring certain data, metadata, repositories, mirrors, processing environments, backups, logs, AI workflows, Studio workflows, National Portfolio objects, public authority learning objects, or handoff packages to remain, be mirrored, be processed, or be governed within a specified country, region, National Node, sovereign data zone, institutional environment, secure room, data room, clean room, or compute-to-data environment.

Data localization may be required by law, public authority condition, data-sharing agreement, consent condition, community safeguard, Indigenous protocol where applicable, protected knowledge control, health data condition, cyber condition, infrastructure condition, cloud-region requirement, National Node rule, or handoff-recipient obligation.

A Data Localization Record should identify:

1. localized data object;
2. required location or environment;
3. reason for localization;
4. permitted users and processors;
5. permitted transfer outputs, including public-safe summary, metadata-only record, aggregate, synthetic data, or compute-to-data output;
6. prohibited transfers;
7. repository and backup requirements;
8. AI-use limitations by location;
9. public-safe release and handoff conditions;
10. correction, deletion, sealing, archive, and return rules.

Localization can support national trust and lawful continuity. It should not become a hidden assertion of public authority approval, nor should it be bypassed because centralized processing is easier. Where localization applies, Nexus should design workflows around it rather than treating it as an exception.

### 10.5.8 Retention

Retention is the DICE control defining how long data, metadata, derived data, logs, AI inputs, AI outputs, access records, proof receipts, Studio records, DRI records, Observatory records, Reports data, Academy data, Campaign data, Marketplace metadata, Registry metadata, Grid data, National Portfolio data, Nexus Universe data, handoff data, correction records, and archive records may or must be kept.

Retention should be purpose-bound. Data should not be retained indefinitely merely because it may be useful later. Retention periods should reflect legal obligations, public-good purpose, evidence needs, correction needs, audit needs, privacy obligations, cybersecurity risk, community safeguards, Indigenous protocol conditions where applicable, protected knowledge controls, public authority conditions, data sovereignty conditions, handoff obligations, and archive value.

A Retention Record should identify:

1. data object or record class;
2. retention purpose;
3. retention period;
4. retention start and end triggers;
5. review cadence;
6. who may extend retention and on what basis;
7. whether data becomes archive-only after active use;
8. whether deletion, sealing, return, anonymization, aggregation, or public-safe transformation applies after retention;
9. correction and recall obligations during retention.

Retention does not authorize new use. Keeping data for one purpose does not permit AI training, public release, handoff, publication, procurement use, finance use, insurance use, public authority action, deployment, or execution unless separately permitted. Retention is custody, not unrestricted future use.

### 10.5.9 Deletion

Deletion is the DICE control for removing data, metadata, derived data, copies, logs, exports, AI inputs, AI outputs, cached materials, temporary files, repository files, Studio files, data-room files, secure-room files, clean-room files, handoff-recipient materials, or archive materials where deletion is required or appropriate.

Deletion may be required by law, data rights, consent withdrawal, rights-holder request, Indigenous protocol where applicable, protected knowledge restriction, privacy risk, cyber risk, public-safe risk, mistaken intake, unauthorized data submission, secret exposure, expired purpose, retention expiry, handoff recall, correction, withdrawal, or non-continuation.

A Deletion Record should identify:

1. data deleted;
2. reason for deletion;
3. deletion authority or basis;
4. systems, repositories, backups, logs, rooms, recipients, and derived objects affected;
5. whether deletion is complete, partial, delayed, technically infeasible, or legally restricted;
6. whether metadata may remain as a deletion record;
7. whether downstream derived objects require correction, withdrawal, recall, or archive;
8. notice requirements.

Deletion is different from archive. Archive preserves memory under restriction. Deletion removes data where preservation is unlawful, unsafe, unauthorized, unnecessary, or inconsistent with the governing conditions. Where full deletion is impossible because of backups, legal holds, audit requirements, or distributed copies, the record should state the limitation and apply sealing, restriction, or non-use controls.

Deletion does not erase accountability. A safe deletion record may remain where lawful and necessary to show that deletion occurred.

### 10.5.10 Sealing

Sealing is the DICE control for preserving the existence or custody of data while prohibiting ordinary access, use, publication, AI processing, handoff, display, citation, or reuse. Sealing may be necessary where deletion is not permitted, not appropriate, or not immediately feasible, but continued access would be unsafe or unlawful.

Sealing may apply to protected knowledge, Indigenous protocol-sensitive data where applicable, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, public authority-sensitive data, legal-sensitive data, geospatial-sensitive data, community-sensitive data, confidential provider data, handoff-recipient-only data, incident records, vulnerability records, withdrawn data, recalled data, or data subject to legal hold.

A Sealing Record should identify:

1. sealed data object;
2. sealing reason;
3. sealing authority or steward;
4. access prohibition and permitted exceptional access, if any;
5. review or reopening conditions;
6. relationship to deletion, archive, correction, or legal hold;
7. metadata display restrictions;
8. downstream objects affected;
9. notice and public-safe handling.

Sealing is not concealment for convenience. It is a protective governance state. It should be used where access must be stopped while memory, legal retention, accountability, correction, or future review must be preserved. Sealed data must not appear in Marketplace listings, public Registry views, public Reports, open Academy materials, public dashboards, or Nexus Universe materials except through safe metadata or public-safe notices where lawful and appropriate.

### 10.5.11 Archive

Archive is the DICE control for preserving data, metadata, derived objects, records, public-safe outputs, reports, dashboards, Studio workflows, DRI outputs, Observatory outputs, National Portfolio objects, Nexus Universe objects, handoff packages, correction records, deletion records, sealing records, and lifecycle records as memory without current authority.

Archive may occur after completion, supersession, support expiry, public-safe release closure, data rights change, correction, withdrawal, recall, retention expiry, Nexus Universe cycle closure, National Portfolio cycle closure, Campaign closure, Studio workflow closure, handoff completion, non-continuation, or legal requirement.

A Data Archive Record should identify:

1. archived object identity and version;
2. prior lifecycle state;
3. archive date and steward;
4. archive reason;
5. archive access class;
6. use and citation restrictions;
7. data-use and AI-use restrictions after archive;
8. privacy, cyber, protected knowledge, community, Indigenous protocol where applicable, geospatial, public authority, legal, and security controls;
9. successor object where applicable;
10. relationship to deletion, sealing, retention, or legal hold;
11. correction and recall history;
12. non-current authority notice.

Archive preserves institutional memory and correctionability. It does not preserve current permission. Archived data is not open, current, AI-trainable, public-safe, handoff-ready, financeable, insurable, public-authority-approved, consented, deployable, or executable by default.

Archive is the disciplined alternative to both forgetting and stale reliance.

### 10.5.12 Incident Response

Incident response is the DICE control for identifying, containing, assessing, correcting, notifying, repairing, restricting, deleting, sealing, recalling, archiving, or otherwise responding to events that compromise or threaten data governance.

Data incidents may include:

1. unauthorized access;
2. unauthorized disclosure;
3. unauthorized download, copy, export, or transfer;
4. unauthorized AI use;
5. unauthorized publication;
6. unauthorized Marketplace listing or Registry display;
7. public-safe release error;
8. data rights violation;
9. consent or permission breach;
10. protected knowledge exposure;
11. Indigenous protocol breach where applicable;
12. youth data exposure;
13. health-sensitive data exposure;
14. cyber-sensitive or infrastructure-sensitive exposure;
15. geospatial exposure;
16. public authority-sensitive data misuse;
17. data quality error causing reliance risk;
18. handoff package error;
19. deletion, sealing, retention, or archive failure;
20. correction propagation failure.

A Data Incident Record should identify incident class, affected data objects, affected source and derived objects, affected users or recipients, severity, discovery date, containment steps, legal or steward review, public-safe risk, notification obligations, correction steps, deletion or sealing requirements, recall requirements, Marketplace and Registry updates, Studio shutdowns, Reports corrections, Grid updates, National Portfolio updates, Nexus Universe updates, handoff-recipient notices, archive treatment, and closure conditions.

Incident response should be fast enough to prevent harm and disciplined enough to preserve evidence. It should not hide errors, over-disclose sensitive details, or allow corrected data failures to persist in downstream objects.

The final Data Governance Controls rule is: minimize data; bind it to purpose; record consent and permissions; control access; govern cross-border movement; respect sovereignty and localization; retain only with purpose; delete when required; seal when access must stop but memory must remain; archive without current authority; respond to incidents through correction, notification, recall, repair, and record.

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

### 10.6.1 Secure Room

A Secure Room is a controlled Nexus environment for reviewing, processing, demonstrating, analyzing, or preserving sensitive data, software, models, workflows, records, dashboards, cyber artifacts, infrastructure materials, protected knowledge, public authority-sensitive materials, National Portfolio objects, Nexus Universe materials, or handoff-context packages under enhanced access, security, logging, monitoring, output-review, correction, and archive controls.

A Secure Room may be physical, digital, hybrid, cloud-based, sovereign-zone-based, National Node-based, Studio-linked, data-room-linked, clean-room-linked, compute-to-data-linked, public authority learning-linked, handoff-recipient-linked, or Nexus Universe-linked. Its defining feature is not location. Its defining feature is controlled access and bounded use.

A Secure Room should identify:

1. room purpose, including review, learning, DICE handling, AI review, cyber review, public authority learning, National Portfolio preparation, Nexus Universe preparation, Studio workflow, Grid or TRL review, readiness review, or handoff-context review;
2. approved participants, including stewards, reviewers, maintainers, public authority learners, National Node users, Working Group members, Competence Cell members, lawful recipients, or other approved roles;
3. approved materials, including data objects, metadata, software, models, reports, dashboards, handoff packages, logs, records, or restricted evidence;
4. approved actions, including view, query, compute, annotate, review, summarize, transform, output-request, or correction-propose;
5. prohibited actions, including unauthorized download, copy, export, publication, AI training, cross-border transfer, write-back, operational command, procurement action, finance action, insurance action, consent substitution, deployment, or execution;
6. technical controls, including identity verification, access approval, least privilege, encryption, logging, monitoring, key management, no-download controls, no-copy controls, session limits, watermarking where appropriate, and revocation;
7. output controls, including output review, redaction, aggregation, masking, public-safe transformation, recipient restriction, correction, recall, and archive;
8. incident controls, including access suspension, investigation, notification, correction, sealing, deletion where required, recall, and public repair where appropriate.

A Secure Room is not a decision room by default. It does not create public authority action, certification, procurement, finance, insurance, consent, deployment authorization, or execution. It creates a controlled environment for sensitive work that should not occur in ordinary open channels.

### 10.6.2 Data Room

A Data Room is a controlled review environment for documents, datasets, metadata, evidence packs, reports, diligence materials, public authority learning materials, finance-readiness records, insurance-readiness records, donor-readiness records, public finance learning records, National Portfolio objects, Nexus Universe outputs, Grid and TRL records, Studio outputs, support records, assumptions registers, dependency registers, diligence-gap registers, safeguard records, consent boundary records, and handoff packages.

A Data Room differs from a general repository because access is purpose-bound, participant-bound, logged, time-bounded where appropriate, and subject to use restrictions. It may support public-good review, public authority learning, capital-reader review, insurance-reader review, donor-reader review, public finance learning, Project SPV review, National Consortium Company review, provider review, operator review, university or laboratory review, community safeguard review, Indigenous protocol-sensitive review where applicable, or handoff preparation.

A Data Room should include:

1. data-room purpose and scope, including what is being reviewed and why;
2. data-room inventory, including each document, dataset, record, report, dashboard, register, ledger, workflow, package, or evidence object made available;
3. access roles, including viewers, reviewers, contributors, stewards, administrators, public authority learners, capital readers, insurance readers, donors, public finance readers, lawful recipients, or safeguard reviewers;
4. use restrictions, including no-download, no-redistribution, no-publication, no-AI-training, no-external-citation, no-commercial-use, no-procurement-reliance, no-finance-reliance, no-insurance-reliance, no-public-authority-action, no-consent-transfer, and no-execution;
5. document controls, including watermarking, access expiry, version control, update notices, withdrawal notices, recall notices, and archive notices;
6. review outputs, including questions, comments, learning notes, dependency notes, diligence-gap notes, readiness notes, correction requests, handoff notes, and public-safe summaries;
7. closure pathway, including return, deletion, sealing, archive, handoff completion, recall, or non-continuation.

A Data Room gives structured access to materials. It does not grant ownership, unrestricted reuse, AI-use rights, publication rights, procurement rights, finance rights, insurance rights, public authority rights, consent rights, deployment rights, or execution rights.

### 10.6.3 Clean Room

A Clean Room is a controlled environment in which approved computation, comparison, analysis, matching, aggregation, measurement, model evaluation, or statistical processing may occur without exposing raw data to unauthorized users or transferring raw data outside the approved environment. Clean Rooms are used where data may be useful for public-good analysis, DRI, Observatory, Studio, Reports, Academy, Grid, National Portfolio, Nexus Universe, finance-readiness literacy, insurance-readiness literacy, or handoff context, but raw data cannot be openly disclosed.

A Clean Room may support:

1. privacy-preserving analytics;
2. secure data matching;
3. aggregate indicator generation;
4. benchmark evaluation;
5. model evaluation without raw-data export;
6. public-safe summary generation;
7. data quality assessment;
8. synthetic data validation;
9. finance-readiness or insurance-readiness question review without data extraction;
10. handoff-recipient review under controlled computation.

A Clean Room should define:

1. approved datasets and stewards;
2. approved users and roles;
3. approved workloads, including permitted queries, models, computations, joins, aggregations, or evaluations;
4. prohibited workloads, including raw export, unauthorized linkage, re-identification attempts, prohibited AI training, prohibited fine-tuning, prohibited embedding, uncontrolled scraping, or operational command;
5. output rules, including thresholding, suppression, aggregation, masking, redaction, public-safe review, steward review, and no-small-cell disclosure;
6. technical controls, including isolation, encryption, logging, query review, output review, no-download controls, access expiry, and audit;
7. correction and incident pathways, including output recall, access suspension, deletion, sealing, public-safe correction, and archive.

A Clean Room allows computation without collapsing data rights. It does not make raw data open. It does not grant AI-use permission beyond approved workloads. It does not create certification, public authority action, procurement, finance, insurance, consent, deployment authorization, or execution.

### 10.6.4 Protected Knowledge Room

A Protected Knowledge Room is a controlled Nexus environment for materials involving protected knowledge, community-sensitive knowledge, Indigenous protocol-sensitive knowledge where applicable, cultural knowledge, ecological knowledge, place-based knowledge, humanitarian-sensitive knowledge, protected sites, rights-bearing knowledge, local resilience knowledge, or other knowledge that requires protection against exposure, extraction, misinterpretation, AI ingestion, commodification, geospatial disclosure, unauthorized publication, unauthorized handoff, or consent overclaim.

A Protected Knowledge Room should be governed through the relevant stewardship, custodianship, community, Indigenous governance where applicable, rights-holder, or institutional process. It should not treat protected knowledge as ordinary data merely because it is stored digitally, discussed in a meeting, summarized in a report, or referenced in metadata.

A Protected Knowledge Room should identify:

1. knowledge class and protection basis;
2. steward, custodian, or governance pathway;
3. approved participants and roles;
4. approved purposes, including learning, safeguard review, public-safe transformation, National Portfolio context, DRI context, Observatory context, Studio context, Reports context, or handoff dependency context;
5. prohibited uses, including open publication, AI training, fine-tuning, embedding, geospatial exposure, commercialization, public dashboarding, uncontrolled translation, provider reuse, sponsor use, public authority overclaim, consent transfer, deployment, or execution;
6. output controls, including summary review, protected detail removal, community review, Indigenous protocol review where applicable, public-safe transformation, translation control, and handoff restriction;
7. withdrawal, correction, sealing, deletion, return, archive, and public repair pathway.

A Protected Knowledge Room is a legitimacy safeguard, not an administrative convenience. It enables respectful learning and review while preventing extraction. Participation in such a room does not create consent, rights waiver, protected knowledge permission, data-use permission, AI-use permission, public authority action, handoff authorization, deployment authorization, or execution.

### 10.6.5 Public Authority Learning Room

A Public Authority Learning Room is a controlled Nexus environment in which public authorities and public-sector actors may examine evidence, dashboards, Reports, Studio workflows, DRI indicators, GRIx mappings, Observatory signals, DICE records, National Portfolio objects, Nexus Universe outputs, Grid and TRL context, public-safe summaries, finance-readiness questions, procurement-boundary notes, public finance learning materials, and handoff dependencies without being treated as having made a public authority decision.

A Public Authority Learning Room may support learning by ministries, agencies, regulators, municipalities, public utilities, public finance actors, emergency bodies, public-sector teams, or other public institutions. Its purpose is to improve understanding, questions, readiness, literacy, and context. It is not a substitute for public authority procedure.

A Public Authority Learning Room should identify:

1. learning purpose, including risk intelligence, public-safe reporting, DRI literacy, data governance, AI governance, cyber resilience, WFEH-B systems, finance-readiness literacy, public finance learning, procurement boundary learning, emergency-language discipline, or handoff dependency review;
2. participant roles, including public authority learners, Nexus facilitators, evidence stewards, technical contributors, public-safe reporting reviewers, National Node representatives, or other recorded roles;
3. materials reviewed, including Reports, dashboards, datasets, Studio outputs, Grid records, National Portfolio objects, Nexus Universe outputs, and handoff materials;
4. non-decision status, confirming that the room is not approval, rejection, permit, license, public warning, emergency command, procurement decision, public finance allocation, policy adoption, regulatory action, official classification, compliance finding, or endorsement;
5. output classes, including learning notes, questions registers, non-decision observations, public-safe summaries, restricted notes, correction triggers, or handoff dependency notes;
6. archive and correction pathway, including correction of public authority overclaims, public-facing language, dashboard interpretation, and handoff context.

Public authority learning is necessary for public-good readiness. It remains legitimate only if learning is not misrepresented as public authority action.

### 10.6.6 Readiness Room

A Readiness Room is a controlled Nexus environment for examining whether an object, pathway, report, dataset, model, dashboard, software release, Studio workflow, Grid or TRL record, Marketplace listing, Registry status, National Portfolio object, Nexus Universe output, Campaign object, Academy object, Foundry build, or handoff package is ready for a defined next Nexus pathway within recorded limits.

A Readiness Room may review readiness for:

1. evidence review;
2. method review;
3. data review;
4. AI review;
5. cyber and privacy review;
6. public-safe release;
7. accessibility and safeguard review;
8. Academy use;
9. Campaign use;
10. Reports publication;
11. Marketplace discovery;
12. Registry status update;
13. Studio demonstration;
14. Grid or TRL classification;
15. Nexus Universe presentation;
16. National Portfolio inclusion;
17. handoff-context preparation;
18. archive or non-continuation.

A Readiness Room should identify:

1. readiness question;
2. object and version under review;
3. required records, including evidence, method, data-use, AI-use, support, review, public-safe, sensitivity, correction, and archive records;
4. review participants and roles;
5. readiness criteria;
6. outcome class, including ready, ready with conditions, returned for revision, restricted, suspended, withdrawn, recalled, archived, or non-continuing;
7. boundary notices, including readiness-not-certification, readiness-not-procurement, readiness-not-finance, readiness-not-insurance, readiness-not-public-authority-action, readiness-not-consent, readiness-not-deployment, and readiness-not-execution.

Readiness is pathway-specific. An object may be ready for Academy use but not for public Reports; ready for Studio demonstration but not handoff; ready for handoff context but not deployment. A Readiness Room controls routing. It does not approve external action.

### 10.6.7 Capital-Reader Room

A Capital-Reader Room is a controlled learning and interpretation environment in which capital readers may review finance-readiness context, risk-to-capital translation, assumptions registers, dependency registers, diligence-gap records, National Portfolio context, Nexus Universe outputs, Reports, Studio workflows, Grid and TRL context, public authority dependency notes, safeguard dependencies, and handoff-context materials without receiving investment advice, securities solicitation, transaction access, valuation, rating, guarantee, financing commitment, or execution authority.

Capital-reader participation may support better questions about what evidence, governance, data, public authority dependencies, procurement dependencies, insurance dependencies, safeguards, operating models, revenue models where separately appropriate, or Project SPV conditions would be needed before any separate financial process could occur. It does not convert Nexus into a financial adviser, broker, dealer, placement agent, fund, lender, underwriter, arranger, guarantor, rating agency, or transaction platform.

A Capital-Reader Room should identify:

1. room purpose, including capital-readability, finance-readiness literacy, diligence-gap learning, dependency review, National Portfolio context, Nexus Universe context, or handoff dependency review;
2. participant roles, including capital readers, GRA-supported facilitators, public-good stewards, technical contributors, National Node representatives, Project SPV observers where applicable, or lawful recipients;
3. materials reviewed, including finance-readiness records, assumptions, dependencies, Reports, Grid records, Studio outputs, handoff packages, and public-safe summaries;
4. regulated-perimeter controls, including no investment advice, no solicitation, no offer, no valuation, no rating, no guarantee, no transaction execution, no investor recommendation, and no reliance;
5. output classes, including questions, diligence gaps, dependency notes, readiness literacy notes, and handoff-context notes;
6. archive and correction pathway.

A Capital-Reader Room improves legibility. It does not create finance.

### 10.6.8 Insurance-Reader Room

An Insurance-Reader Room is a controlled learning and interpretation environment in which insurers, reinsurers, brokers where appropriate, risk engineers, DRF actors, protection-gap experts, public finance readers, or insurance-related observers may review risk intelligence, DRI datasets, Observatory outputs, National Portfolio context, Nexus Universe outputs, Studio scenarios, Grid and TRL context, vulnerability and resilience indicators, assumptions registers, dependency registers, safeguard notes, and handoff-context materials without receiving or making underwriting decisions by implication.

Insurance-reader participation may help identify what data, evidence, modeling, public authority context, asset context, resilience measures, risk-reduction records, exposure information, legal conditions, claims history, governance records, or operational controls would be needed for any separate insurance process. It does not create coverage, premium indication, underwriting approval, claim determination, insurance advice, risk rating, guarantee, or insurability determination.

An Insurance-Reader Room should identify:

1. room purpose, including insurance-readiness literacy, DRF learning, protection-gap analysis, risk-to-insurance translation, resilience evidence review, dependency mapping, or handoff-context review;
2. participant roles, including insurance readers, reinsurers, risk engineers, GRA-supported facilitators, technical stewards, public authority learners, National Node representatives, or lawful recipients;
3. materials reviewed, including DRI outputs, Observatory signals, Studio simulations, Reports, National Portfolio objects, Grid records, handoff packages, and assumptions registers;
4. insurance boundary controls, including no underwriting, no coverage commitment, no premium indication, no claims determination, no insurance advice, no guarantee, no insurability claim, and no reliance;
5. output classes, including insurance-readiness questions, protection-gap notes, data-gap notes, resilience-evidence needs, and handoff dependency notes;
6. correction and archive pathway.

An Insurance-Reader Room helps insurance actors understand context. It does not insure.

### 10.6.9 Donor-Reader Room

A Donor-Reader Room is a controlled learning and interpretation environment in which donors, foundations, philanthropies, development actors, grantmakers, public-interest funders, CSR actors where appropriate, or public-good supporters may review public-good needs, Campaign objects, Reports, National Portfolio context, Nexus Universe outputs, Academy needs, Foundry builds, Studio workflows, DRI and Observatory outputs, safeguard records, support needs, readiness records, and handoff dependencies without creating donor commitment, grant award, philanthropic allocation, restricted funding approval, public finance allocation, procurement, or execution authority.

A Donor-Reader Room may help clarify public-good need, support gaps, capacity gaps, evidence needs, community safeguards, accessibility needs, translation needs, National Node support needs, Academy support needs, Campaign support needs, and post-cycle continuation needs. It may support donor literacy and lawful support discovery. It does not create a pledge unless a separate lawful pledge, grant, donation, sponsorship, or support instrument is executed by the relevant actor.

A Donor-Reader Room should identify:

1. room purpose, including donor-readiness literacy, support discovery, public-good needs review, Campaign support review, National Portfolio learning, Nexus Universe continuation, or handoff dependency review;
2. participant roles, including donor readers, foundations, public-good supporters, GRA-supported facilitators, GRF-supported public-good legitimacy stewards, National Node representatives, community safeguard participants where appropriate, or lawful recipients;
3. materials reviewed, including Reports, Campaign objects, support records, Academy needs, Foundry needs, National Portfolio objects, Nexus Universe outputs, safeguard records, and handoff-context notes;
4. donor boundary controls, including no donor commitment, no grant award, no philanthropic allocation, no public finance allocation, no procurement, no endorsement, no reliance, and no execution;
5. output classes, including support questions, donor-readiness notes, dependency notes, safeguard notes, and public-safe summaries;
6. correction and archive pathway.

A Donor-Reader Room helps donors understand where public-good support may be useful. It does not allocate support by implication.

### 10.6.10 Compute-to-Data Workflow

A Compute-to-Data Workflow is a controlled architecture in which approved computation moves to data rather than raw data moving to the user, analyst, model, dashboard, repository, or recipient. It is preferred where data is restricted, sovereign-sensitive, public authority-sensitive, rights-bearing, community-sensitive, Indigenous protocol-sensitive where applicable, protected-knowledge-sensitive, health-sensitive, youth-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, or otherwise high-risk.

Compute-to-data may support data quality review, DRI calculation, Observatory signal processing, model evaluation, AI-assisted analysis under restriction, public-safe aggregation, dashboard generation, feature-set preparation, benchmark evaluation, Studio workflows, National Portfolio preparation, Nexus Universe preparation, and handoff-context review without raw data export.

A Compute-to-Data Workflow should identify:

1. source data and steward;
2. approved compute environment;
3. approved users and roles;
4. approved workloads, including scripts, queries, models, transformations, aggregations, or evaluations;
5. prohibited workloads, including raw export, unauthorized joins, re-identification attempts, prohibited AI training, prohibited fine-tuning, prohibited embedding, uncontrolled agentic workflows, and operational command;
6. input controls, including code review, dependency review, secret scanning, AI-use labeling, and workflow approval;
7. output controls, including output review, thresholding, aggregation, masking, redaction, geospatial generalization, public-safe classification, and handoff restriction;
8. logging, monitoring, audit, correction, recall, deletion, sealing, and archive rules.

Compute-to-data is not a workaround for data rights. It is a rights-respecting architecture for bounded computation. It does not make raw data open, grant AI-use permission beyond approved workloads, authorize publication, transfer consent, approve public authority action, create finance or insurance determinations, authorize deployment, or execute.

### 10.6.11 Output Review

Output Review is the control through which outputs 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, AI workflows, dashboards, notebooks, and handoff demonstrations are examined before release, display, publication, listing, registration, teaching, handoff, archive, or deletion.

Output Review should determine whether an output contains or implies:

1. personal data exposure;
2. protected knowledge exposure;
3. Indigenous protocol-sensitive disclosure where applicable;
4. community-sensitive disclosure;
5. youth or health-sensitive disclosure;
6. cyber or infrastructure-sensitive disclosure;
7. geospatial-sensitive disclosure;
8. public authority overclaim;
9. finance or insurance overclaim;
10. donor commitment implication;
11. procurement implication;
12. certification implication;
13. consent implication;
14. deployment or execution implication;
15. AI-generated hallucination, bias, leakage, or unsupported claim;
16. low-cell or re-identification risk;
17. source-data leakage;
18. license or rights violation.

Output Review may result in approval for release within scope, redaction, aggregation, masking, summary-only release, public-safe transformation, restriction, return for revision, suspension, withdrawal, recall, archive, sealing, deletion, or non-continuation.

Output Review is not certification. It is a release-safety control. An output cleared for a defined purpose remains bounded by its release class and no-conversion notices.

### 10.6.12 No-Download Controls

No-Download Controls are technical, administrative, and procedural controls that prohibit or limit downloading, copying, exporting, syncing, printing, scraping, screen-capturing where feasible and lawful, bulk extraction, local storage, model ingestion, unauthorized transfer, or uncontrolled reuse of data and materials in controlled rooms.

No-download controls may apply to Secure Rooms, Data Rooms, Clean Rooms, Protected Knowledge Rooms, Public Authority Learning Rooms, Readiness Rooms, Capital-Reader Rooms, Insurance-Reader Rooms, Donor-Reader Rooms, Studio workflows, National Node repositories, handoff-recipient-only environments, and archive environments.

No-download controls may include:

1. view-only access;
2. disabled downloads;
3. disabled copy and paste where feasible;
4. watermarking;
5. screen-capture warnings or technical restrictions where appropriate;
6. session logging;
7. access expiry;
8. device restrictions;
9. no local storage;
10. no unmanaged sync;
11. no raw export;
12. output review before export;
13. query-only or compute-to-data mode;
14. recipient-specific access;
15. immediate revocation for misuse.

No-download does not mean no-risk. Users may still remember, summarize, photograph, transcribe, or misuse material. Therefore no-download controls must be paired with legal, ethical, conduct, confidentiality, access, logging, review, and incident controls.

No-download access is not permission to use the material beyond the room. It is controlled viewing or controlled computation only.

### 10.6.13 Room Archive

Room Archive is the lifecycle process for preserving, restricting, sealing, deleting where required, or marking non-current the records, inventories, access logs, outputs, review notes, public-safe summaries, correction records, questions, dependency notes, handoff notes, support notes, incident records, and closure records produced by 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, and related Studio environments.

A Room Archive should identify:

1. room identity and purpose;
2. room dates and steward;
3. participants and roles, subject to privacy and confidentiality controls;
4. materials made available;
5. outputs produced;
6. outputs approved for release, restricted, sealed, deleted, recalled, or archived;
7. access logs and retention rules;
8. correction and incident history;
9. handoff records or recipient notices where applicable;
10. public-safe summary where appropriate;
11. archive access class;
12. non-current authority notice.

Room Archive prevents controlled-room work from disappearing while also preventing room materials from remaining active beyond their purpose. It preserves memory, correctionability, and accountability without converting room participation into authority.

A Room Archive is not public authority action, finance commitment, insurance decision, donor commitment, procurement record, certification, consent record, deployment authorization, or execution record unless a separate competent actor has created such a record outside the Nexus room context.

The final Secure-Room and Compute-to-Data Architecture rule is: sensitive work belongs in controlled rooms; raw data should not move when computation can move instead; outputs must be reviewed before release; downloads must be limited where risk requires; room records must be archived without current authority; no room, computation, access, review, output, or archive creates certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 10.7 Data Boundaries

### 10.7.1 Data Availability Is Not Data Right

Data availability is not data right. A data object may be visible, accessible, discoverable, stored in a repository, referenced in metadata, displayed in a dashboard, summarized in a Report, reviewed in a Studio workflow, discussed in a public authority learning room, listed in Marketplace, statused in Registry, included in a National Portfolio, presented at Nexus Universe, or attached to a handoff package without granting a general right to copy, reuse, publish, transform, commercialize, train AI on, transfer, hand off, deploy, or execute with that data.

Availability describes technical, practical, or contextual access. A right describes lawful permission. Nexus requires the two to remain separate. A person may be able to see a dataset without being permitted to download it. A reviewer may be permitted to query data without being permitted to export raw records. A public-safe summary may be released without releasing the source data. A National Portfolio may reference data without making it open. A handoff package may include data context without granting unrestricted downstream use.

A data object should therefore identify, at minimum:

1. who may know the data exists;
2. who may view the data;
3. who may query or compute against the data;
4. who may download or export the data;
5. who may transform or derive new objects from the data;
6. who may publish data or data-derived outputs;
7. who may use the data with AI systems;
8. who may transfer the data across borders;
9. who may include the data in handoff materials;
10. who must delete, seal, return, restrict, correct, or archive the data.

Where rights are unclear, limited, disputed, expired, withdrawn, jurisdiction-specific, community-bound, Indigenous protocol-sensitive where applicable, protected-knowledge-bound, or public authority-sensitive, Nexus should default to controlled or restricted handling until the competent steward records the permissible use.

The boundary rule is direct: data may be available in a Nexus context without being available for general use.

### 10.7.2 Metadata Is Not Open Data

Metadata is not open data. Metadata may describe a data object, but the existence of metadata does not make the underlying data open, downloadable, reusable, publishable, AI-trainable, transferable, or handoff-ready. Metadata exists to support discovery, governance, review, routing, public-safe transformation, Registry status truth, Marketplace awareness, National Portfolio memory, Nexus Universe continuity, and lawful handoff context. It does not release the source data by implication.

Metadata may include title, steward, description, source class, geography, time period, data class, access class, sensitivity class, data-use label, AI-use label, quality summary, lineage summary, update cadence, public-safe status, Registry status, Marketplace relationship, Studio relationship, Grid relationship, National Portfolio relationship, Nexus Universe relationship, and handoff relevance. Some of that metadata may be public-safe; some may itself be sensitive.

Metadata can be sensitive where it reveals:

1. the existence of a restricted dataset;
2. the location of vulnerable populations, protected sites, infrastructure, or ecological resources;
3. a public authority learning process;
4. a cyber, security, or infrastructure weakness;
5. a community-sensitive or Indigenous protocol-sensitive context where applicable;
6. protected knowledge or knowledge-holder relationships;
7. a finance, insurance, procurement, or handoff dependency;
8. a confidential provider, sponsor, public authority, or institutional relationship.

A metadata-only record should clearly state whether it is open, controlled, restricted, public-safe, metadata-only, access-request-only, National Node-only, public authority learning-only, handoff-awareness-only, archive-only, sealed, or non-public. It should also state whether the underlying source data is accessible, inaccessible, restricted, controlled, or available only through secure-room, data-room, clean-room, compute-to-data, or handoff-recipient pathways.

The boundary rule is direct: metadata may make data governable and discoverable; it does not make the underlying data open.

### 10.7.3 Dataset Citation Is Not Permission to Reuse

Dataset citation is not permission to reuse. Citing a dataset, referencing it in a Report, listing it in a bibliography, linking it in a repository, displaying its metadata in Registry, showing it in Marketplace, naming it in a National Portfolio, discussing it in Nexus Universe, or identifying it in a handoff package does not grant permission to access, copy, download, scrape, transform, combine, republish, commercialize, train AI on, or transfer the dataset.

Citation supports attribution, transparency, provenance, reproducibility where permitted, and evidence discipline. Permission requires a separate rights basis, license, data-use label, access approval, data-sharing agreement, consent where applicable, steward authorization, public authority permission where required, Indigenous governance permission where applicable, protected knowledge permission where applicable, or handoff-recipient authorization where applicable.

A dataset citation should be accompanied by appropriate context where reuse risk exists, including:

1. source and version;
2. license or rights status;
3. access class;
4. data-use label;
5. AI-use label;
6. sensitivity class;
7. public-safe status;
8. citation limits;
9. reuse restrictions;
10. correction and archive status.

Where citation points to a public-safe derivative, the citation should not imply access to raw source data. Where citation points to a restricted dataset, the citation should not imply that readers may request or receive it automatically. Where citation points to a controlled data-room object, the citation should not imply open access.

The boundary rule is direct: citation shows evidentiary relationship; it does not grant use rights.

### 10.7.4 Public-Safe Data Is Not Raw Data Release

Public-safe data is not raw data release. A public-safe dataset, summary, dashboard, map, chart, indicator, Report table, Academy example, Campaign metric, Marketplace description, Registry public view, Nexus Universe output, National Portfolio summary, or handoff-facing note may communicate selected data-derived information without releasing the underlying raw data.

Public-safe transformation may involve aggregation, masking, redaction, de-identification, suppression, geospatial generalization, spatial displacement, time-window generalization, field removal, uncertainty language, limitation language, synthetic substitution, protected knowledge exclusion, public authority boundary language, finance and insurance boundary language, consent boundary language, and no-execution notices. These transformations create a new governed object with its own scope and release class.

Public-safe release should not be interpreted as permission to:

1. access the raw dataset;
2. reverse-engineer the source data;
3. request unrestricted download;
4. combine the output with other data to re-identify subjects or places;
5. use the output for AI training beyond the recorded AI-use label;
6. treat the output as an official public authority record;
7. treat the output as procurement, finance, insurance, consent, deployment, or execution authority;
8. bypass the data steward, National Node, community safeguard, Indigenous protocol where applicable, or protected knowledge control.

Where public-safe data is derived from restricted, controlled, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive, health-sensitive, youth, cyber-sensitive, infrastructure-sensitive, or geospatial-sensitive sources, the source restrictions may still matter. Public-safe data should carry enough metadata to preserve context while avoiding unsafe disclosure.

The boundary rule is direct: public-safe release communicates safe context; it does not release raw data.

### 10.7.5 Data-Room Access Is Not Handoff Permission

Data-room access is not handoff permission. Access to a data room allows a recorded participant to view, review, question, comment on, or analyze materials under defined room conditions. It does not grant the right to export, reuse, publish, transfer, operationalize, incorporate into procurement, incorporate into finance diligence, incorporate into insurance underwriting, use for AI training, share with affiliates, deliver to Project SPVs, deliver to National Consortium Companies, deliver to public authorities, or otherwise hand off the materials unless a separate Handoff Record or permission instrument provides that authority.

A Data Room may support public-good review, public authority learning, capital-reader learning, insurance-reader learning, donor-reader learning, public finance learning, Studio review, Readiness Room review, National Portfolio review, Nexus Universe preparation, Project SPV awareness, National Consortium Company awareness, provider review, operator review, community safeguard review, Indigenous protocol-sensitive review where applicable, or handoff preparation. Those functions are not the same as handoff.

Data-room records should distinguish:

1. view permission;
2. query permission;
3. download permission;
4. note-taking permission;
5. output permission;
6. citation permission;
7. AI-use permission;
8. internal-sharing permission;
9. external-sharing permission;
10. handoff permission;
11. archive permission;
12. deletion, return, or sealing obligations.

Where handoff is appropriate, it must occur through a Handoff Record identifying the object, version, recipient, purpose, included data, rights, restrictions, data-use label, AI-use label, public-safe status, support status, correction pathway, recall pathway, archive rule, recipient responsibility, and no-authority-transfer notices.

The boundary rule is direct: data-room access supports review; it does not transfer handoff rights.

### 10.7.6 Data Object Is Not Public Authority Record Unless Separately Recorded

A data object is not a public authority record unless separately recorded as such by a competent public authority or under an applicable lawful public authority process. A dataset, dashboard, DRI indicator, Observatory signal, public-safe summary, Studio workflow, National Portfolio object, Nexus Universe output, Registry record, Marketplace listing, Report table, public authority learning note, Grid record, handoff package, or data-room material does not become an official public authority record merely because a public authority participated, viewed it, supplied context, asked questions, attended a room, appeared at Nexus Universe, or received handoff context.

Nexus may create public authority learning records. These records document learning, questions, materials reviewed, non-decision observations, public-safe context, and handoff dependencies. They are not permits, licenses, approvals, official classifications, statutory findings, public warnings, emergency commands, procurement decisions, public finance allocations, enforcement actions, compliance determinations, or policy decisions unless the competent public authority separately creates such a record through its own procedures.

A data object connected to public authority participation should state:

1. whether the data is public authority-sensitive;
2. whether the public authority supplied, reviewed, or received the data;
3. whether the public authority role was learning, observer, contributor, steward, regulator, procurer, public finance actor, emergency actor, or separate lawful recipient;
4. whether the data has official status or non-decision status;
5. what public authority boundary notices apply;
6. what use, publication, handoff, archive, and correction restrictions apply.

Where public authority status is claimed, the record must identify the competent public authority, legal or institutional basis, decision instrument, effective date, scope, limitations, and withdrawal or correction pathway. Absent that record, the object remains a Nexus public-good or learning object, not an official public authority record.

The boundary rule is direct: public authority relevance is not public authority action.

### 10.7.7 AI Use Is Not Automated Decision Authority

AI use is not automated decision authority. A data object may be summarized, classified, translated, embedded, queried, visualized, transformed, evaluated, simulated, or analyzed using AI under a recorded AI-Use Label, but AI involvement does not authorize automated decisions, public authority action, procurement decisions, finance decisions, insurance decisions, donor allocations, consent determinations, deployment decisions, operational commands, handoff completion, certification, or execution by default.

AI use within Nexus must remain bounded by purpose, data rights, sensitivity, access class, human review, public-safe status, output review, correction, and no-conversion notices. An AI-generated classification is not official classification. An AI-generated risk score is not insurance underwriting. An AI-generated readiness note is not financeability. An AI-generated public authority summary is not public authority decision. An AI-generated handoff package is not handoff completion. An AI-generated dashboard is not operational command.

AI-use records should identify:

1. AI-use purpose, including summarization, classification, translation, retrieval, analysis, simulation, visualization, review support, metadata generation, or workflow assistance;
2. approved data inputs and prohibited inputs;
3. model or system class where relevant;
4. human review requirement;
5. output review requirement;
6. prohibited automated actions;
7. retention and logging rules;
8. bias, hallucination, leakage, and prompt-injection controls;
9. correction, recall, and archive pathway.

Where automated decision-making is legally or operationally contemplated by a separate competent actor, that actor must establish its own lawful authority, safeguards, auditability, human review, appeal or contestability where required, data rights, public authority basis where applicable, procurement process where applicable, professional responsibility, and liability framework. Nexus AI use may support learning and context; it does not create decision authority.

The final Data Boundaries rule is: data availability is not data right; metadata is not open data; citation is not reuse permission; public-safe data is not raw data release; data-room access is not handoff permission; Nexus data is not a public authority record absent separate public authority status; AI use is not automated decision authority. Data must remain rights-bound, purpose-bound, label-bound, review-bound, correctionable, and non-executing.

<br>


---

# 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/standardization/nexus-ecosystem/ii.-structure/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.