# V. PORTFOLIOS

Nexus Agile Framework Portfolios define the **NAF portfolio governance model** for public-good systems delivery. This section explains how **global, regional, national, thematic, sector, technology, campaign, Foundry, Reports, handoff-dependency, correction, and archive portfolios** organize strategy, priorities, evidence, and governed work.

This section sets the operating logic for **national portfolios**, **strategy-to-docket translation**, **WFEH-B portfolio architecture**, **DRR, DRF, and DRI portfolio logic**, **innovation portfolios**, **risk-weighted prioritization**, and **portfolio governance metrics**. It helps Nexus structure public-good value, national ownership, lawful handoff preparation, and correction discipline without creating certification, procurement, finance, insurance, approval, or execution by implication.

### What this section covers

* **Portfolio architecture** - Defines the NAF portfolio layers and how work is organized.
* **National and systems logic** - Explains national portfolios, WFEH-B logic, risk intelligence, and innovation routing.
* **Governance and prioritization** - Defines scoring, metrics, handoff dependency clarity, and correction-sensitive oversight.

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, [II. SYSTEMS](/organization/operations/frameworks/nexus-agile-framework-naf/ii.-systems.md) for system architecture, [III. STANDARDS](/organization/operations/frameworks/nexus-agile-framework-naf/iii.-standards.md) for interoperability, and [IV. LIFECYCLE](/organization/operations/frameworks/nexus-agile-framework-naf/iv.-lifecycle.md) for work movement and release discipline.

## 5.1 Nexus Portfolio Management

### 5.1.1 Global Portfolio.

5.1.1.1 The Global Portfolio is the highest-level NAF portfolio layer through which Nexus records, organizes, sequences, reviews, releases, routes, corrects, and archives work that has universal, cross-regional, multi-country, all-hazards, whole-of-society, exponential-technology, public-good, standards-interface, or Nexus-system-wide relevance. The Global Portfolio shall preserve common architecture, common terminology, common rails, common public-good operating discipline, common no-conversion rules, common correction pathways, and common interoperability across Nexus without creating global supremacy over national pathways.

5.1.1.2 The Global Portfolio may include universal Docket priorities, Nexus Universe global priorities, Nexus Core Build priorities, GRIx risk-meaning structures, DRI public-safe intelligence structures, DICE commons structures, Nexus Observatory global signal structures, Nexus Academy and Risk Academy global learning pathways, Nexus Foundry global builds, Nexus Campaigns global mobilization objects, Nexus Reports publication programs, Nexus Marketplace and Nexus Registry global object structures, Nexus Studio shared workflow patterns, Nexus Grid and TRL evidence structures, standards-interface records, open technical baselines, global public-good software, global correction priorities, and lawful handoff architecture patterns.

5.1.1.3 The Global Portfolio shall not authorize implementation, issue public warnings, allocate public finance, approve procurement, approve insurance, certify maturity, certify standards conformance, certify technology readiness, validate providers, endorse sponsors, create national consent, or execute projects. It shall provide coherence, memory, common rail discipline, and public-good routing.

### 5.1.2 Regional Portfolios.

5.1.2.1 Regional Portfolios are NAF portfolio layers through which Nexus organizes work involving regional clusters, cross-border systems, shared hazards, regional WFEH-B dependencies, transboundary climate and disaster-risk conditions, regional infrastructure corridors, regional digital and compute infrastructure, regional data and observability needs, regional workforce and competence needs, regional public authority learning questions, regional Nexus Universe preparation, and regional lawful handoff dependencies.

5.1.2.2 Regional Portfolios shall translate global public-good architecture into regionally relevant patterns while preserving national ownership. A Regional Portfolio may support multiple National Portfolios by identifying shared risks, common methods, regional DRI and Observatory needs, regional Academy pathways, regional Campaigns, regional Foundry builds, regional public-safe Reports, regional standards-interface gaps, regional finance-readiness questions, regional insurance-readiness questions, and regional corridor dependencies.

5.1.2.3 A Regional Portfolio shall not override National Portfolios, national public authorities, national data sovereignty, national safeguard processes, community or Indigenous protocols, national procurement processes, national financing decisions, or lawful implementation channels. Regional work shall coordinate and support; it shall not command, certify, finance, procure, consent, or execute.

### 5.1.3 National Portfolios.

5.1.3.1 National Portfolios are the principal country-level NAF portfolio layer. They shall organize national Nexus priorities, national systems-risk records, national WFEH-B priorities, national DRR, DRF, and DRI needs, national exponential-technology priorities, national public authority learning needs, national data and observability requirements, national workforce and competence needs, national Campaigns, national Foundry builds, national Academy pathways, national Reports, national Registry and Marketplace objects, national Studio workflows, national Grid and TRL inputs, national safeguard records, and national lawful handoff dependency packages.

5.1.3.2 National Portfolios shall preserve the rule of national ownership before local delivery. They shall prevent global, regional, sponsor, provider, capital-reader, media, or external technical actors from bypassing national stakeholder pathways. They shall record country context, public authority dependencies, national institutions, National Nexus Consortium interfaces, National Council interfaces, National Working Group interfaces, Competence Cell interfaces, National Node interfaces, community and Indigenous protocol considerations where applicable, data sovereignty, language localization, legal localization, public-safe communication requirements, and lawful handoff pathways.

5.1.3.3 A National Portfolio shall not be a government plan, public authority decision, procurement framework, public finance allocation, investment pipeline, insurance approval, national certification, country ranking, public warning, community consent record, Indigenous consent record, deployment authorization, or execution plan unless separately and lawfully created by competent actors outside NAF’s default public-good posture.

### 5.1.4 Thematic Portfolios.

5.1.4.1 Thematic Portfolios are organized around cross-cutting public-good themes that recur across countries, regions, sectors, technologies, and Nexus mechanisms. They may include all-hazards resilience, public authority learning, disaster-risk intelligence, climate adaptation, biodiversity, food systems, water systems, energy resilience, public health resilience, cyber-physical resilience, data commons, AI governance, open-source public-good software, sovereign compute, public-safe reporting, finance-readiness literacy, insurance-readiness literacy, workforce resilience, protected knowledge, accessibility, youth, community safeguards, and lawful handoff literacy.

5.1.4.2 Thematic Portfolios shall help NAF accumulate reusable evidence, methods, learning objects, Reports, Studio workflows, DICE objects, GRIx categories, DRI structures, Foundry builds, Campaign patterns, Marketplace listings, Registry records, Grid inputs, TRL notes, and correction records across multiple national and regional contexts. They shall prevent repeated reinvention while preserving context-specific review and localization.

5.1.4.3 A Thematic Portfolio shall not impose a single universal solution on all national or local contexts. Thematic reuse shall remain bounded by jurisdiction, hazard, data, technology, safeguard, public authority, finance, procurement, and handoff conditions.

### 5.1.5 Sector Portfolios.

5.1.5.1 Sector Portfolios are organized around sectors whose resilience, innovation, infrastructure, workforce, data, public authority learning, and lawful handoff needs are material to Nexus. Sectors may include water, food, energy, health, biodiversity, infrastructure, telecommunications, cloud and compute, cybersecurity, public safety, emergency management, education, finance, insurance, public finance, manufacturing, supply chains, transport, agriculture, housing, urban systems, rural systems, humanitarian systems, and community resilience.

5.1.5.2 Sector Portfolios shall record sector-specific hazards, technologies, standards-interface issues, data needs, public authority dependencies, workforce needs, provider-neutrality issues, sponsor-boundary issues, procurement-neutrality issues, finance-readiness questions, insurance-readiness questions, public-safe reporting requirements, and lawful handoff dependencies.

5.1.5.3 Sector Portfolio work shall not become sector certification, supplier approval, procurement recommendation, public authority approval, market endorsement, financeability determination, insurance approval, or deployment authorization by implication.

### 5.1.6 Technology Portfolios.

5.1.6.1 Technology Portfolios are organized around technology domains within the full Nexus scope, including AI, agentic systems, AI-RAN, O-RAN, telecom, private wireless, edge, cloud, HPC, sovereign compute, verifiable compute, cybersecurity, zero trust, geospatial systems, Earth observation, digital twins, drones, robotics, sensors, IoT, OT, IIoT, DLT, DePIN, Web3, digital identity, quantum-relevant security, semiconductors, advanced manufacturing, biosecurity-sensitive systems, and frontier science infrastructure.

5.1.6.2 Technology Portfolios shall record technology-specific evidence, methods, testbeds, software, data, models, APIs, standards-interface records, AI-use labels, cyber controls, privacy controls, safety constraints, dual-use sensitivities, public authority dependencies, Grid inputs, TRL notes, Studio workflows, Nexus Universe demonstrations, Marketplace listings, Registry records, and handoff dependency packages.

5.1.6.3 Technology Portfolio status shall not constitute technology approval, product certification, standards conformance, security certification, AI safety certification, procurement status, financeability, insurability, public authority approval, deployment authorization, or execution readiness.

### 5.1.7 Campaign Portfolios.

5.1.7.1 Campaign Portfolios are organized around public-good mobilization. They shall hold national, regional, global, thematic, sector, youth, university, public authority learning, Nexus Universe, Foundry, WFEH-B, DRR, DRF, DRI, and lawful handoff awareness Campaigns.

5.1.7.2 Campaign Portfolios shall record campaign purposes, audiences, public-safe messaging, support records, signature records, pledge records, volunteer records, team and chapter records, ambassador records, sponsor controls, provider controls, trust and safety controls, fraud controls, Campaign-to-Academy pathways, Campaign-to-Foundry pathways, Campaign-to-National Portfolio pathways, Campaign-to-Nexus Universe pathways, and correction records.

5.1.7.3 Campaign Portfolio activity shall not create public mandate, vote, consent, endorsement, public authority approval, finance commitment, donor commitment, procurement status, employment, deployment authorization, or execution authority.

### 5.1.8 Foundry Portfolios.

5.1.8.1 Foundry Portfolios are organized around public-good production. They shall hold Nexus Foundry programs, tracks, quests, bounties, builds, micro-production objects, public-good software, open technical baselines, data pipelines, dashboards, Studio workflows, Registry record builds, Marketplace object builds, Reports builds, Grid inputs, TRL notes, National Portfolio builds, Campaign builds, Nexus Universe Core Build outputs, and handoff dependency builds.

5.1.8.2 Foundry Portfolios shall include maintainer records, contributor records, review gates, release classes, repository records, support classes, data and AI controls, cyber controls, public-safe controls, safeguard controls, sponsor and provider boundary records, labor boundary records, and correction pathways.

5.1.8.3 Foundry Portfolio work shall remain production for public-good evidence and reusable capability; it shall not become enterprise execution, employment by contribution, procurement qualification, product certification, provider validation, deployment authorization, or project implementation by implication.

### 5.1.9 Reports Portfolios.

5.1.9.1 Reports Portfolios are organized around public-safe publication, evidence translation, knowledge distribution, open science where safe, controlled knowledge where necessary, National Portfolio reporting, WFEH-B reporting, DRR reporting, DRF reporting, DRI reporting, DICE reporting, GRIx reporting, Observatory reporting, Foundry reporting, Campaign reporting, Academy reporting, Labs reporting, Risk Agency reporting, Nexus Universe reporting, Grid and TRL reporting, handoff context notes, correction reports, and archive reports.

5.1.9.2 Reports Portfolios shall record report families, evidence basis, public-safe status, data availability statements, AI-use statements, repository strategy, metadata, licensing, controlled knowledge exclusions, review status, correction pathways, withdrawal rules, and archive rules.

5.1.9.3 Reports Portfolio activity shall not constitute public warning, public authority approval, certification, procurement recommendation, financeability, insurability, country ranking, provider validation, community consent, Indigenous consent, deployment authorization, or execution.

### 5.1.10 Handoff-Dependency Portfolios.

5.1.10.1 Handoff-Dependency Portfolios are organized around work that may become relevant to lawful implementation by competent actors. They shall hold 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-readiness questions, insurance-readiness questions, procurement-neutrality notes, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, recall pathways, correction pathways, and archive rules.

5.1.10.2 Handoff-Dependency Portfolios shall distinguish between public-good readiness context and lawful execution. They may assist National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, funders, insurers, donors, universities, labs, community actors where appropriate, and other competent lawful actors by transferring dependencies and evidence context.

5.1.10.3 A Handoff-Dependency Portfolio shall not itself authorize handoff, implementation, financing, underwriting, procurement, certification, public authority approval, community consent, Indigenous consent, deployment, or execution. It is a dependency memory and preparation layer.

### 5.1.11 Correction Portfolios.

5.1.11.1 Correction Portfolios are organized around errors, overclaims, incidents, misclassifications, outdated records, public-safe issues, data issues, AI issues, cyber issues, privacy issues, protected knowledge issues, standards overclaims, public authority boundary issues, finance boundary issues, procurement boundary issues, sponsor control issues, provider validation issues, consent overclaims, handoff overclaims, execution overclaims, withdrawals, recalls, archive actions, and reinstatement reviews.

5.1.11.2 Correction Portfolios shall track correction priority, affected records, affected outputs, affected Reports, affected Registry statuses, affected Marketplace listings, affected Studio workflows, affected Grid inputs, affected TRL notes, affected Campaigns, affected Nexus Universe outputs, affected National Portfolios, affected handoff packages, public-safe notices, and correction propagation.

5.1.11.3 Correction Portfolios shall have priority where trust, safety, legality, public authority boundaries, finance/procurement boundaries, sponsor/provider boundaries, data protection, AI safety, cyber safety, protected knowledge, community safeguards, Indigenous protocols, or execution boundaries are at risk.

### 5.1.12 Archive Portfolios.

5.1.12.1 Archive Portfolios are organized around institutional memory. They shall hold archived Docket items, old Signals, closed backlogs, withdrawn records, recalled handoff packages, superseded Reports, deprecated software, retired datasets, obsolete models, closed Studio workflows, old Grid inputs, historical TRL notes, past Nexus Universe outputs, non-continuing work, correction history, public-safe notices, and successor links.

5.1.12.2 Archive Portfolios shall preserve archive-not-current notices, access class, public-safe status, sensitivity class, support status, license status, correction history, successor objects, retention rules, deletion or sealing rules where applicable, and permitted historical use.

5.1.12.3 Archive Portfolio status shall not create current authority. Archived objects shall not be used as active guidance, readiness evidence, public authority support, procurement support, finance-readiness support, insurance-readiness support, or handoff support unless reinstated through recorded review.

## 5.2 Strategy-to-Docket Translation

### 5.2.1 Strategic Signals.

5.2.1.1 Strategic Signals are high-level indications that a portfolio priority, systems-risk issue, technology opportunity, public-good capability gap, national resilience need, regional cluster need, global Nexus need, public authority learning need, finance-readiness issue, standards-interface gap, or correction need may require Docket formation.

5.2.1.2 Strategic Signals may arise from Nexus governance records, public authority learning, National Portfolios, Regional Portfolios, Nexus Universe outcomes, Reports, DRI, Nexus Observatory, Campaigns, Labs, Marketplace discovery, Registry records, Grid and TRL patterns, Foundry outputs, Academy needs, Risk Agency expertise, community input, Indigenous protocol-sensitive input where applicable, sponsors, providers, capital readers, insurers, donors, public finance readers, or external developments.

5.2.1.3 Strategic Signals shall be translated into Docket items only after intake, triage, classification, public-good purpose recording, boundary notice recording, and pathway selection. A Strategic Signal shall not be treated as a mandate, approval, finance signal, procurement signal, public warning, public authority instruction, or execution order.

### 5.2.2 National Priorities.

5.2.2.1 National Priorities are country-level priorities identified through National Nexus Consortium pathways, National Councils, National Working Groups, Competence Cells, National Nodes, public authority learning rooms, National Portfolio review, Campaigns, Academy pathways, DRI and Observatory records, Reports, and stakeholder formation processes.

5.2.2.2 National Priorities may concern WFEH-B resilience, DRR, DRF, DRI, digital infrastructure, AI, cyber, data commons, public-good software, workforce resilience, public authority learning, standards-interface needs, community safeguards, Indigenous protocols where applicable, finance-readiness questions, insurance-readiness questions, and lawful handoff dependencies.

5.2.2.3 National Priorities shall be translated into National Docket items without implying government adoption, public authority approval, public finance allocation, procurement plan, financeability, insurance approval, consent, deployment authorization, or execution.

### 5.2.3 Regional Cluster Priorities.

5.2.3.1 Regional Cluster Priorities are priorities arising from shared hazards, corridors, regional infrastructure dependencies, climate zones, WFEH-B interdependencies, migration patterns, supply chains, digital infrastructure, regional public authority learning, cross-border disaster-risk intelligence, regional Nexus Universe preparation, and shared standards-interface needs.

5.2.3.2 Regional Cluster Priorities shall be translated into Regional Docket items and, where relevant, linked to affected National Dockets. They shall identify national routing conditions, transboundary dependencies, data sensitivity, public authority dependencies, regional coordination needs, and correction pathways.

5.2.3.3 Regional Cluster Priorities shall not override national priorities. Regional translation shall support national ownership and shall not create supranational authority, regional procurement, regional public finance allocation, regional certification, regional consent, or regional execution.

### 5.2.4 Nexus Universe Priorities.

5.2.4.1 Nexus Universe Priorities are priorities selected or prepared for annual convergence, Core Build, arena presentation, public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, Studio demonstrations, Marketplace and Registry discovery, Campaign activation, Reports publication, Grid and TRL review, National Portfolio comparison-without-ranking, and lawful handoff preparation.

5.2.4.2 Nexus Universe Priorities shall be translated into Universe Docket items with release class, public-safe status, presentation eligibility, room type, sponsor/provider restrictions, public authority boundary notices, finance/insurance/procurement notices, safeguard status, data and AI labels, and post-Universe continuation pathway.

5.2.4.3 Nexus Universe priority status shall not imply endorsement, approval, certification, financeability, insurance approval, procurement readiness, public authority decision, public warning, consent, deployment authorization, or execution.

### 5.2.5 Public Authority Learning Questions.

5.2.5.1 Public Authority Learning Questions are questions raised by or relevant to public authorities, ministries, regulators, municipal bodies, emergency management bodies, infrastructure authorities, public health bodies, public finance actors, public employment systems, disaster-risk agencies, climate services, standards-interface bodies, or other public institutions seeking learning, evidence, scenario exploration, policy intelligence, or readiness understanding.

5.2.5.2 Such questions may be translated into Docket items for Reports, Studio workflows, Academy modules, Risk Academy pathways, Labs research, Foundry builds, DRI records, Observatory records, Grid inputs, Nexus Universe rooms, or handoff dependency notes.

5.2.5.3 Public Authority Learning Questions shall not become public authority decisions by implication. They shall remain non-decision learning records unless separately and lawfully converted into official action by competent public authorities.

### 5.2.6 Observatory Signals.

5.2.6.1 Observatory Signals are signals from Nexus Observatory nodes, hubs, regional clusters, national dense Nexus cores, sensors, edge systems, geospatial sources, Earth observation sources, digital twin inputs, dashboards, degraded-mode records, public-safe observability outputs, and related signal environments.

5.2.6.2 Observatory Signals may be translated into Docket items for DRI, GRIx, DICE, Studio, Reports, Grid, National Portfolios, Nexus Universe, Campaigns, Academy, Foundry, Marketplace, Registry, or handoff context.

5.2.6.3 Observatory Signals shall not be treated as surveillance authority, public warning, official map, public authority decision, insurance score, investment signal, procurement score, or operational command.

### 5.2.7 Campaign Signals.

5.2.7.1 Campaign Signals are signals arising from public-good mobilization, signatures, pledges, support, donations where lawful, volunteers, team formation, chapters, ambassadors, public-safe stories, Campaign dashboards, community feedback, youth participation, university participation, public authority learning Campaigns, and Nexus Universe Campaigns.

5.2.7.2 Campaign Signals may be translated into Docket items for National Portfolios, Academy pathways, Foundry quests, Reports, Marketplace listings, Registry records, DRI contributions, DICE contributions, public-safe reporting, public authority learning, or lawful handoff awareness.

5.2.7.3 Campaign Signals shall not be treated as votes, mandates, public authority decisions, community consent, Indigenous consent, donor commitments, finance commitments, procurement commitments, employment commitments, or execution authority.

### 5.2.8 Risk Intelligence Signals.

5.2.8.1 Risk Intelligence Signals are signals from DRI indicators, GRIx categories, Observatory records, Reports, Studio scenarios, digital twins, datasets, dashboards, research, public authority learning, Campaign inputs, National Portfolios, and external sources concerning risk, uncertainty, vulnerability, exposure, resilience capacity, cascade potential, disaster-risk finance relevance, insurance-readiness, or public-safe communication needs.

5.2.8.2 Risk Intelligence Signals may be translated into Docket items for DRI review, GRIx refinement, public-safe Reports, National Portfolio updates, Studio workflows, Grid inputs, Nexus Universe rooms, Campaigns, Academy modules, Foundry builds, or handoff dependency packages.

5.2.8.3 Risk Intelligence Signals shall not become public warnings, forecasts of certainty, ratings, insurance scores, investment signals, procurement scores, public authority decisions, or emergency commands.

### 5.2.9 Finance-Readiness Signals.

5.2.9.1 Finance-Readiness Signals are signals that a public-good output, National Portfolio object, Foundry build, Report, Studio workflow, Grid input, TRL note, Nexus Universe output, Campaign record, DRI record, Observatory record, or handoff dependency may require capital-readability, donor-readiness, public finance relevance, insurance-readiness, diligence-gap mapping, assumptions registers, dependency registers, or no-reliance framing.

5.2.9.2 Finance-Readiness Signals may be translated into Docket items for The Global Risks Alliance-supported readiness analysis, capital-reader room preparation, insurance-reader room preparation, donor-reader room preparation, public finance learning rooms, handoff dependency packages, or National Portfolio notes.

5.2.9.3 Finance-Readiness Signals shall not constitute investment advice, securities activity, financing commitment, donor commitment, public finance allocation, insurance underwriting, bankability, financeability, rating, solicitation, transaction, or regulated financial activity by default.

### 5.2.10 Safeguard Signals.

5.2.10.1 Safeguard Signals are signals that work may involve community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, conflict sensitivity, rights-based concerns, non-extractive engagement, public-safe communication, or community-facing correction.

5.2.10.2 Safeguard Signals may be translated into Docket items for safeguard review, public-safe review, data restriction, secure-room handling, Campaign modification, Report restriction, Studio limitation, Marketplace delisting, Registry status update, Nexus Universe room restriction, or handoff dependency condition.

5.2.10.3 Safeguard Signals shall have priority where rights, dignity, protected knowledge, community safety, Indigenous protocols, vulnerable populations, accessibility, or public trust are at risk.

### 5.2.11 Labs Research Signals.

5.2.11.1 Labs Research Signals are signals emerging from research questions, evidence gaps, testbeds, methods, datasets, models, simulations, digital twins, benchmark records, system cards, agent workflow cards, scenario records, and research translation activities.

5.2.11.2 Labs Research Signals may be translated into Docket items for Nexus Labs, Nexus Foundry, Nexus Reports, DICE, GRIx, DRI, Observatory, Studio, Academy, Grid, TRL, Nexus Universe, National Portfolios, Marketplace, Registry, or handoff context.

5.2.11.3 A Labs Research Signal shall not be treated as validated research finding, public authority decision, deployment approval, financeability, procurement status, certification, consent, or execution authority.

### 5.2.12 Marketplace Discovery Signals.

5.2.12.1 Marketplace Discovery Signals are signals arising from search, listing interest, reuse interest, support requests, translation requests, accessibility requests, bug reports, feature requests, download signals, national demand signals, handoff interest signals, and object discovery patterns within Nexus Marketplace.

5.2.12.2 Marketplace Discovery Signals may be translated into Docket items for Foundry builds, Academy modules, Reports updates, Registry corrections, Studio workflows, DICE improvements, software maintenance, data quality work, localization, accessibility, support status changes, National Portfolio updates, Nexus Universe prioritization, or handoff dependency review.

5.2.12.3 Marketplace Discovery Signals shall not be treated as procurement demand, provider validation, endorsement, finance signal, insurance signal, public authority approval, or execution mandate.

## 5.3 National Portfolio Architecture

### 5.3.1 National Context Records.

5.3.1.1 National Context Records shall be the foundation of each National Portfolio. They shall record the national setting within which NAF work is interpreted, including governance context, public authority structure, legal context, geography, language, data sovereignty, climate and hazard profile, WFEH-B systems, infrastructure dependencies, digital infrastructure, workforce conditions, technology ecosystem, research ecosystem, enterprise ecosystem, community context, Indigenous protocols where applicable, public finance context, donor context, insurance context, and lawful handoff pathways.

5.3.1.2 National Context Records shall be living records. They shall be updated when national priorities, public authority dependencies, legal constraints, data rules, hazard context, infrastructure conditions, community safeguards, technology readiness, or handoff pathways change.

5.3.1.3 National Context Records shall not be country rankings, government approvals, legal opinions, public authority decisions, investment memoranda, insurance underwriting records, procurement plans, or implementation approvals by default.

### 5.3.2 National Systems-Risk Maps.

5.3.2.1 National Systems-Risk Maps shall record systems-risk relationships across WFEH-B systems, climate, nature, biodiversity, infrastructure, public health, cyber-physical systems, supply chains, disaster risk, finance-readiness questions, public authority learning needs, technology dependencies, and community vulnerabilities.

5.3.2.2 National Systems-Risk Maps may include exposure, vulnerability, resilience capacity, cascade pathways, dependency pathways, data gaps, Observatory needs, DRI indicator needs, public-safe reporting needs, Studio scenario needs, and handoff dependencies.

5.3.2.3 National Systems-Risk Maps shall not be official hazard maps, public warnings, insurance ratings, investment ratings, procurement scores, country rankings, public authority decisions, or emergency commands unless separately and lawfully issued by competent authorities.

### 5.3.3 National Challenge Briefs.

5.3.3.1 National Challenge Briefs shall translate National Context Records and National Systems-Risk Maps into structured challenge statements. A National Challenge Brief shall identify the public-good challenge, affected systems, national relevance, evidence gaps, data needs, technology needs, learning needs, stakeholder context, safeguard issues, public authority dependencies, finance-readiness questions, insurance-readiness questions, potential Nexus pathways, and correction pathway.

5.3.3.2 National Challenge Briefs may become Docket items, Campaign objects, Academy pathways, Labs research questions, Foundry quests, Reports, Studio workflows, Grid inputs, Nexus Universe arena items, or handoff dependency items.

5.3.3.3 National Challenge Briefs shall not create government priority status, procurement intent, financeability, insurance approval, sponsor endorsement, provider validation, consent, deployment authorization, or execution.

### 5.3.4 Evidence Need Records.

5.3.4.1 Evidence Need Records shall identify what evidence is required to understand, review, communicate, build, test, publish, classify, route, present, or hand off a National Portfolio item. Evidence needs may include datasets, methods, literature, field inputs, public authority records, community inputs, Indigenous protocol-sensitive inputs where applicable, model evaluations, benchmark records, system cards, Studio logs, Observatory signals, DRI indicators, and external standards-interface references.

5.3.4.2 Evidence Need Records shall distinguish between missing evidence, insufficient evidence, restricted evidence, public-safe evidence, disputed evidence, outdated evidence, and evidence requiring correction. They shall guide Academy, Labs, Foundry, Reports, Studio, Grid, TRL, Nexus Universe, and handoff pathways.

5.3.4.3 Evidence Need Records shall not imply that missing evidence is a deficiency of a country, community, provider, public authority, or project. They are work-routing records, not blame records.

### 5.3.5 Observatory Need Records.

5.3.5.1 Observatory Need Records shall identify national needs for observability, signals, indicators, sensors, edge systems, geospatial layers, Earth observation, digital twins, dashboards, degraded-mode awareness, public-safe observability outputs, data rooms, secure rooms, and national dense Nexus Core profiles.

5.3.5.2 Observatory Need Records shall identify data sources, sensitivity, access requirements, public authority dependencies, community safeguards, protected knowledge controls, geospatial masking requirements, compute-to-data needs, public-safe release limits, and correction pathways.

5.3.5.3 Observatory Need Records shall not create surveillance authority, public warning authority, official map status, public authority approval, data rights, or deployment authorization.

### 5.3.6 Core Build Requests.

5.3.6.1 Core Build Requests shall identify National Portfolio needs that may be routed to Nexus Core Build or Nexus Foundry for concentrated build activity. Core Build Requests may include public-good software, data pipelines, dashboards, APIs, Studio workflows, learning objects, DRI indicators, GRIx mappings, Reports, Marketplace objects, Registry records, Grid inputs, TRL notes, and handoff dependency packages.

5.3.6.2 Core Build Requests shall include purpose, scope, national context, evidence requirements, data and AI labels, cyber controls, safeguard conditions, public-safe status, support class, maintainer needs, Nexus Universe relevance, and correction pathway.

5.3.6.3 A Core Build Request shall not authorize a build to become production deployment, procurement object, provider validation, public authority decision, financeable project, insured project, consented project, or executed project.

### 5.3.7 Safeguard Records.

5.3.7.1 Safeguard Records shall identify safeguard conditions affecting National Portfolio work, including community safeguards, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, conflict sensitivity, rights concerns, non-extractive engagement, data protection, public-safe reporting, and community-facing correction.

5.3.7.2 Safeguard Records shall govern what may be collected, reviewed, disclosed, summarized, translated, mapped, visualized, published, shown in Nexus Universe, listed in Marketplace, recorded in Registry, included in Reports, used in Studio, used in Grid or TRL, or included in handoff packages.

5.3.7.3 Safeguard Records shall not imply that participation equals consent. Consent, where required, must be separately and lawfully recorded through competent processes.

### 5.3.8 Public Authority Learning Records.

5.3.8.1 Public Authority Learning Records shall record non-decision learning interactions involving public authorities. They may include questions, room participation, scenario participation, Studio workflows, DRI interpretation, Observatory interpretation, Reports review, Academy modules, Nexus Universe sessions, finance-readiness discussions, insurance-readiness discussions, public finance learning, standards-interface dialogue, or handoff dependency review.

5.3.8.2 Public Authority Learning Records shall include public authority role, non-decision status, scope, date, materials reviewed, data status, public-safe status, unresolved questions, dependencies, correction pathway, and boundary notices.

5.3.8.3 Public Authority Learning Records shall not be represented as official approval, policy adoption, public finance allocation, procurement decision, permit, license, public warning, emergency command, or implementation authorization.

### 5.3.9 Readiness Question Records.

5.3.9.1 Readiness Question Records shall identify readiness questions related to evidence, data, methods, technology, AI, cyber, privacy, safeguards, public-safe reporting, national capability, workforce, public authority learning, finance-readiness, insurance-readiness, donor-readiness, public finance relevance, procurement neutrality, standards-interface, Grid inputs, TRL notes, and lawful handoff.

5.3.9.2 Readiness Question Records shall be routed to appropriate pathways for review, including Foundry, Labs, Reports, Studio, Grid, TRL, The Global Risks Alliance-supported readiness rooms, public authority learning rooms, National Working Groups, Competence Cells, Nexus Universe, or lawful handoff packages.

5.3.9.3 A Readiness Question Record is a question, not a conclusion. It shall not imply readiness, financeability, insurability, procurement status, certification, approval, deployment, or execution.

### 5.3.10 Competence Cell Workplans.

5.3.10.1 Competence Cell Workplans shall identify the applied capability work required to advance National Portfolio priorities. Workplans may include data tasks, AI tasks, cyber tasks, geospatial tasks, DRI tasks, GRIx tasks, WFEH-B tasks, Reports tasks, Studio tasks, Foundry builds, Campaign support, Academy outputs, Grid inputs, TRL notes, and handoff dependency work.

5.3.10.2 Competence Cell Workplans shall record members, roles, mentors, reviewers, work scope, learning needs, evidence outputs, public-safe outputs, safeguard conditions, data and AI labels, labor boundary notices, support class, correction pathway, and archive rule.

5.3.10.3 Competence Cell work shall not create employment, procurement qualification, professional license, public authority approval, provider validation, consent, deployment authorization, or execution.

### 5.3.11 Universe Arena Routing Records.

5.3.11.1 Universe Arena Routing Records shall identify National Portfolio items prepared for Nexus Universe arenas, rooms, Core Build environments, public authority learning sessions, readiness rooms, Studio demonstrations, Marketplace and Registry discovery, Reports release, Campaign activation, or handoff dependency discussion.

5.3.11.2 Universe Arena Routing Records shall include release class, public-safe status, safeguard status, data and AI labels, presenter roles, room type, sponsor/provider controls, public authority boundary notices, finance/insurance/procurement notices, correction pathway, and post-Universe national continuation pathway.

5.3.11.3 Arena routing shall not imply approval, endorsement, certification, financeability, insurance approval, procurement status, consent, deployment authorization, or execution.

### 5.3.12 National Portfolio Archives.

5.3.12.1 National Portfolio Archives shall preserve historical National Portfolio records, including context records, systems-risk maps, challenge briefs, evidence need records, Observatory need records, Core Build requests, safeguard records, public authority learning records, readiness question records, Competence Cell workplans, Universe routing records, handoff dependency packages, corrections, withdrawals, recalls, and non-continuation records.

5.3.12.2 National Portfolio Archives shall include archive-not-current notices, access classes, public-safe status, sensitive data rules, successor links, correction history, support status, retention, deletion or sealing where applicable, and permitted historical use.

5.3.12.3 National Portfolio Archives shall preserve national memory without creating current authority or country ranking.

## 5.4 WFEH-B Portfolio Logic

### 5.4.1 Water Systems.

5.4.1.1 Water Systems Portfolio logic shall cover water security, drinking water, sanitation, wastewater, watersheds, floods, droughts, groundwater, surface water, coastal water, water quality, water-energy-food-health-biodiversity interdependencies, hydrological data, water infrastructure, water governance, public authority learning, community water concerns, Indigenous water protocols where applicable, and water-related disaster risk.

5.4.1.2 Water Systems work may generate DRI indicators, Observatory needs, Studio scenarios, digital twins, public-safe Reports, Academy modules, Foundry builds, Campaigns, Grid inputs, TRL notes, Marketplace objects, Registry records, and handoff dependency packages. Water Systems work shall not issue official warnings, water rights decisions, regulatory approvals, public procurement decisions, finance decisions, or implementation authorizations.

### 5.4.2 Food Systems.

5.4.2.1 Food Systems Portfolio logic shall cover food security, agriculture, soil health, climate-smart agriculture, supply chains, cold chains, food safety literacy, agri-tech, sensors, biosecurity-sensitive food systems, rural livelihoods, market access, public authority learning, community food systems, and food-water-energy-health-biodiversity dependencies.

5.4.2.2 Food Systems work shall record exposure, vulnerability, resilience capacity, data needs, technology needs, safeguard issues, public-safe reporting needs, finance-readiness questions, insurance-readiness questions, donor-readiness questions, and lawful handoff dependencies. It shall not create food safety approval, agricultural certification, procurement recommendation, financeability, insurance approval, or execution authority.

### 5.4.3 Energy Systems.

5.4.3.1 Energy Systems Portfolio logic shall cover energy security, renewable energy, energy efficiency, grid resilience, distributed energy resources, critical infrastructure, energy-water-food-health-biodiversity dependencies, emergency power, telecom and compute energy needs, cyber-physical risk, climate adaptation, public authority learning, and lawful handoff dependencies.

5.4.3.2 Energy Systems work may include open technical baselines, dashboards, digital twins, resilience scenarios, data rooms, secure rooms, Studio workflows, public-safe Reports, Grid inputs, TRL notes, Marketplace objects, Registry records, and handoff packages. It shall not authorize energy projects, approve grid interconnections, certify systems, allocate public finance, select providers, or execute deployments.

### 5.4.4 Health Systems.

5.4.4.1 Health Systems Portfolio logic shall cover public health resilience, climate-health risks, health infrastructure, health data controls, One Health literacy, emergency health systems, biosecurity-sensitive systems, community health, youth safeguards, privacy, public authority learning, and health-water-food-energy-biodiversity dependencies.

5.4.4.2 Health Systems work shall be subject to heightened data, privacy, public-safe, biosecurity, public authority, and safeguard controls. It may support learning, evidence, public-safe reporting, Studio scenarios, DRI indicators, Observatory needs, and handoff dependencies but shall not create medical advice, public health orders, clinical decisions, regulatory approval, insurance approval, procurement approval, or deployment authorization.

### 5.4.5 Biodiversity and Nature Systems.

5.4.5.1 Biodiversity and Nature Systems Portfolio logic shall cover ecosystems, biodiversity, nature-based solutions, protected species, protected areas, sensitive location data, ecosystem services, climate adaptation, WFEH-B dependencies, community knowledge, Indigenous protocols where applicable, protected knowledge, and public-safe nature reporting.

5.4.5.2 Biodiversity and Nature Systems work shall use geospatial sensitivity controls, protected species masking, protected knowledge restrictions, community-facing safeguards, public-safe summaries, and correction pathways. It shall not create environmental approval, green certification, protected knowledge permission, land-use approval, community consent, Indigenous consent, procurement preference, or execution authority.

### 5.4.6 Cross-System Cascades.

5.4.6.1 Cross-System Cascade logic shall identify how disruptions in one system may affect others, including water-energy-food-health-biodiversity cascades, climate-infrastructure cascades, cyber-physical cascades, supply-chain cascades, public health cascades, telecom and compute cascades, financial protection gaps, insurance gaps, and public authority capacity constraints.

5.4.6.2 Cascade records shall identify assumptions, dependencies, uncertainty, confidence where applicable, scenario limits, data limits, public-safe communication status, public authority dependencies, and correction pathway. Cascade records shall not be treated as forecast certainty, public warnings, emergency commands, insurance scores, investment signals, or public authority decisions.

### 5.4.7 Corridor and Cluster Dependencies.

5.4.7.1 Corridor and Cluster Dependencies shall record shared infrastructure, logistics, climate zones, watersheds, ecosystems, migration routes, trade routes, telecom corridors, energy corridors, disaster-risk corridors, data corridors, and regional Nexus cluster relationships that affect National and Regional Portfolios.

5.4.7.2 Corridor and Cluster Dependencies shall support regional coordination while preserving national ownership. They shall not create corridor authorities, regional procurement, regional finance, regional certification, or regional execution by implication.

### 5.4.8 National Dense Nexus Core Profiles.

5.4.8.1 National Dense Nexus Core Profiles shall identify concentrated national capability environments where data, compute, observability, Studio workflows, Academy pathways, Foundry builds, Campaigns, Reports, Registry records, Marketplace objects, Grid inputs, TRL notes, public authority learning, and handoff dependencies converge around national priorities.

5.4.8.2 These profiles shall record infrastructure, data, compute, connectivity, workforce, public authority learning, safeguards, public-safe reporting, standards-interface, finance-readiness, insurance-readiness, and lawful handoff conditions. They shall not imply public authority approval, deployment authorization, financeability, procurement readiness, or execution.

### 5.4.9 Public-Safe WFEH-B Reporting.

5.4.9.1 Public-Safe WFEH-B Reporting shall translate WFEH-B evidence, risk intelligence, observability, scenarios, and portfolio updates into public-safe knowledge products. Such reporting shall avoid panic, false certainty, official warning overclaim, country ranking, community blaming, sensitive location disclosure, protected knowledge exposure, sponsor or provider promotion, and finance or procurement overclaim.

5.4.9.2 Public-Safe WFEH-B Reports shall include scope, evidence basis, limitations, public authority dependencies, data-use status, AI-use status, safeguard status, correction pathway, and no-conversion notices.

### 5.4.10 WFEH-B Handoff Dependencies.

5.4.10.1 WFEH-B Handoff Dependencies shall record what competent lawful actors must assess before implementation, including public authority approvals, data permissions, environmental and social safeguards, community processes, Indigenous protocols where applicable, technical feasibility, finance-readiness questions, insurance-readiness questions, procurement processes, provider-neutrality conditions, sponsor-boundary conditions, and correction pathways.

5.4.10.2 WFEH-B Handoff Dependencies shall transfer context, not authority. They shall not authorize projects, certify systems, approve finance, approve insurance, select vendors, approve procurement, grant consent, or execute implementation.

## 5.5 DRR, DRF, and DRI Portfolio Logic

### 5.5.1 Disaster Risk Reduction Portfolio.

5.5.1.1 The Disaster Risk Reduction Portfolio shall organize NAF work involving risk governance, risk knowledge, prevention, mitigation, preparedness, response learning, recovery learning, reconstruction learning, resilience capacity, hazard exposure, vulnerability, critical infrastructure, community resilience, WFEH-B systems, climate adaptation, public authority learning, and all-hazards systems transformation.

5.5.1.2 The DRR Portfolio may include National Systems-Risk Maps, DRI indicators, Observatory signals, Studio scenarios, public-safe Reports, Academy modules, Foundry builds, Campaigns, Grid inputs, TRL notes, Nexus Universe arenas, and handoff dependency packages.

5.5.1.3 DRR Portfolio status shall not create public warnings, emergency commands, public authority decisions, procurement decisions, financeability, insurance approval, certification, consent, deployment authorization, or execution.

### 5.5.2 Disaster Risk Finance Portfolio.

5.5.2.1 The Disaster Risk Finance Portfolio shall organize NAF work relating to risk layering, protection gaps, insurance-readiness questions, capital-readability, donor-readiness, public finance relevance, contingent finance learning, resilience-finance literacy, assumptions registers, dependency registers, diligence-gap registers, and no-reliance readiness rooms.

5.5.2.2 The DRF Portfolio shall be supported through The Global Risks Alliance role where appropriate and shall remain non-advisory, non-soliciting, non-transactional, no-reliance, and regulated-perimeter controlled. It may support capital-reader, insurance-reader, donor-reader, and public finance learning without executing finance.

5.5.2.3 DRF Portfolio status shall not create investment advice, insurance underwriting, donor commitment, public finance allocation, guarantee, loan, fund, securities activity, rating, bankability, financeability, procurement status, or transaction.

### 5.5.3 Disaster Risk Intelligence Portfolio.

5.5.3.1 The Disaster Risk Intelligence Portfolio shall organize DRI structures, indicator records, signal records, dashboard records, hotspot records, multi-hazard records, cascade records, public-safe intelligence summaries, uncertainty labels, confidence labels, national DRI contributions, correction records, and archive records.

5.5.3.2 The DRI Portfolio shall interface with GRIx, DICE, Nexus Observatory, Nexus Studio, Nexus Reports, Nexus Grid, National Portfolios, Nexus Universe, Academy pathways, Campaigns, Foundry builds, Marketplace listings, Registry records, and handoff context.

5.5.3.3 DRI Portfolio outputs shall not be public warnings, insurance scores, investment signals, procurement scores, country rankings, public authority decisions, emergency commands, or execution instructions.

### 5.5.4 Protection-Gap Questions.

5.5.4.1 Protection-Gap Questions shall identify where populations, systems, infrastructure, livelihoods, ecosystems, public services, or national capabilities may be exposed to losses, disruptions, or resilience deficits not adequately covered by current preparedness, finance, insurance, public finance, social protection, infrastructure resilience, or institutional capacity.

5.5.4.2 Protection-Gap Questions may be routed to DRR, DRF, DRI, National Portfolios, public authority learning, Reports, Studio scenarios, Academy modules, Nexus Universe rooms, or handoff dependency packages.

5.5.4.3 A Protection-Gap Question shall not be an insurance determination, finance recommendation, public finance allocation, public authority decision, or social protection decision.

### 5.5.5 Risk-Layering Questions.

5.5.5.1 Risk-Layering Questions shall identify how different layers of risk may require different forms of learning, prevention, mitigation, preparedness, finance-readiness, insurance-readiness, public finance relevance, donor-readiness, community resilience, or lawful implementation.

5.5.5.2 Risk-layering work shall preserve no-reliance discipline and shall not recommend, sell, broker, underwrite, arrange, solicit, or approve financial or insurance products. It shall structure questions and dependencies for competent actors.

### 5.5.6 DRI Indicator Needs.

5.5.6.1 DRI Indicator Needs shall identify where indicators are needed to understand disaster-risk signals, exposure, vulnerability, resilience capacity, cascade risk, hotspot conditions, degraded-mode awareness, public-safe reporting, public authority learning, or National Portfolio updates.

5.5.6.2 DRI Indicator Needs shall include data source, method, frequency, uncertainty, confidence where applicable, sensitivity, public-safe status, correction pathway, and archive rule. Indicator needs shall not become ratings, warnings, insurance scores, investment signals, or public authority decisions.

### 5.5.7 Public Authority Learning Needs.

5.5.7.1 Public Authority Learning Needs shall identify where public authorities may benefit from evidence, scenarios, dashboards, Reports, Academy modules, DRI interpretation, Observatory interpretation, Studio workflows, finance-readiness rooms, insurance-readiness rooms, or handoff dependency reviews.

5.5.7.2 Such needs shall remain learning needs, not official actions. Public authorities retain their own decision-making, legal mandates, procedures, accountability, and authority.

### 5.5.8 Insurance-Readiness Questions.

5.5.8.1 Insurance-Readiness Questions shall identify what information, evidence, dependencies, assumptions, risk layers, data quality, loss history, exposure context, resilience measures, public authority dependencies, safeguard conditions, and handoff responsibilities may be relevant for independent insurance or reinsurance assessment by competent actors.

5.5.8.2 Insurance-Readiness Questions shall not constitute underwriting, insurance advice, insurance approval, premium indication, coverage determination, risk score, or guarantee.

### 5.5.9 Donor-Readiness Questions.

5.5.9.1 Donor-Readiness Questions shall identify whether a public-good output, National Portfolio object, Campaign, Report, Foundry build, Academy pathway, Studio workflow, or handoff context may be understandable to donors, foundations, development actors, or philanthropic supporters.

5.5.9.2 Donor-readiness work shall not create donor commitment, grant approval, fundraising claim, reliance claim, or public finance allocation.

### 5.5.10 Public Finance Relevance Questions.

5.5.10.1 Public Finance Relevance Questions shall identify whether a National Portfolio priority, resilience need, public-good capability, infrastructure dependency, social protection issue, disaster-risk finance issue, or climate adaptation issue may be relevant for public finance learning or future competent public finance consideration.

5.5.10.2 Public Finance Relevance Questions shall not allocate public funds, approve budgets, create government commitments, approve projects, authorize procurement, or create entitlement to public resources.

## 5.6 Innovation Portfolio Logic

### 5.6.1 Public-Good Innovation.

5.6.1.1 Public-Good Innovation Portfolio logic shall organize innovation that advances public-good evidence, methods, learning, software, data commons, observability, public-safe reporting, standards-aware interoperability, risk intelligence, competence formation, national capacity, Nexus Universe readiness, and lawful handoff context.

5.6.1.2 Public-Good Innovation shall be evaluated by public-good value, evidence basis, safeguard status, national relevance, openness where safe, controlled access where necessary, correctionability, anti-capture, interoperability, sustainability, accessibility, and downstream boundary clarity.

5.6.1.3 Public-Good Innovation shall not be reduced to market novelty, investor interest, sponsor visibility, provider promotion, media visibility, or technology demonstration. It shall be record-bearing and correctionable.

### 5.6.2 Frontier Technology Innovation.

5.6.2.1 Frontier Technology Innovation Portfolio logic shall cover AI, agentic systems, AI-RAN, O-RAN, telecom, edge, HPC, sovereign compute, cybersecurity, geospatial, Earth observation, digital twins, robotics, drones, sensors, IoT, OT, IIoT, DLT, DePIN, Web3, quantum-relevant systems, semiconductors, advanced manufacturing, biosecurity-sensitive systems, and frontier science infrastructure.

5.6.2.2 Frontier Technology Innovation shall require heightened attention to AI-use labels, data-use labels, cyber controls, safety controls, dual-use controls, standards-interface records, provider-neutrality, sponsor-boundary controls, public authority dependencies, Grid inputs, TRL notes, Studio controls, and handoff dependencies.

5.6.2.3 Frontier Technology Innovation shall not create technology approval, product certification, safety approval, deployment authorization, procurement preference, financeability, insurance approval, or execution.

### 5.6.3 Social and Institutional Innovation.

5.6.3.1 Social and Institutional Innovation Portfolio logic shall cover new or improved institutional practices, governance models, public authority learning rooms, community safeguards, Indigenous protocol-sensitive pathways where applicable, workforce pathways, Campaign structures, National Council formation, Working Group models, Competence Cell models, Academy pathways, Registry and Marketplace practices, correction processes, and lawful handoff structures.

5.6.3.2 Social and Institutional Innovation shall be evaluated by legitimacy, role separation, national ownership, public-good discipline, anti-capture, accessibility, inclusion, correctionability, evidence quality, and no-conversion protection.

5.6.3.3 Institutional innovation shall not create hidden agency, shared liability, collapsed authority, public authority substitution, or execution by governance design.

### 5.6.4 Governance Innovation.

5.6.4.1 Governance Innovation Portfolio logic shall cover new methods for public-good stewardship, records discipline, Docket governance, review gates, release classes, correction mechanisms, archive rules, claims discipline, public-safe reporting, standards-interface handling, finance-readiness boundaries, procurement neutrality, sponsor controls, provider controls, community safeguards, and lawful handoff.

5.6.4.2 Governance Innovation shall be tested through records, scenarios, controlled workflows, public-safe review, stakeholder formation, and correction pathways before being generalized across Nexus.

5.6.4.3 Governance Innovation shall not be treated as authority merely because it is designed, piloted, or published.

### 5.6.5 Data and Intelligence Innovation.

5.6.5.1 Data and Intelligence Innovation Portfolio logic shall cover data commons, metadata, data dictionaries, schemas, DRI indicators, Observatory signals, GRIx taxonomies, dashboards, AI-assisted analysis, model cards, system cards, benchmark cards, digital twins, compute-to-data workflows, secure rooms, clean rooms, and public-safe intelligence summaries.

5.6.5.2 Data and Intelligence Innovation shall prioritize data rights, privacy, data sovereignty, public-safe transformation, AI-use controls, cyber controls, geospatial sensitivity, protected knowledge, community safeguards, Indigenous protocols where applicable, and correctionability.

5.6.5.3 Data and Intelligence Innovation shall not create data rights, AI training permission, surveillance authority, public warning authority, official decision authority, insurance score, investment signal, or execution authority.

### 5.6.6 Open Technical Baselines.

5.6.6.1 Open Technical Baselines shall be reusable public-good technical foundations that support interoperability, learning, public-good software, reference implementation, data exchange, AI evaluation, Studio workflows, Registry and Marketplace objects, Grid inputs, TRL notes, Nexus Universe builds, National Portfolio support, and lawful handoff context.

5.6.6.2 Open Technical Baselines shall include scope, version, steward, license, dependencies, assumptions, test status, support class, security status, public-safe status, standards-interface notes, correction pathway, and archive rule.

5.6.6.3 Open Technical Baselines shall not create warranty, certification, procurement status, provider validation, public authority approval, deployment authorization, or execution.

### 5.6.7 Public-Good Software.

5.6.7.1 Public-Good Software Portfolio logic shall cover repositories, libraries, services, dashboards, APIs, SDKs, connectors, adapters, notebooks, templates, infrastructure-as-code, test suites, reference implementations, model evaluation tools, Studio components, Registry components, Marketplace components, Campaign components, Academy components, DRI tools, Observatory tools, and handoff support tools.

5.6.7.2 Public-Good Software shall be governed by repository records, maintainers, contributors, licensing, code review, dependency scanning, SBOM records, vulnerability disclosure, support classes, release classes, public-safe documentation, correction, deprecation, and archive.

5.6.7.3 Public-Good Software shall not create warranty, certification, production approval, procurement recommendation, provider validation, public authority approval, financeability, insurance approval, deployment authorization, or execution.

### 5.6.8 National Technology Portfolios.

5.6.8.1 National Technology Portfolios shall organize country-level technology needs, assets, gaps, public-good software, open technical baselines, data infrastructure, AI capabilities, cyber capabilities, telecom capabilities, compute capabilities, geospatial capabilities, Observatory needs, Studio needs, Academy pathways, Foundry builds, Grid inputs, TRL notes, Nexus Universe demonstrations, and handoff dependencies.

5.6.8.2 National Technology Portfolios shall preserve national ownership, data sovereignty, public authority boundaries, community safeguards, provider neutrality, sponsor boundaries, standards-interface discipline, and lawful handoff rules.

5.6.8.3 National Technology Portfolio status shall not create national technology endorsement, procurement status, financeability, insurance approval, public authority approval, or deployment authorization.

### 5.6.9 Labs-to-Foundry Pathways.

5.6.9.1 Labs-to-Foundry Pathways shall translate research questions, evidence gaps, methods, testbeds, datasets, models, simulations, benchmark records, and public-safe findings into Foundry quests, bounties, builds, open technical baselines, data pipelines, software objects, Reports, Studio workflows, Grid inputs, TRL notes, or handoff dependency objects.

5.6.9.2 Labs-to-Foundry movement shall require transfer records identifying evidence, method, limitations, data-use labels, AI-use labels, cyber controls, public-safe status, safeguard status, support needs, maintainer needs, and correction pathway.

5.6.9.3 Labs-to-Foundry movement shall not convert research into deployment approval, certification, procurement readiness, financeability, insurance approval, or execution.

### 5.6.10 Foundry-to-Handoff Pathways.

5.6.10.1 Foundry-to-Handoff Pathways shall translate reviewed Foundry outputs into bounded lawful handoff dependency context. Outputs may include software, data pipelines, dashboards, Studio workflows, Registry records, Marketplace objects, Reports, Grid inputs, TRL notes, National Portfolio objects, and Nexus Universe outputs.

5.6.10.2 Foundry-to-Handoff records shall identify evidence context, data context, method context, support class, technical dependencies, 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.

5.6.10.3 Foundry-to-Handoff movement shall not authorize implementation, deployment, procurement, financing, underwriting, certification, consent, or execution.

## 5.7 Risk-Weighted Prioritization

### 5.7.1 Nexus Risk–Readiness–Safeguard–Public-Good Scoring.

5.7.1.1 NAF shall use Nexus Risk–Readiness–Safeguard–Public-Good Scoring to prioritize portfolio work. This scoring shall weigh public-good value, risk reduction potential, urgency, evidence readiness, learning value, national relevance, regional relevance, whole-of-society relevance, technical feasibility, safeguard status, data and AI status, cyber status, standards-interface relevance, support class, handoff dependency clarity, correction sensitivity, and archive need.

5.7.1.2 This scoring shall replace narrow delivery-priority logic with public-good systems logic. It shall prevent sponsor influence, provider influence, capital-reader interest, media visibility, political attention, or internal convenience from overriding evidence, risk, safeguards, national ownership, public authority boundaries, and correction discipline.

5.7.1.3 Scoring shall be a decision-support record, not an authority record. It shall not create ranking, certification, financeability, procurement preference, public authority approval, consent, deployment authorization, or execution.

### 5.7.2 Strategic Fit.

5.7.2.1 Strategic Fit shall assess whether a portfolio item advances Nexus purpose, public-good mandate, national or regional priorities, Nexus Universe cycle needs, all-hazards resilience, WFEH-B resilience, DRR/DRF/DRI integration, exponential-technology governance, public authority learning, open technical baselines, public-safe reporting, lawful handoff context, or correction.

5.7.2.2 Strategic Fit shall not be used to justify work that violates non-execution, no-conversion, public-good firewall, national ownership, safeguards, data rights, AI controls, cyber controls, procurement neutrality, finance-readiness boundaries, or role separation.

### 5.7.3 Public-Good Value.

5.7.3.1 Public-Good Value shall assess whether a portfolio item improves shared capability, evidence, learning, interoperability, public-safe knowledge, data commons, public-good software, risk intelligence, observability, national capacity, accessibility, inclusion, correctionability, or lawful handoff understanding.

5.7.3.2 Public-Good Value shall not be equated with revenue potential, sponsor value, provider visibility, investor interest, media attention, or private advantage.

### 5.7.4 Risk Reduction Potential.

5.7.4.1 Risk Reduction Potential shall assess whether a portfolio item may help reduce, understand, communicate, prepare for, or lawfully route work concerning hazards, vulnerabilities, exposure, resilience capacity, cascading risk, climate risk, cyber-physical risk, technology risk, public authority capacity gaps, finance-readiness gaps, insurance-readiness gaps, or WFEH-B system risk.

5.7.4.2 Risk Reduction Potential shall be recorded with limitations and shall not be overstated as measured risk reduction unless supported by evidence. It shall not create public warning, insurance rating, investment signal, procurement score, or public authority decision.

### 5.7.5 Evidence Readiness.

5.7.5.1 Evidence Readiness shall assess whether sufficient evidence exists to proceed to the next lifecycle stage. It shall consider source quality, method quality, data quality, reproducibility, review status, uncertainty, confidence where applicable, limitations, public-safe status, and correction pathway.

5.7.5.2 Evidence Readiness shall not be treated as certification, approval, maturity, financeability, insurability, procurement readiness, or deployment authorization.

### 5.7.6 Safeguard Status.

5.7.6.1 Safeguard Status shall assess whether community safeguards, Indigenous protocols where applicable, protected knowledge controls, youth safeguards, disability inclusion, accessibility, humanitarian sensitivity, rights concerns, and public-safe communication needs are satisfied for the proposed stage of movement.

5.7.6.2 Unsatisfied safeguard status shall slow, restrict, reroute, pause, correct, or stop work where appropriate. Safeguard satisfaction shall not imply consent unless consent is separately and lawfully recorded.

### 5.7.7 National Ownership.

5.7.7.1 National Ownership shall assess whether country-level work is shaped, localized, recorded, reviewed, and routed through appropriate national pathways. It shall consider National Nexus Consortium interfaces, National Councils, National Working Groups, Competence Cells, National Nodes, public authority learning, language localization, legal context, data sovereignty, community safeguards, and lawful handoff channels.

5.7.7.2 National Ownership shall prevent bypass but shall not create national gatekeeping abuse, public authority substitution, monopoly control, procurement control, finance control, or execution authority.

### 5.7.8 Feasibility and Support Class.

5.7.8.1 Feasibility and Support Class shall assess whether a portfolio item can be responsibly advanced with available evidence, expertise, tools, data rights, infrastructure, funding support where lawful, reviewers, maintainers, public-safe capacity, safeguard capacity, security capacity, and correction capacity.

5.7.8.2 Support Class shall state expected support and limits. Support status shall not create warranty, service guarantee, procurement readiness, financeability, public authority approval, or deployment authorization.

### 5.7.9 Handoff Dependency Clarity.

5.7.9.1 Handoff Dependency Clarity shall assess whether the dependencies required for lawful handoff are understood, recorded, and bounded. These may include evidence, data, methods, public authority approvals, legal requirements, finance and insurance questions, procurement processes, technical readiness, safeguard conditions, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathway, and recall pathway.

5.7.9.2 Clear handoff dependencies do not mean handoff approval. They mean that NAF can describe what competent lawful actors must consider independently.

### 5.7.10 Correction Sensitivity.

5.7.10.1 Correction Sensitivity shall assess the likelihood and consequence of error, overclaim, outdated evidence, misclassification, public-safe risk, data issue, AI issue, cyber issue, protected knowledge issue, public authority boundary issue, finance/procurement boundary issue, sponsor/provider boundary issue, consent overclaim, handoff overclaim, or execution overclaim.

5.7.10.2 High correction sensitivity shall require stronger review, clearer boundary notices, tighter release class, stronger downstream tracking, and explicit correction propagation.

## 5.8 Portfolio Governance Metrics

### 5.8.1 Evidence Velocity.

5.8.1.1 Evidence Velocity shall measure how effectively portfolio items move from evidence need to evidence assembly, review, release, routing, and correction within scope. It shall consider quality, not only speed.

5.8.1.2 Evidence Velocity shall not reward rushed, weak, unsafe, or overclaimed outputs. Evidence Velocity is useful only where evidence remains traceable, reviewable, public-safe, and correctionable.

### 5.8.2 Correction Velocity.

5.8.2.1 Correction Velocity shall measure how quickly and effectively NAF detects, records, contains, corrects, propagates, and archives corrections. It shall include errors, overclaims, incident records, Registry status updates, Marketplace delisting, Report corrections, Studio restrictions, Grid downgrades, TRL corrections, Campaign freezes, handoff recalls, and public-safe notices.

5.8.2.2 Correction Velocity shall be treated as a trust metric. A high-quality correction culture is evidence of institutional maturity, not institutional weakness.

### 5.8.3 Public-Safe Release Rate.

5.8.3.1 Public-Safe Release Rate shall measure the rate at which portfolio outputs are transformed into appropriate release classes, including public-safe summaries, controlled public outputs, open public outputs, Studio-only outputs, data-room-only outputs, secure-room-only outputs, handoff-recipient-only outputs, archived outputs, and non-continuing outputs.

5.8.3.2 Public-Safe Release Rate shall not reward public exposure where control is required. Proper restriction may be a positive public-safe outcome.

### 5.8.4 National Portfolio Maturity Inputs.

5.8.4.1 National Portfolio Maturity Inputs shall measure the completeness and quality of 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, handoff dependency records, correction records, and archives.

5.8.4.2 National Portfolio Maturity Inputs shall not become maturity certification, country ranking, public authority evaluation, procurement score, investment score, or insurance score.

### 5.8.5 Learning Conversion Rate.

5.8.5.1 Learning Conversion Rate shall measure how portfolio needs become Academy modules, Risk Academy modules, Work-Integrated Learning Paths, Integrated Learning Account records, micro-credentials where applicable, public authority learning records, Foundry contributor pathways, public-safe reporting training, safeguard training, and handoff literacy.

5.8.5.2 Learning Conversion Rate shall not imply professional licensing, employment, public authority competence certification, procurement qualification, or execution authority.

### 5.8.6 Campaign Activation Rate.

5.8.6.1 Campaign Activation Rate shall measure how portfolio priorities become Campaign objects, public-safe messages, support pathways, volunteer pathways, teams, chapters, ambassadors, public-safe stories, Campaign dashboards, and Nexus Universe mobilization.

5.8.6.2 Campaign Activation Rate shall not measure public mandate, consent, approval, finance commitment, donor commitment, public authority action, or execution readiness.

### 5.8.7 Foundry Build Completion.

5.8.7.1 Foundry Build Completion shall measure completion of quests, bounties, builds, public-good software, data pipelines, dashboards, Studio workflows, Registry records, Marketplace objects, Reports builds, Grid inputs, TRL notes, National Portfolio builds, Campaign builds, and handoff dependency builds.

5.8.7.2 Foundry Build Completion shall not imply deployment readiness, certification, provider validation, procurement readiness, financeability, insurance approval, or execution.

### 5.8.8 Registry Status Completeness.

5.8.8.1 Registry Status Completeness shall measure whether objects have accurate identity, version, steward, lifecycle state, review status, data-use label, AI-use label, support class, release class, correction pathway, withdrawal status where applicable, recall status where applicable, and archive rule.

5.8.8.2 Registry completeness shall preserve status truth. It shall not create certification or approval.

### 5.8.9 Marketplace Discovery Completeness.

5.8.9.1 Marketplace Discovery Completeness shall measure whether eligible objects have appropriate metadata, public-safe descriptions, license status, access class, support class, Registry linkage, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, correction pathway, and archive rule.

5.8.9.2 Marketplace discovery completeness shall not imply endorsement, procurement recommendation, provider validation, financeability, insurance approval, or implementation authority.

### 5.8.10 Handoff Dependency Readiness.

5.8.10.1 Handoff Dependency Readiness shall measure whether potential lawful handoff packages contain sufficient 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 pathway, recall pathway, and archive rule.

5.8.10.2 Handoff Dependency Readiness shall not imply handoff authorization, recipient approval, financeability, insurability, procurement status, certification, consent, deployment authorization, or execution.

### 5.8.11 DRI Refresh Rate.

5.8.11.1 DRI Refresh Rate shall measure how often DRI indicators, signal records, confidence labels, uncertainty labels, dashboards, hotspot records, multi-hazard records, cascade records, national DRI contributions, public-safe summaries, corrections, and archive records are reviewed and updated.

5.8.11.2 DRI Refresh Rate shall support risk-intelligence currency without creating warning authority, rating authority, insurance scoring, investment signaling, public authority decision-making, or emergency command.

### 5.8.12 Archive Integrity.

5.8.12.1 Archive Integrity shall measure whether inactive, superseded, withdrawn, recalled, deprecated, unsupported, non-continuing, and historical portfolio objects are properly preserved with archive-not-current notices, access class, public-safe status, sensitivity status, support status, license status, correction history, successor links, retention rules, sealing or deletion rules where applicable, and permitted historical use.

5.8.12.2 Archive Integrity shall preserve institutional memory and prevent obsolete records from being misused as current authority.

5.8.12.3 The final portfolio rule of Part V is that NAF portfolios shall translate strategy into Dockets, Dockets into governed work, governed work into evidence, evidence into public-safe records, public-safe records into readiness memory, readiness memory into Nexus Universe and national continuation, and continuation into lawful handoff context where appropriate, while no portfolio status, signal, metric, priority, map, report, build, listing, registry entry, readiness note, or handoff dependency shall become certification, procurement, finance, insurance, public authority action, public warning, consent, deployment, or execution 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/v.-portfolios.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.