# VI. PEOPLE

Nexus Agile Framework People defines the **NAF people and participation model** for public-good systems delivery. This section explains how **individual contributors, teams, squads, guilds, national working groups, competence cells, studio rooms, academy cohorts, expert panels, and public authority learning rooms** participate in governed work.

This section sets the operating rules for **whole-of-society participation**, **team topologies**, **guild practice**, **national working groups**, **competence cells**, **participation records**, and **labor, volunteer, learning, and contribution boundaries**. It helps Nexus mobilize people, capability, and contribution while preserving role separation, non-execution, public-safe discipline, and no employment or authority by implication.

### What this section covers

* **Participation architecture** - Defines how people, teams, rooms, and work units engage in NAF.
* **Capability structures** - Explains guilds, working groups, competence cells, and team topologies.
* **Boundary discipline** - Defines participation records, labor rules, volunteer safeguards, and no-execution controls.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview, [I. FOUNDATIONS](/organization/operations/frameworks/nexus-agile-framework-naf/i.-foundations.md) for constitutional rules, [IV. LIFECYCLE](/organization/operations/frameworks/nexus-agile-framework-naf/iv.-lifecycle.md) for work movement, and [V. PORTFOLIOS](/organization/operations/frameworks/nexus-agile-framework-naf/v.-portfolios.md) for strategy and portfolio governance.

## 6.1 Nexus Work Unit Taxonomy

### 6.1.1 Individual Contributors.

6.1.1.1 Individual Contributors are persons who participate in NAF work through learning, research, drafting, review, data stewardship, software contribution, public-safe reporting, Campaign support, Studio participation, Nexus Foundry quests, bounties, builds, National Working Group tasks, Competence Cell tasks, Academy pathways, Risk Academy pathways, Risk Agency expert support, Marketplace or Registry object work, Grid or TRL evidence support, Nexus Universe preparation, correction, archive, or lawful handoff dependency work.

6.1.1.2 Individual Contributors may include students, youth participants where permitted, researchers, engineers, data stewards, AI reviewers, cyber reviewers, public-safe writers, designers, community participants, Indigenous participants where applicable, domain experts, public authority learning participants, mentors, maintainers, translators, accessibility contributors, legal-boundary reviewers, safeguard reviewers, and other qualified or supervised persons. Their participation shall be recorded by role, scope, contribution, review status where applicable, learning status where applicable, support class, conflict status where applicable, data and confidentiality obligations, public-safe obligations, correction pathway, and archive rule.

6.1.1.3 Individual contribution shall not create employment, agency, authority, certification, professional license, public authority status, procurement qualification, provider validation, sponsor endorsement, community consent, Indigenous consent, deployment authorization, or execution authority by implication. Individual Contributors act within recorded role boundaries and shall not represent Nexus, NAF, GCRI, The Global Risks Forum (GRF), The Global Risks Alliance (GRA), any Nexus Consortium, public authority, National Consortium Company, Project SPV, provider, sponsor, host, or lawful handoff recipient unless separately authorized in writing.

### 6.1.2 Teams.

6.1.2.1 Teams are bounded groups formed to complete defined NAF work within a Docket, backlog, portfolio, pillar, mechanism, National Portfolio, Nexus Universe cycle, Foundry build, Campaign, Academy pathway, Labs stream, Studio workflow, Reports production process, Registry update, Marketplace listing process, Grid input, TRL note, correction task, archive task, or handoff dependency package.

6.1.2.2 Each Team shall have a recorded purpose, scope, steward, members, roles, workplan, Docket reference, review requirements, release class, data-use label, AI-use label, public-safe status, safeguard status, support class, labor boundary status, conflict controls, correction pathway, and archive rule. A Team may be temporary, cycle-based, project-based, national, regional, global, thematic, sectoral, technology-specific, public authority learning-focused, or handoff-dependency-focused.

6.1.2.3 Team formation shall not create authority to approve, certify, procure, finance, insure, issue public warnings, grant consent, deploy, operate, command, or execute. Team outputs shall move through NAF review, release, Registry, Marketplace, Reports, Studio, Grid, TRL, Nexus Universe, national continuation, handoff, correction, and archive pathways only as recorded.

### 6.1.3 Squads.

6.1.3.1 Squads are small, focused, time-bound work units formed to address narrow Docket items, build tasks, Campaign tasks, research tasks, data tasks, software tasks, public-safe reporting tasks, Studio tasks, Academy tasks, Registry tasks, Marketplace tasks, Grid tasks, TRL tasks, correction tasks, or handoff dependency tasks. Squads are designed for speed with control, not speed without governance.

6.1.3.2 A Squad shall have a defined output, Docket reference, steward or lead, participant list, review pathway, support class, release expectation, dependencies, public-safe status, data and AI labels, safeguard classification, and correction pathway. Squads may be nested within Teams, National Working Groups, Competence Cells, Foundry programs, Campaign teams, Academy cohorts, Labs streams, Studio rooms, or Nexus Universe Core Build environments.

6.1.3.3 Squad work shall remain bounded by NAF lifecycle controls. A Squad may produce evidence, drafts, software, data objects, dashboards, cards, notes, methods, summaries, or dependency records, but shall not create approval, certification, procurement preference, financeability, insurance approval, public authority action, consent, deployment authorization, or execution.

### 6.1.4 Guilds.

6.1.4.1 Guilds are cross-cutting communities of practice that maintain methods, quality, terminology, reviewer capacity, contributor capacity, public-safe discipline, technical practice, data practice, AI practice, cyber practice, privacy practice, safeguard practice, legal-boundary practice, Studio practice, Grid and TRL practice, Marketplace and Registry practice, Reports practice, DICE practice, GRIx practice, DRI practice, Observatory practice, and handoff practice across NAF.

6.1.4.2 Guilds may advise, review, train, template, maintain, correct, localize, and improve NAF practices within their scope. Guilds shall record their membership or participant class, steward, scope, methods, outputs, review authorities if any, conflicts, public-safe duties, sponsor and provider controls, contribution rules, correction pathway, and archive rule.

6.1.4.3 Guild standing shall not constitute professional license, certification authority, public authority status, procurement authority, finance authority, insurance authority, employment status, provider validation authority, sponsor approval authority, consent authority, deployment authority, or execution authority. Guilds preserve competence and discipline; they do not replace competent authorities.

### 6.1.5 National Working Groups.

6.1.5.1 National Working Groups are country-level NAF work units formed to convert National Portfolio priorities into structured workplans, evidence needs, learning needs, Campaign pathways, Foundry tasks, Reports, Studio workflows, DICE objects, GRIx mappings, DRI inputs, Observatory needs, Marketplace and Registry objects, Grid inputs, TRL notes, Nexus Universe preparation records, public authority learning records, safeguard records, and handoff dependency records.

6.1.5.2 National Working Groups shall operate under national ownership before local delivery. They shall be formed through appropriate national pathways and shall preserve national context, legal context, public authority boundaries, data sovereignty, language and localization, community safeguards, Indigenous protocols where applicable, provider neutrality, sponsor boundaries, capital-reader boundaries, procurement neutrality, finance-readiness boundaries, and correctionability.

6.1.5.3 National Working Group participation shall not create government appointment, public authority approval, procurement role, finance role, insurance role, certification role, national endorsement, consent, project authorization, deployment authorization, or execution authority. National Working Groups produce records, evidence, learning, workplans, and routing context.

### 6.1.6 Competence Cells.

6.1.6.1 Nexus Competence Cells are applied capability units that convert learning, expertise, domain knowledge, technical skill, public-good production, and national priorities into evidence-bearing outputs. Competence Cells may be organized by domain, technology, sector, hazard, geography, national priority, Nexus mechanism, Nexus pillar, WFEH-B system, DRR/DRF/DRI theme, data commons, AI, cyber, geospatial, public-safe reporting, Studio workflow, Grid/TRL review, Campaign, Foundry build, or lawful handoff dependency.

6.1.6.2 Competence Cells shall create structured workplans, evidence outputs, learning outputs, Foundry outputs, Studio outputs, Reports outputs, Registry records, Marketplace objects, Grid inputs, TRL notes, Campaign support records, National Portfolio records, Nexus Universe preparation records, handoff dependency records, correction records, and archive records.

6.1.6.3 Competence Cells shall be bounded by non-execution. A Cell may strengthen capability, but Cell status shall not create employment, certification, professional license, provider validation, procurement qualification, public authority approval, financeability, insurance approval, community consent, Indigenous consent, deployment authorization, or execution.

### 6.1.7 Foundry Build Teams.

6.1.7.1 Foundry Build Teams are Teams or Squads formed within Nexus Foundry and BuildGrid to produce public-good outputs, including software, data pipelines, dashboards, APIs, notebooks, reference implementations, open technical baselines, reports, public-safe summaries, Studio workflows, Registry records, Marketplace objects, Grid inputs, TRL notes, Campaign assets, National Portfolio objects, Nexus Universe Core Build outputs, and lawful handoff dependency packages.

6.1.7.2 Foundry Build Teams shall operate with recorded scope, build brief, acceptance criteria, maintainer assignment, reviewer requirements, contributor rules, labor boundary notices, support class, release class, security review, data and AI labels, public-safe status, safeguard status, repository status where applicable, correction pathway, and archive rule.

6.1.7.3 Foundry Build Team completion shall not imply deployment readiness, product certification, warranty, procurement status, provider approval, investment readiness, insurance approval, public authority approval, consent, or execution. Foundry builds create public-good objects and handoff context, not implementation authority.

### 6.1.8 Campaign Teams.

6.1.8.1 Campaign Teams are work units formed to design, operate, moderate, support, review, correct, and archive Nexus Campaigns. Campaign Teams may manage public-safe messages, signature tools, pledge tools, support tools, volunteer pathways, team and chapter formation, ambassador pathways, Campaign dashboards, Campaign Reports, Campaign-to-Academy routing, Campaign-to-Foundry routing, Campaign-to-National Portfolio routing, Campaign-to-Nexus Universe routing, and Campaign correction records.

6.1.8.2 Campaign Teams shall operate under claims discipline, trust and safety controls, data protection, youth safeguards where applicable, community consent boundaries, Indigenous protocol boundaries where applicable, sponsor controls, provider controls, support ledger discipline, fraud controls, public-safe reporting controls, correction pathways, and archive rules.

6.1.8.3 Campaign Team activity shall not create public mandate, vote, public authority action, community consent, Indigenous consent, donor commitment, finance commitment, procurement commitment, employment, deployment authorization, or execution authority.

### 6.1.9 Studio Rooms.

6.1.9.1 Studio Rooms are controlled environments used for scenarios, simulations, dashboards, digital twins, AI workflow review, public authority learning, readiness review, capital-reader learning, insurance-reader learning, donor-reader learning, public finance learning, data-room workflows, secure-room workflows, Nexus Universe workflows, handoff demonstrations, and public-safe output review.

6.1.9.2 Studio Rooms shall have recorded room class, purpose, participants, access controls, role permissions, data classification, AI-use labels, no-write-back rules, no-command rules, output review rules, logging, public-safe restrictions, safeguard controls, shutdown triggers, correction triggers, and archive rules.

6.1.9.3 Participation in a Studio Room shall not create public authority action, finance approval, insurance approval, donor commitment, procurement decision, technical certification, public warning, operational command, deployment authorization, or execution. Studio Rooms support controlled learning and review.

### 6.1.10 Academy Cohorts.

6.1.10.1 Academy Cohorts are groups of learners, contributors, mentors, reviewers, public authority learning participants, youth participants where permitted, professionals, students, workers, community participants, or other participants engaged in Nexus Academy, Risk Academy, Work-Integrated Learning Paths, micro-credentials where applicable, public-safe reporting training, Foundry contributor pathways, Campaign pathways, Studio practice, data and AI literacy, cyber literacy, safeguard training, or handoff literacy.

6.1.10.2 Academy Cohorts shall record learning pathway, competency scope, mentor roles, assessment or evidence basis where applicable, learner data protections, accessibility needs, language and localization, youth safeguards where applicable, sponsor/provider controls, public-safe duties, credential boundaries, correction rights, withdrawal rights, and archive rules.

6.1.10.3 Cohort participation, course completion, micro-credential completion, WILP participation, or learning record display shall not create professional license, employment status, wage entitlement, immigration status, procurement qualification, public authority competence certification, deployment authorization, or execution authority.

### 6.1.11 Labs Streams.

6.1.11.1 Labs Streams are research-oriented work streams used to explore, define, test, evaluate, translate, or document research questions, evidence gaps, methods, testbeds, datasets, models, benchmarks, scenarios, public-safe summaries, research impact notes, research-to-Foundry transfer records, research-to-Reports pathways, research-to-Studio pathways, and research-to-handoff context.

6.1.11.2 Labs Streams shall operate with research ethics controls, data rights review, AI-use controls, cyber controls, public-safe publication controls, protected knowledge controls, community safeguards, Indigenous protocol controls where applicable, public authority boundaries, sponsor/provider controls, dual-use controls, correction pathways, and archive rules.

6.1.11.3 Labs Stream outputs shall not be treated as approval, certification, public authority decision, financeability, insurance approval, procurement status, deployment authorization, or execution unless separately and lawfully determined by competent actors outside NAF’s default posture.

### 6.1.12 Risk Agency Expert Panels.

6.1.12.1 Risk Agency Expert Panels are groups of experts formed to support risk interpretation, systems resilience advisory, public-safe reporting support, public authority learning, finance-readiness literacy, insurance-readiness literacy, safeguard review, scenario interpretation, crisis-learning, after-action learning, digital trust, data, AI, cyber, privacy, and handoff dependency support.

6.1.12.2 Expert Panels shall record panel scope, expert roles, standing, conflicts, confidentiality duties, reliance labels, output class, review status, public-safe status, finance/insurance/procurement boundary notices, public authority boundary notices, correction pathway, and archive rule.

6.1.12.3 Expert Panel participation shall not create professional license confirmation, certification authority, public authority approval, investment advice, insurance underwriting, procurement advice, consent, deployment authorization, or execution. Expert outputs shall be bounded by recorded scope and reliance status.

### 6.1.13 Public Authority Learning Rooms.

6.1.13.1 Public Authority Learning Rooms are non-decision environments in which public authorities may examine evidence, scenarios, Reports, dashboards, DRI records, Observatory signals, Studio workflows, National Portfolio records, standards-interface questions, public-safe reporting, finance-readiness questions, insurance-readiness questions, public finance learning questions, or lawful handoff dependencies.

6.1.13.2 Public Authority Learning Rooms shall record public authority participants, learning purpose, non-decision status, materials reviewed, room rules, data status, public-safe status, confidentiality obligations, public authority boundary notices, unresolved questions, correction pathway, and archive rule.

6.1.13.3 Public Authority Learning Room participation shall not create official action, policy adoption, regulatory approval, permit, license, public finance allocation, procurement decision, public warning, emergency command, consent, deployment authorization, or execution.

### 6.1.14 Readiness Rooms.

6.1.14.1 Readiness Rooms are controlled review environments used to examine evidence readiness, data readiness, technical readiness, public-safe readiness, safeguard readiness, national readiness, Universe readiness, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, Grid inputs, TRL notes, and handoff dependency clarity.

6.1.14.2 Readiness Rooms shall be no-reliance, non-advisory where applicable, non-soliciting where applicable, non-transactional where applicable, competition-compliant, confidentiality-aware, and regulated-perimeter controlled. They shall record participants, scope, materials, questions, limitations, boundary notices, unresolved dependencies, correction pathway, and archive rule.

6.1.14.3 Readiness Room participation or output shall not create investment advice, finance approval, insurance approval, donor commitment, public finance allocation, procurement status, certification, public authority approval, bankability, financeability, insurability, deployment authorization, or execution.

### 6.1.15 Secure Rooms and Data Rooms.

6.1.15.1 Secure Rooms and Data Rooms are controlled access environments for restricted data, sensitive evidence, protected knowledge, cyber-sensitive records, infrastructure-sensitive records, geospatial-sensitive records, public authority-sensitive materials, health-sensitive data, youth data, community-sensitive materials, Indigenous protocol-sensitive materials where applicable, finance-readiness materials, insurance-readiness materials, handoff-recipient-only materials, and other controlled objects.

6.1.15.2 Secure Rooms and Data Rooms shall include approved users, approved purposes, no-download controls where appropriate, compute-to-data controls where appropriate, output review, logging, access recertification, confidentiality terms, data-use labels, AI-use labels, public-safe transformation rules, incident response, correction, sealing, deletion where applicable, and archive rules.

6.1.15.3 Access to Secure Rooms or Data Rooms shall not create data rights, AI training permission, public authority approval, finance approval, insurance approval, procurement status, handoff permission, consent, deployment authorization, or execution.

## 6.2 Whole-of-Society Participation Architecture

### 6.2.1 Public Authorities.

6.2.1.1 Public Authorities may participate in NAF through public authority learning, policy intelligence, evidence review, Studio Rooms, Readiness Rooms, Nexus Universe arenas, National Portfolios, National Working Groups where appropriate, Reports review, DRI interpretation, Observatory interpretation, Academy learning, Campaign observation, standards-interface dialogue, and lawful handoff dependency review.

6.2.1.2 Public Authority participation shall be recorded by role, purpose, jurisdiction, non-decision status unless otherwise separately recorded, materials reviewed, public-safe status, data conditions, confidentiality conditions, unresolved questions, boundary notices, correction pathway, and archive rule.

6.2.1.3 Public Authority participation shall not imply official approval, endorsement, regulatory action, public finance allocation, procurement decision, public warning, emergency command, permit, license, certification, consent, deployment authorization, or execution unless separately and lawfully recorded by the competent public authority through its own process.

### 6.2.2 Universities and Research Bodies.

6.2.2.1 Universities and Research Bodies may participate through research, teaching, Nexus Academy, Risk Academy, Labs Streams, data stewardship, methods development, peer review, student participation, WILPs, public-safe Reports, Foundry builds, Studio workflows, National Portfolios, Nexus Universe, and standards-interface work.

6.2.2.2 Their participation shall preserve academic freedom, research integrity, ethics review where required, data rights, intellectual property rules, publication controls, public-safe reporting, student protections, conflict disclosure, sponsor and provider controls, correctionability, and archive discipline.

6.2.2.3 University or research participation shall not create endorsement, certification, public authority approval, procurement recommendation, financeability, insurance approval, deployment authorization, or execution. Research participation does not by itself validate a project, provider, sponsor, or technology.

### 6.2.3 Industry and Enterprise Actors.

6.2.3.1 Industry and Enterprise Actors may participate as providers, technical contributors, hosts, employers, WILP hosts, domain contributors, data contributors, Foundry contributors, Marketplace participants, Registry record subjects, Studio participants, Campaign supporters, Nexus Universe participants, National Portfolio contributors, or lawful handoff recipients.

6.2.3.2 Industry and Enterprise participation shall be governed by provider-neutrality, sponsor-boundary, procurement-neutrality, competition, confidentiality, data protection, public-safe claims, conflict disclosure, support class, contribution records, correction pathways, and no-validation rules.

6.2.3.3 Industry participation shall not create provider validation, preferred supplier status, procurement advantage, certification, financeability, insurance approval, public authority approval, community consent, Indigenous consent, deployment authorization, or execution.

### 6.2.4 Capital, Insurance, Donor, and Public Finance Readers.

6.2.4.1 Capital, Insurance, Donor, and Public Finance Readers may participate to understand public-good records, National Portfolios, disaster-risk finance questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, diligence gaps, assumptions, dependencies, safeguard conditions, and lawful handoff context.

6.2.4.2 Their participation shall be no-reliance, non-soliciting, non-transactional, competition-compliant, confidentiality-aware, and regulated-perimeter controlled where applicable. Records shall distinguish reading, learning, and questioning from investment, underwriting, donation, grant, guarantee, lending, allocation, procurement, or transaction.

6.2.4.3 Capital-reader, insurer, donor, or public finance presence shall not imply investment interest, capital commitment, underwriting, insurance approval, donor commitment, public finance allocation, bankability, financeability, insurability, rating, public authority approval, procurement status, or execution.

### 6.2.5 Civil Society and Public-Interest Actors.

6.2.5.1 Civil Society and Public-Interest Actors may participate through Campaigns, National Councils, National Working Groups, Competence Cells, public-safe reporting, community safeguards, Academy pathways, Reports review, Studio discussions, Nexus Universe arenas, DRI interpretation, Observatory interpretation, accessibility review, rights review, humanitarian sensitivity, and correction processes.

6.2.5.2 Their participation shall be treated as substantive public-interest participation, not symbolic presence. It shall be structured, non-extractive, respectful, recorded, safeguarded, accessible, and correctionable.

6.2.5.3 Civil society participation shall not automatically create public consent, community consent, Indigenous consent, public authority approval, endorsement, implementation authorization, or execution.

### 6.2.6 Communities.

6.2.6.1 Communities may participate by contributing lived-risk knowledge, local context, vulnerability information, resilience priorities, safeguard concerns, accessibility needs, public-safe reporting input, Campaign participation, Studio learning, National Portfolio input, Observatory needs, DRI interpretation, Academy pathways, and correction requests.

6.2.6.2 Community participation shall be non-extractive and shall preserve dignity, rights, privacy, protected knowledge, data rights, local context, language access, accessibility, and community-facing correction. Community participation records shall identify participation scope and consent boundaries.

6.2.6.3 Community participation shall not equal consent, approval, endorsement, land access permission, project authorization, data permission beyond the recorded scope, deployment approval, or execution authority.

### 6.2.7 Indigenous Participants Where Applicable.

6.2.7.1 Indigenous Participants may participate where relevant through national or local pathways, community protocols, protected knowledge rules, public-safe reporting input, safeguard review, National Portfolios, Campaigns, Academy pathways, Studio Rooms, Nexus Universe rooms, DRI interpretation, Observatory needs, and correction pathways.

6.2.7.2 Participation involving Indigenous peoples, knowledge, lands, waters, territories, cultural heritage, sacred sites, ecological knowledge, protected species information, or community-sensitive context shall be governed by applicable Indigenous protocols, protected knowledge controls, non-extractive practice, data sovereignty where applicable, permission records, public-safe transformation, and community-facing correction.

6.2.7.3 Indigenous participation shall not imply Indigenous consent, community consent, approval, endorsement, knowledge-use permission, land access, data rights, benefit-sharing agreement, project authorization, deployment authorization, or execution unless separately and lawfully recorded through appropriate processes.

### 6.2.8 Youth and Students.

6.2.8.1 Youth and Students may participate through Academy Cohorts, Risk Academy, Campaigns, supervised Foundry tasks, WILPs, learning quests, public-safe reporting exercises, Studio exercises, Competence Cells, National Working Groups where appropriate, Nexus Universe youth pathways, and contribution recognition systems.

6.2.8.2 Youth and Student participation shall be governed by learner safeguards, youth protection, mentor supervision, privacy, data minimization, consent and permission where required, safe workload rules, anti-exploitation controls, accessibility, correction rights, and archive rules.

6.2.8.3 Youth or Student participation shall not create employment, unpaid labor substitution, professional qualification, procurement qualification, public authority status, deployment authority, or execution responsibility.

### 6.2.9 Media and Public Narrative Actors.

6.2.9.1 Media and Public Narrative Actors may participate in public-safe reporting, public narrative, public education, Campaign communication, Nexus Universe visibility, Reports dissemination, stakeholder formation, and correction notices.

6.2.9.2 Their participation shall be governed by public-safe communications, claims discipline, no-warning language where applicable, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-execution language, sponsor and provider controls, protected knowledge restrictions, data restrictions, and correction pathways.

6.2.9.3 Media visibility shall not create legitimacy by itself, endorsement, public authority approval, public warning, certification, financeability, procurement status, consent, deployment authorization, or execution.

### 6.2.10 Diaspora and Place-Based Actors.

6.2.10.1 Diaspora and Place-Based Actors may support National Portfolios, Campaigns, Academy pathways, Competence Cells, National Working Groups, Nexus Universe preparation, public-safe reporting, workforce pathways, local knowledge, investment literacy without transaction, donor-readiness learning, and lawful handoff context.

6.2.10.2 Their participation shall preserve national ownership, local context, community safeguards, data boundaries, public-safe claims, sponsor and provider boundaries where applicable, and correction pathways.

6.2.10.3 Diaspora or place-based participation shall not bypass national pathways, create public authority approval, finance commitment, donor commitment, procurement status, consent, deployment authorization, or execution.

### 6.2.11 Sponsors and Hosts.

6.2.11.1 Sponsors and Hosts may provide resources, venues, infrastructure, learning environments, technical access, cloud or compute support, connectivity, event space, Studio environments, Academy support, Campaign support, Nexus Universe support, Foundry support, data-room support, or other lawful support.

6.2.11.2 Sponsor and Host participation shall be recorded in Sponsor Support Records or Host Records. Such records shall identify support type, scope, restrictions, branding limits, claims limits, no-control rule, no-pay-to-influence rule, no-pay-to-routing rule, no-provider-validation rule where applicable, conflicts, public-safe wording, correction pathway, and archive rule.

6.2.11.3 Sponsor or Host support shall not create governance control, priority control, content control, validation, procurement status, financeability, insurance approval, public authority approval, endorsement, consent, deployment authorization, or execution authority.

### 6.2.12 Providers and Technical Contributors.

6.2.12.1 Providers and Technical Contributors may contribute tools, software, APIs, datasets, models, expertise, infrastructure, cloud services, compute, telecom support, AI systems, cybersecurity support, dashboards, Studio components, Academy content, Foundry builds, Nexus Universe demonstrations, Marketplace objects, Registry records, or handoff context.

6.2.12.2 Provider and Technical Contributor participation shall be governed by provider-neutrality, contribution records, support class, security review, license and IP rules, data-use labels, AI-use labels, public-safe documentation, sponsor-boundary rules where applicable, procurement-neutrality rules, correction, deprecation, withdrawal, and archive.

6.2.12.3 Provider contribution shall not create provider validation, preferred vendor status, procurement recommendation, certification, security approval, AI safety approval, public authority approval, financeability, insurance approval, deployment authorization, or execution.

## 6.3 Team Topologies for Nexus

### 6.3.1 Stream-Aligned Teams.

6.3.1.1 Stream-Aligned Teams shall be organized around a clear flow of public-good work, such as a National Portfolio stream, WFEH-B stream, DRR/DRF/DRI stream, Foundry build stream, Campaign stream, Academy stream, Reports stream, Studio stream, Marketplace and Registry stream, DICE stream, GRIx stream, Observatory stream, or handoff dependency stream.

6.3.1.2 Stream-Aligned Teams shall own flow within scope from Docket item to output, review, release, routing, correction, and archive. They shall maintain clarity of purpose, dependencies, review needs, release class, support class, public-safe status, and boundary notices.

6.3.1.3 Stream alignment shall not create autonomous authority to approve, certify, finance, procure, insure, warn, consent, deploy, or execute. Stream-Aligned Teams move work; they do not convert work into authority.

### 6.3.2 Enabling Teams.

6.3.2.1 Enabling Teams shall help other teams, Working Groups, Competence Cells, Guilds, Academy Cohorts, Foundry Build Teams, Campaign Teams, Labs Streams, Studio Rooms, and National Portfolios improve capability, solve constraints, adopt methods, use templates, satisfy review gates, improve public-safe outputs, manage data and AI controls, address cyber and privacy requirements, apply safeguards, and prepare correction pathways.

6.3.2.2 Enabling Teams may provide coaching, tools, templates, documentation, review support, training, standards-interface mapping, data stewardship support, AI governance support, public-safe reporting support, accessibility support, and handoff dependency support.

6.3.2.3 Enabling support shall not replace required review or create certification, approval, compliance determination, procurement status, financeability, insurance approval, consent, deployment authorization, or execution.

### 6.3.3 Complicated-Subsystem Teams.

6.3.3.1 Complicated-Subsystem Teams shall be formed where work requires deep specialized competence in areas such as AI safety, agentic systems, AI-RAN, O-RAN, telecom, edge, HPC, sovereign compute, cybersecurity, zero trust, geospatial systems, Earth observation, digital twins, robotics, drones, sensors, IoT, OT, IIoT, DLT, DePIN, quantum-relevant systems, semiconductors, advanced manufacturing, biosecurity-sensitive systems, climate systems, WFEH-B cascades, DRI indicators, or secure-room architecture.

6.3.3.2 These Teams shall support evidence assembly, technical review, methods, testbeds, model and system cards, benchmark cards, standards-interface records, Studio workflows, Grid inputs, TRL notes, public-safe summaries, and handoff dependency notes.

6.3.3.3 Technical specialization shall not create authority to certify, approve, deploy, operate, command, procure, finance, insure, or execute. Specialized review is bounded by scope and shall be recorded.

### 6.3.4 Platform Teams.

6.3.4.1 Platform Teams shall develop, maintain, support, and correct reusable NAF platforms, including Nexus Marketplace, Nexus Registry, Nexus Studio, Nexus Grid, Nexus Reports infrastructure, Nexus Campaigns platform, Nexus Academy platform, Nexus Foundry tooling, DICE infrastructure, GRIx infrastructure, DRI dashboards, Nexus Observatory tools, Nexus Rails routing tools, Nexus Network memory infrastructure, and National Node infrastructure.

6.3.4.2 Platform Teams shall maintain platform roadmaps, access controls, support classes, security controls, privacy controls, data-use labels, AI-use labels, APIs, SDKs, connectors, documentation, incident records, vulnerability channels, release classes, correction pathways, deprecation rules, and archive rules.

6.3.4.3 Platform operation shall not create service warranty, public authority approval, procurement platform status, regulated financial platform status, insurance platform status, certification authority, public warning authority, deployment authorization, or execution.

### 6.3.5 Public-Safe Review Teams.

6.3.5.1 Public-Safe Review Teams shall review outputs for public-safe release, including Reports, public summaries, Campaign materials, Marketplace listings, Registry public fields, Studio outputs, DRI summaries, Observatory outputs, National Portfolio summaries, Nexus Universe materials, Academy materials, and handoff context summaries.

6.3.5.2 Public-Safe Review Teams shall check for overclaim, false certainty, public warning overclaim, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, protected knowledge exposure, sensitive geospatial exposure, cyber-sensitive disclosure, sponsor or provider promotion, and correction readiness.

6.3.5.3 Public-safe review shall not be public authority approval, legal clearance by default, certification, media approval, or immunity from correction. It is a review gate within NAF.

### 6.3.6 Safeguard Review Teams.

6.3.6.1 Safeguard Review Teams shall review work for community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, conflict sensitivity, rights concerns, non-extractive practice, and community-facing correction.

6.3.6.2 Safeguard Review Teams may restrict, reroute, delay, condition, correct, or stop work where safeguard requirements are not satisfied. Their review records shall identify scope, findings, unresolved issues, required controls, release implications, correction pathway, and archive rule.

6.3.6.3 Safeguard review shall not itself grant community consent, Indigenous consent, legal permission, public authority approval, or implementation authorization. It identifies conditions and boundaries.

### 6.3.7 Data Steward Teams.

6.3.7.1 Data Steward Teams shall govern data intake, classification, metadata, data dictionaries, schemas, lineage, quality, rights, access, data-use labels, AI-use labels, cross-border controls, data sovereignty, retention, deletion, sealing, compute-to-data, public-safe transformation, DICE routing, Registry records, Marketplace metadata, correction, and archive.

6.3.7.2 Data Steward Teams shall be required where work involves restricted data, public authority-sensitive data, health-sensitive data, youth data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, or AI training or evaluation data.

6.3.7.3 Data stewardship shall not create data ownership, data rights, publication permission, AI training permission, public authority approval, handoff permission, or execution authority.

### 6.3.8 AI, Cyber, and Privacy Review Teams.

6.3.8.1 AI, Cyber, and Privacy Review Teams shall review model objects, AI workflows, agentic systems, prompts, retrieval systems, classification systems, evaluation harnesses, datasets, system cards, model cards, benchmark cards, cybersecurity controls, zero-trust controls, vulnerabilities, dependency risks, privacy risks, data protection issues, and incident records.

6.3.8.2 Their review shall include human review requirements, prohibited uses, tool permissions, prompt-injection controls, data leakage controls, bias and harm review, secret scanning, dependency scanning, SBOM records, vulnerability disclosure, privacy impact considerations, public-safe output rules, incident response, withdrawal, and correction.

6.3.8.3 AI, cyber, or privacy review shall not create AI safety certification, security certification, legal compliance determination, public authority approval, deployment authorization, warranty, or execution.

### 6.3.9 National Portfolio Teams.

6.3.9.1 National Portfolio Teams shall support the creation, maintenance, review, release, routing, correction, and archive of National Portfolio objects. They may include national context contributors, systems-risk contributors, public authority learning participants, data stewards, Academy contributors, Foundry contributors, Campaign contributors, Reports contributors, Studio participants, Grid and TRL reviewers, safeguard reviewers, and handoff dependency contributors.

6.3.9.2 National Portfolio Teams shall preserve national ownership, public authority boundaries, data sovereignty, localization, safeguards, community and Indigenous protocol boundaries where applicable, provider neutrality, sponsor boundaries, finance-readiness boundaries, procurement neutrality, correctionability, and archive discipline.

6.3.9.3 National Portfolio Team participation shall not create national adoption, public authority approval, country ranking, procurement status, financeability, insurance approval, consent, deployment authorization, or execution.

### 6.3.10 Handoff Dependency Teams.

6.3.10.1 Handoff Dependency Teams shall prepare, review, correct, and archive handoff dependency packages. They may include evidence stewards, data stewards, technical reviewers, public-safe reviewers, safeguard reviewers, legal-boundary reviewers, finance-readiness reviewers, insurance-readiness reviewers, procurement-neutrality reviewers, provider-neutrality reviewers, sponsor-boundary reviewers, National Portfolio representatives, and lawful recipient interface participants.

6.3.10.2 Handoff Dependency Teams shall identify evidence context, data context, method context, software context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathway, recall pathway, and archive rule.

6.3.10.3 Handoff Dependency Teams shall not authorize implementation, approve recipients, approve finance, approve insurance, approve procurement, certify systems, grant consent, authorize deployment, or execute projects.

## 6.4 Nexus Guilds

### 6.4.1 Data Guilds.

6.4.1.1 Data Guilds shall maintain data practices across NAF, including data classification, metadata, data dictionaries, schemas, lineage, quality, access control, data-use labels, AI-use labels, cross-border controls, data sovereignty, compute-to-data, public-safe transformation, DICE routing, data-room practice, correction, and archive.

6.4.1.2 Data Guild outputs may include templates, methods, review guidance, training, controlled vocabulary, data object rules, public-safe data practices, and correction practices. Data Guild work shall not create data rights, publication permission, AI training permission, legal compliance determination, or public authority approval.

### 6.4.2 AI Guilds.

6.4.2.1 AI Guilds shall maintain AI-use practices, model card practices, system card practices, benchmark card practices, agent workflow card practices, human review practices, AI incident practices, evaluation practices, bias and harm review practices, prompt-injection controls, tool-permission controls, and public-safe AI output rules.

6.4.2.2 AI Guild status shall not create AI certification, AI safety approval, automated decision authority, deployment authorization, or professional license.

### 6.4.3 Cyber Guilds.

6.4.3.1 Cyber Guilds shall maintain cybersecurity practices, zero-trust patterns, identity and access controls, dependency scanning, secret scanning, SBOM practice, vulnerability disclosure, incident response, cyber-sensitive publication controls, secure-room rules, and public-safe cyber reporting.

6.4.3.2 Cyber Guild review or guidance shall not create security certification, compliance determination, operational command, warranty, or deployment authorization.

### 6.4.4 Privacy Guilds.

6.4.4.1 Privacy Guilds shall maintain privacy-by-design practices, data minimization, purpose limitation, consent and permission records, data subject rights where applicable, sensitive data handling, youth data controls, health data controls, community data controls, cross-border literacy, deletion, sealing, archive, and privacy incident correction.

6.4.4.2 Privacy Guild guidance shall not constitute legal advice, legal compliance determination, public authority approval, or permission to process data beyond recorded authority.

### 6.4.5 Geospatial Guilds.

6.4.5.1 Geospatial Guilds shall maintain geospatial practices, sensitive location controls, Earth observation source records, map generalization, masking, delay rules, protected species controls, sacred site controls, community-sensitive location controls, infrastructure-sensitive location controls, public-safe atlas outputs, and geospatial correction.

6.4.5.2 Geospatial Guild outputs shall not create official maps, public warnings, surveillance authority, land-use approval, protected knowledge permission, or deployment authorization.

### 6.4.6 WFEH-B Guilds.

6.4.6.1 WFEH-B Guilds shall maintain cross-system practices for water, food, energy, health, biodiversity, nature, infrastructure dependencies, climate adaptation, cascade analysis, public-safe WFEH-B reporting, National Portfolio support, Studio scenarios, DRI indicators, Observatory needs, and handoff dependencies.

6.4.6.2 WFEH-B Guild work shall not create environmental certification, public health decision, resource allocation, public authority approval, procurement recommendation, financeability, insurance approval, or execution.

### 6.4.7 DRR Guilds.

6.4.7.1 DRR Guilds shall maintain disaster-risk-reduction practices, including risk knowledge, prevention, mitigation, preparedness, response learning, recovery learning, reconstruction learning, resilience capacity, exposure, vulnerability, community resilience, public authority learning, and public-safe disaster-risk communication.

6.4.7.2 DRR Guild outputs shall not be public warnings, emergency commands, public authority decisions, official disaster plans, or deployment authorizations.

### 6.4.8 DRF Guilds.

6.4.8.1 DRF Guilds shall maintain disaster-risk-finance literacy, protection-gap questions, risk-layering questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, no-reliance rooms, assumptions registers, dependency registers, and diligence-gap registers.

6.4.8.2 DRF Guild work shall not constitute investment advice, insurance underwriting, financial promotion, finance arrangement, donor commitment, public finance allocation, rating, or transaction.

### 6.4.9 DRI Guilds.

6.4.9.1 DRI Guilds shall maintain disaster-risk-intelligence practices, including indicator records, signal records, uncertainty labels, confidence labels, dashboards, hotspot records, multi-hazard records, cascade records, public-safe intelligence summaries, correction, and archive.

6.4.9.2 DRI Guild outputs shall not create warning authority, ratings, insurance scores, investment signals, public authority decisions, or emergency commands.

### 6.4.10 GRIx Guilds.

6.4.10.1 GRIx Guilds shall maintain risk ontology, controlled vocabulary, taxonomies, categories, definitions, semantic interoperability, mapping rules, localization, translation, standards-interface records, and correction of risk meaning.

6.4.10.2 GRIx Guild work shall not create legal classification, rating, certification, standards authority, public authority approval, or compliance determination.

### 6.4.11 DICE Guilds.

6.4.11.1 DICE Guilds shall maintain Data Commons, Innovation Commons, Software Commons, Knowledge Commons, Guild Commons, secure-room practices, data-room practices, clean-room practices, compute-to-data practices, public-good digital economy infrastructure, and commons anti-capture controls.

6.4.11.2 DICE Guild outputs shall not create unrestricted data rights, ownership transfer, software warranty, provider validation, public authority approval, or deployment authorization.

### 6.4.12 Public-Safe Reporting Guilds.

6.4.12.1 Public-Safe Reporting Guilds shall maintain publication language, public-safe summaries, no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-execution language, protected knowledge controls, correction notices, and public repair practice.

6.4.12.2 Public-Safe Reporting Guild review shall not create media approval, legal clearance, public authority approval, public warning authority, or immunity from correction.

### 6.4.13 Legal Boundary Guilds.

6.4.13.1 Legal Boundary Guilds shall maintain role-separation practices, non-execution language, no-conversion controls, public authority boundary controls, finance-readiness boundaries, procurement-neutrality rules, provider-neutrality rules, sponsor-boundary rules, data and AI boundary notices, standards-authority boundary notices, reliance labels, handoff notices, correction notices, and archive notices.

6.4.13.2 Legal Boundary Guild participation shall not substitute for jurisdiction-specific legal advice, board authorization, public authority action, regulatory approval, or court determination.

### 6.4.14 Safeguard Guilds.

6.4.14.1 Safeguard Guilds shall maintain community safeguards, Indigenous protocol-sensitive practices where applicable, protected knowledge controls, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, rights-based review, non-extractive engagement, community-facing correction, and safeguard stop-the-line practices.

6.4.14.2 Safeguard Guild review shall not grant consent, legal permission, public authority approval, or implementation authorization.

### 6.4.15 Marketplace and Registry Guilds.

6.4.15.1 Marketplace and Registry Guilds shall maintain listing practices, metadata practices, status-truth records, version records, review records, support records, data-use records, AI-use records, provider contribution records, sponsor support records, correction records, withdrawal records, recall records, archive records, and non-continuation records.

6.4.15.2 Marketplace and Registry Guild outputs shall not create endorsement, certification, procurement recommendation, provider validation, financeability, insurance approval, or execution authority.

### 6.4.16 Studio Guilds.

6.4.16.1 Studio Guilds shall maintain Studio workflow practices, dashboard practices, digital twin practices, simulation practices, AI workflow review practices, public authority learning room practices, readiness room practices, capital-reader room practices, insurance-reader room practices, secure-room practices, output review, no-command rules, no-write-back rules, shutdown triggers, correction, and archive.

6.4.16.2 Studio Guild work shall not create operational command, public authority decision, finance approval, insurance approval, deployment authorization, or execution.

### 6.4.17 Grid and TRL Guilds.

6.4.17.1 Grid and TRL Guilds shall maintain readiness-input practices, evidence sufficiency practices, method quality practices, data status practices, AI-use status practices, cyber status practices, public-safe status practices, safeguard status practices, support status practices, TRL 1–10 evidence notes, downgrade, suspension, withdrawal, reinstatement, correction, and archive.

6.4.17.2 Grid and TRL Guild outputs shall not create certification, maturity certification, procurement readiness, financeability, insurability, public authority approval, or deployment authorization.

### 6.4.18 Handoff Guilds.

6.4.18.1 Handoff Guilds shall maintain lawful handoff dependency practices, evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive rules.

6.4.18.2 Handoff Guild work shall not authorize implementation, approve recipients, finance projects, insure projects, procure suppliers, certify systems, grant consent, deploy, operate, command, or execute.

## 6.5 National Working Groups

### 6.5.1 Formation.

6.5.1.1 National Working Groups shall be formed through appropriate national Nexus pathways to support National Portfolio priorities, public authority learning, Campaign activation, Academy pathways, Foundry builds, Labs translation, Reports, Studio workflows, DICE objects, GRIx mappings, DRI inputs, Observatory needs, Marketplace and Registry objects, Grid and TRL inputs, Nexus Universe preparation, and lawful handoff dependency records.

6.5.1.2 Formation records shall identify formation basis, national context, sponsoring or convening institution if any, participants, roles, scope, Docket references, National Portfolio linkage, public authority boundary status, data and AI labels, safeguard status, conflicts, support class, claims limits, correction pathway, and archive rule.

6.5.1.3 Formation shall not create authority, endorsement, certification, procurement status, financeability, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 6.5.2 Mandate.

6.5.2.1 The mandate of a National Working Group shall be to produce evidence-bearing, public-good, nationally routed work within defined scope. A National Working Group may map needs, define challenges, assemble evidence, review methods, propose learning pathways, support Campaigns, create Foundry tasks, support Reports, structure data, support DRI and Observatory inputs, prepare Studio workflows, support Grid and TRL inputs, prepare Nexus Universe materials, and identify handoff dependencies.

6.5.2.2 The mandate shall expressly preserve non-execution, no-conversion, national ownership, public authority learning without substitution, finance-readiness without finance, procurement neutrality, sponsor support without control, provider contribution without validation, community participation without consent overclaim, Indigenous protocol protections where applicable, data and AI controls, correctionability, and archive discipline.

### 6.5.3 Workplans.

6.5.3.1 National Working Group Workplans shall translate National Portfolio priorities into structured tasks, timelines, outputs, review gates, release classes, dependencies, assumptions, support needs, and correction paths. Workplans may cover evidence, data, AI, cyber, privacy, safeguards, Campaigns, Academy, Foundry, Reports, Studio, Grid, TRL, Nexus Universe, Marketplace, Registry, and handoff dependencies.

6.5.3.2 Workplans shall include public-safe status, data-use labels, AI-use labels, public authority boundary status, finance/insurance/procurement boundary status, provider-neutrality notes, sponsor-boundary notes, labor boundary notices, and archive rules.

### 6.5.4 Records.

6.5.4.1 National Working Groups shall maintain formation records, participation records, meeting records, Docket records, workplan records, evidence records, learning records, Campaign records, review records, public authority learning records, sponsor support records, provider contribution records, community participation records, consent boundary records, correction records, and archive records.

6.5.4.2 Records shall preserve validity by record. Unrecorded claims, approvals, endorsements, decisions, consent, authority, or commitments shall not be attributed to the Working Group.

### 6.5.5 Outputs.

6.5.5.1 National Working Group outputs may include National Context Records, National Systems-Risk Maps, 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, Reports, public-safe summaries, Studio workflows, Registry records, Marketplace objects, Grid inputs, TRL notes, Campaign objects, and handoff dependency packages.

6.5.5.2 Outputs shall be released only according to their classification, review status, release class, public-safe status, and boundary notices.

### 6.5.6 Public Authority Interfaces.

6.5.6.1 National Working Groups may interface with public authorities for learning, evidence questions, scenario review, DRI interpretation, Observatory needs, public-safe reporting, national context review, public finance relevance questions, standards-interface issues, and handoff dependencies.

6.5.6.2 Public Authority Interfaces shall be recorded as non-decision unless separately and lawfully documented by the competent public authority. Interface records shall not create official action, public finance allocation, procurement decision, permit, license, public warning, emergency command, or implementation approval.

### 6.5.7 National Portfolio Interfaces.

6.5.7.1 National Working Groups shall interface with National Portfolios by producing, reviewing, updating, correcting, or archiving National Portfolio objects. Such interfaces shall preserve national ownership, country context, data sovereignty, language and localization, public authority boundaries, safeguards, and lawful handoff pathways.

6.5.7.2 National Portfolio interfaces shall not create country ranking, government approval, procurement status, financeability, insurance approval, consent, deployment authorization, or execution.

### 6.5.8 Campaign Interfaces.

6.5.8.1 National Working Groups may support Campaigns by identifying public-good topics, public-safe messages, participation pathways, volunteer tasks, Academy routes, Foundry routes, community safeguards, youth safeguards, Campaign-to-National Portfolio links, Campaign-to-Universe links, and correction pathways.

6.5.8.2 Campaign interfaces shall preserve claims discipline and shall not convert Campaign participation into mandate, vote, approval, consent, finance commitment, procurement commitment, or execution.

### 6.5.9 Universe Interfaces.

6.5.9.1 National Working Groups may prepare Nexus Universe materials, including arena records, National Portfolio presentations, public authority learning materials, readiness-room questions, Studio demonstrations, Foundry build records, Campaign records, Reports, Registry updates, Marketplace listings, Grid inputs, TRL notes, and handoff dependency notes.

6.5.9.2 Universe interface records shall include release class, presenter role, public-safe status, safeguard status, data and AI labels, boundary notices, correction pathway, and post-Universe continuation plan.

### 6.5.10 Continuation and Archive.

6.5.10.1 National Working Groups shall maintain continuation and archive discipline. Each work item shall either continue through a recorded pathway, transfer to a Competence Cell, route to another Nexus pathway, prepare for Nexus Universe, enter lawful handoff dependency review, be corrected, be archived, or be marked non-continuing.

6.5.10.2 Archive records shall preserve institutional memory and shall prevent non-current Working Group outputs from being misused as current authority.

## 6.6 Nexus Competence Cells

### 6.6.1 Cell Identity.

6.6.1.1 A Nexus Competence Cell is an applied capability unit organized around a defined domain, system, technology, method, hazard, geography, National Portfolio need, Foundry build, Studio workflow, Campaign, Academy pathway, DICE object, GRIx mapping, DRI input, Observatory need, Report, Marketplace object, Registry record, Grid input, TRL note, or handoff dependency.

6.6.1.2 Each Cell shall have a recorded identity, including name, purpose, scope, national or regional relationship where applicable, steward, participants, roles, Docket references, competence area, review requirements, release classes, support class, boundary notices, correction pathway, and archive rule.

### 6.6.2 Cell Scope.

6.6.2.1 Cell Scope shall define what the Cell may and may not do. Scope shall identify domain boundaries, evidence boundaries, data boundaries, AI boundaries, cyber boundaries, public-safe boundaries, safeguard boundaries, public authority boundaries, finance/insurance/procurement boundaries, sponsor/provider boundaries, handoff boundaries, and execution boundaries.

6.6.2.2 Cells shall not expand beyond scope without recorded amendment, review, and correction of downstream dependencies where required.

### 6.6.3 Cell Workplans.

6.6.3.1 Cell Workplans shall convert Cell Scope into tasks, outputs, roles, timelines, dependencies, review gates, release classes, support needs, correction pathways, and archive rules. Workplans shall identify Academy links, Foundry links, Studio links, Reports links, DICE links, GRIx links, DRI links, Observatory links, Campaign links, Marketplace links, Registry links, Grid and TRL links, Nexus Universe links, and handoff links where applicable.

6.6.3.2 Workplans shall include labor boundary notices, participant protections, data-use labels, AI-use labels, public-safe status, safeguards, conflicts, and review requirements.

### 6.6.4 Cell Evidence Outputs.

6.6.4.1 Cell Evidence Outputs may include evidence packs, method notes, data notes, model cards, system cards, benchmark cards, agent workflow cards, API cards, digital twin cards, scenario notes, public-safe summaries, review notes, assumptions registers, dependency registers, and correction records.

6.6.4.2 Evidence Outputs shall be bounded by scope and shall not create approval, certification, financeability, insurance approval, procurement readiness, public authority action, consent, deployment authorization, or execution.

### 6.6.5 Cell Learning Outputs.

6.6.5.1 Cell Learning Outputs may include Academy modules, Risk Academy modules, learning objects, WILP tasks, micro-credential evidence where applicable, mentor notes, learner pathways, public-safe reporting exercises, data and AI training objects, cyber training objects, safeguard training objects, and handoff literacy objects.

6.6.5.2 Learning Outputs shall not create professional license, employment, public authority competence certification, procurement qualification, or execution authority.

### 6.6.6 Cell Foundry Outputs.

6.6.6.1 Cell Foundry Outputs may include quests, bounties, builds, software objects, data pipelines, dashboards, notebooks, APIs, SDKs, connectors, templates, Reports builds, Registry builds, Marketplace builds, Studio workflow builds, Grid inputs, TRL notes, Campaign builds, and handoff dependency builds.

6.6.6.2 Foundry Outputs shall be subject to review, release, support class, correction, and archive. They shall not create warranty, certification, procurement status, provider validation, financeability, insurance approval, deployment authorization, or execution.

### 6.6.7 Cell Studio Outputs.

6.6.7.1 Cell Studio Outputs may include dashboard workflows, digital twin workflows, simulations, scenario workflows, AI workflow reviews, data-room workflows, secure-room workflows, public authority learning workflows, readiness-room workflows, capital-reader room workflows, insurance-reader room workflows, Nexus Universe workflows, and handoff demonstration workflows.

6.6.7.2 Studio Outputs shall remain controlled runtime outputs and shall not create decisions, warnings, approvals, commands, finance approvals, underwriting, deployment authorization, or execution.

### 6.6.8 Cell Reports Outputs.

6.6.8.1 Cell Reports Outputs may include technical notes, public-safe summaries, National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF Reports, DRI Reports, DICE Reports, GRIx Reports, Observatory Reports, Foundry Reports, Campaign Reports, Academy Reports, Nexus Universe Reports, Grid and TRL Reports, handoff context notes, correction reports, and archive reports.

6.6.8.2 Reports Outputs shall include evidence basis, limitations, data and AI statements, public-safe status, boundary notices, correction pathway, and archive rule.

### 6.6.9 Cell Handoff Dependencies.

6.6.9.1 Cell Handoff Dependencies shall identify what downstream lawful actors must review before any implementation, procurement, finance, insurance, deployment, operation, or execution. Such dependencies may include evidence, data, methods, technical constraints, public authority approvals, legal requirements, safeguards, provider-neutrality conditions, sponsor-boundary conditions, finance and insurance questions, support class, correction pathway, and recall pathway.

6.6.9.2 Cell Handoff Dependencies shall not authorize handoff, implementation, procurement, finance, insurance, certification, consent, deployment, or execution.

### 6.6.10 Cell Correction and Archive.

6.6.10.1 Cells shall maintain correction and archive records for all outputs. Correction may include amendment, erratum, addendum, revision, downgrade, suspension, withdrawal, recall, public repair, archive, or non-continuation.

6.6.10.2 Cell archives shall preserve institutional memory, participant contributions, evidence history, review history, release history, correction history, support status, successor links, and permitted historical use without creating current authority.

## 6.7 Participation Records

### 6.7.1 Participation Before Authority.

6.7.1.1 NAF shall treat participation as record-bearing engagement before authority. Participation may create learning records, contribution records, review records, Campaign records, public authority learning records, sponsor support records, provider contribution records, community participation records, consent boundary records, correction records, and archive records.

6.7.1.2 Participation shall not create approval, endorsement, certification, procurement status, financeability, insurance approval, public authority action, public warning, consent, deployment authorization, employment, agency, or execution by implication.

### 6.7.2 Contribution Records.

6.7.2.1 Contribution Records shall record what a participant contributed, when, under what role, under what Docket item, with what review status, with what release class, with what data or AI labels, with what public-safe status, with what support class, with what conflict disclosures, and with what correction pathway.

6.7.2.2 Contribution Records may support ILA, iCRS, WILPs, Academy pathways, Foundry records, Reports, Marketplace, Registry, Grid, TRL, Nexus Universe, National Portfolios, or handoff dependency context, but shall not create employment, compensation, credential, professional license, procurement qualification, or execution authority by default.

### 6.7.3 Learning Records.

6.7.3.1 Learning Records shall record learning participation, learning completion, assessment evidence where applicable, WILP participation, mentor verification where applicable, public-safe reporting practice, data and AI learning, cyber learning, safeguard learning, public authority learning participation, handoff literacy, and correction or withdrawal.

6.7.3.2 Learning Records may be linked to ILA, iCRS, Academy, Risk Academy, Registry, Marketplace, National Portfolios, and Nexus Universe where permitted. Learning Records shall not create professional license, degree, employment, wage, visa, public authority credential, procurement eligibility, or execution authority by implication.

### 6.7.4 Review Records.

6.7.4.1 Review Records shall document the scope, reviewer role, review type, evidence reviewed, limitations, findings, required changes, unresolved questions, release implication, correction need, and archive rule for a review.

6.7.4.2 Review Records shall be bounded by scope. Review shall not create certification, approval, legal compliance determination, public authority action, finance approval, insurance approval, procurement decision, provider validation, consent, deployment authorization, or execution.

### 6.7.5 Public Authority Learning Records.

6.7.5.1 Public Authority Learning Records shall document participation by public authorities in learning, evidence review, Studio Rooms, Readiness Rooms, Reports review, DRI interpretation, Observatory interpretation, National Portfolio review, Nexus Universe sessions, standards-interface dialogue, finance-readiness discussion, insurance-readiness discussion, public finance learning, or handoff dependency review.

6.7.5.2 Public Authority Learning Records shall include non-decision notices unless separately recorded otherwise. They shall not create official action, approval, permit, license, public finance allocation, procurement decision, public warning, emergency command, deployment authorization, or execution.

### 6.7.6 Sponsor Support Records.

6.7.6.1 Sponsor Support Records shall document sponsor support, including financial support where lawful, in-kind support, venue support, infrastructure support, cloud or compute support, connectivity, event support, Campaign support, Academy support, Foundry support, Studio support, Nexus Universe support, or other lawful support.

6.7.6.2 Sponsor Support Records shall include support scope, restrictions, acknowledgments, branding limits, no-control notice, no-priority notice, no-validation notice, no-procurement notice, no-finance notice, conflicts, correction pathway, and archive rule.

6.7.6.3 Sponsor Support Records shall not create sponsor control, endorsement, procurement status, validation, financeability, public authority approval, consent, deployment authorization, or execution.

### 6.7.7 Provider Contribution Records.

6.7.7.1 Provider Contribution Records shall document provider contributions, including tools, services, software, APIs, data, models, infrastructure, expertise, documentation, training, support, Studio components, Foundry builds, Marketplace objects, Registry records, or Nexus Universe demonstrations.

6.7.7.2 Provider Contribution Records shall include contribution scope, license or rights status, support class, review status, security status, data and AI labels, provider-neutrality notice, procurement-neutrality notice, no-validation notice, correction pathway, withdrawal rule, and archive rule.

6.7.7.3 Provider Contribution Records shall not create preferred supplier status, procurement recommendation, provider validation, certification, financeability, insurance approval, public authority approval, deployment authorization, or execution.

### 6.7.8 Community Participation Records.

6.7.8.1 Community Participation Records shall document community input, lived-risk knowledge, local context, vulnerability information, resilience priorities, safeguard concerns, accessibility needs, public-safe reporting input, Campaign participation, Studio participation, National Portfolio input, Nexus Universe participation, and correction requests.

6.7.8.2 Community Participation Records shall include scope, permission status where applicable, data-use limits, public-safe limits, protected knowledge limits, consent boundary notices, community-facing correction, and archive rules.

6.7.8.3 Community Participation Records shall not imply consent, endorsement, land access, project approval, data permission beyond scope, deployment authorization, or execution.

### 6.7.9 Consent Boundary Records.

6.7.9.1 Consent Boundary Records shall document what participation does and does not mean for consent. They shall identify whether consent is not required for the recorded activity, consent is outside scope, consent is pending, consent is refused, consent is restricted, consent is separately recorded, or consent must be obtained through competent legal and community processes outside NAF’s default records.

6.7.9.2 Consent Boundary Records shall be required where work involves communities, Indigenous participants where applicable, protected knowledge, local knowledge, personal data, youth data, health-sensitive data, land or water context, sensitive geospatial context, deployment-adjacent context, public-safe reporting, or lawful handoff.

6.7.9.3 Consent Boundary Records shall prevent participation from being misused as consent.

### 6.7.10 Correction Records.

6.7.10.1 Correction Records shall document corrections involving participation, contribution, learning, review, public authority learning, sponsor support, provider contribution, community participation, consent boundaries, labor boundaries, safeguard concerns, data issues, AI issues, cyber issues, public-safe claims, or handoff overclaims.

6.7.10.2 Correction Records shall include issue, affected records, containment action, correction action, public-safe notice where needed, Registry update where needed, Marketplace update where needed, Report correction where needed, Studio restriction where needed, Grid or TRL correction where needed, handoff recall where needed, and archive rule.

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

### 6.8.1 Volunteer Work.

6.8.1.1 Volunteer Work within NAF shall mean voluntary public-good contribution within recorded scope, without expectation of employment, wage, equity, token, procurement status, finance status, professional credential, public authority status, or execution authority unless separately and lawfully recorded.

6.8.1.2 Volunteer Work shall be governed by role clarity, scope, reasonable workload, safe participation, anti-harassment controls, data protection, confidentiality where applicable, public-safe duties, sponsor/provider boundaries, contribution records, correction rights, withdrawal pathways, and archive rules.

6.8.1.3 Volunteer Work shall not be used to disguise employment, substitute regular labor, evade labor protections, create unpaid operational obligations, or execute projects by implication.

### 6.8.2 Learning Work.

6.8.2.1 Learning Work shall mean work performed primarily for learning, competence formation, public-good practice, WILP participation, Academy progression, Risk Academy progression, Studio exercise, Foundry contributor practice, Campaign practice, or evidence-of-learning. Learning Work may produce public-good artifacts, but its learning character must be recorded.

6.8.2.2 Learning Work shall include learner protections, mentor or supervision status where required, assessment scope, expected outputs, data and confidentiality obligations, AI-use rules, safety controls, accessibility, youth safeguards where applicable, correction rights, and archive rules.

6.8.2.3 Learning Work shall not create employment, professional license, wage entitlement, procurement qualification, public authority competence certification, deployment authorization, or execution responsibility.

### 6.8.3 Bounty-Supported Work.

6.8.3.1 Bounty-Supported Work shall mean scoped contribution opportunities supported through recognition, credits, rewards, stipends, honoraria, or other lawful support where permitted and recorded. Bounty-Supported Work shall be tied to defined tasks, acceptance criteria, review requirements, release class, support class, labor boundary, tax or legal considerations where applicable, correction pathway, and archive rule.

6.8.3.2 Bounty support shall not create employment unless separately and lawfully documented. It shall not create equity, token, securities, finance, insurance, procurement, public authority, certification, or execution rights by default.

6.8.3.3 Bounty programs shall include anti-exploitation controls, transparency, fair task scoping, review fairness, dispute and correction channels, sponsor/provider controls, and no-disguised-labor protections.

### 6.8.4 Stipend-Supported Work.

6.8.4.1 Stipend-Supported Work shall mean participation supported by a stipend, honorarium, travel support, learning support, access support, or other lawful support intended to reduce participation barriers or support defined public-good contribution without necessarily creating employment.

6.8.4.2 Stipend-Supported Work shall be recorded with purpose, amount or support class where appropriate, eligibility, scope, duration, role, tax or legal status where applicable, labor boundary notice, conflict controls, sponsor controls where applicable, correction pathway, and archive rule.

6.8.4.3 Stipend support shall not create employment, wage entitlement beyond the recorded stipend, procurement status, finance status, credential status, public authority status, deployment authorization, or execution authority by implication.

### 6.8.5 Contracted Work.

6.8.5.1 Contracted Work shall mean work performed under a separate written agreement with defined parties, scope, deliverables, compensation, IP terms, confidentiality, data terms, security obligations, review requirements, public-safe obligations, acceptance process, correction duties, termination rules, and liability terms.

6.8.5.2 Contracted Work may support NAF outputs but shall remain legally separate from volunteer work, learning work, bounty-supported work, sponsor-supported work, public authority learning work, and lawful handoff recipient work. Contracted Work shall be recorded in a manner that prevents role confusion.

6.8.5.3 Contracted Work shall not by itself create certification, public authority approval, procurement recommendation, provider validation, financeability, insurance approval, consent, deployment authorization, or execution outside the contract scope.

### 6.8.6 Sponsored Work.

6.8.6.1 Sponsored Work shall mean work supported by a sponsor through money, infrastructure, tools, venue, cloud, compute, connectivity, staff time, services, or other support. Sponsored Work shall be governed by support-without-control, no-pay-to-influence, no-pay-to-routing, no-pay-to-validation, provider-neutrality, procurement-neutrality, public-safe claims, conflict disclosure, and correction rules.

6.8.6.2 Sponsored Work shall include Sponsor Support Records, work scope, support class, public acknowledgment limits, branding rules, data and confidentiality rules, independence controls, reviewer independence where applicable, and archive rule.

6.8.6.3 Sponsorship shall not create sponsor control, endorsement, provider validation, procurement advantage, financeability, public authority approval, consent, deployment authorization, or execution.

### 6.8.7 Public Authority Learning Work.

6.8.7.1 Public Authority Learning Work shall mean work performed to support learning, evidence review, scenario exploration, DRI interpretation, Observatory interpretation, public-safe reporting, policy intelligence, standards-interface dialogue, finance-readiness learning, insurance-readiness learning, public finance learning, or handoff dependency review involving public authorities.

6.8.7.2 Public Authority Learning Work shall record non-decision status, public authority role, scope, materials, data restrictions, public-safe status, confidentiality obligations, unresolved questions, boundary notices, correction pathway, and archive rule.

6.8.7.3 Public Authority Learning Work shall not create public authority action, official approval, regulation, permit, license, public finance allocation, procurement decision, public warning, emergency command, deployment authorization, or execution.

### 6.8.8 No Disguised Labor.

6.8.8.1 NAF shall not use volunteer, learning, bounty-supported, stipend-supported, Campaign, Academy, Foundry, Studio, Competence Cell, National Working Group, or public-good contribution structures to disguise employment, evade labor laws, replace paid workers, extract unpaid work for private benefit, or impose operational responsibilities without lawful basis.

6.8.8.2 Work classification shall consider purpose, control, compensation, duration, dependency, supervision, output ownership, commercial use, beneficiary, participant expectation, legal context, and safeguard needs. Where a work relationship may constitute employment, contracting, apprenticeship, internship, or other legally regulated work, the appropriate lawful pathway shall be used.

6.8.8.3 No Disguised Labor discipline shall be central to NAF legitimacy. Public-good contribution shall not become exploitation.

### 6.8.9 No Employment by Implication.

6.8.9.1 Participation in NAF, including contribution, learning, WILP, Campaign participation, Foundry work, bounty participation, stipend-supported participation, Academy cohort participation, Guild participation, Competence Cell participation, National Working Group participation, Studio participation, Nexus Universe participation, Risk Agency participation, Marketplace participation, Registry participation, Grid or TRL participation, and correction work, shall not create employment by implication.

6.8.9.2 Employment may arise only through separate lawful agreement, appointment, or legal relationship. NAF records shall avoid language that implies hiring, employment guarantee, wage entitlement, labor authorization, immigration status, employee benefits, agency, or worker classification beyond what is separately and lawfully recorded.

### 6.8.10 No Execution by Contribution.

6.8.10.1 No contribution within NAF shall be treated as project execution, deployment authorization, operational command, public authority action, procurement action, finance action, insurance action, certification action, consent action, or lawful implementation action merely because the contribution supports a Docket item, portfolio, Report, build, Campaign, Studio workflow, Registry record, Marketplace listing, Grid input, TRL note, Nexus Universe output, National Portfolio object, or handoff dependency package.

6.8.10.2 Contributors may produce evidence, learning, software, data objects, methods, summaries, Campaign assets, dashboards, workflows, records, reviews, readiness notes, and dependency packages. Lawful execution, where applicable, must occur separately through competent public authority, enterprise, National Consortium Company, Project SPV, provider, operator, contractor, funder, insurer, donor, community process, Indigenous process where applicable, or other lawful actor with proper authority.

6.8.10.3 The final people rule of Part VI is that NAF mobilizes people before authority, records before claims, competence before credential overclaim, contribution before execution, participation before handoff, and correction before trust; no participant, team, squad, guild, Working Group, Competence Cell, room, cohort, panel, sponsor, provider, public authority participant, community participant, Indigenous participant, capital reader, insurer, donor, host, or contributor shall acquire certification power, procurement power, finance power, insurance power, public authority power, consent power, deployment power, employment status, agency status, or execution authority by implication.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/nexus-agile-framework-naf/vi.-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.