> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/cooperation/nexus-universe/framework/xxix.-portfolios.md). # XXIX. PORTFOLIOS ### Summary * Defines the national portfolio as the country-level record for Nexus evidence, learning, and continuation context. * Organizes national inputs from Nexus Universe and Foundry, including stacks, consortiums, working groups, competence cells, and WEFH-B records. * Sets boundaries for continuation, handoff, dependencies, public-safe reporting, regional links, and long-term archive. ## 29.1 National Portfolio Role ### 29.1.1 National Portfolio Function 29.1.1.1 **National Portfolio** means the country-level public-good record through which Nexus Universe outputs, Nexus Foundry work, BuildGrid contributions, Nexus Core validation records, Stack Passports, Evidence Packs, public authority learning records, Competence Cell records, industrial capability records, WEFH-B records, public-safe reporting notes, capital-readability notes, insurance-readiness notes, Grid inputs, Rails routes, and lawful handoff dependencies are organized for national memory, national priority-setting, national capability formation, and lawful continuation review. 29.1.1.2 The National Portfolio is not a government plan by default, not a procurement pipeline, not a finance pipeline, not a public authority decision system, not a project approval system, and not a deployment program. It is the public-good record layer that helps a country understand what was prepared, tested, evidenced, corrected, matured, routed, held, withdrawn, archived, or identified for separate lawful review. 29.1.1.3 The National Portfolio gives Nexus Universe national continuity. Without it, annual validation outputs risk becoming disconnected demonstrations. With it, evidence, learning, talent, public authority questions, industrial capability, safeguard conditions, and continuation dependencies become country-level institutional memory. ### 29.1.2 National Portfolio Composition 29.1.2.1 A National Portfolio may include national stack records, National Team records, National Nexus Consortium records, National Working Group records, Competence Cell records, public authority learning records, industrial capability records, WEFH-B records, talent and Academy records, capital-readability notes, insurance-readiness notes, public-safe reporting notes, Grid input summaries, Rails route summaries, continuation Dockets, National Consortium Company review notes, Project SPV candidate review notes, safeguard records, community dependency notes, and archive references. 29.1.2.2 The National Portfolio should distinguish public-good records from enterprise-stack records, learning records from decisions, maturity inputs from certification, Rails routes from execution, and handoff context from authority transfer. 29.1.2.3 National Portfolio entries must be versioned, source-linked, classified, correctionable, and bounded by public-safe, data, privacy, protected knowledge, public authority, capital-readiness, insurance-readiness, procurement, and lawful-handoff rules. ### 29.1.3 National Portfolio Users 29.1.3.1 National Portfolio users may include National Nexus Consortiums, National Working Groups, Competence Cells, public authorities, universities, companies, communities, Indigenous actors where applicable, civil society, capital readers, insurers, donors, DFIs, MDBs, hosts, providers, National Consortium Companies, Project SPVs, and lawful execution actors, each only within the role and access class recorded for that user. 29.1.3.2 National Portfolio use must remain role-separated. A public authority may learn from a portfolio without approving it. A capital reader may read evidence without financing it. A National Consortium Company may review dependencies without executing them. A Project SPV candidate may be mapped without being formed. ### 29.1.4 National Portfolio Boundary 29.1.4.1 The National Portfolio does not create sovereign endorsement, public authority approval, procurement status, public finance allocation, financeability, bankability, insurance approval, community consent, Indigenous consent, certification, deployment authorization, or execution authority. 29.1.4.2 The National Portfolio organizes national evidence and continuation context only. ## 29.2 National Portfolio Inputs from Nexus Universe ### 29.2.1 Universe Input Function 29.2.1.1 **National Portfolio Inputs from Nexus Universe** are the country-relevant records produced through Nexus Universe that may be entered into a National Portfolio after classification, public-safe review, evidence review, correction review, and national relevance review. 29.2.1.2 These inputs connect the annual validation cycle to national continuity. They capture what national teams, national institutions, public authorities, universities, companies, communities, Competence Cells, and lawful continuation actors may learn from Nexus Core validation, public dashboards, challenge results, evidence records, failures, corrections, recognition records, Grid inputs, Rails routes, and public-safe reports. 29.2.1.3 A Nexus Universe output becomes a National Portfolio input only where the record identifies the country relevance, evidence basis, limitations, correction status, access class, public-safe treatment, and boundary conditions. ### 29.2.2 Input Categories 29.2.2.1 National Portfolio inputs from Nexus Universe may include Stack Passports, stack results, National Team results, challenge records, benchmark records, telemetry summaries, public dashboard records, recognition records, failure and correction analyses, public-safe reports, public authority learning summaries, capital-readiness explainers, insurance-readiness notes, community safeguard records, accessibility records, talent records, public-good release records, Grid inputs, Rails routes, and handoff dependency notes. 29.2.2.2 Inputs may also include national capability gaps, infrastructure gaps, data gaps, model gaps, cyber gaps, workforce gaps, public authority learning gaps, safeguard gaps, capital-readiness gaps, insurance-readiness gaps, and continuation dependencies identified during Nexus Universe. 29.2.2.3 Inputs must distinguish direct national participation from general relevance. A stack may be nationally built, nationally hosted, nationally tested, nationally relevant, nationally routed, nationally reviewed, or merely relevant to a national priority. Each basis must be recorded. ### 29.2.3 Input Records 29.2.3.1 National Portfolio Universe Input Records should identify the source Nexus Universe record, country relevance, participating actors, evidence basis, access class, public-safe status, correction status, Grid status, Rails status, limitation, dependency, and archive reference. 29.2.3.2 Inputs affected by disputes, safety holds, integrity holds, corrections, withdrawals, or archive restrictions must not be treated as current without the relevant status notice. ### 29.2.4 Universe Input Boundary 29.2.4.1 A Nexus Universe input to a National Portfolio does not create national adoption, government approval, procurement status, financeability, insurance approval, public authority action, community consent, deployment authorization, or execution authority. 29.2.4.2 It records national relevance of Universe evidence only. ## 29.3 National Portfolio Inputs from Nexus Foundry ### 29.3.1 Foundry Input Function 29.3.1.1 **National Portfolio Inputs from Nexus Foundry** are the country-relevant Dockets, Programs, Tracks, Quests, Bounties, Builds, review-gate records, release-class records, public-good object records, Stack Passport candidates, Evidence Pack candidates, Grid input candidates, Rails route candidates, and lawful handoff dependency candidates prepared through Nexus Foundry. 29.3.1.2 Foundry inputs allow a National Portfolio to capture not only what was validated during Nexus Universe, but what is being prepared, corrected, held, matured, or routed toward future cycles. 29.3.1.3 Foundry inputs are preparation records. They are not validation records unless separately validated through Nexus Core or another recorded review process. ### 29.3.2 Foundry Input Categories 29.3.2.1 National Portfolio inputs from Nexus Foundry may include national priority Dockets, public authority question Dockets, community concern Dockets, national WEFH-B challenge Dockets, industrial capability Dockets, AI and compute Dockets, cyber and infrastructure Dockets, public-good software Dockets, Academy and workforce Dockets, capital-readiness Dockets, insurance-readiness Dockets, and lawful continuation Dockets. 29.3.2.2 Foundry inputs may also include national Foundry Programs, national Tracks, regional Tracks with national relevance, country-specific Quests, BuildGrid Bounties, public-good Builds, Competence Cell preparation records, and release-class records. 29.3.2.3 Each Foundry input must identify whether it is exploratory, active, Universe-preparing, Universe-ready, Grid-ready, Rails-ready, handoff-ready candidate, held, returned for correction, superseded, withdrawn, retired, or archived. ### 29.3.3 Foundry Input Records 29.3.3.1 National Portfolio Foundry Input Records should identify Docket or Program identity, national relevance, source signal, public-good purpose, participants, review-gate status, release class, evidence requirements, safeguard requirements, public-safe status, correction status, and archive reference. 29.3.3.2 Foundry inputs involving protected knowledge, public authority-sensitive information, sovereign data, community safeguards, capital-reader materials, insurance-reader materials, or handoff-only materials must be classified and access-limited. ### 29.3.4 Foundry Input Boundary 29.3.4.1 A Foundry input to a National Portfolio does not create validation, national adoption, public authority approval, procurement status, financeability, insurance approval, community consent, deployment authorization, Project SPV approval, National Consortium Company approval, or execution authority. 29.3.4.2 It records national preparation status only. ## 29.4 National Stack Participation ### 29.4.1 National Stack Participation Function 29.4.1.1 **National Stack Participation** records the participation of country-linked stacks, National Teams, national institutions, universities, companies, public-good teams, Competence Cells, National Working Groups, National Nexus Consortiums, public authorities, hosts, and lawful support actors in Nexus Universe stack preparation, Stack Passport submission, Nexus Core validation, public-safe reporting, Grid input preparation, Rails routing, and handoff dependency mapping. 29.4.1.2 National Stack Participation helps a country understand which technical capabilities were prepared or tested in its name, by its institutions, within its territory, for its public-good priorities, or with relevance to its national systems. 29.4.1.3 National stack participation must be carefully bounded because national attribution can be misread as sovereign endorsement, government approval, public finance support, procurement status, or national deployment intent. ### 29.4.2 Participation Basis 29.4.2.1 National Stack Participation may be based on builder location, operator location, National Nexus Consortium routing, National Working Group contribution, public authority question, national host hub participation, national dataset contribution, national university participation, national company participation, community relevance, sector relevance, or National Portfolio relevance. 29.4.2.2 The participation basis must be recorded. A nationally relevant stack is not necessarily nationally endorsed. A nationally hosted stack is not necessarily nationally adopted. A public authority-question stack is not necessarily public authority-approved. 29.4.2.3 Where multiple countries contribute to a stack, the record should distinguish national contribution, regional contribution, cross-border contribution, and global contribution. ### 29.4.3 National Stack Records 29.4.3.1 National Stack Participation Records should identify stack identity, country attribution basis, builder, operator, Competence Cell support, Foundry origin, BuildGrid origin, Stack Passport status, validation status, score status, recognition status, correction status, Grid status, Rails status, handoff dependency status, and archive reference. 29.4.3.2 Records should identify sponsor, provider, public authority, capital-reader, insurance-reader, community, and host relationships where relevant. ### 29.4.4 National Stack Boundary 29.4.4.1 National Stack Participation does not create sovereign endorsement, public authority approval, procurement status, public finance allocation, financeability, insurance approval, community consent, deployment authorization, certification, or execution authority. 29.4.4.2 It records national stack participation only. ## 29.5 National Public-Good Consortium Participation ### 29.5.1 National Consortium Participation Function 29.5.1.1 **National Public-Good Consortium Participation** records the role of the National Nexus Consortium in preparing, coordinating, contextualizing, reviewing, and preserving country-level Nexus Universe participation and National Portfolio continuity. 29.5.1.2 The National Nexus Consortium acts as the normal country-level public-good gateway for Nexus activity. It may organize stakeholder formation, National Councils, Helix Councils, National Working Groups, Competence Cells, National Portfolio inputs, public authority learning, public-safe reporting, and lawful continuation preparation without becoming a public authority, procurement body, financier, insurer, project developer, or execution vehicle. 29.5.1.3 National Consortium participation gives country-level structure to Nexus Universe outputs while preserving non-execution and role separation. ### 29.5.2 Consortium Functions 29.5.2.1 A National Nexus Consortium may support National Portfolio intake, national Docket formation, national challenge framing, National Team formation, Competence Cell formation, public authority learning coordination, community safeguard coordination, national public-safe reporting, sponsor boundary discipline, provider neutrality, national Grid input review, Rails continuation review, and lawful handoff preparation. 29.5.2.2 A National Nexus Consortium may also coordinate with Regional Nexus Consortiums and the Global Nexus Consortium where national outputs have regional or global relevance. 29.5.2.3 National Consortium participation must not bypass national public authorities, community safeguards, Indigenous protocols where applicable, public-good stack controls, enterprise-stack separation, or lawful handoff requirements. ### 29.5.3 Consortium Participation Records 29.5.3.1 National Public-Good Consortium Participation Records should identify Consortium role, National Portfolio functions performed, councils involved, Working Groups involved, Competence Cells involved, public authority interfaces, sponsor and provider controls, safeguard records, Grid inputs, Rails routes, correction status, and archive reference. 29.5.3.2 Records should distinguish consortium coordination from public authority approval, National Consortium Company action, Project SPV action, procurement, finance, insurance, and execution. ### 29.5.4 Consortium Participation Boundary 29.5.4.1 National Public-Good Consortium Participation does not create government approval, procurement status, public finance allocation, financeability, insurance approval, certification, community consent, deployment authorization, National Consortium Company approval, Project SPV approval, or execution authority. 29.5.4.2 It coordinates public-good national participation only. ## 29.6 National Working Group Participation ### 29.6.1 National Working Group Function 29.6.1.1 **National Working Group Participation** records the role of National Working Groups in preparing, reviewing, contextualizing, and continuing Nexus Universe and Nexus Foundry work within a country. 29.6.1.2 National Working Groups may be thematic, sectoral, technical, domain-specific, regional-within-country, public authority-facing, community-facing, industry-facing, academic, capital-readiness-facing, insurance-readiness-facing, or safeguard-focused. 29.6.1.3 National Working Groups help convert national priorities and Nexus Universe outputs into structured national evidence, learning, capability, and continuation records without becoming execution bodies. ### 29.6.2 Working Group Functions 29.6.2.1 National Working Groups may support challenge framing, Stack Passport preparation, Evidence Pack review, public-safe reporting, public authority learning materials, WEFH-B records, industrial capability records, Academy records, community safeguard records, data governance review, Grid input preparation, Rails route preparation, and National Continuation Docket updates. 29.6.2.2 Working Groups may also refer work to Nexus Foundry, BuildGrid, Competence Cells, National Portfolio review, Regional Nexus Consortium review, or lawful handoff preparation. 29.6.2.3 Working Group outputs must be reviewed, classified, and corrected before being treated as National Portfolio entries. ### 29.6.3 Working Group Records 29.6.3.1 National Working Group Participation Records should identify Working Group identity, mandate, members or participant classes where public-safe, Dockets reviewed, outputs produced, evidence reviewed, safeguards considered, public authority questions addressed, correction status, and archive reference. 29.6.3.2 Records should identify conflicts, sponsor involvement, provider involvement, public authority involvement, community participation, and boundary controls where relevant. ### 29.6.4 Working Group Boundary 29.6.4.1 National Working Group Participation does not create public authority approval, procurement status, financeability, insurance approval, certification, community consent, deployment authorization, National Consortium Company approval, Project SPV approval, or execution authority. 29.6.4.2 National Working Groups prepare and review public-good records only. ## 29.7 National Competence Cell Participation ### 29.7.1 National Competence Cell Function 29.7.1.1 **National Competence Cell Participation** records the role of country-linked Nexus Competence Cells in preparing stacks, supporting Foundry Programs, operating BuildGrid work, assisting Nexus Core validation, assembling Evidence Packs, supporting public-safe reporting, preparing Grid inputs, preparing Rails continuation notes, updating National Portfolios, and mapping lawful handoff dependencies. 29.7.1.2 National Competence Cells are capability structures. They help a country retain technical, evidence, data, AI, cyber, public-safe, safeguard, and continuation competence after the annual Nexus Universe cycle. 29.7.1.3 National Competence Cell status must be governed because it may otherwise be misread as certification authority, public authority status, procurement qualification, provider approval, financeability, or execution authority. ### 29.7.2 Competence Cell Functions 29.7.2.1 National Competence Cells may support stack preparation, integration, telemetry, benchmark readiness, Model Cards, System Cards, Benchmark Cards, Safety Cases, Cyber Cases, Data Cases, public-safe output cases, AI governance, data governance, cyber review, interoperability review, post-validation analysis, Grid maturity input, Rails continuation note, and handoff dependency mapping. 29.7.2.2 Competence Cells may also support national workforce formation through Nexus Academy, Risk Academy, micro-credentials, Work-Integrated Learning Programs, and contribution recognition. 29.7.2.3 Competence Cell outputs must identify reviewer role, evidence basis, limitation, conflict status, correction status, and access class. ### 29.7.3 Competence Cell Records 29.7.3.1 National Competence Cell Participation Records should identify cell identity, country relationship, domain, functions performed, stacks supported, Foundry work supported, BuildGrid work supported, evidence assembled, training outputs, public-safe outputs, Grid inputs, Rails notes, handoff dependencies, correction status, and archive reference. 29.7.3.2 Records should disclose sponsor support, provider relationships, conflicts, and role limitations where relevant. ### 29.7.4 Competence Cell Boundary 29.7.4.1 National Competence Cell Participation does not create certification, procurement status, financeability, insurance approval, public authority approval, provider approval, community consent, deployment authorization, or execution authority. 29.7.4.2 It records national competence support only. ## 29.8 National Public Authority Learning Records ### 29.8.1 Public Authority Learning Record Function 29.8.1.1 **National Public Authority Learning Records** are National Portfolio entries documenting public authority participation, observer status, learning questions, scenario rooms, dashboard review, capacity gap notes, rule-interface notes, public-safe summaries, continuation questions, and boundary incidents arising from Nexus Universe, Nexus Foundry, Nexus Core, Nexus Grid, Nexus Rails, or National Working Group activity. 29.8.1.2 These records preserve public authority learning without converting learning into public authority action. 29.8.1.3 Public authority learning records are especially sensitive because they may be misread as regulatory approval, procurement preference, public finance allocation, policy adoption, public warning, emergency command, or deployment authorization. ### 29.8.2 Record Contents 29.8.2.1 National Public Authority Learning Records may include authority participant category, learning context, questions reviewed, evidence reviewed, dashboards reviewed, scenarios reviewed, capacity gaps identified, rule-interface issues identified, public-safe report relevance, Grid relevance, Rails route relevance, confidentiality status, correction status, and archive reference. 29.8.2.2 Records must distinguish observer participation, technical participation, question ownership, public-service learning, confidential review, and public-safe summary. 29.8.2.3 Records must not disclose confidential public authority information, security-sensitive information, public authority-sensitive deliberations, protected knowledge, personal data, or handoff-only details unless authorized. ### 29.8.3 Learning Record Correction 29.8.3.1 Public authority learning records must be corrected where they overstate public authority role, misstate evidence, omit limitations, imply approval, or create public warning confusion. 29.8.3.2 Public authority boundary incidents must be recorded and corrected. ### 29.8.4 Public Authority Learning Boundary 29.8.4.1 National Public Authority Learning Records do not create public authority approval, regulatory approval, procurement status, public finance allocation, public warning, emergency command, policy adoption, deployment authorization, or execution authority. 29.8.4.2 They record learning only. ## 29.9 National Industrial Capability Records ### 29.9.1 Industrial Capability Record Function 29.9.1.1 **National Industrial Capability Records** document country-level industrial capabilities, gaps, stack participation, technology readiness, infrastructure readiness, workforce readiness, public-good software readiness, supply-chain relevance, host capacity, provider capacity, university capacity, and lawful continuation dependencies identified through Nexus Universe and Nexus Foundry. 29.9.1.2 Industrial Capability Records help a country understand how high-performance technologies relate to manufacturing, logistics, telecom, energy, water, food, health, built environment, mining, materials, ports, mobility, public services, cyber-physical infrastructure, and other productive systems. 29.9.1.3 Industrial capability must be recorded as evidence and learning, not as procurement preference, investment quality, national endorsement, or deployment approval. ### 29.9.2 Record Contents 29.9.2.1 Industrial Capability Records may include relevant stacks, industrial challenges, benchmark results, interoperability findings, continuity findings, supply-chain issues, workforce gaps, infrastructure gaps, cyber posture, data posture, AI posture, public-good assets, National Working Group outputs, Competence Cell outputs, Grid inputs, Rails routes, and handoff dependency maps. 29.9.2.2 Records should distinguish demonstrated capability, partially demonstrated capability, simulated capability, proposed capability, inferred capability, unvalidated capability, and capability gap. 29.9.2.3 Records must identify limitations, evidence quality, dependency assumptions, correction status, and access class. ### 29.9.3 Industrial Capability Correction 29.9.3.1 Industrial Capability Records must be corrected where evidence changes, stack status changes, benchmark results are corrected, capability is overstated, dependencies are missing, or continuation routes change. 29.9.3.2 Industrial capability overclaims may require public-safe correction, National Portfolio correction, Grid correction, Rails correction, or handoff package correction. ### 29.9.4 Industrial Capability Boundary 29.9.4.1 National Industrial Capability Records do not create vendor approval, procurement status, investment recommendation, financeability, insurance approval, public authority approval, national adoption, deployment authorization, or execution authority. 29.9.4.2 They record industrial learning and capability context only. ## 29.10 National Talent and Academy Records ### 29.10.1 Talent and Academy Record Function 29.10.1.1 **National Talent and Academy Records** document country-level learning, workforce formation, Academy participation, Risk Academy participation, Work-Integrated Learning Programs, micro-credentials, contribution recognition, BuildGrid participation, Competence Cell apprenticeships, university participation, youth participation, public-good software contribution, public-safe reporting contribution, and national skills intelligence arising from Nexus Universe and Nexus Foundry. 29.10.1.2 These records help a country understand how Nexus Universe contributes to future workforce capability, systems-risk literacy, AI literacy, cyber literacy, data literacy, public-good software capability, evidence discipline, and lawful continuation capacity. 29.10.1.3 Talent records must be governed to prevent misuse as employment ranking, immigration signal, social scoring, procurement qualification, wage promise, professional licensure, or public authority status. ### 29.10.2 Record Contents 29.10.2.1 National Talent and Academy Records may include learning pathways, courses, micro-credentials where separately governed, BuildGrid contributions, Competence Cell training, mentorship records, youth participation, university participation, Work-Integrated Learning Program records, Integrated Learning Account references, contribution recognition, accessibility learning, public-safe reporting learning, and skills gap notes. 29.10.2.2 Records must protect personal data, youth data, learner privacy, contributor privacy, and sensitive participation data. 29.10.2.3 Public versions should use aggregated or public-safe summaries unless individual publication is specifically permitted. ### 29.10.3 Talent Record Correction 29.10.3.1 Talent and Academy Records must be corrected where participation is misstated, contribution is overstated, credential status is incorrect, youth privacy is affected, or public claims imply employment or professional status. 29.10.3.2 Corrections should propagate to National Portfolio summaries, Academy records, BuildGrid cards, Competence Cell profiles, and public-safe reports where relevant. ### 29.10.4 Talent and Academy Boundary 29.10.4.1 National Talent and Academy Records do not create employment, academic credit, professional licensure, immigration status, wage promise, procurement qualification, public authority status, financeability, insurance approval, deployment authorization, or execution authority. 29.10.4.2 They record learning and contribution only. ## 29.11 National WEFH-B Records ### 29.11.1 WEFH-B Record Function 29.11.1.1 **National WEFH-B Records** document country-level Nexus Universe and Nexus Foundry evidence, learning, stack participation, challenges, risks, gaps, public authority questions, community safeguards, public-safe reports, Grid inputs, Rails routes, and continuation dependencies relating to water, energy, food, health, and built environment systems. 29.11.1.2 WEFH-B systems are core national resilience terrain. They connect public services, critical infrastructure, climate adaptation, industrial continuity, community welfare, public authority learning, insurance-readiness, capital-readiness, and lawful implementation pathways. 29.11.1.3 National WEFH-B Records must preserve public-good evidence without becoming public warnings, public authority directives, procurement lists, investment pipelines, or deployment plans by implication. ### 29.11.2 Record Contents 29.11.2.1 National WEFH-B Records may include stack results, digital twin outputs, simulation outputs, public-safe risk summaries, public authority learning records, community safeguard records, data governance notes, infrastructure dependencies, cyber dependencies, workforce dependencies, capital-readiness notes, insurance-readiness notes, Grid inputs, Rails routes, and handoff dependency maps. 29.11.2.2 Records should identify whether evidence relates to water systems, energy systems, food systems, health systems, built environment systems, cross-system cascade risk, climate adaptation, nature systems, or industrial continuity. 29.11.2.3 WEFH-B records involving health-sensitive data, community vulnerability, critical infrastructure, protected knowledge, or public authority-sensitive information must be access-controlled and public-safe reviewed. ### 29.11.3 WEFH-B Correction 29.11.3.1 National WEFH-B Records must be corrected where data changes, model assumptions change, digital twin outputs change, public-safe reports are corrected, community safeguard issues arise, or public warning confusion occurs. 29.11.3.2 WEFH-B corrections may require dashboard correction, public-safe notice, public authority boundary correction, community safeguard correction, Grid correction, Rails correction, or archive update. ### 29.11.4 WEFH-B Boundary 29.11.4.1 National WEFH-B Records do not create public warning, emergency command, public authority approval, procurement status, financeability, insurance approval, community consent, deployment authorization, or execution authority. 29.11.4.2 They record WEFH-B evidence and learning only. ## 29.12 National Capital-Readability Notes ### 29.12.1 Capital-Readability Note Function 29.12.1.1 **National Capital-Readability Notes** are no-reliance, non-advisory, non-soliciting, non-transactional National Portfolio records that summarize evidence relevant to capital readability, diligence gaps, risk-to-capital mapping, public finance relevance, resilience value, SPV-readiness dependencies, and lawful continuation conditions. 29.12.1.2 These notes help capital readers, donors, DFIs, MDBs, public finance observers, National Consortium Companies, Project SPV candidates, and lawful continuation actors understand evidence gaps and dependency maps without creating financeability, bankability, investment advice, public finance allocation, guarantee, rating, or transaction status. 29.12.1.3 Capital-readability notes must remain evidence notes, not deal materials. ### 29.12.2 Note Contents 29.12.2.1 National Capital-Readability Notes may include relevant Nexus Universe records, Stack Passports, Evidence Packs, Grid inputs, Rails routes, resilience value evidence, public authority dependencies, host dependencies, provider dependencies, technical dependencies, safeguard dependencies, data dependencies, insurance questions, revenue-model questions where appropriate, legal dependencies, and unresolved diligence gaps. 29.12.2.2 Notes must include no-investment-advice, no-solicitation, no-financeability, no-bankability, no-rating, no-guarantee, no-public-finance-allocation, no-procurement, and no-execution notices. 29.12.2.3 Notes may be public-safe, controlled, capital-reader-room-only, handoff-only, or archive-only depending on sensitivity. ### 29.12.3 Capital-Readability Correction 29.12.3.1 Capital-Readability Notes must be corrected where evidence changes, dependencies change, overclaims occur, public authority status changes, Grid status changes, Rails status changes, or handoff package status changes. 29.12.3.2 Finance overclaim incidents must trigger correction and may require Rails hold or handoff correction. ### 29.12.4 Capital-Readability Boundary 29.12.4.1 National Capital-Readability Notes do not create investment advice, solicitation, financeability, bankability, rating, guarantee, public finance allocation, procurement status, public authority approval, deployment authorization, or execution authority. 29.12.4.2 They make evidence more readable to capital-relevant actors only. ## 29.13 National Public-Safe Reporting Notes ### 29.13.1 Public-Safe Reporting Note Function 29.13.1.1 **National Public-Safe Reporting Notes** are National Portfolio records that identify what Nexus Universe and Nexus Foundry outputs may be communicated publicly for a country, under what wording, with what limitations, with what corrections, and with what boundary notices. 29.13.1.2 These notes support public learning, public dashboards, media materials, annual reports, community-facing summaries, public authority learning summaries, and national public-good communication. 29.13.1.3 National Public-Safe Reporting Notes prevent national evidence from being turned into public warning, government endorsement, procurement signal, finance signal, insurance signal, community consent claim, or deployment claim. ### 29.13.2 Note Contents 29.13.2.1 National Public-Safe Reporting Notes may include approved public wording, prohibited wording, public-safe evidence summaries, public authority boundary language, capital-readiness boundary language, insurance-readiness boundary language, community consent boundary language, protected knowledge restrictions, geospatial masking requirements, accessibility requirements, translation requirements, correction notices, and archive references. 29.13.2.2 Notes should identify which materials may be public, which are controlled, which are restricted, which are protected, which are public authority-sensitive, which are handoff-only, and which are archive-only. 29.13.2.3 Notes must be updated when evidence, scores, recognition, Grid inputs, Rails routes, public authority participation, capital-readiness status, community safeguard status, or correction status changes. ### 29.13.3 Reporting Note Correction 29.13.3.1 Public-Safe Reporting Notes must be corrected where public materials misstate evidence, omit limitations, expose protected knowledge, imply public authority approval, imply consent, or create finance/procurement/insurance overclaim. 29.13.3.2 Corrections must propagate to public dashboards, reports, media packages, National Portfolio summaries, and public archive entries where relevant. ### 29.13.4 Public-Safe Reporting Boundary 29.13.4.1 National Public-Safe Reporting Notes do not create public warning, public authority approval, procurement status, financeability, insurance approval, community consent, deployment authorization, or execution authority. 29.13.4.2 They govern public-safe communication only. ## 29.14 National Continuation Docket ### 29.14.1 National Continuation Docket Function 29.14.1.1 **National Continuation Docket** is the country-level record of Nexus Universe and Nexus Foundry outputs that require further action, review, correction, maturation, public authority learning, Foundry continuation, BuildGrid work, Grid review, Rails routing, National Consortium Company review, Project SPV candidate review, community safeguard review, capital-readiness review, insurance-readiness review, or lawful handoff preparation. 29.14.1.2 The National Continuation Docket is the structured continuation memory of the National Portfolio. It prevents promising outputs, unresolved gaps, failures, corrections, and dependencies from being lost after the annual cycle. 29.14.1.3 A continuation Docket does not authorize continuation. It identifies what may need separate review. ### 29.14.2 Docket Categories 29.14.2.1 National Continuation Docket categories may include return to Foundry, return to BuildGrid, additional stack validation, public authority learning follow-up, community safeguard follow-up, protected knowledge review, data governance review, cyber review, AI review, WEFH-B follow-up, industrial capability follow-up, Academy follow-up, Grid maturity review, Rails route review, National Consortium Company review, Project SPV-readiness review, capital-readiness review, insurance-readiness review, public-safe reporting correction, and archive-only. 29.14.1.2 Each Docket item should identify priority, evidence basis, unresolved gaps, dependencies, responsible public-good actor, possible lawful continuation actor, access class, correction status, and archive reference. 29.14.2.3 Docket priority must not be determined by sponsor pressure, provider influence, capital interest, media attention, or public authority overclaim. ### 29.14.3 Docket Records 29.14.3.1 National Continuation Docket Records should identify item identity, source record, national relevance, route type, dependencies, safeguards, limitations, review status, correction status, next review gate, and archive reference. 29.14.3.2 Docket items should be closed, continued, held, returned, withdrawn, retired, or archived by record. ### 29.14.4 Continuation Docket Boundary 29.14.4.1 National Continuation Docket status does not create project approval, public authority approval, procurement status, financeability, insurance approval, community consent, deployment authorization, National Consortium Company approval, Project SPV approval, or execution authority. 29.14.4.2 It records continuation questions only. ## 29.15 Regional Cluster Records ### 29.15.1 Regional Cluster Record Function 29.15.1.1 **Regional Cluster Records** document how national Nexus Universe outputs, Foundry Programs, stacks, Competence Cells, Working Groups, public authority learning, WEFH-B records, industrial capability records, public-safe reports, Grid inputs, Rails routes, and continuation Dockets relate to wider regional cluster priorities. 29.15.1.2 Regional Cluster Records allow a National Portfolio to connect national work to regional systems, cross-border risks, shared infrastructure, supply chains, climate corridors, water basins, energy systems, food systems, health systems, telecom systems, cyber systems, industrial corridors, and regional public-good learning. 29.15.1.3 Regional cluster recording must preserve national ownership. Regional relevance does not override national authority, national safeguards, national data rules, community safeguards, Indigenous protocols where applicable, or lawful handoff conditions. ### 29.15.2 Record Contents 29.15.2.1 Regional Cluster Records may include regional risk relevance, cross-border infrastructure relevance, shared WEFH-B relevance, industrial corridor relevance, data-sharing dependencies, public authority interface notes, regional Competence Cell relevance, regional Foundry Tracks, regional Nexus Universe host relevance, Grid relevance, Rails route relevance, and lawful continuation dependencies. 29.15.2.2 Records should identify whether the national output is regionally informative, regionally reusable, regionally interoperable, regionally dependent, regionally constrained, or regionally routed. 29.15.2.3 Records must classify cross-border data, public authority-sensitive information, protected knowledge, and sovereign dependencies. ### 29.15.3 Regional Cluster Correction 29.15.3.1 Regional Cluster Records must be corrected when national evidence changes, regional assumptions change, cross-border dependencies change, data-sharing conditions change, public authority status changes, or Rails routes change. 29.15.3.2 Regional overclaims must be corrected where a regional record implies authority over a country, public authority approval, procurement, finance, insurance, or execution. ### 29.15.4 Regional Cluster Boundary 29.15.4.1 Regional Cluster Records do not create regional supremacy, national adoption, public authority approval, cross-border authorization, procurement status, financeability, insurance approval, community consent, deployment authorization, or execution authority. 29.15.4.2 They record regional relevance only. ## 29.16 Regional Nexus Consortium Interface ### 29.16.1 Regional Interface Function 29.16.1.1 **Regional Nexus Consortium Interface** defines how a National Portfolio may interface with a Regional Nexus Consortium for regional coordination, regional cluster planning, regional Nexus Universe preparation, regional public-safe reporting, regional Competence Cell formation, regional Observatory linkages, regional Grid and Rails alignment, and cross-border continuation questions. 29.16.1.2 The Regional Nexus Consortium may support translation, clustering, country support, regional learning, and regional public-good coordination without supremacy over National Nexus Consortiums or national public-good ownership. 29.16.1.3 The regional interface exists to strengthen national portfolios through regional learning, not to replace national decision-making. ### 29.16.2 Interface Activities 29.16.2.1 Interface activities may include regional review of National Portfolio themes, regional cluster mapping, regional Foundry Track coordination, cross-border Docket coordination, regional host hub preparation, regional public-safe report alignment, regional data governance issue identification, regional Competence Cell coordination, and regional continuation dependency mapping. 29.16.2.2 The interface must preserve national access controls, sovereign data rules, public authority confidentiality, protected knowledge restrictions, community safeguards, sponsor controls, provider neutrality, and lawful handoff boundaries. 29.16.2.3 Regional Nexus Consortium inputs should be recorded as support, coordination, or regional learning, not as national approval. ### 29.16.3 Interface Records 29.16.3.1 Regional Nexus Consortium Interface Records should identify Regional Consortium role, National Portfolio records reviewed, regional cluster issues, cross-border issues, support provided, limitations, safeguards, correction status, and archive reference. 29.16.3.2 Records should distinguish regional coordination from national adoption and external execution. ### 29.16.4 Regional Interface Boundary 29.16.4.1 The Regional Nexus Consortium Interface does not create regional authority over national portfolios, public authority approval, procurement status, financeability, insurance approval, cross-border authorization, community consent, deployment authorization, or execution authority. 29.16.4.2 It enables regional coordination only. ## 29.17 Cross-Border Corridors ### 29.17.1 Cross-Border Corridor Function 29.17.1.1 **Cross-Border Corridors** are recorded pathways through which National Portfolio outputs may relate to shared regional or international systems, including infrastructure corridors, energy corridors, water basins, food systems, health systems, supply chains, telecom corridors, cyber dependencies, transport routes, climate adaptation systems, nature systems, migration-linked systems, industrial corridors, and public authority learning interfaces. 29.17.1.2 Cross-border corridors help identify interdependence. They do not create cross-border authority, project approval, data transfer permission, public authority action, procurement, finance, insurance, or execution. 29.17.1.3 Corridor records are especially sensitive because they may involve sovereign data, public authority-sensitive information, critical infrastructure, protected knowledge, geospatial risk, security issues, and multiple legal systems. ### 29.17.2 Corridor Record Contents 29.17.2.1 Cross-Border Corridor Records may include corridor identity, countries involved, systems involved, risks, dependencies, data restrictions, public authority questions, technical interoperability issues, WEFH-B relevance, industrial relevance, Grid inputs, Rails routes, continuation Dockets, public-safe reporting status, and safeguard requirements. 29.17.2.2 Corridor records must distinguish observed interdependence from approved corridor action, proposed coordination from authorized coordination, and evidence context from execution. 29.17.2.3 Corridor records must apply cross-border transfer controls, geospatial masking, protected knowledge controls, public authority confidentiality, and public-safe reporting controls. ### 29.17.3 Corridor Correction 29.17.3.1 Cross-Border Corridor Records must be corrected where evidence changes, jurisdictional conditions change, data permissions change, public authority positions change, cross-border dependencies change, or corridor relevance is overstated. 29.17.3.2 Corridor overclaims may require public-safe correction, public authority boundary correction, data transfer correction, or Rails hold. ### 29.17.4 Cross-Border Corridor Boundary 29.17.4.1 Cross-Border Corridor Records do not create treaty status, cross-border authorization, public authority approval, procurement status, financeability, insurance approval, public warning, community consent, deployment authorization, or execution authority. 29.17.4.2 They record cross-border relevance and dependencies only. ## 29.18 National Ownership and Local Delivery ### 29.18.1 National Ownership Function 29.18.1.1 **National Ownership and Local Delivery** is the principle that country-level Nexus outputs, National Portfolio records, National Continuation Dockets, public authority learning, public-safe reporting, Competence Cell formation, National Working Group activity, National Consortium Company review, Project SPV candidate review, and lawful handoff preparation must preserve national ownership before local delivery and local delivery before execution. 29.18.1.2 National ownership means that country-level Nexus activity should be organized through the National Nexus Consortium and national public-good structures where applicable, with respect for national law, public authority roles, data sovereignty, community safeguards, Indigenous protocols where applicable, and local institutional realities. 29.18.1.3 Local delivery means that any downstream implementation must be performed only by competent lawful actors under separate authority, not by Nexus Universe or the National Portfolio. ### 29.18.2 Ownership and Delivery Requirements 29.18.2.1 National Portfolio records should identify national relevance, local relevance, responsible public-good actors, possible lawful continuation actors, public authority dependencies, host dependencies, provider dependencies, workforce dependencies, community dependencies, data dependencies, capital dependencies, insurance dependencies, and safeguard dependencies. 29.18.2.2 National ownership must not be bypassed by global, regional, sponsor, provider, capital, media, or external institutional pressure. 29.18.2.3 Local delivery must not be implied from validation, recognition, Grid input, Rails route, public authority learning, capital-readability, insurance-readiness, National Portfolio entry, National Consortium Company review, or Project SPV candidate review. ### 29.18.3 Ownership Records 29.18.3.1 National Ownership and Local Delivery Records should identify national public-good owner, local delivery context where relevant, lawful authority conditions, dependency map, safeguards, access class, correction status, and archive reference. 29.18.3.2 Records should distinguish national public-good ownership from execution ownership, local readiness from deployment approval, and handoff context from authority transfer. ### 29.18.4 Ownership and Delivery Boundary 29.18.4.1 National Ownership and Local Delivery records do not create public authority approval, procurement status, financeability, insurance approval, community consent, deployment authorization, Project SPV approval, National Consortium Company approval, or execution authority. 29.18.4.2 They preserve ownership and dependency context only. ## 29.19 National Company Continuation Review ### 29.19.1 National Company Review Function 29.19.1.1 **National Company Continuation Review** is the recorded interface through which a National Consortium Company may review National Portfolio records, National Continuation Docket items, Grid inputs, Rails routes, Evidence Packs, public authority learning records, capital-readability notes, insurance-readiness notes, host dependencies, provider dependencies, safeguard dependencies, and lawful handoff packages for possible separate enterprise-stack consideration. 29.19.1.2 National Company Continuation Review is not automatic continuation. It is not procurement, investment, contracting, finance, insurance, public authority approval, project approval, deployment authorization, or execution. 29.19.1.3 The review exists to help separate enterprise vehicles understand public-good evidence without collapsing into public-good governance. ### 29.19.2 Review Requirements 29.19.2.1 National Company review should identify evidence received, dependencies identified, unresolved gaps, public authority conditions, procurement conditions, finance conditions, insurance conditions, host conditions, provider conditions, workforce conditions, data conditions, community safeguards, protected knowledge restrictions, correction status, and external review needs. 29.19.2.2 The review must preserve legal separateness between National Nexus Consortium, Nexus Universe, GCRI, GRF, GRA, public authorities, National Consortium Company, Project SPVs, providers, sponsors, capital readers, insurers, and lawful execution actors. 29.19.2.3 Review materials must include no-automatic-continuation, no-procurement, no-finance, no-insurance, no-public-authority-approval, no-deployment, and no-execution notices. ### 29.19.3 Review Records 29.19.3.1 National Company Continuation Review Records should identify company role, records reviewed, evidence basis, dependencies, limitations, conflicts, decision status, correction status, handoff package status, and archive reference. 29.19.3.2 Records should distinguish review from acceptance, acceptance from contracting, contracting from financing, and financing from execution. ### 29.19.4 National Company Review Boundary 29.19.4.1 National Company Continuation Review does not create National Consortium Company approval, procurement approval, financeability, insurance approval, public authority approval, community consent, deployment authorization, Project SPV approval, or execution authority. 29.19.4.2 It supports separate lawful enterprise-stack review only. ## 29.20 Project SPV Candidate Review ### 29.20.1 Project SPV Candidate Review Function 29.20.1.1 **Project SPV Candidate Review** is the recorded review of whether a National Portfolio output, Nexus Universe result, Foundry Program, Grid input, Rails route, or National Continuation Docket item has sufficient evidence, dependency clarity, safeguard clarity, authority clarity, and unresolved-gap mapping to be considered as a possible candidate for separate Project SPV evaluation outside the public-good stack. 29.20.1.2 A Project SPV candidate is not a Project SPV. Candidate status does not mean formation, approval, financing, procurement, insurance, public authority approval, community consent, deployment authorization, or execution. 29.20.1.3 Candidate review identifies whether the evidence package is coherent enough for separate lawful actors to consider next steps. ### 29.20.2 Candidate Review Requirements 29.20.2.1 Project SPV Candidate Review should identify project concept, source records, technical evidence, public authority dependencies, procurement dependencies, finance dependencies, insurance dependencies, host dependencies, provider dependencies, workforce dependencies, data dependencies, community safeguard dependencies, protected knowledge restrictions, legal dependencies, environmental dependencies, cyber dependencies, AI dependencies, unresolved risks, correction status, and archive reference. 29.20.2.2 Candidate review must identify what remains outside Nexus Universe, including contracting, financing, underwriting, permitting, procurement, community consent, public authority authorization, engineering approval, environmental approval, legal compliance, construction, deployment, operation, and risk allocation. 29.20.2.3 Candidate review must be classified and access-controlled where it involves confidential enterprise, public authority, capital, insurance, community, or protected knowledge information. ### 29.20.3 Candidate Review Records 29.20.3.1 Project SPV Candidate Review Records should identify candidate item, evidence basis, dependencies, readiness gaps, external review needs, access class, correction status, Rails relationship, National Company relationship where applicable, and archive reference. 29.20.3.2 Candidate status should be active, held, returned for Foundry work, returned for Grid review, returned for Rails review, corrected, withdrawn, retired, or archived by record. ### 29.20.4 Project SPV Candidate Boundary 29.20.4.1 Project SPV Candidate Review does not create Project SPV formation, Project SPV approval, investment approval, procurement approval, financeability, insurance approval, public authority approval, community consent, deployment authorization, or execution authority. 29.20.4.2 It records possible external review context only. ## 29.21 Public Authority, Host, Provider, Capital, Insurance, Safeguard, and Community Dependencies ### 29.21.1 Dependency Record Function 29.21.1.1 **Public Authority, Host, Provider, Capital, Insurance, Safeguard, and Community Dependencies** are National Portfolio records identifying the external conditions that would need to be satisfied before any Nexus Universe or Nexus Foundry output could lawfully continue beyond public-good evidence, maturity, routing, or handoff context. 29.21.1.2 Dependency records prevent overclaim by showing that validation does not equal implementation. Even a strong stack, recognition record, Grid input, Rails route, National Portfolio entry, National Company review, or Project SPV candidate may depend on unresolved authority, host, provider, finance, insurance, safeguard, community, legal, data, workforce, security, or operational conditions. 29.21.1.3 Dependency recording is a core lawful handoff discipline. ### 29.21.2 Dependency Categories 29.21.2.1 Public authority dependencies may include permits, approvals, regulatory review, policy decisions, public finance decisions, public warnings, emergency powers, procurement authority, data authority, public service authority, or legal mandates. 29.21.2.2 Host and provider dependencies may include site access, infrastructure capacity, technical support, operations capability, service-level arrangements, cyber controls, data hosting, compute resources, network resources, maintenance obligations, and continuity plans. 29.21.2.3 Capital and insurance dependencies may include diligence gaps, risk allocation, revenue assumptions, resilience value evidence, finance structure questions, public finance relevance, insurance evidence, underwriting questions, coverage conditions, guarantees, or external transaction requirements. 29.21.2.4 Safeguard and community dependencies may include community engagement, Indigenous protocols where applicable, protected knowledge restrictions, consent processes, accessibility, geospatial masking, environmental safeguards, rights-bearing data controls, and public-safe reporting conditions. ### 29.21.3 Dependency Records 29.21.3.1 Dependency Records should identify dependency type, source record, responsible external actor where known, status, evidence basis, unresolved gap, required next review, access class, correction status, and archive reference. 29.21.3.2 Dependencies should be classified as satisfied, partially satisfied, unresolved, blocked, not applicable, externally pending, returned for review, corrected, withdrawn, retired, or archived. 29.21.3.3 Dependency satisfaction must be recorded separately and must not be inferred from participation, attendance, sponsorship, visibility, recognition, or public statements. ### 29.21.4 Dependency Boundary 29.21.4.1 Dependency Records do not satisfy the dependency by themselves and do not create public authority approval, host approval, provider commitment, capital commitment, insurance approval, community consent, procurement status, deployment authorization, or execution authority. 29.21.4.2 They identify what remains to be lawfully resolved. ## 29.22 National Portfolio Archive ### 29.22.1 National Portfolio Archive Function 29.22.1.1 **National Portfolio Archive** is the country-level archive preserving National Portfolio records, Universe inputs, Foundry inputs, stack records, consortium records, Working Group records, Competence Cell records, public authority learning records, industrial capability records, talent and Academy records, WEFH-B records, capital-readability notes, public-safe reporting notes, continuation Dockets, regional cluster records, cross-border corridor records, National Company review records, Project SPV candidate records, dependency records, corrections, withdrawals, retirements, and archive-only materials. 29.22.1.2 The National Portfolio Archive preserves institutional memory across cycles. It allows a country to understand what was tried, what was validated, what failed, what was corrected, what matured, what routed, what stopped, what returned to Foundry, what remained unresolved, and what was archived. 29.22.1.3 The Archive must preserve national memory without exposing restricted data, protected knowledge, public authority-sensitive information, personal data, cyber-sensitive material, capital-reader materials, insurance-reader materials, confidential enterprise information, or handoff-only materials. ### 29.22.2 Archive Structure 29.22.2.1 The National Portfolio Archive should include public-safe archive, controlled archive, restricted archive, sovereign archive, protected archive, public authority-sensitive archive, capital-reader-room archive, insurance-reader-room archive, handoff-only archive, legal-hold archive, and long-term preservation archive where applicable. 29.22.2.2 Archive entries should identify source record, version, status, access class, correction history, supersession status, withdrawal status, retirement status, legal hold status, retention rule, deletion rule where applicable, and archive reference. 29.22.2.3 Public archive materials should remain accessible where public-safe, while controlled and restricted materials should remain available only to authorized users under recorded conditions. ### 29.22.3 Archive Correction and Renewal 29.22.3.1 National Portfolio Archive records must be correctionable. Corrections, supersessions, withdrawals, retirements, access changes, legal holds, and public-safe notices must be linked to affected records. 29.22.3.2 Each annual Nexus Universe cycle should review relevant National Portfolio Archive entries for renewal, continuation, correction, downgrade, retirement, or carry-forward into the next National Continuation Docket. 29.22.3.3 Archive does not mean disappearance. It means the record is preserved with accurate status. ### 29.22.4 Final National Portfolio Rule 29.22.4.1 No National Portfolio entry, National Portfolio input, National Stack record, National Consortium record, Working Group record, Competence Cell record, public authority learning record, industrial capability record, WEFH-B record, capital-readability note, continuation Docket item, regional cluster record, cross-border corridor record, National Company review, Project SPV candidate review, dependency record, or archive entry may be treated as authority beyond its recorded scope. 29.22.4.2 The final National Portfolio rule is that Nexus Universe becomes nationally useful only when its outputs become national memory; national memory becomes trustworthy only when it remains evidence-linked, correctionable, public-safe, safeguard-aware, role-separated, and incapable of becoming procurement, finance, insurance, public authority approval, community consent, deployment authorization, or execution by implication. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.therisk.global/organization/cooperation/nexus-universe/framework/xxix.-portfolios.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.