# XIV. PEOPLE

This section defines people in Nexus as governed participants, work units, and role-bearing pathways for public-good contribution.

It explains how contributors, teams, guilds, councils, rooms, records, and participation structures organize capability, review, learning, support, and handoff context across Nexus. It also sets the core boundary rule: participation and work-unit status may create records, scope, safeguards, recognition, and routing context, but they do not become employment, certification, procurement, finance, insurance, public authority action, consent, deployment authorization, or execution by implication.

## 14.1 Nexus Work Unit Taxonomy

### 14.1.1 Individual Contributors

Individual Contributors are persons who contribute work, knowledge, review, research, software, data, documentation, translation, learning, public-safe reporting, Campaign activity, Studio support, DRI support, Observatory support, Academy participation, Foundry builds, Labs research, safeguard review, or other bounded contribution to Nexus Ecosystem without becoming institutional authorities by virtue of contribution.

Individual Contributors may include researchers, engineers, data scientists, AI practitioners, cyber specialists, geospatial specialists, policy professionals, legal contributors, public authority learners, community participants, Indigenous knowledge holders where applicable, students, youth participants, volunteers, fellows, maintainers, reviewers, translators, designers, writers, domain experts, media-safe communicators, risk experts, finance-readiness contributors, insurance-readiness contributors, and public-interest contributors.

An Individual Contributor Record should identify:

1. contributor identity and role, subject to privacy, safety, youth, community, protected knowledge, and participation controls;
2. contribution pathway, including Foundry, Academy, Campaigns, Reports, Studio, Labs, Observatory, DRI, GRIx, Grid, Registry, Marketplace, National Portfolio, Nexus Universe, Competence Cell, Working Group, secure room, data room, public authority learning room, readiness room, or handoff-dependency pathway;
3. contribution class, including research, review, software, data, AI, cyber, geospatial, public-safe communication, learning, translation, accessibility, safeguard, community, policy, legal, finance-readiness, insurance-readiness, donor-readiness, or operational-support-without-execution contribution;
4. permission and access class, including open contributor, controlled contributor, room-bound contributor, National Node contributor, protected knowledge-controlled contributor, youth contributor, public authority learner, or handoff-context contributor;
5. proof and recognition records, including contribution record, review record, learning record, proof receipt, iCRS record where applicable, support record, correction record, and archive status;
6. boundary notices, confirming that contribution does not create authority, employment, agency, certification power, public authority status, procurement status, finance authority, insurance authority, consent authority, deployment authority, or execution authority by implication.

Individual Contributors are essential to distributed public-good production. Their contributions must be recorded, credited where appropriate, protected where required, reviewed where necessary, and corrected where needed. Contribution is participation in a governed pathway, not an unrestricted power to speak for Nexus or act on behalf of any Nexus institution.

### 14.1.2 Teams

Teams are small groups formed to complete a defined Nexus work object, review object, learning object, campaign object, report object, Studio object, data object, software object, evidence object, safeguard object, National Portfolio object, Nexus Universe output, or handoff-dependency object. A Team is a bounded work unit, not a governing body by default.

A Team may be formed within Nexus Foundry, Nexus Academy, Risk Academy, Nexus Campaigns, Nexus Reports, Nexus Studio, Nexus Observatory, Nexus Grid, Nexus Registry, Nexus Marketplace, Nexus Universe, Nexus Labs, National Working Groups, Competence Cells, public authority learning rooms, readiness rooms, secure rooms, data rooms, or other recorded Nexus pathways.

A Team Record should identify:

1. team purpose, including the object, Docket, program, track, quest, bounty, build, review, report, campaign, learning pathway, Studio workflow, Observatory output, DRI record, Registry record, Marketplace listing, Grid input, National Portfolio object, Nexus Universe output, or handoff dependency being addressed;
2. team members and roles, including contributor, maintainer, reviewer, steward, facilitator, editor, technical lead, data lead, AI lead, cyber lead, safeguard lead, public-safe reviewer, public authority boundary reviewer, finance-readiness reviewer, or archive steward;
3. scope and deliverables, including draft, evidence pack, software object, dataset, dashboard, report, module, campaign object, review note, public-safe output, readiness question, handoff dependency record, correction record, or archive object;
4. access and room controls, including open, controlled, restricted, secure room, data room, clean room, protected knowledge room, public authority learning room, readiness room, or handoff room status;
5. review and approval pathway, including human review, public-safe review, data review, AI review, cyber review, safeguard review, public authority boundary review, finance and insurance boundary review, Registry review, Marketplace review, Grid review, or handoff review;
6. boundary status, confirming that Team formation does not create legal authority, public authority action, procurement authority, finance authority, insurance authority, donor commitment, consent authority, deployment authority, or execution authority by implication.

Teams create coordination for bounded work. They do not create institutional mandate beyond their recorded scope. A Team may recommend, draft, build, review, or prepare; it does not certify, approve, procure, finance, insure, consent, deploy, or execute unless a separate competent actor lawfully acts through its own process.

### 14.1.3 Squads

Squads are focused, time-bounded, cross-functional Nexus work units formed to deliver a specific build, sprint, review, response, correction, public-safe release, Studio workflow, Campaign activation, Nexus Universe output, Registry correction, Marketplace correction, Grid input, National Portfolio update, or handoff-dependency package. Squads are used where speed and coordination are needed, but all Nexus boundaries continue to apply.

A Squad may combine technical contributors, data reviewers, AI reviewers, cyber reviewers, designers, writers, public-safe reviewers, safeguard reviewers, policy and legal reviewers, Academy contributors, Campaign contributors, Studio facilitators, National Node representatives, Working Group members, Competence Cell members, and room stewards.

A Squad Record should identify:

1. squad trigger, including Docket priority, Core Build Request, Campaign signal, Nexus Universe need, public-safe release need, correction need, incident response need, Studio demonstration need, Registry or Marketplace need, Grid review need, or handoff-dependency need;
2. sprint or work period, including start, end, milestones, review gates, release conditions, correction checkpoints, and archive conditions;
3. object scope, including software, data, AI, Report, Campaign, Academy module, Studio workflow, dashboard, DRI indicator, Observatory output, National Portfolio object, Nexus Universe output, correction object, or handoff dependency;
4. cross-functional roles, including product steward, method steward, data steward, AI steward, cyber steward, public-safe reviewer, safeguard reviewer, accessibility reviewer, documentation lead, maintainer, and archive steward;
5. stop-the-line conditions, including unresolved safeguards, data rights issues, public authority overclaim, finance or insurance overclaim, cyber issue, protected knowledge exposure, AI incident, unsupported claim, or handoff overclaim;
6. output status, including draft, review-ready, public-safe candidate, controlled release, Registry candidate, Marketplace candidate, Studio-ready, Grid input, Nexus Universe-ready, corrected, withdrawn, recalled, archived, or non-continuing.

Squads may work quickly, but speed does not relax governance. A Squad’s output remains subject to review, status truth, correctionability, public-good firewall, and no-conversion discipline.

### 14.1.4 Guilds

Guilds are standing or semi-standing communities of practice that develop methods, skills, review standards, templates, learning pathways, tooling, public-good baselines, ontology patterns, software practices, data practices, AI practices, cyber practices, geospatial practices, public-safe reporting practices, safeguard practices, and handoff-dependency practices across Nexus Ecosystem.

Guilds differ from Teams and Squads because their primary function is capability, coherence, practice quality, and cross-portfolio learning rather than delivery of one object. A Guild may support many Teams, Squads, Working Groups, Competence Cells, Foundry programs, Academy pathways, Reports, Studio workflows, Campaigns, National Portfolios, Nexus Universe outputs, and handoff pathways.

A Guild Record should identify:

1. guild domain, including data, AI, cyber, geospatial, DRI, GRIx, Observatory, Studio, Reports, public-safe communication, legal and boundary discipline, safeguards, accessibility, software, open technical baselines, Academy, Campaigns, finance-readiness literacy, insurance-readiness literacy, or handoff dependencies;
2. practice outputs, including templates, methods, playbooks, checklists, schemas, code patterns, review rubrics, learning modules, public-safe language, correction patterns, Registry patterns, Marketplace listing standards, Grid input guidance, and handoff dependency patterns;
3. membership and participation, including experts, contributors, maintainers, reviewers, National Node participants, university or lab participants, public authority learners where appropriate, community participants, and professional contributors;
4. quality controls, including review cadence, method review, versioning, public-safe review, safeguard review, correction records, archive records, and non-continuation rules;
5. cross-portfolio support, including Global, Regional, National, Thematic, Sector, Technology, Campaign, Foundry, Reports, DRR, DRF, DRI, Innovation, Handoff-Dependency, Correction, and Archive Portfolios;
6. boundary controls, confirming that Guild guidance is not certification, regulation, procurement rule, finance advice, insurance advice, public authority action, consent, deployment authorization, or execution authority unless separately adopted by a competent actor.

Guilds strengthen consistency without becoming hidden governance bodies. Their authority is methodological and record-based within Nexus, not external or coercive by default.

### 14.1.5 National Working Groups

National Working Groups are country-level Nexus work units formed under the relevant national pathway to examine, prepare, review, draft, build, translate, localize, safeguard, and route National Portfolio objects, National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, Reports, Campaigns, Academy pathways, Studio workflows, DRI indicators, GRIx localization, Nexus Universe priorities, Grid inputs, and handoff-dependency records.

A National Working Group should be nationally owned, context-aware, and role-separated. It should not operate as a public authority, procurement body, finance body, insurer, donor allocation body, certification body, standards authority, community consent body, National Consortium Company, Project SPV, or execution vehicle by default.

A National Working Group Record should identify:

1. formation basis, including National Nexus Consortium, National Node, National Council, Helix Council, National Leadership Council, National Investors Council, Steering or Stewardship Board pathway where applicable, or Nexus Universe preparation pathway;
2. working group scope, including hazard class, WFEH-B system, technology domain, public-good software, DRI, Observatory, Academy, Campaign, Reports, Studio, Grid, public authority learning, finance-readiness, insurance-readiness, safeguard, or handoff dependency;
3. participants, including public authorities in learning mode, universities, research bodies, industry actors, capital readers, insurers, donors, civil society, communities, Indigenous institutions where applicable, youth, media, professional bodies, providers, sponsors, and public-interest actors, each under recorded role boundaries;
4. outputs, including workplans, evidence needs, Observatory needs, Reports, Studio scenarios, Campaign objects, Academy pathways, National Portfolio inputs, Nexus Universe routing records, readiness questions, safeguard records, handoff dependency records, correction records, and archive records;
5. national safeguards, including language, accessibility, data sovereignty, localization, community safeguards, Indigenous protocols where applicable, protected knowledge, privacy, cyber, public authority boundaries, finance and insurance boundaries, and procurement neutrality;
6. boundary status, confirming no public authority action, procurement, finance, insurance, certification, consent, deployment, or execution by implication.

National Working Groups are the country-level work formation engine. Their work produces records and capability, not automatic decisions.

### 14.1.6 Competence Cells

Competence Cells are specialized Nexus work units formed to concentrate expertise, review capacity, build capacity, and safeguard capacity around defined technical, data, risk, public-safe, Studio, Foundry, Academy, Campaign, or handoff domains. They may operate nationally, regionally, thematically, sectorally, or within Nexus Universe and Nexus Foundry pathways, subject to recorded scope and authority boundaries.

Competence Cells may include Data Cells, AI Cells, Cyber Cells, Geospatial and Observatory Cells, WFEH-B Cells, DRR / DRF / DRI Cells, Public-Safe Reporting Cells, Studio Cells, Foundry Build Cells, Handoff Dependency Cells, Accessibility Cells, Legal and Boundary Cells, Protected Knowledge Cells, Community Safeguard Cells, Academy Cells, Campaign Cells, and Registry / Marketplace / Grid Cells.

A Competence Cell Record should identify:

1. cell identity and domain, including specialized competence, object classes, portfolios served, and national or regional relationship;
2. cell mandate, including review, build, evidence preparation, data governance, AI governance, cyber review, geospatial review, public-safe transformation, Studio support, Academy support, Campaign support, Registry support, Marketplace support, Grid input preparation, Nexus Universe support, or handoff-dependency preparation;
3. competence requirements, including expertise, training, access level, confidentiality, public-safe literacy, safeguard literacy, correctionability literacy, and role-boundary literacy;
4. work products, including review notes, datasets, code, models, dashboards, reports, templates, playbooks, Studio workflows, Academy modules, Campaign objects, Registry drafts, Marketplace drafts, Grid inputs, handoff dependency records, correction records, and archive objects;
5. quality and safeguard controls, including peer review, method review, data review, AI review, cyber review, public-safe review, community review, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, and correction review;
6. boundary notices, confirming that cell expertise does not create certification, professional licensing, public authority decision, procurement recommendation, finance advice, insurance advice, consent, deployment authorization, or execution authority by default.

Competence Cells give Nexus depth. They must remain bounded by record, pathway, review, and correction discipline.

### 14.1.7 Foundry Build Teams

Foundry Build Teams are Nexus Foundry and BuildGrid work units that convert Dockets, National Challenge Briefs, Core Build Requests, Labs research signals, Campaign signals, Nexus Universe priorities, Observatory needs, DRI needs, Academy needs, Reports needs, Studio needs, Registry needs, Marketplace needs, Grid needs, and handoff-dependency needs into governed public-good build outputs.

A Foundry Build Team may produce software, data pipelines, AI workflows, dashboards, APIs, schemas, ontologies, public-safe reporting tools, Campaign tools, Academy modules, Studio workflows, DRI tools, Observatory components, open technical baselines, reference implementations, test suites, templates, Registry objects, Marketplace objects, Grid inputs, Nexus Universe build outputs, and handoff-context packages.

A Foundry Build Team Record should identify:

1. program, track, quest, bounty, or build assignment;
2. build object identity, including object class, purpose, version, steward, source Docket, National Portfolio relationship, Nexus Universe relationship, and expected Registry or Marketplace relationship;
3. team roles, including product steward, technical lead, maintainer, developer, data steward, AI reviewer, cyber reviewer, public-safe reviewer, documentation lead, accessibility reviewer, safeguard reviewer, and archive steward;
4. review gates, including code review, data review, AI review, security review, dependency review, accessibility review, documentation review, public-safe review, safeguard review, Registry review, Marketplace review, Grid review, and handoff review;
5. release controls, including release class, support class, license, contribution terms, SBOM, vulnerability disclosure, no-warranty notice, no-deployment notice, correction pathway, and archive rule;
6. handoff boundary, confirming that Foundry build completion is not production approval, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

Foundry Build Teams build public-good objects. They do not implement projects by default.

### 14.1.8 Campaign Teams

Campaign Teams are Nexus work units formed to design, operate, review, moderate, support, correct, and archive Nexus Campaigns. They may manage public-good mobilization, signatures, pledges, support, donations where lawful, volunteers, teams, chapters, ambassadors, quests, bounties, builds, public-safe storytelling, Campaign dashboards, learning conversion, Nexus Universe mobilization, National Portfolio support, and post-cycle continuation.

A Campaign Team must preserve campaign boundaries. Mobilization is not endorsement. Visibility is not approval. Support is not control. Donation interest is not allocation by default. Volunteer participation is not employment. Community participation is not consent. Public authority participation is not public authority action. Sponsor support is not sponsor control. Provider contribution is not provider validation.

A Campaign Team Record should identify:

1. campaign identity and class, including global, regional, national, thematic, sectoral, technology, community, youth, university, public authority learning, Nexus Universe, Foundry, Academy, Reports, DRR, DRF, DRI, or safeguard campaign;
2. team roles, including campaign steward, public-safe communications lead, trust and safety lead, moderation lead, volunteer lead, support ledger steward, sponsor-control reviewer, provider-claim reviewer, accessibility lead, community safeguard lead, youth safeguard lead, and archive steward;
3. campaign tools, including signature tools, pledge tools, support tools, donation tools where lawful, volunteer tools, team tools, chapter tools, ambassador tools, quest tools, bounty tools, dashboards, widgets, Reports, learning links, and Marketplace links;
4. claims controls, including no endorsement, no public authority action, no procurement, no finance, no insurance, no donor commitment, no consent, no deployment, no execution, no sponsor control, and no provider validation language;
5. trust and safety controls, including moderation, fraud prevention, privacy, youth protection, public-safe reporting, media-safe language, data-use labels, AI-use labels, correction, withdrawal, recall, and archive;
6. continuation pathway, including National Node continuation, Nexus Universe routing, Academy conversion, Foundry build conversion, Reports conversion, Marketplace discovery, Registry status, correction, archive, or non-continuation.

Campaign Teams turn mobilization into governed public-good records. They do not convert public support into authority.

### 14.1.9 Studio Rooms

Studio Rooms are controlled Nexus work units and runtime environments where participants examine dashboards, digital twins, simulations, AI workflows, data-room outputs, secure-room outputs, DRI indicators, Observatory signals, public authority learning materials, readiness records, National Portfolio objects, Nexus Universe materials, and handoff demonstrations under defined access, logging, output review, no-command, no-write-back, public-safe, and archive controls.

A Studio Room may be used for scenario learning, public authority learning, DRI review, Observatory review, digital twin review, dashboard review, AI workflow review, Readiness Room support, capital-reader learning, insurance-reader learning, donor-reader learning, public finance learning, Nexus Universe demonstrations, and handoff-context demonstrations.

A Studio Room Record should identify:

1. room purpose, including learning, scenario review, simulation, dashboard review, digital twin review, AI workflow review, public authority learning, readiness review, finance-readiness question formation, insurance-readiness question formation, donor-readiness question formation, Nexus Universe demonstration, or handoff-context demonstration;
2. room participants and roles, including facilitators, reviewers, public authority learners, National Node participants, Working Group members, Competence Cell members, capital readers, insurance readers, donors, community safeguard participants, Indigenous protocol participants where applicable, technical contributors, and lawful recipients;
3. objects shown or used, including datasets, dashboards, maps, models, digital twins, simulations, Reports, public-safe summaries, DRI records, Observatory outputs, Grid records, National Portfolio objects, Nexus Universe outputs, and handoff packages;
4. runtime controls, including access control, no-download, no-write-back, no-command, logging, human review, output review, public-safe transformation, AI-use limits, secure-room or data-room linkage, and kill-switch conditions;
5. outputs, including learning notes, questions, public-safe summaries, readiness notes, correction triggers, dependency notes, handoff-context notes, and archive records;
6. boundary status, confirming that Studio Room activity is not deployment, operational command, public authority action, procurement, finance, insurance, consent, or execution by implication.

Studio Rooms make complex systems learnable under control. They are not operational control rooms by default.

### 14.1.10 Academy Cohorts

Academy Cohorts are structured learning work units formed through Nexus Academy, Risk Academy, National Nodes, National Working Groups, Competence Cells, Campaigns, Nexus Universe, Foundry, Labs, public authority learning pathways, or partner learning pathways to develop role-bounded competence in Nexus concepts, data governance, AI governance, cyber resilience, DRI, GRIx, Observatory, Studio, Reports, public-safe communication, WFEH-B systems, DRR, DRF literacy, public authority learning, finance-readiness literacy, insurance-readiness literacy, safeguards, and lawful handoff.

An Academy Cohort may include students, youth, professionals, public authority learners, Working Group members, Competence Cell members, community participants, university participants, provider participants, sponsor participants, capital readers, insurers, donors, media actors, public-interest actors, and other learners. Cohort participation must be recorded without credential overclaim.

An Academy Cohort Record should identify:

1. learning pathway, including Academy, Risk Academy, Foundry contributor learning, Studio learning, DRI learning, GRIx learning, Observatory learning, public-safe reporting learning, public authority learning, finance-readiness literacy, insurance-readiness literacy, safeguard learning, Campaign learning, or Nexus Universe preparation;
2. cohort members and learner classes, subject to privacy, youth protection, accessibility, and participation safeguards;
3. learning objects, including modules, readings, Reports, dashboards, Studio exercises, simulations, public-safe summaries, case studies, templates, quizzes, projects, contribution tasks, and reflection records;
4. learning records, including participation record, completion record, proof receipt, micro-credential input where applicable, contribution record, review record, correction record, and archive status;
5. accessibility and safeguard controls, including language, low-bandwidth access, disability access, youth safeguards, community safeguards, protected knowledge limits, Indigenous protocol controls where applicable, public-safe language, and AI-use limits;
6. credential boundary, confirming that cohort completion is not professional licensure, certification, public authority qualification, procurement qualification, finance qualification, insurance qualification, deployment authority, or execution authority unless separately issued by a competent body.

Academy Cohorts convert knowledge into capability. They do not convert learning into authority by default.

### 14.1.11 Labs Streams

Labs Streams are research, exploration, testbed, method-development, prototype, evaluation, experiment, scientific, technical, policy, legal, social science, governance, data, AI, cyber, geospatial, WFEH-B, Observatory, Studio, or public-good software work units operating through Nexus Labs or aligned research pathways.

Labs Streams are used where Nexus needs to investigate frontier questions before Foundry build, Reports publication, Academy conversion, Studio demonstration, Grid input, Nexus Universe presentation, National Portfolio inclusion, or handoff-context preparation. A Labs Stream should preserve the boundary between research promise and validated output.

A Labs Stream Record should identify:

1. research stream identity, including topic, steward, institution, lab, university, Working Group, Competence Cell, partner, or Nexus Labs relationship;
2. research question, including scientific, technical, data, AI, cyber, policy, legal, social, institutional, risk, WFEH-B, DRI, Observatory, Studio, finance-readiness, insurance-readiness, safeguard, or handoff question;
3. research objects, including datasets, methods, models, benchmarks, prototypes, testbeds, papers, code, dashboards, simulations, digital twins, interview records, public-safe summaries, and Reports inputs;
4. review and ethics controls, including data-use labels, AI-use labels, research ethics where applicable, public-safe review, privacy, cyber, geospatial sensitivity, protected knowledge, Indigenous protocols where applicable, community safeguards, rights and IP, and publication limits;
5. translation pathway, including Labs-to-Foundry, Labs-to-Reports, Labs-to-Academy, Labs-to-Studio, Labs-to-Grid, Labs-to-Nexus Universe, Labs-to-National Portfolio, Labs-to-Handoff Context, correction, archive, or non-continuation;
6. boundary status, confirming that Labs Stream output is not validation, certification, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

Labs Streams create frontier learning. They must be recorded before being translated into public-good production.

### 14.1.12 Risk Agency Expert Panels

Risk Agency Expert Panels are curated expert work units that provide bounded expert review, advisory support, cross-sphere translation, public-safe reporting support, capacity-building support, readiness-question support, handoff-dependency support, and domain interpretation within Nexus pathways. They may support Reports, DRI, Observatory, Studio, Academy, Campaigns, National Portfolios, Nexus Universe, Grid, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public authority learning rooms, and lawful handoff-preparation pathways.

A Risk Agency Expert Panel may include experts in disaster risk, climate, water, food, energy, health, biodiversity, cyber, AI, telecom, infrastructure, finance-readiness, insurance-readiness, public finance learning, law, public policy, safeguards, Indigenous protocols where applicable, community engagement, media-safe communication, geospatial systems, Earth observation, digital twins, and other Nexus domains.

A Risk Agency Expert Panel Record should identify:

1. panel scope, including domain, portfolio, Docket, Report, Studio workflow, National Portfolio, Nexus Universe priority, readiness question, safeguard issue, or handoff dependency;
2. expert roles, including technical reviewer, method reviewer, data reviewer, public-safe reviewer, safeguard reviewer, public authority boundary reviewer, finance-readiness reviewer, insurance-readiness reviewer, community reviewer, or translation reviewer;
3. materials reviewed, including Reports, datasets, DRI indicators, Observatory outputs, Studio workflows, Grid inputs, National Portfolio records, Nexus Universe outputs, Campaign materials, Academy materials, or handoff packages;
4. outputs, including expert notes, review records, questions, limitation statements, correction triggers, public-safe recommendations, readiness questions, dependency notes, and archive records;
5. conflict and independence controls, including disclosure, anti-capture, no provider validation, no sponsor control, no procurement preference, no finance advice, no insurance advice, and no hidden agency;
6. advisory boundary, confirming that expert panel input is advisory, review-supporting, and non-executing unless a separate competent actor lawfully adopts its own decision.

Risk Agency Expert Panels improve interpretation. They do not create certification, public authority action, procurement, finance, insurance, consent, deployment, or execution by default.

### 14.1.13 Public Authority Learning Rooms

Public Authority Learning Rooms are controlled Nexus work units where public authorities and public-sector actors may examine evidence, DRI indicators, Observatory outputs, Studio scenarios, Reports, dashboards, National Portfolio objects, Nexus Universe outputs, public-safe summaries, Grid and TRL context, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance learning materials, safeguard records, and handoff dependencies in learning mode.

A Public Authority Learning Room must be carefully recorded because public-sector presence can be misread as approval. The room exists to support learning, questions, context, capacity, and lawful pathway awareness. It does not create public authority decision, public warning, emergency command, regulatory action, permit, license, compliance finding, procurement decision, public finance allocation, policy adoption, endorsement, deployment authorization, or execution.

A Public Authority Learning Room Record should identify:

1. room purpose, including risk intelligence learning, data governance learning, AI governance learning, cyber resilience learning, public-safe reporting learning, WFEH-B learning, procurement-boundary learning, public finance learning, regulatory-learning context, emergency-language discipline, Nexus Universe preparation, or handoff dependency review;
2. public authority participant class, including ministry, agency, regulator, municipality, public utility, emergency body, public finance actor, public service institution, or public-sector learner;
3. materials reviewed, including object identifiers, versions, Registry status, public-safe status, correction status, access class, and boundary language;
4. outputs, including learning notes, questions, non-decision observations, evidence needs, public-safe language notes, safeguard issues, readiness questions, handoff dependency notes, correction triggers, and archive records;
5. boundary controls, including learning-only, non-decision, non-warning, non-command, non-regulatory, non-procurement, non-public-finance, non-policy, non-endorsement, non-deployment, and non-execution notices;
6. correction pathway, including correction of public authority overclaim, public-safe language, dashboard interpretation, Report language, Marketplace wording, Registry wording, handoff context, and public repair where required.

Public Authority Learning Rooms allow public institutions to learn without being misrepresented and allow Nexus to support public-good capacity without substituting for the state.

### 14.1.14 Readiness Rooms

Readiness Rooms are controlled Nexus work units where portfolio objects, Dockets, Reports, Studio workflows, software objects, data objects, AI objects, dashboards, Campaigns, Academy objects, National Portfolio objects, Nexus Universe outputs, Grid and TRL records, Marketplace candidates, Registry records, and handoff-dependency packages are examined for pathway-specific readiness.

A Readiness Room should ask a bounded question: ready for what, under whose pathway, with what records, with what safeguards, with what limits, with what correction pathway, and with what no-conversion notices. Readiness for one pathway is not readiness for all pathways.

A Readiness Room Record should identify:

1. readiness question, including Reports readiness, public-safe readiness, Studio readiness, Academy readiness, Campaign readiness, Registry readiness, Marketplace readiness, Grid readiness, TRL context, Nexus Universe readiness, National Portfolio readiness, finance-readiness question readiness, insurance-readiness question readiness, public authority learning readiness, or handoff-context readiness;
2. object under review, including identity, version, steward, portfolio relationship, Docket relationship, lifecycle state, Registry status, and correction status;
3. evidence required, including source records, method records, data-use labels, AI-use labels, security reviews, public-safe reviews, safeguard records, support records, confidence labels, uncertainty labels, and boundary notices;
4. participants and reviewers, including technical reviewers, data reviewers, AI reviewers, cyber reviewers, public-safe reviewers, safeguard reviewers, public authority boundary reviewers, finance and insurance boundary reviewers, National Node representatives, and archive stewards;
5. outcome class, including ready within scope, ready with conditions, returned for revision, restricted, suspended, withdrawn, recalled, archived, non-continuing, or referred to separate competent actor;
6. boundary controls, confirming that readiness-room outcome is not certification, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

Readiness Rooms route objects responsibly. They do not approve external action.

### 14.1.15 Secure Rooms and Data Rooms

Secure Rooms and Data Rooms are controlled Nexus work units used where sensitive data, restricted records, protected knowledge, public authority-sensitive materials, cyber-sensitive materials, infrastructure-sensitive materials, geospatial-sensitive materials, health-sensitive materials, youth data, finance-sensitive materials, insurance-sensitive materials, handoff-recipient-only materials, or non-public Nexus objects require controlled access, logging, review, output control, correction, and archive.

A Secure Room emphasizes controlled processing, sensitive review, runtime restrictions, no-download controls, compute-to-data, secure-room AI where permitted, and output review. A Data Room emphasizes controlled access to structured materials, evidence packs, Records, Reports, diligence-context materials, public authority learning materials, capital-reader materials, insurance-reader materials, donor-reader materials, public finance learning materials, and handoff-context materials. Both are access-control structures, not authority structures.

A Secure Room or Data Room Record should identify:

1. room type and purpose, including secure review, data review, clean-room workflow, compute-to-data workflow, protected knowledge review, public authority learning, readiness review, capital-reader review, insurance-reader review, donor-reader review, public finance learning, Studio review, Nexus Universe review, or handoff-context review;
2. materials included, including datasets, documents, reports, dashboards, logs, models, software, AI outputs, maps, Studio workflows, DRI records, Observatory outputs, Grid records, National Portfolio objects, Nexus Universe outputs, or handoff packages;
3. access roles, including steward, reviewer, viewer, contributor, public authority learner, capital reader, insurance reader, donor reader, National Node participant, community safeguard participant, Indigenous protocol participant where applicable, lawful recipient, or archive custodian;
4. controls, including least privilege, logging, no-download, no-copy, watermarking where appropriate, access expiry, output review, data-use labels, AI-use labels, secure-room AI restrictions, cross-border restrictions, retention, deletion, sealing, correction, recall, and archive;
5. outputs, including questions, comments, review notes, public-safe summaries, readiness notes, dependency notes, handoff notes, correction records, and room archive records;
6. boundary notices, confirming that room access is not ownership, unrestricted reuse, AI-use permission, publication permission, procurement permission, finance permission, insurance permission, public authority action, consent, deployment authorization, handoff permission, or execution authority unless separately and lawfully recorded.

Secure Rooms and Data Rooms allow sensitive work to proceed safely. They do not convert access into action.

The final Nexus Work Unit Taxonomy rule is: Individual Contributors, Teams, Squads, Guilds, National Working Groups, Competence Cells, Foundry Build Teams, Campaign Teams, Studio Rooms, Academy Cohorts, Labs Streams, Risk Agency Expert Panels, Public Authority Learning Rooms, Readiness Rooms, and Secure Rooms or Data Rooms are work units for contribution, learning, review, production, mobilization, controlled access, and readiness routing. Work-unit status creates scope, records, roles, safeguards, and correction pathways; it never creates certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 14.2 Whole-of-Society Participation Architecture

### 14.2.1 Public Authorities

Public Authorities participate in Nexus as public-sector learners, observers, contributors of context, public-good capacity participants, public finance learners, regulatory-context participants, emergency-language reviewers, infrastructure-context actors, and lawful recipients where separately recorded. Their participation is essential because disaster risk, systems risk, WFEH-B resilience, frontier technology governance, public-safe reporting, data sovereignty, public finance, procurement boundaries, and lawful implementation pathways often depend on public authority context.

Public Authority participation should be structured through Public Authority Learning Rooms, National Councils, Government / Public Authority Helix Councils, National Working Groups, Nexus Universe rooms, Studio Rooms, Reports review pathways, DRI and Observatory review pathways, public-safe reporting pathways, Academy learning pathways, and lawful handoff-dependency pathways. Public Authorities may ask questions, review evidence, clarify public-sector constraints, identify data gaps, identify public-safe language needs, identify public finance learning needs, and identify lawful public authority processes that would be required outside Nexus.

A Public Authority Participation Record should identify:

1. public authority role, including learner, observer, data steward, context contributor, public finance reader, regulator in learning mode, municipality, utility, emergency actor, public service institution, or separate lawful recipient;
2. participation pathway, including National Council, Helix Council, Working Group, Learning Room, Studio Room, Readiness Room, Nexus Universe room, DRI review, Observatory review, Reports review, Academy pathway, or handoff-dependency pathway;
3. materials reviewed or contributed, including Reports, dashboards, DRI records, Observatory signals, Studio workflows, National Portfolio objects, Grid or TRL records, public-safe summaries, safeguard records, and handoff dependency records;
4. boundary status, including learning-only, non-decision, non-warning, non-command, non-regulatory, non-procurement, non-public-finance, non-policy, non-endorsement, non-deployment, and non-execution status;
5. correction pathway, including correction of public authority overclaim, official-status confusion, public-safe language, dashboard interpretation, Report language, Marketplace wording, Registry wording, Nexus Universe materials, and handoff context.

Public Authority participation does not create public authority action by implication. Nexus may support learning and capacity, but any public authority decision, warning, approval, permit, license, procurement, public finance allocation, policy adoption, emergency command, regulatory act, or implementation authorization must be separately made by the competent public authority through its own lawful process.

### 14.2.2 Universities and Research Bodies

Universities and Research Bodies participate as research contributors, methods stewards, evidence reviewers, Labs participants, Academy partners, student and youth capability partners, DRI contributors, Observatory contributors, Studio participants, Reports contributors, peer review participants, public-good software contributors, data governance contributors, AI and cyber research contributors, geospatial and Earth observation contributors, WFEH-B research contributors, and lawful handoff recipients where separately appropriate.

University and research participation should strengthen scientific quality, methodological rigor, reproducibility, evidence discipline, education, talent formation, open technical baselines, and public-good research translation. It should not convert Nexus into a university program, academic credentialing body, research ethics board by implication, public authority substitute, procurement channel, vendor validation pathway, or commercial technology transfer vehicle by default.

A University and Research Body Participation Record should identify:

1. institutional role, including researcher, lab, institute, faculty group, student cohort, reviewer, method steward, data steward, technical contributor, Academy partner, Reports contributor, Labs stream participant, or lawful recipient;
2. research object, including dataset, method, model, benchmark, software prototype, report, technical paper, dashboard, simulation, digital twin, AI workflow, public-safe summary, or open technical baseline;
3. translation pathway, including Labs-to-Foundry, Labs-to-Reports, Labs-to-Academy, Labs-to-Studio, Labs-to-Grid, Labs-to-Nexus Universe, Labs-to-National Portfolio, or Labs-to-Handoff Context;
4. rights and safeguards, including intellectual property, license, data-use labels, AI-use labels, ethics requirements where applicable, privacy, cyber, protected knowledge, Indigenous protocol controls where applicable, community safeguards, publication restrictions, and archive rules;
5. boundary controls, including research-not-validation, prototype-not-production, peer review-not-certification, academic participation-not-public-authority-action, university contribution-not-provider-validation, and research output-not-deployment-authorization.

Universities and research bodies help Nexus learn and build responsibly. Their participation does not create certification, procurement readiness, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

### 14.2.3 Industry and Enterprise Actors

Industry and Enterprise Actors participate as sector experts, operators, providers, infrastructure owners, technology contributors, data contributors where lawful, implementation-context contributors, public-good software contributors, standards-interface participants, National Council participants, Helix Council participants, Working Group participants, Studio participants, Nexus Universe participants, and lawful handoff recipients where separately recorded.

Industry and enterprise participation is important because many risks are embedded in real systems: telecom networks, AI-RAN/O-RAN/private wireless systems, energy systems, water systems, food systems, health infrastructure, cyber systems, cloud and compute systems, logistics, ports, manufacturing, finance infrastructure, geospatial systems, data platforms, and critical supply chains. Enterprise actors may help identify implementation realities, technical dependencies, operational constraints, maintenance issues, cyber risks, data limits, supply-chain dependencies, workforce needs, and handoff conditions.

An Industry and Enterprise Participation Record should identify:

1. enterprise role, including sector participant, operator, provider, technology contributor, data contributor, host, sponsor, contractor, manufacturer, infrastructure actor, platform actor, National Council participant, Working Group participant, Studio participant, or lawful recipient;
2. participation purpose, including evidence contribution, technical review, operational-context review, public-good software contribution, DRI contribution, Observatory contribution, Studio demonstration, Nexus Universe participation, Academy support, Campaign support, or handoff-dependency clarification;
3. conflict and anti-capture controls, including disclosure, no provider validation, no sponsor control, no procurement preference, no pay-to-influence, no pay-to-routing, no exclusive advantage, no hidden endorsement, and no Marketplace distortion;
4. data and IP controls, including confidentiality, data-use labels, AI-use labels, proprietary information limits, public-safe transformation, secure-room use, handoff-recipient-only controls, and correction obligations;
5. boundary status, confirming that enterprise participation is not certification, procurement award, vendor approval, finance approval, insurance approval, public authority action, consent, deployment authorization, or execution by implication.

Industry and enterprise actors may later act in the enterprise stack through separate lawful vehicles, contracts, procurement, finance, insurance, permits, public authority approvals, consent processes, and implementation responsibilities. Participation in Nexus’s public-good stack does not itself create those rights or responsibilities.

### 14.2.4 Capital, Insurance, Donor, and Public Finance Readers

Capital, Insurance, Donor, and Public Finance Readers participate as readers, learners, question-formers, diligence-gap observers, dependency reviewers, finance-readiness literacy participants, insurance-readiness literacy participants, donor-readiness participants, public finance learning participants, and lawful recipients of context where separately recorded. Their role is to improve capital-readability and risk-to-resource understanding without converting Nexus into a finance, insurance, donor allocation, public finance, or transaction platform.

These actors may participate through National Investors Councils, Capital / Insurance / Donor / Development Helix Councils, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, Nexus Universe rooms, Studio Rooms, Reports pathways, National Portfolio review, DRI and Observatory review, Grid context review, and handoff-dependency pathways.

A Capital, Insurance, Donor, and Public Finance Reader Participation Record should identify:

1. reader class, including investor, lender, development finance reader, insurer, reinsurer, broker where appropriate, donor, foundation, philanthropic actor, public finance reader, public-good supporter, or CSR actor where appropriate;
2. review purpose, including finance-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, protection-gap questions, risk-layering questions, assumptions review, dependency review, diligence-gap review, or handoff-context review;
3. materials reviewed, including Reports, DRI records, Observatory outputs, Studio scenarios, National Portfolio objects, Nexus Universe outputs, Grid or TRL context, safeguard records, assumptions registers, dependency registers, and handoff dependency records;
4. regulated-perimeter controls, including no investment advice, no solicitation, no securities offering, no valuation, no rating, no lending decision, no underwriting, no coverage commitment, no premium indication, no donor commitment, no public finance allocation, no guarantee, no transaction execution, and no reliance;
5. correction pathway, including correction of finance, insurance, donor, public finance, procurement, reliance, or handoff overclaims.

Reader participation improves questions and legibility. It does not create financeability, insurability, donor commitment, public finance allocation, procurement readiness, investment approval, underwriting, rating, guarantee, or execution.

### 14.2.5 Civil Society and Public-Interest Actors

Civil Society and Public-Interest Actors participate as legitimacy, accountability, public-interest, safeguard, accessibility, community, rights, environmental, humanitarian, youth, media-safe, and public-safe reporting contributors. They may include NGOs, public-interest organizations, rights organizations, environmental organizations, accessibility advocates, civic groups, humanitarian organizations, community organizations, youth organizations, watchdog groups, professional associations, and public-interest researchers.

Civil society participation helps Nexus avoid technocratic isolation, sponsor capture, provider capture, public authority overclaim, finance overclaim, community extraction, protected knowledge misuse, inaccessible outputs, and public-safe communication failures. Civil society actors may contribute lived context, rights concerns, public-interest priorities, safeguard review, accessibility review, public-safe language, Campaign participation, Reports review, Academy pathways, National Portfolio work, Nexus Universe participation, and correction triggers.

A Civil Society and Public-Interest Participation Record should identify:

1. actor class, including NGO, civic group, public-interest organization, accessibility advocate, rights advocate, environmental group, humanitarian organization, youth organization, community organization, or public-interest researcher;
2. participation pathway, including Helix Council, Working Group, Campaign, Reports review, Academy pathway, Studio Room, public-safe review, safeguard review, Nexus Universe room, National Portfolio pathway, or correction pathway;
3. contribution type, including safeguard input, public-safe reporting input, accessibility input, community context, accountability concern, rights concern, environmental concern, Campaign mobilization, learning support, correction request, or handoff-dependency concern;
4. protection controls, including privacy, safety, anti-retaliation where appropriate, community-sensitive handling, protected knowledge controls, public-safe summary rules, and attribution preferences;
5. boundary status, confirming that civil society participation is not consent, public authority action, procurement decision, finance approval, insurance approval, certification, deployment authorization, or execution by implication.

Civil society participation is not symbolic presence. It is part of Nexus legitimacy architecture. It must be structured, recorded, protected, and capable of triggering correction.

### 14.2.6 Communities

Communities participate as holders of lived-risk knowledge, local context, vulnerability information, resilience priorities, cultural context, accessibility needs, public-safe reporting concerns, local systems knowledge, safeguard concerns, Campaign participation, Academy participation, National Portfolio input, Nexus Universe participation, and handoff-dependency context. Community participation must be non-extractive, dignity-preserving, language-aware, accessibility-aware, rights-aware, and consent-boundary-aware.

Community participation should occur through community safeguard rooms, National Councils, Community / Indigenous / Diaspora / Place-Based Legitimacy Helix Councils, National Working Groups, Campaigns, Academy pathways, Reports review, Studio Rooms, public-safe review, National Portfolio pathways, Nexus Universe rooms, and correction pathways. Participation must not be treated as consent, waiver, endorsement, approval, data-use permission, AI-use permission, land access permission, implementation approval, or deployment authorization unless separately and lawfully recorded.

A Community Participation Record should identify:

1. community context, including place, affected system, risk context, language, accessibility needs, vulnerability context, and participation pathway, subject to privacy and public-safe controls;
2. contribution type, including lived-risk knowledge, local context, safeguard concern, public-safe reporting input, Campaign participation, Academy participation, Studio review, National Portfolio input, Nexus Universe input, or correction request;
3. consent boundary, including what participation does and does not authorize, what data or knowledge may be used, what may not be published, what may not be AI-processed, and what may not be handed off;
4. safeguard controls, including privacy, dignity, non-extraction, protected knowledge, geospatial masking, community review, language access, accessibility, youth safeguards where relevant, and public repair;
5. boundary status, confirming that community participation is not community consent, public authority action, procurement, finance, insurance, certification, deployment authorization, or execution.

Communities are not data sources to be mined. They are legitimacy-bearing participants whose knowledge and rights must be protected.

### 14.2.7 Indigenous Participants Where Applicable

Indigenous Participants Where Applicable may participate as Nations, governments, institutions, communities, knowledge holders, custodians, rights holders, researchers, youth, elders where appropriate, organizations, or representatives according to the applicable Indigenous governance, protocol, legal, cultural, and institutional context. Nexus must not collapse Indigenous participation into ordinary stakeholder engagement.

Where applicable, Indigenous participation may involve land, water, biodiversity, cultural heritage, language, traditional knowledge, ecological knowledge, data sovereignty, protected knowledge, community safeguards, public-safe reporting, geospatial controls, AI-use restrictions, protected knowledge rooms, National Portfolio inputs, Nexus Universe participation, Reports review, Academy pathways, Campaigns, Studio Rooms, and handoff dependencies.

An Indigenous Participation Record, where lawful and appropriate, should identify:

1. participation pathway, respecting the relevant Indigenous governance, protocol, custodian, community, or institutional process;
2. knowledge or data status, including Indigenous protocol-sensitive, protected knowledge, public-safe, controlled, restricted, metadata-only, secure-room, protected knowledge room, no-AI-use, or handoff-prohibited status;
3. permission and consent conditions, including what may be discussed, recorded, stored, translated, mapped, published, AI-processed, transferred, archived, returned, deleted, sealed, or handed off;
4. safeguard controls, including data sovereignty, geospatial masking, protected site controls, language controls, knowledge custodian review, public-safe transformation, community review, correction, withdrawal, deletion, sealing, return, archive, and public repair;
5. boundary status, confirming that participation is not rights waiver, knowledge release, consent, approval, public authority action, procurement, finance, insurance, deployment authorization, or execution by implication.

Public-good purpose does not override Indigenous governance, custodianship, consent, protected knowledge, or data sovereignty. Where uncertainty exists, the most protective treatment should apply until the proper governance pathway is recorded.

### 14.2.8 Youth and Students

Youth and Students participate as learners, contributors, Campaign participants, Academy cohort members, student researchers, youth ambassadors, public-interest participants, early-career builders, volunteers, Nexus Universe participants, Foundry contributors, and community-context contributors under heightened safeguarding, privacy, accessibility, and consent controls.

Youth and student participation helps build the next generation of risk, resilience, technology, public-good software, data governance, AI governance, cyber, public-safe reporting, WFEH-B, DRR, DRF literacy, and DRI capability. It must not expose youth to unsafe publicity, excessive data collection, inappropriate contact, exploitative labor, credential overclaim, public authority overclaim, or implementation responsibility.

A Youth and Student Participation Record should identify:

1. participant class, including minor youth, student, university student, early-career learner, youth organization participant, ambassador, volunteer, cohort member, or contributor, subject to privacy and lawful consent controls;
2. participation pathway, including Academy, Risk Academy, Campaign, Foundry, Labs, Nexus Universe, National Working Group, Competence Cell, Reports, Studio, public-safe review, or community pathway;
3. safeguards, including age-appropriate consent where required, guardian or institutional permission where applicable, privacy, safe communications, limited data collection, public display restrictions, youth data controls, moderation, accessibility, and escalation pathways;
4. learning and contribution records, including participation record, learning record, proof receipt, contribution record, micro-credential input where applicable, review record, correction record, and archive status;
5. boundary controls, including learning-not-licensure, participation-not-employment, contribution-not-authority, youth visibility-not-consent, and no procurement, finance, insurance, public authority action, deployment, or execution by implication.

Youth participation should be empowering, protected, educational, and correctionable. Recognition must be balanced against privacy and safety.

### 14.2.9 Media and Public Narrative Actors

Media and Public Narrative Actors participate as public-safe communication learners, narrative translators, public-interest storytellers, Reports amplifiers, Campaign amplifiers, Nexus Universe observers, public education participants, and public-safe reporting contributors under claims discipline and media-safe controls.

Media and narrative actors may help Nexus make complex risk, resilience, technology, WFEH-B, DRR, DRF, DRI, public-good software, community, and public authority learning issues understandable. They may also create risk if they overstate warnings, imply endorsement, simplify uncertainty, sensationalize risk, expose sensitive data, imply public authority action, imply financeability or insurability, or convert participation into public claims.

A Media and Public Narrative Participation Record should identify:

1. actor role, including journalist, editor, documentary actor, public communicator, civic media participant, Campaign storyteller, Reports communicator, Nexus Universe media participant, or public-safe reporting contributor;
2. materials accessible, including public Reports, public-safe summaries, Campaign materials, Registry public views, Marketplace public listings, Nexus Universe public materials, or controlled media-safe room materials;
3. claims controls, including non-warning, non-certification, non-procurement, non-finance, non-insurance, non-public-authority-action, non-consent, non-deployment, non-execution, no endorsement, no sponsor control, and no provider validation language;
4. sensitivity controls, including no disclosure of restricted data, protected knowledge, Indigenous protocol-sensitive information where applicable, youth data, health-sensitive data, cyber-sensitive details, infrastructure-sensitive details, geospatial-sensitive details, or handoff-recipient-only materials;
5. correction pathway, including media correction, public repair, clarification, withdrawal, recall, archive, and non-continuation.

Media participation can strengthen public understanding only if public-safe discipline travels with the story. Narrative must not outrun records.

### 14.2.10 Diaspora and Place-Based Actors

Diaspora and Place-Based Actors participate as bridge-builders, local-context contributors, national and regional connectors, community legitimacy contributors, Campaign participants, Academy participants, Nexus Universe participants, National Portfolio contributors, support contributors, and lawful handoff-context contributors where appropriate.

Diaspora actors may connect global expertise, capital-reader literacy, technical capability, university links, public-interest networks, and international experience to national and local priorities. Place-based actors may provide grounded knowledge, local legitimacy, accessibility context, community resilience needs, and implementation realities. Both must operate through national ownership, community safeguard, data protection, and consent-boundary discipline.

A Diaspora and Place-Based Participation Record should identify:

1. actor relationship, including diaspora community, local institution, local government learner, neighborhood group, regional association, professional network, place-based NGO, university link, or community network;
2. participation pathway, including National Council, Helix Council, Working Group, Campaign, Academy, Nexus Universe, National Portfolio, Reports, Studio, safeguard review, or handoff-dependency pathway;
3. contribution type, including local context, technical expertise, support interest, learning support, Campaign support, public-safe reporting, community safeguard input, translation, accessibility, or handoff dependency clarification;
4. boundary and safeguard controls, including national anti-bypass, community participation-not-consent, diaspora support-not-control, public authority learning-not-decision, finance-readiness-not-finance, protected knowledge controls, privacy, and public-safe review;
5. correction pathway, including correction of local-context errors, overclaim, consent confusion, public-safe failure, or handoff overclaim.

Diaspora and place-based participation should strengthen national ownership and local legitimacy, not bypass them.

### 14.2.11 Sponsors and Hosts

Sponsors and Hosts participate by providing support, venues, infrastructure, resources, visibility, services, facilities, platforms, technical capacity, event support, learning support, public-good support, Campaign support, Nexus Universe support, Studio support, Academy support, Reports support, Foundry support, or National Node support under strict support-without-control discipline.

Sponsor and Host participation is valuable when it expands public-good capacity without capturing agenda, claims, routing, records, recognition, procurement, finance, insurance, public authority learning, community safeguards, or handoff pathways. Sponsors and Hosts must not control Nexus object status, Registry status, Marketplace listing, Grid or TRL outcome, public-safe reporting, Reports conclusions, Campaign claims, National Portfolio priorities, Nexus Universe programming, Working Group outputs, or handoff routing.

A Sponsor and Host Participation Record should identify:

1. support class, including financial support where lawful, in-kind support, venue support, cloud or compute support, data-room support, Studio support, communications support, logistics support, Academy support, Campaign support, Nexus Universe support, or National Node support;
2. support terms, including permitted recognition, prohibited influence, conflict controls, public-safe language, support ledger entry, sponsor support record, host record, and correction pathway;
3. anti-capture controls, including no agenda control, no provider validation, no procurement preference, no pay-to-influence, no pay-to-routing, no hidden endorsement, no public authority overclaim, no finance overclaim, and no handoff control;
4. data and access controls, including whether sponsor or host receives any access, whether access is public, controlled, room-based, or prohibited, and whether data-use, AI-use, confidentiality, and security restrictions apply;
5. boundary notices, confirming that sponsorship or hosting does not create endorsement, certification, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

Sponsors and Hosts support the public-good stack. They do not own it.

### 14.2.12 Providers and Technical Contributors

Providers and Technical Contributors participate by contributing technical knowledge, software, data where lawful, infrastructure context, APIs, tools, models, dashboards, code, documentation, test environments, secure-room capabilities, Studio workflows, Academy content, Reports input, Foundry builds, Nexus Universe demonstrations, or handoff-dependency context under provider-contribution-without-validation discipline.

Provider and technical contribution is important because Nexus works across complex technologies and infrastructure. However, contribution must not become validation, endorsement, procurement preference, certification, marketplace advantage, public authority approval, financeability, insurability, deployment authorization, or execution by implication.

A Provider and Technical Contributor Participation Record should identify:

1. provider role, including contributor, maintainer, demonstrator, technical reviewer, infrastructure-context actor, API contributor, software contributor, data contributor, model contributor, Studio participant, Academy contributor, or lawful recipient;
2. contributed object, including software, dataset, model, API, dashboard, documentation, benchmark, reference implementation, test suite, secure-room workflow, Studio workflow, or technical baseline;
3. review requirements, including code review, security review, dependency review, SBOM, data review, AI review, public-safe review, documentation review, accessibility review, Registry review, Marketplace review, Grid review, and correction pathway;
4. conflict and claims controls, including no provider validation, no vendor certification, no procurement recommendation, no preferred-provider status, no sponsor control, no public authority endorsement, no finance or insurance overclaim, and no deployment authorization;
5. handoff boundary, including separate recipient responsibility, separate procurement where applicable, separate operational review, separate security review, separate public authority approval where applicable, separate finance or insurance review where applicable, and separate execution responsibility.

Providers may help build public-good capability. They do not become validated providers by contributing.

### 14.2.13 Humanitarian Actors

Humanitarian Actors participate as risk, vulnerability, protection, access, community, logistics, public-safe communication, crisis-learning, health, shelter, WFEH-B, displacement, field-context, safeguard, and public-interest contributors. Their participation may be especially important for disaster-risk intelligence, degraded-mode awareness, public-safe reporting, community safeguards, Nexus Campaigns, Academy learning, Studio scenarios, Reports, National Portfolios, Nexus Universe, and lawful handoff-dependency mapping.

Humanitarian participation must respect humanitarian principles, protection concerns, data responsibility, do-no-harm discipline, affected-population dignity, public-safe language, sensitive-location controls, youth and health safeguards, and public authority boundaries. Nexus should not convert humanitarian context into public warning, operational command, beneficiary targeting, surveillance, procurement, finance, insurance, public authority action, or execution by implication.

A Humanitarian Actor Participation Record should identify:

1. humanitarian role, including NGO, response organization, protection actor, health actor, logistics actor, shelter actor, WFEH-B actor, field-context contributor, data responsibility contributor, public-safe reporting contributor, or learning participant;
2. participation pathway, including National Working Group, Helix Council, Campaign, Reports, Studio, public-safe review, DRI review, Observatory review, Academy pathway, Nexus Universe room, safeguard room, or handoff-dependency pathway;
3. sensitivity controls, including affected-population privacy, protection data, health data, youth data, geospatial sensitivity, shelter or facility location masking, public-safe transformation, humanitarian data responsibility, and no-surveillance controls;
4. boundary controls, including non-command, non-warning, non-public-authority-action, non-procurement, non-finance, non-insurance, non-consent, non-deployment, and non-execution status;
5. correction pathway, including correction of harmful publication, sensitive-location exposure, public-safe failure, overclaim, handoff error, withdrawal, recall, archive, and public repair.

Humanitarian actors help Nexus understand risk in human terms. Their participation must never compromise protection or dignity.

### 14.2.14 Standards-Interface Actors

Standards-Interface Actors participate as observers, technical contributors, terminology contributors, interoperability contributors, assurance-context contributors, standards-mapping contributors, policy-learning contributors, and public-good baseline reviewers where Nexus objects may need alignment with external standards, frameworks, specifications, protocols, technical norms, or assurance practices.

Standards-interface participation is important because Nexus work may interact with AI standards, cyber standards, data standards, geospatial standards, telecom standards, public safety standards, humanitarian data standards, accessibility standards, sustainability standards, financial reporting standards, insurance data practices, public procurement norms, and sector-specific technical specifications. However, standards-interface work must not imply that Nexus is the standards authority unless a separate competent protocol or standards authority is explicitly and lawfully recorded.

A Standards-Interface Actor Participation Record should identify:

1. actor role, including standards expert, standards body participant, technical committee observer, interoperability expert, assurance expert, protocol contributor, taxonomy contributor, or technical baseline reviewer;
2. standards relationship, including mapping, gap analysis, terminology alignment, interoperability review, assurance-context review, technical baseline review, public-safe language review, or handoff dependency review;
3. object relationship, including software, data, AI system, API, ontology, schema, DRI indicator, GRIx term, Studio workflow, Registry record, Marketplace listing, Grid or TRL input, Report, Academy object, or handoff package;
4. boundary controls, including standards-interface-not-standards-authority, mapping-not-certification, alignment-not-conformity-assessment, review-not-accreditation, benchmark-not-validation, and no procurement, finance, insurance, public authority action, consent, deployment, or execution by implication;
5. correction and versioning, including standards update monitoring, terminology correction, mapping correction, supersession, withdrawal, archive, and non-continuation.

Standards-interface actors help Nexus remain interoperable and credible. They do not convert Nexus objects into certified standards-compliant products or approved implementations by implication.

The final Whole-of-Society Participation Architecture rule is: Public Authorities, universities, enterprises, capital and insurance readers, donors, public finance readers, civil society, communities, Indigenous participants where applicable, youth, media, diaspora, place-based actors, sponsors, hosts, providers, humanitarian actors, and standards-interface actors each participate through defined roles, records, safeguards, boundaries, and correction pathways. Whole-of-society participation creates legitimacy, knowledge, capability, support, review, and readiness context; it never creates certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 14.3 Team Topologies for Nexus

### 14.3.1 Stream-Aligned Teams

Stream-Aligned Teams are Nexus teams organized around a continuous stream of public-good work, portfolio objects, national priorities, sector domains, technology domains, DRI pathways, Observatory workflows, Studio workflows, Reports series, Campaign lines, Academy pathways, Foundry programs, Nexus Universe tracks, or handoff-dependency streams. Their purpose is to maintain flow from signal to Docket, from Docket to build, from build to review, from review to release, from release to Registry and Marketplace, from portfolio to Nexus Universe, and from Nexus Universe to national continuation or lawful handoff context.

A Stream-Aligned Team should be close enough to its subject matter to understand the work without constant re-briefing and broad enough to route work through Nexus controls. It may be aligned to water systems, food systems, energy systems, health systems, biodiversity systems, DRR, DRF, DRI, AI governance, cyber resilience, public-good software, data commons, public authority learning, finance-readiness questions, insurance-readiness questions, public-safe reporting, National Portfolio development, Nexus Universe preparation, or Foundry production.

A Stream-Aligned Team Record should identify:

1. stream identity, including portfolio, Docket family, national priority, regional cluster, theme, sector, technology, Nexus pillar, Foundry program, Campaign line, Academy pathway, Reports series, or handoff-dependency pathway;
2. stream scope, including object classes, audiences, jurisdictions, National Node relationships, public authority learning relationships, safeguard conditions, and expected outputs;
3. team responsibilities, including intake, triage, Docket maintenance, evidence coordination, review coordination, public-safe routing, Registry and Marketplace coordination, Nexus Universe preparation, correction coordination, archive, and continuation;
4. interfaces, including enabling teams, platform teams, complicated-subsystem teams, public-safe review teams, safeguard review teams, data steward teams, AI/cyber/privacy review teams, National Portfolio teams, Handoff Dependency teams, public authority learning rooms, and readiness rooms;
5. flow metrics, including evidence velocity, correction velocity, public-safe release rate, learning conversion, build completion, Registry status completeness, Marketplace discovery completeness, handoff dependency readiness, DRI refresh rate, and archive integrity;
6. boundary controls, confirming that stream alignment does not create public authority action, certification, procurement, finance, insurance, consent, deployment authorization, or execution.

Stream-Aligned Teams are the main delivery surface for Nexus public-good work. They own flow and context within scope; they do not own external authority.

### 14.3.2 Enabling Teams

Enabling Teams are Nexus teams that help other teams acquire skills, methods, tools, templates, governance literacy, public-safe capability, data governance competence, AI governance competence, cyber competence, accessibility competence, safeguard competence, portfolio discipline, and handoff-dependency discipline. Their function is to improve the capability of stream-aligned teams and national work units without permanently taking over their work.

An Enabling Team may support National Working Groups, Competence Cells, Foundry Build Teams, Campaign Teams, Reports Teams, Studio Rooms, Academy Cohorts, Labs Streams, Risk Agency Expert Panels, public authority learning rooms, readiness rooms, secure rooms, data rooms, National Portfolio teams, and Nexus Universe tracks. It may provide coaching, playbooks, templates, review rubrics, onboarding, training, tooling support, retrospective support, correction support, and capability transfer.

An Enabling Team Record should identify:

1. enablement domain, including data governance, AI governance, cyber review, public-safe reporting, DRI, GRIx, Observatory, Studio, software release, accessibility, safeguards, Indigenous protocol sensitivity where applicable, protected knowledge, finance-readiness literacy, insurance-readiness literacy, public authority boundary discipline, Campaign operations, Academy design, Registry, Marketplace, Grid, or handoff dependency;
2. supported teams, including Stream-Aligned Teams, National Working Groups, Competence Cells, Foundry Build Teams, Campaign Teams, Studio Rooms, Academy Cohorts, Labs Streams, National Portfolio teams, or Handoff Dependency teams;
3. enablement outputs, including training, checklists, templates, examples, reference objects, review guides, playbooks, office hours, coaching notes, public-safe language banks, boundary language, correction patterns, and archive guidance;
4. duration and exit criteria, including when the supported team is expected to operate independently or when enablement must be renewed;
5. knowledge transfer records, including learning records, proof receipts, competency records, support records, correction records, and archive records;
6. boundary controls, confirming that enablement advice is not certification, approval, public authority action, procurement advice, finance advice, insurance advice, consent, deployment authorization, or execution.

Enabling Teams increase capability and reduce dependency. They should not become bottlenecks or shadow approval bodies. Their success is measured by the supported team’s ability to work safely and correctly within Nexus discipline.

### 14.3.3 Complicated-Subsystem Teams

Complicated-Subsystem Teams are specialist Nexus teams responsible for work that requires deep expertise, advanced technical skill, high-risk review, specialized methods, or concentrated stewardship that cannot reasonably be distributed across ordinary stream-aligned teams. They exist where the subsystem is difficult, sensitive, safety-critical, security-critical, model-intensive, data-intensive, legally sensitive, or infrastructure-sensitive.

Complicated subsystems may include AI evaluation harnesses, secure-room architecture, compute-to-data workflows, cyber review systems, geospatial masking pipelines, Earth observation processing, digital twin engines, DRI indicator methods, GRIx ontology engineering, Registry status-truth systems, Marketplace discovery governance, Grid and TRL review logic, public-safe publication workflows, protected knowledge rooms, AI-RAN/O-RAN/private wireless testbeds, sovereign compute workflows, cryptographic controls, SBOM and dependency review pipelines, and handoff-dependency engines.

A Complicated-Subsystem Team Record should identify:

1. subsystem identity, including technical scope, method scope, risk class, object classes, platform dependencies, and portfolio relationships;
2. specialist competence requirements, including domain expertise, security clearance or confidentiality where applicable, data stewardship, AI review, cyber review, geospatial review, software engineering, legal-boundary literacy, public-safe literacy, safeguard literacy, and correctionability literacy;
3. supported streams, including which Stream-Aligned Teams, Foundry programs, Studio workflows, Reports, Campaigns, National Portfolios, Nexus Universe tracks, or handoff pathways depend on the subsystem;
4. service interface, including documentation, APIs, review gates, templates, request pathways, escalation pathways, support class, and correction pathway;
5. risk controls, including access controls, logging, red-team review, security review, output review, public-safe review, incident response, withdrawal, recall, archive, and non-continuation;
6. boundary controls, confirming that subsystem expertise and review do not create certification, production approval, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution.

Complicated-Subsystem Teams protect quality in areas where error would be costly. They should make specialized capability available through clear interfaces rather than becoming opaque expert silos.

### 14.3.4 Platform Teams

Platform Teams are Nexus teams responsible for shared internal platforms, rails, repositories, templates, APIs, registries, marketplaces, Studio environments, data rooms, secure rooms, Docket systems, proof receipt systems, ledgers, dashboards, Academy tooling, Campaign tooling, Foundry tooling, Observatory tooling, DRI tooling, Grid tooling, Nexus Universe tooling, and archive systems that enable other teams to deliver public-good work safely and consistently.

A Platform Team should treat its platform as public-good infrastructure and governed object infrastructure. Its users are other Nexus work units, not unrestricted external customers by default. The platform must reduce cognitive load while preserving data governance, AI-use labels, access controls, public-safe review, safeguard review, Registry status truth, Marketplace discovery discipline, correctionability, and archive integrity.

A Platform Team Record should identify:

1. platform identity, including Docket system, Nexus Rails, Registry, Marketplace, Studio, Grid, Academy platform, Campaign platform, Foundry BuildGrid, Observatory platform, DRI platform, secure-room platform, data-room platform, compute-to-data platform, proof receipt system, ledger system, repository system, or archive platform;
2. platform users, including Stream-Aligned Teams, Enabling Teams, Complicated-Subsystem Teams, Public-Safe Review Teams, Safeguard Review Teams, Data Steward Teams, AI/Cyber/Privacy Review Teams, National Portfolio Teams, Handoff Dependency Teams, Working Groups, Competence Cells, Academy Cohorts, Campaign Teams, or Nexus Universe teams;
3. platform capabilities, including intake, routing, records, access control, review workflow, object identity, metadata, publication, listing, registration, dashboarding, learning, contribution tracking, proof receipts, correction, recall, archive, and reporting;
4. self-service boundaries, including what users may do without review, what requires review, what requires secure-room handling, what requires public-safe review, what requires safeguard review, what requires human approval, and what is prohibited;
5. operational controls, including uptime, support class, access management, logging, privacy, security, vulnerability handling, incident response, change management, correction, withdrawal, recall, archive, and non-continuation;
6. boundary notices, confirming that platform availability does not create certification, procurement, finance, insurance, public authority action, consent, deployment authorization, handoff permission, or execution authority.

Platform Teams make Nexus scalable. They must not allow platform convenience to bypass review, safeguards, rights, or no-conversion discipline.

### 14.3.5 Public-Safe Review Teams

Public-Safe Review Teams are specialist teams responsible for reviewing whether Nexus outputs can be communicated, published, displayed, listed, registered, taught, presented, campaigned, summarized, or handed off safely within the intended audience and release class. They protect against public harm, panic, false reassurance, overclaim, sensitivity exposure, official-status confusion, finance and insurance overclaim, procurement implication, consent overclaim, deployment implication, and execution overclaim.

Public-Safe Review Teams may review Reports, dashboards, maps, Studio summaries, DRI summaries, Observatory outputs, Campaign materials, Academy materials, Marketplace descriptions, Registry public views, Nexus Universe materials, National Portfolio summaries, media materials, public authority learning summaries, capital-reader materials, insurance-reader materials, donor-reader materials, public finance learning materials, and handoff-safe briefs.

A Public-Safe Review Team Record should identify:

1. review scope, including object family, audience, release class, pathway, jurisdictional context, portfolio relationship, and public-facing surface;
2. review criteria, including source fidelity, uncertainty, confidence, public-safe transformation, sensitivity protection, 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;
3. review inputs, including data review records, method review records, safeguard records, geospatial review records, cyber review records, AI review records, public authority boundary records, finance and insurance boundary records, correction records, and archive status;
4. possible outcomes, including public-safe release, controlled-safe release, restricted release, return for revision, secure-room-only, data-room-only, suspend, withdraw, recall, archive, or non-continuing;
5. correction authority within scope, including ability to require correction, pause release, require boundary language, require redaction, trigger escalation, request recall, or route to correction review;
6. boundary controls, confirming that public-safe review is not public authority approval, legal certification, procurement approval, finance approval, insurance approval, consent, deployment authorization, or execution.

Public-Safe Review Teams protect meaning. They do not authorize external action.

### 14.3.6 Safeguard Review Teams

Safeguard Review Teams are specialist teams responsible for reviewing whether Nexus work adequately protects privacy, cybersecurity, community dignity, Indigenous protocols where applicable, protected knowledge, youth, health-sensitive data, accessibility, language access, geospatial sensitivity, infrastructure sensitivity, data sovereignty, public authority boundaries, finance and insurance boundaries, procurement neutrality, sponsor and provider controls, competition neutrality, consent boundaries, correctionability, and public trust.

Safeguard Review Teams may operate nationally, regionally, thematically, sectorally, or within Nexus Universe, Nexus Foundry, Reports, Campaigns, Academy, Studio, Observatory, DRI, Registry, Marketplace, Grid, Readiness Rooms, Secure Rooms, Data Rooms, or handoff-dependency pathways.

A Safeguard Review Team Record should identify:

1. safeguard domain, including privacy, cyber, public-safe reporting, community safeguards, Indigenous protocols where applicable, protected knowledge, youth protection, health sensitivity, accessibility, language, ecological sensitivity, geospatial sensitivity, infrastructure sensitivity, public authority boundary, finance boundary, insurance boundary, procurement neutrality, sponsor support, provider contribution, consent boundary, or correctionability;
2. reviewed object classes, including data, software, AI, reports, dashboards, maps, Studio workflows, Campaigns, Academy objects, Registry records, Marketplace listings, Grid inputs, National Portfolio objects, Nexus Universe outputs, and handoff packages;
3. review criteria, including harm risk, rights risk, exposure risk, overclaim risk, misuse risk, access risk, AI-use risk, public-safe risk, capture risk, and downstream handoff risk;
4. review outcomes, including proceed, proceed with safeguards, restrict, route to secure room, route to protected knowledge room, require community review, require Indigenous protocol review where applicable, require redaction, require no-AI-use, pause, withdraw, recall, archive, or non-continuation;
5. stop-the-line authority, including conditions under which safeguard risk prevents release, listing, registration, presentation, Studio use, Campaign activation, Nexus Universe routing, Grid routing, or handoff context;
6. boundary controls, confirming that safeguard review is a protection and routing control, not certification, public authority action, procurement decision, finance or insurance approval, consent, deployment authorization, or execution.

Safeguard Review Teams ensure that Nexus does not trade legitimacy for speed. Their review must be strong enough to stop momentum where harm risks remain unresolved.

### 14.3.7 Data Steward Teams

Data Steward Teams are Nexus teams responsible for data object governance, metadata discipline, data-use labels, AI-use labels, source review, rights review, sensitivity review, lineage, quality, access class, public-safe transformation, secure-room routing, clean-room routing, compute-to-data workflows, data correction, data retention, deletion, sealing, archive, and downstream use controls.

Data Steward Teams may operate within DICE, DRI, Nexus Observatory, Nexus Studio, Nexus Reports, Nexus Academy, Nexus Campaigns, Nexus Foundry, Nexus Grid, Nexus Registry, Nexus Marketplace, National Portfolios, Nexus Universe, secure rooms, data rooms, clean rooms, protected knowledge rooms, public authority learning rooms, readiness rooms, and handoff-dependency pathways.

A Data Steward Team Record should identify:

1. data domain, including DRI data, Observatory data, WFEH-B data, geospatial data, Earth observation data, sensor data, AI data, cyber data, public authority-sensitive data, health-sensitive data, youth data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, finance-sensitive data, insurance-sensitive data, or handoff-recipient-only data;
2. stewardship responsibilities, including source review, rights review, access classification, sensitivity classification, data-use labeling, AI-use labeling, metadata completion, lineage capture, quality assessment, retention, deletion, sealing, and archive;
3. access pathways, including open access, controlled access, restricted access, secure room, data room, clean room, compute-to-data, protected knowledge room, National Node-only, public authority learning-only, handoff-recipient-only, sealed, or archive-only;
4. review interfaces, including method review, indicator review, AI review, cyber review, geospatial review, public-safe review, safeguard review, public authority boundary review, finance and insurance boundary review, Registry review, Marketplace review, Grid review, and handoff review;
5. correction controls, including data correction, metadata correction, lineage correction, label correction, access correction, public-safe correction, downstream correction propagation, withdrawal, recall, archive, and non-continuation;
6. boundary controls, confirming that data stewardship does not create ownership transfer, unrestricted reuse, AI-use permission beyond labels, public authority record status, procurement status, finance status, insurance status, consent, deployment authorization, or execution.

Data Steward Teams make data trustworthy enough for governed use. They do not make data open by default.

### 14.3.8 AI, Cyber, and Privacy Review Teams

AI, Cyber, and Privacy Review Teams are specialist Nexus teams responsible for reviewing AI systems, model objects, agentic workflows, software objects, data workflows, dashboards, Studio environments, Observatory systems, DRI pipelines, secure rooms, data rooms, compute-to-data workflows, public-good software, Registry systems, Marketplace systems, Grid systems, Campaign platforms, Academy platforms, and handoff packages for AI safety, cybersecurity, privacy, data protection, prompt-injection risk, tool-permission risk, model drift, vulnerability risk, secret exposure, personal data exposure, youth and health data exposure, and incident response readiness.

These teams may operate as separate teams or a combined review structure where risk domains intersect. Their work is essential because AI, cyber, and privacy risks often converge: AI systems may process sensitive data, agents may call tools, dashboards may expose locations, code may contain vulnerabilities, logs may contain personal data, and handoff packages may propagate insecure assumptions.

An AI, Cyber, and Privacy Review Team Record should identify:

1. review domain, including AI safety, model governance, agentic workflow control, prompt-injection, tool permissions, data privacy, cybersecurity, software security, secure release, cloud security, sovereign compute, secure-room architecture, compute-to-data, or incident response;
2. reviewed objects, including models, system cards, benchmark cards, agent workflow cards, AI-use labels, software repositories, APIs, dashboards, data pipelines, logs, secure rooms, Studio workflows, Observatory nodes, DRI systems, Registry systems, Marketplace systems, Grid systems, and handoff packages;
3. review criteria, including data provenance, training data constraints, evaluation records, bias and harm review, red-team records, drift detection, access controls, encryption, secret scanning, dependency scanning, SBOM, vulnerability disclosure, logging, retention, deletion, and archive;
4. control outcomes, including approve within Nexus scope, approve with restrictions, require human-in-the-loop, require no-write-back, require no-command, require secure-room-only, require no-AI-use, require re-evaluation, require patch, require withdrawal, require recall, require archive, or require non-continuation;
5. incident interface, including AI incident records, cybersecurity incident records, privacy incident records, protected knowledge incidents, public-safe publication incidents, kill-switch activation, containment, correction, notification, public repair, and archive;
6. boundary controls, confirming that AI, cyber, and privacy review is not AI safety certification, cybersecurity certification, legal compliance certification, public authority approval, procurement approval, finance approval, insurance approval, consent, deployment authorization, or execution.

AI, Cyber, and Privacy Review Teams reduce risk and preserve correctionability. Their review creates controlled readiness evidence, not external approval by default.

### 14.3.9 National Portfolio Teams

National Portfolio Teams are country-level or country-linked teams responsible for maintaining National Portfolio records, coordinating national Dockets, organizing National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, Safeguard Records, Public Authority Learning Records, Readiness Question Records, Competence Cell Workplans, Universe Arena Routing Records, National Portfolio Archives, and handoff-dependency relationships.

A National Portfolio Team should connect National Nexus Consortiums, National Nodes, National Councils, Helix Councils, National Working Groups, Competence Cells, public authority learning rooms, universities, communities, Indigenous participants where applicable, industry actors, capital readers, insurers, donors, public-interest actors, Campaign Teams, Foundry Build Teams, Reports Teams, Studio Rooms, Academy pathways, Registry, Marketplace, Grid, and Nexus Universe cycles.

A National Portfolio Team Record should identify:

1. national scope, including jurisdiction, National Nexus Consortium relationship, National Node relationship, Regional Portfolio relationship, Global Portfolio relationship, language and accessibility context, and data sovereignty context;
2. portfolio responsibilities, including intake, Docket translation, record creation, status tracking, review routing, public-safe routing, safeguard coordination, National Systems-Risk Map maintenance, Challenge Brief maintenance, Nexus Universe routing, correction, archive, and continuation;
3. interfaces, including public authority learning rooms, National Working Groups, Competence Cells, Campaign Teams, Foundry Build Teams, Academy Cohorts, Studio Rooms, Data Steward Teams, Safeguard Review Teams, Public-Safe Review Teams, AI/Cyber/Privacy Review Teams, and Handoff Dependency Teams;
4. portfolio metrics, including Evidence Velocity, Correction Velocity, Public-Safe Release Rate, National Portfolio Maturity Inputs, Learning Conversion Rate, Campaign Activation Rate, Foundry Build Completion, Registry Status Completeness, Marketplace Discovery Completeness, Handoff Dependency Readiness, DRI Refresh Rate, and Archive Integrity;
5. anti-bypass controls, including national ownership before local delivery, regional support without regional supremacy, global support without global supremacy, sponsor support without control, provider contribution without validation, public authority learning without substitution, and finance-readiness without finance execution;
6. boundary controls, confirming that National Portfolio maintenance is not government policy, public authority action, procurement, finance, insurance, consent, deployment authorization, or execution.

National Portfolio Teams make country-level Nexus work coherent and durable. They are national public-good portfolio stewards, not national execution authorities.

### 14.3.10 Handoff Dependency Teams

Handoff Dependency Teams are specialist Nexus teams responsible for identifying, documenting, reviewing, clarifying, updating, correcting, and archiving the dependencies that must be understood before any Nexus public-good object can move as context toward a separate competent actor for possible action. They protect the public-good stack from collapsing into the enterprise stack.

A Handoff Dependency Team may work with National Portfolio Teams, Foundry Build Teams, Studio Rooms, Reports Teams, Grid teams, Registry teams, Marketplace teams, public authority learning rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, National Consortium Companies, Project SPVs, providers, operators, hosts, universities, labs, community actors where appropriate, Indigenous institutions where applicable, funders, insurers, donors, and public authorities acting separately.

A Handoff Dependency Team Record should identify:

1. handoff candidate object, including software, dataset, model, dashboard, Studio workflow, Report, Academy object, Campaign object, DRI output, Observatory output, Grid record, TRL record, National Portfolio object, Nexus Universe output, Marketplace object, Registry record, or Foundry build;
2. recipient class, including National Consortium Company, Project SPV, public authority acting separately, provider, operator, contractor, host, university, lab, community actor where appropriate, Indigenous institution where applicable, funder, insurer, donor, public finance actor, or other lawful recipient;
3. dependency categories, 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. dependency status, including unresolved, under review, conditionally satisfied for context, satisfied for context, blocked, restricted, stop-the-line, withdrawn, recalled, archived, or non-continuing;
5. handoff package controls, including recipient responsibility notice, no-authority-transfer notice, data-use labels, AI-use labels, support class, warranty boundary, reliance boundary, public authority boundary, finance and insurance boundary, procurement boundary, consent boundary, deployment boundary, execution boundary, correction pathway, and recall pathway;
6. correction and recall interface, including downstream correction propagation, recipient notification, handoff package recall, Registry update, Marketplace update, Grid update, National Portfolio update, Nexus Universe update, archive, and public repair where required.

Handoff Dependency Teams do not approve handoff recipients, execute projects, issue procurement decisions, arrange finance, underwrite insurance, grant public authority approval, secure consent, authorize deployment, or implement work. Their task is to make dependencies explicit so that separate competent actors cannot mistake Nexus context for Nexus authority.

The final Team Topologies for Nexus rule is: Stream-Aligned Teams own flow; Enabling Teams build capability; Complicated-Subsystem Teams steward specialist systems; Platform Teams provide shared rails; Public-Safe Review Teams govern communication; Safeguard Review Teams protect legitimacy; Data Steward Teams govern data; AI, Cyber, and Privacy Review Teams control high-risk technology; National Portfolio Teams preserve country-level coherence; Handoff Dependency Teams protect the public-good-to-enterprise boundary. Team topology creates disciplined work architecture, not certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 14.4 Nexus Guilds

### 14.4.1 Data Guilds

Data Guilds are Nexus communities of practice responsible for strengthening data governance, data stewardship, data quality, metadata discipline, data-use labeling, AI-use labeling, lineage, data dictionaries, schemas, codebooks, data commons practice, secure-room practice, clean-room practice, compute-to-data practice, public-safe data transformation, data correction, data archive, and lawful data handoff discipline across Nexus Ecosystem.

Data Guilds should support DICE, DRI, Nexus Observatory, Nexus Studio, Nexus Reports, Nexus Academy, Nexus Campaigns, Nexus Foundry, Nexus Grid, Nexus Registry, Nexus Marketplace, National Portfolios, Nexus Universe, National Nodes, National Working Groups, Competence Cells, public authority learning rooms, readiness rooms, secure rooms, data rooms, and handoff-dependency pathways.

A Data Guild Record should identify:

1. data practice scope, including data intake, source review, rights review, data-use labels, AI-use labels, metadata, lineage, data quality, sensitivity classification, access class, retention, deletion, sealing, archive, and correction;
2. data object classes, including raw data, processed data, public-safe data, aggregated data, synthetic data, metadata-only records, DRI datasets, Observatory datasets, benchmark datasets, National Portfolio datasets, Studio datasets, and handoff-recipient-only datasets;
3. practice outputs, including schemas, data dictionaries, codebooks, templates, quality rubrics, data review checklists, AI-use review checklists, public-safe transformation guides, secure-room playbooks, compute-to-data playbooks, and archive guides;
4. safeguard integration, including privacy, cyber, protected knowledge, Indigenous protocol-sensitive data where applicable, community-sensitive data, youth data, health-sensitive data, geospatial-sensitive data, infrastructure-sensitive data, public authority-sensitive data, and sovereign data controls;
5. correction practice, including data correction, metadata correction, lineage correction, label correction, public-safe correction, downstream correction propagation, withdrawal, recall, sealing, deletion where required, archive, and non-continuation;
6. boundary controls, confirming that data practice guidance does not create ownership transfer, unrestricted reuse, AI-use permission beyond recorded labels, public authority record status, procurement status, finance status, insurance status, consent, deployment authorization, or execution.

Data Guilds make data work more consistent and trustworthy. They do not make data open, approved, certified, financeable, insurable, public-authority-recognized, or executable by implication.

### 14.4.2 AI Guilds

AI Guilds are Nexus communities of practice responsible for AI governance, model documentation, system documentation, benchmark documentation, agent workflow cards, AI-use labels, model evaluation, human review, agentic workflow controls, prompt-injection controls, tool-permission controls, bias and harm review, drift detection, AI incident response, model withdrawal, and AI archive discipline.

AI Guilds should support AI systems used in data processing, DRI, Observatory, Studio, Reports, Academy, Campaigns, Foundry, Grid, Registry, Marketplace, National Portfolios, Nexus Universe, secure rooms, data rooms, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, and handoff-context pathways.

An AI Guild Record should identify:

1. AI practice scope, including AI system records, model cards, system cards, benchmark cards, agent workflow cards, AI-use labels, evaluation records, red-team records, drift records, incident records, withdrawal records, and archive records;
2. AI object classes, including statistical models, machine-learning models, foundation-model interfaces, fine-tuned models, retrieval-augmented systems, agentic workflows, classifiers, forecasting models, simulation models, digital twin models, risk models, optimization models, decision-support models, and evaluation harnesses;
3. practice outputs, including AI governance playbooks, model card templates, system card templates, benchmark card templates, agent workflow templates, AI-use label guides, evaluation rubrics, red-team patterns, human review checklists, public-safe AI output guides, and AI incident response guides;
4. control discipline, 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, public-safe AI output only, no-command rules, no-write-back rules, escalation triggers, kill-switch conditions, and output review;
5. risk controls, including data provenance, training data constraints, bias and harm review, prompt-injection controls, tool-permission controls, logging, red-team records, drift detection, AI incident response, model withdrawal, and archive;
6. boundary controls, confirming that AI documentation, evaluation, benchmark performance, agent output, workflow operation, or guild guidance does not create AI safety certification, deployment authorization, public authority decision, procurement readiness, financeability, insurability, consent, or execution.

AI Guilds make AI use legible, bounded, reviewed, and correctable. They do not certify AI systems or authorize deployment by implication.

### 14.4.3 Cyber Guilds

Cyber Guilds are Nexus communities of practice responsible for cybersecurity methods, secure software practice, secure release discipline, vulnerability handling, dependency review, SBOM practice, secret scanning, access control, secure-room architecture, data-room security, compute-to-data security, prompt-injection security, tool-permission security, incident response, cyber sensitivity review, and cyber-safe publication discipline.

Cyber Guilds should support public-good software, APIs, dashboards, data pipelines, Studio workflows, Observatory Nodes, sensor networks, DRI systems, Registry systems, Marketplace systems, Campaign platforms, Academy platforms, Foundry tools, Grid systems, Nexus Universe systems, secure rooms, data rooms, National Nodes, and handoff packages.

A Cyber Guild Record should identify:

1. cyber practice scope, including secure coding, threat modeling, dependency scanning, secret scanning, SBOMs, vulnerability disclosure, access control, encryption, logging, incident response, secure defaults, release controls, and archive controls;
2. system classes supported, including repositories, services, APIs, dashboards, AI workflows, Studio environments, Observatory systems, DRI platforms, Registry platforms, Marketplace platforms, Campaign platforms, Academy platforms, secure rooms, data rooms, compute-to-data systems, and handoff packages;
3. practice outputs, including secure release checklists, threat-model templates, vulnerability disclosure templates, dependency review guides, SBOM templates, access-control guides, prompt-injection playbooks, tool-permission controls, incident response playbooks, and public-safe cyber reporting guides;
4. sensitivity controls, including cyber-sensitive data, infrastructure-sensitive data, secrets, credentials, system configurations, network architecture, vulnerabilities, exploit details, incident logs, operational technology details, and handoff-recipient-only security information;
5. correction and incident practice, including vulnerability correction, secret rotation, access revocation, kill-switch activation, Registry correction, Marketplace delisting, Report correction, Studio shutdown, handoff recall, public repair where appropriate, and archive;
6. boundary controls, confirming that cyber review, secure release, code review, SBOM production, or guild guidance does not create cybersecurity certification, public authority approval, procurement approval, insurance approval, deployment authorization, warranty, or execution authority.

Cyber Guilds reduce attack surface and improve trust. They do not certify security or authorize production use by default.

### 14.4.4 Privacy Guilds

Privacy Guilds are Nexus communities of practice responsible for privacy, data protection, data minimization, purpose limitation, consent and permission discipline, sensitive-data classification, youth data safeguards, health-sensitive data safeguards, cross-border transfer controls, data sovereignty, retention, deletion, sealing, access control, public-safe transformation, privacy-by-design, AI privacy controls, and privacy incident response.

Privacy Guilds should support DICE, DRI, Observatory, Studio, Reports, Academy, Campaigns, Foundry, Registry, Marketplace, Grid, National Portfolios, Nexus Universe, secure rooms, data rooms, clean rooms, compute-to-data workflows, public authority learning rooms, and handoff-dependency pathways.

A Privacy Guild Record should identify:

1. privacy practice scope, including data minimization, purpose limitation, consent, permission, access control, data-use labels, AI-use labels, privacy review, retention, deletion, sealing, archive, and incident response;
2. sensitive-data classes, including personal data, youth data, health-sensitive data, vulnerable-population data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, geospatial-sensitive data, cyber-sensitive data, infrastructure-sensitive data, and handoff-recipient-only data;
3. practice outputs, including privacy review templates, data minimization guides, consent-boundary language, youth data safeguards, health data handling guides, cross-border transfer checklists, retention schedules, deletion and sealing procedures, public-safe transformation guides, and privacy incident playbooks;
4. AI privacy controls, including no-AI-use labels, secure-room AI only, training-data constraints, fine-tuning restrictions, prompt logging limits, output review, model withdrawal, and privacy incident records;
5. correction practice, including privacy correction, access correction, data-use label correction, AI-use label correction, deletion, sealing, withdrawal, recall, public repair where appropriate, and archive;
6. boundary controls, confirming that privacy review or guild guidance does not create legal compliance certification, public authority approval, consent, data ownership transfer, unrestricted data use, procurement approval, finance approval, insurance approval, deployment authorization, or execution.

Privacy Guilds protect people and trust. They do not convert data availability into data rights.

### 14.4.5 Geospatial Guilds

Geospatial Guilds are Nexus communities of practice responsible for geospatial data governance, mapping standards within Nexus, spatial metadata, Earth observation use, sensor-location discipline, geospatial sensitivity review, public-safe mapping, spatial aggregation, masking, displacement, digital twin geographies, geospatial AI limits, infrastructure mapping controls, protected-site controls, ecological sensitivity, and location-based correction.

Geospatial Guilds should support DRI, GRIx, Observatory, Studio, Reports, National Systems-Risk Maps, WFEH-B portfolios, Regional Clusters, National Dense Nexus Cores, Nexus Universe outputs, Campaign maps, Academy maps, Marketplace listings, Registry records, Grid inputs, and handoff packages.

A Geospatial Guild Record should identify:

1. geospatial practice scope, including maps, layers, coordinates, rasters, vectors, geocoding, spatial indicators, Earth observation products, sensor locations, digital twin inputs, Studio maps, public-safe maps, and archive maps;
2. sensitivity classes, including exact location, high-resolution imagery, vulnerable-population locations, protected sites, sacred or culturally significant sites, Indigenous protocol-sensitive locations where applicable, ecological-sensitive locations, infrastructure-sensitive locations, cyber-physical assets, health facilities, shelters, public authority-sensitive assets, and security-sensitive facilities;
3. practice outputs, including mapping templates, geospatial metadata guides, spatial uncertainty labels, map legend guidance, public-safe mapping playbooks, aggregation guides, masking and displacement rules, Earth observation interpretation guides, and geospatial archive rules;
4. review controls, including geospatial sensitivity review, public-safe review, cyber review, privacy review, safeguard review, public authority boundary review, finance and insurance boundary review, and correction review;
5. correction practice, including map correction, layer correction, dashboard correction, public-safe map withdrawal, geospatial recall, sealing, deletion where required, archive, and non-continuation;
6. boundary controls, confirming that geospatial objects are not official maps, public warnings, public authority designations, procurement priorities, finance signals, insurance ratings, consent records, deployment authorizations, or execution instructions by default.

Geospatial Guilds make location intelligence usable without making it dangerous. They preserve the difference between mapping and authority.

### 14.4.6 WFEH-B Guilds

WFEH-B Guilds are Nexus communities of practice responsible for water, food, energy, health, biodiversity, cross-system cascades, corridor dependencies, degraded-mode continuity, nature-based resilience, WFEH-B data, WFEH-B indicators, WFEH-B Studio scenarios, WFEH-B Reports, WFEH-B Academy pathways, WFEH-B Campaigns, WFEH-B National Portfolio objects, and WFEH-B handoff dependencies.

WFEH-B Guilds should ensure that water, food, energy, health, and biodiversity are treated as interdependent life-support systems rather than isolated sectors. They should support National Portfolios, Regional Portfolios, Global Portfolios, DRI, GRIx, Observatory, Studio, Reports, Academy, Campaigns, Grid, TRL, Nexus Universe, and lawful handoff pathways.

A WFEH-B Guild Record should identify:

1. domain scope, including water systems, food systems, energy systems, health systems, biodiversity and nature systems, cross-system cascades, corridors, clusters, and National Dense Nexus Core profiles;
2. practice outputs, including WFEH-B taxonomies, indicators, systems-risk maps, cascade templates, scenario templates, public-safe reporting guides, National Challenge Brief templates, evidence need templates, Observatory need templates, and handoff dependency templates;
3. data and intelligence controls, including DRI indicators, Observatory signals, Earth observation, sensor networks, geospatial layers, public authority learning inputs, community context, protected knowledge exclusions, Indigenous protocol controls where applicable, confidence labels, uncertainty labels, and correction pathways;
4. safeguards, including health sensitivity, youth data, ecological sensitivity, protected sites, community safeguards, Indigenous protocols where applicable, protected knowledge, infrastructure sensitivity, cyber sensitivity, accessibility, and public-safe reporting;
5. handoff practice, including public authority dependencies, utility and operator dependencies, procurement dependencies, finance dependencies, insurance dependencies, donor dependencies, public finance dependencies, community and Indigenous consent dependencies where applicable, enterprise dependencies, and correction dependencies;
6. boundary controls, confirming that WFEH-B portfolio or guild outputs do not create warnings, public health advisories, utility commands, environmental approvals, procurement, finance, insurance, consent, deployment authorization, or execution.

WFEH-B Guilds make life-support systems intelligible and connected. They do not govern those systems by default.

### 14.4.7 DRR Guilds

DRR Guilds are Nexus communities of practice responsible for disaster risk reduction methods, preparedness learning, mitigation intelligence, resilience capability, degraded-mode planning, continuity learning, after-action learning, public-safe DRR reporting, National Portfolio DRR objects, Nexus Universe DRR tracks, Academy DRR pathways, Campaign DRR mobilization, Studio DRR scenarios, and DRR handoff dependencies.

DRR Guilds should help Nexus organize prevention, mitigation, preparedness, resilience, recovery learning, adaptation, systems-risk reduction, WFEH-B resilience, infrastructure resilience, cyber-physical resilience, and whole-of-society capability formation without becoming an emergency command body or public authority.

A DRR Guild Record should identify:

1. DRR practice scope, including risk understanding, risk governance learning, mitigation, preparedness, resilience strengthening, continuity, degraded-mode awareness, recovery learning, adaptation, and correction;
2. practice outputs, including DRR taxonomies, scenario templates, preparedness learning modules, National Challenge Brief templates, public-safe DRR reporting guides, after-action learning templates, Campaign templates, Studio exercise patterns, and handoff dependency guides;
3. portfolio relationships, including DRR Portfolios, National Portfolios, Regional Portfolios, DRI Portfolios, WFEH-B Portfolios, Reports Portfolios, Campaign Portfolios, Academy pathways, Nexus Universe outputs, and handoff-dependency portfolios;
4. public authority boundary discipline, including learning-only, non-warning, non-command, non-emergency-response, non-regulatory, non-procurement, non-public-finance, and non-execution language;
5. safeguards, including community dignity, humanitarian data responsibility, youth and health sensitivity, geospatial and infrastructure sensitivity, protected knowledge, Indigenous protocols where applicable, accessibility, and public-safe communication;
6. boundary controls, confirming that DRR guild guidance does not issue warnings, direct response, certify readiness, allocate public finance, approve procurement, grant consent, authorize deployment, or execute projects.

DRR Guilds strengthen preparedness and resilience learning. They do not command disaster response.

### 14.4.8 DRF Guilds

DRF Guilds are Nexus communities of practice responsible for disaster risk finance literacy, protection-gap questions, risk-layering questions, finance-readiness question formation, insurance-readiness question formation, donor-readiness question formation, public finance learning, assumptions registers, dependency registers, diligence-gap records, capital-reader room methods, insurance-reader room methods, donor-reader room methods, and regulated-perimeter discipline.

DRF Guilds should be GRA-aligned in posture while preserving no-reliance, non-advisory, non-soliciting, non-transactional, non-underwriting, non-rating, non-allocation, and non-execution boundaries. Their role is to help risk intelligence become capital-readable and insurance-readable without becoming finance or insurance execution.

A DRF Guild Record should identify:

1. DRF practice scope, including protection-gap questions, risk-layering questions, finance-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, resilience finance context, capital-readability, and handoff dependency mapping;
2. practice outputs, including no-reliance templates, assumptions register templates, dependency register templates, diligence-gap templates, capital-reader room guides, insurance-reader room guides, donor-reader room guides, public finance learning room guides, and regulated-perimeter escalation guides;
3. portfolio relationships, including DRF Portfolios, National Investors Councils, Capital / Insurance / Donor / Development Helix Councils, National Portfolios, Nexus Universe rooms, DRI outputs, Studio scenarios, Reports, Grid and TRL context, and handoff-dependency portfolios;
4. regulated-perimeter controls, including no investment advice, no solicitation, no securities offering, no valuation, no rating, no brokerage, no lending decision, no underwriting, no coverage commitment, no premium indication, no guarantee, no donor commitment, no public finance allocation, no transaction execution, and no reliance;
5. safeguard controls, including confidentiality, competition neutrality, sponsor and provider controls, public authority boundary discipline, public-safe reporting, data-use restrictions, and correction of finance or insurance overclaims;
6. boundary controls, confirming that DRF guild work does not create financeability, bankability, insurability, donor commitment, public finance approval, procurement readiness, or execution.

DRF Guilds make financial questions safer and clearer. They do not transact.

### 14.4.9 DRI Guilds

DRI Guilds are Nexus communities of practice responsible for Disaster Risk Intelligence structures, indicator records, signal records, confidence labels, uncertainty labels, public-safe intelligence summaries, dashboard records, hotspot records, multi-hazard records, cascade records, national DRI contributions, correction records, archive records, and DRI review practice.

DRI Guilds should support National Portfolios, Regional Portfolios, Global Portfolios, Nexus Observatory, GRIx, Studio, Reports, Academy, Campaigns, Grid, Registry, Marketplace, Nexus Universe, public authority learning rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, and handoff-dependency pathways.

A DRI Guild Record should identify:

1. DRI practice scope, including hazard, exposure, vulnerability, capacity, resilience, degraded-mode, WFEH-B, cyber-physical, geospatial, infrastructure, systems-risk, public authority learning, finance-readiness, insurance-readiness, safeguard, and handoff intelligence;
2. practice outputs, including indicator templates, signal templates, confidence label guides, uncertainty label guides, hotspot record templates, multi-hazard record templates, cascade record templates, dashboard interpretation guides, public-safe intelligence summary templates, DRI refresh guidance, and correction playbooks;
3. review controls, 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;
4. public-safe controls, including non-warning language, non-rating language, dashboard-not-decision language, scenario-not-forecast-certainty language, DRI-output-not-insurance-score language, and DRI-output-not-investment-signal language;
5. correction and archive practice, including indicator correction, dashboard correction, signal correction, hotspot correction, cascade correction, Report correction, Registry correction, Marketplace correction, Grid correction, handoff correction, withdrawal, recall, archive, and non-continuation;
6. boundary controls, confirming that DRI objects are not official warnings, legal classifications, insurance scores, investment signals, procurement priorities, public authority decisions, consent records, deployment approvals, or execution instructions.

DRI Guilds make disaster risk intelligence structured, reviewed, and correctable. They do not issue warnings or ratings.

### 14.4.10 GRIx Guilds

GRIx Guilds are Nexus communities of practice responsible for the risk ontology, controlled vocabulary, taxonomies, semantic interoperability, definitions, term governance, versioning, localization, translation, public-safe terminology, boundary categories, safeguard categories, and handoff dependency categories used across Nexus Ecosystem.

GRIx Guilds should support GRIx risk categories, WFEH-B taxonomies, DRR categories, DRF categories, DRI categories, systems-risk categories, frontier technology risk categories, public authority boundary categories, finance and insurance boundary categories, safeguard categories, handoff dependency categories, and cross-institution vocabulary used by GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), Nexus pillar institutions, consortiums, National Nodes, and enterprise-interface pathways.

A GRIx Guild Record should identify:

1. ontology scope, including risk terms, WFEH-B terms, DRR terms, DRF terms, DRI terms, systems-risk terms, technology-risk terms, public authority boundary terms, finance and insurance boundary terms, safeguard terms, and handoff dependency terms;
2. term governance, including term proposal, definition, source context, controlled vocabulary placement, synonyms, deprecated terms, localization, translation, versioning, correction, supersession, archive, and non-continuation;
3. interoperability outputs, including glossaries, taxonomies, schemas, mappings, term cards, public-safe language guides, Registry term records, Marketplace term use, Reports terminology, Academy terminology, Studio terminology, and handoff terminology;
4. legal-boundary discipline, including category-not-legal-classification, mapping-not-certification, alignment-not-conformity-assessment, readiness-term-not-approval, and handoff-term-not-execution language;
5. review interfaces, including DRI Guilds, WFEH-B Guilds, DRR Guilds, DRF Guilds, Legal Boundary Guilds, Safeguard Guilds, Data Guilds, AI Guilds, Public-Safe Reporting Guilds, Registry and Marketplace Guilds, Grid and TRL Guilds, and Handoff Guilds;
6. boundary controls, confirming that controlled vocabulary does not create law, regulation, insurance class, finance class, procurement class, certification class, consent status, deployment status, or execution status by implication.

GRIx Guilds make Nexus language precise enough for interoperability and safe enough for public use. They do not legislate.

### 14.4.11 DICE Guilds

DICE Guilds are Nexus communities of practice responsible for the Data, Innovation, Commons, and Evidence governance layer. They integrate data governance, innovation governance, commons stewardship, evidence discipline, metadata, public-good objects, public-safe transformation, access classes, data-use labels, AI-use labels, source review, rights review, evidence records, method records, and correction pathways.

DICE Guilds should support all public-good object families, including data, software, AI, reports, learning objects, dashboards, models, schemas, APIs, Campaign objects, Studio workflows, Registry objects, Marketplace objects, Grid objects, National Portfolio objects, Nexus Universe objects, handoff objects, correction objects, and archive objects.

A DICE Guild Record should identify:

1. DICE scope, including data governance, innovation governance, commons governance, evidence governance, metadata governance, public-good object governance, and correction governance;
2. object governance outputs, including object identity templates, metadata templates, data-use label guides, AI-use label guides, evidence record templates, method record templates, access-class guides, commons stewardship guides, and archive guides;
3. commons controls, including open where lawful, controlled where necessary, restricted where required, protected knowledge controls, Indigenous protocol controls where applicable, public-safe transformation, licensing, contribution terms, support class, and correction pathway;
4. evidence controls, including source records, lineage, quality assessment, method review, confidence labels, uncertainty labels, public-safe status, Registry status, Marketplace relationship, Grid context, and handoff dependency records;
5. innovation controls, including public-good innovation review, open technical baseline review, public-good software review, Labs-to-Foundry routing, Foundry-to-Handoff routing, and anti-capture discipline;
6. boundary controls, confirming that DICE governance does not create open data rights, AI-use permission beyond labels, certification, procurement, finance, insurance, public authority action, consent, deployment authorization, or execution.

DICE Guilds make public-good objects governable from intake to archive. They do not make the commons uncontrolled.

### 14.4.12 Public-Safe Reporting Guilds

Public-Safe Reporting Guilds are Nexus communities of practice responsible for safe publication, public-safe summaries, Reports language, Campaign language, dashboard language, map language, Nexus Universe language, media-safe language, Academy public materials, Marketplace descriptions, Registry public views, public authority boundary language, finance and insurance boundary language, safeguard language, correction notices, withdrawal notices, recall notices, public repair, and archive notices.

Public-Safe Reporting Guilds should ensure that Nexus communicates risk, readiness, uncertainty, public-good work, evidence, data, AI, WFEH-B, DRR, DRF, DRI, public authority learning, finance-readiness questions, and handoff dependencies without causing harm or overclaim.

A Public-Safe Reporting Guild Record should identify:

1. reporting scope, including Reports, dashboards, maps, Campaigns, Academy materials, Studio summaries, Observatory outputs, DRI summaries, National Portfolio summaries, Nexus Universe materials, Marketplace listings, Registry public views, media materials, and handoff-safe briefs;
2. language controls, including uncertainty language, limitation language, non-warning language, non-decision 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;
3. sensitivity controls, 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;
4. practice outputs, including public-safe style guides, claim review checklists, media-safe templates, dashboard language guides, map legends, correction notice templates, withdrawal templates, recall templates, public repair guides, and archive notice guides;
5. correction practice, including public correction, errata, addenda, supersession, withdrawal, recall, clarification, Marketplace correction, Registry correction, Campaign correction, media correction, and archive;
6. boundary controls, confirming that public-safe reporting is not official warning, certification, procurement recommendation, finance signal, insurance score, public authority decision, consent, deployment authorization, or execution.

Public-Safe Reporting Guilds protect Nexus public meaning. They keep publication truthful, bounded, and repairable.

### 14.4.13 Legal Boundary Guilds

Legal Boundary Guilds are Nexus communities of practice responsible for legal-boundary literacy, no-conversion discipline, non-execution doctrine, role separation, public authority boundary language, finance and insurance boundary language, procurement neutrality, no-reliance language, non-solicitation language, no-agency language, no-implied-authority language, sponsor support-without-control language, provider contribution-without-validation language, consent-boundary language, handoff-not-execution language, and correction of legal overclaims.

Legal Boundary Guilds are not law firms by default and do not provide legal advice unless separately and lawfully engaged through competent professional structures. Their function within Nexus is to steward boundary patterns, issue-spotting, templates, escalation pathways, and role-separation discipline.

A Legal Boundary Guild Record should identify:

1. boundary domain, including non-execution, public authority, procurement, finance, insurance, donor, public finance, securities, investment advice, underwriting, certification, standards authority, consent, data rights, AI use, privacy, cyber, IP, sponsor, provider, competition, antitrust, handoff, and archive;
2. practice outputs, including boundary clauses, no-conversion notices, role-separation templates, escalation checklists, claims review guides, room rules, handoff notices, Marketplace notices, Registry notices, Reports notices, Campaign notices, and correction notices;
3. review interfaces, including Public-Safe Reporting Guilds, Safeguard Guilds, DRF Guilds, Data Guilds, AI Guilds, Registry and Marketplace Guilds, Studio Guilds, Grid and TRL Guilds, Handoff Guilds, National Portfolio Teams, and public authority learning rooms;
4. escalation triggers, including regulated-perimeter risk, public authority overclaim, procurement overclaim, finance or insurance overclaim, donor commitment overclaim, public finance overclaim, consent overclaim, deployment overclaim, execution overclaim, data rights ambiguity, IP ambiguity, competition risk, or jurisdictional conflict;
5. correction practice, including overclaim correction, public repair, withdrawal, recall, restriction, archive, and non-continuation;
6. boundary controls, confirming that guild guidance is boundary support and issue-spotting, not legal advice, certification, public authority decision, procurement decision, finance approval, insurance approval, consent, deployment authorization, or execution.

Legal Boundary Guilds keep Nexus from collapsing roles. They make boundary discipline reusable across the ecosystem.

### 14.4.14 Safeguard Guilds

Safeguard Guilds are Nexus communities of practice responsible for protection of people, communities, rights, data, knowledge, accessibility, ecological sensitivity, public trust, Indigenous protocols where applicable, protected knowledge, youth safeguards, health sensitivity, privacy, cyber, geospatial sensitivity, anti-capture, competition neutrality, sponsor controls, provider controls, consent boundaries, and correctionability.

Safeguard Guilds should support all Nexus objects and pathways, especially those involving communities, Indigenous participants where applicable, protected knowledge, public-safe reporting, DRI, Observatory, Studio, Campaigns, Academy, Reports, Marketplace, Registry, Grid, National Portfolios, Nexus Universe, public authority learning, finance-readiness, insurance-readiness, and lawful handoff.

A Safeguard Guild Record should identify:

1. safeguard domain, including privacy, cyber, community, Indigenous protocol where applicable, protected knowledge, youth, health, accessibility, language, environmental and social safeguards, ecological sensitivity, geospatial sensitivity, infrastructure sensitivity, public-safe reporting, anti-capture, competition neutrality, and correctionability;
2. practice outputs, including safeguard review templates, community participation guides, Indigenous protocol-sensitive handling guides where applicable, protected knowledge room rules, youth safeguard guides, accessibility checklists, public-safe transformation guides, anti-capture checklists, and correction playbooks;
3. review pathways, including Safeguard Review Teams, Public-Safe Review Teams, Data Steward Teams, AI/Cyber/Privacy Review Teams, National Portfolio Teams, Studio Rooms, Campaign Teams, Academy Cohorts, and Handoff Dependency Teams;
4. stop-the-line conditions, including protected knowledge exposure, consent overclaim, community harm, Indigenous protocol breach where applicable, youth risk, health-sensitive exposure, privacy incident, cyber exposure, geospatial exposure, public authority overclaim, finance or insurance overclaim, sponsor capture, provider validation, or handoff overclaim;
5. correction and repair, including correction, withdrawal, recall, sealing, deletion where required, community repair, public repair, archive, and non-continuation;
6. boundary controls, confirming that safeguard review supports protection and legitimacy without creating consent, public authority approval, certification, procurement, finance, insurance, deployment authorization, or execution.

Safeguard Guilds make legitimacy operational. They ensure that public-good ambition does not override rights, dignity, or trust.

### 14.4.15 Marketplace and Registry Guilds

Marketplace and Registry Guilds are Nexus communities of practice responsible for Marketplace discovery discipline and Registry status-truth discipline. They govern how objects are listed, described, versioned, statused, corrected, delisted, archived, discovered, supported, and bounded across Nexus public-good surfaces.

Marketplace and Registry Guilds should support software, data, AI, Reports, Academy materials, Campaigns, Studio workflows, DRI outputs, GRIx mappings, Observatory outputs, Grid and TRL records, National Portfolio objects, Nexus Universe outputs, support opportunities, contribution opportunities, and handoff-awareness objects.

A Marketplace and Registry Guild Record should identify:

1. Registry practice scope, including object identity, lifecycle state, support class, review status, access class, public-safe status, sensitivity class, correction status, withdrawal status, recall status, archive status, and non-continuation status;
2. Marketplace practice scope, including discovery listing, object description, support discovery, contribution discovery, learning discovery, demand-signal capture, handoff-awareness discovery, listing governance, correction, delisting, and archive;
3. practice outputs, including Registry templates, Marketplace listing templates, status taxonomy, lifecycle taxonomy, support taxonomy, listing review checklists, boundary notice templates, delisting playbooks, correction playbooks, and archive rules;
4. status-truth controls, including current status, supersession, correction, withdrawal, recall, archive, non-current authority notices, Registry-Marketplace consistency, and downstream dependency propagation;
5. boundary controls, including Registry-not-certification, Marketplace-not-procurement, listing-not-endorsement, listing-not-provider-validation, listing-not-financeability, listing-not-insurability, listing-not-public-authority-approval, listing-not-consent, listing-not-deployment, and listing-not-execution;
6. correction practice, including Registry correction, Marketplace correction, delisting, relisting, support reclassification, public-safe correction, handoff-awareness correction, withdrawal, recall, archive, and non-continuation.

Marketplace and Registry Guilds ensure that discovery follows status truth. They do not certify, endorse, procure, finance, insure, approve, consent, deploy, or execute.

### 14.4.16 Studio Guilds

Studio Guilds are Nexus communities of practice responsible for controlled runtime learning, dashboard workflows, digital twin workflows, simulation workflows, AI workflow review, data-room workflows, secure-room workflows, public authority learning workflows, readiness workflows, handoff-demonstration workflows, no-command rules, no-write-back rules, output review, logging, and Studio archive.

Studio Guilds should support Studio Rooms, Readiness Rooms, Public Authority Learning Rooms, Capital-Reader Rooms, Insurance-Reader Rooms, Donor-Reader Rooms, Public Finance Learning Rooms, secure rooms, data rooms, National Portfolio rooms, Nexus Universe rooms, Observatory workflows, DRI workflows, Reports, Academy, Campaigns, Grid, Registry, Marketplace, and handoff-dependency pathways.

A Studio Guild Record should identify:

1. Studio practice scope, including dashboards, digital twins, simulations, scenario learning, AI workflows, data rooms, secure rooms, compute-to-data workflows, public authority learning, readiness review, Nexus Universe demonstrations, and handoff demonstrations;
2. runtime controls, including access control, no-download, no-write-back, no-command, logging, human-in-the-loop, human-on-the-loop, output review, AI-use labels, data-use labels, prompt-injection controls, tool-permission controls, kill-switch conditions, correction, and archive;
3. practice outputs, including Studio room templates, scenario templates, dashboard review guides, digital twin limitation notices, simulation boundary notices, AI workflow cards, output review checklists, room rules, demonstration scripts, and archive templates;
4. safeguard and boundary integration, including public-safe review, data review, AI review, cyber review, geospatial review, public authority boundary review, finance and insurance boundary review, safeguard review, and handoff review;
5. correction practice, including Studio workflow correction, dashboard correction, model correction, digital twin correction, scenario correction, AI workflow suspension, room output correction, withdrawal, recall, archive, and non-continuation;
6. boundary controls, confirming that Studio workflows are not deployment, operational command, public authority action, procurement, finance, insurance, consent, handoff authorization, or execution by implication.

Studio Guilds make complex systems learnable under control. They do not operate those systems by default.

### 14.4.17 Grid and TRL Guilds

Grid and TRL Guilds are Nexus communities of practice responsible for Grid maturity-input discipline, TRL 1–10 classification practice, review-routing logic, evidence sufficiency, support status, readiness classes, downgrade, suspension, withdrawal, reinstatement, archive, and the boundary that Grid and TRL records are not certification.

Grid and TRL Guilds should support public-good software, data objects, AI objects, models, dashboards, Studio workflows, Reports, Academy objects, Campaign objects, Observatory outputs, DRI indicators, GRIx mappings, National Portfolio objects, Nexus Universe outputs, Marketplace listings, Registry records, and handoff dependency packages.

A Grid and TRL Guild Record should identify:

1. readiness practice scope, including technical readiness, evidence readiness, public-good readiness, Studio readiness, Reports readiness, Academy readiness, Campaign readiness, Registry readiness, Marketplace readiness, Nexus Universe readiness, and handoff-context readiness;
2. TRL 1–10 interpretation, including concept, basic principle, proof of concept, validated component, integrated prototype, relevant environment demonstration, operational environment demonstration where separately controlled, system completion context, deployment-context readiness only where separate actors assume responsibility, and post-deployment learning where separately recorded, each bounded by Nexus non-execution;
3. Grid record requirements, including object identity, evidence records, method records, data-use labels, AI-use labels, security review, public-safe review, support class, Registry status, Marketplace status, correction history, and archive rule;
4. review outputs, including readiness inputs, review-routing notes, evidence sufficiency notes, downgrade records, suspension records, withdrawal records, reinstatement records, and archive records;
5. boundary controls, including Grid-not-certification, TRL-not-procurement, readiness-not-financeability, readiness-not-insurability, review-not-public-authority-approval, maturity-not-consent, maturity-not-deployment-authorization, and maturity-not-execution;
6. correction practice, including Grid correction, TRL correction, downgrade, suspension, withdrawal, reinstatement, Registry update, Marketplace update, public-safe correction, handoff correction, archive, and non-continuation.

Grid and TRL Guilds make readiness language disciplined. They do not certify readiness for external action.

### 14.4.18 Handoff Guilds

Handoff Guilds are Nexus communities of practice responsible for lawful handoff logic, handoff dependency categories, handoff package structure, recipient responsibility notices, no-authority-transfer notices, public-good-to-enterprise stack controls, National Consortium Company interfaces, Project SPV interfaces, public authority acting-separately interfaces, provider interfaces, operator interfaces, host interfaces, funder interfaces, insurer interfaces, donor interfaces, university and lab recipient interfaces, community actor interfaces where appropriate, correction propagation, handoff recall, and handoff archive.

Handoff Guilds should preserve the One Rail–Two Stacks doctrine. They should ensure that public-good records can inform separate lawful actors without becoming execution, procurement, finance, insurance, public authority action, consent, deployment authorization, or implementation by implication.

A Handoff Guild Record should identify:

1. handoff practice scope, including handoff candidate identification, dependency mapping, recipient class identification, handoff package assembly, recipient responsibility language, no-authority-transfer language, correction propagation, recall, archive, and non-continuation;
2. handoff candidate objects, including Reports, datasets, software, models, dashboards, Studio workflows, DRI outputs, Observatory outputs, Grid records, TRL records, Registry records, Marketplace records, National Portfolio objects, Nexus Universe outputs, Campaign outputs, Academy objects, and Foundry builds;
3. dependency categories, 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 classes, including National Consortium Companies, Project SPVs, public authorities acting separately, providers, operators, contractors, hosts, universities, labs, communities where appropriate, Indigenous institutions where applicable, funders, insurers, donors, public finance actors, and other lawful recipients;
5. handoff controls, including support status, warranty boundary, reliance boundary, data-use labels, AI-use labels, access limits, secure-room requirements, public-safe status, Registry status, Marketplace status, Grid status, correction history, recall pathway, and archive rule;
6. boundary controls, confirming that handoff context is not certification, warranty, procurement approval, financeability, insurability, public authority action, consent, deployment authorization, implementation authorization, or execution.

Handoff Guilds protect the most sensitive boundary in Nexus: the movement from public-good knowledge to possible separate action. Their role is to make lawful context transferable without transferring authority.

The final Nexus Guilds rule is: Data, AI, Cyber, Privacy, Geospatial, WFEH-B, DRR, DRF, DRI, GRIx, DICE, Public-Safe Reporting, Legal Boundary, Safeguard, Marketplace and Registry, Studio, Grid and TRL, and Handoff Guilds create cross-ecosystem practice coherence. Guilds produce methods, templates, language, review patterns, correction discipline, and capability; they do not become regulators, certifiers, procurers, financiers, insurers, public authorities, consent bodies, deployment authorities, or execution vehicles by implication.

## 14.5 Participation Records

### 14.5.1 Participation Before Authority

Participation Before Authority is the Nexus rule that participation must be recorded before any actor may be treated as having a defined role, pathway, eligibility, standing, access class, contribution status, learning status, review status, support status, or handoff-context relationship within Nexus. Participation creates visibility, accountability, contribution memory, and pathway discipline. It does not create authority by implication.

Participation may occur through National Councils, Helix Councils, National Working Groups, Competence Cells, Foundry Build Teams, Campaign Teams, Studio Rooms, Academy Cohorts, Labs Streams, Risk Agency Expert Panels, Public Authority Learning Rooms, Readiness Rooms, Secure Rooms, Data Rooms, Nexus Universe rooms, Marketplace interactions, Registry pathways, Campaign pathways, Reports pathways, Academy pathways, National Portfolio pathways, or lawful handoff-dependency pathways.

A Participation Record should identify:

1. participant identity or class, subject to privacy, safety, youth, community, protected knowledge, and public-safe controls;
2. participation pathway, including council, helix, working group, competence cell, team, room, cohort, stream, campaign, build, review, learning pathway, portfolio, or Nexus Universe cycle;
3. role class, including learner, contributor, reviewer, steward, maintainer, sponsor, host, provider, public authority learner, capital reader, insurer reader, donor reader, community participant, Indigenous participant where applicable, youth participant, media participant, humanitarian actor, standards-interface actor, or lawful recipient;
4. scope and duration, including object, Docket, portfolio, room, campaign, cohort, build, report, Studio workflow, Registry record, Marketplace listing, Grid input, Nexus Universe output, or handoff-dependency object;
5. access and safeguards, including access class, data-use limits, AI-use limits, confidentiality, public-safe controls, secure-room requirements, protected knowledge restrictions, youth safeguards, community safeguards, Indigenous protocol controls where applicable, and correction pathway;
6. authority boundary, confirming that participation does not create governance authority, public authority action, endorsement, certification, procurement status, finance authority, insurance authority, donor commitment, consent, deployment authorization, or execution authority.

Participation before authority protects Nexus from hidden agency, role collapse, sponsor capture, provider validation, public authority overclaim, community consent overclaim, and handoff overclaim. No participant should be represented as having authority beyond what a separate competent record expressly grants.

### 14.5.2 Contribution Records

Contribution Records document work, knowledge, materials, review, code, data, methods, models, reports, translations, designs, Campaign activity, learning support, Studio support, DRI support, Observatory support, Academy support, Foundry support, safeguard input, public-safe input, or handoff-dependency input contributed to Nexus by a participant, team, institution, sponsor, provider, university, public authority learner, community actor, Indigenous participant where applicable, youth participant, expert panel, or other contributor.

A Contribution Record should identify:

1. contributor and role, including individual, team, institution, Working Group, Competence Cell, provider, university, community actor, public authority learner, expert, sponsor-supported contributor, or other contributor class;
2. contribution object, including data, software, AI object, model, method, report, dashboard, schema, API, learning object, Campaign object, Studio workflow, Observatory signal, DRI indicator, GRIx term, Registry record, Marketplace listing, Grid input, National Portfolio object, Nexus Universe output, or handoff dependency;
3. contribution pathway, including Foundry, Academy, Reports, Campaigns, Studio, Observatory, DRI, GRIx, DICE, Grid, Registry, Marketplace, National Portfolio, Nexus Universe, Labs, public authority learning, readiness, secure room, data room, or handoff pathway;
4. rights and use conditions, including license, attribution, confidentiality, data-use label, AI-use label, public-safe status, IP terms, protected knowledge restrictions, Indigenous protocol controls where applicable, and handoff restrictions;
5. review status, including accepted, accepted with limitations, under review, returned for revision, restricted, rejected, corrected, superseded, withdrawn, recalled, archived, or non-continuing;
6. recognition and proof, including proof receipt, contribution ledger entry, iCRS record where applicable, maintainer record, support record, learning record, or review record;
7. boundary notices, confirming that contribution does not create ownership of Nexus objects, control over public-good pathways, provider validation, sponsor control, certification, public authority action, procurement, finance, insurance, consent, deployment authorization, or execution.

Contribution Records ensure that work is visible, credited where appropriate, reviewable, correctable, and traceable. Contribution is evidence of participation and work; it is not authority over the object or its downstream use.

### 14.5.3 Learning Records

Learning Records document participation in Nexus Academy, Risk Academy, Studio learning, public authority learning, Foundry contributor learning, Campaign learning, DRI learning, GRIx learning, Observatory learning, data governance learning, AI governance learning, cyber learning, privacy learning, public-safe reporting learning, safeguard learning, finance-readiness literacy, insurance-readiness literacy, donor-readiness literacy, public finance learning, handoff-dependency learning, and Nexus Universe learning.

A Learning Record should identify:

1. learner identity or learner class, subject to privacy, youth protection, safety, accessibility, and public-safe controls;
2. learning pathway, including Academy cohort, Risk Academy pathway, Studio Room, public authority learning room, Readiness Room, Campaign pathway, Foundry pathway, Labs pathway, National Working Group pathway, Competence Cell pathway, Nexus Universe room, or handoff-dependency pathway;
3. learning object, including module, Report, dashboard, simulation, digital twin, DRI record, GRIx taxonomy, data-governance lesson, AI-governance lesson, cyber lesson, public-safe reporting lesson, safeguard module, public authority learning object, finance-readiness literacy object, or handoff module;
4. learning status, including registered, participating, completed, reviewed, proof-issued, corrected, expired, superseded, archived, or non-continuing;
5. assessment or reflection record where applicable, including quiz, exercise, Studio scenario, contribution task, review task, public-safe drafting task, project, proof receipt, or competency input;
6. credential boundary, confirming that a Learning Record is not professional licensure, legal qualification, public authority qualification, procurement qualification, finance qualification, insurance qualification, certification, consent authority, deployment authority, or execution authority unless separately issued by a competent body under a separate recorded process.

Learning Records convert knowledge activity into institutional memory. They support capability formation, contributor routing, cohort management, and correction. They do not create external professional authority by default.

### 14.5.4 Review Records

Review Records document the examination of Nexus objects by competent reviewers, teams, guilds, rooms, panels, stewards, or pathways. They show what was reviewed, by whom, against what criteria, with what evidence, what limitations, what decisions within Nexus scope, what corrections, and what downstream restrictions.

Review Records may include 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.

A Review Record should identify:

1. object reviewed, including identifier, version, steward, portfolio relationship, Docket relationship, lifecycle state, Registry status, Marketplace status, support class, and correction state;
2. review type and scope, including what questions were reviewed and what questions were not reviewed;
3. reviewer identity or reviewer class, including team, guild, Competence Cell, expert panel, steward, public-safe reviewer, safeguard reviewer, data steward, AI/cyber/privacy reviewer, public authority boundary reviewer, finance and insurance boundary reviewer, or handoff reviewer;
4. materials considered, including data records, method records, model records, software records, reports, dashboards, public-safe summaries, source records, incident records, correction records, and archive records;
5. review outcome, including approved within scope, approved with conditions, returned for revision, restricted, escalated, suspended, withdrawn, recalled, archived, non-continuing, or referred to separate competent actor;
6. limitations and boundary notices, confirming what the review does not decide, certify, approve, finance, insure, procure, consent to, deploy, or execute;
7. correction pathway, including triggers, required changes, downstream propagation, notification, public repair, recall, archive, and review cadence.

Review Records are evidence of review within scope. They are not universal validation, certification, legal approval, public authority approval, procurement approval, finance approval, insurance approval, consent, deployment authorization, or execution authority by default.

### 14.5.5 Public Authority Learning Records

Public Authority Learning Records document learning-mode participation by public authorities, public-sector actors, regulators, municipalities, public utilities, emergency bodies, public finance actors, public service institutions, or other public institutions. They preserve the distinction between learning and official action.

A Public Authority Learning Record should be created whenever public authority participants engage with Nexus Reports, DRI indicators, Observatory outputs, Studio scenarios, dashboards, National Systems-Risk Maps, National Challenge Briefs, Evidence Need Records, Observatory Need Records, Core Build Requests, Grid inputs, TRL context, National Portfolio objects, Nexus Universe outputs, finance-readiness questions, insurance-readiness questions, public finance learning materials, safeguard records, or handoff dependency records.

A Public Authority Learning Record should identify:

1. public authority participant or class, subject to confidentiality, public-safe, and applicable legal controls;
2. learning context, including room, pathway, Docket, National Portfolio, Nexus Universe cycle, Studio workflow, Report, Observatory output, DRI object, public finance learning pathway, or handoff-dependency pathway;
3. materials reviewed, including object identifiers, versions, access class, public-safe status, Registry status, Marketplace status, Grid or TRL context, correction status, and archive status;
4. questions and observations, clearly marked as learning, context, issue-spotting, evidence need, safeguard concern, public-safe concern, public finance learning question, or handoff dependency;
5. non-decision boundary, confirming that the record is not a public warning, emergency command, regulatory action, permit, license, compliance finding, procurement decision, public finance allocation, policy adoption, official endorsement, deployment authorization, or execution;
6. follow-up pathway, including evidence need, Observatory need, Studio scenario, Report correction, Academy module, public-safe review, safeguard review, public authority boundary review, separate public authority process outside Nexus, archive, or non-continuation;
7. correction pathway, including correction of public authority overclaim, official-status confusion, public-safe language, dashboard interpretation, Report language, Marketplace wording, Registry wording, Nexus Universe materials, and handoff context.

Public Authority Learning Records allow public institutions to participate safely. They protect both the public institution and Nexus from role collapse.

### 14.5.6 Sponsor Support Records

Sponsor Support Records document support provided by sponsors to Nexus public-good activities, including financial support where lawful, in-kind support, venue support, cloud or compute support, platform support, logistics support, communications support, Academy support, Campaign support, Reports support, Foundry support, Studio support, Nexus Universe support, National Node support, data-room support, secure-room support, or other public-good support.

Sponsor Support Records must preserve the support-without-control rule. Sponsorship may be acknowledged only within approved language and must not control agenda, Docket routing, National Portfolio priorities, Reports conclusions, public-safe language, Registry status, Marketplace listing, Grid or TRL outcome, Studio workflow, Campaign claim, public authority learning room, finance-readiness pathway, insurance-readiness pathway, safeguard decision, or handoff routing.

A Sponsor Support Record should identify:

1. sponsor identity and support class, including financial, in-kind, venue, platform, compute, logistics, communications, learning, Campaign, Reports, Foundry, Studio, Nexus Universe, National Node, or other support;
2. supported object or pathway, including Docket, program, campaign, report, room, cohort, build, Nexus Universe cycle, National Portfolio activity, public-safe release, or support ledger entry;
3. recognition terms, including permitted name use, logo use, acknowledgement language, public-safe claims, duration, and correction rules;
4. control prohibitions, including no agenda control, no content control, no review control, no routing control, no Registry status control, no Marketplace control, no Grid control, no public authority influence, no finance-readiness influence, no provider preference, no procurement influence, no handoff control, and no pay-to-influence;
5. access limits, including whether the sponsor receives no access, public access, controlled access, room-based access, or strictly limited access, subject to confidentiality, data-use labels, AI-use labels, and public-safe limits;
6. conflict and anti-capture controls, including disclosure, monitoring, claims review, correction, suspension of recognition, withdrawal, recall, archive, and non-continuation;
7. boundary notices, confirming that sponsorship does not create endorsement, certification, procurement status, financeability, insurability, public authority approval, consent, deployment authorization, or execution authority.

Sponsor Support Records make support transparent and correctable. They protect the public-good stack from capture.

### 14.5.7 Provider Contribution Records

Provider Contribution Records document contributions by technology providers, service providers, infrastructure providers, professional service providers, data providers, software providers, AI providers, cloud providers, telecom providers, cyber providers, geospatial providers, equipment providers, implementation providers, or other technical and enterprise actors.

Provider Contribution Records must preserve the provider-contribution-without-validation rule. A provider may contribute expertise, code, data where lawful, APIs, documentation, test environments, reference implementations, dashboards, models, Studio workflows, Academy content, Reports input, Foundry builds, Nexus Universe demonstrations, or handoff-context clarification. That contribution must not be represented as provider approval, vendor certification, procurement preference, Marketplace endorsement, Grid maturity approval, public authority approval, financeability, insurability, deployment authorization, or execution authority.

A Provider Contribution Record should identify:

1. provider identity and role, including contributor, reviewer, technical steward, maintainer, demonstrator, infrastructure-context actor, data contributor, API contributor, model contributor, software contributor, Studio participant, Academy contributor, Reports contributor, Nexus Universe participant, or lawful recipient;
2. contributed object, including software, dataset, model, API, dashboard, documentation, benchmark, reference implementation, test suite, secure-room workflow, Studio workflow, technical baseline, Report input, or handoff dependency note;
3. rights and restrictions, including IP terms, license, confidentiality, data-use labels, AI-use labels, public-safe status, proprietary information limits, secure-room requirements, and handoff restrictions;
4. review requirements, including code review, security review, dependency review, SBOM, data review, AI review, public-safe review, documentation review, accessibility review, safeguard review, Registry review, Marketplace review, Grid review, and correction review;
5. claims controls, including no provider validation, no vendor certification, no preferred-provider status, no procurement recommendation, no sponsor control, no public authority endorsement, no finance or insurance overclaim, no deployment authorization, and no execution claim;
6. correction and withdrawal, including correction of provider claims, contribution correction, delisting, Registry update, Marketplace correction, withdrawal, recall, archive, and non-continuation.

Provider Contribution Records allow technical capability to enter Nexus without becoming market validation.

### 14.5.8 Community Participation Records

Community Participation Records document participation by communities, local actors, place-based groups, affected stakeholders, community organizations, public-interest groups, youth groups, local institutions, community researchers, local knowledge holders, and other community participants in Nexus pathways.

Community Participation Records should protect dignity, context, language, accessibility, privacy, public-safe communication, non-extraction, protected knowledge, geospatial sensitivity, youth safeguards, health sensitivity, and consent boundaries. A Community Participation Record must not be used to imply community consent, waiver, endorsement, approval, data-use permission, AI-use permission, land access permission, implementation approval, deployment authorization, or execution.

A Community Participation Record should identify:

1. community context, including place, affected system, participation pathway, language needs, accessibility needs, public-safe limits, and privacy protections;
2. participation pathway, including National Council, Community / Indigenous / Diaspora / Place-Based Legitimacy Helix Council, Working Group, Campaign, Academy, Reports review, Studio Room, public-safe review, safeguard review, National Portfolio pathway, Nexus Universe room, or correction pathway;
3. contribution type, including lived-risk knowledge, local context, vulnerability information, resilience priority, public-safe reporting input, Campaign participation, Academy participation, Studio review, safeguard concern, National Portfolio input, Nexus Universe input, or correction request;
4. knowledge and data controls, including what may be recorded, summarized, anonymized, translated, mapped, published, AI-processed, retained, archived, or handed off, and what must remain restricted, protected, deleted, sealed, or returned;
5. public-safe and safeguard controls, including non-extraction, dignity, accessibility, language, community review, geospatial masking, protected knowledge controls, youth safeguards, privacy, and public repair;
6. boundary notices, confirming participation-not-consent, participation-not-endorsement, participation-not-public-authority-action, participation-not-procurement, participation-not-finance, participation-not-insurance, participation-not-deployment, and participation-not-execution;
7. correction pathway, including correction of misrepresentation, harmful publication, consent overclaim, data-use error, AI-use error, geospatial exposure, withdrawal, recall, archive, sealing, deletion where required, and public repair.

Community Participation Records preserve legitimacy only when they protect communities from being converted into evidence without rights.

### 14.5.9 Consent Boundary Records

Consent Boundary Records document the distinction between participation, consultation, engagement, learning, contribution, support, attendance, review, comment, data provision, knowledge sharing, public authority presence, community presence, Indigenous participation where applicable, sponsor support, provider contribution, or handoff discussion and any separate consent, authorization, approval, permission, waiver, access right, implementation permission, deployment authorization, or execution authority.

Consent Boundary Records are required wherever Nexus work could be misread as implying consent. This includes community participation, Indigenous protocol-sensitive contexts where applicable, protected knowledge, data use, AI use, geospatial mapping, youth participation, health-sensitive contexts, public authority-sensitive contexts, land or facility access, handoff packages, Studio demonstrations, Campaigns, Reports, National Portfolio objects, Nexus Universe outputs, and enterprise-interface pathways.

A Consent Boundary Record should identify:

1. context requiring consent discipline, including community, Indigenous, data subject, public authority, institutional, land, facility, knowledge, data, AI, health, youth, geospatial, environmental, or handoff context;
2. activity recorded, including participation, consultation, learning, contribution, review, attendance, support, data-room access, Studio demonstration, Campaign participation, Nexus Universe participation, handoff discussion, or public-safe reporting;
3. what is not consented to, including publication, data reuse, AI use, mapping, translation, transfer, handoff, public authority action, procurement, finance, insurance, deployment, implementation, land access, field work, operational action, or execution unless separately recorded;
4. separate consent pathway if required, including who must decide, under what law, protocol, governance process, institutional authority, ethics process, community process, Indigenous governance process where applicable, data agreement, public authority process, or contract;
5. records and restrictions, including consent-not-obtained, consent-pending, consent-limited, consent-withdrawn, consent-not-required-for-this-limited-use, or consent-held-by-separate-actor, with access limits and use restrictions;
6. correction and withdrawal, including correction of consent overclaim, withdrawal of affected materials, recall, public repair, sealing, deletion, archive, and non-continuation.

Consent Boundary Records are not substitutes for consent. They prevent false consent claims and clarify when separate lawful consent is required.

### 14.5.10 Correction Records

Correction Records document the identification, review, correction, restriction, withdrawal, recall, public repair, archive, or non-continuation of participation-related errors, contribution errors, learning record errors, review record errors, public authority learning overclaims, sponsor support overclaims, provider contribution overclaims, community participation misrepresentations, consent boundary errors, safeguard failures, public-safe communication failures, data-use errors, AI-use errors, access errors, attribution errors, recognition errors, or handoff-context errors.

A Correction Record should identify:

1. affected record, including Participation Record, Contribution Record, Learning Record, Review Record, Public Authority Learning Record, Sponsor Support Record, Provider Contribution Record, Community Participation Record, Consent Boundary Record, support ledger, contribution ledger, proof receipt, iCRS record where applicable, Campaign record, Academy record, Nexus Universe record, or handoff record;
2. correction trigger, including factual error, attribution error, rights error, privacy issue, youth safeguard issue, protected knowledge issue, Indigenous protocol issue where applicable, public authority overclaim, sponsor control overclaim, provider validation overclaim, consent overclaim, finance or insurance overclaim, procurement overclaim, access error, AI-use error, public-safe error, or archive error;
3. severity and scope, including affected participants, communities, institutions, objects, public materials, rooms, portfolios, Nexus Universe outputs, Marketplace listings, Registry records, Grid records, handoff packages, and downstream users;
4. correction action, including metadata correction, role correction, attribution correction, access correction, public-safe correction, claims correction, record restriction, delisting, withdrawal, recall, sealing, deletion where required, public repair, archive, or non-continuation;
5. notification requirements, including participant notice, community notice, Indigenous protocol notice where applicable, public authority learner notice, sponsor notice, provider notice, reviewer notice, recipient notice, public notice, or internal notice;
6. closure and learning, including correction completion, downstream propagation, recurrence-prevention action, archive update, successor record, and review cadence.

Correction Records make participation trustworthy. Nexus participation is not credible because it is error-free; it is credible because errors, overclaims, and boundary failures can be detected, recorded, corrected, repaired, recalled, and archived.

The final Participation Records rule is: participation must be recorded before authority is claimed; contributions, learning, reviews, public authority learning, sponsor support, provider contribution, community participation, and consent boundaries must be traceable; correction records repair errors and overclaims. Participation records create memory, accountability, safeguards, recognition, and correctionability; they never create certification, procurement, finance, insurance, public authority action, consent, deployment, or execution by implication.

## 14.6 Labor, Volunteer, Learning, and Contribution Boundaries

### 14.6.1 Volunteer Work

Volunteer Work is contribution activity undertaken freely by a participant for a defined Nexus public-good purpose without employment, wages, employment benefits, agency authority, execution authority, procurement authority, finance authority, insurance authority, public authority status, deployment authority, or implied right to bind any Nexus institution. Volunteer Work may include Campaign support, translation, public-safe communication support, Academy participation, Reports support, documentation, community outreach, data labeling where lawful and appropriate, review support, event support, Nexus Universe support, Foundry contribution, Studio support, DRI support, Observatory support, accessibility support, and other bounded contribution activity.

Volunteer Work must be structured, recorded, safe, non-extractive, and role-bounded. A Volunteer Work Record should identify the volunteer role, contribution pathway, expected tasks, time expectations where relevant, access class, data-use limits, AI-use limits, supervision or steward contact, public-safe rules, youth safeguards where applicable, community safeguards, confidentiality requirements, expenses or reimbursements if any, recognition rules, correction pathway, withdrawal pathway, and archive rule.

Volunteer Work shall not be used to bypass labor law, procurement law, contracting requirements, public authority staffing rules, professional licensing requirements, safety requirements, data protection duties, or paid work obligations. Where the work is regular, controlled, commercially valuable, safety-sensitive, legally regulated, or functionally equivalent to employee or contractor labor, it must be reviewed and routed to an appropriate lawful work, stipend, contract, internship, fellowship, or employment pathway.

Volunteer Work creates participation and contribution records. It does not create employment, ownership, authority, certification power, public authority action, procurement status, finance status, insurance status, consent, deployment authorization, or execution.

### 14.6.2 Learning Work

Learning Work is activity undertaken primarily for education, capability formation, practice, supervised learning, Academy participation, Risk Academy participation, Studio learning, public authority learning, Foundry contributor learning, Campaign 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, or handoff-dependency literacy.

Learning Work may produce useful outputs, but its primary purpose must remain learning unless separately converted into a contribution, bounty, stipend, contract, employment, or handoff pathway. A Learning Work Record should identify the learning pathway, learning objective, learner class, learning materials, exercises, expected outputs, review status, proof receipt where applicable, micro-credential input where applicable, public-safe limits, access controls, youth safeguards where applicable, correction pathway, and credential boundary.

Learning Work shall not be represented as professional certification, public authority qualification, procurement qualification, finance qualification, insurance qualification, licensure, employment, contractor status, implementation authority, or execution authority unless a separate competent body issues such status through a separate lawful process.

Learning Work may support contribution readiness. It does not itself create authority to approve, certify, procure, finance, insure, consent, deploy, or execute.

### 14.6.3 Bounty-Supported Work

Bounty-Supported Work is task-specific contribution work supported by a defined bounty, prize, reward, recognition, challenge support, or completion-based support mechanism within Nexus Foundry, Campaigns, Academy, Reports, Studio, Registry, Marketplace, Grid, DRI, Observatory, Nexus Universe, or National Portfolio pathways. Bounty-Supported Work should be used for clearly scoped tasks, such as documentation, translation, data cleaning where lawful, issue resolution, software patches, template creation, public-safe summaries, accessibility improvements, test cases, dashboards, review-support artifacts, or defined build tasks.

A Bounty-Supported Work Record should identify the bounty sponsor or support source where applicable, task scope, deliverable, eligibility rules, review criteria, acceptance criteria, payment or reward terms where lawful, tax or reporting notes where required, IP and license terms, data-use limits, AI-use limits, confidentiality, public-safe requirements, conflict controls, correction obligations, and archive rule.

Bounty-Supported Work shall not be used to disguise employment, avoid procurement, evade contracting controls, create uncontrolled work direction, or obtain sensitive work without proper room controls. Tasks involving restricted data, protected knowledge, public authority-sensitive materials, cyber-sensitive systems, health-sensitive data, youth data, Indigenous protocol-sensitive materials where applicable, or handoff-recipient-only materials must be routed through appropriate secure-room, data-room, review, and safeguard pathways.

Bounty completion does not create employment, procurement status, vendor validation, certification, financeability, insurability, public authority approval, consent, deployment authorization, or execution. It creates a contribution record and, where accepted, a bounded output record.

### 14.6.4 Stipend-Supported Work

Stipend-Supported Work is limited support provided to enable participation, learning, research, public-interest contribution, community participation, youth participation, fellowship activity, travel, access, accessibility, translation, local engagement, public-safe reporting, or bounded public-good work without converting the participant into an employee, contractor, agent, officer, public authority representative, procurement actor, finance actor, insurer, certifier, or execution actor by implication.

A Stipend-Supported Work Record should identify the stipend purpose, support source, participant class, eligibility basis, permitted work or learning pathway, duration, expected outputs if any, non-employment status, expenses or support categories, tax or reporting conditions where required, conflict controls, public-safe obligations, data-use limits, AI-use limits, safeguard requirements, correction pathway, and archive rule.

Stipend support must be especially careful where communities, youth, students, public-interest actors, Indigenous participants where applicable, vulnerable groups, or public authority learners are involved. Support must not be coercive, extractive, pay-for-consent, pay-for-endorsement, pay-for-public authority influence, pay-for-procurement, pay-for-routing, pay-for-claims, or pay-for-handoff.

Stipend-Supported Work supports participation and capability. It does not purchase consent, create employment, create contractor status by implication, create sponsor control, create provider validation, create procurement preference, create finance or insurance status, authorize public authority action, authorize deployment, or execute work.

### 14.6.5 Contracted Work

Contracted Work is work performed under a separate written agreement, purchase order, statement of work, consulting agreement, service agreement, employment agreement, grant agreement, fellowship agreement, research agreement, data agreement, sponsorship agreement, or other lawful instrument that defines scope, obligations, compensation, IP, confidentiality, data protection, liability, deliverables, review, termination, correction, and archive requirements.

Contracted Work must be separated from ordinary participation, volunteering, learning, sponsorship, provider contribution, public authority learning, community participation, and handoff discussion. Where a person or institution is contracted to perform work, the applicable contract governs the work scope. Nexus participation records may reference the contract pathway, but they must not replace the contract.

A Contracted Work Record should identify:

1. the contracting parties or responsible institutional pathway;
2. the contract type and scope;
3. deliverables and acceptance process;
4. payment or support terms;
5. IP, license, confidentiality, data-use, AI-use, cybersecurity, privacy, and public-safe requirements;
6. safeguard requirements, including community, Indigenous protocol where applicable, youth, health, accessibility, protected knowledge, geospatial, and infrastructure-sensitive controls;
7. conflicts, anti-capture, procurement-neutrality, sponsor-control, and provider-validation controls;
8. correction, withdrawal, recall, handoff, termination, and archive obligations.

Contracted Work may produce Nexus public-good objects or enterprise-interface objects depending on the contract and pathway. It must not blur public-good and enterprise-stack roles. Contracted Work does not itself create certification, public authority action, procurement award, finance approval, insurance approval, consent, deployment authorization, or execution beyond the lawful contract scope and the competent actor’s own authority.

### 14.6.6 Sponsored Work

Sponsored Work is work supported by sponsor resources, including funding, venue, infrastructure, compute, cloud credits, data-room support, logistics, communications, Academy support, Campaign support, Nexus Universe support, Reports support, Foundry support, Studio support, National Node support, or other in-kind support, while remaining governed by Nexus public-good controls.

Sponsored Work must preserve sponsor support without sponsor control. Sponsor support shall not determine Docket priority, National Portfolio priority, public-safe conclusions, Report findings, Studio outputs, Registry status, Marketplace listing, Grid or TRL status, Campaign claims, public authority learning outcomes, finance-readiness pathway, insurance-readiness pathway, provider selection, handoff routing, or correction decisions.

A Sponsored Work Record should identify the sponsor, support type, supported pathway, permitted recognition, prohibited influence, conflict controls, access limits, data-use and AI-use limits, confidentiality, claims controls, public-safe requirements, safeguard requirements, correction pathway, withdrawal or suspension conditions, and archive treatment.

Sponsored Work shall not become paid influence, pay-to-route, pay-to-rank, pay-to-certify, pay-to-procure, pay-to-finance, pay-to-insure, pay-to-endorse, pay-to-consent, pay-to-deploy, or pay-to-execute. Sponsor support may enable public-good work; it cannot own, direct, validate, certify, or command it.

### 14.6.7 Public Authority Learning Work

Public Authority Learning Work is work undertaken with, for, or around public authority learning pathways, including learning questions, evidence review, DRI interpretation, Observatory review, Studio scenarios, Reports review, public-safe reporting, data governance learning, AI governance learning, cyber learning, WFEH-B learning, public finance learning, procurement-boundary learning, emergency-language discipline, regulatory-context learning, National Portfolio review, Nexus Universe rooms, and handoff-dependency understanding.

Public Authority Learning Work must be recorded as learning unless a competent public authority separately creates an official decision, contract, procurement, grant, policy, regulatory act, public finance allocation, emergency command, permit, license, approval, or other lawful public authority action through its own process.

A Public Authority Learning Work Record should identify the public authority participant class, learning purpose, materials reviewed, questions raised, outputs produced, non-decision status, non-warning status, non-command status, non-regulatory status, non-procurement status, non-public-finance status, non-policy status, non-endorsement status, correction pathway, and archive rule.

Public Authority Learning Work is not shadow government work. It must not be used to outsource public authority decisions to Nexus, to create unofficial procurement, to imply public approval, to bypass statutory processes, to create public warnings, to allocate public funds, or to direct implementation.

### 14.6.8 No Disguised Labor

No Disguised Labor is the rule that Nexus participation, volunteering, learning, bounty work, stipend support, sponsorship, provider contribution, community participation, youth participation, public-interest contribution, or public authority learning shall not be used to obtain labor under a misleading label or to avoid applicable labor, employment, contractor, procurement, safety, tax, benefits, immigration, human-subjects, ethics, data-protection, or professional obligations.

A disguised-labor review should be triggered where work is recurring, controlled, required, economically dependent, commercially valuable, time-intensive, safety-sensitive, legally regulated, assigned with employee-like supervision, performed for enterprise-stack benefit, performed under sponsor or provider direction, or necessary for execution rather than public-good learning or contribution.

Where disguised labor risk exists, the work must be paused, reviewed, reclassified, contracted, compensated, reduced, converted to learning, converted to volunteer-safe activity, routed to a lawful employer or contractor pathway, or discontinued. The review record should identify the work, participants, control level, expected value, legal and institutional pathway, compensation or support status, rights and safeguards, correction action, and archive treatment.

No Disguised Labor protects contributors and Nexus legitimacy. Public-good mission does not excuse extractive work design.

### 14.6.9 No Employment by Implication

No Employment by Implication is the rule that participation in Nexus as a volunteer, learner, contributor, reviewer, council participant, Working Group member, Competence Cell participant, Campaign participant, Academy cohort member, Studio participant, Nexus Universe participant, Labs participant, expert panel participant, public authority learner, sponsor-supported participant, provider contributor, community participant, youth participant, or handoff-context participant does not create employment unless a separate lawful employment relationship is expressly recorded.

Nexus participation records should not use language that implies employment where none exists. Titles, badges, proof receipts, learning records, contribution records, campaign roles, maintainer labels, reviewer labels, ambassador labels, fellow labels, or cohort labels must be carefully framed so they do not imply wages, benefits, authority to bind, employment protections, payroll status, employer control, or agency authority unless separately established.

A No Employment by Implication Record or notice should clarify:

1. participation role and scope;
2. whether the person is volunteer, learner, contributor, contractor, employee, stipend-supported participant, bounty participant, fellow, intern, or other defined class;
3. whether compensation, stipend, bounty, reimbursement, or support applies;
4. access and confidentiality obligations;
5. ownership and license terms for contributions;
6. supervision and review pathway;
7. withdrawal and correction pathway;
8. explicit statement that no employment is created absent a separate written employment agreement.

No Employment by Implication does not reduce duties to treat participants fairly, safely, lawfully, and respectfully. It prevents role confusion while preserving contributor protection.

### 14.6.10 No Execution by Contribution

No Execution by Contribution is the rule that a contribution to Nexus does not execute a project, deploy a system, approve an intervention, authorize implementation, complete procurement, create finance, bind insurance, grant public authority action, create consent, operate infrastructure, direct field activity, or transfer authority to an enterprise actor by implication.

A contribution may produce a draft, dataset, report, dashboard, code object, model, simulation, Studio workflow, Campaign object, Academy module, Registry record, Marketplace listing, Grid input, TRL context, National Portfolio object, Nexus Universe output, or handoff-dependency note. Each remains governed by its own lifecycle state, review status, public-safe status, support class, correction pathway, archive rule, and boundary notices.

No Execution by Contribution requires that contribution records, bounty records, stipend records, volunteer records, provider contribution records, sponsor support records, community participation records, public authority learning records, and handoff records state that:

1. contribution is not approval;
2. contribution is not certification;
3. contribution is not procurement;
4. contribution is not finance;
5. contribution is not insurance;
6. contribution is not public authority action;
7. contribution is not consent;
8. contribution is not deployment authorization;
9. contribution is not operational command;
10. contribution is not execution.

Where a contribution is later used by a separate competent actor, that actor must conduct its own legal, technical, operational, procurement, finance, insurance, public authority, safeguard, consent, deployment, and execution review. Nexus contribution may inform action; it does not perform it.

The final Labor, Volunteer, Learning, and Contribution Boundaries rule is: Volunteer Work, Learning Work, Bounty-Supported Work, Stipend-Supported Work, Contracted Work, Sponsored Work, and Public Authority Learning Work must be classified honestly, recorded clearly, safeguarded properly, and corrected when misclassified. Nexus shall not use disguised labor, imply employment without a separate lawful relationship, or allow contribution to become execution by implication. Work records create participation, learning, contribution, support, review, and correction memory; they do not create certification, procurement, finance, insurance, public authority action, consent, deployment, or execution unless a separate competent actor lawfully acts through its own recorded process.

<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/xiv.-people.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.