# II. SYSTEMS

Nexus Agile Framework Systems defines the **NAF system architecture**. It maps the Nexus operating model across global, regional, national, council, working group, competence cell, public-good, and lawful handoff layers.

This section explains how institutions, mechanisms, and interfaces work together without collapsing roles. It defines the **Nexus system map**, the **public-good stack**, the **enterprise stack**, and the role-separation rules that keep public-good delivery, public authority learning, and lawful implementation distinct.

### What this section covers

* **System map** - Explains global, regional, national, and institutional layers of Nexus.
* **Role separation** - Defines how public-good work stays separate from enterprise execution.
* **Operating interfaces** - Maps pillars, mechanisms, consortiums, and lawful handoff pathways.

Use this section with [Nexus Agile Framework (NAF)](/organization/operations/frameworks/nexus-agile-framework-naf.md) for the full framework overview and [I. FOUNDATIONS](/organization/operations/frameworks/nexus-agile-framework-naf/i.-foundations.md) for the constitutional rules, non-execution doctrine, and validity-by-record principles.

## 2.1 Nexus System Map

### 2.1.1 Global Nexus Layer.

2.1.1.1 The Global Nexus Layer is the universal public-good coordination layer through which Nexus maintains common operating doctrine, global agenda formation, shared terminology, cross-border interoperability, public-good records, global-to-regional routing, Nexus Universe preparation, public-safe reporting discipline, standards-interface awareness, and correction memory. The Global Nexus Layer shall provide coherence without creating global supremacy, centralized command, public authority status, procurement authority, finance authority, certification authority, or execution authority.

2.1.1.2 The Global Nexus Layer shall support the formation and movement of global Dockets, global challenge briefs, global public-safe reports, global Nexus Universe priorities, global standards-interface questions, global research and evidence gaps, global public-good software needs, global observability and intelligence questions, global learning pathways, global capability formation priorities, global Campaign themes, and global handoff-dependency patterns. It shall not override national law, national public authority, national ownership, regional localization, community safeguards, Indigenous protocols where applicable, data sovereignty, protected knowledge rules, or competent lawful implementation processes.

2.1.1.3 Work at the Global Nexus Layer shall be recorded, role-separated, public-safe, correctionable, and routed through appropriate Nexus pathways. Global visibility shall not be treated as endorsement, approval, maturity certification, standards conformance, financeability, procurement status, country ranking, public warning, public authority decision, or implementation authorization.

### 2.1.2 Regional Nexus Layer.

2.1.2.1 The Regional Nexus Layer is the translation, clustering, regional-learning, country-support, and systems-risk coordination layer through which regional conditions, shared hazards, cross-border infrastructure dependencies, climate corridors, water-food-energy-health-biodiversity systems, disaster-risk patterns, finance-readiness questions, insurance-readiness questions, labor and capability needs, technology-readiness questions, and Nexus Universe regional preparations are organized. The Regional Nexus Layer shall support countries and national pathways without becoming a regional government, supranational authority, regional regulator, public finance body, procurement body, certifier, insurer, investment platform, or execution vehicle.

2.1.2.2 The Regional Nexus Layer shall help connect national portfolios with regional cluster intelligence. It may support Regional Nexus Consortiums, regional cluster program plans, regional public-safe reporting, regional DRI and Observatory inputs, regional Academy and Risk Academy pathways, regional Foundry build preparation, regional Campaign coordination, regional standards-localization questions, regional public authority learning rooms, and regional Nexus Universe arenas. It shall preserve national ownership and shall not route around National Nexus Consortiums, National Councils, National Working Groups, National Nodes, competent public authorities, community protocols, or lawful national processes.

2.1.2.3 Regional records shall identify the countries, systems, corridors, hazards, technologies, stakeholders, data constraints, public authority dependencies, safeguard conditions, and handoff boundaries to which they relate. A regional record shall not convert into national adoption, public authority approval, investment priority, insurance approval, procurement preference, community consent, Indigenous consent, or execution authority.

### 2.1.3 National Nexus Layer.

2.1.3.1 The National Nexus Layer is the country-level ownership, localization, stakeholder-formation, public-good mandate, national routing, public authority learning, National Portfolio, safeguard, and lawful handoff preparation layer of Nexus. It is the normal gateway for country-level Nexus activity and shall organize national priorities before local delivery, public-good discipline before enterprise handoff, evidence before claims, readiness before finance, participation before execution, and correction before trust.

2.1.3.2 The National Nexus Layer shall support National Nexus Consortiums, National Councils, National Leadership Councils, National Investors Councils, Helix Councils, National Working Groups, Nexus Competence Cells, National Nodes, National Portfolios, national Campaigns, national Academy pathways, national Foundry build programs, national Reports, national Registry and Marketplace records, public authority learning rooms, capital-reader and insurance-reader rooms, community safeguard records, Indigenous protocol-sensitive controls where applicable, national DICE, GRIx, DRI and Observatory contributions, and lawful handoff pathways to competent actors.

2.1.3.3 The National Nexus Layer shall not itself execute projects by implication. Its records may support learning, public-safe knowledge, evidence production, capability formation, readiness questions, public authority learning, finance-readiness, insurance-readiness, procurement-neutral handoff, and enterprise legibility. National Nexus status shall not be treated as government approval, public authority delegation, public finance allocation, procurement award, investment recommendation, insurance approval, community consent, or implementation authorization.

### 2.1.4 National Council Layer.

2.1.4.1 The National Council Layer is the primary national stakeholder-formation and participation layer through which leadership, sector, public authority, university, enterprise, civil society, community, youth, technical, capital-reader, insurance-reader, donor, media, and helix participation is structured before formal work is routed into National Working Groups, Competence Cells, National Portfolios, Nexus Universe pathways, Campaigns, public authority learning rooms, or lawful handoff preparation.

2.1.4.2 National Councils shall generate participation records, agenda signals, leadership pools, issue maps, committee proposals, Working Group candidates, National Portfolio inputs, Nexus Universe preparation inputs, public-safe reporting inputs, Campaign topics, Academy pathway needs, investor and insurer literacy questions, and stakeholder legitimacy records. National Council participation shall not create board appointment, public authority decision, procurement status, finance commitment, insurance approval, donor commitment, certification, endorsement, consent, or execution authority.

2.1.4.3 National Councils shall operate under claims discipline, conflict controls, sponsor-boundary controls, provider-neutrality controls, public authority boundary controls, data and privacy controls, community safeguard controls, and correction rules. The National Council Layer shall be treated as structured formation, not implementation.

### 2.1.5 National Working Group Layer.

2.1.5.1 The National Working Group Layer is the formal national work-shaping layer for translating signals, priorities, risks, technology questions, policy-learning needs, evidence gaps, Campaign inputs, Academy needs, Foundry opportunities, DICE needs, GRIx and DRI needs, Observatory inputs, Studio workflows, Grid questions, and Nexus Universe preparation into recorded workplans and outputs.

2.1.5.2 National Working Groups may prepare challenge briefs, evidence need records, public-safe summaries, data needs, research questions, learning-pathway proposals, Foundry quest and build scopes, Campaign workplans, National Portfolio updates, standards-interface questions, public authority learning records, safeguard notes, finance-readiness questions, insurance-readiness questions, and handoff dependency notes. Their work shall be bounded by mandate, records, role separation, review requirements, release classes, correction pathways, and national routing.

2.1.5.3 National Working Groups shall not act as public authorities, procurement bodies, certifiers, funders, insurers, project developers, operators, contractors, or execution vehicles by default. Participation in a National Working Group shall not imply endorsement, public authority approval, procurement eligibility, investment interest, insurance approval, community consent, Indigenous consent, employment, professional standing, or authority to bind any institution.

### 2.1.6 Nexus Competence Cell Layer.

2.1.6.1 The Nexus Competence Cell Layer is the applied capability, specialist-production, technical-learning, public-good build, review, and localization layer through which smaller focused units convert National Working Group needs, Foundry quests, Academy pathways, DICE objects, GRIx mappings, DRI indicators, Observatory signals, Studio workflows, Reports objects, Marketplace listings, Registry records, Grid inputs, TRL notes, and handoff dependencies into evidence-bearing work products.

2.1.6.2 Competence Cells may be formed around domains, technologies, hazards, sectors, communities, functions, methods, datasets, software stacks, public-safe reporting needs, secure-room workflows, public authority learning needs, standards-interface questions, or handoff dependencies. Each Competence Cell shall have recorded scope, participants, stewardship, outputs, review needs, data and AI controls, safeguard conditions, support class, release class, correction pathway, and archive rule.

2.1.6.3 Nexus Competence Cells shall build capability and evidence, not execution authority. A Competence Cell output shall not be treated as deployment, certification, procurement recommendation, finance approval, insurance approval, public authority decision, public warning, community consent, Indigenous consent, professional qualification, or enterprise instruction unless separately and lawfully recorded by competent actors.

### 2.1.7 Guild, Expert, Maintainer, and Contributor Layer.

2.1.7.1 The Guild, Expert, Maintainer, and Contributor Layer is the distributed human capability layer of NAF. It includes domain guilds, technical guilds, data guilds, AI guilds, cyber guilds, privacy guilds, geospatial guilds, WFEH-B guilds, DRR/DRF/DRI guilds, public-safe reporting guilds, safeguard guilds, legal-boundary guilds, Marketplace and Registry guilds, Studio guilds, Grid and TRL guilds, handoff guilds, subject-matter experts, reviewers, maintainers, mentors, contributors, translators, accessibility contributors, community contributors, and public-good builders.

2.1.7.2 This layer shall enable distributed contribution while preserving record discipline. Contributors may support research, data, code, models, reports, reviews, Campaigns, learning materials, Studio workflows, Registry records, Marketplace objects, Grid inputs, TRL notes, public-safe summaries, and handoff packages, but every material contribution shall be associated with appropriate contribution records, review records, conflicts where applicable, attribution where appropriate, data and AI-use labels where relevant, release status, support class, correction pathway, and archive rule.

2.1.7.3 Guild standing, expert participation, maintainer status, reviewer participation, mentor role, or contributor recognition shall not create professional licensure, certification authority, employment, agency, procurement qualification, public authority status, provider validation, finance-readiness approval, insurance-readiness approval, consent, endorsement, or execution authority by implication.

### 2.1.8 Public-Good Mechanism Layer.

2.1.8.1 The Public-Good Mechanism Layer is the set of Nexus operating mechanisms that allow work, learning, contribution, evidence, records, value, proof, data, risk meaning, risk intelligence, support, assumptions, dependencies, diligence gaps, correction, and archive to move coherently across NAF. These mechanisms include the Integrated Learning Account, Integrated Credits and Rewards System, Work-Integrated Learning Paths, Micro-Production Model, Integrated Value Reporting System, DICE, GRIx, DRI, Proof Receipts, Dockets, Support Ledgers, Assumptions Registers, Dependency Registers, Diligence-Gap Registers, Correction Registers, and Archive Registers.

2.1.8.2 Public-good mechanisms shall convert participation into records, records into meaning, meaning into routing, routing into review, review into release, release into public-safe knowledge or controlled access, and correction into institutional trust. They shall not convert participation into employment, learning into professional license, contribution into procurement status, support into control, proof into certification, readiness into financeability, risk intelligence into warning, or handoff into execution.

2.1.8.3 Mechanism interfaces shall be designed for interoperability, correctionability, privacy, public-safe publication, controlled access where necessary, data sovereignty, national localization, protected knowledge safeguards, and role separation among public-good, public authority, enterprise, finance, insurance, provider, sponsor, community, and lawful execution actors.

### 2.1.9 Enterprise and Lawful Handoff Layer.

2.1.9.1 The Enterprise and Lawful Handoff Layer is the boundary layer through which NAF outputs may be made legible to National Consortium Companies, Project SPVs, public authorities, enterprises, providers, operators, contractors, funders, insurers, donors, universities, labs, community actors where appropriate, and other competent lawful recipients. It is the bridge from public-good preparation to lawful implementation consideration, not the execution of implementation itself.

2.1.9.2 Handoff at this layer shall occur through recorded dependency packages. Such packages may include evidence context, method context, data context, software context, model context, Studio context, Grid and TRL context, Reports, Registry records, Marketplace listings, public-safe summaries, 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.

2.1.9.3 The Enterprise and Lawful Handoff Layer shall preserve the public-good stack and enterprise-stack separation. It shall not create investment advice, solicitation, underwriting, lending, public finance allocation, procurement award, supplier preference, regulatory approval, public warning, community consent, Indigenous consent, standards certification, operational command, project authorization, or execution by implication.

### 2.1.10 Archive, Correction, and Institutional Memory Layer.

2.1.10.1 The Archive, Correction, and Institutional Memory Layer is the trust-preservation layer of NAF. It shall maintain records of what was created, what was reviewed, what was released, what was superseded, what was corrected, what was withdrawn, what was recalled, what was archived, what was not continued, what dependencies remained, what claims were limited, and what lessons were preserved.

2.1.10.2 This layer shall include Correction Registers, Archive Registers, Registry status history, Marketplace delisting records, Report correction notices, Studio workflow archive records, Grid and TRL change records, Docket closure records, handoff recall records, Campaign correction records, learning-object withdrawal records, data sealing records, model withdrawal records, software deprecation records, public-safe notices, and institutional learning summaries.

2.1.10.3 Archive and correction shall not be treated as afterthoughts. They shall be constitutional features of NAF, ensuring that Nexus remains trustworthy, inspectable, legally bounded, publicly safe, and capable of learning from error, context change, evidence change, technology change, safeguard incident, role-collapse incident, or boundary overclaim.

## 2.2 Institutional Triad

### 2.2.1 The Global Centre for Risk and Innovation as Evidence, Methods, Observability, Ontology, Public-Good R\&D, Public-Good Software, Open Technical Baseline, Verifiable Compute, and Intelligence Steward.

2.2.1.1 The Global Centre for Risk and Innovation shall be understood within NAF as the evidence, methods, observability, ontology, public-good R\&D, public-good software, open technical baseline, verifiable compute, and intelligence steward. Its NAF-facing role is to support disciplined evidence production, technical methods, data and model governance, observability architectures, controlled vocabularies, public-good software, reproducible workflows, research-to-build pathways, verifiable compute and intelligence records, Nexus Observatory methods, DICE, GRIx, DRI technical structures, and Nexus Core Build technical baselines.

2.2.1.2 The Global Centre for Risk and Innovation may support NAF through technical guidance, method notes, evidence pack structures, ontology and schema work, software repositories, model and system card patterns, benchmark card patterns, data lineage methods, compute-to-data patterns, secure-room methods, Observatory node patterns, Studio workflow methods, Grid input structures, TRL evidence logic, open technical baselines, public-good software, and public-safe technical summaries.

2.2.1.3 The Global Centre for Risk and Innovation shall not, by virtue of its NAF role, act as the public-facing legitimacy steward, registry recognition authority, finance-readiness steward, investor-interface body, insurer-interface body, procurement authority, public authority, standards authority, enterprise executor, project developer, operator, contractor, or implementation vehicle. Its technical evidence role shall remain role-separated from public-good legitimacy, finance-readiness, recognition-interface, certification, procurement, and execution functions unless a separate lawful authority is expressly recorded.

### 2.2.2 The Global Risks Forum as Public-Good Legitimacy, Claims Discipline, Registry, Recognition-Interface, Maturity-Record, Public-Safe Reporting, Stakeholder Formation, Public Narrative, and Correction Steward.

2.2.2.1 The Global Risks Forum shall be understood within NAF as the public-good legitimacy, claims discipline, Registry, recognition-interface, maturity-record, public-safe reporting, stakeholder formation, public narrative, and correction steward. Its NAF-facing role is to preserve public trust, public-safe meaning, claims discipline, registry status truth, correctionability, public-facing records, stakeholder legitimacy, recognition-interface boundaries, maturity-record discipline, and non-execution controls.

2.2.2.2 The Global Risks Forum may support NAF through Registry governance, public-safe reporting review, claims review, recognition-interface records, maturity-record structures, stakeholder-formation processes, public narrative controls, correction notices, public repair, support ledgers, participation records, publication discipline, public-facing knowledgebase controls, Nexus Universe public-good legitimacy processes, and public-safe communication rules.

2.2.2.3 The Global Risks Forum shall not, by virtue of its NAF role, become the technical evidence authority for all methods, the finance-readiness steward, investor-interface body, insurer-interface body, procurement authority, public authority, standards authority, enterprise executor, project developer, operator, contractor, or implementation vehicle. Registry or recognition-interface records shall not create certification, procurement eligibility, financeability, insurability, public authority approval, provider validation, sponsor endorsement, or execution authorization by default.

### 2.2.3 The Global Risks Alliance as Finance-Readiness, Capital-Readability, Insurance-Readiness, Disaster-Risk-Finance, Diligence-Gap, No-Reliance, and Regulated-Perimeter Steward.

2.2.3.1 The Global Risks Alliance shall be understood within NAF as the finance-readiness, capital-readability, insurance-readiness, disaster-risk-finance, diligence-gap, no-reliance, and regulated-perimeter steward. Its NAF-facing role is to make risk, evidence, readiness questions, public-good outputs, National Portfolio needs, Nexus Universe outputs, and lawful handoff dependencies legible to capital readers, insurers, reinsurers, donors, public finance readers, development actors, and other finance-adjacent stakeholders without crossing into regulated financial execution by default.

2.2.3.2 The Global Risks Alliance may support NAF through finance-readiness question records, capital-readability notes, insurance-readiness question records, disaster-risk-finance literacy, protection-gap framing, risk-layering questions, diligence-gap registers, assumptions registers, dependency registers, no-reliance room protocols, capital-reader room controls, insurance-reader room controls, donor-reader room controls, public finance learning room controls, and handoff dependency structures.

2.2.3.3 The Global Risks Alliance shall not, by virtue of its NAF role, provide investment advice, securities solicitation, brokerage, underwriting, lending, insurance approval, guarantee, rating, public finance allocation, procurement recommendation, public authority approval, certification, project execution, or financial transaction execution by default. Finance-readiness and insurance-readiness shall remain question, literacy, dependency, and diligence-context functions unless separately and lawfully undertaken by competent regulated actors.

### 2.2.4 Coordinated Arc Without Merger.

2.2.4.1 The Global Centre for Risk and Innovation, The Global Risks Forum, and The Global Risks Alliance together form a coordinated NAF-facing arc of evidence, legitimacy, and finance-readiness. The arc allows technical evidence to become publicly meaningful, publicly meaningful records to become finance-readable, finance-readable questions to remain non-transactional, and all outputs to remain bounded by role separation, non-execution, correctionability, and lawful handoff discipline.

2.2.4.2 Coordination among the triad shall not constitute merger, legal fusion, shared liability, hidden agency, mutual control, authority transfer, or collapse of mandates. Each institution shall remain legally, operationally, and substantively separate unless a separate lawful instrument expressly states otherwise.

2.2.4.3 The coordinated arc shall operate through recorded interfaces, not assumed authority. Cross-institutional work shall identify the contributing institution, role, scope, record, review status, boundary notice, and correction pathway. No institution shall imply that another has approved, endorsed, certified, financed, insured, procured, authorized, or executed an output unless separately and lawfully recorded.

### 2.2.5 No Hidden Agency, Shared Liability, or Collapsed Authority.

2.2.5.1 NAF shall prohibit hidden agency, shared liability by implication, and collapsed authority among the institutional triad, Nexus pillars, Nexus mechanisms, consortiums, councils, National Working Groups, Competence Cells, National Nodes, public authorities, providers, sponsors, capital readers, insurers, donors, National Consortium Companies, Project SPVs, and lawful implementation actors.

2.2.5.2 A participant, institution, council, working group, cell, sponsor, provider, public authority, investor, insurer, donor, host, university, community actor, or contributor shall not be deemed the agent, partner, representative, fiduciary, contractor, employee, certifier, procuring authority, financier, insurer, regulator, or implementation arm of another actor merely by participating in NAF, appearing in a record, contributing to a Docket item, attending a room, sponsoring an activity, supporting a build, appearing in the Marketplace, being recorded in the Registry, or participating in Nexus Universe.

2.2.5.3 Any actual agency, contractual authority, fiduciary responsibility, employment relationship, procurement authority, regulated financial role, insurance role, public authority delegation, project development role, operational duty, or execution responsibility must be separately and lawfully documented outside NAF’s default public-good operating posture.

### 2.2.6 Role-Separation Records.

2.2.6.1 NAF shall require role-separation records where work crosses institutional, public-good, enterprise, public authority, finance, insurance, sponsor, provider, community, Indigenous, data, or handoff boundaries. Role-separation records shall identify who convenes, who contributes evidence, who reviews, who publishes, who lists, who records status, who provides support, who participates, who reads, who may receive handoff, and who, if anyone, executes outside NAF.

2.2.6.2 Role-separation records shall be maintained for material Docket items, Reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Campaigns, Academy pathways, Foundry builds, Nexus Universe outputs, public authority learning rooms, capital-reader rooms, insurance-reader rooms, sponsor-supported activities, provider-supported activities, and handoff packages.

2.2.6.3 Role-separation records shall prevent public confusion and internal drift. They shall state what each actor did and did not do, what authority each actor did and did not have, what claims may and may not be made, and what correction pathway applies if role boundaries are misstated.

### 2.2.7 Cross-Institution Escalation.

2.2.7.1 NAF shall provide cross-institution escalation pathways for issues that exceed a single pillar, mechanism, council, working group, cell, or institution. Escalation may be required for boundary incidents, role-collapse risks, public authority overclaims, finance or insurance boundary concerns, procurement neutrality issues, sponsor control risks, provider validation risks, data and privacy incidents, AI incidents, cyber incidents, protected knowledge concerns, community or Indigenous consent overclaims, public-safe publication issues, and handoff overclaims.

2.2.7.2 Cross-institution escalation shall be recorded. The record shall identify the issue, affected objects, institutions involved, interim containment measures, claims freeze if required, data freeze if required, technical freeze if required, Marketplace or Registry status changes, public-safe notice needs, handoff recall needs, correction steps, decision authority, and archive requirements.

2.2.7.3 Escalation shall not create new authority beyond the mandates of the relevant institutions. It shall coordinate review, containment, correction, and routing while preserving legal separateness and role boundaries.

### 2.2.8 Boundary Repair and Correction.

2.2.8.1 Boundary repair shall be a required NAF function where role separation, public-good firewall discipline, non-execution, no-conversion, public authority learning boundaries, finance-readiness boundaries, procurement neutrality, sponsor controls, provider controls, community consent boundaries, Indigenous protocol boundaries, data rules, AI rules, cyber rules, or public-safe publication rules are breached, misstated, or at material risk.

2.2.8.2 Boundary repair may include correction notice, claim revision, public-safe clarification, Registry status change, Marketplace delisting, Report amendment, Studio workflow restriction, Grid or TRL downgrade, Campaign claims freeze, handoff recall, participant notice, sponsor notice, provider notice, public authority notice, community-facing correction, archive action, or reinstatement where appropriate.

2.2.8.3 Boundary repair shall be treated as a trust-preserving discipline. NAF shall not conceal role confusion, overclaim, or boundary drift. It shall correct them through records, public-safe notices where appropriate, downstream propagation, and archive.

## 2.3 Pillar Interface Logic

### 2.3.1 Nexus Academy Interface.

2.3.1.1 The Nexus Academy Interface shall connect NAF work to learning pathways, skills development, contributor preparation, workforce resilience, capability formation, public-good literacy, technical training, data and AI literacy, cyber literacy, standards-interface literacy, public-safe reporting literacy, and lawful handoff literacy. NAF shall route Docket items into Nexus Academy where work requires structured learning, participant preparation, micro-credentials, Work-Integrated Learning Paths, mentor support, or capability formation.

2.3.1.2 The Nexus Academy Interface shall produce learning records, Integrated Learning Account entries, micro-credential records where applicable, contribution-to-learning records, learning-object Registry records, Marketplace discovery metadata, Reports inputs, Campaign learning pathways, Foundry contributor pathways, and Nexus Universe preparation records.

2.3.1.3 Nexus Academy outputs shall not create professional licensure, employment status, procurement eligibility, public authority competence, certification, deployment authorization, or execution authority by implication.

### 2.3.2 Risk Academy Interface.

2.3.2.1 The Risk Academy Interface shall connect NAF work to systems-risk literacy, DRR learning, DRF literacy, DRI interpretation, WFEH-B risk learning, public-safe reporting, crisis-learning, after-action learning, public authority learning support, finance-readiness literacy, insurance-readiness literacy, safeguard literacy, and frontier-technology risk literacy.

2.3.2.2 NAF shall route risk-related Docket items to Risk Academy where participants require common language, risk interpretation capacity, public-safe communication discipline, scenario literacy, Observatory literacy, DRI dashboard literacy, or handoff dependency literacy. Risk Academy records shall support ILA, iCRS, Reports, Campaigns, National Portfolios, Nexus Universe, Registry, Marketplace, and Grid inputs where applicable.

2.3.2.3 Risk Academy learning shall not constitute public warning authority, emergency command competence, professional certification, insurance approval, finance advice, public authority approval, or implementation authorization.

### 2.3.3 Risk Agency Interface.

2.3.3.1 The Risk Agency Interface shall connect NAF work to expert routing, advisory support, resilience consulting support, public-safe reporting support, cross-sphere translation, public authority learning support, finance-readiness support, insurance-readiness support, safeguard support, and lawful handoff support.

2.3.3.2 NAF shall route Docket items to Risk Agency where specialist expertise, advisory interpretation, workshop support, scenario interpretation, dashboard literacy, public-safe translation, readiness question mapping, or handoff support is required. Engagement records shall identify request, expert match, conflict status, output class, reliance label, review requirements, correction pathway, and archive rule.

2.3.3.3 Risk Agency outputs shall not create execution, certification, professional license, public authority decision, investment advice, underwriting, procurement preference, consent, or deployment authorization by implication.

### 2.3.4 Nexus Labs Interface.

2.3.4.1 The Nexus Labs Interface shall connect NAF work to research questions, frontier discovery, methods, testbeds, evidence gaps, datasets, models, system cards, benchmark records, scenario records, dual-use review, public-safe publication, research translation, and Labs-to-Foundry pathways.

2.3.4.2 NAF shall route Docket items to Nexus Labs where work requires research design, method development, evidence testing, data analysis, prototype inquiry, simulation inquiry, AI or model evaluation, technology assessment, observability method development, or public-good R\&D. Labs outputs shall be prepared for Reports, Foundry, DICE, GRIx, DRI, Observatory, Studio, Grid, Marketplace, Registry, Nexus Universe, or handoff context as appropriate.

2.3.4.3 Research outputs shall not constitute approval, certification, deployment, public authority decision, financeability, insurability, procurement readiness, consent, or endorsement by implication.

### 2.3.5 Nexus Foundry Interface.

2.3.5.1 The Nexus Foundry Interface shall connect NAF work to public-good production, BuildGrid programs, tracks, quests, bounties, builds, maintainers, review gates, release classes, open technical baselines, software objects, data pipeline builds, dashboard builds, Studio workflow builds, Registry record builds, Marketplace object builds, Reports builds, Grid inputs, TRL notes, National Portfolio builds, Campaign builds, and handoff dependency builds.

2.3.5.2 NAF shall route Docket items to Nexus Foundry where work requires structured production, micro-production, distributed build activity, maintainer stewardship, code or data work, public-good software, reusable technical objects, documentation, public-safe outputs, or handoff package preparation. Foundry outputs shall remain governed by evidence, review, release, support, correction, and handoff boundary rules.

2.3.5.3 Foundry production shall not constitute enterprise execution, deployment authorization, vendor validation, procurement recommendation, warranty, certification, public authority decision, finance approval, insurance approval, or community consent.

### 2.3.6 Nexus Campaigns Interface.

2.3.6.1 The Nexus Campaigns Interface shall connect NAF work to civic mobilization, public-good support, signatures, pledges, volunteers, chapters, ambassadors, team formation, Campaign dashboards, public-safe storytelling, Campaign Dockets, Nexus Universe preparation, National Portfolio activation, Working Group formation, Competence Cell formation, Foundry participation, Academy pathways, Reports inputs, and public-safe reporting.

2.3.6.2 NAF shall route Docket items to Nexus Campaigns where work requires broad mobilization, public-good participation, stakeholder awareness, volunteer engagement, support mobilization, learning activation, national or thematic campaign structure, or Nexus Universe preparation. Campaign records shall include purpose, support, volunteer, pledge, signature, public-safe status, data status, sponsor controls, provider controls, public authority boundaries, consent boundaries, correction, and archive.

2.3.6.3 Campaign participation, signature, pledge, support, visibility, or success shall not create vote, mandate, finance commitment, procurement status, public authority approval, community consent, Indigenous consent, employment, endorsement, or execution authority.

### 2.3.7 Nexus Reports Interface.

2.3.7.1 The Nexus Reports Interface shall connect NAF work to public-safe publication, controlled knowledge products, evidence translation, National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF Reports, DRI Reports, DICE Reports, GRIx Reports, Observatory Reports, Foundry Reports, Campaign Reports, Academy Reports, Labs Reports, Risk Agency Reports, Nexus Universe Reports, Grid and TRL Reports, handoff context notes, correction reports, and archive reports.

2.3.7.2 NAF shall route Docket items to Nexus Reports where evidence requires public-safe interpretation, formal publication, repository deposit, DOI discipline where applicable, metadata preparation, licensing, data availability statements, AI-use statements, controlled knowledge exclusions, correction notice, or archive. Reports shall carry boundary notices and correction pathways.

2.3.7.3 Publication shall not create approval, public warning, certification, financeability, insurability, procurement readiness, country ranking, provider validation, community consent, public authority decision, or execution authority.

### 2.3.8 Nexus Marketplace Interface.

2.3.8.1 The Nexus Marketplace Interface shall connect NAF work to discovery of public-good objects, learning opportunities, Campaigns, Foundry outputs, software, data, models, Reports, Studio workflows, National Portfolio objects, DICE objects, GRIx objects, DRI objects, Observatory objects, Grid and TRL objects, and handoff context objects.

2.3.8.2 NAF shall route objects to Nexus Marketplace when they are suitable for discovery under recorded metadata, release class, access class, support class, Registry status, public-safe status, license status, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, correction pathway, and archive rule.

2.3.8.3 Marketplace listing, featuring, download, interest signal, reuse signal, support request, or handoff relevance shall not create procurement recommendation, endorsement, validation, warranty, finance commitment, investment signal, insurance approval, public authority approval, deployment authorization, or execution authority.

### 2.3.9 Nexus Registry Interface.

2.3.9.1 The Nexus Registry Interface shall connect NAF work to status truth, object identity, lifecycle records, version records, support status, review status, data-use labels, AI-use labels, release classes, provider contribution records, sponsor support records, public authority participation records, correction records, withdrawal records, recall records, archive records, and non-continuation records.

2.3.9.2 NAF shall route outputs to Nexus Registry where status truth is required for public-good records, Marketplace discovery, Reports publication, Grid inputs, TRL notes, Studio workflows, Foundry outputs, Campaign objects, Academy learning objects, National Portfolio objects, Nexus Universe outputs, or handoff packages.

2.3.9.3 Registry status shall not create certification, approval, compliance determination, public authority action, financeability, insurability, procurement eligibility, provider validation, endorsement, deployment authorization, or execution authority.

### 2.3.10 Nexus Studio Interface.

2.3.10.1 The Nexus Studio Interface shall connect NAF work to controlled runtime environments, dashboards, simulations, digital twins, AI workflows, secure-room workflows, data-room workflows, public authority learning workflows, readiness-room workflows, capital-reader room workflows, insurance-reader room workflows, Nexus Universe demonstrations, and handoff demonstrations.

2.3.10.2 NAF shall route Docket items to Nexus Studio where work requires controlled demonstration, scenario learning, digital twin interpretation, dashboard review, AI output review, data workflow review, secure-room activity, public authority learning, readiness-room preparation, or handoff demonstration. Studio records shall include data basis, model basis, assumptions, uncertainty, confidence where applicable, access controls, no-write-back rules, no-command rules, output review, logging, shutdown triggers, correction triggers, and archive rules.

2.3.10.3 Studio activity shall not constitute deployment, simulation certification, public authority decision, AI determination, operational command, finance approval, insurance underwriting, procurement status, or execution.

### 2.3.11 Nexus Grid Interface.

2.3.11.1 The Nexus Grid Interface shall connect NAF work to maturity inputs, review routing, evidence sufficiency, support status, readiness classes, TRL 1–10 notes, assurance without certification, downgrade, suspension, withdrawal, reinstatement, and correction memory.

2.3.11.2 NAF shall route outputs to Nexus Grid where readiness status, review sufficiency, evidence quality, data status, AI-use status, cyber status, public-safe status, safeguard status, support status, repository status, Marketplace status, Registry status, or handoff dependency status must be recorded.

2.3.11.3 Grid status and TRL notes shall not constitute certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, maturity certification, or legal compliance determination.

### 2.3.12 Nexus Observatory Interface.

2.3.12.1 The Nexus Observatory Interface shall connect NAF work to observability, signals, indicators, sensors, edge signals, geospatial signals, Earth observation signals, digital twin needs, regional clusters, national dense Nexus cores, degraded-mode awareness, and public-safe observability outputs.

2.3.12.2 NAF shall route Observatory signals into Dockets, DRI records, GRIx categories, DICE objects, Studio workflows, Reports, Grid inputs, Marketplace listings, Registry records, Nexus Universe arenas, National Portfolios, and handoff contexts as appropriate. Observatory outputs shall include source notes, confidence labels, uncertainty labels, sensitivity labels, public-safe classifications, and correction pathways.

2.3.12.3 Observatory signals shall not constitute surveillance authority, public warning, emergency command, official map, legal classification, insurance score, investment signal, public authority decision, or execution instruction.

### 2.3.13 Nexus Universe Interface.

2.3.13.1 The Nexus Universe Interface shall connect NAF work to the annual public-good systems-build cycle, Nexus Core Build, arenas, rooms, public authority learning concentration, National Portfolio convergence, Foundry build concentration, Campaign mobilization, Academy and Labs concentration, Marketplace and Registry discovery, Reports publication, Grid and TRL visibility, and lawful handoff preparation.

2.3.13.2 NAF shall route eligible National Portfolio objects, Campaign outputs, Foundry builds, Studio workflows, Reports, Registry records, Marketplace listings, DRI and Observatory records, public authority learning questions, finance-readiness questions, insurance-readiness questions, safeguard records, and handoff dependency notes into Nexus Universe where they can be reviewed, demonstrated, discussed, corrected, continued, archived, or prepared for lawful handoff.

2.3.13.3 Nexus Universe participation, visibility, arena presentation, public authority attendance, sponsor presence, provider demonstration, capital-reader room participation, insurance-reader room participation, or media visibility shall not create endorsement, approval, finance, insurance, procurement, certification, consent, public warning, public authority action, or execution.

### 2.3.14 Nexus Rails Interface.

2.3.14.1 The Nexus Rails Interface shall connect NAF work to routing pathways across Nexus pillars, mechanisms, institutions, national nodes, regional clusters, global layers, public-good records, controlled rooms, repositories, Registry, Marketplace, Reports, Studio, Grid, Nexus Universe, and lawful handoff channels.

2.3.14.2 Rails shall record where work came from, where it is going, what conditions apply, what dependencies remain, what release class governs movement, what safeguards apply, what public-safe status applies, what data or AI restrictions apply, and what correction pathway must follow the object downstream.

2.3.14.3 Rails routing shall not create approval, authorization, procurement status, financeability, insurability, certification, consent, deployment, or execution. Routing means controlled movement, not legal effect beyond the record.

### 2.3.15 Nexus Network Interface.

2.3.15.1 The Nexus Network Interface shall connect NAF work to permanent memory, public-good infrastructure, records preservation, cross-cycle continuity, institutional learning, national-to-global knowledge exchange, archive, correction history, and reusable public-good capability.

2.3.15.2 NAF shall route durable outputs into Nexus Network where they require persistence, discoverability, continuity, correction history, institutional memory, cross-cycle reuse, national localization, or future Nexus Universe preparation. Nexus Network records shall preserve not only successful outputs but also corrected, withdrawn, superseded, archived, and non-continuing objects.

2.3.15.3 Nexus Network memory shall not convert archived or historical records into current authority. Network preservation shall support learning and traceability, not certification, approval, implementation authorization, or public authority action.

### 2.3.16 Nexus Core Build Interface.

2.3.16.1 The Nexus Core Build Interface shall connect NAF work to the concentrated technical and institutional build environment through which annual public-good surge capacity is assembled, tested, demonstrated, documented, reviewed, and preserved. Nexus Core Build shall operate as a temporary stack with permanent record, annual surge with year-round continuity, open contribution with controlled release, and technical excellence with institutional memory.

2.3.16.2 NAF shall route Core Build work through Dockets, Foundry, Studio, DICE, GRIx, DRI, Observatory, Reports, Marketplace, Registry, Grid, TRL, Academy, Campaigns, National Portfolios, Nexus Universe, Rails, and Network as appropriate. Core Build outputs shall record scope, methods, evidence, data status, AI-use status, cyber status, public-safe status, support class, release class, correction pathway, and archive rule.

2.3.16.3 Nexus Core Build shall not create deployment authorization, operational command, service warranty, procurement preference, provider validation, sponsor control, public authority approval, financeability, insurability, certification, consent, or execution.

### 2.3.17 National Nodes Interface.

2.3.17.1 The National Nodes Interface shall connect NAF work to national localization, national repositories, national stakeholder routing, national data and language conditions, national public authority learning, national Working Groups, national Competence Cells, national Campaigns, national Reports, national Registry and Marketplace records, national DRI and Observatory contributions, national Academy pathways, national Nexus Universe preparation, and lawful national handoff.

2.3.17.2 National Nodes shall preserve national ownership and local continuity. They may host or coordinate national records, localized public-safe outputs, national software or data mirrors, learning pathways, Campaigns, Studio workflows, Grid inputs, National Portfolio records, and handoff dependencies. They shall not act as public authorities, procurement bodies, funders, insurers, certifiers, regulators, operators, or execution vehicles by default.

2.3.17.3 National Node status shall not imply government adoption, public authority approval, national endorsement, financeability, procurement eligibility, insurance approval, community consent, Indigenous consent, or deployment authorization.

## 2.4 Mechanism Interface Logic

### 2.4.1 Integrated Learning Account Interface.

2.4.1.1 The Integrated Learning Account Interface shall connect NAF work to learner records, capability pathways, micro-credentials where applicable, contribution evidence, Work-Integrated Learning Paths, Academy participation, Risk Academy participation, Foundry contribution, Campaign participation, Studio exercises, public authority learning participation, safeguard learning, and portable skills records.

2.4.1.2 NAF shall record learning activity through the Integrated Learning Account where learning has evidentiary or pathway relevance. Such records may support contributor routing, competence development, National Portfolio capability formation, Nexus Universe talent visibility, and lawful handoff context.

2.4.1.3 Integrated Learning Account records shall not create professional licensure, employment status, wage entitlement, immigration status, public authority approval, procurement eligibility, certification, deployment authority, or execution authority by implication.

### 2.4.2 Integrated Credits and Rewards System Interface.

2.4.2.1 The Integrated Credits and Rewards System Interface shall connect NAF work to contribution recognition, public-good work memory, learning credit, review credit, mentor credit, bounty recognition, support-linked recognition, non-monetary recognition, and correction of credits.

2.4.2.2 NAF shall use iCRS to recognize contribution without converting contribution into currency, wage, employment, equity, token, procurement qualification, professional credential, authority, or finance claim by default. iCRS records shall support motivation, transparency, contributor memory, public-good value reporting, and correction.

2.4.2.3 iCRS recognition shall remain bounded by contribution records, review status, support class, public display controls, privacy rules, conflict controls, sponsor and provider controls, and correction pathways.

### 2.4.3 Work-Integrated Learning Paths Interface.

2.4.3.1 The Work-Integrated Learning Paths Interface shall connect NAF work to evidence-bearing learning through practice. WILPs may occur through Academy, Risk Academy, Foundry, Campaigns, National Working Groups, Competence Cells, Studio, Labs, Risk Agency, public authority learning rooms, employers, universities, community hosts, National Nodes, National Consortium Companies, or Project SPV interfaces where lawful and bounded.

2.4.3.2 WILPs shall record learning agreement, scope, workplan, mentor role, supervision level, health and safety conditions, data and confidentiality controls, AI and tool-use controls, fair work controls, accessibility controls, safeguard controls, output records, mentor verification, host verification where applicable, correction, grievance, and archive.

2.4.3.3 WILP participation shall not create employment, hiring commitment, procurement qualification, public authority decision, professional license, deployment authorization, community consent, Indigenous consent, or execution authority by implication.

### 2.4.4 Micro-Production Model Interface.

2.4.4.1 The Micro-Production Model Interface shall connect NAF work to scoped micro-tasks, micro-bounties, micro-builds, micro-reviews, micro-releases, micro-corrections, and micro-archives. It enables distributed contributors to produce useful public-good outputs without losing scope discipline, labor boundary discipline, review discipline, or correctionability.

2.4.4.2 Micro-production shall be routed through Dockets, Foundry, Campaigns, Academy, DICE, GRIx, DRI, Reports, Studio, Marketplace, Registry, Grid, TRL, National Portfolios, Nexus Universe, and handoff preparation where appropriate. Each micro-production object shall have scope, evidence expectations, acceptance criteria, review status, support class, contribution record, release class, and correction pathway.

2.4.4.3 Micro-production shall not create disguised labor, employment, procurement qualification, vendor validation, certification, deployment authorization, or execution by contribution.

### 2.4.5 Integrated Value Reporting System Interface.

2.4.5.1 The Integrated Value Reporting System Interface shall connect NAF work to public-good value, learning value, evidence value, risk-reduction value, resilience value, contribution value, support value, national capability value, correction value, and archive value. It shall enable Nexus to understand value without reducing public-good work to financial valuation.

2.4.5.2 Integrated value records may support Reports, National Portfolios, Campaigns, Academy pathways, Foundry outputs, Marketplace discovery, Registry status, Grid inputs, Nexus Universe records, public authority learning, finance-readiness questions, and handoff dependency packages.

2.4.5.3 Integrated value reporting shall not constitute financial statements, investment valuation, economic impact certification, procurement score, country ranking, provider validation, public authority assessment, or financeability claim by default.

### 2.4.6 DICE Interface.

2.4.6.1 The DICE Interface shall connect NAF work to data commons, innovation commons, software commons, knowledge commons, guild commons, secure rooms, data rooms, clean rooms, compute-to-data workflows, public-good digital economy infrastructure, and digital public-good object governance.

2.4.6.2 NAF shall route data, software, model, knowledge, learning, Campaign, Studio, Registry, Marketplace, Grid, TRL, Observatory, DRI, GRIx, Reports, and handoff objects through DICE where commons governance, metadata, lineage, rights review, data-use labeling, AI-use labeling, access controls, public-safe transformation, or controlled-room handling is required.

2.4.6.3 DICE availability shall not create data rights, unrestricted reuse, open-data status, public authority approval, deployment permission, AI training permission, or handoff permission beyond the recorded access class and use conditions.

### 2.4.7 GRIx Interface.

2.4.7.1 The GRIx Interface shall connect NAF work to risk ontology, controlled vocabulary, risk categories, WFEH-B categories, DRR categories, DRF categories, DRI categories, systems-risk categories, frontier-technology risk categories, public authority boundary categories, finance and insurance boundary categories, safeguard categories, and handoff dependency categories.

2.4.7.2 NAF shall route risk meaning through GRIx so that Dockets, Reports, Campaigns, Foundry work, Academy pathways, DRI records, Observatory signals, Studio workflows, Grid inputs, Marketplace listings, Registry records, National Portfolios, Nexus Universe outputs, and handoff packages use consistent and correctionable terminology.

2.4.7.3 GRIx categories shall not constitute legal classification, insurance rating, investment signal, public authority determination, certification, procurement score, public warning, or standards authority by default.

### 2.4.8 DRI Interface.

2.4.8.1 The DRI Interface shall connect NAF work to disaster risk intelligence, indicators, signals, confidence labels, uncertainty labels, dashboard records, hotspot records, multi-hazard records, cascade records, national DRI contributions, public-safe intelligence summaries, correction records, and archive records.

2.4.8.2 NAF shall route DRI outputs to Reports, Studio, Observatory, GRIx, DICE, Grid, Marketplace, Registry, National Portfolios, Nexus Universe, public authority learning rooms, capital-reader rooms, insurance-reader rooms, and handoff context where appropriate.

2.4.8.3 DRI output shall not constitute public warning, official forecast, emergency command, insurance score, investment signal, country ranking, public authority decision, or deployment instruction.

### 2.4.9 Proof Receipts Interface.

2.4.9.1 The Proof Receipts Interface shall connect NAF work to verifiable records of participation, contribution, review, release, support, handoff, correction, archive, and other bounded actions. Proof Receipts may support validity-by-record, auditability, public-safe reporting, contributor recognition, Registry records, Marketplace metadata, Grid inputs, TRL notes, Nexus Universe outputs, and handoff dependency packages.

2.4.9.2 Proof Receipts shall record that something occurred within a defined scope; they shall not certify the substantive truth, legal sufficiency, safety, quality, compliance, financeability, insurability, procurement eligibility, public authority approval, consent, or execution status of the underlying activity unless expressly and lawfully recorded by a competent authority.

### 2.4.10 Dockets Interface.

2.4.10.1 The Dockets Interface shall connect all NAF work to structured work movement. Dockets shall receive signals, convert records into work, route work into pathways, preserve scope, assign stewardship, identify review gates, classify sensitivity, record boundary notices, track release classes, capture correction pathways, and preserve archive rules.

2.4.10.2 Dockets may be public-good, national, regional, global, Universe, Foundry, Campaign, Academy, Labs, Reports, Studio, Grid and TRL, handoff, or correction Dockets. Docket types may interoperate but shall preserve source, scope, review, release, and correction continuity.

2.4.10.3 Docketing shall not create approval, authorization, endorsement, finance, procurement, certification, consent, deployment, public warning, or execution. It creates governed movement.

### 2.4.11 Support Ledgers Interface.

2.4.11.1 The Support Ledgers Interface shall connect NAF work to recorded support from sponsors, hosts, providers, donors, volunteers, institutions, technical contributors, infrastructure contributors, compute contributors, community contributors, and other supporters. Support Ledgers shall identify what support was provided, by whom, under what conditions, with what limitations, and under what boundary notices.

2.4.11.2 Support Ledgers shall prevent support from becoming control. Sponsor support, provider contribution, host support, donor support, cloud support, compute support, venue support, media support, or expert support shall not confer Docket control, review control, Registry control, Marketplace placement control, public authority influence, finance-readiness control, handoff routing control, or public narrative control.

### 2.4.12 Assumptions Registers Interface.

2.4.12.1 The Assumptions Registers Interface shall connect NAF work to recorded assumptions underlying evidence, methods, models, simulations, digital twins, forecasts, scenarios, finance-readiness questions, insurance-readiness questions, infrastructure plans, National Portfolios, Studio workflows, Grid inputs, TRL notes, Reports, and handoff packages.

2.4.12.2 Assumptions shall be explicit, reviewable, revisable, and correctable. Unrecorded assumptions shall not support strong claims. Where assumptions materially affect readiness, public-safe interpretation, finance-readiness, insurance-readiness, public authority learning, or handoff, they shall be identified in the relevant output.

### 2.4.13 Dependency Registers Interface.

2.4.13.1 The Dependency Registers Interface shall connect NAF work to dependencies, including evidence dependencies, data dependencies, compute dependencies, software dependencies, model dependencies, public authority dependencies, legal dependencies, safeguard dependencies, finance and insurance dependencies, procurement dependencies, infrastructure dependencies, community dependencies, Indigenous protocol dependencies where applicable, standards-interface dependencies, support dependencies, and handoff dependencies.

2.4.13.2 Dependencies shall be recorded before claims are made. A dependency record shall clarify what must be satisfied by whom, under what authority, within what scope, and before which downstream use, release, public-safe claim, readiness note, or handoff can be treated as appropriate.

### 2.4.14 Diligence-Gap Registers Interface.

2.4.14.1 The Diligence-Gap Registers Interface shall connect NAF work to gaps that capital readers, insurers, donors, public finance readers, procurement actors, public authorities, National Consortium Companies, Project SPVs, providers, operators, or other lawful recipients would need to evaluate independently before implementation, finance, insurance, procurement, approval, or execution.

2.4.14.2 Diligence-gap records shall improve legibility without becoming diligence completion. A Diligence-Gap Register identifies missing or unresolved questions; it does not answer them for reliance, approve investment, approve insurance, approve procurement, or authorize implementation.

### 2.4.15 Correction Registers Interface.

2.4.15.1 The Correction Registers Interface shall connect NAF work to correction records, errata, addenda, supersession, downgrade, suspension, withdrawal, retraction where necessary, recall, public repair, archive, and correction propagation. Correction Registers shall identify affected objects, affected claims, downstream dependencies, action taken, date, steward, public-safe notice needs, and archive status.

2.4.15.2 Correction Registers shall be used across Reports, Registry, Marketplace, Studio, Grid, TRL, Foundry, Academy, Campaigns, Labs, Risk Agency, DICE, GRIx, DRI, Observatory, Nexus Universe, National Portfolios, and handoff packages. Correction shall preserve trust through visibility and propagation.

### 2.4.16 Archive Registers Interface.

2.4.16.1 The Archive Registers Interface shall connect NAF work to historical preservation, non-current notices, successor links, access class, retention rules, license status, public-safe status, correction history, withdrawal history, support status, and permitted historical use.

2.4.16.2 Archive Registers shall prevent obsolete materials from being mistaken for current authority. Archived outputs may support learning, transparency, audit, institutional memory, and future research, but shall not be treated as active approval, current status, current guidance, current readiness, or implementation authority unless reinstated through recorded review.

## 2.5 Consortium and Enterprise Interfaces

### 2.5.1 Global Nexus Consortium Interface.

2.5.1.1 The Global Nexus Consortium Interface shall connect NAF work to global agenda formation, universal participation architecture, global public-good records, Nexus Universe preparation, standards-interface discipline, regional routing, global Campaign alignment, global Foundry priorities, global Reports, global Registry and Marketplace structures, and global correction memory.

2.5.1.2 The Global Nexus Consortium may support common rail formation, cross-regional learning, global stakeholder formation, global public-safe reporting, global Nexus Universe agenda, global capability mobilization, and global-to-regional routing. It shall not create global supremacy, national override, public authority action, finance allocation, procurement status, certification, endorsement, consent, or execution authority.

### 2.5.2 Regional Nexus Consortium Interface.

2.5.2.1 The Regional Nexus Consortium Interface shall connect NAF work to regional clusters, regional translation, country support, regional systems-risk mapping, regional Nexus Universe preparation, regional standards localization, regional observability, regional finance-readiness questions, and regional public-safe reporting.

2.5.2.2 Regional Nexus Consortiums shall support national pathways without bypassing them. Regional coordination shall not create regional authority over countries, public authority approval, procurement status, finance approval, insurance approval, certification, consent, or implementation authorization.

### 2.5.3 National Nexus Consortium Interface.

2.5.3.1 The National Nexus Consortium Interface shall connect NAF work to country-level ownership, national stakeholder formation, National Portfolios, National Councils, National Working Groups, Nexus Competence Cells, National Nodes, national public authority learning, national Campaigns, national Reports, national Registry and Marketplace records, national Nexus Universe participation, and lawful handoff pathways.

2.5.3.2 National Nexus Consortiums shall be the normal gateway for country-level Nexus activity. They shall not act as public authorities, procurement bodies, certifiers, financiers, insurers, operators, project developers, or execution vehicles by default unless separately and lawfully constituted for a specific function.

### 2.5.4 National Council Interface.

2.5.4.1 The National Council Interface shall connect NAF work to stakeholder formation, leadership pools, investor and insurer literacy pathways, helix participation, public authority learning questions, Working Group formation, Campaign topics, National Portfolio inputs, Nexus Universe preparation, and public-safe reporting.

2.5.4.2 National Council participation shall be recorded as participation, not authority. It shall not imply board appointment, public authority approval, procurement, finance, insurance, donor commitment, certification, endorsement, consent, employment, or execution.

### 2.5.5 National Leadership Council Interface.

2.5.5.1 The National Leadership Council Interface shall connect NAF work to national leadership formation, strategic agenda signals, public-good priorities, public authority learning needs, institutional participation, National Portfolio direction, Working Group sponsorship, Campaign alignment, Nexus Universe preparation, and correction oversight.

2.5.5.2 National Leadership Council participation shall not create authority to bind public authorities, enterprises, communities, funders, insurers, universities, sponsors, providers, National Consortium Companies, Project SPVs, or Nexus institutions unless separately and lawfully recorded.

### 2.5.6 National Investors Council Interface.

2.5.6.1 The National Investors Council Interface shall connect NAF work to finance-readiness, capital-readability, insurance-readiness, donor-readiness, public finance relevance, diligence-gap identification, risk-to-capital translation, SPV-readiness questions, no-reliance room discipline, and regulated-perimeter controls.

2.5.6.2 The National Investors Council shall be a capital-readiness participation surface, not a fund, broker, dealer, investment adviser, underwriter, lender, insurer, reinsurer, guarantee provider, donor allocation body, public finance body, securities platform, transaction room, rating agency, procurement body, certification body, public authority, National Consortium Company, Project SPV, or execution vehicle by default.

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

### 2.5.7 Helix Council Interface.

2.5.7.1 The Helix Council Interface shall connect NAF work to structured participation by public authorities, academia, industry, civil society, communities, media, youth, capital readers, insurers, donors, and other relevant stakeholder families according to the applicable national design. Helix Councils shall help generate public-good intelligence, participation records, capability needs, Campaign topics, Working Group candidates, Nexus Universe pathways, and National Portfolio inputs.

2.5.7.2 Helix participation shall not create endorsement, public authority approval, procurement, finance, insurance, donor commitment, consent, professional status, employment, or execution. It shall be participation before authority.

### 2.5.8 National Working Group Interface.

2.5.8.1 The National Working Group Interface shall connect NAF work to national workplans, evidence gaps, challenge briefs, public authority learning questions, technology-readiness questions, Campaign-to-work routing, Academy pathway needs, Foundry quest scopes, DICE needs, GRIx and DRI work, Observatory inputs, Reports, Grid inputs, Nexus Universe preparation, and handoff dependency notes.

2.5.8.2 National Working Groups shall operate within recorded mandates. They shall not create public authority decisions, procurement recommendations, finance approvals, insurance approvals, certification, consent, employment, or execution authority.

### 2.5.9 Nexus Competence Cell Interface.

2.5.9.1 The Nexus Competence Cell Interface shall connect NAF work to applied specialist capacity, localized production, technical review, public-good software, data work, model review, Studio workflows, Reports, Grid inputs, TRL notes, National Portfolio support, Nexus Universe preparation, and handoff context.

2.5.9.2 Competence Cell outputs shall be evidence-bearing and reviewable. They shall not be treated as deployment, certification, procurement qualification, professional license, public authority approval, finance approval, insurance approval, consent, or execution by default.

### 2.5.10 National Consortium Company Interface.

2.5.10.1 The National Consortium Company Interface shall connect NAF work to legally separate enterprise-stack vehicles that may, where lawfully constituted and authorized, receive public-good handoff context for implementation consideration, project development, contracting, operations, financing, or other enterprise activity. The National Consortium Company shall be separate from public-good consortium governance, GCRI, The Global Risks Forum, The Global Risks Alliance, Nexus public-good pillars, public authorities, and default NAF work movement.

2.5.10.2 Handoff to a National Consortium Company shall require recorded scope, evidence context, dependencies, public authority conditions, procurement boundaries, finance and insurance questions, provider-neutrality conditions, sponsor-boundary notes, safeguard conditions, recipient responsibilities, correction pathway, recall pathway, and archive rule.

2.5.10.3 National Consortium Company status shall not retroactively convert public-good work into enterprise execution, public authority approval, procurement status, certification, financeability, insurance approval, consent, or endorsement.

### 2.5.11 Project SPV Interface.

2.5.11.1 The Project SPV Interface shall connect NAF work to legally separate project-specific enterprise vehicles where a lawful implementation pathway may require ring-fenced project governance, financing, contracting, operations, risk allocation, insurance, procurement, public authority approvals, or delivery responsibilities. Project SPVs shall be recipients of handoff context, not public-good institutions by default.

2.5.11.2 Handoff to a Project SPV shall be recorded through a lawful handoff dependency package. The Project SPV shall remain responsible for independent diligence, finance, insurance, procurement, approvals, safeguards, community processes, technical implementation, operational controls, and legal compliance.

2.5.11.3 Project SPV formation or visibility shall not imply Nexus endorsement, public authority approval, procurement award, investment approval, insurance approval, certification, consent, or execution authorization by NAF.

### 2.5.12 Provider, Sponsor, Host, Operator, and Lawful Implementation Actor Interfaces.

2.5.12.1 Provider, sponsor, host, operator, and lawful implementation actor interfaces shall be governed by role separation, conflict controls, support ledgers, contribution records, provider-neutrality records, sponsor-boundary records, procurement-neutrality records, public authority boundary records, and correction pathways.

2.5.12.2 Providers may contribute technical knowledge, infrastructure, software, data tools, demonstrations, documentation, or support without being validated. Sponsors may support public-good activity without control. Hosts may provide venues, environments, infrastructure, or convening support without authority over outcomes. Operators and implementation actors may receive handoff context but remain responsible for lawful execution outside NAF.

2.5.12.3 Participation by any provider, sponsor, host, operator, or implementation actor shall not create endorsement, certification, procurement status, provider validation, sponsor ownership, public authority approval, financeability, insurance approval, consent, or execution authority by implication.

## 2.6 Public-Good Stack / Enterprise-Stack Architecture

### 2.6.1 Public-Good Stack Defined.

2.6.1.1 The Public-Good Stack is the Nexus layer in which signals, learning, evidence, methods, research, public-good software, open technical baselines, DICE objects, GRIx structures, DRI records, Observatory signals, Campaign objects, Reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Nexus Universe outputs, National Portfolio memory, correction records, and archive records are created, reviewed, routed, published, preserved, and corrected under public-good discipline.

2.6.1.2 The Public-Good Stack shall be non-executing by default. It exists to create shared capability, public-safe knowledge, evidence, literacy, readiness context, stakeholder formation, digital public goods, standards-interface awareness, and lawful handoff context. It shall not procure, finance, insure, regulate, certify, command, approve, deploy, operate, or execute projects by implication.

### 2.6.2 Enterprise Stack Defined.

2.6.2.1 The Enterprise Stack is the separate lawful implementation layer in which competent actors may undertake project development, procurement, contracting, financing, insurance, permitting, construction, deployment, operations, maintenance, service delivery, commercialization, enterprise support, or other execution activity under their own legal authority and accountability.

2.6.2.2 The Enterprise Stack may include National Consortium Companies, Project SPVs, providers, operators, contractors, enterprises, funders, insurers, donors, universities, public authorities, community actors where appropriate, and other lawful implementation actors. These actors may receive NAF handoff context, but they do not receive automatic authority from NAF.

### 2.6.3 Interface Rules.

2.6.3.1 The interface between the Public-Good Stack and the Enterprise Stack shall be controlled by handoff records, dependency registers, role-separation records, public authority dependency records, finance and insurance question records, procurement-neutrality notices, provider-neutrality notes, sponsor-boundary notes, safeguard records, support class records, correction pathways, recall pathways, and archive rules.

2.6.3.2 No Public-Good Stack output shall silently cross into Enterprise Stack execution. Every crossing shall be recorded, bounded, and subject to independent recipient responsibility.

### 2.6.4 Handoff Conditions.

2.6.4.1 Handoff conditions shall include sufficient scope definition, evidence context, method context, data status, AI-use status, cyber status, public-safe status, safeguard status, review status, support class, Registry status where applicable, Marketplace status where applicable, Grid or TRL context where applicable, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathway, and recall pathway.

2.6.4.2 Handoff conditions shall not be satisfied merely by interest, visibility, urgency, sponsorship, provider readiness, capital-reader presence, public authority attendance, Campaign success, or Nexus Universe presentation.

### 2.6.5 No-Conversion Controls.

2.6.5.1 No-conversion controls shall ensure that Public-Good Stack work does not convert into certification, procurement, finance, insurance, public authority action, public warning, community consent, Indigenous consent, provider validation, sponsor control, deployment authorization, or execution by implication.

2.6.5.2 No-conversion controls shall be embedded in Dockets, Reports, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Campaign records, Academy records, Foundry outputs, Nexus Universe outputs, public authority learning records, capital-reader room records, insurance-reader room records, and handoff packages.

### 2.6.6 National Company and SPV Separation.

2.6.6.1 National Consortium Companies and Project SPVs shall be legally and operationally separate from public-good consortiums, councils, Working Groups, Competence Cells, Nexus public-good institutions, GCRI, The Global Risks Forum, The Global Risks Alliance, public authorities, providers, sponsors, and NAF by default.

2.6.6.2 Their involvement in implementation shall not alter the public-good character of upstream NAF records. Upstream evidence, reports, software, data, Registry records, Marketplace listings, Studio workflows, Grid inputs, TRL notes, Nexus Universe outputs, and National Portfolio memory shall remain bounded by their original records unless separately updated through lawful handoff and correction processes.

### 2.6.7 Provider and Sponsor Boundaries.

2.6.7.1 Providers and sponsors may support the Public-Good Stack, but shall not control it. Provider contribution shall not create validation. Sponsor support shall not create ownership. Support shall be recorded, transparent where appropriate, bounded, conflict-reviewed, and correctionable.

2.6.7.2 Provider or sponsor involvement shall not determine Docket priority, evidence outcome, public-safe conclusions, Registry status, Marketplace placement, Grid or TRL status, public authority learning content, finance-readiness framing, procurement routing, handoff recipient selection, or Nexus Universe visibility except through neutral and recorded processes.

### 2.6.8 Public Authority Boundaries.

2.6.8.1 Public authorities may participate in NAF for learning, observation, evidence review, policy intelligence, risk understanding, National Portfolio dialogue, Nexus Universe participation, Studio workflows, readiness questions, and handoff dependency review. Such participation shall not create official action unless separately and lawfully taken by the public authority.

2.6.8.2 NAF shall record public authority dependencies, but it shall not assume approvals, permits, licenses, public finance allocation, public warnings, emergency commands, regulatory determinations, procurement decisions, or policy adoption.

### 2.6.9 Capital-Reader and Insurer Boundaries.

2.6.9.1 Capital readers, insurers, reinsurers, donors, and public finance readers may participate in no-reliance rooms, readiness discussions, diligence-gap mapping, risk-to-capital translation, and handoff dependency review. Their presence shall not create investment interest, capital commitment, insurance underwriting, donor commitment, public finance allocation, financeability, bankability, insurability, rating, or transaction status.

2.6.9.2 NAF shall preserve regulated-perimeter discipline. Finance-readiness and insurance-readiness shall remain records of questions, dependencies, assumptions, evidence gaps, and diligence needs unless separately undertaken by competent regulated actors.

### 2.6.10 Community, Indigenous, and Protected-Knowledge Boundaries.

2.6.10.1 Community participation, Indigenous participation, civil society participation, youth participation, local knowledge contribution, lived-risk contribution, and protected knowledge handling shall be governed by safeguard, consent-boundary, privacy, public-safe, data sovereignty, and protected knowledge rules.

2.6.10.2 Community participation shall not imply consent. Indigenous participation shall not imply Indigenous consent. Protected knowledge shall not be opened merely because it enters a NAF pathway. Sensitive knowledge shall be controlled, masked, generalized, restricted, sealed, or withheld from public release where required.

## 2.7 Role-Separated Operating Model

### 2.7.1 Convening Roles.

2.7.1.1 Convening roles include the functions of assembling participants, framing agendas, creating rooms, organizing councils, initiating Campaigns, preparing Nexus Universe arenas, supporting National Portfolio dialogue, and enabling stakeholder formation. Convening shall not create authority over outcomes.

2.7.1.2 Conveners shall record purpose, participants, scope, claims limits, public authority boundaries, sponsor and provider boundaries, data rules, safeguard conditions, and correction pathways. Convening shall not imply endorsement, approval, mandate, procurement, finance, insurance, certification, consent, or execution.

### 2.7.2 Evidence Roles.

2.7.2.1 Evidence roles include research, data collection, method design, analysis, model review, system review, benchmark preparation, Observatory signal interpretation, DRI indicator preparation, Studio scenario support, public-safe evidence translation, and evidence pack assembly.

2.7.2.2 Evidence actors shall record sources, methods, assumptions, limitations, data status, AI-use status, review status, uncertainty, confidence where applicable, public-safe status, safeguard status, and correction pathway. Evidence roles shall not create approval, certification, public warning, financeability, procurement status, or execution.

### 2.7.3 Learning Roles.

2.7.3.1 Learning roles include teaching, mentoring, curriculum design, micro-credentialing where applicable, Work-Integrated Learning Path supervision, Risk Academy literacy, contributor onboarding, public authority learning support, Studio exercise support, and Nexus Universe preparation.

2.7.3.2 Learning roles shall not create professional license, employment, public authority competence, procurement eligibility, certification, deployment authority, or execution by implication.

### 2.7.4 Production Roles.

2.7.4.1 Production roles include Foundry build work, software development, data pipeline development, dashboard development, Studio workflow build, Reports drafting, Campaign object production, Registry record preparation, Marketplace object preparation, Grid input preparation, TRL note preparation, National Portfolio object preparation, and handoff package assembly.

2.7.4.2 Production roles shall produce public-good outputs under recorded scope, evidence expectations, review gates, release classes, support classes, correction pathways, and handoff boundaries. Production shall not equal enterprise execution by default.

### 2.7.5 Registry Roles.

2.7.5.1 Registry roles include status recording, lifecycle recording, version recording, review recording, support status recording, data-use and AI-use recording, provider contribution recording, sponsor support recording, public authority participation recording, correction recording, withdrawal recording, recall recording, archive recording, and non-continuation recording.

2.7.5.2 Registry roles shall preserve status truth without certifying by default. Registry stewards shall not overstate active status, supported status, review status, maturity status, or public-safe status as certification, approval, financeability, procurement eligibility, deployment authorization, or execution authority.

### 2.7.6 Marketplace Roles.

2.7.6.1 Marketplace roles include listing review, metadata preparation, discovery support, license review, support class review, public-safe review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, correction, delisting, and archive.

2.7.6.2 Marketplace roles shall enable discovery without endorsement. Marketplace stewards shall prevent listings, featured placements, download metrics, support signals, or handoff relevance from being represented as approval, procurement recommendation, provider validation, financeability, insurability, or execution authority.

### 2.7.7 Studio Roles.

2.7.7.1 Studio roles include controlled runtime design, dashboard operation, simulation support, digital twin workflow support, AI workflow review, data-room facilitation, secure-room facilitation, public authority learning facilitation, readiness-room facilitation, capital-reader room facilitation, insurance-reader room facilitation, and handoff demonstration support.

2.7.7.2 Studio roles shall preserve no-command, no-write-back, output review, access control, logging, public-safe status, shutdown triggers, correction triggers, and archive rules. Studio roles shall not create decision authority, deployment authority, public authority action, finance approval, insurance underwriting, or execution.

### 2.7.8 Readiness Roles.

2.7.8.1 Readiness roles include preparing Grid inputs, TRL notes, evidence sufficiency reviews, method sufficiency reviews, data sufficiency reviews, AI-use sufficiency reviews, cyber sufficiency reviews, public-safe sufficiency reviews, safeguard sufficiency reviews, support sufficiency reviews, reproducibility sufficiency reviews, and correction sufficiency reviews.

2.7.8.2 Readiness roles shall support assurance without certification. Readiness actors shall not represent Grid inputs, TRL notes, review status, or readiness classes as procurement readiness, financeability, insurability, public authority approval, deployment authorization, maturity certification, or compliance determination.

### 2.7.9 Public Authority Learning Roles.

2.7.9.1 Public authority learning roles include public authority participants, facilitators, evidence presenters, Studio demonstrators, DRI interpreters, Observatory interpreters, Reports authors, policy translators, legal-boundary reviewers, and record stewards who support public authority understanding without replacing public authority action.

2.7.9.2 Public authority learning roles shall record non-decision status, public authority dependencies, official-action boundaries, public finance boundaries, emergency-command boundaries, public-warning boundaries, and correction pathways. Public authority learning shall not equal public authority decision.

### 2.7.10 Capital-Reader and Insurance-Reader Roles.

2.7.10.1 Capital-reader and insurance-reader roles include investors, lenders, banks, insurers, reinsurers, donors, public finance readers, development finance actors, risk finance experts, diligence reviewers, and finance-readiness facilitators participating under no-reliance, non-solicitation, non-transactional, regulated-perimeter, and competition-compliant controls.

2.7.10.2 These roles shall support readability, not finance or insurance execution. Participation shall not imply investment interest, capital commitment, lending, underwriting, insurance approval, donor commitment, public finance allocation, financeability, bankability, insurability, rating, or transaction.

### 2.7.11 Handoff Recipient Roles.

2.7.11.1 Handoff recipient roles include National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, funders, insurers, donors, universities, labs, community actors where appropriate, and other competent lawful actors that may receive NAF handoff context.

2.7.11.2 Handoff recipients shall remain responsible for independent diligence, legal authority, procurement, finance, insurance, public authority approvals, community processes, Indigenous protocols where applicable, technical implementation, operations, safeguards, cybersecurity, privacy, data governance, and correction obligations. Receipt of handoff context shall not transfer authority from NAF.

### 2.7.12 Execution Roles Outside NAF Default Posture.

2.7.12.1 Execution roles exist outside NAF’s default public-good posture. Execution may include procurement, contracting, financing, underwriting, permitting, building, deploying, operating, maintaining, regulating, issuing warnings, commanding emergencies, delivering services, or implementing projects.

2.7.12.2 Execution shall be undertaken only by competent lawful actors through appropriate authority, contracts, approvals, financing, insurance, procurement, safeguards, community processes, data controls, technical controls, and accountability structures. NAF may prepare records and handoff context for such actors, but it shall not become the execution actor by implication.

2.7.12.3 The final role-separation rule of Part II is that NAF organizes movement; institutions preserve mandates; mechanisms preserve records; pillars perform bounded functions; consortiums form participation and national ownership; public authorities decide only through lawful public authority processes; enterprise actors execute only through lawful enterprise processes; and correction preserves the integrity of the whole system.


---

# 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/ii.-systems.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.