# XIV. DATA

## **14.1 Data Competency Doctrine**

### **14.1.1 Data Literacy as Foundational Competence.**

14.1.1.1 **SCF shall treat data literacy as a foundational competence for all Nexus learning, contribution, workforce resilience, public-good capability formation, National Portfolio development, Nexus Foundry production, Nexus Studio operation, Nexus Reports publication, Nexus Marketplace discovery, Nexus Registry status truth, Nexus Grid review, Nexus Universe preparation, and lawful handoff context.** Data literacy shall not be limited to technical users, analysts, researchers, or software contributors; it shall apply across learners, workers, public authority learning participants, communities, mentors, reviewers, sponsors, providers, hosts, employers, National Working Groups, Competence Cells, Risk Agency experts, and lawful downstream recipients.

14.1.1.2 Data literacy shall include the ability to understand what data is, where it comes from, why it was collected, what it can and cannot support, what rights or restrictions attach to it, how it may be classified, how it may be transformed, how it may be used safely, how it may be misused, how it may be corrected, and how it may be archived.

14.1.1.3 SCF shall ensure that data literacy includes both technical and institutional judgment. A person shall not be treated as data-literate merely because they can operate software, create a dashboard, use a spreadsheet, run a model, query an API, prompt an AI system, or interpret a visualization. Data literacy under SCF shall require awareness of provenance, purpose limitation, consent, sensitivity, quality, uncertainty, privacy, cybersecurity, public-safe output, protected knowledge, data sovereignty, cross-border transfer, and correction.

14.1.1.4 Data literacy shall be integrated into Nexus Academy, Risk Academy, WILPs, Micro-Credentials, ILA records, iCRS recognition, DICE workflows, GRIx classification, DRI interpretation, Observatory outputs, Foundry builds, Studio exercises, Reports drafting, Marketplace listings, Registry records, Grid inputs, TRL notes, and Nexus Universe outputs.

14.1.1.5 Data literacy shall not create a data access right, data ownership right, data reuse permission, public authority record status, legal evidentiary status, regulated compliance status, professional certification, procurement qualification, deployment authorization, financeability, insurability, or execution authority by implication.

### **14.1.2 Data Stewardship as Public-Good Capability.**

14.1.2.1 **Data Stewardship** shall mean the competence to handle data as a public-good responsibility, including classification, metadata, lineage, quality review, rights review, access control, privacy protection, sensitivity protection, public-safe transformation, AI-use labeling, retention, deletion, sealing, correction, and archive.

14.1.2.2 SCF shall treat data stewardship as a role-bearing competence that may be exercised by trained learners, contributors, reviewers, maintainers, mentors, Competence Cells, National Working Groups, Academy staff, Foundry teams, Reports teams, Studio teams, Registry stewards, Marketplace stewards, DICE stewards, Observatory contributors, and lawful downstream recipients within bounded scope.

14.1.2.3 Data stewardship competence shall include:\
(a) identifying data source and provenance;\
(b) recording purpose and permitted use;\
(c) applying data-use labels;\
(d) applying AI-use labels;\
(e) identifying sensitivity and access class;\
(f) managing metadata and data dictionaries;\
(g) preserving lineage;\
(h) supporting quality review;\
(i) escalating privacy, cybersecurity, protected knowledge, youth, health, public authority, community, Indigenous, infrastructure, geospatial, and cross-border concerns;\
(j) supporting correction, withdrawal, sealing, deletion, and archive.

14.1.2.4 Data stewardship shall be treated as operating trust infrastructure. It shall protect Nexus from unreviewed data reuse, unsafe publication, unauthorized AI use, misleading dashboards, uncontrolled public release, sponsor capture, provider capture, public authority overclaim, community extraction, protected knowledge exposure, and unlawful handoff.

14.1.2.5 Data stewardship shall not create legal authority over data, ownership of data, permission to disclose data, permission to train AI systems, permission to export data, public authority approval, regulated compliance certification, or execution authority unless separately and lawfully recorded.

### **14.1.3 Data Governance as Workforce Competence.**

14.1.3.1 **SCF shall treat data governance as a workforce competence required for modern public-good work, technical work, public authority learning, resilience work, risk intelligence, digital public goods, AI-enabled workflows, cyber-physical systems, research, open science, enterprise handoff, and national capability formation.**

14.1.3.2 Data governance competence shall include understanding:\
(a) data classification;\
(b) access rights and permissions;\
(c) consent and purpose limitation;\
(d) privacy and data protection;\
(e) data sovereignty and localization;\
(f) cross-border transfer;\
(g) retention and deletion;\
(h) security and access control;\
(i) metadata, lineage, and data quality;\
(j) public-safe publication;\
(k) protected knowledge handling;\
(l) AI-use restrictions;\
(m) data incident response;\
(n) correction and archive.

14.1.3.3 SCF shall ensure that data governance is not treated as a narrow compliance function. Data governance shall be taught as a practical competence for anyone who collects, receives, reviews, transforms, analyzes, visualizes, publishes, shares, stores, archives, or hands off data-related objects.

14.1.3.4 Data governance competence shall support employability, public-good contribution, technical trust, public-safe reporting, regulated-perimeter literacy, and lawful handoff, while preserving the rule that SCF does not replace lawyers, regulators, data protection officers, institutional review bodies, cybersecurity officers, public authorities, professional certifiers, employers, or lawful data controllers.

### **14.1.4 Data Ethics and Rights.**

14.1.4.1 **Data Ethics and Rights Competence** shall mean the ability to identify and respect the ethical, legal, institutional, community, human-rights, privacy, accessibility, equity, and public-good dimensions of data use.

14.1.4.2 Data ethics competence shall include:\
(a) fairness and non-discrimination awareness;\
(b) privacy and dignity;\
(c) consent and permission literacy;\
(d) youth and vulnerable-person safeguards;\
(e) health-sensitive data awareness;\
(f) community data protection;\
(g) Indigenous protocol-sensitive knowledge controls where applicable;\
(h) protected knowledge controls;\
(i) accessibility and inclusion;\
(j) public-safe communication;\
(k) avoidance of extraction;\
(l) correction and public repair.

14.1.4.3 SCF shall train participants to distinguish lawful availability from ethical use, technical access from permission, metadata from open data, publication from unrestricted reuse, and analysis from authority.

14.1.4.4 Data ethics and rights competence shall not authorize data use, waive rights, create consent, replace community protocols, replace Indigenous governance, replace public authority requirements, or determine legal compliance by implication.

### **14.1.5 AI-Use Labels as Learning Competence.**

14.1.5.1 **SCF shall treat AI-use labels as a required learning competence for any learner, contributor, reviewer, mentor, maintainer, employer, provider, sponsor, public authority learning participant, Competence Cell, Working Group, or lawful recipient using data, documents, models, reports, dashboards, Studio workflows, software, or digital public-good objects within Nexus.**

14.1.5.2 AI-use label competence shall include the ability to understand and apply distinctions among:\
(a) no-AI use;\
(b) retrieval-only use;\
(c) summarization with review;\
(d) classification with review;\
(e) evaluation-only use;\
(f) fine-tuning permitted;\
(g) training permitted;\
(h) agentic use prohibited;\
(i) secure-room AI only;\
(j) public-safe AI output only.

14.1.5.3 AI-use competence shall include awareness that AI tools may create privacy leakage, protected knowledge exposure, hallucination, bias, provenance loss, confidentiality breach, data export, cross-border transfer, prompt-injection risk, model inversion risk, unauthorized training risk, and false authority claims.

14.1.5.4 AI-use label competence shall not authorize AI training, fine-tuning, agentic use, automated decision-making, public authority decisions, employment decisions, certification, deployment, or disclosure of sensitive information unless separately and lawfully approved.

### **14.1.6 Compute-to-Data Literacy.**

14.1.6.1 **Compute-to-Data Literacy** shall mean the ability to understand workflows where approved computation, analysis, model evaluation, query execution, or controlled processing occurs near or within a governed data environment without raw data extraction.

14.1.6.2 Compute-to-data literacy shall include:\
(a) restricted-data reasoning;\
(b) secure enclave awareness;\
(c) clean-room awareness;\
(d) data-room and secure-room procedures;\
(e) no-download rules;\
(f) approved workload rules;\
(g) approved user rules;\
(h) output review;\
(i) audit logging;\
(j) privacy-preserving analytics;\
(k) confidential computing concepts where applicable;\
(l) incident escalation;\
(m) correction and archive.

14.1.6.3 SCF shall treat compute-to-data as especially relevant for public authority-sensitive data, health-sensitive data, youth data, community-sensitive data, Indigenous protocol-sensitive information where applicable, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, sovereign-sensitive data, and cross-border data contexts.

14.1.6.4 Compute-to-data literacy shall not create a right to access data, extract data, export outputs, train models, bypass data residency rules, bypass public authority requirements, or treat controlled outputs as automatically public-safe.

### **14.1.7 Secure-Room Work Literacy.**

14.1.7.1 **Secure-Room Work Literacy** shall mean the competence to work within controlled-access environments, including Data Rooms, Secure Rooms, Clean Rooms, Protected Knowledge Rooms, Public Authority Learning Rooms, Readiness Rooms, Capital-Reader Rooms, Insurance-Reader Rooms, Donor-Reader Rooms, AI Review Rooms, Cyber Review Rooms, and Community Safeguard Rooms.

14.1.7.2 Secure-room competence shall include:\
(a) role-based access awareness;\
(b) identity and permission controls;\
(c) no-download rules;\
(d) no-copy rules where applicable;\
(e) no-write-back rules where applicable;\
(f) no-command rules where applicable;\
(g) secure collaboration practices;\
(h) output review;\
(i) logging and audit awareness;\
(j) confidentiality obligations;\
(k) escalation triggers;\
(l) incident reporting;\
(m) correction and archive.

14.1.7.3 Secure-room competence shall be required for learners and contributors who interact with sensitive data, controlled outputs, public authority learning materials, readiness materials, capital-reader materials, insurance-reader materials, protected knowledge, secure Studio workflows, or restricted handoff context.

14.1.7.4 Secure-room participation shall not imply public authority approval, data access rights beyond the room, permission to disclose outputs, finance approval, insurance approval, donor commitment, procurement status, certification, community consent, Indigenous consent, or execution authority.

### **14.1.8 Data Competence Without Data Rights by Default.**

14.1.8.1 **SCF shall maintain the rule that data competence is not data right.** A learner, worker, contributor, reviewer, mentor, maintainer, expert, employer, host, sponsor, provider, public authority learning participant, Competence Cell, National Working Group, National Node, or lawful downstream recipient may demonstrate competence in data literacy, data stewardship, data governance, secure-room work, AI-use labels, metadata, lineage, data quality, dashboards, models, or public-safe reporting without acquiring any legal or practical right to access, copy, export, reuse, disclose, commercialize, train on, or transfer data.

14.1.8.2 Competence records shall remain bounded by the evidence submitted and the scope recorded. They shall not enlarge data permissions, override consent, override licenses, override confidentiality, override protected knowledge controls, override community protocols, override Indigenous protocols where applicable, override public authority controls, override cross-border transfer restrictions, or override data sovereignty rules.

14.1.8.3 SCF shall ensure that every data competence pathway carries boundary notices, including no data access right, no unrestricted reuse, no automated authority, no public authority approval, no certification by default, no deployment authorization, no procurement status, and no execution by implication.

***

## **14.2 DICE Skills**

### **14.2.1 Data Commons Literacy.**

14.2.1.1 **Data Commons Literacy** shall mean the ability to understand the Data Commons function of DICE as a governed public-good environment for data discovery, metadata, data-use records, data stewardship, controlled access, public-safe transformation, data quality, lineage, correction, archive, and lawful routing.

14.2.1.2 Data Commons literacy shall include awareness of:\
(a) open data;\
(b) public-safe data;\
(c) controlled public data;\
(d) restricted data;\
(e) metadata-only records;\
(f) sensitive data classes;\
(g) access classes;\
(h) data-use labels;\
(i) AI-use labels;\
(j) lineage;\
(k) quality review;\
(l) correction and archive.

14.2.1.3 Data Commons literacy shall train participants to understand that a commons is not an unrestricted pool. DICE shall be treated as a governed commons where openness is conditioned by rights, safety, privacy, sovereignty, sensitivity, and public-good purpose.

14.2.1.4 Data Commons literacy shall not create data ownership, open data permission, dataset reuse rights, API access rights, secure-room access, public authority status, or handoff permission by implication.

### **14.2.2 Innovation Commons Literacy.**

14.2.2.1 **Innovation Commons Literacy** shall mean the ability to understand DICE as a governed space for reusable innovation objects, including challenge briefs, method notes, evidence packs, prototypes, models, software components, dashboards, Studio workflows, learning objects, public-safe summaries, National Portfolio objects, Foundry outputs, and handoff-context records.

14.2.2.2 Innovation Commons literacy shall include:\
(a) public-good innovation principles;\
(b) anti-capture controls;\
(c) sponsor support without control;\
(d) provider contribution without validation;\
(e) open where safe and controlled where necessary;\
(f) object lifecycle awareness;\
(g) registry and marketplace routing;\
(h) review and release classes;\
(i) correction and archive;\
(j) no-conversion boundaries.

14.2.2.3 Innovation Commons literacy shall not convert participation, contribution, sponsorship, hosting, publication, listing, or demonstration into endorsement, certification, procurement status, financeability, public authority approval, or execution authority.

### **14.2.3 Software Commons Literacy.**

14.2.3.1 **Software Commons Literacy** shall mean the ability to understand public-good software as reusable, governed, versioned, reviewed, documented, licensed, supported, correctable, and boundary-labeled digital public-good infrastructure.

14.2.3.2 Software Commons literacy shall include:\
(a) repository literacy;\
(b) open-source contribution literacy;\
(c) license awareness;\
(d) attribution awareness;\
(e) dependency awareness;\
(f) SBOM awareness;\
(g) secure software basics;\
(h) maintainer roles;\
(i) support classes;\
(j) release notes;\
(k) vulnerability reporting;\
(l) correction and deprecation.

14.2.3.3 Software Commons literacy shall ensure that participants understand that public-good software may be useful, reusable, educational, demonstrable, and handoff-relevant without being warranted, certified, procurement-approved, production-approved, secure by certification, or deployment-authorized.

### **14.2.4 Knowledge Commons Literacy.**

14.2.4.1 **Knowledge Commons Literacy** shall mean the ability to understand public-good knowledge objects, including reports, guides, public-safe summaries, learning materials, method notes, datasets descriptions, model cards, system cards, benchmark cards, scenario records, glossaries, controlled vocabularies, taxonomies, and ontology records.

14.2.4.2 Knowledge Commons literacy shall include:\
(a) open knowledge principles;\
(b) controlled knowledge restrictions;\
(c) citation and attribution;\
(d) versioning;\
(e) public-safe abstraction;\
(f) plain-language accessibility;\
(g) translation and localization;\
(h) protected knowledge exclusion;\
(i) no-reliance notices;\
(j) correction and archive.

14.2.4.3 Knowledge Commons literacy shall not create public authority status, legal advice, professional advice, financial advice, medical advice, emergency warning authority, certification, or unrestricted reuse.

### **14.2.5 Metadata Skills.**

14.2.5.1 **Metadata Skills** shall mean the competence to describe data, software, models, reports, dashboards, credentials, learning objects, Studio workflows, Registry records, Marketplace listings, Grid inputs, TRL notes, and handoff packages in a manner that supports discovery, interpretation, governance, reuse, review, correction, and archive.

14.2.5.2 Metadata skills shall include:\
(a) title and description;\
(b) purpose and scope;\
(c) source class;\
(d) steward identity;\
(e) version;\
(f) license;\
(g) access class;\
(h) data-use label;\
(i) AI-use label;\
(j) sensitivity class;\
(k) review status;\
(l) support class;\
(m) public-safe status;\
(n) correction pathway;\
(o) archive rule.

14.2.5.3 SCF shall train participants that metadata can make an object discoverable, but discoverability does not equal openness, permission, approval, quality assurance, certification, or authority.

### **14.2.6 Data Dictionary Skills.**

14.2.6.1 **Data Dictionary Skills** shall mean the ability to create, read, maintain, and correct structured descriptions of data fields, variables, categories, definitions, units, permissible values, missing-value meanings, coding rules, source notes, sensitivity flags, and quality notes.

14.2.6.2 Data dictionary skills shall support interoperability, DICE, GRIx, DRI, Observatory outputs, Studio workflows, Reports, Marketplace listings, Registry records, Grid inputs, TRL evidence notes, and lawful handoff context.

14.2.6.3 Data dictionary competence shall include the ability to distinguish plain-language definitions, technical definitions, statistical definitions, legal definitions, public authority classifications, and GRIx controlled vocabulary terms.

14.2.6.4 A data dictionary shall not create legal classification, public authority status, data ownership, standards conformance, certification, or unrestricted data rights.

### **14.2.7 Schema Skills.**

14.2.7.1 **Schema Skills** shall mean competence in understanding and supporting structured data, metadata, API, registry, marketplace, evidence, report, credential, proof receipt, Studio workflow, Grid, TRL, and handoff package schemas.

14.2.7.2 Schema skills shall include:\
(a) field structure;\
(b) required and optional fields;\
(c) data types;\
(d) validation rules;\
(e) versioning;\
(f) mapping;\
(g) interoperability;\
(h) localization;\
(i) backward compatibility;\
(j) deprecation and correction.

14.2.7.3 Schema competence shall support interoperability without creating standards authority. A schema may guide structured exchange, but schema conformance shall not constitute certification, legal compliance, public authority approval, procurement status, or deployment authorization by default.

### **14.2.8 Lineage Skills.**

14.2.8.1 **Lineage Skills** shall mean the competence to trace where data, software, models, reports, dashboards, learning objects, AI outputs, risk indicators, Studio workflows, Grid inputs, and handoff packages came from, how they were transformed, who handled them, what assumptions were applied, what reviews occurred, and what limitations remain.

14.2.8.2 Lineage skills shall include:\
(a) source recording;\
(b) transformation recording;\
(c) derivation tracking;\
(d) version tracking;\
(e) dependency mapping;\
(f) contributor records;\
(g) reviewer records;\
(h) AI-use records;\
(i) public-safe transformation records;\
(j) correction propagation.

14.2.8.3 Lineage competence shall support validity-by-record. It shall not convert lineage into endorsement, certification, audit assurance, legal admissibility, public authority approval, or proof of correctness beyond the recorded scope.

### **14.2.9 Data Quality Skills.**

14.2.9.1 **Data Quality Skills** shall mean the ability to identify, describe, assess, and communicate data quality within scope, including completeness, accuracy, timeliness, consistency, representativeness, uncertainty, bias, limitations, provenance, resolution, sensitivity, and fitness for purpose.

14.2.9.2 Data quality skills shall include:\
(a) quality dimensions;\
(b) missingness awareness;\
(c) outlier awareness;\
(d) sampling limitations;\
(e) measurement limitations;\
(f) timeliness;\
(g) uncertainty;\
(h) bias and representativeness;\
(i) public-safe use limits;\
(j) correction needs.

14.2.9.3 Data quality competence shall not certify data quality, guarantee accuracy, authorize public authority reliance, approve AI training, validate models, create financeability, or create legal reliance by default.

### **14.2.10 Data Availability Statement Skills.**

14.2.10.1 **Data Availability Statement Skills** shall mean the competence to write, review, and interpret statements that explain whether data exists, whether it is open, controlled, restricted, unavailable, metadata-only, secure-room-only, data-room-only, handoff-recipient-only, or archive-only.

14.2.10.2 Data availability statements shall identify:\
(a) data title or description;\
(b) data steward;\
(c) access class;\
(d) license or use condition;\
(e) sensitivity status;\
(f) public-safe status;\
(g) AI-use status;\
(h) request pathway where applicable;\
(i) restrictions;\
(j) correction and archive pathway.

14.2.10.3 SCF shall train participants to avoid misleading statements that imply open access, permission, reproducibility, unrestricted reuse, data ownership, or compliance where those conditions have not been reviewed and recorded.

14.2.10.4 A data availability statement shall not itself grant data access, waive restrictions, authorize reuse, permit AI training, override privacy, override protected knowledge controls, or create public authority status.

***

## **14.3 Cybersecurity and Digital Trust Skills**

### **14.3.1 Cyber Hygiene.**

14.3.1.1 **Cyber Hygiene** shall mean foundational competence in safe digital behavior, secure account use, phishing awareness, password and passphrase practices, multi-factor authentication, secure device use, safe file handling, secure collaboration, update discipline, malware awareness, and incident escalation.

14.3.1.2 Cyber hygiene shall be required across SCF learning, WILPs, iCRS participation, Foundry contribution, Campaign administration, Academy participation, Reports drafting, Studio workflows, Marketplace operations, Registry stewardship, secure-room work, and Nexus Universe preparation.

14.3.1.3 Cyber hygiene competence shall not constitute cybersecurity certification, professional qualification, security clearance, secure-system approval, or authority to conduct testing, scanning, monitoring, incident response, or operational defense beyond approved scope.

### **14.3.2 Identity and Access Management Literacy.**

14.3.2.1 **Identity and Access Management Literacy** shall mean the ability to understand user identity, authentication, authorization, least privilege, role-based access, access review, permission expiry, account recovery, privileged access, logging, and access revocation.

14.3.2.2 IAM literacy shall include:\
(a) identity proofing awareness;\
(b) account security;\
(c) multi-factor authentication;\
(d) role-based permissions;\
(e) least privilege;\
(f) access recertification;\
(g) privileged access risks;\
(h) shared-account risks;\
(i) audit logs;\
(j) incident escalation.

14.3.2.3 IAM literacy shall not grant administrative access, security authority, identity verification authority, credential issuer authority, or permission to access restricted systems.

### **14.3.3 Secure Collaboration.**

14.3.3.1 **Secure Collaboration** shall mean the competence to work with others using appropriate controls for documents, data, code, models, dashboards, reports, credentials, public-safe summaries, secure-room outputs, and handoff-context materials.

14.3.3.2 Secure collaboration skills shall include:\
(a) correct sharing settings;\
(b) least-access collaboration;\
(c) version control;\
(d) secure messaging practices;\
(e) confidentiality marking;\
(f) public-safe review before sharing;\
(g) restricted-data handling;\
(h) protected knowledge handling;\
(i) no-download or no-forward rules where applicable;\
(j) correction and recall.

14.3.3.3 Secure collaboration shall not create authority to share beyond approved scope, invite unauthorized participants, disclose protected knowledge, publish drafts, or treat collaborative access as public release.

### **14.3.4 Secure Software Basics.**

14.3.4.1 **Secure Software Basics** shall mean foundational competence in secure development practices, secure configuration, input validation awareness, dependency risk, secret management, access control, logging, vulnerability reporting, safe testing, and secure release.

14.3.4.2 Secure software basics shall apply to public-good software builds, notebooks, APIs, dashboards, connectors, adapters, Studio workflows, data pipelines, AI systems, model evaluation harnesses, and digital public-good objects.

14.3.4.3 Secure software competence shall include:\
(a) secure repository practices;\
(b) code review;\
(c) dependency review;\
(d) secret scanning;\
(e) SBOM literacy;\
(f) vulnerability disclosure;\
(g) threat modeling awareness;\
(h) secure defaults;\
(i) release notes;\
(j) patch and correction discipline.

14.3.4.4 Secure software basics shall not constitute secure coding certification, penetration testing authority, production approval, security certification, warranty, or deployment authorization.

### **14.3.5 SBOM and Dependency Literacy.**

14.3.5.1 **SBOM and Dependency Literacy** shall mean the ability to understand software bills of materials, dependency lists, package provenance, version risk, licensing risk, vulnerability exposure, dependency update needs, transitive dependencies, and support status.

14.3.5.2 SBOM and dependency literacy shall support public-good software governance, repository stewardship, Marketplace listing review, Registry status truth, secure release, vulnerability correction, and lawful handoff context.

14.3.5.3 SBOM literacy shall not certify software security, guarantee absence of vulnerabilities, validate licensing compliance, approve production use, or create procurement status.

### **14.3.6 Incident Response Literacy.**

14.3.6.1 **Incident Response Literacy** shall mean foundational competence in recognizing, reporting, escalating, containing, documenting, and learning from incidents involving data, privacy, cybersecurity, AI, protected knowledge, public-safe outputs, credentials, software, secure rooms, public authority boundaries, finance boundaries, procurement boundaries, sponsor control, provider validation, consent overclaim, or execution overclaim.

14.3.6.2 Incident response literacy shall include:\
(a) incident recognition;\
(b) immediate containment;\
(c) reporting pathway;\
(d) escalation;\
(e) evidence preservation;\
(f) claims freeze where required;\
(g) data freeze where required;\
(h) technical freeze where required;\
(i) correction record;\
(j) archive and after-action learning.

14.3.6.3 Incident response literacy shall not authorize unapproved investigation, system access, forensic activity, public notification, legal determination, emergency command, public warning, or regulated breach notification unless separately assigned by competent authority.

### **14.3.7 Critical Infrastructure Sensitivity.**

14.3.7.1 **Critical Infrastructure Sensitivity** shall mean the ability to recognize when data, diagrams, workflows, vulnerabilities, maps, dashboards, models, sensor records, network records, facility records, or operational context may relate to critical infrastructure and require heightened protection.

14.3.7.2 Critical infrastructure sensitivity shall include awareness of energy, water, transport, telecommunications, health, food, emergency services, public administration, finance, digital infrastructure, industrial systems, data centers, cloud environments, edge nodes, and other mission-critical systems.

14.3.7.3 SCF shall train participants to avoid publishing, sharing, mapping, modeling, or demonstrating sensitive infrastructure information in ways that could create safety, security, operational, public authority, or misuse risks.

14.3.7.4 Critical infrastructure literacy shall not authorize access to infrastructure systems, operational monitoring, vulnerability testing, public warnings, or emergency decisions.

### **14.3.8 OT / IoT / Edge Security Literacy.**

14.3.8.1 **OT / IoT / Edge Security Literacy** shall mean competence in understanding security and resilience risks associated with operational technology, industrial control systems, sensors, IoT devices, IIoT systems, edge nodes, field devices, private wireless systems, robotics, drones, smart infrastructure, and cyber-physical systems.

14.3.8.2 OT / IoT / Edge security literacy shall include:\
(a) device identity awareness;\
(b) network segmentation awareness;\
(c) patching constraints;\
(d) remote access risk;\
(e) sensor integrity;\
(f) data spoofing awareness;\
(g) physical security;\
(h) safety impacts;\
(i) degraded-mode awareness;\
(j) public-safe technical disclosure.

14.3.8.3 OT / IoT / Edge security literacy shall not authorize operational access, device control, penetration testing, system modification, command issuance, deployment, or emergency intervention.

### **14.3.9 AI Security Literacy.**

14.3.9.1 **AI Security Literacy** shall mean the ability to understand security risks arising from AI systems, foundation-model interfaces, retrieval systems, agentic workflows, AI-enabled software, model inputs, prompts, tool permissions, embeddings, training data, evaluation data, outputs, and deployment contexts.

14.3.9.2 AI security literacy shall include:\
(a) prompt-injection awareness;\
(b) data leakage awareness;\
(c) model misuse awareness;\
(d) tool-permission risk;\
(e) retrieval poisoning awareness;\
(f) model and system card literacy;\
(g) agentic workflow controls;\
(h) human review;\
(i) logging and escalation;\
(j) AI incident correction.

14.3.9.3 AI security literacy shall not constitute AI safety certification, cybersecurity certification, model approval, red-team authorization, deployment approval, or automated decision authority.

### **14.3.10 Public-Safe Technical Disclosure.**

14.3.10.1 **Public-Safe Technical Disclosure** shall mean the ability to communicate technical information, including cybersecurity issues, software vulnerabilities, data limitations, AI limitations, system assumptions, infrastructure dependencies, and technical incidents, without enabling misuse, creating panic, misleading the public, overclaiming authority, or bypassing responsible disclosure channels.

14.3.10.2 Public-safe technical disclosure shall include:\
(a) severity awareness;\
(b) audience awareness;\
(c) misuse-risk awareness;\
(d) responsible disclosure pathways;\
(e) sensitive detail restriction;\
(f) no-operational-instruction safeguards;\
(g) no-warning boundary where applicable;\
(h) public-safe summaries;\
(i) correction notices;\
(j) archive discipline.

14.3.10.3 Public-safe technical disclosure shall not replace official security advisories, regulated breach notices, emergency warnings, vulnerability coordination processes, public authority communications, or provider security obligations.

***

## **14.4 Privacy and Data Protection Skills**

### **14.4.1 Privacy Principles.**

14.4.1.1 **Privacy Principles** shall mean foundational competence in privacy, dignity, autonomy, fairness, confidentiality, proportionality, necessity, transparency, accountability, access control, purpose limitation, data minimization, retention limits, correction, deletion, and safe use.

14.4.1.2 Privacy competence shall be embedded in all SCF pathways involving learner records, worker records, contribution records, WILP records, micro-credentials, Skills Wallets, ILA profiles, public display, data commons, secure rooms, AI workflows, Reports, Campaigns, Studio workflows, Marketplace listings, Registry records, and handoff context.

14.4.1.3 Privacy principles shall not be treated as only a legal compliance topic. They shall be taught as practical competence for ethical work, safe data handling, public-good legitimacy, community trust, youth protection, worker protection, and technical trust.

14.4.1.4 Privacy competence shall not constitute legal advice, compliance certification, privacy officer authority, data protection officer authority, or public authority approval.

### **14.4.2 Consent and Permission Literacy.**

14.4.2.1 **Consent and Permission Literacy** shall mean the ability to understand the difference between participation, notice, consent, permission, authorization, license, access, disclosure, reuse, publication, AI use, and lawful handoff.

14.4.2.2 Consent and permission literacy shall include:\
(a) informed consent awareness;\
(b) purpose-specific consent;\
(c) withdrawal awareness;\
(d) permission scope;\
(e) data-use restrictions;\
(f) community consent boundaries;\
(g) Indigenous consent and protocol sensitivity where applicable;\
(h) youth and guardian considerations;\
(i) public display permissions;\
(j) correction and withdrawal requests.

14.4.2.3 SCF shall ensure that participants understand that attendance, participation, contribution, survey response, data submission, public display, campaign signature, WILP participation, community meeting, or Nexus Universe participation shall not imply unlimited data use, community consent, Indigenous consent, AI training permission, publication permission, or handoff permission.

### **14.4.3 Data Minimization.**

14.4.3.1 **Data Minimization** shall mean the competence to collect, retain, process, display, publish, and hand off only the data reasonably required for a recorded purpose and scope.

14.4.3.2 Data minimization skills shall include:\
(a) purpose review;\
(b) field necessity review;\
(c) sensitive data avoidance;\
(d) aggregation where appropriate;\
(e) pseudonymization awareness;\
(f) anonymization limitations;\
(g) retention limits;\
(h) no-download controls where appropriate;\
(i) public-safe abstraction;\
(j) deletion and sealing pathways.

14.4.3.3 Data minimization competence shall reduce unnecessary exposure of learners, workers, communities, youth, protected knowledge, public authority-sensitive data, health data, geospatial data, infrastructure data, and handoff-sensitive materials.

### **14.4.4 Purpose Limitation.**

14.4.4.1 **Purpose Limitation** shall mean the competence to use data only for the purpose recorded, permitted, reviewed, and communicated, and to avoid secondary use unless separately reviewed and authorized.

14.4.4.2 Purpose limitation skills shall include:\
(a) purpose statement drafting;\
(b) use-case boundaries;\
(c) secondary-use identification;\
(d) AI-use limitation;\
(e) training-use limitation;\
(f) sharing limitation;\
(g) publication limitation;\
(h) handoff limitation;\
(i) correction when purpose drift occurs;\
(j) archive controls.

14.4.4.3 Purpose limitation competence shall prevent learning records, worker records, community data, public authority learning data, protected knowledge, and secure-room outputs from being repurposed into profiling, ranking, surveillance, marketing, employment screening, provider validation, finance signals, procurement signals, or public authority decisions by implication.

### **14.4.5 Sensitive Data Handling.**

14.4.5.1 **Sensitive Data Handling** shall mean competence in identifying and protecting data whose disclosure, misuse, linkage, reidentification, or improper interpretation could harm individuals, communities, public authorities, infrastructure, ecosystems, organizations, or public trust.

14.4.5.2 Sensitive data may include:\
(a) personal data;\
(b) youth data;\
(c) health data;\
(d) worker data;\
(e) learner records;\
(f) community-sensitive data;\
(g) Indigenous protocol-sensitive knowledge where applicable;\
(h) protected knowledge;\
(i) geospatial-sensitive data;\
(j) infrastructure-sensitive data;\
(k) cyber-sensitive data;\
(l) financial or insurance-sensitive context;\
(m) public authority-sensitive information;\
(n) handoff-recipient-only information.

14.4.5.3 Sensitive data handling shall require appropriate classification, access controls, minimization, secure collaboration, no-download rules where applicable, secure-room routing, public-safe transformation, review, correction, and archive.

14.4.5.4 Sensitive data competence shall not authorize access, disclosure, publication, AI training, export, or handoff.

### **14.4.6 Youth Data Protection.**

14.4.6.1 **Youth Data Protection** shall mean competence in protecting data relating to children, youth, students, early-career learners, and vulnerable young participants in SCF, Nexus Academy, Risk Academy, WILPs, Campaigns, Competence Cells, ILA, iCRS, Marketplace displays, Registry records, and Nexus Universe participation.

14.4.6.2 Youth data protection skills shall include:\
(a) minimization;\
(b) guardian or institutional permission awareness where applicable;\
(c) safe profile display;\
(d) restricted public visibility;\
(e) anti-exploitation safeguards;\
(f) harassment and abuse prevention;\
(g) no automated ranking;\
(h) AI-use restrictions;\
(i) deletion and withdrawal pathways;\
(j) incident reporting.

14.4.6.3 Youth data protection competence shall not create legal authority to process youth data, publish youth profiles, disclose youth achievements, or share youth data with employers, sponsors, providers, public authorities, or downstream recipients without appropriate permissions and safeguards.

### **14.4.7 Health Data Protection.**

14.4.7.1 **Health Data Protection** shall mean competence in recognizing and protecting health-related data, including clinical data, public health data, climate-health data, disability-related data, mental health context, exposure data, disease-risk context, One Health information, and health-sensitive community information.

14.4.7.2 Health data protection skills shall include:\
(a) sensitivity recognition;\
(b) access controls;\
(c) minimization;\
(d) de-identification limitations;\
(e) public-safe aggregation;\
(f) secure-room routing;\
(g) AI-use restrictions;\
(h) public authority boundary awareness;\
(i) incident reporting;\
(j) correction and archive.

14.4.7.3 Health data protection competence shall not authorize medical advice, clinical decision-making, public health declarations, disease surveillance authority, health data access, or public warning authority.

### **14.4.8 Community Data Protection.**

14.4.8.1 **Community Data Protection** shall mean competence in protecting information relating to communities, neighborhoods, Indigenous peoples where applicable, informal settlements, rural communities, displaced populations, vulnerable groups, livelihoods, local risks, place-based knowledge, community priorities, and local resilience conditions.

14.4.8.2 Community data protection skills shall include:\
(a) non-extractive data practices;\
(b) community context awareness;\
(c) consent boundary literacy;\
(d) protected knowledge controls;\
(e) Indigenous protocol-sensitive controls where applicable;\
(f) sensitive location controls;\
(g) aggregation and masking;\
(h) language and accessibility;\
(i) community-facing correction;\
(j) safe archive.

14.4.8.3 Community data protection competence shall prevent SCF learning, Campaigns, Reports, Studio exercises, DRI dashboards, Observatory outputs, or Marketplace listings from turning community information into surveillance, stigma, ranking, exploitation, commercial extraction, or consent overclaim.

### **14.4.9 Cross-Border Data Literacy.**

14.4.9.1 **Cross-Border Data Literacy** shall mean the ability to understand that data movement across jurisdictions may trigger legal, institutional, sovereignty, security, privacy, contractual, ethical, public authority, community, or protected knowledge concerns.

14.4.9.2 Cross-border data literacy shall include:\
(a) data residency awareness;\
(b) data localization awareness;\
(c) sovereign data zone awareness;\
(d) transfer restriction awareness;\
(e) cloud hosting awareness;\
(f) remote access awareness;\
(g) compute-to-data alternatives;\
(h) secure-room routing;\
(i) public-safe summaries;\
(j) escalation and review.

14.4.9.3 Cross-border data literacy shall not authorize transfer, export, remote access, cloud processing, AI processing, or publication of restricted data.

### **14.4.10 Data Incident Reporting.**

14.4.10.1 **Data Incident Reporting** shall mean competence in recognizing and escalating suspected or confirmed data incidents, including unauthorized access, unauthorized disclosure, improper publication, AI misuse, data leakage, cross-border transfer concern, protected knowledge exposure, youth data exposure, health data exposure, community data misuse, incorrect data, corrupted data, misleading dashboard output, or unlawful handoff.

14.4.10.2 Data incident reporting skills shall include:\
(a) immediate containment awareness;\
(b) reporting pathway;\
(c) evidence preservation;\
(d) confidentiality during escalation;\
(e) claims freeze where required;\
(f) data freeze where required;\
(g) public-safe notice routing;\
(h) correction record creation;\
(i) withdrawal or recall support;\
(j) archive and after-action learning.

14.4.10.3 Data incident reporting competence shall not authorize legal breach determination, public notification, system forensics, disciplinary action, regulatory filing, or public authority decision unless separately assigned by competent actors.

***

## **14.5 Secure-Room and Controlled-Access Skills**

### **14.5.1 Data Room Literacy.**

14.5.1.1 **Data Room Literacy** shall mean competence in using a controlled environment for access to bounded data, documents, evidence packs, diligence materials, public authority learning materials, readiness materials, handoff-context records, and restricted review objects.

14.5.1.2 Data Room literacy shall include:\
(a) access purpose;\
(b) participant roles;\
(c) document classes;\
(d) access restrictions;\
(e) download restrictions;\
(f) confidentiality obligations;\
(g) permitted notes;\
(h) output review;\
(i) audit logs;\
(j) correction and archive.

14.5.1.3 Data Room access shall not imply data ownership, reuse permission, publication permission, finance approval, insurance approval, procurement status, public authority approval, or handoff authorization.

### **14.5.2 Secure Room Literacy.**

14.5.2.1 **Secure Room Literacy** shall mean competence in working within a controlled environment for sensitive data, secure workflows, restricted materials, protected knowledge, cyber-sensitive information, infrastructure-sensitive information, sovereign-sensitive data, or public authority-sensitive materials.

14.5.2.2 Secure Room literacy shall require understanding of identity checks, least privilege, session controls, no-download rules, no-copy rules, output review, logging, escalation, incident reporting, and correction.

14.5.2.3 Secure Room literacy shall not authorize participants to remove, disclose, reproduce, train AI on, transfer, or operationalize secure-room contents.

### **14.5.3 Clean Room Literacy.**

14.5.3.1 **Clean Room Literacy** shall mean competence in understanding environments where data or analysis can be compared, matched, queried, evaluated, or aggregated under controlled conditions without unrestricted disclosure of underlying data.

14.5.3.2 Clean Room literacy shall include:\
(a) approved workload awareness;\
(b) approved user awareness;\
(c) query limitations;\
(d) aggregation thresholds;\
(e) output review;\
(f) privacy-preserving processing;\
(g) no raw export;\
(h) audit records;\
(i) cross-party trust boundaries;\
(j) incident escalation.

14.5.3.3 Clean Room participation shall not create data access rights, data sharing rights, AI training rights, commercial rights, public authority approval, finance approval, insurance approval, or legal compliance determination.

### **14.5.4 Protected Knowledge Room Literacy.**

14.5.4.1 **Protected Knowledge Room Literacy** shall mean competence in handling knowledge that requires heightened ethical, community, Indigenous, cultural, ecological, security, privacy, or legal protection.

14.5.4.2 Protected Knowledge Room literacy shall include:\
(a) recognition of protected knowledge;\
(b) custodian and permission awareness;\
(c) cultural and community context;\
(d) Indigenous protocol-sensitive controls where applicable;\
(e) no-download controls;\
(f) no-publication controls;\
(g) restricted note-taking;\
(h) public-safe abstraction;\
(i) community-facing correction;\
(j) archive restrictions.

14.5.4.3 Protected Knowledge Room competence shall not authorize disclosure, publication, commercialization, translation, modeling, mapping, training, transfer, or handoff of protected knowledge unless separately and lawfully permitted.

### **14.5.5 Public Authority Learning Room Literacy.**

14.5.5.1 **Public Authority Learning Room Literacy** shall mean competence in participating in controlled learning environments involving public authorities, policy questions, regulatory context, emergency management context, infrastructure context, public finance context, or public-interest decision contexts without converting participation into official action.

14.5.5.2 Public Authority Learning Room literacy shall include:\
(a) non-decision status;\
(b) no public authority substitution;\
(c) no public warning authority;\
(d) no regulatory approval;\
(e) no procurement implication;\
(f) no public finance allocation;\
(g) public-safe reporting;\
(h) records discipline;\
(i) escalation where official action is needed;\
(j) correction and archive.

14.5.5.3 Public Authority Learning Room participation shall not create public authority decisions, official approvals, policy adoption, procurement status, emergency command, public warning, funding allocation, or legal reliance by implication.

### **14.5.6 No-Download Controls.**

14.5.6.1 **No-Download Controls** shall mean restrictions preventing participants from downloading, exporting, copying, photographing, scraping, syncing, forwarding, training on, or otherwise removing controlled content from a governed environment.

14.5.6.2 No-download competence shall include understanding:\
(a) why download is restricted;\
(b) what objects are restricted;\
(c) whether notes are permitted;\
(d) whether summaries are permitted;\
(e) whether AI tools are prohibited;\
(f) whether screenshots are prohibited;\
(g) whether outputs require review;\
(h) incident consequences;\
(i) correction duties;\
(j) archive rules.

14.5.6.3 No-download controls shall not be bypassed by convenience, collaboration pressure, sponsor request, provider request, public authority presence, capital-reader interest, learner need, or downstream handoff interest.

### **14.5.7 Output Review.**

14.5.7.1 **Output Review** shall mean the process of reviewing outputs created from controlled data, secure-room work, AI workflows, clean-room queries, compute-to-data processing, Studio workflows, dashboards, Reports, or public-safe summaries before release, display, publication, sharing, or handoff.

14.5.7.2 Output review shall include:\
(a) source review;\
(b) sensitivity review;\
(c) privacy review;\
(d) AI-use review;\
(e) protected knowledge review;\
(f) public authority boundary review;\
(g) finance and procurement boundary review;\
(h) public-safe language review;\
(i) correction pathway review;\
(j) archive rule review.

14.5.7.3 Output review shall not constitute certification, public authority approval, legal approval, security certification, finance approval, insurance approval, or deployment approval by default.

### **14.5.8 Audit Logs and Access Records.**

14.5.8.1 **Audit Logs and Access Records** shall mean records showing who accessed what, when, under what role, for what purpose, with what permissions, and with what outputs or actions.

14.5.8.2 Audit log competence shall include:\
(a) access record awareness;\
(b) purpose record awareness;\
(c) session logging awareness;\
(d) export logging awareness;\
(e) output logging awareness;\
(f) privileged access awareness;\
(g) review and recertification;\
(h) incident escalation;\
(i) retention and deletion;\
(j) archive.

14.5.8.3 Audit log literacy shall not authorize surveillance, worker monitoring beyond approved purpose, public disclosure of access logs, disciplinary conclusions, or legal determinations by default.

### **14.5.9 Compute-to-Data Workflows.**

14.5.9.1 **Compute-to-Data Workflows** shall mean controlled processing arrangements where approved computation occurs in relation to restricted or sensitive data while raw data remains within a controlled environment.

14.5.9.2 Compute-to-data workflow competence shall include:\
(a) workload proposal;\
(b) user authorization;\
(c) query approval;\
(d) tool restrictions;\
(e) AI-use restrictions;\
(f) no raw extraction;\
(g) output review;\
(h) logging;\
(i) incident response;\
(j) correction and archive.

14.5.9.3 Compute-to-data workflows shall be preferred where raw data export would create unacceptable privacy, sovereignty, protected knowledge, public authority, cyber, health, youth, community, geospatial, infrastructure, or cross-border risk.

### **14.5.10 Controlled Output Publication.**

14.5.10.1 **Controlled Output Publication** shall mean the publication of reviewed, public-safe, bounded, and authorized outputs derived from controlled environments, secure rooms, data rooms, clean rooms, compute-to-data workflows, Studio workflows, or restricted data sources.

14.5.10.2 Controlled output publication shall require:\
(a) output scope;\
(b) review record;\
(c) public-safe transformation;\
(d) sensitivity clearance within scope;\
(e) no-warning language where applicable;\
(f) no-approval language;\
(g) no-finance language;\
(h) no-procurement language;\
(i) no-certification language;\
(j) correction notice.

14.5.10.3 Controlled output publication shall not imply that underlying data is open, that raw data may be accessed, that outputs are certified, that public authority has approved the content, or that downstream actors may rely on it for regulated decisions without independent review.

***

## **14.6 Software and Public-Good Technical Skills**

### **14.6.1 Open-Source Contribution.**

14.6.1.1 **Open-Source Contribution** shall mean competence in contributing to public-good software, documentation, data tools, dashboards, notebooks, APIs, schemas, tests, translations, accessibility improvements, issue reports, reviews, and maintenance workflows within governed repositories.

14.6.1.2 Open-source contribution competence shall include:\
(a) repository navigation;\
(b) issue and pull request literacy;\
(c) contribution guidelines;\
(d) code of conduct;\
(e) license awareness;\
(f) attribution;\
(g) review discipline;\
(h) security awareness;\
(i) support class awareness;\
(j) correction and archive.

14.6.1.3 Open-source contribution shall not create employment, compensation, equity, token rights, maintainer authority, warranty, provider validation, procurement qualification, deployment authorization, or execution authority by implication.

### **14.6.2 Public-Good Software Maintenance.**

14.6.2.1 **Public-Good Software Maintenance** shall mean competence in sustaining public-good software through issue triage, dependency updates, documentation updates, release notes, security patches, support classification, deprecation, correction, archive, and continuity planning.

14.6.2.2 Maintenance competence shall include:\
(a) maintainer role awareness;\
(b) backlog triage;\
(c) release discipline;\
(d) dependency awareness;\
(e) vulnerability response;\
(f) user support boundaries;\
(g) support classes;\
(h) versioning;\
(i) deprecation;\
(j) archive and non-continuation.

14.6.2.3 Maintenance competence shall not create warranty, service-level guarantee, certification authority, employment status, procurement status, or operational responsibility beyond recorded scope.

### **14.6.3 API and SDK Literacy.**

14.6.3.1 **API and SDK Literacy** shall mean competence in understanding application programming interfaces, software development kits, connectors, adapters, authentication, authorization, rate limits, data minimization, versioning, deprecation, documentation, support status, and security responsibilities.

14.6.3.2 API and SDK literacy shall include:\
(a) endpoint purpose;\
(b) data returned;\
(c) authentication;\
(d) authorization;\
(e) error handling;\
(f) rate limits;\
(g) versioning;\
(h) data-use restrictions;\
(i) security controls;\
(j) no-data-right boundaries.

14.6.3.3 API availability shall not create data rights, unrestricted access, provider validation, standards conformance, production approval, or deployment authorization.

### **14.6.4 Notebook and Reproducibility Skills.**

14.6.4.1 **Notebook and Reproducibility Skills** shall mean competence in creating, reviewing, and using computational notebooks, scripts, workflows, data references, model references, environment files, dependency records, result notes, and reproducibility packages.

14.6.4.2 Reproducibility skills shall include:\
(a) source recording;\
(b) environment recording;\
(c) dependency recording;\
(d) execution notes;\
(e) data availability statements;\
(f) parameter documentation;\
(g) uncertainty notes;\
(h) public-safe output;\
(i) review status;\
(j) correction and archive.

14.6.4.3 Reproducibility competence shall not guarantee results, certify methods, authorize data access, approve models, or create legal reliance.

### **14.6.5 Dashboard Development Skills.**

14.6.5.1 **Dashboard Development Skills** shall mean competence in designing, building, reviewing, documenting, and maintaining dashboards for learning, public-safe reporting, risk intelligence, National Portfolios, Campaigns, Foundry outputs, Studio workflows, Marketplace discovery, Registry status, Grid review, or Nexus Universe outputs.

14.6.5.2 Dashboard skills shall include:\
(a) data source review;\
(b) metric definition;\
(c) visualization literacy;\
(d) uncertainty display;\
(e) accessibility;\
(f) public-safe language;\
(g) sensitive location masking;\
(h) update cadence;\
(i) correction notices;\
(j) archive labels.

14.6.5.3 Dashboard development competence shall not create official decision support, public warning authority, public authority approval, rating, ranking, finance signal, insurance score, procurement status, or operational command.

### **14.6.6 Model Card and System Card Skills.**

14.6.6.1 **Model Card and System Card Skills** shall mean competence in documenting AI models, statistical models, risk models, forecasting models, simulation models, agentic workflows, retrieval systems, decision-support tools, and AI-enabled systems.

14.6.6.2 Model and system card skills shall include:\
(a) intended use;\
(b) prohibited use;\
(c) data provenance;\
(d) training or development constraints;\
(e) evaluation scope;\
(f) limitations;\
(g) bias and harm considerations;\
(h) human review requirements;\
(i) security risks;\
(j) withdrawal and correction pathways.

14.6.6.3 Model and system cards shall not constitute AI safety certification, general validation, public authority approval, deployment authorization, financial suitability, insurance suitability, procurement readiness, or legal compliance.

### **14.6.7 Benchmark Card Skills.**

14.6.7.1 **Benchmark Card Skills** shall mean competence in documenting benchmarks, evaluation datasets, metrics, test conditions, limitations, scope, relevance, representativeness, uncertainty, and misuse risks.

14.6.7.2 Benchmark card skills shall include:\
(a) benchmark purpose;\
(b) dataset source;\
(c) metric definition;\
(d) test environment;\
(e) limitation statement;\
(f) bias and representativeness notes;\
(g) reproducibility notes;\
(h) public-safe interpretation;\
(i) comparison boundaries;\
(j) correction and archive.

14.6.7.3 Benchmark results shall not create general validation, certification, model approval, procurement readiness, financeability, insurability, or deployment authorization.

### **14.6.8 Release Notes and Changelog Skills.**

14.6.8.1 **Release Notes and Changelog Skills** shall mean competence in documenting changes to software, data, models, reports, dashboards, Studio workflows, credentials, Registry records, Marketplace listings, Grid inputs, TRL notes, and handoff-context packages.

14.6.8.2 Release notes and changelog competence shall include:\
(a) version identification;\
(b) change summary;\
(c) added features;\
(d) removed features;\
(e) fixed issues;\
(f) known limitations;\
(g) security notes;\
(h) data or model changes;\
(i) migration notes;\
(j) correction or withdrawal notes.

14.6.8.3 Release notes shall not create warranty, certification, compliance approval, security approval, procurement approval, deployment approval, or public authority approval.

### **14.6.9 Vulnerability Reporting Skills.**

14.6.9.1 **Vulnerability Reporting Skills** shall mean competence in recognizing, documenting, responsibly reporting, and escalating suspected security weaknesses in software, data systems, APIs, dashboards, repositories, AI workflows, secure rooms, infrastructure, or digital public-good objects.

14.6.9.2 Vulnerability reporting skills shall include:\
(a) scope awareness;\
(b) safe reproduction boundaries;\
(c) no-exploitation rule;\
(d) responsible disclosure;\
(e) sensitive detail restriction;\
(f) evidence preservation;\
(g) maintainer notification;\
(h) public-safe communication;\
(i) correction tracking;\
(j) archive.

14.6.9.3 Vulnerability reporting competence shall not authorize penetration testing, exploitation, public disclosure, operational scanning, system access, emergency command, or public warning.

### **14.6.10 No-Warranty and Support-Class Literacy.**

14.6.10.1 **No-Warranty and Support-Class Literacy** shall mean competence in understanding whether a software object, data object, model object, dashboard, API, learning object, report, Studio workflow, Marketplace listing, Registry record, Grid input, TRL note, or handoff package is unsupported, community-supported, maintainer-supported, Academy-supported, Foundry-supported, National Node-supported, Studio-supported, handoff-recipient-supported, time-limited, deprecated, withdrawn, or archived.

14.6.10.2 Support-class literacy shall include:\
(a) support status;\
(b) maintainer identity;\
(c) response expectations;\
(d) known issues;\
(e) end-of-support notices;\
(f) deprecation notices;\
(g) security update status;\
(h) user responsibilities;\
(i) correction pathway;\
(j) archive status.

14.6.10.3 Support status shall not create warranty, service-level guarantee, procurement eligibility, production approval, provider validation, certification, or execution responsibility by default.

***

## **14.7 Data and Technical Boundary Rules**

### **14.7.1 Data Skill Is Not Data Access Right.**

14.7.1.1 No data skill, data literacy record, data stewardship record, DICE skill, metadata skill, data dictionary skill, schema skill, lineage skill, data quality skill, data availability statement skill, secure-room skill, compute-to-data skill, or privacy skill shall create a right to access, download, copy, export, reuse, disclose, publish, commercialize, transfer, or train AI systems on data.

14.7.1.2 Data access must be separately authorized under applicable permissions, licenses, consent, institutional controls, public authority requirements, community protocols, Indigenous protocols where applicable, protected knowledge controls, privacy controls, cybersecurity controls, and cross-border transfer rules.

### **14.7.2 Metadata Skill Is Not Open Data Permission.**

14.7.2.1 Metadata competence, metadata publication, metadata display, data dictionary availability, schema availability, data availability statement, Registry record, Marketplace listing, or public-safe summary shall not imply that underlying data is open, reusable, downloadable, exportable, or available for AI training.

14.7.2.2 Metadata may support discovery and interpretation, but access to underlying data remains governed by recorded rights, restrictions, sensitivity classes, access classes, and review pathways.

### **14.7.3 Cyber Literacy Is Not Security Certification by Default.**

14.7.3.1 Cyber hygiene, IAM literacy, secure collaboration, secure software basics, SBOM literacy, dependency literacy, incident response literacy, critical infrastructure sensitivity, OT / IoT / Edge security literacy, AI security literacy, or public-safe technical disclosure competence shall not constitute cybersecurity certification, professional qualification, security clearance, secure-system approval, penetration testing authority, audit assurance, or legal compliance determination by default.

14.7.3.2 Security certification, regulated assurance, accreditation, penetration testing authority, incident response authority, and compliance determinations must be separately and lawfully established by competent actors.

### **14.7.4 Software Contribution Is Not Deployment Approval.**

14.7.4.1 No software contribution, repository commit, pull request, issue report, code review, notebook, dashboard, API, SDK, connector, adapter, model card, benchmark card, release note, changelog, Marketplace listing, Registry record, Grid input, TRL note, or Foundry build shall constitute deployment approval by default.

14.7.4.2 Deployment decisions remain outside SCF and must be made by competent lawful actors with appropriate technical, legal, operational, security, public authority, procurement, finance, insurance, community, and safeguard review.

### **14.7.5 AI-Use Competence Is Not AI System Certification.**

14.7.5.1 AI-use label competence, model card literacy, system card literacy, benchmark card literacy, agentic workflow literacy, AI security literacy, AI evaluation literacy, prompt-injection awareness, red-team awareness, or human review competence shall not constitute AI safety certification, AI management-system certification, model approval, system approval, automated decision authority, public authority approval, procurement readiness, financeability, insurability, or deployment authorization.

14.7.5.2 AI system certification, regulated approval, conformity assessment, professional assurance, procurement approval, and public authority use decisions must be separately and lawfully established where applicable.

### **14.7.6 Secure-Room Participation Is Not Public Authority Approval.**

14.7.6.1 Participation in a Data Room, Secure Room, Clean Room, Protected Knowledge Room, Public Authority Learning Room, Readiness Room, Capital-Reader Room, Insurance-Reader Room, Donor-Reader Room, AI Review Room, Cyber Review Room, or Studio-controlled environment shall not imply public authority approval, official action, finance approval, insurance approval, donor commitment, procurement status, certification, community consent, Indigenous consent, data access right, disclosure permission, or execution authority.

14.7.6.2 Secure-room participation shall remain bounded by recorded purpose, access class, role, permitted outputs, confidentiality obligations, public-safe review, correction pathway, and archive rule.

***

## **14.8 Final Part XIV Operating Statement**

14.8.1 SCF shall treat DICE, data skills, digital commons, cybersecurity, privacy, secure rooms, compute-to-data, software contribution, and technical trust competencies as core workforce and public-good capabilities required for Nexus learning, contribution, R\&D, National Portfolios, Nexus Foundry, Nexus Studio, Nexus Reports, Nexus Marketplace, Nexus Registry, Nexus Grid, Nexus Universe, Nexus Observatory, DRI, GRIx, lawful handoff, correction, and archive.

14.8.2 SCF shall ensure that data competence includes data literacy, data stewardship, data governance, data ethics, AI-use labels, compute-to-data literacy, secure-room work literacy, and the non-conversion rule that data competence does not create data rights by default.

14.8.3 SCF shall structure DICE skills across Data Commons, Innovation Commons, Software Commons, Knowledge Commons, metadata, data dictionaries, schemas, lineage, data quality, and data availability statements, ensuring that commons participation remains governed, rights-aware, public-safe, correctionable, and protected from extraction or capture.

14.8.4 SCF shall structure cybersecurity and digital trust skills across cyber hygiene, identity and access management, secure collaboration, secure software basics, SBOM and dependency literacy, incident response literacy, critical infrastructure sensitivity, OT / IoT / Edge security literacy, AI security literacy, and public-safe technical disclosure.

14.8.5 SCF shall structure privacy and data protection skills across privacy principles, consent and permission literacy, data minimization, purpose limitation, sensitive data handling, youth data protection, health data protection, community data protection, cross-border data literacy, and data incident reporting.

14.8.6 SCF shall structure secure-room and controlled-access skills across Data Rooms, Secure Rooms, Clean Rooms, Protected Knowledge Rooms, Public Authority Learning Rooms, no-download controls, output review, audit logs, access records, compute-to-data workflows, and controlled output publication.

14.8.7 SCF shall structure software and public-good technical skills across open-source contribution, public-good software maintenance, API and SDK literacy, notebook and reproducibility skills, dashboard development skills, model card and system card skills, benchmark card skills, release notes, changelog skills, vulnerability reporting, no-warranty literacy, and support-class literacy.

14.8.8 The final rule of Part XIV is that SCF shall make Nexus learners, workers, contributors, reviewers, mentors, Competence Cells, National Working Groups, public authority learning participants, employers, providers, sponsors, and lawful downstream actors more technically competent, data-literate, privacy-aware, cyber-aware, AI-aware, secure-room-capable, public-safe, and correctionable, but shall not convert any data skill, cyber skill, software skill, AI-use skill, secure-room participation, metadata record, Marketplace listing, Registry record, DICE object, Studio output, Grid input, TRL note, or handoff-context package into data access rights, open data permission, security certification, AI system certification, public authority approval, procurement status, financeability, insurability, deployment authorization, community consent, Indigenous consent, or execution authority by implication.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/sustainable-competency-framework-scf/xiv.-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.