# XV. COMPETENCE

This section defines competence in Nexus as the governed record of learning, contribution, review, practice, and role capability across public-good work.

It explains how SCF structures competency families, learning accounts, micro-credentials, work-integrated learning, contribution recognition, labor-market intelligence, career mobility, and AI-era skills across Academy, Foundry, Campaigns, National Portfolios, Nexus Universe, and lawful handoff. It also sets the core boundary rule: competence records may support learning, routing, review, recognition, and recipient diligence, but they do not become licensure, employment, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.1 SCF Within Nexus

### 15.1.1 SCF as Competence Layer of Nexus

The Sustainable Competency Framework (SCF) is the competence layer of Nexus Ecosystem. It defines how knowledge, skills, practices, roles, learning records, contribution records, review records, work-integrated learning, micro-credentials where applicable, public-good capability, workforce transition, labor-market intelligence, and lawful handoff competence are structured, recorded, reviewed, corrected, and archived across Nexus.

SCF exists because Nexus cannot be delivered through institutions, platforms, reports, campaigns, dashboards, models, software, or portfolios alone. It requires people and teams with the capability to understand risk, evidence, data, AI, cyber, geospatial systems, WFEH-B systems, DRR, DRF, DRI, public-safe reporting, public authority learning, finance-readiness literacy, insurance-readiness literacy, safeguards, correctionability, non-execution, and lawful handoff boundaries.

SCF should connect:

1. Nexus Academy, as the general learning and capability engine;
2. Risk Academy, as the risk-literacy and systems-risk capability engine;
3. Foundry and BuildGrid, as the applied work, quest, bounty, build, maintainer, and contributor capability environment;
4. Campaigns, as the mobilization, volunteer, learning, ambassador, chapter, and public-good participation capability surface;
5. National Portfolios, as the country-level human-capability planning and competence-record layer;
6. Nexus Universe, as the annual talent, competence, learning, build, review, and surge-capacity arena;
7. Competence Cells and Working Groups, as applied national, regional, thematic, sectoral, and technical competence units;
8. Lawful handoff pathways, as competence context for separate actors who may later receive Nexus public-good objects.

SCF is not a generic training catalogue. It is the human-capability operating layer that makes Nexus work trustworthy, repeatable, localized, scalable, and correctionable. SCF records competence; it does not create professional licensing, employment guarantee, public authority qualification, procurement qualification, finance qualification, insurance qualification, immigration status, wage entitlement, certification, consent authority, deployment authority, or execution authority by implication.

### 15.1.2 SCF as Learning Spine of Nexus Academy

SCF is the learning spine of Nexus Academy. Nexus Academy uses SCF to translate Nexus doctrines, frameworks, portfolios, technologies, risk-intelligence objects, public-good software, Campaigns, Reports, Studio workflows, Grid and TRL records, National Portfolio objects, Nexus Universe outputs, and handoff-dependency records into structured learning pathways.

Nexus Academy learning should not be random content production. It should be mapped to SCF competency domains, levels, learning outcomes, evidence of learning, contribution pathways, review requirements, public-safe boundaries, accessibility needs, localization needs, and correction pathways. Each Academy module, cohort, micro-course, workshop, work-integrated learning program, simulation exercise, Studio exercise, Campaign learning pathway, or contributor onboarding pathway should identify what competence it develops and how that competence is recorded.

SCF-linked Nexus Academy pathways should include:

1. foundational Nexus literacy, including Nexus doctrines, role separation, public-good stack, enterprise stack, one rail, Dockets, records, proof receipts, Registry, Marketplace, Grid, Studio, Reports, Campaigns, National Portfolios, Nexus Universe, and lawful handoff;
2. data, AI, cyber, and digital public-good literacy, including DICE, data-use labels, AI-use labels, public-good software, secure release, model cards, system cards, agentic workflow controls, privacy, cybersecurity, and correction;
3. risk and resilience literacy, including GRIx, DRI, Observatory, WFEH-B, DRR, DRF, systems risk, degraded-mode awareness, public-safe reporting, and scenario learning;
4. participation and contribution literacy, including volunteer work, learning work, bounty-supported work, stipend-supported work, contribution records, review records, support records, community participation, public authority learning, and no-execution boundaries;
5. portfolio and handoff literacy, including National Portfolio records, readiness questions, Grid and TRL inputs, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance learning, safeguard records, and handoff dependency packages.

Nexus Academy may issue learning records, participation records, proof receipts, competency records, and micro-credential inputs where applicable. Those records document learning within Nexus scope. They do not create licensure, professional certification, public authority status, procurement qualification, finance qualification, insurance qualification, employment entitlement, deployment authority, or execution authority unless a separate competent body lawfully issues such status through a separate recorded process.

### 15.1.3 SCF as Risk-Literacy Spine of Risk Academy

SCF is the risk-literacy spine of Risk Academy. Risk Academy uses SCF to define the competencies required to understand, communicate, review, and apply risk intelligence across disaster risk reduction, disaster risk finance literacy, disaster risk intelligence, WFEH-B systems, systems risk, frontier technology risk, public authority learning, public-safe reporting, finance-readiness questions, insurance-readiness questions, safeguards, and lawful handoff dependencies.

Risk literacy in Nexus must be deeper than general awareness. It must allow participants to distinguish signal from warning, indicator from rating, dashboard from decision, scenario from forecast certainty, Observatory signal from surveillance authority, GRIx category from legal classification, DRI output from insurance score or investment signal, and readiness question from approval.

SCF-linked Risk Academy pathways should develop competence in:

1. risk ontology and interpretation, including GRIx categories, WFEH-B taxonomies, DRR categories, DRF categories, DRI categories, systems-risk categories, frontier technology risk categories, safeguard categories, and handoff dependency categories;
2. risk-intelligence review, including data review, method review, indicator review, geospatial sensitivity review, cyber sensitivity review, public-safe review, public authority boundary review, finance and insurance boundary review, safeguard review, and correction review;
3. scenario and simulation literacy, including scenario learning, simulation evidence, digital twin evidence, stress testing, red-team scenarios, drift detection, model limitations, public authority learning uses, finance-readiness question uses, and no certification by simulation;
4. DRR, DRF, and DRI competence, including disaster risk reduction portfolios, disaster risk finance portfolios, disaster risk intelligence portfolios, protection-gap questions, risk-layering questions, DRI indicator needs, public authority learning needs, insurance-readiness questions, donor-readiness questions, and public finance relevance questions;
5. public-safe and no-conversion literacy, including non-warning, non-rating, non-decision, non-certification, non-procurement, non-finance, non-insurance, non-consent, non-deployment, and non-execution language.

Risk Academy learning records should identify the risk-literacy domain, level, learning object, evidence of participation, assessment where applicable, contribution pathway, review status, correction status, and archive status. Risk-literacy records are capability records. They are not public authority qualifications, emergency management certifications, insurance qualifications, investment qualifications, procurement qualifications, professional licenses, or execution authorizations by default.

### 15.1.4 SCF as Workforce Spine of Foundry and BuildGrid

SCF is the workforce spine of Nexus Foundry and BuildGrid. Foundry and BuildGrid convert Nexus priorities into programs, tracks, quests, bounties, builds, review gates, release classes, maintainer roles, competence-cell work, public-good software, datasets, reports, Studio workflows, Campaign tools, Academy objects, Grid inputs, Registry records, Marketplace objects, Nexus Universe outputs, and handoff dependency packages. SCF defines the human capability required for that work.

Foundry and BuildGrid should use SCF to classify roles, tasks, competencies, learning needs, review capacity, maintainer capacity, contributor progression, work-integrated learning, proof receipts, contribution records, and lawful labor boundaries. A build is not only a technical artifact; it is a competence-producing process that creates evidence of work, learning, review, correction, and support capacity.

SCF-linked Foundry and BuildGrid workforce logic should include:

1. role mapping, including contributor, maintainer, reviewer, steward, product lead, data steward, AI reviewer, cyber reviewer, public-safe reviewer, safeguard reviewer, accessibility reviewer, documentation lead, Campaign lead, Studio facilitator, Academy designer, Registry steward, Marketplace steward, Grid reviewer, and handoff dependency steward;
2. task-to-competence mapping, including quests, bounties, builds, reviews, reports, dashboards, schemas, APIs, AI evaluations, DRI indicators, GRIx mappings, Studio workflows, Campaign objects, Academy modules, Registry records, Marketplace listings, and handoff dependency records;
3. learning-through-work pathways, including onboarding, mentorship, peer review, review gates, proof receipts, contribution records, learning records, micro-credential inputs where applicable, maintainer progression, and competence-cell formation;
4. quality and safeguard requirements, including public-safe review, data governance, AI governance, cyber review, privacy, accessibility, community safeguards, Indigenous protocol controls where applicable, protected knowledge, legal boundary literacy, and correctionability;
5. labor boundary controls, including volunteer work, learning work, bounty-supported work, stipend-supported work, contracted work, sponsored work, public authority learning work, no disguised labor, no employment by implication, and no execution by contribution.

SCF makes Foundry and BuildGrid a workforce-development and public-good production system rather than a loose task board. It records competence formation without implying employment, contractor status, procurement qualification, professional licensing, certification, deployment authorization, or execution authority.

### 15.1.5 SCF as Participation Spine of Campaigns

SCF is the participation spine of Nexus Campaigns. Campaigns mobilize signatures, pledges, support, donations where lawful, volunteers, teams, chapters, ambassadors, quests, bounties, builds, dashboards, public-safe storytelling, Academy learning, Risk Academy literacy, National Portfolio support, Nexus Universe preparation, and handoff-awareness participation. SCF ensures that this mobilization becomes structured capability rather than unrecorded attention.

Campaign participation should be mapped to SCF participation classes, learning pathways, contribution records, volunteer roles, ambassador roles, chapter roles, team roles, public-safe communication competencies, safeguard competencies, data-use boundaries, youth safeguards, community safeguards, sponsor controls, provider controls, correction pathways, and archive rules.

SCF-linked Campaign participation should include:

1. campaign literacy, including public-good purpose, claims discipline, public-safe language, participation-not-authority, support-not-control, provider-contribution-not-validation, public-authority-learning-not-decision, community-participation-not-consent, and campaign-not-execution;
2. volunteer and contributor pathways, including onboarding, role descriptions, safe tasks, contribution records, learning records, proof receipts, support records, correction records, and withdrawal pathways;
3. ambassador, chapter, and team capability, including facilitation, public-safe communication, moderation, privacy, youth safeguards, accessibility, local context, translation, Campaign dashboard interpretation, and escalation;
4. quest and bounty capability, including task scoping, deliverable quality, review criteria, data-use labels, AI-use labels, public-safe review, IP and license terms, and no-disguised-labor controls;
5. mobilization-to-learning conversion, including campaign signals routed to Academy modules, Risk Academy materials, Foundry builds, Reports, National Portfolio records, Nexus Universe rooms, Marketplace discovery, Registry records, and handoff dependency questions.

Campaign learning and participation records do not create endorsement, employment, certification, public authority action, procurement, finance, insurance, donor commitment, community consent, Indigenous consent where applicable, deployment authorization, or execution. They create capability and mobilization memory within Nexus boundaries.

### 15.1.6 SCF as Human-Capability Layer of National Portfolios

SCF is the human-capability layer of National Portfolios. A National Portfolio is incomplete if it records risks, systems, evidence needs, Observatory needs, Core Build Requests, safeguards, public authority learning, readiness questions, Universe routing, and handoff dependencies without also recording the national competence required to work on them.

SCF should help each National Portfolio identify the skills, roles, learning pathways, Working Groups, Competence Cells, Academy cohorts, Risk Academy pathways, Campaign teams, Foundry contributors, Studio facilitators, public-safe reviewers, safeguard reviewers, data stewards, AI reviewers, cyber reviewers, geospatial reviewers, finance-readiness literate participants, insurance-readiness literate participants, public authority learners, community participants, youth participants, and handoff dependency reviewers required for national continuation.

A National Portfolio SCF layer should identify:

1. national competency needs, including risk intelligence, WFEH-B systems, DRR, DRF literacy, DRI, GRIx, Observatory, Studio, data governance, AI governance, cyber, geospatial, public-safe reporting, Campaigns, Foundry builds, Reports, Registry, Marketplace, Grid, and handoff dependencies;
2. national work-unit capacity, including National Working Groups, Competence Cells, Teams, Squads, Guild participation, Academy cohorts, Risk Academy cohorts, Labs streams, public authority learning rooms, readiness rooms, secure rooms, and data rooms;
3. learning and contribution pathways, including Academy modules, micro-credentials where applicable, work-integrated learning, quests, bounties, builds, Campaign participation, Nexus Universe participation, proof receipts, iCRS records where applicable, and contribution records;
4. labor and safeguard controls, including volunteer classification, learning classification, stipend support, bounty support, contracted work, youth safeguards, community safeguards, Indigenous protocol controls where applicable, no disguised labor, no employment by implication, and no execution by contribution;
5. continuation and archive, including post-Nexus Universe learning continuation, National Node continuation, Academy conversion, Competence Cell continuation, Campaign continuation, Foundry continuation, handoff-context competence records, correction, and archive.

SCF gives National Portfolios a human-capability memory. It does not create national employment policy, immigration status, professional licensing, procurement qualification, public authority qualification, finance qualification, insurance qualification, consent, deployment authorization, or execution authority by implication.

### 15.1.7 SCF as Talent and Competence Layer of Nexus Universe

SCF is the talent and competence layer of Nexus Universe. Nexus Universe concentrates annual surge capacity through year-long mobilization, one-month Nexus Core Build, one-week live arena, post-cycle reporting, National Portfolio continuation, public authority learning, capital-reader learning, insurance-reader learning, donor-reader learning, Studio demonstrations, Foundry builds, Academy learning, Campaigns, Reports, Grid inputs, Registry updates, Marketplace discovery, and lawful handoff-dependency preparation. SCF ensures that this surge creates lasting capability rather than event-only visibility.

SCF-linked Nexus Universe should identify the people, roles, teams, cells, cohorts, panels, rooms, guilds, and national pathways required to deliver and continue the annual cycle. It should record participation, learning, contribution, review, support, public authority learning, sponsor support, provider contribution, community participation, consent boundaries, correction, and archive.

A Nexus Universe SCF layer should include:

1. talent intake and routing, including learners, contributors, reviewers, maintainers, facilitators, public authority learners, community participants, Indigenous participants where applicable, youth and students, providers, sponsors, capital readers, insurers, donors, public finance readers, media participants, humanitarian actors, and standards-interface actors;
2. competence pathways, including Academy tracks, Risk Academy tracks, Foundry BuildGrid tracks, Campaign tracks, Studio tracks, Reports tracks, DRI tracks, Observatory tracks, Grid and TRL tracks, Marketplace and Registry tracks, safeguard tracks, and handoff tracks;
3. annual-cycle records, including participation records, learning records, contribution records, review records, proof receipts, support ledger entries, public authority learning records, Nexus Universe output records, Registry records, Marketplace records, Grid records, handoff dependency records, correction records, and archive records;
4. surge-to-continuation pathways, including National Node continuation, National Working Group continuation, Competence Cell continuation, Academy continuation, Foundry continuation, Campaign continuation, Reports continuation, Studio continuation, public authority learning continuation, and handoff dependency continuation;
5. boundary controls, including Universe participation-not-endorsement, public authority presence-not-decision, capital-reader presence-not-investment-interest, insurer presence-not-underwriting, donor presence-not-commitment, sponsor support-not-control, provider contribution-not-validation, community participation-not-consent, and Universe output-not-execution.

Nexus Universe should be a talent formation engine, not only a convening arena. SCF ensures that the annual surge leaves behind competence, records, and continuation capacity. It does not create employment, certification, public authority status, financeability, insurability, procurement readiness, consent, deployment authorization, or execution.

### 15.1.8 SCF as Competence Context for Lawful Handoff

SCF is the competence context for lawful handoff. A handoff package should not include only evidence, data, software, reports, dashboards, Studio workflows, Grid records, TRL context, public-safe summaries, Registry status, Marketplace discovery, and dependency notes. It should also identify the human capability and competence assumptions that a separate lawful recipient would need to review, adapt, operate, govern, maintain, correct, support, or implement any downstream action.

Lawful handoff requires competence clarity because a technically strong object may fail if the recipient lacks data governance competence, AI governance competence, cyber competence, public-safe communication competence, public authority process competence, finance and insurance literacy, safeguard competence, community engagement competence, Indigenous protocol competence where applicable, operational competence, maintenance competence, incident response competence, or correction competence.

An SCF-linked Handoff Competence Record should identify:

1. recipient competence assumptions, including legal, technical, operational, data, AI, cyber, privacy, public-safe, safeguard, public authority, procurement, finance, insurance, donor, public finance, community, Indigenous protocol where applicable, accessibility, maintenance, incident response, and correction competencies;
2. Nexus competence records transferred as context, including learning records, contribution records, review records, Academy records, Risk Academy records, Competence Cell records, Foundry records, Studio records, Campaign records, Nexus Universe records, and proof receipts where appropriate;
3. competence gaps, including training needs, reviewer needs, maintainer needs, data steward needs, AI reviewer needs, cyber reviewer needs, public-safe reviewer needs, safeguard reviewer needs, operator needs, public authority process needs, finance or insurance literacy needs, and handoff recipient responsibilities;
4. handoff learning materials, including Academy modules, Risk Academy modules, Reports, public-safe summaries, technical documentation, model cards, system cards, benchmark cards, agent workflow cards, Studio guides, secure-room rules, data-use labels, AI-use labels, support notes, and correction instructions;
5. recipient responsibility notice, confirming that the recipient must conduct its own competence, staffing, training, legal, technical, operational, procurement, finance, insurance, public authority, safeguard, consent, deployment, and execution review before action;
6. no-authority-transfer notice, confirming that competence context does not certify the recipient, qualify the workforce, approve procurement, approve finance, approve insurance, grant public authority action, grant consent, authorize deployment, or execute implementation.

SCF makes handoff more honest by showing not only what the object is, but what human capability is required to use it responsibly. Competence context supports lawful recipient diligence; it does not substitute for it.

The final SCF Within Nexus rule is: SCF is the competence layer of Nexus, the learning spine of Nexus Academy, the risk-literacy spine of Risk Academy, the workforce spine of Foundry and BuildGrid, the participation spine of Campaigns, the human-capability layer of National Portfolios, the talent and competence layer of Nexus Universe, and the competence context for lawful handoff. SCF turns participation, learning, work, contribution, review, and capability into records; it never creates professional licensure, employment, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.2 Labor-Market Intelligence

### 15.2.1 Labor-Market Intelligence as Dynamic Competency Signal

Labor-market intelligence is the SCF function through which Nexus observes, interprets, records, updates, and corrects signals about work, occupations, tasks, skills, competencies, roles, credentials, employer demand, worker transition, public-good capability, regional capacity, national capability, informal work, care work, gig work, community work, and frontier-technology labor change. It is a dynamic competency signal layer, not a static job catalogue.

Labor-market intelligence within Nexus should connect labor-market change to Nexus public-good priorities, National Portfolios, Academy pathways, Risk Academy pathways, Foundry and BuildGrid roles, Campaign participation, Competence Cell formation, Nexus Universe talent routing, public authority learning, capital-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, and lawful handoff competence context. Its purpose is to help Nexus understand what capabilities are emerging, missing, displaced, under-recognized, under-supported, or required for resilience, risk reduction, technology governance, public-good software, data stewardship, AI governance, cyber resilience, WFEH-B systems, DRR, DRF, DRI, public-safe reporting, Studio workflows, and handoff dependencies.

Labor-market intelligence should be treated as a governed signal object. A Labor-Market Intelligence Record should identify the source, jurisdiction, sector, occupation family, task family, skill family, competency domain, evidence basis, update cadence, confidence label, uncertainty label, data-use label, AI-use label, public-safe status, privacy status, sensitivity class, labor-rights considerations, accessibility considerations, equity considerations, correction pathway, and archive rule.

Labor-market intelligence shall not be used as social scoring, worker ranking, automated employment decision-making, wage determination, immigration status, benefit eligibility, professional licensing, procurement qualification, public authority decision, finance qualification, insurance qualification, or employment guarantee by default. It is a capability signal layer. It helps Nexus see how work is changing and what learning, contribution, reskilling, upskilling, public-good work, and handoff competence may be needed.

### 15.2.2 Occupation-to-Task-to-Skill Decomposition

Occupation-to-task-to-skill decomposition is the SCF method for translating broad occupations into the actual tasks people perform and the competencies required to perform those tasks safely, effectively, ethically, and within Nexus boundaries. It prevents Nexus from treating job titles as sufficient evidence of capability.

An occupation title may hide many different tasks. A “data analyst” may clean data, build dashboards, evaluate DRI indicators, manage metadata, write public-safe summaries, use AI tools, prepare Studio inputs, or support handoff packages. A “cyber specialist” may conduct secure release review, vulnerability disclosure, threat modeling, prompt-injection review, access-control design, incident response, or public-safe cyber reporting. SCF therefore decomposes occupations into task families and skill families so that capability can be recorded more accurately.

An Occupation-to-Task-to-Skill Record should identify:

1. occupation family, including conventional occupation names, emerging role names, public-good role names, Nexus role names, and local or national terminology;
2. task family, including recurring activities, work products, tools used, review requirements, public-safe responsibilities, safeguard responsibilities, and handoff responsibilities;
3. skill family, including technical skills, analytical skills, digital skills, AI skills, cyber skills, data skills, geospatial skills, risk skills, communication skills, public-safe skills, safeguard skills, legal-boundary literacy, and collaboration skills;
4. competency level, including beginner, assisted, supervised, independent, reviewer, maintainer, steward, expert, or educator levels where appropriate;
5. evidence of competence, including learning records, contribution records, review records, proof receipts, portfolio objects, Academy records, Risk Academy records, Foundry records, Studio records, Campaign records, and Nexus Universe records;
6. boundary controls, confirming that task-skill mapping is not professional licensing, employment qualification, procurement qualification, immigration classification, wage determination, public authority status, finance qualification, insurance qualification, deployment authorization, or execution authority.

Occupation-to-task-to-skill decomposition allows SCF to recognize real capability, emerging work, public-good contribution, and transition pathways. It also helps identify where additional learning, review, supervision, safeguarding, or lawful credentialing by a separate competent body may be required.

### 15.2.3 Job Posting Intelligence

Job posting intelligence is the SCF method for analyzing public or lawfully available job postings, role descriptions, vacancy announcements, tender-related workforce signals where appropriate, fellowship calls, internship descriptions, volunteer role descriptions, contributor calls, and public-good work calls to identify changing skill demand, emerging occupations, task shifts, technology adoption, regional needs, sector needs, and national workforce gaps.

Job posting intelligence should be used as a signal, not as a complete labor-market truth. Job postings may overstate requirements, reflect employer bias, exclude informal work, miss public-good work, use inconsistent terminology, understate care and community capabilities, inflate credential demands, omit accessibility requirements, or misrepresent actual tasks. SCF should therefore treat job posting intelligence as one evidence stream among others.

A Job Posting Intelligence Record should identify:

1. source context, including jurisdiction, sector, employer class, role family, posting date, source pathway, and whether the posting is public, controlled, or restricted;
2. task and skill extraction, including stated tasks, implied tasks, required skills, preferred skills, tools, technologies, credentials, experience, language requirements, accessibility requirements, remote or place-based requirements, and public-good relevance;
3. Nexus competency mapping, including links to SCF competency domains, Academy pathways, Risk Academy pathways, Foundry roles, Competence Cell roles, National Portfolio needs, Nexus Universe tracks, and handoff competence assumptions;
4. bias and limitation review, including credential inflation, exclusionary language, unclear task requirements, automation exposure, wage transparency gaps, accessibility gaps, regional bias, language bias, gendered or exclusionary wording, and missing informal or community capabilities;
5. AI-use controls, including whether AI was used for extraction, classification, summarization, forecasting, or clustering, and what human review was applied;
6. boundary notices, confirming that job posting intelligence is not employment advice, hiring decision, worker ranking, credential equivalence, wage determination, immigration guidance, procurement qualification, public authority decision, or guarantee of demand.

Job posting intelligence helps Nexus keep SCF current. It should inform learning design, National Portfolio capability planning, Academy modules, Foundry role design, Campaign volunteer pathways, and handoff competence context, while remaining subject to correction and human interpretation.

### 15.2.4 Employer Demand Signals

Employer demand signals are labor-market intelligence records that identify what employers, enterprises, public institutions, universities, laboratories, NGOs, infrastructure actors, providers, operators, National Consortium Companies, Project SPVs, sponsors, public authorities acting separately, and other lawful actors appear to need in terms of tasks, skills, competencies, roles, workforce transition, training, upskilling, reskilling, public-good capability, and handoff competence.

Employer demand signals may arise from job postings, employer surveys, sector consultations, National Councils, Helix Councils, National Working Groups, Competence Cells, public authority learning rooms, Nexus Universe rooms, Studio rooms, handoff dependency records, Marketplace discovery signals, Campaign signals, Academy inquiries, provider contribution records, sponsor support records, and lawful handoff discussions.

An Employer Demand Signal Record should identify:

1. employer or employer class, including industry, public-sector, university, lab, nonprofit, humanitarian, infrastructure, provider, operator, National Consortium Company, Project SPV, or other lawful recipient class;
2. demand type, including occupation need, task need, skill need, training need, certification need where separately lawful, review capacity need, data capacity need, AI capacity need, cyber capacity need, public-safe communication need, safeguard need, or handoff competence need;
3. time horizon, including immediate, near-term, medium-term, long-term, seasonal, project-specific, crisis-linked, Nexus Universe-linked, or transition-linked demand;
4. regional and national context, including jurisdiction, sector, language, accessibility, data sovereignty, public authority context, and local labor-market conditions;
5. evidence basis, including postings, surveys, consultation records, DRI signals, National Portfolio records, Marketplace signals, Studio records, Reports, Academy records, or handoff dependency records;
6. boundary controls, confirming that employer demand signals are not hiring commitments, job guarantees, procurement commitments, finance commitments, insurance commitments, donor commitments, public authority decisions, wage promises, immigration pathways, or employment authorization by implication.

Employer demand signals help SCF align learning and contribution pathways with real-world needs while protecting learners and contributors from overpromised outcomes.

### 15.2.5 Worker Transition Signals

Worker transition signals are SCF records that identify how workers, learners, volunteers, students, public-good contributors, displaced workers, underemployed workers, informal workers, gig workers, care workers, community workers, public-sector workers, enterprise workers, technical workers, and professionals may need to move from one task, role, sector, technology, or competency domain to another as risk, technology, climate, public services, infrastructure, AI, cyber, WFEH-B systems, and labor markets change.

Worker transition signals should identify not only technical skill gaps but also access barriers, time constraints, caregiving constraints, language needs, accessibility needs, credential barriers, digital divide issues, regional constraints, financial constraints, recognition gaps, public-good contribution opportunities, and safeguard needs. SCF should not treat transition as an individual responsibility alone; it should record structural barriers and institutional support needs.

A Worker Transition Signal Record should identify:

1. worker or learner class, subject to privacy and public-safe controls, including sector, role family, region, experience level, learning pathway, or transition context;
2. transition driver, including automation, AI adoption, climate transition, disaster risk, sector decline, new infrastructure, public-good technology, cyber risk, WFEH-B system change, public authority reform, enterprise restructuring, or community resilience need;
3. current task and skill profile, including transferable skills, missing skills, recognition gaps, informal competencies, public-good contribution records, learning records, and review records;
4. target task and skill profile, including Nexus Academy pathways, Risk Academy pathways, Foundry roles, Campaign roles, Competence Cell roles, National Portfolio roles, Nexus Universe roles, or lawful handoff recipient needs;
5. support needs, including learning access, stipends, childcare, accessibility, language support, devices, connectivity, mentoring, work-integrated learning, recognition, public-safe participation, and labor protections;
6. boundary controls, confirming that transition signaling is not employment placement, job guarantee, wage guarantee, immigration advice, public benefit determination, professional licensing, procurement qualification, finance qualification, insurance qualification, or automated worker ranking.

Worker transition signals help Nexus design inclusive pathways from risk and disruption toward capability and public-good participation. They should be handled with dignity and without surveillance, profiling, or social scoring.

### 15.2.6 Regional and National Skills Signals

Regional and national skills signals are SCF records that identify competency patterns, shortages, strengths, gaps, transition needs, training needs, public-good work capacity, technical capacity, review capacity, safeguard capacity, and handoff competence needs across countries, regions, corridors, clusters, sectors, National Portfolios, Regional Portfolios, and Nexus Universe pathways.

Regional and national skills signals should support national ownership and regional learning without converting skills intelligence into rankings, public authority decisions, immigration classifications, funding allocations, labor-market enforcement, procurement qualifications, or social scoring. They should be used to plan Academy pathways, Risk Academy pathways, Competence Cells, National Working Groups, Foundry tracks, Campaigns, Nexus Universe talent pathways, National Dense Nexus Core profiles, and lawful handoff competence context.

A Regional or National Skills Signal Record should identify:

1. geographic scope, including country, region, corridor, basin, cluster, city, National Node, Regional Consortium pathway, or National Portfolio relationship;
2. skill domain, including data, AI, cyber, privacy, geospatial, WFEH-B, DRR, DRF literacy, DRI, GRIx, DICE, public-safe reporting, legal boundary, safeguards, Marketplace and Registry, Studio, Grid and TRL, handoff, public-good software, Academy, Campaigns, or governance;
3. signal source, including job posting intelligence, employer demand signals, worker transition signals, Academy records, contribution records, National Portfolio records, Campaign records, Marketplace discovery signals, Reports, Studio rooms, public authority learning rooms, and Nexus Universe outputs;
4. capacity status, including emerging, sufficient within scope, scarce, fragmented, under-recognized, inaccessible, unsupported, regionally concentrated, nationally missing, or correction-needed;
5. equity and access considerations, including language, accessibility, rural and urban access, youth access, gender barriers, digital access, community access, Indigenous participation where applicable, and informal work recognition;
6. boundary controls, confirming that skills signals are not country rankings, worker rankings, employment decisions, funding allocations, procurement qualifications, immigration classifications, public authority determinations, or execution authorizations.

Regional and national skills signals help Nexus place capability where it is needed. They should support investment in learning, not judgment of people or countries.

### 15.2.7 Informal, Gig, Care, Community, and Public-Good Work Signals

Informal, gig, care, community, and public-good work signals are SCF records that recognize capability and contribution that ordinary labor-market systems often fail to capture. Nexus must not define competence only through formal employment, conventional credentials, job postings, or enterprise roles. Many essential resilience capabilities are built through informal work, caregiving, community organizing, mutual aid, volunteering, local knowledge, disaster response experience, public-interest advocacy, open-source contribution, Campaign participation, youth leadership, diaspora support, and public-good work.

These signals should be recorded carefully because they can be sensitive, undervalued, gendered, unpaid, informal, precarious, or community-protected. Recognition must not become extraction, surveillance, unpaid labor normalization, consent overclaim, public authority overclaim, or employment guarantee.

An Informal, Gig, Care, Community, and Public-Good Work Signal Record should identify:

1. work signal class, including informal work, gig work, care work, community work, volunteer work, public-good software contribution, open knowledge contribution, disaster experience, mutual aid, Campaign participation, Academy support, Foundry contribution, Studio support, Reports support, or Nexus Universe participation;
2. competence evidence, including contribution records, participation records, learning records, proof receipts, community records, public-safe summaries, work samples, peer review, self-attestation where appropriate, supervisor or steward attestation where appropriate, and correction records;
3. recognition limits, including privacy, dignity, attribution preferences, youth safeguards, community safeguards, Indigenous protocol controls where applicable, protected knowledge, and consent boundaries;
4. transition relevance, including transferable skills, learning pathways, public-good contribution pathways, National Portfolio needs, Competence Cell formation, Foundry roles, Campaign roles, Academy pathways, and handoff competence context;
5. labor protection controls, including no disguised labor, no employment by implication, no extraction, no unpaid replacement of paid work, no coercive participation, and no pay-for-consent;
6. boundary notices, confirming that recognition of informal or public-good work is not employment status, wage entitlement, benefit eligibility, professional licensure, procurement qualification, public authority status, immigration status, finance qualification, insurance qualification, consent, deployment authorization, or execution.

SCF should make hidden competence visible without exposing or exploiting people. Public-good work deserves recognition, but recognition must remain rights-aware and correctionable.

### 15.2.8 AI-Driven Labor Forecasting With Human Review

AI-driven labor forecasting with human review is the SCF method for using AI-assisted tools to identify emerging skill demand, task transformation, automation exposure, regional skills gaps, national capability needs, employer demand patterns, worker transition signals, public-good work opportunities, Academy pathway needs, Foundry role needs, Nexus Universe talent needs, and handoff competence assumptions, while preserving human oversight, bias review, public-safe interpretation, and labor-rights safeguards.

AI-driven labor forecasting may use job posting intelligence, employer demand signals, worker transition signals, Academy records, contribution records, National Portfolio records, Campaign signals, Marketplace discovery signals, DRI signals, Studio records, public authority learning records, and other lawful data sources. It must not use restricted, personal, youth, health-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, public authority-sensitive, or handoff-recipient-only data for training, inference, ranking, or profiling unless expressly permitted under recorded data-use and AI-use labels and safeguards.

An AI-Driven Labor Forecasting Record should identify:

1. forecasting purpose, including Academy planning, National Portfolio capability planning, Competence Cell formation, Foundry role design, Campaign volunteer routing, Nexus Universe talent routing, public authority learning planning, or handoff competence context;
2. input data, including source records, data-use labels, AI-use labels, access class, sensitivity class, provenance, confidence, uncertainty, and correction status;
3. AI method, including model type, prompt pattern, classification method, clustering method, forecasting method, evaluation record, bias and harm review, human review pathway, and drift detection;
4. output class, including skills signal, task shift signal, occupation trend, regional capacity signal, national capability signal, transition need, learning pathway recommendation, or handoff competence assumption;
5. human review requirements, including expert review, labor-market review, safeguard review, public-safe review, bias review, accessibility review, national-context review, and correction review;
6. prohibited uses, including automated hiring, automated firing, worker ranking, social scoring, wage determination, immigration decision, benefit decision, public authority decision, procurement qualification, finance qualification, insurance qualification, credential decision, or execution decision;
7. correction and archive, including forecast correction, model correction, bias correction, withdrawal, recall, archive, and non-continuation.

AI may help SCF detect labor-market change, but it must not become an automated labor authority. Human review is required because work, dignity, capability, and transition cannot be safely reduced to model outputs.

The final Labor-Market Intelligence rule is: labor-market intelligence is a dynamic competency signal layer; occupation-to-task-to-skill decomposition reveals real capability; job posting intelligence, employer demand signals, worker transition signals, regional and national skills signals, informal and public-good work signals, and AI-assisted forecasting help Nexus align learning, contribution, Foundry work, National Portfolios, Nexus Universe, and lawful handoff competence. Labor-market intelligence informs capability formation; it never creates worker ranking, social scoring, employment decision, wage determination, immigration status, professional licensing, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.3 Competency Ontology

### 15.3.1 Competency Defined

Competency is the integrated capacity to apply knowledge, skill, ability, practice, judgment, disposition, role understanding, contextual awareness, safeguard discipline, and correctionability within a defined Nexus pathway, work unit, portfolio, technology domain, risk domain, learning pathway, contribution pathway, review pathway, public authority learning pathway, or lawful handoff context.

Competency in SCF is not merely possession of information or completion of a course. It is the recordable ability to perform, review, communicate, build, analyze, safeguard, correct, or steward a defined function within scope and under boundary conditions. A person, team, cell, cohort, guild, Working Group, or recipient may be competent for one Nexus context and not competent for another. Competency is therefore domain-specific, role-specific, pathway-specific, evidence-based, bounded, and correctable.

A Competency Record should identify:

1. competency domain, including data, AI, cyber, privacy, geospatial, WFEH-B, DRR, DRF literacy, DRI, GRIx, DICE, public-safe reporting, legal boundary, safeguards, Marketplace and Registry, Studio, Grid and TRL, handoff, public-good software, Campaigns, Academy, Foundry, Labs, National Portfolio, Nexus Universe, or public authority learning;
2. competency level, including awareness, assisted practice, supervised practice, independent practice, reviewer, maintainer, steward, expert, educator, or pathway lead where appropriate;
3. competency evidence, including learning records, contribution records, review records, proof receipts, work products, Studio exercises, Reports inputs, Campaign outputs, Foundry builds, National Portfolio objects, Nexus Universe outputs, public-safe records, correction records, and archive records;
4. scope and limits, including what the competency supports, what it does not support, what review is required, what safeguards apply, and what boundary notices travel with the record;
5. currency and correction, including issue date, review date, expiry or refresh cadence where applicable, supersession, downgrade, suspension, withdrawal, correction, archive, and non-continuation.

Competency is not professional licensure, employment status, procurement qualification, public authority qualification, finance qualification, insurance qualification, certification, consent authority, deployment authority, or execution authority unless a separate competent body lawfully grants such status through a separate recorded process. SCF competency makes capability visible; it does not create external authority by implication.

### 15.3.2 Skill Defined

Skill is a learned and demonstrable capability to perform a specific task, technique, operation, analysis, review, communication act, build activity, safeguard activity, or contribution activity within a defined scope. Skills are components of competency. They may be technical, analytical, digital, social, institutional, ethical, legal-boundary, public-safe, safeguard, operational, or communication-oriented.

A skill may include writing a data dictionary, reviewing a model card, identifying prompt-injection risk, masking a geospatial layer, drafting public-safe language, triaging a Docket, maintaining a repository, running a secure-room workflow, facilitating a Studio scenario, interpreting a DRI indicator, preparing a Campaign page, applying GRIx terminology, mapping a handoff dependency, or correcting a Registry record.

A Skill Record should identify:

1. skill name and task relationship, including the task or work object the skill supports;
2. skill domain, including data, AI, cyber, privacy, geospatial, WFEH-B, DRR, DRF, DRI, GRIx, DICE, public-safe reporting, legal boundary, safeguard, software, Studio, Grid, Registry, Marketplace, Campaign, Academy, Foundry, or handoff;
3. performance conditions, including tools, data classes, access classes, room requirements, review requirements, public-safe requirements, and safeguard conditions;
4. demonstration evidence, including exercises, work products, contributions, reviews, proof receipts, learning records, simulations, Studio outputs, code, reports, dashboards, public-safe summaries, or correction records;
5. level of independence, including observed, assisted, supervised, independent, reviewer-level, maintainer-level, steward-level, or educator-level;
6. limitations, including where the skill does not apply, where a higher-level reviewer is required, and where separate legal, technical, public authority, finance, insurance, consent, deployment, or execution review is required.

Skill recognition is useful for learning design, work routing, contribution matching, Competence Cell formation, Foundry role design, Academy pathways, Campaign roles, Nexus Universe talent routing, and handoff competence context. Skill recognition is not a license, credential guarantee, job guarantee, procurement qualification, public authority qualification, finance qualification, insurance qualification, consent, deployment authorization, or execution authority.

### 15.3.3 Knowledge Defined

Knowledge is the understood body of concepts, facts, theories, doctrines, methods, terms, evidence, standards-interface context, legal-boundary context, public-good principles, technical patterns, risk categories, safeguard rules, and institutional relationships that enables a participant to interpret Nexus work correctly.

Knowledge may be explicit, such as a written doctrine, taxonomy, method, report, policy, standard, model card, system card, data dictionary, Academy module, or technical guide. Knowledge may also be contextual, such as understanding how public authority learning differs from public authority decision, how finance-readiness differs from finance, how Marketplace discovery differs from procurement, how Registry status differs from certification, how Studio demonstration differs from deployment, and how handoff context differs from execution.

A Knowledge Record should identify:

1. knowledge domain, including Nexus doctrines, SCF, NAF, DDPGF, DICE, GRIx, DRI, Observatory, Studio, Reports, Academy, Campaigns, Foundry, Grid, Registry, Marketplace, National Portfolios, Nexus Universe, WFEH-B, DRR, DRF, AI governance, cyber, privacy, geospatial, safeguards, legal boundaries, or handoff;
2. knowledge object, including report, module, glossary, taxonomy, doctrine, method note, playbook, template, dataset documentation, model card, system card, benchmark card, dashboard guide, Studio guide, or handoff guide;
3. evidence of understanding, including completion record, reflection, assessment, contribution, review note, public-safe drafting exercise, scenario exercise, Studio exercise, Docket exercise, or correction exercise;
4. currency, including version, source, date, supersession, correction status, archive status, and refresh requirement;
5. scope limits, including whether the knowledge is general, national, regional, domain-specific, room-specific, public-safe, controlled, restricted, or archive-only.

Knowledge alone is not competency. A participant may know a doctrine but not be able to apply it in review, drafting, data stewardship, Studio facilitation, public-safe reporting, or handoff dependency mapping. SCF records knowledge as a foundation for competence, not as authority by itself.

### 15.3.4 Ability Defined

Ability is the demonstrated capacity to use knowledge and skill under real or simulated conditions, with appropriate independence, judgment, review, safeguards, and correction. Ability is more than exposure to learning materials and more than isolated skill performance. It is the capacity to perform within context.

Ability may be demonstrated when a participant can apply DICE controls to a dataset, classify AI-use labels correctly, draft a public-safe summary, identify a finance overclaim, manage a Campaign boundary, interpret a DRI dashboard without treating it as warning, conduct a method review, route a Docket, facilitate a Studio scenario, prepare a Grid input, or produce a handoff dependency record under supervision or independently.

An Ability Record should identify:

1. ability domain and task context;
2. conditions of performance, including real work, simulation, Studio exercise, Academy exercise, Campaign activity, Foundry build, Competence Cell work, public authority learning room, secure room, data room, Nexus Universe room, or handoff review;
3. degree of independence, including assisted, supervised, independent, reviewer-level, maintainer-level, steward-level, or educator-level ability;
4. quality indicators, including accuracy, completeness, safeguard compliance, public-safe language, boundary discipline, documentation, correction responsiveness, and collaboration;
5. review evidence, including reviewer notes, proof receipts, contribution records, work outputs, correction records, and archive records;
6. limitations and escalation triggers, including when the person or team must seek higher review, legal boundary review, public-safe review, safeguard review, AI/cyber/privacy review, public authority boundary review, finance and insurance boundary review, or handoff review.

Ability is contextual and perishable. It should be refreshed where technologies, laws, data, risks, methods, safeguards, or Nexus pathways change. Ability recognition is not certification, employment entitlement, professional qualification, procurement qualification, public authority status, finance qualification, insurance qualification, consent, deployment authorization, or execution authority.

### 15.3.5 Practice Defined

Practice is the repeated, disciplined, observable performance of tasks, reviews, contributions, decisions within Nexus scope, corrections, communications, builds, learning activities, safeguards, and handoff-preparation work over time. Practice converts isolated ability into reliable competence.

Practice matters because Nexus work requires repeated application under varying conditions. A participant may once complete a public-safe drafting exercise, but practice is shown when the participant repeatedly produces public-safe outputs across Reports, Campaigns, Studio summaries, Marketplace descriptions, Registry notices, National Portfolio summaries, or Nexus Universe materials while preserving uncertainty, boundaries, safeguards, and correctionability.

A Practice Record should identify:

1. practice domain, including data stewardship, AI review, cyber review, public-safe reporting, safeguard review, DRI interpretation, GRIx terminology, Studio facilitation, Campaign operations, Foundry build, Registry maintenance, Marketplace listing, Grid review, National Portfolio stewardship, or handoff dependency mapping;
2. practice frequency and duration, including whether the practice is occasional, active, recurring, maintained, dormant, refreshed, or retired;
3. practice outputs, including contributions, reviews, records, reports, dashboards, code, datasets, learning objects, Campaign objects, Studio workflows, Grid inputs, Registry records, Marketplace listings, handoff records, corrections, and archives;
4. quality and correction history, including successful outputs, returned outputs, corrected outputs, withdrawals, recalls, public repair, reviewer notes, and improvement evidence;
5. context range, including whether the practice has been demonstrated in one narrow setting or across national, regional, thematic, technical, public-safe, secure-room, Nexus Universe, or handoff contexts;
6. support and supervision, including whether the practice remains supervised, peer-reviewed, maintainer-reviewed, stewarded, or independently performed.

Practice is not mere activity volume. Repeated unsafe work does not create competence. Practice must be aligned with quality, safeguards, boundaries, and correction. Practice records support role progression, but they do not create licensure, employment, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution.

### 15.3.6 Judgment Defined

Judgment is the capacity to decide, within a recorded Nexus role and scope, how to interpret evidence, uncertainty, risk, safeguards, boundaries, competing values, incomplete information, public-safe concerns, role separation, escalation needs, and correction requirements. Judgment is the competence component that prevents mechanical skill from becoming unsafe action.

Judgment is required when a participant must determine whether a dataset is suitable for public-safe use, whether a dashboard may imply a warning, whether a sponsor claim creates capture risk, whether a provider contribution implies validation, whether a community input requires consent-boundary treatment, whether an AI workflow requires human-in-the-loop control, whether a DRI indicator is too uncertain for public release, whether a Marketplace listing should be delisted, whether a Grid record should be downgraded, or whether a handoff package should be paused.

A Judgment Record should identify:

1. judgment context, including review, routing, public-safe communication, safeguard assessment, data use, AI use, cyber risk, public authority boundary, finance and insurance boundary, Campaign claims, Studio output, Grid classification, Registry status, Marketplace listing, Nexus Universe routing, or handoff dependency;
2. facts and evidence considered;
3. uncertainty and limitations considered;
4. boundary and safeguard issues considered;
5. decision within Nexus scope, including proceed, proceed with conditions, restrict, escalate, pause, correct, withdraw, recall, archive, or mark non-continuing;
6. review or escalation pathway, including whether higher review, legal boundary review, safeguard review, public authority boundary review, finance and insurance boundary review, AI/cyber/privacy review, or handoff review was required;
7. correction history, including whether the judgment was later upheld, corrected, superseded, withdrawn, or archived.

Judgment must be bounded. SCF judgment is not judicial authority, regulatory authority, public authority decision-making, investment judgment, underwriting judgment, procurement judgment, consent determination, deployment approval, or execution command. It is the ability to make appropriate Nexus pathway decisions within a recorded public-good role.

### 15.3.7 Disposition Defined

Disposition is the stable orientation, habit, ethic, and professional posture that supports trustworthy Nexus work. It includes public-good orientation, humility under uncertainty, correction readiness, respect for role boundaries, safeguard sensitivity, non-extractive conduct, accessibility awareness, anti-capture discipline, public-safe communication discipline, respect for national ownership, respect for community and Indigenous protocols where applicable, data responsibility, cybersecurity caution, and willingness to escalate when limits are reached.

Disposition matters because technical skill without the right posture can harm Nexus legitimacy. A technically capable person who overclaims certainty, ignores public-safe limits, treats communities as data sources, accepts sponsor influence, treats public authority presence as approval, or treats handoff context as execution is not competent within Nexus, regardless of technical ability.

A Disposition Record should be used carefully and fairly. It should not become personality scoring, social scoring, discriminatory profiling, political screening, or informal gatekeeping. Where disposition is relevant, it should be recorded through observable conduct and role-specific behavior, not subjective preference.

Disposition may be evidenced through:

1. correction behavior, including willingness to correct errors, withdraw claims, update records, and notify affected pathways;
2. boundary behavior, including accurate use of no-certification, no-procurement, no-finance, no-insurance, no-public-authority-action, no-consent, no-deployment, and no-execution language;
3. safeguard behavior, including protection of privacy, protected knowledge, youth, health-sensitive data, community dignity, Indigenous protocols where applicable, and accessibility;
4. collaboration behavior, including respectful participation, transparent conflict disclosure, anti-capture discipline, and responsible escalation;
5. public-good behavior, including contribution to shared capability, avoidance of self-promotion overclaim, and respect for open or controlled commons rules.

Disposition records should remain bounded to Nexus participation and role suitability. They should not determine employment, immigration, public benefits, professional licensing, procurement qualification, finance qualification, insurance qualification, public authority status, consent, deployment authorization, or execution authority.

### 15.3.8 Role Capability Defined

Role capability is the demonstrated combination of competency, skill, knowledge, ability, practice, judgment, disposition, access eligibility, safeguard literacy, boundary literacy, and correction readiness required to perform a defined Nexus role. Role capability connects the competency ontology to real work units and pathways.

Nexus roles may include contributor, reviewer, maintainer, steward, facilitator, public-safe reviewer, data steward, AI reviewer, cyber reviewer, privacy reviewer, geospatial reviewer, safeguard reviewer, Academy instructor, Campaign steward, Studio facilitator, Reports editor, Registry steward, Marketplace steward, Grid reviewer, National Portfolio steward, Nexus Universe room steward, public authority learning facilitator, readiness room steward, secure-room steward, data-room steward, handoff dependency steward, and lawful recipient context reviewer.

A Role Capability Record should identify:

1. role name and pathway, including the Nexus institution, portfolio, room, team, guild, cohort, Docket, or handoff context in which the role operates;
2. required competency domains, including technical, governance, safeguard, public-safe, legal-boundary, communication, review, correction, and archive competencies;
3. required evidence, including learning records, contribution records, review records, practice records, proof receipts, work products, supervisor or steward review, peer review, and correction history;
4. access requirements, including confidentiality, secure-room access, data-room access, protected knowledge access, public authority learning access, capital-reader room access, or handoff-recipient access where relevant;
5. scope of authority within Nexus, including what the role may do, what requires approval, what requires escalation, and what is prohibited;
6. boundary notices, including role capability-not-employment, role capability-not-professional-license, role capability-not-public-authority-status, role capability-not-procurement-qualification, role capability-not-finance-qualification, role capability-not-insurance-qualification, and role capability-not-execution-authority.

Role capability allows Nexus to route work responsibly. It does not create external authority or guarantee suitability for non-Nexus roles unless separately assessed by a competent actor.

### 15.3.9 Contextual Competence Defined

Contextual competence is the ability to apply knowledge, skill, judgment, practice, and safeguards appropriately in a specific legal, cultural, national, regional, sectoral, technological, public authority, community, Indigenous protocol-sensitive where applicable, data, AI, cyber, geospatial, WFEH-B, DRR, DRF, DRI, Studio, Campaign, Academy, Foundry, Nexus Universe, or handoff context.

Contextual competence prevents SCF from treating capability as universal. A person may be competent in AI model review for public-good reports but not competent in AI model review for health-sensitive data. A person may be competent in DRI dashboard interpretation in one country but not another without localization. A person may be competent in public-safe reporting generally but not in Indigenous protocol-sensitive knowledge contexts. A person may be competent in finance-readiness literacy but not qualified to give investment advice.

A Contextual Competence Record should identify:

1. context type, including national, regional, local, community, Indigenous protocol-sensitive where applicable, sectoral, WFEH-B, technology, data, AI, cyber, geospatial, public authority, finance-readiness, insurance-readiness, donor-readiness, public finance learning, Studio, Campaign, Reports, Grid, Registry, Marketplace, Nexus Universe, or handoff context;
2. applicable constraints, including law, language, accessibility, data sovereignty, privacy, cyber, protected knowledge, public authority boundaries, finance and insurance boundaries, procurement neutrality, consent boundaries, safeguards, and public-safe communication rules;
3. competence evidence in context, including local work products, national records, community-reviewed outputs, secure-room work, public authority learning records, Studio outputs, Campaign outputs, Nexus Universe records, and correction history;
4. localization and translation status, including whether terminology, learning, reports, dashboards, data, safeguards, and public-safe outputs have been localized;
5. limits and escalation triggers, including where local experts, community reviewers, Indigenous governance pathways where applicable, public authority boundary review, legal review, finance and insurance boundary review, or safeguard review are required.

Contextual competence is essential for national ownership and lawful handoff. It ensures that Nexus does not export generic capability into contexts where it may be unsafe or illegitimate. Contextual competence is not local authority, public authority approval, community consent, Indigenous consent where applicable, procurement qualification, financeability, insurability, deployment authorization, or execution authority by implication.

### 15.3.10 Evidence of Competence Defined

Evidence of competence is the recorded proof that a person, team, cohort, guild, Working Group, Competence Cell, National Portfolio team, Foundry Build Team, Campaign Team, Studio Room participant, reviewer, steward, maintainer, or lawful handoff recipient context has demonstrated knowledge, skill, ability, practice, judgment, disposition, role capability, or contextual competence within a defined Nexus scope.

Evidence of competence may include:

1. learning evidence, including Academy records, Risk Academy records, module completions, exercises, reflections, assessments, micro-credential inputs where applicable, and learning proof receipts;
2. contribution evidence, including code, datasets, data dictionaries, schemas, Reports inputs, Campaign objects, Studio workflows, DRI indicators, GRIx mappings, public-safe summaries, Registry records, Marketplace listings, Grid inputs, Nexus Universe outputs, and handoff dependency records;
3. review evidence, including data review records, method review records, AI review records, cyber review records, privacy review records, public-safe review records, safeguard review records, public authority boundary review records, finance and insurance boundary review records, Grid review records, and handoff review records;
4. practice evidence, including repeated work over time, maintainer activity, reviewer activity, correction activity, room facilitation, National Portfolio stewardship, Campaign stewardship, Foundry builds, and Academy teaching;
5. judgment evidence, including recorded routing decisions, escalation decisions, restriction decisions, correction decisions, withdrawal decisions, recall decisions, archive decisions, and non-continuation decisions within Nexus scope;
6. correction evidence, including willingness and ability to correct, update, withdraw, recall, repair, archive, and learn from errors;
7. context evidence, including national, regional, community, Indigenous protocol-sensitive where applicable, public authority learning, secure-room, data-room, Studio, Nexus Universe, or handoff-context work.

Evidence of competence must be evaluated for relevance, currency, authenticity, sufficiency, context, and correction history. A record from one domain should not be silently treated as evidence for another. Evidence of competence can support learning progression, work routing, reviewer eligibility, maintainer status, Competence Cell formation, Academy pathways, Nexus Universe talent routing, and handoff competence context.

Evidence of competence is not a universal credential. It does not create professional licensure, employment status, procurement qualification, finance qualification, insurance qualification, public authority qualification, consent authority, deployment authority, or execution authority by implication. It makes demonstrated capability visible within recorded limits.

The final Competency Ontology rule is: competency integrates knowledge, skill, ability, practice, judgment, disposition, role capability, contextual awareness, and evidence; skills perform tasks, knowledge gives meaning, ability applies, practice stabilizes, judgment governs uncertainty, disposition sustains trust, role capability connects competence to work, contextual competence localizes it, and evidence of competence records it. SCF competency records make human capability visible, reviewable, correctable, and useful for Nexus learning, work, portfolios, Universe, and lawful handoff; they never create professional licensure, employment, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.4 Competency Families

### 15.4.1 Foundational Literacies

Foundational literacies are the baseline competencies required for meaningful, safe, and effective participation in Nexus. They include the ability to read, understand, communicate, navigate records, interpret basic evidence, recognize uncertainty, use digital tools safely, participate respectfully, understand role boundaries, and distinguish learning, contribution, review, support, and handoff from authority or execution.

Foundational literacies should be treated as the entry layer for Nexus Academy, Risk Academy, Campaigns, Foundry, BuildGrid, National Working Groups, Competence Cells, Studio Rooms, public authority learning rooms, readiness rooms, secure rooms, data rooms, National Portfolios, Nexus Universe, and lawful handoff literacy. They are not remedial or secondary. They are the common basis for whole-of-society participation across different education levels, languages, sectors, ages, professions, and national contexts.

Foundational literacies should include:

1. Nexus literacy, including understanding Nexus Ecosystem, public-good stack, enterprise stack, one rail, Dockets, proof receipts, records, registers, ledgers, rooms, Registry, Marketplace, Studio, Grid, TRL 1–10, Reports, Campaigns, Foundry, Academy, Observatory, DRI, GRIx, National Portfolios, Nexus Universe, and lawful handoff;
2. evidence literacy, including source awareness, uncertainty, confidence, review status, limitations, correction, supersession, withdrawal, recall, archive, and non-current authority notices;
3. digital literacy, including safe use of platforms, repositories, dashboards, communication tools, access controls, data rooms, secure rooms, AI tools where permitted, and public-safe outputs;
4. participation literacy, including participation-before-authority, contribution records, learning records, review records, support records, community participation records, consent boundary records, and correction records;
5. boundary literacy, including no-certification, no-procurement, no-finance, no-insurance, no-public-authority-action, no-consent, no-deployment, and no-execution by implication;
6. accessibility and language literacy, including plain-language communication, multilingual awareness, disability access, low-bandwidth participation, inclusive participation design, and respectful communication across contexts.

Foundational literacy records may support onboarding, cohort placement, volunteer routing, Campaign roles, Academy pathways, Foundry contributor pathways, public authority learning participation, and Nexus Universe participation. They do not create professional certification, employment status, procurement qualification, finance qualification, insurance qualification, public authority authority, consent authority, deployment authority, or execution authority.

### 15.4.2 Technical and Vocational Competencies

Technical and vocational competencies are the applied capabilities required to perform practical, technical, operational, craft, infrastructure, field, maintenance, engineering, implementation-context, data-collection, laboratory, manufacturing, logistics, systems-support, and resilience-support tasks relevant to Nexus work and lawful handoff contexts.

These competencies are broader than formal technical education. They include recognized vocational skills, workplace skills, field experience, maintenance skills, technician skills, infrastructure skills, public-service support skills, field-observation skills, digital tool skills, hardware skills, software-adjacent skills, safety skills, and operational-context knowledge that may be critical for water, food, energy, health, biodiversity, telecom, cyber-physical systems, geospatial systems, sensor networks, logistics, ports, manufacturing, advanced manufacturing, robotics, drones, and other mission-critical systems.

Technical and vocational competencies should include:

1. systems operation and maintenance literacy, including understanding how physical, digital, cyber-physical, WFEH-B, telecom, energy, water, logistics, and health systems operate, fail, degrade, recover, and require support;
2. field and infrastructure competence, including inspection, installation support, sensor handling, basic instrumentation, field data collection, equipment awareness, safety protocols, maintenance context, and degraded-mode observation;
3. technical documentation competence, including reading manuals, schematics, diagrams, system descriptions, maintenance notes, data sheets, safety notes, public-safe technical summaries, and handoff documentation;
4. quality and safety competence, including safe work practices, hazard awareness, incident reporting, escalation, secure handling, access control, and correction of technical errors;
5. vocational-to-digital bridge competence, including translating field conditions into data records, evidence needs, Observatory signals, Studio scenarios, Reports inputs, Academy modules, and handoff dependency records;
6. implementation-context literacy, including understanding that technical feasibility, operational feasibility, procurement, finance, insurance, public authority approval, consent, deployment, and execution remain separate from Nexus public-good records.

Technical and vocational competency records may support Competence Cell formation, National Portfolio capability mapping, Academy pathways, Foundry builds, Nexus Universe technical rooms, and handoff competence context. They do not create licensure, employment, procurement qualification, public authority authorization, operator certification, safety certification, deployment approval, or execution authority unless separately granted by a competent body or lawful employer through a separate recorded process.

### 15.4.3 Digital and Data Competencies

Digital and data competencies are the capabilities required to work responsibly with digital public goods, data objects, metadata, repositories, dashboards, APIs, software tools, data pipelines, schemas, ontologies, notebooks, registries, marketplaces, Studio workflows, DRI indicators, Observatory signals, Grid inputs, National Portfolio records, Nexus Universe outputs, and handoff-context data.

Digital and data competencies are central to Nexus because nearly every public-good object becomes record-bearing, metadata-bearing, status-bearing, reviewable, searchable, correctable, and archivable. Participants must therefore understand not only how to use digital systems, but how to preserve source truth, access boundaries, data rights, AI-use limits, public-safe transformation, sensitivity controls, correction, and archive.

Digital and data competencies should include:

1. data stewardship competence, including source review, rights review, data-use labeling, AI-use labeling, metadata completion, lineage capture, quality review, confidence labeling, uncertainty labeling, access classification, retention, deletion, sealing, and archive;
2. metadata and object-governance competence, including object identity, object class, object version, object steward, lifecycle state, support class, access class, public-safe status, correction pathway, and archive rule;
3. digital public-good competence, including repositories, APIs, schemas, dashboards, notebooks, software objects, data dictionaries, codebooks, learning objects, Registry objects, Marketplace listings, Studio workflow objects, and handoff objects;
4. secure-room and data-room competence, including least privilege, no-download controls, output review, compute-to-data, clean rooms, protected knowledge rooms, public authority learning rooms, readiness rooms, and room archive;
5. data-to-intelligence competence, including DRI indicator construction, Observatory signal interpretation, GRIx mapping, dashboard interpretation, public-safe summaries, Studio inputs, Reports inputs, Grid inputs, and handoff dependency notes;
6. data boundary competence, including data availability is not data right, metadata is not open data, dataset citation is not permission to reuse, public-safe data is not raw data release, data-room access is not handoff permission, and AI use is not automated decision authority.

Digital and data competency records may support data steward roles, DICE Guild participation, DRI work, Observatory work, Studio work, Foundry builds, Reports, Academy modules, National Portfolios, Nexus Universe, and lawful handoff competence. They do not create unrestricted data rights, AI-use permission, public authority record status, procurement qualification, finance qualification, insurance qualification, consent, deployment authorization, or execution authority.

### 15.4.4 AI and Human-AI Collaboration Competencies

AI and human-AI collaboration competencies are the capabilities required to use, review, govern, limit, document, correct, and communicate AI systems, model objects, agentic workflows, retrieval systems, classifiers, forecasting models, simulation models, digital twin models, evaluation harnesses, AI-assisted drafting, AI-assisted coding, AI-assisted analysis, and AI-assisted public-safe transformation within Nexus.

Nexus AI competence must be grounded in human review and non-execution. AI may assist learning, drafting, classification, summarization, evaluation, scenario preparation, dashboard support, data review support, code support, public-safe drafting, and handoff-context preparation. It must not become automated authority, public authority decision, public warning, procurement decision, finance decision, insurance decision, consent determination, deployment authorization, or execution command by default.

AI and human-AI collaboration competencies should include:

1. AI-use label competence, including no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, and public-safe AI output only;
2. model documentation competence, including Model Cards, System Cards, Benchmark Cards, Agent Workflow Cards, intended uses, prohibited uses, limitations, evaluation records, drift records, withdrawal rules, and archive rules;
3. human review competence, including human-in-the-loop, human-on-the-loop, output review, escalation triggers, no-command rules, no-write-back rules, and kill-switch conditions;
4. AI safety and harm-review competence, including bias review, hallucination review, prompt-injection controls, tool-permission controls, model leakage, training-data constraints, evaluation records, red-team records, drift detection, and AI incident response;
5. AI public-safe competence, including AI output labeling, uncertainty, source checking, public-safe transformation, protected knowledge avoidance, geospatial sensitivity, cyber sensitivity, health and youth sensitivity, public authority boundaries, and finance and insurance boundaries;
6. AI boundary competence, including Model Card is not certification, benchmark result is not general validation, agent output is not determination, AI workflow is not public authority decision, model release is not deployment authorization, and evaluation is not financeability, insurability, or procurement readiness.

AI competence records may support AI Guild participation, AI review roles, Studio work, Foundry builds, public-safe reporting, data stewardship, Academy pathways, Nexus Universe work, and handoff competence context. They do not create AI safety certification, legal compliance certification, public authority approval, procurement approval, finance approval, insurance approval, consent, deployment authorization, or execution authority.

### 15.4.5 Cybersecurity and Digital Trust Competencies

Cybersecurity and digital trust competencies are the capabilities required to protect Nexus digital public goods, data, software, AI workflows, repositories, dashboards, APIs, Studio environments, Observatory systems, DRI pipelines, Registry systems, Marketplace systems, Campaign platforms, Academy platforms, secure rooms, data rooms, compute-to-data workflows, sensor networks, National Nodes, Nexus Universe systems, and handoff packages from compromise, misuse, exposure, and trust failure.

Cybersecurity competence within Nexus must include both technical controls and public-safe controls. A vulnerability is not only a code issue; it can become a public-safe issue, a protected knowledge issue, a public authority issue, an insurance overclaim issue, a provider validation issue, or a handoff risk.

Cybersecurity and digital trust competencies should include:

1. secure software competence, including code review, dependency scanning, secret scanning, SBOM records, vulnerability disclosure, threat modeling, secure defaults, testing, accessibility, reproducibility, and release notes;
2. access and identity competence, including least privilege, authentication, authorization, room access, token handling, key management, logging, access expiry, account removal, and incident escalation;
3. cyber sensitivity competence, including identifying vulnerabilities, exploit paths, credentials, network architecture, system configurations, operational technology details, infrastructure-sensitive details, cyber-physical dependencies, and handoff-recipient-only security information;
4. incident response competence, including containment, secret rotation, access revocation, tool-permission revocation, kill-switch activation, Registry correction, Marketplace delisting, Report correction, Studio suspension, handoff recall, notification, public repair, and archive;
5. digital trust competence, including provenance, integrity, audit trails, proof receipts, versioning, status truth, correction records, support class, reproducibility, transparency within safety limits, and archive integrity;
6. cyber boundary competence, including code review is not security certification, SBOM is not assurance certification, Marketplace listing is not security endorsement, provider contribution is not provider validation, and secure release is not deployment authorization.

Cybersecurity and digital trust records may support Cyber Guilds, AI/cyber/privacy review teams, secure-room stewardship, software releases, Studio work, Observatory operations, Registry and Marketplace systems, National Portfolios, Nexus Universe, and handoff dependency records. They do not create cybersecurity certification, procurement approval, insurance approval, public authority approval, warranty, deployment authorization, or execution authority.

### 15.4.6 Systems Thinking and Complexity Competencies

Systems thinking and complexity competencies are the capabilities required to understand interdependence, feedback, cascade, compound risk, thresholds, degraded-mode operation, uncertainty, emergence, adaptation, institutional fragmentation, technology convergence, WFEH-B dependencies, cyber-physical dependencies, public authority interfaces, finance and insurance interfaces, community safeguards, and lawful handoff dependencies.

Nexus operates in complex systems where risk does not stay inside one sector, discipline, institution, technology, geography, or legal boundary. Systems competence is therefore required for DRI, GRIx, Observatory, Studio, National Portfolios, Regional Clusters, Nexus Universe, Foundry, Reports, Campaigns, Academy, Grid, and handoff pathways.

Systems thinking and complexity competencies should include:

1. interdependency mapping, including water-energy-food-health-biodiversity links, infrastructure dependencies, supply chains, telecom, compute, data systems, cyber-physical systems, public services, ecosystems, finance, insurance, public authority processes, and community systems;
2. cascade and compound-risk analysis, including first-order and downstream effects, simultaneous hazards, sequential shocks, degraded-mode transitions, capacity saturation, feedback loops, and threshold risks;
3. uncertainty and scenario competence, including scenario learning, simulation evidence, digital twin evidence, stress testing, red-team scenarios, drift detection, model limitations, and no certification by simulation;
4. cross-scale competence, including local, national, regional, global, corridor, cluster, public authority, community, enterprise, and public-good-to-enterprise interfaces;
5. role-separation competence, including knowing when systems insight must remain public-good intelligence and when separate competent actors must act through their own lawful processes;
6. correction competence, including recognizing when systems assumptions drift, when models become stale, when dashboards mislead, when portfolio objects require update, and when handoff dependencies change.

Systems thinking records may support National Systems-Risk Maps, WFEH-B Portfolios, DRR Portfolios, DRI work, Observatory outputs, Studio scenarios, Nexus Universe rooms, Academy pathways, and handoff packages. They do not create public authority decisions, public warnings, procurement priorities, financeability, insurability, consent, deployment authorization, or execution authority.

### 15.4.7 Risk, Resilience, and Crisis Competencies

Risk, resilience, and crisis competencies are the capabilities required to understand, reduce, prepare for, communicate, learn from, and recover from hazards, disasters, crises, disruptions, degraded-mode conditions, systems-risk events, WFEH-B failures, infrastructure interruptions, cyber-physical incidents, climate and nature shocks, public-service stress, and institutional overload.

These competencies should be grounded in DRR, DRF literacy, DRI, public-safe reporting, scenario learning, public authority learning, National Portfolio preparation, Nexus Universe surge capacity, and lawful handoff dependencies. They must preserve the boundary between risk intelligence and emergency command.

Risk, resilience, and crisis competencies should include:

1. risk understanding, including hazard, exposure, vulnerability, capacity, resilience, residual risk, uncertainty, confidence, DRI indicators, GRIx categories, Observatory signals, and public-safe summaries;
2. resilience planning literacy, including preparedness, mitigation, continuity, degraded-mode operation, redundancy, recovery learning, adaptation, WFEH-B resilience, infrastructure resilience, cyber resilience, and community resilience;
3. crisis-learning competence, including after-action records, correction records, incident records, public-safe reporting, public authority learning records, Campaign response learning, Nexus Universe post-cycle reporting, and archive;
4. public authority boundary competence, including intelligence is not warning, dashboard is not decision, Studio scenario is not command, public authority learning is not public authority action, and Nexus does not direct emergency response by default;
5. finance and insurance literacy, including protection-gap questions, risk-layering questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, no-reliance, and regulated-perimeter controls;
6. safeguard competence, including affected-population dignity, humanitarian data responsibility, health and youth safeguards, geospatial sensitivity, infrastructure sensitivity, protected knowledge, Indigenous protocols where applicable, and public-safe communication.

Risk, resilience, and crisis competency records may support Risk Academy, public authority learning rooms, DRR Guilds, DRF Guilds, DRI Guilds, National Portfolios, Nexus Universe, Campaigns, Studio, Reports, and handoff context. They do not create emergency management authority, public warning authority, incident command authority, procurement authority, finance authority, insurance authority, consent authority, deployment authority, or execution authority.

### 15.4.8 Sustainability, Climate, Nature, and Green Skills

Sustainability, climate, nature, and green skills are competencies required to understand and support climate resilience, nature-based resilience, biodiversity, ecosystem services, WFEH-B systems, adaptation, mitigation context, green infrastructure, blue systems, circularity, resilience finance literacy, public-safe environmental reporting, ecological safeguards, community and Indigenous protocol-sensitive contexts where applicable, and lawful handoff dependencies.

These competencies must avoid shallow “green” labeling. Nexus treats climate, nature, and sustainability as systems-risk and life-support infrastructure domains connected to water, food, energy, health, biodiversity, infrastructure, technology, finance-readiness, insurance-readiness, public authority learning, and community legitimacy.

Sustainability, climate, nature, and green skills should include:

1. climate-risk literacy, including physical risk, transition context, adaptation, mitigation context, climate-health links, climate-water links, climate-food links, climate-energy links, climate-biodiversity links, and climate-infrastructure links;
2. nature and biodiversity competence, including ecosystems, habitats, species, ecological integrity, nature-based solutions, ecosystem services, watersheds, forests, wetlands, coastal systems, soil systems, pollination, fisheries, and ecological tipping points;
3. WFEH-B integration competence, including cross-system cascades, corridor dependencies, Regional Clusters, National Dense Nexus Core profiles, public-safe WFEH-B reporting, and WFEH-B handoff dependencies;
4. green and resilience skills, including sustainable infrastructure literacy, resource efficiency, circular systems, renewable energy context, water stewardship, food-system resilience, ecological restoration context, resilience indicators, and lifecycle thinking;
5. safeguard competence, including protected sites, sacred sites where applicable, Indigenous knowledge and data sovereignty where applicable, protected knowledge, ecological sensitivity, geospatial masking, community safeguards, and public-safe environmental communication;
6. boundary competence, including environmental intelligence is not environmental approval, public-safe climate reporting is not official warning, nature portfolio status is not conservation designation, and green-readiness context is not financeability, insurability, procurement status, consent, deployment authorization, or execution.

Sustainability, climate, nature, and green skill records may support WFEH-B Guilds, DRR pathways, National Portfolios, Reports, Studio scenarios, Nexus Universe, Academy, Campaigns, Grid, Marketplace, Registry, and handoff packages. They do not create professional environmental certification, public authority approval, finance approval, insurance approval, procurement qualification, land-use consent, deployment authorization, or execution.

### 15.4.9 Governance, Ethics, and Public-Good Competencies

Governance, ethics, and public-good competencies are the capabilities required to preserve Nexus role separation, public-good purpose, legitimacy, anti-capture discipline, boundary controls, claims discipline, correctionability, validity-by-record, non-execution, public-good firewall, no-conversion, public authority learning without substitution, finance-readiness without finance execution, procurement neutrality, sponsor support without control, provider contribution without validation, community participation without consent overclaim, and lawful handoff without authority transfer.

These competencies are central to all Nexus work. A technically excellent participant without governance and ethics competence may cause harm through overclaim, capture, role collapse, unsafe release, public authority confusion, finance overclaim, procurement implication, or consent overclaim.

Governance, ethics, and public-good competencies should include:

1. Nexus doctrine competence, including Non-Execution, Validity-by-Record, Correctionability, Verifiable Compute and Verifiable Intelligence, One Rail–Two Stacks, public-good firewall, no-conversion, and lawful handoff discipline;
2. role-separation competence, including GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), protocol authority, National Nexus Consortiums, National Nodes, National Companies, Project SPVs, providers, sponsors, public authorities, capital readers, insurers, donors, universities, communities, and media actors;
3. anti-capture competence, including sponsor support without control, provider contribution without validation, capital-reader presence without capital control, public authority learning without public authority capture, community participation without tokenization, media visibility without legitimacy capture, regional support without regional supremacy, and global support without global supremacy;
4. ethics and safeguard competence, including dignity, non-extraction, privacy, cyber, accessibility, protected knowledge, Indigenous protocols where applicable, youth safeguards, health sensitivity, public-safe reporting, and correction;
5. claims discipline competence, including no endorsement overclaim, no certification overclaim, no procurement overclaim, no finance or insurance overclaim, no public authority overclaim, no consent overclaim, no deployment overclaim, and no execution overclaim;
6. record governance competence, including Dockets, proof receipts, registers, ledgers, rooms, review records, support records, correction records, archive records, Registry status truth, Marketplace discovery, Grid inputs, and handoff dependency records.

Governance, ethics, and public-good competency records may support reviewer eligibility, steward roles, council participation, Working Group participation, Campaign leadership, Studio facilitation, Reports editing, Registry and Marketplace stewardship, Grid review, and handoff dependency work. They do not create legal authority, public authority status, certification power, procurement authority, finance authority, insurance authority, consent authority, deployment authority, or execution authority.

### 15.4.10 Communication, Collaboration, and Leadership Competencies

Communication, collaboration, and leadership competencies are the capabilities required to help diverse participants work together across disciplines, countries, sectors, institutions, technologies, communities, public authorities, funders, insurers, donors, universities, providers, sponsors, media actors, humanitarian actors, and standards-interface actors while preserving Nexus boundaries.

Nexus leadership is not command-and-control by default. It is stewardship, facilitation, sensemaking, boundary preservation, conflict management, public-safe communication, record discipline, correction readiness, and capability formation across distributed work units.

Communication, collaboration, and leadership competencies should include:

1. public-good communication, including clarity, plain language, multilingual awareness, accessibility, uncertainty communication, limitation communication, public-safe language, media-safe language, and correction notices;
2. cross-sector collaboration, including working with public authorities, universities, enterprises, capital readers, insurers, donors, civil society, communities, Indigenous participants where applicable, youth, media, humanitarian actors, and standards-interface actors under role boundaries;
3. facilitation competence, including councils, Working Groups, Competence Cells, Studio Rooms, public authority learning rooms, readiness rooms, secure rooms, data rooms, Academy cohorts, Campaign teams, Nexus Universe rooms, and handoff dependency rooms;
4. leadership-as-stewardship, including agenda formation without capture, decision framing within scope, escalation, stop-the-line support, conflict disclosure, inclusion, respectful participation, and correction culture;
5. collaborative production competence, including Dockets, programs, tracks, quests, bounties, builds, reviews, Reports, Campaigns, Academy pathways, Studio workflows, Registry records, Marketplace listings, Grid inputs, and handoff packages;
6. boundary communication, including communicating what a record, report, dashboard, scenario, listing, Registry status, Grid input, learning record, proof receipt, or handoff package does and does not mean.

Communication and leadership records may support facilitator roles, steward roles, Campaign roles, Academy roles, Nexus Universe roles, public authority learning roles, and handoff dependency roles. They do not create governance authority, public authority status, employment status, procurement authority, finance authority, insurance authority, consent authority, deployment authority, or execution authority unless separately recorded by a competent actor.

### 15.4.11 Public-Safe Reporting Competencies

Public-safe reporting competencies are the capabilities required to translate evidence, data, risk intelligence, Observatory signals, DRI indicators, Studio outputs, dashboards, maps, Reports, Campaign materials, Academy materials, Marketplace listings, Registry public views, National Portfolio summaries, Nexus Universe materials, and handoff-safe briefs into communication that informs without harming, overclaiming, exposing sensitive information, or implying authority.

Public-safe reporting is not ordinary communications. It is a governed competence that integrates evidence fidelity, uncertainty, sensitivity, public authority boundaries, finance and insurance boundaries, safeguards, protected knowledge, data rights, AI-use limits, geospatial controls, cyber controls, community dignity, Indigenous protocols where applicable, accessibility, and correctionability.

Public-safe reporting competencies should include:

1. evidence translation, including summarizing methods, limitations, confidence, uncertainty, review status, correction status, and public-safe transformation clearly;
2. sensitivity handling, including privacy, youth, health, community-sensitive context, Indigenous protocol-sensitive context where applicable, protected knowledge, cyber-sensitive information, infrastructure-sensitive information, geospatial-sensitive information, public authority-sensitive information, and handoff-recipient-only information;
3. claims discipline, including avoiding warning overclaim, rating overclaim, certification overclaim, procurement overclaim, financeability overclaim, insurability overclaim, public authority overclaim, consent overclaim, deployment overclaim, and execution overclaim;
4. audience and release-class competence, including public, controlled, Academy, Campaign, Marketplace, Registry, Studio, public authority learning, capital-reader, insurance-reader, donor-reader, public finance learning, Nexus Universe, secure-room, data-room, and handoff-safe audiences;
5. correction and public repair competence, including errata, addenda, clarification, correction notices, withdrawal, recall, public repair, Registry correction, Marketplace correction, Report correction, Campaign correction, dashboard correction, and archive notices;
6. accessibility and trust competence, including plain language, multilingual communication, screen-reader compatibility, low-bandwidth outputs, respectful framing, non-stigmatizing language, and dignity-preserving public narrative.

Public-safe reporting competency records may support Reports teams, Campaign teams, Academy teams, Public-Safe Reporting Guilds, media-safe work, National Portfolio summaries, Nexus Universe outputs, and handoff-safe briefs. They do not create public warning authority, public authority approval, certification, procurement recommendation, finance signal, insurance score, consent, deployment authorization, or execution.

### 15.4.12 Safeguard and Inclusion Competencies

Safeguard and inclusion competencies are the capabilities required to protect people, communities, rights, data, knowledge, accessibility, dignity, public trust, and lawful boundaries across Nexus work. They include privacy, cybersecurity, public-safe communication, community safeguards, Indigenous protocols where applicable, protected knowledge, youth protection, health sensitivity, disability inclusion, language access, gender and equity awareness, ecological sensitivity, geospatial sensitivity, infrastructure sensitivity, anti-capture, competition neutrality, consent boundaries, and correctionability.

Safeguard and inclusion competencies must be present across all Nexus pathways, not isolated in specialist teams only. Every participant should have baseline safeguard literacy; higher-risk roles require specialized safeguard competence.

Safeguard and inclusion competencies should include:

1. privacy and data protection competence, including data minimization, purpose limitation, consent and permission, access control, cross-border controls, data sovereignty, retention, deletion, sealing, and archive;
2. community safeguard competence, including non-extraction, dignity, local context, language, accessibility, community review, participation-not-consent, harm review, public repair, and correction;
3. Indigenous protocol competence where applicable, including governance, custodianship, protected knowledge, data sovereignty, consent, mapping limits, AI-use limits, publication limits, return, deletion, sealing, and archive;
4. inclusion competence, including disability access, youth safeguards, gender and equity awareness, low-bandwidth design, multilingual design, culturally respectful participation, and accessible learning pathways;
5. anti-capture competence, including sponsor support without control, provider contribution without validation, capital-reader presence without finance execution, public authority learning without substitution, Marketplace discovery without procurement, and Registry status without certification;
6. stop-the-line competence, including recognizing when work must be paused, restricted, escalated, corrected, withdrawn, recalled, archived, or marked non-continuing.

Safeguard and inclusion competency records may support safeguard review roles, community rooms, protected knowledge rooms, Academy pathways, Campaigns, Reports, Studio, National Portfolios, Nexus Universe, and handoff dependency work. They do not create consent, legal compliance certification, public authority approval, procurement approval, finance approval, insurance approval, deployment authorization, or execution.

### 15.4.13 Entrepreneurship and Innovation Competencies

Entrepreneurship and innovation competencies are the capabilities required to identify needs, frame problems, design public-good innovations, build prototypes, test assumptions, organize teams, mobilize support, translate research into Foundry work, develop open technical baselines, create public-good software, identify lawful handoff dependencies, and understand enterprise-interface pathways without collapsing public-good work into premature venture, procurement, finance, or execution claims.

Nexus innovation competence is not generic startup competence. It is public-good, evidence-bearing, safeguard-bound, nationally grounded, correctionable, non-executing, and handoff-aware. It must preserve the difference between public-good innovation, enterprise opportunity, lawful handoff, and actual implementation.

Entrepreneurship and innovation competencies should include:

1. problem-framing competence, including National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, public authority learning questions, Campaign signals, Marketplace discovery signals, Labs research signals, and handoff dependency mapping;
2. public-good design competence, including open technical baselines, public-good software, reusable objects, metadata, documentation, accessibility, public-safe reporting, support class, correction pathway, and archive rule;
3. Foundry and BuildGrid competence, including programs, tracks, quests, bounties, builds, maintainers, review gates, release classes, Registry records, Marketplace listings, Grid inputs, Nexus Universe routing, and correction loops;
4. innovation governance competence, including IP and licensing, contribution terms, sponsor support without control, provider contribution without validation, public-good firewall, One Rail–Two Stacks, no-conversion, and non-execution;
5. enterprise-interface literacy, including National Consortium Companies, Project SPVs, lawful recipients, recipient responsibility, procurement dependencies, finance dependencies, insurance dependencies, public authority dependencies, safeguard dependencies, consent dependencies, and handoff-not-execution;
6. iteration and correction competence, including testing, feedback, red-team review, public-safe review, safeguard review, correction, withdrawal, recall, archive, non-continuation, and renewal.

Entrepreneurship and innovation competency records may support Foundry roles, Labs-to-Foundry pathways, Foundry-to-Handoff pathways, Campaigns, National Technology Portfolios, Nexus Universe, and handoff competence context. They do not create company formation, investment readiness, procurement status, provider validation, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority by implication.

### 15.4.14 Care, Community, and Civic Competencies

Care, community, and civic competencies are the capabilities required to understand lived risk, community resilience, mutual aid, caregiving systems, civic participation, place-based knowledge, public-interest advocacy, community safeguards, accessibility, local trust, participation boundaries, public-safe storytelling, and dignity-preserving engagement within Nexus.

These competencies recognize that resilience is not created only by formal institutions, markets, technologies, or professionals. Care workers, community organizers, local leaders, youth groups, diaspora actors, public-interest actors, humanitarian actors, accessibility advocates, elders where appropriate, informal networks, and place-based institutions often hold critical knowledge about vulnerability, capacity, degraded-mode survival, social trust, and public-safe communication.

Care, community, and civic competencies should include:

1. lived-risk interpretation, including listening to community experience, understanding vulnerability, capacity, trust, local systems, accessibility barriers, language needs, and dignity concerns;
2. care-system literacy, including recognizing unpaid care, formal care, informal support, health and social care dependencies, youth and elder support where relevant, disability support, community safety, and crisis impacts on care systems;
3. civic participation competence, including Campaign participation, public-interest engagement, community review, National Council participation, Working Group participation, public-safe reporting, correction requests, and local accountability;
4. community safeguard competence, including participation-not-consent, non-extraction, privacy, protected knowledge, geospatial sensitivity, public-safe transformation, community review, public repair, and archive;
5. inclusive facilitation competence, including accessible meetings, multilingual engagement, low-bandwidth access, respectful communication, conflict sensitivity, trauma-aware participation where relevant, and youth safeguards;
6. boundary competence, including community input is not consent, public interest is not public authority action, civic support is not endorsement, volunteer work is not employment, and participation is not execution.

Care, community, and civic competency records may support Campaigns, Academy pathways, National Portfolios, public-safe reporting, community safeguard rooms, Nexus Universe, DRI context, Observatory context, and handoff dependency records. They do not create public authority status, consent, employment, procurement qualification, finance qualification, insurance qualification, deployment authorization, or execution authority.

### 15.4.15 Lawful Handoff Literacy Competencies

Lawful handoff literacy competencies are the capabilities required to understand, prepare, review, communicate, and correct the movement of Nexus public-good objects toward separate competent actors without transferring authority, creating execution by implication, or collapsing the public-good stack into the enterprise stack.

Lawful handoff literacy is required for Foundry teams, National Portfolio teams, Handoff Guilds, Handoff Dependency Teams, Studio Rooms, Readiness Rooms, Reports teams, Campaign teams, Registry and Marketplace stewards, Grid and TRL reviewers, National Consortium Companies, Project SPVs, public authorities acting separately, providers, operators, hosts, funders, insurers, donors, universities, labs, and community actors where appropriate.

Lawful handoff literacy competencies should include:

1. handoff doctrine competence, including One Rail–Two Stacks, public-good stack, enterprise stack, public-good firewall, no-authority-transfer, recipient responsibility, non-execution, validity-by-record, correctionability, and no-conversion;
2. handoff package competence, including object identity, version, metadata, evidence records, method records, data-use labels, AI-use labels, support class, public-safe status, Registry status, Marketplace status, Grid or TRL context, correction history, archive rule, and dependency records;
3. dependency mapping competence, including evidence, data, technical, software, AI, cyber, privacy, public-safe, public authority, procurement, finance, insurance, donor, public finance, safeguard, consent, legal, operational, enterprise, maintenance, liability, correction, recall, archive, and non-continuation dependencies;
4. recipient-class competence, including National Consortium Companies, Project SPVs, public authorities acting separately, providers, operators, contractors, hosts, universities, labs, funders, insurers, donors, public finance actors, community actors where appropriate, Indigenous institutions where applicable, and other lawful recipients;
5. boundary communication competence, including handoff-not-certification, handoff-not-warranty, handoff-not-procurement, handoff-not-finance, handoff-not-insurance, handoff-not-public-authority-action, handoff-not-consent, handoff-not-deployment, and handoff-not-execution language;
6. correction and recall competence, including downstream correction propagation, recipient notification, Registry correction, Marketplace correction, Grid correction, handoff package recall, archive, non-continuation, and public repair where required.

Lawful handoff literacy records may support readiness roles, handoff review roles, National Portfolio work, Foundry-to-Handoff pathways, Nexus Universe continuation, and recipient context. They do not approve recipients, certify projects, authorize procurement, arrange finance, underwrite insurance, grant public authority approval, secure consent, authorize deployment, or execute implementation.

The final Competency Families rule is: SCF competency families cover foundational literacies, technical and vocational competence, digital and data competence, AI and human-AI collaboration, cybersecurity and digital trust, systems thinking and complexity, risk and resilience, sustainability and nature, governance and ethics, communication and leadership, public-safe reporting, safeguards and inclusion, entrepreneurship and innovation, care and civic capability, and lawful handoff literacy. Together they form the human-capability architecture required for Nexus learning, contribution, review, public-good production, national portfolio formation, Nexus Universe surge capacity, and lawful handoff context, without creating professional licensure, employment, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.5 Integrated Learning Account

### 15.5.1 ILA as Learner Record Infrastructure

The Integrated Learning Account (ILA) is the learner record infrastructure of SCF. It provides the structured record layer through which Nexus participants may hold, organize, update, correct, display where appropriate, restrict where necessary, and archive their learning records, contribution records, competency records, proof receipts, participation records, review records, micro-credential inputs where applicable, work-integrated learning records, Campaign participation records, Foundry and BuildGrid records, Studio learning records, Nexus Universe participation records, and lawful handoff competence-context records.

The ILA is not a generic résumé, social profile, employment platform, credential marketplace, public ranking system, or worker-scoring tool. It is a governed learning and capability record infrastructure designed to make learning visible without turning learners into rated subjects, job candidates by default, procurement-eligible suppliers, public authority-qualified actors, finance-qualified actors, insurance-qualified actors, or execution-capable recipients by implication.

An ILA Record should identify:

1. learner identity and account status, subject to privacy, youth, accessibility, national, data-protection, community, and protected knowledge controls;
2. learning pathways, including Nexus Academy, Risk Academy, Studio learning, Campaign learning, Foundry contributor learning, DRI learning, GRIx learning, DICE learning, public-safe reporting learning, safeguard learning, public authority learning, finance-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, and handoff literacy;
3. record classes, including participation records, learning records, contribution records, review records, proof receipts, competency records, micro-credential inputs where applicable, iCRS records where applicable, support records, correction records, and archive records;
4. access classes, including private, learner-controlled, cohort-visible, National Node-visible, room-visible, reviewer-visible, public-safe display, Marketplace-display-eligible, Registry-linked, handoff-context-visible, restricted, sealed, or archive-only;
5. correction and portability controls, including learner correction requests, steward correction, record dispute, supersession, withdrawal, revocation where applicable, archive, export where lawful, and deletion or sealing where required;
6. boundary notices, confirming that ILA records are not professional licenses, employment guarantees, public authority qualifications, procurement qualifications, finance qualifications, insurance qualifications, immigration statuses, wage promises, consent records, deployment authorizations, or execution authorities.

The ILA allows learning and contribution to become durable without becoming coercive. It should support learner agency, record accuracy, privacy, accessibility, correctionability, and appropriate recognition while preventing surveillance, social scoring, extractive credentialing, and overclaim.

### 15.5.2 ILA as Competency Portfolio

The ILA as competency portfolio is the SCF function through which a learner or contributor may organize evidence of competence across Nexus competency families, levels, domains, pathways, roles, contexts, and records. It allows a participant to show, within controlled boundaries, what they have learned, practiced, reviewed, built, contributed, corrected, and stewarded.

An ILA competency portfolio should not merely list courses completed. It should connect learning to evidence. It should show how competency is supported by knowledge, skills, ability, practice, judgment, disposition, role capability, contextual competence, and evidence of competence within defined Nexus scopes.

An ILA Competency Portfolio Record should identify:

1. competency domains, including foundational literacies, technical and vocational competencies, digital and data competencies, AI and human-AI collaboration, cybersecurity and digital trust, systems thinking and complexity, risk and resilience, sustainability and nature, governance and public-good competencies, communication and leadership, public-safe reporting, safeguards and inclusion, entrepreneurship and innovation, care and civic capability, and lawful handoff literacy;
2. competency level, including awareness, assisted practice, supervised practice, independent practice, reviewer, maintainer, steward, expert, educator, or pathway lead where appropriate;
3. evidence links, including learning records, contribution records, review records, work products, proof receipts, Studio exercises, Campaign outputs, Foundry builds, Reports inputs, DRI indicators, GRIx mappings, National Portfolio objects, Nexus Universe records, handoff dependency records, and correction records;
4. context limits, including national, regional, community, Indigenous protocol-sensitive where applicable, public authority learning, secure-room, data-room, technical, public-safe, finance-readiness, insurance-readiness, Studio, Campaign, Foundry, Nexus Universe, or handoff context;
5. currency and status, including active, current within scope, needs refresh, superseded, corrected, suspended, withdrawn, archived, expired, or non-continuing;
6. display controls, including what may be private, public-safe, National Node-visible, reviewer-visible, Marketplace-display-eligible, handoff-context-visible, or restricted.

An ILA competency portfolio makes competence legible within limits. It does not certify competence universally, guarantee employability, qualify the learner for procurement, approve professional practice, grant public authority status, determine finance or insurance qualifications, authorize deployment, or execute work.

### 15.5.3 ILA as Skills Wallet

The ILA as skills wallet is the controlled, learner-centered function through which verified, reviewed, self-asserted, peer-supported, institution-supported, Academy-supported, Campaign-supported, Foundry-supported, Studio-supported, National Portfolio-supported, Nexus Universe-supported, or handoff-context-supported skill records may be held, updated, selectively displayed, and corrected.

The skills wallet should distinguish between different evidence strengths. A skill learned in a course, practiced in a simulation, demonstrated in a Foundry build, reviewed by a steward, applied in a secure room, used in a National Portfolio, or transferred as handoff context should not be represented as the same evidence class. SCF must preserve record truth and avoid credential inflation.

An ILA Skills Wallet Record should identify:

1. skill identity, including skill name, SCF competency family, domain, task relationship, level, and context;
2. evidence class, including self-declared, learning-completed, exercise-demonstrated, contribution-demonstrated, review-confirmed, maintainer-confirmed, steward-confirmed, micro-credential input where applicable, external credential-referenced where lawful, or handoff-context-relevant;
3. source pathway, including Academy, Risk Academy, Foundry, BuildGrid, Campaigns, Studio, Labs, DRI, Observatory, Reports, Registry, Marketplace, Grid, National Portfolio, Nexus Universe, public authority learning, or handoff pathway;
4. verification and review status, including unreviewed, reviewed within scope, confirmed within scope, expired, corrected, disputed, superseded, withdrawn, archived, or non-continuing;
5. display and sharing settings, including private, shared with reviewer, shared with cohort, shared with National Node, shared with work unit, Marketplace-display-eligible, handoff-context-visible, or public-safe;
6. boundary controls, including skill record-not-license, skill record-not-employment guarantee, skill record-not-procurement qualification, skill record-not-public authority qualification, skill record-not-finance qualification, skill record-not-insurance qualification, skill record-not-consent, skill record-not-deployment, and skill record-not-execution.

The ILA skills wallet gives learners portable memory. It must not become worker surveillance, social scoring, automated hiring, automated exclusion, or a substitute for lawful qualifications.

### 15.5.4 ILA as Contribution Memory

The ILA as contribution memory is the SCF function through which a participant’s public-good work, volunteer work, learning work, bounty-supported work, stipend-supported work, contracted work where linked, sponsored work where linked, Campaign work, Foundry work, Studio work, Reports work, DRI work, Observatory work, Registry work, Marketplace work, Grid work, National Portfolio work, Nexus Universe work, safeguard work, and handoff dependency work may be recorded as contribution evidence.

Contribution memory is important because many Nexus capabilities are formed through work that does not look like conventional employment or formal education. A participant may build competence through open technical baseline work, public-good software contributions, Campaign mobilization, translation, community participation, review support, data stewardship, Studio facilitation, public-safe reporting, correction work, or National Portfolio preparation.

An ILA Contribution Memory Record should identify:

1. contribution object, including software, data, model, dashboard, report, learning object, Campaign object, Studio workflow, DRI indicator, GRIx term, Observatory output, Registry record, Marketplace listing, Grid input, National Portfolio object, Nexus Universe output, handoff dependency note, correction record, or archive object;
2. contribution role, including contributor, reviewer, maintainer, steward, facilitator, translator, designer, writer, data steward, AI reviewer, cyber reviewer, public-safe reviewer, safeguard reviewer, community participant, public authority learner, Campaign volunteer, bounty participant, stipend-supported participant, or contracted contributor where applicable;
3. contribution evidence, including proof receipt, contribution record, review record, accepted change, publication credit, repository record, Campaign ledger entry, support record, iCRS record where applicable, public-safe output, correction record, or archive linkage;
4. rights and recognition, including attribution, anonymity or pseudonymity where appropriate, privacy preferences, community or protected knowledge limits, Indigenous protocol controls where applicable, license terms, confidentiality, and public display permissions;
5. quality and correction status, including accepted, accepted with limitations, under review, corrected, superseded, withdrawn, recalled, archived, disputed, or non-continuing;
6. labor boundary, including volunteer, learning, bounty-supported, stipend-supported, contracted, sponsored, public authority learning, or other work classification, with no disguised labor and no employment by implication controls.

Contribution memory creates recognition and evidence of practice. It does not create ownership, employment, procurement qualification, provider validation, sponsor control, public authority action, finance status, insurance status, consent, deployment authorization, or execution.

### 15.5.5 ILA as National Capability Input

The ILA as national capability input is the SCF function through which aggregated, public-safe, privacy-preserving, learner-controlled, and nationally governed competence signals may inform National Portfolios, National Dense Nexus Core profiles, National Working Group formation, Competence Cell formation, Academy planning, Risk Academy planning, Campaign mobilization, Foundry tracks, Nexus Universe talent routing, public authority learning planning, and lawful handoff competence-context planning.

ILA-derived national capability inputs must never expose personal learning records, sensitive participant information, youth data, community-sensitive data, Indigenous protocol-sensitive information where applicable, protected knowledge, health-sensitive data, or private contribution histories without proper permission, aggregation, public-safe transformation, and safeguards.

A National Capability Input Record derived from ILA data should identify:

1. aggregation scope, including country, region, National Node, National Portfolio, Working Group, Competence Cell, Academy cohort, Campaign pathway, Nexus Universe cycle, or handoff context;
2. competency signal, including domain, level distribution, emerging capacity, gap, shortage, under-recognized competence, learning demand, reviewer capacity, maintainer capacity, safeguard capacity, public-safe capacity, or handoff competence need;
3. privacy and aggregation method, including de-identification, aggregation threshold, suppression, masking, public-safe transformation, consent or permission where required, and youth or sensitive data restrictions;
4. national use case, including Academy pathway planning, Competence Cell formation, Campaign role design, Foundry track planning, Nexus Universe routing, National Portfolio maturity inputs, public authority learning planning, or handoff competence context;
5. limits and uncertainty, including incomplete records, participation bias, language bias, access bias, digital divide, unrecorded informal work, correction status, and non-representativeness;
6. boundary controls, confirming that national capability input is not worker ranking, country ranking, employment decision, immigration classification, wage determination, procurement qualification, finance qualification, insurance qualification, public authority decision, consent, deployment authorization, or execution.

The ILA can help countries see capability formation without converting people into metrics. National capability inputs should guide learning investment, not judge individuals or nations.

### 15.5.6 ILA as Registry-Linked Record

The ILA as Registry-linked record is the function through which learner, contribution, competency, proof, and participation records may link to Nexus Registry objects for status truth, object identity, version control, lifecycle state, correction status, archive status, and public-good provenance.

Registry linkage allows an ILA record to show that a learner contributed to a specific version of a software object, completed a module tied to a specific Academy object, reviewed a public-safe summary of a specific Report, supported a Campaign object, participated in a Studio workflow, contributed to a DRI indicator, worked on a National Portfolio object, or joined a Nexus Universe output. Registry linkage prevents vague claims and strengthens validity-by-record.

An ILA Registry Link Record should identify:

1. ILA record class, including learning record, contribution record, review record, proof receipt, competency record, Campaign record, Studio record, Foundry record, National Portfolio record, Nexus Universe record, or handoff competence-context record;
2. Registry object linked, including object identifier, name, version, lifecycle state, support class, public-safe status, access class, correction status, archive status, and successor object where applicable;
3. relationship type, including learned-from, contributed-to, reviewed, maintained, stewarded, translated, facilitated, corrected, supported, archived, or handoff-context-linked;
4. visibility and permission, including private, public-safe, National Node-visible, reviewer-visible, Marketplace-display-eligible, handoff-context-visible, restricted, sealed, or archive-only;
5. correction propagation, including what happens if the Registry object is corrected, superseded, withdrawn, recalled, archived, or marked non-continuing;
6. boundary notices, confirming that Registry linkage is not certification, endorsement, employment verification for all purposes, procurement qualification, finance qualification, insurance qualification, public authority qualification, consent, deployment authorization, or execution.

Registry-linked ILA records strengthen traceability. They do not transform Registry status into universal approval or credentials.

### 15.5.7 ILA as Marketplace-Display-Eligible Record

The ILA as Marketplace-display-eligible record is the controlled function through which a participant may choose, where appropriate and lawful, to make selected learning, competency, contribution, review, maintainer, public-safe reporting, Campaign, Foundry, Studio, National Portfolio, Nexus Universe, or handoff-literacy records visible through a Marketplace discovery surface.

Marketplace-display eligibility should be controlled by the learner or participant subject to Nexus safeguards, youth protection, privacy rules, community safeguards, protected knowledge restrictions, Indigenous protocol controls where applicable, public-safe review, and anti-discrimination controls. Display should never be automatic by default for sensitive records.

A Marketplace-Display-Eligible ILA Record should identify:

1. record selected for display, including skill, competency, contribution, proof receipt, learning completion, micro-credential input where applicable, public-good software contribution, Campaign role, Foundry build, Studio facilitation, public-safe reporting contribution, reviewer role, maintainer role, or handoff literacy record;
2. display purpose, including contribution discovery, learning discovery, volunteer matching, mentor matching, reviewer routing, Competence Cell formation, Academy cohort formation, Campaign role discovery, Foundry role discovery, or lawful handoff competence context;
3. display limits, including what is public, what is controlled, what is hidden, what is aggregated, what is pseudonymous, what is private, what is restricted, and what must never be displayed;
4. safeguards, including youth restrictions, privacy, anti-harassment, accessibility, community protections, protected knowledge exclusions, Indigenous protocol controls where applicable, non-discrimination, opt-out, correction, withdrawal, and archive controls;
5. Marketplace boundary notices, including display-not-employment, display-not-procurement qualification, display-not-certification, display-not-endorsement, display-not-finance qualification, display-not-insurance qualification, display-not-public-authority qualification, display-not-consent, display-not-deployment, and display-not-execution;
6. correction and removal pathway, including learner edit, dispute, correction, withdrawal from display, removal, archive, or non-continuation.

Marketplace display should help people be found for public-good roles without turning SCF into a labor marketplace by default. Discovery is not hiring, procurement, certification, or execution.

### 15.5.8 ILA Boundaries

ILA Boundaries are the mandatory rules that prevent the Integrated Learning Account from becoming a coercive identity system, social scoring system, automated employment system, surveillance system, credential monopoly, procurement gate, public authority qualification system, finance qualification system, insurance qualification system, immigration classification system, or execution authorization system.

The ILA may record learning, contribution, competency, review, proof receipts, participation, support, public authority learning, Campaign activity, Foundry work, Studio work, Nexus Universe participation, National Portfolio contribution, Registry-linked work, Marketplace-display-eligible records, and handoff competence context. It must not overstate the meaning of those records.

ILA Boundary Notices should state that:

1. ILA records are learning and competence records, not professional licenses, unless a separate competent licensing body issues a license through its own lawful process;
2. ILA records are not employment guarantees, job offers, wage promises, employment status, worker rankings, or automated hiring decisions;
3. ILA records are not procurement qualifications, vendor approvals, supplier certifications, public authority qualifications, or eligibility determinations by default;
4. ILA records are not finance or insurance qualifications, investment qualifications, underwriting qualifications, donor commitments, public finance allocations, or regulated decisions;
5. ILA records are not consent records, community consent, Indigenous consent where applicable, data-use permission, AI-use permission, land access permission, or deployment authorization unless separately and lawfully recorded;
6. ILA records are not execution authority, implementation authority, operational command, public authority action, deployment authorization, or handoff approval;
7. ILA data must be privacy-governed, learner-controlled where appropriate, protected for youth and sensitive participants, correctable, exportable where lawful, restricted where required, and deletable or sealable where required;
8. ILA display must be voluntary and bounded, especially for Marketplace display, public profiles, national capability inputs, youth records, community records, protected knowledge records, and sensitive contribution histories;
9. ILA records must remain correctionable, including dispute, correction, supersession, withdrawal, revocation where applicable, archive, and public repair where required.

The ILA is a trust infrastructure for learning and capability. Its value depends on restraint. It should make competence visible enough to support learning, contribution, National Portfolios, Nexus Universe, and lawful handoff context, but never powerful enough to control a person’s opportunities, rights, public authority status, finance status, insurance status, consent status, deployment status, or execution authority by implication.

The final Integrated Learning Account rule is: the ILA is learner record infrastructure, competency portfolio, skills wallet, contribution memory, national capability input, Registry-linked record, and Marketplace-display-eligible record surface. It gives people portable, correctable, privacy-governed evidence of learning and contribution while preserving boundaries: no professional licensure, no employment guarantee, no worker ranking, no procurement qualification, no finance qualification, no insurance qualification, no public authority action, no consent, no deployment authorization, and no execution by implication.

## 15.6 Micro-Credentials and Badges

### 15.6.1 Credential Doctrine

Credential doctrine is the SCF rule that micro-credentials, badges, proof receipts, learning records, contribution records, review records, competency records, and skills-wallet entries must describe what was actually learned, demonstrated, reviewed, contributed, maintained, corrected, or stewarded within a defined Nexus scope, and must not overstate authority, qualification, employment value, procurement value, finance value, insurance value, public authority status, consent status, deployment authority, or execution authority.

Nexus micro-credentials and badges should exist to make capability visible, portable, reviewable, correctable, and useful for learning pathways, contributor routing, Competence Cell formation, Foundry and BuildGrid work, Campaign roles, Studio rooms, National Portfolio capability mapping, Nexus Universe talent routing, Marketplace-display-eligible records, Registry-linked records, and lawful handoff competence context. They should not be treated as generic certificates of excellence, professional licenses, vendor credentials, regulated qualifications, public authority approvals, procurement gates, or labor-market promises.

Credential doctrine should require that every Nexus micro-credential or badge identify:

1. credential purpose, including learning recognition, contribution recognition, review recognition, maintainer recognition, public-safe reporting capability, data stewardship capability, AI review capability, cyber review capability, safeguard capability, Studio facilitation capability, Campaign capability, Foundry capability, Grid literacy, Registry and Marketplace literacy, National Portfolio capability, Nexus Universe participation, or handoff literacy;
2. competency scope, including the SCF competency family, competency level, pathway, domain, role, context, and limitations;
3. evidence basis, including learning records, assessments, exercises, contribution records, review records, proof receipts, work products, Studio outputs, Reports inputs, Campaign outputs, Foundry builds, Registry links, Marketplace links, Grid inputs, Nexus Universe records, correction records, and archive status;
4. issuer or steward, including Nexus Academy, Risk Academy, National Node, Competence Cell, Guild, Foundry pathway, Campaign pathway, Studio pathway, Reports pathway, Registry pathway, Marketplace pathway, Grid pathway, Nexus Universe pathway, or other recorded steward;
5. verification method, including unique identifier, version, date, status, Registry linkage where applicable, revocation or correction pathway, expiry or refresh rule where applicable, and display permission;
6. boundary notices, confirming that the credential or badge is not professional licensure, employment guarantee, procurement qualification, finance qualification, insurance qualification, public authority qualification, consent, deployment authorization, or execution authority unless separately issued by a competent body under a separate lawful process.

Credential doctrine should preserve trust by making recognition precise. A small, accurate credential is stronger than a broad, inflated one. A badge that clearly states “completed public-safe reporting foundations with reviewed exercise” is more trustworthy than a credential that implies the holder is universally qualified to publish risk intelligence.

### 15.6.2 Micro-Credential Classes

Micro-credential classes are the defined categories of SCF recognition that distinguish different kinds of learning, demonstration, contribution, review, maintenance, stewardship, and contextual competence. Credential classes should prevent all records from being treated as equivalent.

SCF micro-credential classes may include:

1. learning-completion micro-credentials, confirming completion of a defined Academy, Risk Academy, Studio learning, Campaign learning, Foundry learning, data governance learning, AI governance learning, cyber learning, public-safe reporting learning, safeguard learning, finance-readiness literacy, insurance-readiness literacy, or handoff literacy module;
2. assessment-based micro-credentials, confirming that a learner completed a defined assessment, exercise, scenario, simulation, drafting task, data-classification task, review task, dashboard-interpretation task, public-safe language task, or handoff-dependency mapping task within scope;
3. contribution-based badges, recognizing accepted contributions to public-good software, data objects, reports, dashboards, Campaigns, Studio workflows, DRI indicators, GRIx mappings, Academy materials, Registry records, Marketplace listings, Grid inputs, National Portfolio objects, Nexus Universe outputs, or handoff dependency records;
4. reviewer badges, recognizing bounded review capability or completed reviews in domains such as data review, method review, AI review, cyber review, privacy review, public-safe review, safeguard review, public authority boundary review, finance and insurance boundary review, Registry review, Marketplace review, Grid review, or handoff review;
5. maintainer badges, recognizing bounded responsibility for maintaining repositories, datasets, dashboards, Academy modules, Campaign objects, Reports series, Registry objects, Marketplace listings, Studio workflows, Grid records, DRI objects, GRIx terms, or National Portfolio objects;
6. stewardship badges, recognizing role capability for stewarding Dockets, rooms, cohorts, Working Groups, Competence Cells, Campaigns, Nexus Universe rooms, public authority learning rooms, readiness rooms, secure rooms, data rooms, protected knowledge rooms, or handoff pathways;
7. contextual competence badges, recognizing capability within a specific national, regional, community, Indigenous protocol-sensitive where applicable, public authority learning, secure-room, data-room, Studio, Nexus Universe, WFEH-B, DRR, DRF, DRI, AI, cyber, geospatial, public-safe, safeguard, or handoff context;
8. correction and trust badges, recognizing demonstrated capability in correction, public repair, withdrawal, recall, archive, issue triage, vulnerability disclosure support, Registry correction, Marketplace correction, Report correction, Campaign correction, or handoff recall.

Each micro-credential class should carry its own evidence requirements, review requirements, display rules, refresh rules, correction rules, revocation or withdrawal rules where applicable, and boundary notices. Micro-credential class labels should be conservative, specific, and resistant to overclaim.

### 15.6.3 Credential Evidence Requirements

Credential evidence requirements define the minimum records required before a micro-credential or badge may be issued, displayed, linked to an ILA, linked to the Registry, shown in Marketplace where eligible, used for work routing, or included in lawful handoff competence context.

Credential evidence should be sufficient for the credential’s claim. A learning-completion badge may require attendance or module completion. An assessment-based micro-credential should require reviewed performance. A reviewer badge should require review records. A maintainer badge should require sustained practice and correction history. A stewardship badge should require role capability, boundary literacy, safeguard literacy, and demonstrated judgment. A contextual competence badge should require evidence in that context, not only general knowledge.

Credential Evidence Records should identify:

1. source learning evidence, including module completion, cohort participation, exercise completion, assessment, reflection, Studio exercise, scenario exercise, simulation exercise, public-safe drafting exercise, or handoff mapping exercise;
2. source contribution evidence, including accepted work product, repository contribution, dataset contribution, report contribution, Campaign contribution, Studio workflow contribution, DRI indicator contribution, GRIx term contribution, Registry contribution, Marketplace contribution, Grid input, National Portfolio object, Nexus Universe output, or handoff dependency note;
3. source review evidence, including reviewer identity or reviewer class, review criteria, review outcome, limitations, correction notes, public-safe status, safeguard status, and archive status;
4. competency mapping, including SCF competency family, domain, level, role capability, contextual competence, and evidence of competence;
5. boundary and limitation record, including what the credential does not mean, where it does not apply, what additional review is required, whether it is current, whether it requires refresh, and whether it has been corrected, suspended, withdrawn, revoked, archived, or marked non-continuing;
6. verification and traceability, including unique credential identifier, issuing pathway, date, version, Registry link where applicable, ILA link, proof receipt, and correction pathway.

Credential evidence must be auditable within Nexus scope. Where evidence is sensitive, private, protected, youth-related, community-sensitive, Indigenous protocol-sensitive where applicable, health-sensitive, cyber-sensitive, or handoff-recipient-only, the credential should record the existence and class of evidence without exposing protected material.

### 15.6.4 Digital Verification

Digital verification is the method through which Nexus micro-credentials and badges can be checked for identity, issuer, scope, version, status, evidence class, currency, correction status, withdrawal status, revocation status where applicable, archive status, and boundary language. Digital verification should support portability and trust without creating surveillance, social scoring, automated employment decisions, procurement gating, public authority qualification, finance qualification, insurance qualification, or execution authority.

A digitally verifiable credential should include:

1. credential identifier, including unique ID, credential name, class, issuer, version, issuance date, and expiry or refresh rule where applicable;
2. holder relationship, subject to privacy, youth, safety, pseudonymity, and display controls;
3. competency scope, including SCF domain, level, role capability, pathway, and context;
4. evidence class, including learning-completed, assessed, contribution-demonstrated, review-confirmed, maintainer-confirmed, steward-confirmed, contextual, corrected, or archived;
5. status, including active, current within scope, needs refresh, suspended, corrected, superseded, withdrawn, revoked where applicable, archived, expired, or non-continuing;
6. links, including ILA link, Registry link where applicable, proof receipt, issuer record, evidence record class, and correction record;
7. boundary notices, including credential-not-license, credential-not-employment-guarantee, credential-not-procurement-qualification, credential-not-finance-qualification, credential-not-insurance-qualification, credential-not-public-authority-qualification, credential-not-consent, credential-not-deployment, and credential-not-execution;
8. privacy and display controls, including private verification, selective disclosure, public-safe display, Marketplace-display-eligible display, National Node-visible display, reviewer-visible display, handoff-context-visible display, restricted display, and revocation of display permission.

Digital verification should make credentials trustworthy without making them coercive. Verification confirms the record’s status; it does not determine a person’s rights, employment, wages, immigration status, procurement eligibility, financial status, insurance status, consent status, public authority status, deployment status, or execution authority.

### 15.6.5 Recognition of Prior Learning

Recognition of Prior Learning (RPL) is the SCF process for recognizing relevant learning, work, contribution, practice, informal capability, community capability, care work, public-good work, professional experience, vocational experience, research experience, open-source contribution, public authority experience, humanitarian experience, Campaign experience, Studio experience, Foundry experience, Nexus Universe participation, or external credentials as evidence toward SCF competency records, micro-credentials, badges, role capability, or learning pathway placement.

RPL is essential because Nexus should not force every participant to repeat learning they can already demonstrate. It is also high risk because poor RPL can inflate credentials, reproduce inequality, ignore informal capability, privilege formal credentials, misread national contexts, expose sensitive histories, or overstate authority.

An RPL Record should identify:

1. prior learning source, including formal education, vocational training, professional experience, public authority work, community work, care work, informal work, gig work, open-source contribution, research work, humanitarian work, Campaign work, Academy work, Foundry work, Studio work, National Portfolio work, Nexus Universe work, or external credential;
2. evidence submitted, including transcripts, certificates, portfolios, work samples, contribution records, references, self-attestations where appropriate, community attestations where appropriate, proof receipts, publications, repository history, review records, or interviews;
3. SCF mapping, including competency family, skill, knowledge, ability, practice, judgment, disposition, role capability, contextual competence, and evidence of competence;
4. review method, including document review, portfolio review, interview, practical demonstration, scenario exercise, Studio exercise, public-safe drafting exercise, technical task, peer review, steward review, or Competence Cell review;
5. recognition outcome, including accepted within scope, accepted with limitations, partial recognition, placement credit, learning exemption, required bridge module, required supervised practice, not accepted, restricted, disputed, archived, or non-continuing;
6. safeguards, including privacy, anti-discrimination, language access, accessibility, youth safeguards, community-sensitive handling, Indigenous protocol sensitivity where applicable, protected knowledge restrictions, and correction pathway;
7. boundary notices, confirming that RPL recognition is not employment verification for all purposes, professional licensure, public authority qualification, procurement qualification, finance qualification, insurance qualification, immigration status, consent, deployment authorization, or execution.

Recognition of Prior Learning should expand access and respect real competence while preserving evidence discipline and boundaries.

### 15.6.6 Credential Governance

Credential governance is the SCF control system for designing, issuing, reviewing, correcting, suspending, withdrawing, revoking where applicable, renewing, displaying, archiving, and retiring Nexus micro-credentials and badges. Credential governance should ensure that credentials remain accurate, fair, accessible, privacy-protective, evidence-based, anti-inflationary, correctionable, and boundary-safe.

Credential governance should define:

1. issuing authority within Nexus scope, including which Academy, Risk Academy, National Node, Guild, Competence Cell, Foundry pathway, Campaign pathway, Studio pathway, Reports pathway, Grid pathway, Nexus Universe pathway, or SCF steward may issue which class of micro-credential or badge;
2. credential design rules, including competency mapping, evidence requirements, assessment design, accessibility, language, public-safe wording, boundary notices, refresh rules, and archive rules;
3. review and quality assurance, including reviewer eligibility, moderation, sampling, appeals, audit, bias review, safeguard review, public-safe review, legal boundary review, and correction review;
4. issuer controls, including conflict disclosure, anti-capture, sponsor support without control, provider contribution without validation, no pay-to-credential, no pay-to-pass, no procurement influence, no finance or insurance influence, and no public authority overclaim;
5. record controls, including ILA linkage, Registry linkage where applicable, proof receipt issuance, digital verification, display permissions, privacy, youth safeguards, correction records, withdrawal records, revocation records where applicable, and archive;
6. appeal and correction pathways, including learner dispute, evidence correction, assessment correction, credential correction, suspension review, withdrawal review, revocation review where applicable, reinstatement where appropriate, public repair, and archive;
7. retirement and supersession, including when a credential is updated, replaced, expired, suspended, withdrawn, archived, or marked non-continuing because competencies, technologies, laws, safeguards, Nexus doctrine, or public-safe boundaries changed.

Credential governance should protect learners from exploitative credentialing and protect Nexus from credential inflation. A credential is trustworthy only if its issuer, evidence, scope, limits, and correction pathway are clear.

### 15.6.7 Credential Boundary Rules

Credential boundary rules are mandatory notices and controls that prevent Nexus micro-credentials and badges from being misused as licenses, employment promises, procurement gates, public authority qualifications, finance qualifications, insurance qualifications, immigration signals, consent records, deployment approvals, or execution authority.

Every Nexus credential or badge should carry boundary language appropriate to its class. At minimum, credential boundary rules should state:

1. No professional licensure by default. A Nexus credential or badge does not authorize professional practice, regulated work, clinical work, engineering sign-off, legal work, financial advice, insurance advice, public authority action, or any licensed activity unless a separate competent licensing body lawfully grants such authority.
2. No employment guarantee. A Nexus credential or badge does not create employment, contractor status, job placement, wage promise, worker ranking, immigration status, benefit eligibility, or automated hiring decision.
3. No procurement qualification. A Nexus credential or badge does not qualify a person, team, provider, institution, or company for procurement, vendor status, supplier approval, prequalification, or contract award.
4. No finance or insurance qualification. A Nexus credential or badge does not create investment qualification, financeability, bankability, creditworthiness, underwriting qualification, insurability, coverage approval, premium indication, donor commitment, public finance allocation, or guarantee.
5. No public authority qualification. A Nexus credential or badge does not create public authority status, regulator status, emergency authority, public finance authority, policy authority, official warning authority, or public-sector qualification unless separately recognized by a competent public authority through its own process.
6. No consent or rights transfer. A Nexus credential or badge does not create community consent, Indigenous consent where applicable, data-use permission, AI-use permission, land access permission, protected knowledge release, publication permission, handoff permission, or waiver of rights.
7. No deployment or execution authority. A Nexus credential or badge does not authorize deployment, operational command, implementation, infrastructure action, field action, system operation, enterprise execution, or lawful handoff execution.
8. No universal competence. A Nexus credential or badge applies only to its recorded competency scope, evidence basis, level, context, date, version, status, limitations, and refresh rule.
9. Correctionability required. A Nexus credential or badge may be corrected, suspended, withdrawn, revoked where applicable, superseded, archived, or marked non-continuing if evidence, conduct, safeguards, doctrine, technology, law, or context changes.

Credential boundary rules should be visible wherever credentials are issued, displayed in an ILA, linked to a Registry object, surfaced through Marketplace, referenced in a National Portfolio, used in Nexus Universe routing, or included in handoff competence context.

The final Micro-Credentials and Badges rule is: Nexus micro-credentials and badges recognize bounded learning, demonstration, contribution, review, maintenance, stewardship, contextual competence, and correction practice. They require evidence, digital verification, governance, recognition-of-prior-learning discipline, and correctionability. They make competence visible and portable within scope; they never create professional licensure, employment guarantees, worker ranking, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.7 Work-Integrated Learning Paths

### 15.7.1 WILP Doctrine

Work-Integrated Learning Paths (WILPs) are SCF pathways through which learning, contribution, supervised practice, field exposure, Studio practice, Foundry contribution, Campaign work, National Portfolio work, Nexus Universe participation, public authority learning, and lawful handoff literacy are integrated into real or simulated Nexus work under recorded roles, safeguards, labor classifications, review controls, correction pathways, and boundary notices.

WILP doctrine exists because Nexus capability cannot be built only through classroom learning, reading, lectures, or passive credentials. Competence in data stewardship, AI governance, cyber review, public-safe reporting, DRI interpretation, Observatory workflows, Studio facilitation, WFEH-B systems, DRR, DRF literacy, Campaign mobilization, Foundry builds, Grid and TRL inputs, Registry and Marketplace stewardship, National Portfolio formation, Nexus Universe preparation, and lawful handoff dependency mapping must be learned through practice. That practice must be lawful, safe, non-extractive, supervised where necessary, and honest about labor status.

A WILP Record should identify:

1. learning-work pathway, including apprenticeship, internship, cooperative education, field placement, practicum, Studio-based practice, Foundry-based contribution, Campaign-based mobilization work, public authority learning placement, Nexus Universe placement, National Portfolio placement, Competence Cell placement, or handoff dependency placement;
2. learner classification, including student, youth participant, adult learner, worker in transition, volunteer learner, stipend-supported learner, bounty-supported learner, intern, apprentice, fellow, public authority learner, community learner, Indigenous participant where applicable, or contracted learner where separately recorded;
3. work classification, including volunteer work, learning work, stipend-supported work, bounty-supported work, contracted work, sponsored work, public authority learning work, or employment where separately and lawfully recorded;
4. competency objectives, including SCF competency family, role capability, task family, skill family, contextual competence, evidence of competence, review requirements, and expected learning outputs;
5. supervision and review, including supervisor, mentor, steward, reviewer, Competence Cell, Working Group, Academy pathway, Foundry maintainer, Studio facilitator, Campaign steward, public authority learning facilitator, or handoff dependency reviewer;
6. safeguards, including youth protection, privacy, health and safety, accessibility, language support, community safeguards, Indigenous protocols where applicable, protected knowledge, data-use labels, AI-use labels, cyber controls, public-safe review, and no-disguised-labor controls;
7. records and outputs, including learning records, contribution records, proof receipts, review records, competency records, micro-credential inputs where applicable, ILA entries, Registry links where applicable, correction records, and archive records;
8. boundary notices, confirming that WILP participation is not employment unless separately recorded, not professional licensure, not procurement qualification, not finance qualification, not insurance qualification, not public authority qualification, not consent, not deployment authorization, and not execution authority.

WILP doctrine requires that learning and work be mutually honest. A WILP may produce valuable public-good outputs, but the learner must not be exploited as unpaid labor, the host must not treat learning as execution authority, and Nexus must not represent practice as certification or implementation.

### 15.7.2 Apprenticeships

Apprenticeships are structured, sustained, supervised WILP pathways through which learners progressively develop role capability in a defined Nexus domain through repeated practice, mentoring, review, contribution, correction, and evidence accumulation. Apprenticeships may be used for data stewardship, public-good software, AI review, cyber review, geospatial review, DRI, GRIx, Observatory, Studio facilitation, public-safe reporting, Campaign operations, Foundry builds, Registry and Marketplace stewardship, Grid and TRL review, National Portfolio stewardship, safeguard review, and handoff dependency mapping.

A Nexus apprenticeship should have a defined pathway from observation to assisted practice, supervised practice, independent practice within scope, reviewer-readiness where applicable, maintainer-readiness where applicable, and steward-readiness where appropriate. It should not be a vague unpaid work arrangement.

An Apprenticeship Record should identify:

1. apprenticeship domain, including the SCF competency family and Nexus pathway served;
2. apprentice role and learner status, including age and youth safeguards where applicable, prior learning, ILA status, access class, and support needs;
3. mentor or steward, including the person, team, Competence Cell, Guild, Academy pathway, Foundry maintainer, Studio facilitator, or National Portfolio steward responsible for supervision;
4. progression stages, including observation, guided task performance, supervised contribution, reviewed contribution, correction practice, independent contribution within scope, and role-readiness review;
5. work products, including datasets, metadata, code, reports, dashboards, public-safe summaries, review notes, Studio workflows, Campaign objects, Registry records, Marketplace listings, Grid inputs, National Portfolio objects, Nexus Universe outputs, or handoff dependency notes;
6. labor and support classification, including whether the apprenticeship is paid, stipend-supported, grant-supported, volunteer-learning, employer-sponsored, public authority learning, or governed under a separate employment or training agreement;
7. protections, including no disguised labor, no unsafe work, no excessive control without proper status, no substitution for paid employment where inappropriate, accessibility, grievance pathways, correction, withdrawal, and archive;
8. boundary notices, confirming that apprenticeship completion is not professional licensure, employment guarantee, procurement qualification, finance qualification, insurance qualification, public authority status, consent, deployment authorization, or execution authority.

Apprenticeships should create durable competence through practice and mentorship. They must preserve learner protection, labor clarity, and Nexus boundary discipline.

### 15.7.3 Internships

Internships are time-bounded WILP pathways through which learners gain supervised exposure and applied experience in Nexus work while producing learning records, contribution records, proof receipts, and competency evidence. Internships may be hosted through Nexus Academy, Risk Academy, Nexus Foundry, Nexus Reports, Nexus Campaigns, Nexus Studio, Nexus Observatory, DICE, DRI, GRIx, Nexus Grid, Nexus Registry, Nexus Marketplace, National Nodes, National Working Groups, Competence Cells, Nexus Universe, or partner institutions under recorded terms.

Internships must be designed around learning outcomes and lawful labor classification. Where an intern performs productive work under employer-like control, applicable employment, stipend, educational, contractor, volunteer, or labor rules must be reviewed and respected. Nexus must not use internships as disguised labor, unpaid staff replacement, or execution support without lawful basis.

An Internship Record should identify:

1. internship pathway, including host, steward, Academy linkage, National Node linkage, Foundry linkage, Reports linkage, Campaign linkage, Studio linkage, Nexus Universe linkage, or partner linkage;
2. learning objectives, including SCF competency domains, role capability targets, task families, skill families, contextual competence, and expected evidence of competence;
3. duration and workload, including start date, end date, expected hours, supervision cadence, review cadence, accessibility needs, and support arrangements;
4. work classification, including paid internship, stipend-supported internship, academic-credit internship, volunteer-learning internship where lawful, employer-sponsored internship, public authority learning internship, or contracted internship where separately recorded;
5. permitted work, including research, documentation, data review support, public-safe drafting, software contribution, Campaign support, Academy support, Studio exercise support, Reports support, Registry or Marketplace support, National Portfolio support, or handoff dependency support;
6. restricted work, including tasks involving protected knowledge, youth or health-sensitive data, cyber-sensitive materials, public authority-sensitive materials, restricted geospatial materials, secure-room access, data-room access, or handoff-recipient-only materials unless proper controls are recorded;
7. records and outputs, including learning records, contribution records, review records, ILA entries, proof receipts, micro-credential inputs where applicable, correction records, and archive;
8. boundary notices, confirming that internship participation is not employment unless separately recorded, not professional licensing, not procurement qualification, not finance or insurance qualification, not public authority qualification, not consent, not deployment authorization, and not execution.

Internships should help learners enter Nexus practice safely and meaningfully. They should not promise jobs, credentials, procurement status, or authority.

### 15.7.4 Cooperative Education

Cooperative education is a structured WILP pathway that integrates formal education, institutional learning, work placement, supervised practice, contribution records, learning assessments, competency evidence, and Nexus public-good work across defined academic, vocational, professional, or institutional cycles. Cooperative education may involve universities, colleges, technical institutes, vocational institutions, public authorities, employers, National Nodes, Nexus Academy, Risk Academy, Nexus Foundry, National Working Groups, Competence Cells, Nexus Universe, and lawful partner organizations.

Cooperative education should be designed as a bridge between formal learning and public-good practice. It should align curriculum, work objects, supervision, assessment, labor status, learner protection, data controls, public-safe controls, accessibility, and correction. It should not be treated as a procurement pathway, employment guarantee, credential monopoly, or execution channel.

A Cooperative Education Record should identify:

1. educational institution and Nexus pathway, including Academy relationship, Risk Academy relationship, National Node relationship, Foundry relationship, Campaign relationship, Studio relationship, Reports relationship, National Portfolio relationship, Nexus Universe relationship, or handoff dependency relationship;
2. curriculum-to-work mapping, including SCF competency family, learning outcomes, task families, skill families, work products, assessment method, and evidence records;
3. placement structure, including placement host, work unit, supervisor, mentor, duration, workload, support, compensation or academic credit where applicable, and learner protections;
4. work products, including public-good software, datasets, metadata, dashboards, Reports inputs, Studio workflows, Campaign objects, Academy objects, DRI indicators, GRIx mappings, Registry records, Marketplace listings, Grid inputs, National Portfolio objects, Nexus Universe outputs, or handoff dependency notes;
5. quality and review controls, including institutional assessment, Nexus review, public-safe review, safeguard review, data review, AI/cyber/privacy review, correction review, and archive;
6. labor and legal controls, including no disguised labor, no employment by implication, student protection, academic integrity, IP and license rules, confidentiality, data-use labels, AI-use labels, and grievance pathways;
7. boundary notices, confirming that cooperative education does not create professional licensure, employment guarantee, procurement qualification, finance qualification, insurance qualification, public authority qualification, consent, deployment authorization, or execution authority.

Cooperative education should allow national and regional learning institutions to become capability partners in Nexus while preserving learner rights, record integrity, and role boundaries.

### 15.7.5 Field and Practicum Models

Field and practicum models are WILP pathways through which learners, contributors, students, workers in transition, community participants, technical trainees, public authority learners, humanitarian learners, and Competence Cell participants engage with real-world contexts, field conditions, community settings, infrastructure settings, environmental settings, public-service settings, Studio-to-field interpretation, Observatory needs, DRI evidence needs, WFEH-B systems, public-safe reporting, and National Portfolio context under controlled and safeguarded conditions.

Field and practicum work is high value and high risk. It can generate powerful contextual competence, but it may expose communities, sensitive locations, health data, youth data, protected knowledge, Indigenous protocol-sensitive information where applicable, cyber-physical infrastructure, public authority-sensitive conditions, or humanitarian protection concerns. It must therefore be governed by clear scope, supervision, consent-boundary discipline, public-safe transformation, data minimization, and no-execution rules.

A Field or Practicum Record should identify:

1. field context, including geography, community, institution, infrastructure, ecosystem, WFEH-B system, public-service setting, Observatory need, DRI need, Studio scenario linkage, or National Portfolio relationship;
2. learning objective, including observation, contextual competence, data stewardship, public-safe reporting, community engagement, technical field literacy, systems-risk mapping, WFEH-B understanding, safeguard practice, or handoff dependency understanding;
3. participant role, including learner, observer, field contributor, community participant, public authority learner, technical trainee, humanitarian learner, researcher, or Competence Cell participant;
4. permissions and boundaries, including site access, community process, Indigenous protocol pathway where applicable, data permission, photography or recording permission, mapping limits, AI-use limits, publication limits, and handoff limits;
5. safeguards, including safety, privacy, youth protection, health sensitivity, protected knowledge, geospatial masking, infrastructure sensitivity, cyber sensitivity, community dignity, accessibility, language, non-extraction, and public repair;
6. outputs, including field notes, public-safe summaries, evidence need records, Observatory need records, DRI inputs, Studio scenario inputs, Reports inputs, Academy reflections, Campaign inputs, National Portfolio updates, safeguard records, correction records, and archive;
7. boundary notices, confirming that field or practicum participation is not public authority action, not community consent, not Indigenous consent where applicable, not operational command, not procurement, not finance, not insurance, not deployment, and not execution.

Field and practicum models must privilege safety, consent boundaries, and public-safe transformation over data collection volume. Learning from the field must never become extraction from the field.

### 15.7.6 Studio-Based Practice

Studio-based practice is a WILP pathway in which learners and contributors develop competence through controlled Nexus Studio workflows, dashboards, digital twins, simulations, AI workflow reviews, data-room outputs, secure-room outputs, scenario learning, public authority learning exercises, readiness reviews, finance-readiness question exercises, insurance-readiness question exercises, donor-readiness exercises, public finance learning exercises, Nexus Universe demonstrations, and handoff-context demonstrations.

Studio-based practice allows learners to encounter complex systems without being placed directly into operational command or unsafe field execution. It is therefore one of the preferred pathways for high-risk learning in AI, data, cyber, geospatial, WFEH-B systems, DRI, digital twins, public authority learning, and lawful handoff literacy.

A Studio-Based Practice Record should identify:

1. Studio workflow, including dashboard, digital twin, simulation, AI workflow, secure-room output, data-room output, DRI review, Observatory review, public authority learning scenario, readiness scenario, or handoff demonstration;
2. learning objective, including scenario interpretation, dashboard interpretation, model limitation identification, public-safe language, AI output review, data-use review, geospatial sensitivity review, cyber sensitivity review, finance-readiness question formation, insurance-readiness question formation, public authority boundary review, or handoff dependency mapping;
3. runtime controls, including access control, no-download, no-write-back, no-command, logging, output review, AI-use labels, data-use labels, human review, kill-switch conditions, and room archive;
4. learner role and supervision, including observer, participant, analyst, reviewer trainee, facilitator trainee, public authority learner, capital-reader learner, insurance-reader learner, donor-reader learner, or handoff-dependency trainee;
5. outputs, including learning records, review notes, public-safe summaries, readiness questions, correction triggers, limitation statements, dependency notes, proof receipts, competency evidence, and archive records;
6. boundary notices, confirming that Studio practice is not deployment, operational command, public authority action, procurement, finance, insurance, donor commitment, public finance allocation, consent, handoff approval, or execution.

Studio-based practice should make complexity learnable while preserving the boundary between demonstration and action.

### 15.7.7 Foundry-Based Contribution

Foundry-based contribution is a WILP pathway through which learners and contributors develop competence by participating in Nexus Foundry and BuildGrid programs, tracks, quests, bounties, builds, review gates, release classes, maintainer pathways, correction loops, public-good software development, data object development, AI workflow review, dashboard development, Reports production, Academy object production, Campaign tool development, Studio workflow development, Registry and Marketplace object preparation, Grid input preparation, National Portfolio production, Nexus Universe build preparation, and handoff dependency package preparation.

Foundry-based contribution should make production itself a learning environment. It should connect tasks to SCF competencies, learning records, contribution records, review records, proof receipts, ILA entries, micro-credential inputs where applicable, and role capability progression. It must also preserve labor boundaries, secure release, data governance, AI governance, cyber review, public-safe review, safeguards, and correctionability.

A Foundry-Based Contribution Record should identify:

1. Foundry pathway, including program, track, quest, bounty, build, maintainer pathway, review gate, release class, or Nexus Universe build relationship;
2. contribution object, including code, dataset, metadata, schema, API, dashboard, model card, system card, benchmark card, Report, learning object, Campaign tool, Studio workflow, Registry record, Marketplace listing, Grid input, National Portfolio object, or handoff dependency note;
3. competency objectives, including technical skill, digital public-good skill, data stewardship, AI review, cyber review, public-safe reporting, safeguard review, documentation, collaboration, correction, maintainer practice, or handoff literacy;
4. work classification, including learning work, volunteer work, bounty-supported work, stipend-supported work, contracted work, sponsored work, or employment where separately recorded;
5. review and release controls, including code review, data review, AI review, cyber review, public-safe review, safeguard review, accessibility review, documentation review, Registry review, Marketplace review, Grid review, handoff review, and archive;
6. recognition and records, including contribution records, proof receipts, ILA entries, learning records, review records, maintainer records, iCRS records where applicable, micro-credential inputs, correction records, and archive;
7. boundary notices, confirming that Foundry contribution is not employment by implication, not provider validation, not sponsor control, not certification, not procurement, not finance, not insurance, not public authority action, not consent, not deployment authorization, and not execution.

Foundry-based contribution is where SCF and public-good production meet. It creates capability through governed work, not authority through contribution.

### 15.7.8 Campaign-Based Mobilization Work

Campaign-based mobilization work is a WILP pathway through which learners and contributors develop competence by participating in Nexus Campaigns, including public-good mobilization, signatures, pledges, support, donations where lawful, volunteer coordination, team formation, chapter formation, ambassador activity, public-safe storytelling, Campaign dashboards, quest routing, bounty routing, Academy conversion, Reports dissemination, National Portfolio support, Nexus Universe mobilization, and handoff-awareness participation.

Campaign-based work should teach public-good communication, participation ethics, volunteer coordination, moderation, trust and safety, public-safe reporting, accessibility, community safeguards, sponsor controls, provider controls, youth safeguards, data-use discipline, claims discipline, and correction. It must not become disguised labor, political manipulation, consent extraction, sponsor influence, provider promotion, public authority overclaim, donor overclaim, or execution by mobilization.

A Campaign-Based Mobilization Work Record should identify:

1. campaign identity and class, including global, regional, national, thematic, sectoral, technology, community, youth, university, Nexus Universe, Foundry, Academy, Reports, DRR, DRF, DRI, or safeguard campaign;
2. participant role, including learner, volunteer, ambassador, chapter participant, team member, moderator, public-safe storyteller, translator, accessibility contributor, support steward, data steward, Campaign dashboard steward, or correction steward;
3. learning objectives, including public-safe communication, mobilization ethics, participation records, support records, Campaign claims discipline, volunteer coordination, privacy, youth protection, accessibility, community safeguards, and correction;
4. campaign tools used, including signature tools, pledge tools, support tools, volunteer tools, team tools, chapter tools, ambassador tools, quest tools, bounty tools, dashboards, learning links, Reports links, Marketplace links, and Registry links;
5. safeguards, including moderation, fraud prevention, privacy, youth protection, data-use labels, AI-use labels, sponsor support without control, provider contribution without validation, community participation without consent overclaim, Indigenous protocol controls where applicable, media-safe language, and public-safe review;
6. records and recognition, including participation records, learning records, contribution records, Campaign support records, proof receipts, ILA entries, iCRS records where applicable, correction records, withdrawal records, and archive;
7. boundary notices, confirming that Campaign work is not endorsement, employment, public authority action, procurement, finance, insurance, donor commitment, public finance allocation, consent, deployment authorization, or execution.

Campaign-based mobilization work should build civic and public-good capability while preserving the difference between mobilization and authority.

### 15.7.9 Public Authority Learning Placements

Public authority learning placements are WILP pathways through which learners, public authority participants, students, fellows, interns, contributors, National Portfolio teams, Academy cohorts, Risk Academy cohorts, Studio participants, and Competence Cell participants engage with public authority learning contexts under non-decision, non-warning, non-command, non-regulatory, non-procurement, non-public-finance, non-policy, non-endorsement, non-deployment, and non-execution boundaries.

Public authority learning placements may occur in or around public authority learning rooms, public finance learning rooms, Studio scenarios, National Portfolio reviews, Reports reviews, DRI interpretation, Observatory outputs, Academy modules, Risk Academy modules, Nexus Universe rooms, public-safe reporting exercises, procurement-boundary learning, emergency-language discipline, regulatory-context learning, and handoff dependency mapping.

A Public Authority Learning Placement Record should identify:

1. placement context, including public authority learner class, host institution or room where appropriate, Nexus pathway, National Portfolio relationship, Studio workflow, Reports pathway, Academy pathway, Nexus Universe cycle, or handoff dependency pathway;
2. learning purpose, including risk intelligence, DRI, Observatory, Studio scenario, public-safe reporting, data governance, AI governance, cyber, WFEH-B systems, public finance learning, procurement-boundary learning, emergency-language discipline, regulatory-learning context, or handoff dependency review;
3. participant classification, including student, intern, fellow, public authority learner, public-good contributor, National Node participant, Competence Cell participant, or Working Group participant;
4. materials reviewed, including object identifiers, versions, access class, public-safe status, Registry status, Marketplace status, Grid or TRL context, correction status, and archive status;
5. outputs, including learning notes, non-decision observations, evidence need records, public-safe language notes, safeguard records, readiness questions, handoff dependency notes, correction triggers, proof receipts, ILA entries, and archive records;
6. public authority boundary controls, including no official decision, no warning, no command, no regulation, no permit, no license, no compliance finding, no procurement, no public finance allocation, no policy adoption, no endorsement, no deployment, and no execution;
7. labor and ethics controls, including no disguised labor, no employment by implication, confidentiality, public service ethics where applicable, privacy, data-use labels, AI-use labels, youth safeguards, accessibility, and correction pathway.

Public authority learning placements help learners understand public-sector contexts without turning Nexus into a public authority or substituting for public administration.

### 15.7.10 WILP Labor Protections

WILP labor protections are the mandatory safeguards that ensure work-integrated learning remains lawful, fair, non-extractive, safe, accessible, correctly classified, and correctionable. They apply to apprenticeships, internships, cooperative education, field and practicum models, Studio-based practice, Foundry-based contribution, Campaign-based mobilization work, public authority learning placements, Nexus Universe placements, National Portfolio placements, Competence Cell placements, and handoff dependency placements.

WILP labor protections should include:

1. classification accuracy, requiring each WILP to identify whether the activity is learning work, volunteer work, stipend-supported work, bounty-supported work, contracted work, sponsored work, public authority learning work, employment, academic placement, practicum, fellowship, or other lawful category;
2. no disguised labor, prohibiting WILPs from being used to replace paid workers, obtain recurring controlled labor without proper status, bypass procurement or contracting, obtain enterprise-stack execution, or shift execution responsibility onto learners;
3. no employment by implication, requiring clear notices where no employment exists and separate lawful agreements where employment, contractor status, stipend support, academic credit, or other formal status exists;
4. safe scope of work, excluding unsafe, legally regulated, professional, clinical, engineering-signoff, public authority, finance, insurance, procurement, deployment, operational command, or execution tasks unless a separate competent actor lawfully supervises and authorizes the work under its own responsibility;
5. supervision and mentorship, requiring appropriate supervisor, mentor, steward, reviewer, or facilitator roles, with escalation pathways and support;
6. fairness and access, including accessibility, language access, reasonable accommodation where required, anti-discrimination, youth safeguards, care responsibilities, remote or low-bandwidth alternatives where feasible, and protection against harassment or retaliation;
7. data and knowledge protection, including privacy, confidentiality, data-use labels, AI-use labels, secure-room access, data-room access, protected knowledge controls, Indigenous protocol controls where applicable, community safeguards, and public-safe transformation;
8. support and compensation clarity, including whether wages, stipends, bounties, reimbursements, travel support, accommodation support, academic credit, micro-credential inputs, proof receipts, or other recognition are provided;
9. IP and contribution clarity, including ownership, license, attribution, confidentiality, contribution terms, public display, withdrawal, correction, and archive;
10. grievance and correction, including learner complaint pathways, misclassification correction, harmful work correction, access correction, record correction, withdrawal, public repair where required, archive, and non-continuation.

WILP labor protections must be reviewed before scale. A WILP that generates many outputs but harms learners, misclassifies work, extracts community knowledge, exposes sensitive data, or blurs employment and contribution is not successful.

The final Work-Integrated Learning Paths rule is: WILPs integrate learning with real and simulated work through apprenticeships, internships, cooperative education, field and practicum models, Studio practice, Foundry contribution, Campaign mobilization, and public authority learning placements. They produce learning records, contribution records, proof receipts, competency evidence, ILA entries, and public-good capability while preserving labor protections, safeguards, supervision, correctionability, and boundaries. WILPs never create professional licensure, employment by implication, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution unless a separate competent actor lawfully creates that status through its own recorded process.

## 15.8 iCRS and Contribution Recognition

### 15.8.1 iCRS as Contribution Recognition System

The Integrated Contribution Recognition System (iCRS) is the SCF contribution-recognition system through which Nexus records, classifies, verifies, recognizes, corrects, displays where appropriate, restricts where necessary, and archives contributions made by learners, volunteers, contributors, reviewers, mentors, maintainers, stewards, Campaign participants, Foundry participants, Academy participants, Studio participants, National Portfolio participants, Nexus Universe participants, public authority learners, community participants, Indigenous participants where applicable, youth participants, providers, sponsors, universities, civil society actors, humanitarian actors, standards-interface actors, and other recorded participants.

iCRS exists because public-good capability is built through many forms of contribution that conventional labor-market, academic, procurement, and professional recognition systems often fail to capture. Nexus contributions may include learning support, data work, software work, research, review, public-safe reporting, mentoring, translation, accessibility, Campaign mobilization, Foundry builds, Studio facilitation, Registry correction, Marketplace listing, Grid input, National Portfolio preparation, Nexus Universe participation, safeguard review, and lawful handoff dependency mapping.

An iCRS Record should identify:

1. contributor identity or contributor class, subject to privacy, youth, community, protected knowledge, Indigenous protocol where applicable, safety, and public-safe controls;
2. contribution pathway, including Academy, Risk Academy, Campaigns, Foundry, BuildGrid, Studio, Labs, Reports, DICE, DRI, GRIx, Observatory, Grid, Registry, Marketplace, National Portfolio, Nexus Universe, public authority learning, readiness room, secure room, data room, protected knowledge room, or handoff dependency pathway;
3. contribution class, including learning, data, software, research, review, mentorship, translation, accessibility, Campaign, Foundry, Studio, Reports, Registry, Marketplace, Grid, safeguard, community, public authority learning, or handoff contribution;
4. evidence basis, including contribution record, proof receipt, accepted work product, review record, learning record, repository entry, support ledger entry, Campaign ledger entry, Registry link, Marketplace link, Grid link, Nexus Universe output, correction record, or archive record;
5. recognition status, including recorded, reviewed, accepted within scope, accepted with limitations, displayed where permitted, restricted, corrected, superseded, withdrawn, recalled, archived, disputed, or non-continuing;
6. recognition limits, including attribution, anonymity, pseudonymity, privacy, community-sensitive handling, protected knowledge restrictions, Indigenous protocol controls where applicable, youth display limits, public-safe display limits, and Marketplace-display eligibility;
7. boundary notices, confirming that iCRS recognition is not employment, wages, professional licensure, procurement qualification, provider validation, sponsor control, finance qualification, insurance qualification, public authority status, consent, deployment authorization, or execution authority.

iCRS makes contribution visible without converting contribution into power. It supports recognition, learning progression, ILA records, micro-credential inputs, Competence Cell formation, Foundry routing, Campaign routing, National Portfolio capability mapping, Nexus Universe talent routing, and handoff competence context while preserving labor, safeguard, privacy, and no-execution boundaries.

### 15.8.2 Learning Contribution

Learning contribution is contribution made through teaching, learning support, curriculum development, module drafting, cohort facilitation, peer learning, reflection, assessment support, exercise design, Studio learning support, Risk Academy content, public authority learning support, Campaign learning support, Foundry onboarding support, Nexus Universe learning support, and learner feedback that improves Nexus capability formation.

Learning contribution may be made by Academy instructors, cohort facilitators, mentors, reviewers, students, public authority learners, community participants, Indigenous participants where applicable, youth participants, subject-matter experts, translators, accessibility contributors, public-safe reporting contributors, and Foundry contributors.

A Learning Contribution Record should identify:

1. learning pathway supported, including Nexus Academy, Risk Academy, Studio learning, Campaign learning, Foundry learning, DRI learning, GRIx learning, data governance learning, AI governance learning, cyber learning, public-safe reporting learning, safeguard learning, finance-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, or handoff literacy;
2. contribution type, including module drafting, teaching, facilitation, mentoring, peer support, assessment design, exercise design, translation, accessibility adaptation, public-safe review, learning-object correction, or learner-feedback contribution;
3. learning object, including module, lesson, guide, simulation, Studio exercise, public-safe summary, quiz, reflection prompt, scenario, case study, template, credential evidence requirement, or micro-credential input;
4. review and quality status, including reviewed, accepted, corrected, superseded, withdrawn, archived, or non-continuing;
5. recognition pathway, including iCRS entry, ILA link, proof receipt, contribution record, micro-credential input where applicable, Academy record, Risk Academy record, or Nexus Universe record;
6. boundary controls, confirming that learning contribution is not teaching licensure, employment, credentialing authority, public authority qualification, procurement qualification, finance qualification, insurance qualification, consent, deployment authorization, or execution.

Learning contribution strengthens the SCF commons. Recognition should be precise, evidence-based, privacy-governed, and correctionable.

### 15.8.3 Data Contribution

Data contribution is contribution involving data objects, metadata, data dictionaries, codebooks, schemas, datasets, synthetic data, public-safe data, aggregated data, data pipelines, feature sets, benchmark datasets, DRI datasets, Observatory datasets, National Portfolio datasets, Studio datasets, data quality review, data labeling where lawful, lineage capture, data-use labeling, AI-use labeling, public-safe transformation, data correction, and archive.

Data contribution is high-value and high-risk. It must be governed through DICE, Data Guilds, Data Steward Teams, secure rooms, data rooms, clean rooms, compute-to-data workflows, public-safe review, privacy review, cyber review, geospatial review, safeguard review, and correction pathways where applicable.

A Data Contribution Record should identify:

1. data object contributed, including raw, processed, public-safe, aggregated, synthetic, metadata-only, benchmark, DRI, Observatory, National Portfolio, Studio, or handoff-recipient-only data;
2. source and rights context, including source pathway, steward, license, permission, consent where required, data-sharing conditions, public authority sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, protected knowledge status, and cross-border controls;
3. data governance labels, including access class, sensitivity class, data-use label, AI-use label, public-safe status, support class, retention rule, deletion rule, sealing rule, and archive rule;
4. contribution task, including collection, cleaning, structuring, metadata completion, lineage capture, quality review, labeling, transformation, aggregation, anonymization, masking, documentation, review, correction, or archive;
5. review requirements, including source review, rights review, sensitivity review, data review, privacy review, cyber review, geospatial review, public-safe review, safeguard review, public authority boundary review, finance and insurance boundary review, and correction review;
6. recognition and restriction, including attribution, anonymity, restricted recognition, protected recognition, iCRS entry, ILA link, proof receipt, Registry link where applicable, and Marketplace-display limits;
7. boundary controls, confirming that data contribution does not create data ownership transfer, unrestricted reuse, AI-use permission beyond recorded labels, public authority record status, procurement status, finance status, insurance status, consent, deployment authorization, handoff permission, or execution.

Data contribution may be recognized only within the rights and safeguards that govern the data. Recognition must never expose sensitive data, protected knowledge, communities, youth, health information, cyber-sensitive information, geospatial-sensitive information, or handoff-recipient-only materials.

### 15.8.4 Software Contribution

Software contribution is contribution involving repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, templates, infrastructure-as-code, test suites, reference implementations, Studio components, Observatory components, DRI components, Campaign tools, Academy tools, Registry tools, Marketplace tools, Grid tools, public-good software, open technical baselines, secure-room workflows, and handoff-context technical objects.

Software contribution must be governed by repository and release governance, license selection, contribution terms, maintainer assignment, code of conduct, dependency review, security review, public-safe documentation, release classification, Registry records, Marketplace listing governance, support classification, correction, deprecation, and archive.

A Software Contribution Record should identify:

1. software object, including repository, library, service, dashboard, API, SDK, connector, adapter, CLI, notebook, template, infrastructure-as-code, test suite, reference implementation, Studio workflow, Observatory component, DRI component, Registry object, Marketplace object, Grid object, or handoff-context object;
2. contribution type, including code, documentation, tests, issue triage, bug fix, security fix, accessibility improvement, localization, translation, API design, schema design, dashboard design, release notes, SBOM support, vulnerability disclosure support, or correction;
3. rights and contribution terms, including license, contributor agreement where applicable, IP status, attribution, confidentiality, data-use limits, AI-use limits, and public-safe documentation requirements;
4. review controls, including code review, dependency scanning, secret scanning, SBOM review, vulnerability review, threat modeling, secure defaults, accessibility testing, reproducibility review, documentation review, public-safe review, safeguard review, Registry review, Marketplace review, Grid review, and handoff review;
5. release and support status, including draft, in review, controlled release, public-good release, Studio-ready, Academy-ready, Reports-ready, Nexus Universe-ready, Marketplace candidate, Registry-recorded, supported, unsupported, deprecated, corrected, withdrawn, recalled, archived, or non-continuing;
6. recognition pathway, including iCRS entry, proof receipt, contribution ledger, maintainer record, ILA link, Registry link, Marketplace-display eligibility where permitted, micro-credential input where applicable, and correction history;
7. boundary controls, confirming that software contribution is not warranty, security certification, provider validation, procurement approval, production approval, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

Software contribution may produce important public-good infrastructure. It remains non-executing unless a separate competent actor lawfully deploys, operates, procures, finances, insures, or implements it through its own process.

### 15.8.5 Research Contribution

Research contribution is contribution involving scientific inquiry, technical research, policy research, legal research, social science research, field research, public-good software research, data research, AI research, cyber research, geospatial research, WFEH-B research, DRR research, DRF literacy research, DRI research, Observatory methods, Studio methods, governance methods, public-safe reporting methods, Labs streams, Reports inputs, Academy content, National Portfolio evidence, Nexus Universe outputs, and handoff-context research.

Research contribution should preserve the difference between inquiry, evidence, method, publication, translation, public-safe output, Foundry build, Grid input, and handoff context. Research promise is not validation. Peer review is not certification. Testbed performance is not production approval. A study is not public authority action, procurement readiness, financeability, insurability, consent, deployment authorization, or execution.

A Research Contribution Record should identify:

1. research object, including question, method, dataset, model, benchmark, prototype, literature review, field study, survey, interview record, simulation, digital twin, technical paper, public-safe summary, Report input, Academy module, Studio workflow, or Labs output;
2. research pathway, including Nexus Labs, university, research body, National Working Group, Competence Cell, Foundry pathway, Reports pathway, Academy pathway, Observatory pathway, DRI pathway, Nexus Universe pathway, or handoff context;
3. evidence and method status, including exploratory, preliminary, reproducible within scope, peer-reviewed where applicable, expert-reviewed, Studio-tested, public-safe transformed, Reports-ready, Foundry-ready, Grid-ready, handoff-context candidate, corrected, withdrawn, archived, or non-continuing;
4. ethics and safeguards, including research ethics where applicable, privacy, data-use labels, AI-use labels, community safeguards, Indigenous protocol controls where applicable, protected knowledge, youth and health safeguards, cyber sensitivity, geospatial sensitivity, publication limits, and public-safe review;
5. rights and publication controls, including IP, license, attribution, confidentiality, open science pathway, repository pathway, DOI pathway where applicable, embargo, correction, withdrawal, recall, and archive;
6. recognition pathway, including iCRS entry, ILA link, proof receipt, publication record, contribution record, review record, Registry link where applicable, Reports record, Academy record, Labs record, or Nexus Universe record;
7. boundary controls, confirming that research contribution is not validation, certification, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

Research contribution gives Nexus intellectual depth. It must remain reviewable, correctable, bounded, and honest about uncertainty.

### 15.8.6 Review Contribution

Review contribution is contribution involving the structured examination of Nexus objects, including data review, method review, indicator review, geospatial sensitivity review, cyber sensitivity review, AI review, privacy review, public-safe review, safeguard review, public authority boundary review, finance and insurance boundary review, legal boundary review, software review, security review, accessibility review, Registry review, Marketplace review, Grid review, TRL review, Studio review, Reports review, Campaign review, National Portfolio review, Nexus Universe review, handoff review, correction review, and archive review.

Review contribution is a high-trust contribution class. It must be based on role capability, contextual competence, conflict disclosure, evidence review, limitation statements, correction readiness, and boundary discipline.

A Review Contribution Record should identify:

1. object reviewed, including identifier, version, steward, portfolio relationship, Docket relationship, lifecycle state, Registry status, Marketplace status, support class, public-safe status, sensitivity class, and correction state;
2. review type and scope, including what was reviewed, what was not reviewed, what criteria were applied, and what boundaries govern the review;
3. reviewer role, including individual reviewer, team reviewer, guild reviewer, Competence Cell reviewer, expert panel reviewer, public-safe reviewer, safeguard reviewer, data steward, AI/cyber/privacy reviewer, public authority boundary reviewer, finance and insurance boundary reviewer, Grid reviewer, or handoff reviewer;
4. review outcome, including accepted within scope, accepted with conditions, returned for revision, restricted, escalated, suspended, withdrawn, recalled, archived, non-continuing, or referred to separate competent actor;
5. limitations and conflict controls, including conflict disclosure, uncertainty, evidence gaps, review limits, no-certification, no-procurement, no-finance, no-insurance, no-public-authority-action, no-consent, no-deployment, and no-execution language;
6. recognition pathway, including iCRS entry, ILA link, proof receipt, reviewer badge input where applicable, review record, Registry link, Grid link, handoff record, correction record, and archive;
7. boundary controls, confirming that review contribution is not universal validation, certification, public authority approval, procurement approval, finance approval, insurance approval, consent, deployment authorization, or execution.

Review contribution creates confidence within scope. It does not create authority beyond scope.

### 15.8.7 Mentorship Contribution

Mentorship contribution is contribution involving guidance, coaching, supervision, peer support, role development, apprenticeship support, internship support, WILP support, Academy cohort support, Foundry onboarding, Campaign leadership support, Studio practice support, National Portfolio capability support, Nexus Universe talent support, public authority learning support, safeguard practice support, and handoff literacy support.

Mentorship contribution helps convert knowledge into practice and practice into competence. It should be recognized because mentors create capability in others, not only artifacts. Mentorship must be safe, non-extractive, respectful, accessible, conflict-aware, and correctionable.

A Mentorship Contribution Record should identify:

1. mentorship pathway, including Academy, Risk Academy, apprenticeship, internship, cooperative education, field practicum, Studio practice, Foundry contribution, Campaign work, National Working Group, Competence Cell, Nexus Universe, public authority learning, secure room, data room, or handoff dependency pathway;
2. mentor role, including instructor, supervisor, coach, peer mentor, reviewer mentor, maintainer mentor, public-safe mentor, safeguard mentor, data mentor, AI mentor, cyber mentor, Studio mentor, Campaign mentor, or handoff mentor;
3. learner or cohort class, subject to privacy, youth, accessibility, community, and protected knowledge controls;
4. competency objectives, including skills, role capability, contextual competence, judgment, disposition, correction practice, and boundary literacy supported;
5. mentorship evidence, including session records, learning records, contribution reviews, feedback notes, proof receipts, learner progression records, micro-credential inputs where applicable, correction records, and archive;
6. safeguards, including youth protection, harassment prevention, accessibility, language support, non-discrimination, power-balance awareness, confidentiality, community safeguards, Indigenous protocol controls where applicable, and grievance pathways;
7. boundary controls, confirming that mentorship is not employment supervision unless separately recorded, not professional licensing, not credentialing authority unless separately recorded, not procurement qualification, not public authority qualification, not finance or insurance qualification, not consent, not deployment authorization, and not execution.

Mentorship contribution should strengthen human capability while protecting learners from dependency, exploitation, unsafe work, and overclaim.

### 15.8.8 Translation and Accessibility Contribution

Translation and accessibility contribution is contribution involving language translation, localization, interpretation, plain-language rewriting, accessible formatting, screen-reader compatibility, captions, transcripts, low-bandwidth adaptation, disability access support, visual simplification, multilingual glossary work, public-safe terminology adaptation, community language adaptation, cultural-context review, and accessible learning design.

Translation and accessibility contribution is essential to national ownership, whole-of-society participation, public-safe reporting, Academy access, Campaign inclusion, Nexus Universe participation, National Portfolio legitimacy, community participation, public authority learning, and lawful handoff context. It must be treated as substantive public-good work, not cosmetic support.

A Translation and Accessibility Contribution Record should identify:

1. object translated or made accessible, including Report, Academy module, Campaign material, Studio guide, dashboard, public-safe summary, Registry entry, Marketplace listing, DRI summary, GRIx term, National Portfolio object, Nexus Universe material, handoff-safe brief, or credential object;
2. language or accessibility scope, including language, dialect, plain-language level, accessibility standard or need, disability access feature, low-bandwidth adaptation, captioning, transcript, screen-reader formatting, visual accessibility, or community context;
3. review pathway, including translator review, local-context review, public-safe review, accessibility review, community review, Indigenous protocol review where applicable, technical review, legal boundary review, and correction review;
4. terminology controls, including GRIx consistency, public-safe language, legal boundary terms, non-warning language, no-certification language, no-procurement language, no-finance language, no-insurance language, no-public-authority-action language, no-consent language, no-deployment language, and no-execution language;
5. recognition pathway, including iCRS entry, ILA link, proof receipt, contribution record, translation record, accessibility record, micro-credential input where applicable, Registry link, Marketplace-display eligibility where permitted, and archive;
6. boundary controls, confirming that translation or accessibility contribution does not change legal meaning, create public authority action, create certification, authorize procurement, create finance or insurance status, grant consent, authorize deployment, or execute work.

Translation and accessibility contribution expands legitimacy and usability. It must preserve meaning, safeguards, and correctionability across languages and access contexts.

### 15.8.9 Campaign and Foundry Contribution

Campaign and Foundry contribution is contribution made through Nexus Campaigns, Nexus Foundry, Foundry BuildGrid, Nexus Universe preparation, National Portfolio build support, public-good software work, quest work, bounty work, build work, Campaign mobilization, volunteer coordination, support records, public-safe storytelling, Campaign dashboards, Foundry releases, Registry preparation, Marketplace preparation, Grid inputs, Academy conversion, Reports conversion, Studio workflow development, and handoff dependency preparation.

Campaign and Foundry contribution should be recognized because it is where mobilization and production become public-good capability. It must also be bounded because Campaign momentum and Foundry production can be mistaken for endorsement, procurement, finance, public authority action, consent, deployment, or execution.

A Campaign and Foundry Contribution Record should identify:

1. pathway, including Campaign, Foundry program, BuildGrid track, quest, bounty, build, Nexus Universe build, National Portfolio build, Academy conversion, Reports conversion, Studio workflow, Registry object, Marketplace object, Grid input, or handoff dependency package;
2. contribution type, including mobilization, signature support, pledge support, volunteer coordination, chapter support, ambassador work, public-safe storytelling, moderation, trust and safety, code, data, documentation, design, testing, review, release support, maintainer work, correction, archive, or handoff dependency mapping;
3. work classification, including volunteer work, learning work, bounty-supported work, stipend-supported work, contracted work, sponsored work, public authority learning work, or employment where separately recorded;
4. review and safeguard controls, including public-safe review, trust and safety review, sponsor-control review, provider-claim review, data review, AI review, cyber review, accessibility review, safeguard review, Registry review, Marketplace review, Grid review, handoff review, and correction review;
5. recognition pathway, including iCRS entry, ILA link, proof receipt, contribution ledger, Campaign support ledger, maintainer record, micro-credential input where applicable, Registry link, Marketplace display where eligible, Nexus Universe record, and archive;
6. boundary controls, including campaign-not-endorsement, support-not-control, provider-contribution-not-validation, Foundry-build-not-production-approval, Marketplace-listing-not-procurement, Grid-input-not-certification, handoff-context-not-execution, and no employment by implication.

Campaign and Foundry contribution creates movement and build capacity. It does not create authority to act outside Nexus public-good scope.

### 15.8.10 Public-Good Labor Boundary

Public-good labor boundary is the rule that contribution recognition must never be used to normalize disguised labor, unpaid substitution for paid work, extractive volunteering, coerced participation, pay-for-consent, pay-for-endorsement, pay-for-routing, pay-for-visibility, pay-for-credential, sponsor-controlled work, provider-controlled validation, or execution by contribution.

iCRS must distinguish contribution recognition from labor compensation. Recognition may include proof receipts, iCRS entries, ILA entries, badges, micro-credential inputs, public-safe attribution, maintainer records, support records, and contribution memory. Recognition is valuable, but it is not wages, employment benefits, contractor payment, procurement award, finance allocation, insurance value, donor commitment, or public authority compensation.

A Public-Good Labor Boundary Record should identify:

1. work classification, including volunteer work, learning work, bounty-supported work, stipend-supported work, contracted work, sponsored work, public authority learning work, employment where separately recorded, or other lawful category;
2. contribution recognition, including iCRS entry, proof receipt, badge input, ILA entry, public attribution, private attribution, contribution ledger entry, or micro-credential input;
3. compensation or support status, including none, reimbursement, stipend, bounty, prize, grant support, contract payment, employment compensation, sponsorship support, or other lawful support;
4. risk of disguised labor, including recurring controlled work, economically valuable work, enterprise-stack work, safety-sensitive work, regulated work, sponsor-directed work, provider-directed work, public authority work, or execution-like work;
5. required correction, including reclassification, compensation review, contract review, scope reduction, learner protection, withdrawal, archive, or non-continuation;
6. boundary notices, confirming that recognition is not employment, wages, procurement, finance, insurance, public authority action, consent, deployment authorization, or execution.

Public-good contribution must be recognized without being exploited. iCRS should elevate contribution, protect contributors, and preserve honest labor classification.

The final iCRS and Contribution Recognition rule is: iCRS records and recognizes learning, data, software, research, review, mentorship, translation, accessibility, Campaign, Foundry, and public-good contributions as evidence of participation, capability, practice, and trust. Contribution recognition supports ILA records, proof receipts, micro-credential inputs, Competence Cells, National Portfolios, Nexus Universe, and lawful handoff competence context, but it never substitutes for wages, employment, procurement qualification, provider validation, sponsor control, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.9 Career Mobility and Transition

### 15.9.1 Transition Doctrine

Transition doctrine is the SCF rule that career mobility, workforce transition, reskilling, upskilling, public-good contribution, work-integrated learning, micro-credentialing, recognition of prior learning, National Portfolio capability formation, Nexus Universe talent routing, and lawful handoff competence must be designed as dignity-preserving, evidence-based, inclusive, safeguarded, correctionable, and non-coercive pathways. Transition is not merely movement from one job title to another. It is the structured movement of people, skills, experience, identity, confidence, records, learning, contribution, and opportunity across changing work systems.

SCF transition doctrine recognizes that labor markets are being reshaped by AI, automation, climate transition, disaster risk, cyber risk, WFEH-B disruption, demographic change, regional inequality, migration, infrastructure transformation, public-sector capacity gaps, platform work, informal work, care work, and frontier technologies. Nexus must therefore treat transition as a public-good capability challenge, not only an individual employability problem.

A Transition Record should identify:

1. transition context, including youth entry, early-career formation, mid-career shift, displaced worker pathway, informal worker recognition, gig or platform work transition, migrant or refugee skills recognition, diaspora contribution, public authority learning, care-work recognition, community-work recognition, or public-good contribution pathway;
2. current capability base, including prior learning, experience, informal work, care work, community work, contribution records, credentials, skills, language, accessibility needs, digital access, and barriers;
3. target capability pathway, including Academy pathways, Risk Academy pathways, WILPs, micro-credentials, ILA records, iCRS recognition, Foundry roles, Campaign roles, Competence Cells, National Working Groups, Studio practice, Nexus Universe pathways, or handoff competence context;
4. support needs, including mentoring, stipends, accessibility support, childcare or care-sensitive scheduling, language support, devices, connectivity, transport, mental-load awareness, safe participation, credential translation, recognition of prior learning, and labor protections;
5. safeguards, including privacy, anti-discrimination, youth protection, migrant and refugee sensitivity, community dignity, non-extraction, data minimization, AI-use controls, and no social scoring;
6. boundary controls, confirming that transition records do not create employment guarantees, wage promises, immigration status, professional licensure, procurement qualification, finance qualification, insurance qualification, public authority status, consent, deployment authorization, or execution authority.

Transition doctrine should make opportunity pathways visible without overpromising outcomes. SCF may help people move, learn, contribute, and be recognized; it must not pretend to control employers, labor markets, public authorities, immigration systems, professional licensing bodies, funders, insurers, or procurement systems.

### 15.9.2 Youth and Early-Career Pathways

Youth and early-career pathways are SCF transition pathways for students, recent graduates, young workers, youth volunteers, young community leaders, early-career professionals, apprentices, interns, fellows, campaign ambassadors, Foundry contributors, Academy learners, Risk Academy learners, Nexus Universe participants, and young public-good builders. These pathways should create safe entry into Nexus learning, contribution, public-good technology, risk literacy, WFEH-B systems, data, AI, cyber, public-safe reporting, safeguards, and lawful handoff literacy.

Youth and early-career pathways must be designed with heightened safeguards. They should protect participants from unsafe publicity, excessive data collection, exploitative unpaid work, credential inflation, unrealistic job promises, inappropriate contact, unsafe field work, unmanaged online spaces, youth data exposure, and social pressure to contribute beyond reasonable limits.

A Youth and Early-Career Pathway Record should identify:

1. participant class, including minor youth, secondary student, post-secondary student, early-career learner, apprentice, intern, fellow, volunteer, ambassador, contributor, or youth community participant;
2. pathway type, including Academy cohort, Risk Academy cohort, WILP, apprenticeship, internship, cooperative education, Foundry contribution, Campaign participation, Studio practice, National Portfolio participation, Competence Cell participation, Nexus Universe participation, or community learning pathway;
3. competency goals, including foundational literacy, digital and data skills, AI and human-AI collaboration, cyber hygiene, public-safe reporting, systems thinking, WFEH-B literacy, DRR literacy, DRI literacy, governance ethics, communication, safeguards, and handoff literacy;
4. support structure, including mentor, supervisor, cohort facilitator, youth safeguard lead, accessibility support, language support, safe communications rules, guardian or institutional consent where applicable, grievance pathway, and correction pathway;
5. recognition pathway, including learning records, proof receipts, ILA entries, iCRS entries, micro-credential inputs where applicable, Campaign records, Foundry contribution records, Nexus Universe records, and archive;
6. boundary notices, confirming that participation is not employment, professional certification, public authority qualification, procurement qualification, finance qualification, insurance qualification, consent, deployment authorization, or execution.

Youth and early-career pathways should open doors without exploiting aspiration. They should build confidence, public-good identity, technical literacy, systems literacy, and contribution discipline while preserving safety, dignity, and realistic boundaries.

### 15.9.3 Mid-Career Transition

Mid-career transition is the SCF pathway for workers, professionals, managers, practitioners, public-sector staff, technical specialists, care workers, community workers, vocational workers, enterprise employees, nonprofit staff, consultants, and sector experts who need to adapt, reskill, upskill, redirect, or deepen their capabilities in response to changing risk, technology, climate, labor-market, sector, or public-good demands.

Mid-career participants often bring valuable contextual competence, domain knowledge, professional judgment, leadership experience, institutional memory, community trust, operational experience, and practical systems knowledge. SCF should not treat them as beginners merely because they lack a new digital credential. Instead, it should support recognition of prior learning, task-to-skill mapping, bridge modules, WILPs, mentoring, peer learning, Foundry contribution, Studio practice, Campaign leadership, National Portfolio participation, and handoff literacy.

A Mid-Career Transition Record should identify:

1. current role and experience context, including sector, occupation family, task history, informal expertise, public-good work, leadership experience, technical experience, community experience, public authority experience, or enterprise experience;
2. transition driver, including AI adoption, automation, climate transition, disaster-risk need, cyber risk, sector restructuring, public-service transformation, WFEH-B need, new technology, national priority, or personal career change;
3. prior learning recognition, including formal credentials, work samples, contribution records, professional experience, community work, care work, open-source work, public authority work, humanitarian work, or research output;
4. bridge pathway, including Academy modules, Risk Academy modules, data governance learning, AI governance learning, cyber learning, public-safe reporting learning, safeguard learning, Studio practice, Foundry builds, Campaign roles, National Working Groups, Competence Cells, or Nexus Universe participation;
5. support needs, including flexible scheduling, recognition of experience, mentoring, peer cohort design, accessibility, language, care-sensitive participation, employer support where lawful, stipend support where appropriate, and labor protections;
6. boundary controls, confirming that mid-career transition records do not create employment placement, wage guarantee, professional license, procurement qualification, finance qualification, insurance qualification, public authority status, consent, deployment authorization, or execution.

Mid-career transition should value existing competence while enabling new capability. It should prevent both credential gatekeeping and unsafe over-recognition.

### 15.9.4 Displaced Worker Pathways

Displaced worker pathways are SCF transition pathways for people whose work, livelihood, occupation, sector, region, or enterprise role has been disrupted by automation, AI, climate change, disaster, economic restructuring, conflict, public health disruption, supply-chain change, sector decline, infrastructure change, platformization, organizational closure, public-sector reform, or other material labor-market shock.

Displaced worker pathways should be practical, respectful, and protection-oriented. They should not treat displacement as personal failure. They should identify transferable skills, hidden competence, urgent support needs, learning pathways, public-good contribution opportunities, WILPs, Recognition of Prior Learning, ILA records, iCRS records, National Portfolio opportunities, Campaign pathways, Foundry roles, Academy pathways, Risk Academy pathways, and lawful handoff-relevant competence.

A Displaced Worker Pathway Record should identify:

1. displacement context, including sector, region, occupation family, transition driver, time sensitivity, public authority or employer support context where applicable, and worker-protection concerns;
2. transferable competence, including technical skills, vocational skills, digital skills, care skills, community skills, systems knowledge, operational experience, safety knowledge, leadership, language, public-good experience, and informal work;
3. transition pathway options, including bridge learning, micro-credentials, WILPs, apprenticeships, internships where appropriate, cooperative education, Foundry contribution, Campaign roles, Studio practice, Competence Cells, National Working Groups, and Nexus Universe pathways;
4. support needs, including income-support referral where lawful and separate, stipends, devices, connectivity, childcare, transport, accessibility, language, mental-load awareness, mentoring, peer cohorts, and local support;
5. safeguards, including privacy, anti-stigma, non-discrimination, no automated ranking, no social scoring, data minimization, and consent controls;
6. boundary notices, confirming that Nexus transition support is not unemployment benefit determination, immigration determination, job placement guarantee, wage guarantee, employer commitment, professional licensing, public authority decision, procurement qualification, finance qualification, insurance qualification, deployment authorization, or execution.

Displaced worker pathways should convert disruption into recorded capability pathways wherever possible, while being honest that Nexus does not control labor-market outcomes.

### 15.9.5 Informal Worker Recognition

Informal worker recognition is the SCF pathway for recognizing competence developed outside formal employment, formal education, conventional credentials, or standard job classifications. Informal workers may include care workers, domestic workers, community organizers, mutual-aid participants, family business workers, agricultural workers, craft workers, repair workers, local guides, crisis volunteers, public-interest contributors, open-source contributors, community health supporters, informal logistics actors, and others whose work may be essential to resilience but under-recognized by formal systems.

Informal worker recognition should be rights-aware and non-extractive. It should not expose people to surveillance, taxation risk, immigration risk, employer retaliation, community harm, stigma, exploitative recruitment, or unpaid labor demands. Recognition should be voluntary, privacy-governed, context-specific, and correctable.

An Informal Worker Recognition Record should identify:

1. work context, including informal, care, community, mutual-aid, household, agricultural, repair, logistics, digital, open-source, public-good, crisis, or place-based work;
2. competence evidence, including self-attestation where appropriate, community attestation where appropriate, work samples, contribution records, learning records, proof receipts, portfolio evidence, mentor review, practical demonstration, or Recognition of Prior Learning review;
3. SCF competency mapping, including foundational literacy, technical and vocational competence, care and community competence, digital skills, public-safe reporting, systems thinking, risk and resilience, safeguards, communication, and handoff literacy where relevant;
4. privacy and display controls, including private record, learner-controlled display, pseudonymous recognition, community-sensitive handling, youth protections, protected knowledge restrictions, and Marketplace-display limitations;
5. transition pathways, including Academy bridge modules, WILPs, Campaign roles, Foundry tasks, Competence Cells, National Portfolio roles, Nexus Universe participation, or lawful handoff competence context;
6. boundary controls, confirming that recognition is not employment status, wage entitlement, benefit eligibility, immigration status, professional license, procurement qualification, finance qualification, insurance qualification, public authority status, consent, deployment authorization, or execution.

Informal worker recognition should broaden the definition of capability without converting people’s lives into extractive data.

### 15.9.6 Gig and Platform Worker Pathways

Gig and platform worker pathways are SCF transition pathways for people whose work is mediated through digital platforms, short-term tasks, on-demand services, freelance markets, creator platforms, delivery platforms, ride platforms, microwork, data labeling, online freelancing, technical contracting, creative work, or other non-standard work arrangements.

Gig and platform workers may have strong transferable skills, including digital navigation, customer interaction, logistics, time management, route planning, platform literacy, micro-task execution, content production, language skills, data skills, technical problem solving, local knowledge, and resilience under uncertainty. They may also face precarious income, lack of benefits, algorithmic control, surveillance, unfair ratings, unstable work, safety risks, and weak recognition.

A Gig and Platform Worker Pathway Record should identify:

1. work type, including platform work, gig work, freelance work, online work, delivery, mobility, care platform work, creative platform work, technical platform work, microwork, data labeling, or task-based work;
2. competence evidence, including work samples, contribution records, platform-derived records where voluntarily provided and lawful, self-attestation, peer attestation, client feedback where appropriate, practical demonstrations, learning records, or iCRS records;
3. transferable skills, including digital literacy, logistics, communication, customer service, data handling, platform navigation, problem solving, local knowledge, technical skills, language skills, and resilience skills;
4. transition needs, including stable learning pathways, WILPs, Recognition of Prior Learning, micro-credentials, ILA records, support for digital trust, AI literacy, cyber hygiene, data governance, public-safe reporting, and Foundry or Campaign roles;
5. worker protections, including privacy, no platform surveillance import by default, no automated ranking, no social scoring, no coerced disclosure, no discriminatory screening, and no employment-status misrepresentation;
6. boundary notices, confirming that pathway records are not employment decisions, wage determinations, benefit eligibility, immigration status, professional licensing, procurement qualification, finance qualification, insurance qualification, public authority decisions, consent, deployment authorization, or execution.

Gig and platform worker pathways should recognize capability without reproducing platform harms inside SCF.

### 15.9.7 Migrant, Refugee, and Diaspora Skills

Migrant, refugee, and diaspora skills are SCF transition pathways for recognizing, translating, protecting, and mobilizing skills, learning, experience, credentials, languages, cultural knowledge, professional background, technical experience, community experience, crisis experience, public-good contribution, and cross-border knowledge held by migrants, refugees, displaced persons, and diaspora communities.

These pathways must be handled with heightened care. Skills recognition should not expose immigration status, legal vulnerability, trauma histories, sensitive locations, protected knowledge, political risk, employer retaliation, community risk, or personal safety risks. Nexus must not provide immigration advice, legal status determination, credential equivalency determination for regulated purposes, employment guarantees, or public authority decisions by implication.

A Migrant, Refugee, and Diaspora Skills Record should identify:

1. participant context, subject to strict privacy and safety controls, including migrant, refugee, displaced person, diaspora participant, international student, internationally trained professional, cross-border worker, or diaspora contributor;
2. skills and experience evidence, including prior credentials, work history, self-attestation, portfolio evidence, community attestation where appropriate, language ability, technical work, care work, crisis experience, humanitarian experience, public-good contribution, and Nexus contribution records;
3. recognition pathway, including Recognition of Prior Learning, Academy bridge modules, language support, credential translation support where lawful and non-determinative, WILPs, mentorship, Campaign roles, Foundry roles, National Portfolio contribution, Nexus Universe participation, or diaspora support pathways;
4. safeguards, including privacy, anti-discrimination, trauma-aware participation where relevant, legal-status sensitivity, data minimization, no public display by default, pseudonymity where appropriate, youth safeguards, community safeguards, and protected knowledge controls;
5. national and diaspora contribution pathways, including diaspora-to-national capability support, National Node support, Academy support, Campaign support, public-safe reporting, technical contribution, mentoring, translation, investment-literacy participation without finance overclaim, and handoff competence context;
6. boundary notices, confirming that SCF recognition is not immigration status, credential equivalency for regulated purposes, employment authorization, job guarantee, public benefit determination, professional licensure, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution.

Migrant, refugee, and diaspora skills pathways should widen access and respect dignity without exposing people to harm or overclaiming legal effect.

### 15.9.8 Skills-Based Career Mobility

Skills-based career mobility is the SCF pathway for supporting movement across roles, sectors, technologies, public-good work, National Portfolio needs, Foundry roles, Campaign roles, Competence Cells, Studio practice, Nexus Universe participation, and lawful handoff competence through demonstrated skills rather than only degrees, job titles, institutional pedigree, or conventional credentials.

Skills-based mobility should use occupation-to-task-to-skill decomposition, Recognition of Prior Learning, ILA records, iCRS contribution records, micro-credentials, WILP records, proof receipts, competency portfolios, skills wallets, and contextual competence records to identify plausible pathways. It should remain honest about where separate credentials, licenses, employer decisions, public authority approvals, procurement qualifications, finance qualifications, or insurance qualifications are required.

A Skills-Based Career Mobility Record should identify:

1. source skill profile, including skills, tasks, competencies, practice evidence, contribution evidence, learning evidence, review evidence, informal competence, and contextual competence;
2. target pathway, including Academy pathway, Risk Academy pathway, Foundry role, Campaign role, Competence Cell role, National Working Group role, Studio role, DRI role, public-safe reporting role, data steward role, AI review role, cyber review role, Nexus Universe role, or lawful handoff competence context;
3. gap analysis, including missing knowledge, skill, ability, practice, judgment, disposition, role capability, contextual competence, evidence, safeguards, or formal requirements;
4. bridge plan, including modules, WILPs, mentorship, supervised practice, micro-credential inputs, contribution tasks, review tasks, Studio exercises, Campaign work, Foundry quests, or National Portfolio participation;
5. evidence and display controls, including ILA display, Marketplace-display eligibility, National Node visibility, reviewer visibility, privacy, and correction;
6. boundary controls, confirming that skills-based mobility support is not job matching guarantee, employment decision, credential equivalency, professional licensing, procurement qualification, finance qualification, insurance qualification, public authority decision, immigration status, consent, deployment authorization, or execution.

Skills-based mobility should make opportunity less dependent on pedigree while preserving safety, evidence, and lawful boundaries.

### 15.9.9 Inclusion and Equity

Inclusion and equity are mandatory design principles for SCF career mobility and transition. They require that learning, recognition, contribution, WILPs, ILA records, iCRS recognition, micro-credentials, Academy pathways, Campaign roles, Foundry roles, Nexus Universe pathways, National Portfolio roles, and handoff competence pathways be accessible, fair, non-discriminatory, language-aware, disability-aware, gender-aware, youth-aware, care-aware, community-aware, migrant-aware, refugee-aware, rural-aware, low-bandwidth-aware, and dignity-preserving.

Inclusion and equity should not be reduced to representation counts. They should be embedded in pathway design, outreach, access, support, scheduling, language, technology, credential recognition, public-safe reporting, data governance, privacy, correction, and labor protection.

An Inclusion and Equity Record should identify:

1. equity context, including barriers related to language, disability, geography, connectivity, care responsibilities, youth status, age, gender, income, displacement, migration, refugee status, informal work, platform work, community role, Indigenous protocol context where applicable, or credential recognition;
2. access design, including multilingual materials, plain language, accessibility, low-bandwidth options, flexible timing, care-sensitive participation, device support, connectivity support, local facilitation, community pathways, and safe participation channels;
3. recognition fairness, including Recognition of Prior Learning, informal work recognition, care work recognition, community work recognition, international credential sensitivity, contribution recognition, and bias review;
4. data safeguards, including data minimization, privacy, youth safeguards, protected knowledge controls, consent boundaries, no social scoring, no automated exclusion, and display controls;
5. correction pathway, including complaint, appeal, record correction, misclassification correction, harmful display removal, public repair where required, and archive;
6. boundary notices, confirming that inclusion records are not preferential procurement decisions, employment guarantees, public authority determinations, immigration determinations, benefit determinations, finance or insurance determinations, consent, deployment authorization, or execution.

Equity in SCF means people can enter, learn, contribute, be recognized, and transition without being forced into unsafe, extractive, inaccessible, or misleading pathways.

### 15.9.10 Worker Protection and Job Quality

Worker protection and job quality are SCF principles that ensure career mobility and transition do not become a mechanism for precarious work, disguised labor, unpaid substitution, unsafe gigification, credential exploitation, surveillance, social scoring, wage suppression, or responsibility shifting onto workers. SCF must treat job quality, labor protections, safe work, fair classification, learning value, dignity, and worker voice as part of competence architecture.

Worker protection and job quality records should apply to WILPs, apprenticeships, internships, cooperative education, field practice, Foundry contribution, Campaign work, bounty-supported work, stipend-supported work, volunteer work, sponsored work, contracted work, public authority learning work, National Portfolio participation, Nexus Universe participation, and handoff competence contexts.

A Worker Protection and Job Quality Record should identify:

1. work or transition pathway, including learning work, volunteer work, bounty-supported work, stipend-supported work, contracted work, sponsored work, public authority learning work, employment where separately recorded, gig transition pathway, informal worker recognition, or WILP;
2. classification accuracy, including whether the work is correctly classified, whether compensation or support is appropriate, whether supervision creates employment-like control, and whether legal review is required;
3. job quality dimensions, including safety, dignity, predictability, fair treatment, accessibility, learning value, support, grievance pathways, reasonable workload, role clarity, data protection, non-discrimination, and correction rights;
4. risk indicators, including disguised labor, excessive unpaid work, unsafe work, platform-like surveillance, automated ranking, coercive credentialing, pay-for-certification, sponsor-directed work, provider-directed work, public authority role confusion, or execution-like tasks;
5. corrective actions, including reclassification, compensation review, scope reduction, contract conversion, learning redesign, safeguard escalation, withdrawal, public repair where required, archive, or non-continuation;
6. boundary controls, confirming that SCF career mobility support is not employment guarantee, wage determination, labor-law compliance certification, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution.

Worker protection is not external to SCF. It is a measure of whether transition pathways are legitimate. A pathway that produces impressive metrics while degrading job quality, exploiting unpaid work, or misclassifying labor is not a successful Nexus pathway.

The final Career Mobility and Transition rule is: SCF transition doctrine supports youth and early-career entry, mid-career mobility, displaced worker pathways, informal worker recognition, gig and platform worker pathways, migrant, refugee, and diaspora skills, skills-based mobility, inclusion and equity, and worker protection. Career mobility records help people move from capability to opportunity through learning, contribution, recognition, WILPs, ILA, iCRS, National Portfolios, Nexus Universe, and lawful handoff competence context, while never creating job guarantees, wage promises, immigration status, professional licensure, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

## 15.10 AI-Era Work and Future Skills

### 15.10.1 AI as Work Transformation

AI as work transformation is the SCF recognition that artificial intelligence, machine learning, foundation-model interfaces, retrieval systems, agentic workflows, automation tools, decision-support systems, digital twins, simulation systems, intelligent dashboards, code assistants, data assistants, robotics, cyber-physical systems, and human-AI collaboration environments are reshaping tasks, roles, occupations, workflows, organizations, public services, labor markets, public-good work, and lawful handoff contexts.

AI-era work transformation must be treated as a systems change, not a narrow technology adoption issue. AI may automate some tasks, augment others, create new review responsibilities, increase demand for data stewardship, change cyber risk, alter public-safe reporting, reshape public authority learning, affect finance-readiness and insurance-readiness questions, change WFEH-B system operations, and create new needs for human judgment, safeguards, correction, and accountability.

An AI Work Transformation Record should identify:

1. work domain affected, including data, software, public-safe reporting, AI review, cyber, privacy, geospatial, WFEH-B, DRR, DRF, DRI, public authority learning, Campaigns, Foundry, Studio, Reports, Academy, Registry, Marketplace, Grid, National Portfolios, Nexus Universe, or lawful handoff;
2. task changes, including tasks automated, tasks augmented, tasks requiring human review, tasks requiring new safeguards, tasks requiring new documentation, and tasks requiring separate lawful authority;
3. competency implications, including AI literacy, prompt and tool-use discipline, output review, model limitation understanding, data-use and AI-use labels, human judgment, bias and harm review, cybersecurity, privacy, public-safe reporting, and correctionability;
4. labor-market implications, including emerging roles, declining tasks, transition needs, worker protection needs, employer demand signals, skills gaps, informal work impacts, public-good work opportunities, and National Portfolio capability needs;
5. safeguards, including privacy, bias, discrimination, surveillance, worker ranking, social scoring, youth protection, protected knowledge, Indigenous protocol-sensitive materials where applicable, cyber risk, public authority overclaim, finance and insurance overclaim, and deployment overclaim;
6. boundary notices, confirming that AI-era work records are not employment decisions, worker rankings, automation mandates, public authority decisions, procurement approvals, finance or insurance qualifications, consent, deployment authorization, or execution.

AI should be understood as changing the composition of work, not eliminating the need for human competence. SCF should help people, teams, institutions, and National Portfolios identify what must be learned, reviewed, protected, corrected, and handed off responsibly in an AI-shaped labor environment.

### 15.10.2 Human-AI Collaboration Competence

Human-AI collaboration competence is the capability to work with AI systems in ways that are useful, bounded, evidence-aware, secure, privacy-protective, public-safe, safeguard-compliant, and correctionable. It includes knowing when AI can assist, when it must not be used, when human-in-the-loop review is required, when human-on-the-loop oversight is sufficient, when escalation is required, and when AI use must be prohibited.

Human-AI collaboration competence should include:

1. AI task framing, including defining the task, scope, data class, output class, review need, public-safe status, access class, and prohibited uses before AI is used;
2. AI-use label application, including no-AI use, retrieval-only, summarization with review, classification with review, evaluation-only, fine-tuning permitted, training permitted, agentic use prohibited, secure-room AI only, and public-safe AI output only;
3. prompt and workflow discipline, including source grounding, tool-permission awareness, prompt-injection caution, no-write-back rules, no-command rules, logging, output review, and escalation triggers;
4. output evaluation, including checking for hallucination, bias, missing context, unsupported claims, public-safe risk, confidentiality risk, data leakage, legal-boundary risk, finance or insurance overclaim, public authority overclaim, and consent overclaim;
5. collaborative production, including using AI to support drafting, coding, translation, summarization, review support, scenario preparation, data documentation, accessibility adaptation, learning-object generation, and correction without replacing accountable human review;
6. correction practice, including recording AI use, correcting AI-generated errors, withdrawing unsafe outputs, recalling affected objects, updating model or system cards, and archiving AI-assisted work with proper status.

Human-AI collaboration competence does not authorize automated decision-making. A person’s ability to use AI tools does not create professional licensure, procurement qualification, finance qualification, insurance qualification, public authority status, consent authority, deployment authority, or execution authority.

### 15.10.3 Automation Exposure Literacy

Automation exposure literacy is the capability to understand which tasks, roles, workflows, sectors, work units, and contribution pathways may be affected by automation, AI augmentation, algorithmic management, agentic workflows, robotics, data pipelines, digital twins, decision-support systems, and platform-mediated work. It helps learners, workers, institutions, National Portfolios, Academy pathways, Foundry roles, Campaign roles, and handoff recipients plan transition without panic, overclaim, or false certainty.

Automation exposure literacy should distinguish between:

1. task exposure, where parts of a role may be automated or augmented;
2. role transformation, where the mix of tasks changes but human responsibility remains;
3. workflow redesign, where AI changes handoffs, review gates, documentation, or quality controls;
4. new task creation, where AI creates demand for reviewers, data stewards, AI governance, prompt-injection reviewers, model card authors, public-safe reviewers, safeguard reviewers, and correction stewards;
5. risk amplification, where automation increases speed, scale, opacity, bias, surveillance, cyber risk, public authority overclaim, finance overclaim, or deployment overclaim;
6. non-automatable human value, including judgment, care, trust, community context, ethics, public-safe communication, legal-boundary interpretation, safeguard review, contextual competence, and correction.

An Automation Exposure Record should identify the task family, occupation family, affected competencies, automation mechanism, augmentation pathway, uncertainty level, human review needs, transition pathway, safeguard risks, worker protection concerns, and correction pathway.

Automation exposure literacy shall not be used to rank workers, label people obsolete, determine employment, set wages, determine immigration or benefits, deny opportunity, or create automated labor-market decisions. It is a planning and learning tool, not a judgment on people.

### 15.10.4 AI Augmentation Literacy

AI augmentation literacy is the capability to identify how AI can responsibly support human work without displacing accountability, weakening safeguards, increasing hidden risk, degrading public-safe reporting, or creating execution by implication. AI augmentation should be understood as structured assistance under human responsibility, not as autonomous authority.

AI augmentation literacy should include:

1. appropriate use identification, including recognizing where AI may support summarization, translation, coding assistance, data cleaning support, metadata drafting, literature review support, scenario drafting, test generation, accessibility adaptation, learning support, and public-safe draft preparation;
2. inappropriate use identification, including recognizing where AI must not be used for consent determination, public authority decision, public warning, emergency command, legal determination, investment advice, underwriting, procurement decision, worker ranking, community representation, protected knowledge processing, or execution command;
3. augmentation workflow design, including human review points, source checks, data-use limits, AI-use labels, audit trails, output review, public-safe transformation, escalation triggers, and correction pathways;
4. quality control, including validating sources, checking calculations, reviewing assumptions, testing code, identifying hallucinations, documenting uncertainty, and recording limitations;
5. role preservation, including making clear who is accountable, what the AI assisted with, what humans reviewed, and what remains outside AI authority;
6. learning transfer, including helping participants use AI to strengthen capability rather than become dependent on unreviewed output.

AI augmentation literacy should help people become more capable, not less accountable. AI-supported work remains subject to Nexus records, review, safeguards, correction, and no-conversion boundaries.

### 15.10.5 AI Governance Literacy

AI governance literacy is the capability to understand and apply the rules, records, labels, reviews, safeguards, documentation, and correction pathways that govern AI use within Nexus. It is required for anyone who designs, uses, reviews, publishes, lists, registers, teaches, demonstrates, or hands off AI-assisted objects.

AI governance literacy should include:

1. AI object governance, including model objects, system objects, agentic workflow objects, evaluation harnesses, benchmark cards, model cards, system cards, agent workflow cards, AI-use labels, and AI incident records;
2. data governance for AI, including training data constraints, fine-tuning permissions, retrieval-only conditions, no-AI-use labels, protected knowledge exclusions, privacy controls, youth and health safeguards, public authority-sensitive data controls, and cross-border controls;
3. review governance, including bias and harm review, red-team records, evaluation records, prompt-injection controls, tool-permission controls, drift detection, public-safe review, safeguard review, cyber review, and correction review;
4. agentic workflow governance, including agent identity, tool permissions, human-in-the-loop requirements, human-on-the-loop requirements, no-command rules, no-write-back rules, output review, escalation triggers, kill-switch conditions, and incident records;
5. public-safe AI governance, including AI output labeling, confidence and uncertainty language, public authority boundary language, finance and insurance boundary language, consent boundary language, and deployment boundary language;
6. AI boundary rules, including model card is not AI safety certification, benchmark result is not general validation, agent output is not determination, AI workflow is not public authority decision, model release is not deployment authorization, and evaluation is not financeability, insurability, or procurement readiness.

AI governance literacy should be embedded across Academy, Risk Academy, Foundry, Studio, Campaigns, Reports, DRI, Observatory, Registry, Marketplace, Grid, National Portfolios, Nexus Universe, and handoff pathways. It does not create AI certification, legal compliance certification, public authority approval, procurement qualification, finance qualification, insurance qualification, consent, deployment authorization, or execution authority.

### 15.10.6 Human Oversight and Judgment

Human oversight and judgment are the SCF competencies required to ensure that AI-assisted work remains accountable, contextual, ethical, public-safe, safeguard-compliant, and correctable. Human oversight is not a decorative approval step. It must be meaningful, documented, competent, and empowered to pause, reject, correct, withdraw, recall, or escalate AI-assisted outputs.

Human oversight and judgment should include:

1. review competence, including the ability to check AI outputs against sources, evidence records, methods, data-use labels, AI-use labels, public-safe requirements, safeguards, boundary notices, and correction history;
2. contextual judgment, including understanding national, regional, community, Indigenous protocol-sensitive where applicable, public authority, finance-readiness, insurance-readiness, WFEH-B, DRR, DRI, cyber, geospatial, health, youth, and protected knowledge contexts;
3. escalation judgment, including knowing when to route to AI review, cyber review, privacy review, public-safe review, safeguard review, public authority boundary review, finance and insurance boundary review, legal boundary review, or handoff review;
4. stop-the-line authority within Nexus scope, including pausing AI use where there is data leakage, protected knowledge exposure, hallucination risk, public authority overclaim, finance or insurance overclaim, discrimination risk, unsafe automation, cyber issue, or execution overclaim;
5. correction judgment, including determining whether AI-generated or AI-assisted outputs require correction, restriction, withdrawal, recall, public repair, archive, model update, prompt update, workflow change, or non-continuation;
6. accountability clarity, including documenting who reviewed the output, what was reviewed, what limits remain, what decisions were not made, and what separate competent actor must decide outside Nexus.

Human judgment is the safety layer between AI assistance and public meaning. It must not be replaced by automation where rights, public trust, sensitive data, public authority meaning, finance or insurance meaning, consent, deployment, or execution may be affected.

### 15.10.7 AI Labor-Market Monitoring

AI labor-market monitoring is the SCF function for tracking how AI changes tasks, roles, occupations, skills, employer demand, worker transition, public-good contribution, informal work, gig work, care work, public authority capacity, National Portfolio capability, Foundry roles, Campaign roles, Nexus Universe talent needs, and lawful handoff competence assumptions.

AI labor-market monitoring should be evidence-based, human-reviewed, privacy-preserving, non-discriminatory, and correctionable. It may use job posting intelligence, employer demand signals, worker transition signals, regional and national skills signals, Academy records, iCRS records, ILA-derived aggregated records, Campaign signals, Foundry records, Marketplace discovery signals, public authority learning records, and DRI or Observatory signals, subject to lawful data-use and AI-use labels.

An AI Labor-Market Monitoring Record should identify:

1. monitoring question, including task transformation, automation exposure, augmentation need, new role emergence, skill gap, worker transition need, regional capacity need, national capability need, or handoff competence need;
2. data sources, including postings, surveys, public sources, Academy records, ILA aggregates, iCRS aggregates, National Portfolio records, Marketplace signals, Campaign signals, Foundry records, Studio records, public authority learning records, and human expert inputs;
3. AI method and human review, including extraction, clustering, classification, forecasting, bias review, uncertainty labeling, expert review, safeguard review, and correction review;
4. outputs, including skill signals, task signals, transition signals, learning needs, Foundry role needs, Academy module needs, Competence Cell needs, Nexus Universe talent needs, and handoff competence assumptions;
5. prohibited uses, including automated hiring, automated firing, worker ranking, wage determination, immigration decision, benefit decision, social scoring, procurement qualification, public authority decision, finance qualification, insurance qualification, or execution decision;
6. correction and archive, including forecast correction, bias correction, source correction, model correction, withdrawal, recall, archive, and non-continuation.

AI labor-market monitoring should help Nexus adapt learning and capability pathways. It must not become a surveillance or ranking system for workers.

### 15.10.8 AI Work Safeguards

AI work safeguards are the protections required wherever AI affects work, learning, contribution, review, recognition, labor-market intelligence, transition pathways, ILA records, iCRS records, micro-credentials, WILPs, Foundry tasks, Campaign roles, public authority learning, National Portfolios, Nexus Universe routing, Marketplace display, Registry linkage, or handoff competence context.

AI work safeguards should include:

1. data minimization, ensuring only necessary labor, learning, contribution, or competency data is processed;
2. purpose limitation, ensuring AI is used only for recorded learning, capability, routing, analysis, planning, review-support, or public-good purposes;
3. human review, ensuring AI outputs affecting people, roles, recognition, learning pathways, or public display are reviewed by competent humans;
4. bias and harm review, including attention to gender, age, disability, language, region, migration status, informal work, care work, community work, youth, and other vulnerability contexts;
5. privacy protection, including learner control, selective disclosure, aggregation, de-identification, suppression, youth protection, sensitive-data exclusion, and display limits;
6. no social scoring, prohibiting AI use to rank people’s worth, civic value, employability, trustworthiness, community standing, or opportunity entitlement by default;
7. no automated exclusion, prohibiting AI-only denial of learning access, contribution opportunity, Campaign participation, Marketplace display, WILP participation, credential recognition, or transition support;
8. worker protection, including no covert monitoring, no platform-like surveillance, no opaque productivity scoring, no wage determination, no automated employment decisions, and no disguised labor;
9. correction rights, including the ability to dispute, correct, withdraw, restrict, seal, archive, or remove AI-affected records where lawful and appropriate;
10. boundary notices, confirming that AI work outputs do not create employment decisions, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution.

AI work safeguards must be designed before AI labor tools are scaled. A system that improves apparent efficiency while harming dignity, privacy, fairness, or correctionability is not acceptable within SCF.

### 15.10.9 No Automated Worker Ranking by Default

No automated worker ranking by default is the SCF rule that Nexus shall not use AI systems, labor-market intelligence, ILA records, iCRS records, micro-credentials, WILP records, contribution records, learning records, skills-wallet data, Marketplace-display records, Academy records, Campaign records, Foundry records, Nexus Universe records, or National Portfolio records to automatically rank workers, learners, contributors, volunteers, communities, youth, migrants, refugees, informal workers, gig workers, public authority learners, or public-good participants by worth, employability, quality, trustworthiness, social value, procurement value, finance value, insurance value, or execution suitability.

This rule protects people from hidden algorithmic gatekeeping. Nexus may route learning opportunities, suggest pathways, identify competency gaps, recommend bridge modules, match volunteers to safe tasks, support reviewer discovery, or help participants display records where they choose, but such systems must be bounded, explainable, human-reviewed where consequential, correctable, and non-coercive.

No automated worker ranking requires:

1. no opaque scores, unless the score is strictly bounded, explained, non-consequential by default, human-reviewed where relevant, and not used as a gatekeeping decision;
2. no social scoring, including no ranking of civic value, public-good value, trustworthiness, community legitimacy, or personal worth;
3. no automated exclusion, including no AI-only denial of learning, participation, credential recognition, Marketplace display, WILP access, contribution routing, or transition support;
4. no employment decision by Nexus, including no automated hiring, firing, promotion, demotion, wage, benefit, immigration, or labor-status decision;
5. no procurement, finance, or insurance gatekeeping, including no automated qualification for vendor status, procurement status, investment status, credit status, underwriting status, donor status, or public finance status;
6. human appeal and correction, including explanation, dispute, correction, restriction, withdrawal, archive, and public repair where required;
7. privacy and display control, including learner-controlled display, aggregation for national capability inputs, youth protection, sensitive-data restrictions, and non-discrimination review.

The default rule is restraint. If a future Nexus pathway ever proposes consequential automated ranking, it must be treated as a high-risk AI governance matter requiring separate lawful authority, explicit purpose, independent review, human appeal, privacy safeguards, bias review, public-safe review, legal boundary review, and recorded approval by the competent body. Until then, SCF recognizes people through records, not rankings.

The final AI-Era Work and Future Skills rule is: AI transforms work by changing tasks, roles, workflows, risks, and capability needs. SCF responds through human-AI collaboration competence, automation exposure literacy, AI augmentation literacy, AI governance literacy, human oversight and judgment, AI labor-market monitoring, AI work safeguards, and a default prohibition on automated worker ranking. AI may support learning, contribution, forecasting, routing, and public-good production, but it must never become hidden labor authority, worker surveillance, social scoring, automated employment decision-making, procurement qualification, finance qualification, insurance qualification, public authority action, consent, deployment authorization, or execution by implication.

<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/xv.-competence.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.