# IX. HANDOFF This section explains how finance-readiness records move forward without carrying authority forward. It connects the [National Model](/organization/cooperation/consortiums/gateways/national-councils/investors/ix.-handoff.md), [Nexus Rails](/organization/organization/architecture/ii.-definitions/xv.-nexus-rails.md), AEP Passport pathways, Project SPV-readiness, and National Consortium Company interface controls. It defines lawful handoff for capital-readable, insurance-readiness, donor-relevant, and public-finance-relevant matters. It also keeps the boundary clear between public-good readiness and enterprise or project execution. ## 9.1 National Model Finance-Readiness Role ### 9.1.1 National Model as Country-Level Readiness Record **9.1.1.1** The **National Model** shall operate as a country-level readiness record within the National Nexus Consortium architecture. **9.1.1.2** The National Model may organize national priorities, public-good needs, systems-risk conditions, public authority learning, evidence records, technical readiness, observability inputs, National Working Group outputs, Helix Council inputs, Nexus Universe preparation, AEP Passport candidate inputs, Nexus Rail pathways, safeguard conditions, finance-readiness questions, insurance-readiness questions, donor relevance, public finance relevance, Project SPV-readiness questions, National Consortium Company interface conditions, Docket issues, and lawful handoff conditions. **9.1.1.3** The National Model shall not be treated as a project approval record, investment memorandum, public finance approval, donor approval, insurance approval, procurement document, certification, public authority decision, consent record, SPV authorization, National Consortium Company mandate, or execution instruction. **9.1.1.4** Inclusion of a matter in the National Model shall mean only that the matter has been recorded in the relevant country-level readiness architecture according to its recorded status, classification, limits, dependencies, safeguards, and correction pathway. **9.1.1.5** The governing rule shall be: **The National Model records country-level readiness; it does not approve finance, projects, public authority action, or execution.** *** ### 9.1.2 National Investors Council Role in National Model Review **9.1.2.1** The National Investors Council may review National Model materials for finance-readiness, capital-readability, insurance-readiness, public finance relevance, donor relevance, philanthropic relevance, development-readiness, diligence gaps, Project SPV-readiness, National Consortium Company finance-interface conditions, Nexus Rail finance-readiness, AEP Passport finance-layer inputs, and lawful handoff conditions. **9.1.2.2** The Council’s review shall identify what capital readers, insurers, donors, public finance readers, development actors, guarantee-readiness actors, National Consortium Companies, Project SPV pathways, public authorities, and lawful receiving actors may need to understand before any separate external process may occur. **9.1.2.3** The Council shall not approve the National Model, adopt national policy, approve projects, approve finance, approve insurance, approve donor support, approve public finance, approve procurement, approve providers, approve SPVs, bind National Consortium Companies, or authorize implementation through National Model review. **9.1.2.4** The Council’s National Model review outputs shall be classified as readiness notes, question sets, dependency notes, gap maps, routeability notes, Docket inputs, handoff-condition notes, or correction notes. **9.1.2.5** The governing rule shall be: **The Investors Council reviews the National Model to make finance-readiness legible, not to make the National Model financeable.** *** ### 9.1.3 Finance-Readiness Layer of National Model **9.1.3.1** The National Model may contain a finance-readiness layer for matters requiring capital-readable treatment. **9.1.3.2** The finance-readiness layer may include evidence basis, technical status, public authority status, governance structure, legal pathway, procurement dependency, revenue and cost assumptions, lifecycle obligations, risk allocation questions, insurance-readiness questions, donor relevance, public finance relevance, safeguard conditions, data and cyber conditions, community and Indigenous protocol conditions where applicable, environmental and social conditions, Project SPV-readiness conditions, National Consortium Company interface conditions, Nexus Rail routeability, AEP Passport finance-layer inputs, Docket issues, and correction pathway. **9.1.3.3** The finance-readiness layer shall be no-reliance, non-advisory, non-soliciting, non-transactional, claims-limited, safeguard-aware, publication-classified, and correctionable. **9.1.3.4** The finance-readiness layer shall not be described as financeability, bankability, investment readiness, insurance approval, donor approval, public finance approval, guarantee readiness, SPV approval, project approval, procurement status, or execution readiness. **9.1.3.5** The governing rule shall be: **The National Model finance-readiness layer makes gaps and dependencies visible before any lawful external finance process exists.** *** ### 9.1.4 Public Finance Relevance Layer **9.1.4.1** The National Model may contain a public finance relevance layer where a matter may intersect with public investment, public grants, public guarantees, subsidies, concessional finance, resilience finance, disaster-risk finance, climate finance, infrastructure finance, budget processes, public authority funding, public-private interface, or public-good value. **9.1.4.2** The public finance relevance layer may identify competent public authority dependencies, budget questions, public finance pathway questions, public guarantee questions, procurement dependencies, sovereign or subnational finance considerations, concessionality questions, public value logic, fiscal risk, safeguard requirements, and public authority capacity classification. **9.1.4.3** Public finance relevance shall not imply public finance allocation, public funding approval, budget approval, grant award, subsidy approval, public guarantee, procurement status, official position, government endorsement, or public authority action. **9.1.4.4** The layer shall carry no-public-finance-approval language and shall be reviewed carefully before public, donor-facing, investor-facing, sponsor-facing, provider-facing, or media-facing use. **9.1.4.5** The governing rule shall be: **The National Model may show where public finance could be relevant; it shall not show that public finance has been approved.** *** ### 9.1.5 Insurance-Readiness Layer **9.1.5.1** The National Model may contain an insurance-readiness layer where a matter involves exposure, hazard, vulnerability, loss, resilience controls, infrastructure risk, climate risk, cyber risk, disaster risk, public authority insurance interface, risk-transfer relevance, reinsurance relevance, guarantee-readiness, or Project SPV insurance dependency. **9.1.5.2** The insurance-readiness layer may identify insurance questions, reinsurance questions, data and model dependencies, exposure questions, asset questions, operating responsibility questions, public authority insurance dependencies, risk-transfer questions, protection-gap questions, cyber conditions, infrastructure sensitivity, and safeguard limits. **9.1.5.3** The insurance-readiness layer shall not be treated as insurance approval, reinsurance approval, underwriting approval, coverage availability, premium indication, insurability determination, guarantee approval, insurance advice, or insurance placement. **9.1.5.4** Insurance-readiness information shall be handled under confidentiality and competition-compliance controls where insurers, reinsurers, risk-transfer actors, or market-sensitive information are involved. **9.1.5.5** The governing rule shall be: **The National Model may record insurance questions; it shall not answer them as an insurer.** *** ### 9.1.6 Donor and Philanthropic Relevance Layer **9.1.6.1** The National Model may contain a donor and philanthropic relevance layer where a matter may align with donor, philanthropic, foundation, CSR, humanitarian, development, climate, resilience, disaster-risk, public-good, research, community-support, youth, accessibility, education, health, nature, or institutional-strengthening priorities. **9.1.6.2** The layer may identify mission fit, public-good value, development relevance, outcome logic, reporting needs, safeguard expectations, community conditions, public authority dependencies, capacity-building needs, and grant-readiness questions. **9.1.6.3** Donor and philanthropic relevance shall not imply donor commitment, philanthropic commitment, foundation approval, grant award, pledge, allocation, sponsorship, CSR commitment, development assistance commitment, or funding expectation. **9.1.6.4** The layer shall be claims-limited and public-safe where any donor or philanthropic actor is named or implied. **9.1.6.5** The governing rule shall be: **The National Model may identify donor and philanthropic relevance; it shall not create donor or philanthropic commitments.** *** ### 9.1.7 Safeguard and Community Dependency Layer **9.1.7.1** The National Model shall include safeguard and community dependency information where relevant to finance-readiness, capital-readability, insurance-readiness, donor relevance, public finance relevance, SPV-readiness, Rail routing, AEP Passport finance-layer inputs, or lawful handoff. **9.1.7.2** Safeguard and community dependencies may include privacy, cybersecurity, sovereign data, public authority-sensitive information, finance-sensitive information, insurance-sensitive information, donor-sensitive information, commercial sensitivity, provider sensitivity, community-sensitive information, Indigenous or protected knowledge where applicable, accessibility, health, biodiversity, infrastructure security, location sensitivity, environmental and social safeguards, consent boundaries, non-extractive engagement, language access, dignity, and public-safe reporting limits. **9.1.7.3** Community participation, Indigenous participation, diaspora participation, public-interest participation, protected-knowledge reference, safeguard input, or public-safe reporting shall not be treated as consent, rights-holder approval, social licence, data permission, publication authorization, project approval, finance approval, donor legitimacy, public finance legitimacy, or handoff permission. **9.1.7.4** Safeguard and community dependencies shall not be removed, diluted, or reframed to improve apparent financeability, donor appeal, public finance relevance, insurance-readiness, SPV-readiness, or project attractiveness. **9.1.7.5** The governing rule shall be: **A National Model finance-readiness record is unsafe if safeguard and community conditions do not travel with it.** *** ### 9.1.8 Public Authority Dependency Layer **9.1.8.1** The National Model may contain a public authority dependency layer where a matter requires or may require public authority learning, public authority review, regulatory approval, permits, licences, procurement, public finance, public guarantees, public utility approvals, emergency-management input, public health authority input, environmental authority input, infrastructure authority input, public data authorization, or other official process. **9.1.8.2** The public authority dependency layer shall identify the status of public authority involvement, including official, observer, learner, technical contributor, public-safe reviewer, public finance reader, regulator observer, personal-capacity participant, no official position, not yet engaged, or unknown. **9.1.8.3** Public authority dependency shall not be described as public authority approval, government endorsement, regulatory approval, public finance allocation, procurement status, permit, licence, policy adoption, public warning, emergency command, public data authorization, or official position unless a separate lawful public authority record supports that exact claim. **9.1.8.4** The layer shall be reviewed before external communication because public authority language carries high reliance risk. **9.1.8.5** The governing rule shall be: **The National Model must state public authority dependency precisely before any capital-facing or public-facing meaning can be safe.** *** ### 9.1.9 National Model Finance-Readiness Correction **9.1.9.1** The National Model finance-readiness layer shall be correctionable. **9.1.9.2** Correction may be required where the National Model misstates finance-readiness, capital-readability, public finance relevance, donor relevance, philanthropic relevance, insurance-readiness, public authority dependency, safeguard dependency, Project SPV-readiness, National Consortium Company interface conditions, Nexus Rail routeability, AEP Passport finance-layer status, Docket status, or handoff conditions. **9.1.9.3** Correction may include claim narrowing, revised status label, public-safe clarification, controlled clarification, publication reclassification, role reclassification, conflict disclosure, safeguard correction, Docket entry, Rail restriction, AEP Passport finance-layer update, handoff restriction, withdrawal, supersession, archive, or renewal. **9.1.9.4** Correction shall be urgent where the National Model has been used externally or where misunderstanding may create investment expectation, insurance expectation, donor expectation, public finance expectation, public authority confusion, sponsor advantage, provider advantage, community harm, or execution overclaim. **9.1.9.5** The governing rule shall be: **The National Model remains credible only while its finance-readiness layer remains correctable.** *** ### 9.1.10 National Model Finance-Readiness Renewal **9.1.10.1** The National Model finance-readiness layer shall be renewed periodically and at least in connection with the annual Nexus cycle where applicable. **9.1.10.2** Renewal may occur after Nexus Universe, National Council review, National Leadership Council review, Helix Council review, National Working Group outputs, public authority learning, new evidence, safeguard updates, public finance changes, donor changes, insurance-market changes, legal changes, procurement changes, data or cyber changes, AEP Passport pathway updates, Nexus Rail routing updates, Docket changes, handoff changes, or correction events. **9.1.10.3** Renewal shall identify whether each matter remains current, deferred, restricted, blocked, Docketed, corrected, superseded, archived, or ready for further lawful review. **9.1.10.4** Renewal shall not imply financeability, bankability, investment readiness, insurance approval, donor commitment, public finance allocation, SPV approval, project approval, procurement status, public authority approval, consent, or execution readiness. **9.1.10.5** The governing rule shall be: **National Model finance-readiness must renew because national conditions, finance conditions, evidence, safeguards, and public authority dependencies change.** *** ## 9.2 Nexus Rails Interface ### 9.2.1 Nexus Rails as Readiness Routing Pathways **9.2.1.1** Nexus Rails shall operate as readiness routing pathways within the Nexus architecture. **9.2.1.2** Nexus Rails may route matters among National Council records, Helix Council inputs, National Leadership Council priorities, National Investors Council finance-readiness notes, National Working Group outputs, National Model layers, Nexus Universe outputs, AEP Passport candidate pathways, Docket items, public-safe reporting, GCRI evidence pathways, GRF claims and legitimacy pathways, GRA finance-readiness pathways, National Consortium Company interface pathways, Project SPV-readiness pathways, public authority learning pathways, and lawful handoff pathways. **9.2.1.3** A Nexus Rail pathway shall not be treated as execution, approval, certification, procurement, finance, insurance, donor support, public finance allocation, public authority action, consent, SPV authorization, project approval, or Company action. **9.2.1.4** Rail routeability means that a matter may be eligible for recorded routing, review, restriction, deferral, Docketing, handoff preparation, correction, or archive, according to its record. **9.2.1.5** The governing rule shall be: **Nexus Rails route readiness; they do not execute the thing routed.** *** ### 9.2.2 National Investors Council Role in Nexus Rail Finance-Readiness **9.2.2.1** The National Investors Council may support Nexus Rail finance-readiness by identifying whether a matter has the finance-readiness, capital-readability, insurance-readiness, donor relevance, public finance relevance, diligence-gap, SPV-readiness, safeguard, public authority, and handoff information required for routing. **9.2.2.2** The Council may prepare Rail finance-readiness notes, Rail question sets, Rail dependency notes, Rail Docket items, Rail correction notes, and Rail handoff-condition notes. **9.2.2.3** The Council shall not approve Rail execution, determine final Rail status, approve finance, approve insurance, approve donor support, approve public finance, approve procurement, approve AEP Passport status, approve SPV formation, approve projects, or authorize handoff by supporting Rail finance-readiness. **9.2.2.4** The Council’s Rail role shall remain no-reliance, non-advisory, non-soliciting, non-transactional, claims-limited, safeguard-aware, and correctionable. **9.2.2.5** The governing rule shall be: **The Investors Council may strengthen Rail finance-readiness; it shall not execute or approve the Rail.** *** ### 9.2.3 Rail Candidate Identification **9.2.3.1** The National Investors Council may identify matters as Rail candidates where finance-readiness routing may be required or useful. **9.2.3.2** Rail candidates may include National Model items, Nexus Universe outputs, National Working Group outputs, AEP Passport candidates, public authority learning records, Docket items, insurance-readiness matters, donor relevance matters, public finance relevance matters, SPV-readiness matters, National Consortium Company interface matters, and handoff candidates. **9.2.3.3** Rail candidate identification shall not imply Rail approval, Rail execution, Nexus-ready status, financeability, bankability, insurability, donor support, public finance allocation, procurement status, public authority approval, SPV authorization, project approval, or execution readiness. **9.2.3.4** A Rail candidate record shall identify source record, route purpose, classification, gaps, public authority dependencies, safeguards, no-reliance status, claims limits, receiving pathway, and correction pathway. **9.2.3.5** The governing rule shall be: **Rail candidacy means a matter may need routing; it does not mean the route is approved or complete.** *** ### 9.2.4 Rail Finance-Readiness Questions **9.2.4.1** Rail finance-readiness questions may be developed to determine what must be understood before a matter moves along a Nexus Rail pathway. **9.2.4.2** Such questions may address evidence, technical readiness, governance, public authority status, legal pathway, procurement dependency, cost and revenue assumptions, lifecycle obligations, risk allocation, insurance-readiness, public finance relevance, donor relevance, safeguards, data and cyber conditions, community and Indigenous protocols where applicable, environmental and social conditions, Project SPV-readiness, National Consortium Company interface, AEP Passport finance-layer status, Docket issues, and handoff conditions. **9.2.4.3** Rail finance-readiness questions shall not be treated as answers, approvals, transaction documents, investment materials, insurance submissions, donor applications, public finance requests, procurement documents, project approvals, or execution instructions. **9.2.4.4** Unanswered Rail finance-readiness questions may restrict, defer, Docket, correct, or block routing. **9.2.4.5** The governing rule shall be: **A Rail finance-readiness question exists to prevent a matter from travelling farther than its record can safely support.** *** ### 9.2.5 Rail Public Authority Dependencies **9.2.5.1** Rail records shall identify public authority dependencies where a routed matter involves public finance, procurement, permits, licences, regulation, public data, public utilities, public infrastructure, emergency management, public health, environmental authority, infrastructure authority, municipal authority, national authority, or other official process. **9.2.5.2** Public authority dependencies shall identify whether public authority actors are official, observers, learners, technical contributors, public-safe reviewers, public finance readers, regulator observers, personal-capacity participants, no official position, not yet engaged, or unknown. **9.2.5.3** Rail public authority dependency records shall not imply public authority approval, public finance allocation, procurement status, permit, licence, policy adoption, official position, public warning, emergency command, or data authorization. **9.2.5.4** Rail routing shall be restricted where public authority dependency is material and unaddressed. **9.2.5.5** The governing rule shall be: **No matter should travel on Nexus Rails as capital-readable if its public authority dependency is hidden or overstated.** *** ### 9.2.6 Rail Insurance-Readiness Questions **9.2.6.1** Rail records may include insurance-readiness questions where a matter’s route depends on risk, exposure, loss, insurance, reinsurance, risk transfer, disaster-risk finance, infrastructure insurance, cyber insurance, public authority insurance interface, or protection-gap analysis. **9.2.6.2** Rail insurance-readiness questions may address exposure data, loss history, asset value, vulnerability, resilience controls, operating responsibility, cyber conditions, coverage needs, exclusions, underwriting information, reinsurance aggregation, triggers, basis risk, and public authority dependencies. **9.2.6.3** Rail insurance-readiness questions shall not imply insurance approval, coverage availability, premium indication, underwriting, insurability, reinsurance support, guarantee approval, insurance advice, or insurance placement. **9.2.6.4** Insurance-sensitive Rail records shall be classified and competition-compliant. **9.2.6.5** The governing rule shall be: **Insurance-readiness may inform Rail routeability; it shall not make the routed matter insured or insurable.** *** ### 9.2.7 Rail Project SPV-Readiness Questions **9.2.7.1** Rail records may include Project SPV-readiness questions where a routed matter may later require a project-specific lawful vehicle. **9.2.7.2** SPV-readiness questions may address legal form, governance, ownership, public authority approvals, procurement, permits, licences, finance, insurance, donor support, public finance, contracts, data rights, land or asset rights, provider-neutrality, safeguards, consent boundaries, lifecycle obligations, operating responsibility, reporting, audit, and decommissioning. **9.2.7.3** Rail SPV-readiness questions shall not imply SPV approval, SPV formation, project approval, financeability, bankability, insurability, procurement readiness, provider selection, public authority approval, consent, or execution authority. **9.2.7.4** Rail routing toward an SPV pathway shall carry conditions, restrictions, unresolved gaps, public authority dependencies, safeguard dependencies, conflicts, and claims limits. **9.2.7.5** The governing rule shall be: **Routing toward an SPV pathway is a question of possible future lawful review, not SPV authorization.** *** ### 9.2.8 Rail Handoff Conditions **9.2.8.1** Nexus Rail finance-readiness records may identify handoff conditions. **9.2.8.2** Handoff conditions may include receiving pathway, source record, purpose of handoff, no-reliance status, confidentiality class, public authority status, finance-readiness status, insurance-readiness status, donor relevance, public finance relevance, safeguard conditions, unresolved gaps, conflicts, claims limits, required reviews, prohibited inferences, correction pathway, and archive status. **9.2.8.3** Handoff conditions shall not be treated as handoff completion, finance approval, insurance approval, donor approval, public finance allocation, procurement status, certification, public authority approval, SPV approval, project approval, consent, Company action, or execution authority. **9.2.8.4** Handoff may proceed only where a competent receiving actor and competent record accept the matter within lawful bounds. **9.2.8.5** The governing rule shall be: **Rail handoff conditions carry limitations forward; they do not carry authority forward.** *** ### 9.2.9 Rail Claims Limits **9.2.9.1** All Nexus Rail finance-readiness records shall include claims limits. **9.2.9.2** A matter shall not be described as Rail-approved, Rail-executed, Nexus-ready, financeable, bankable, insurable, donor-backed, publicly financed, guaranteed, procured, certified, public-authority-approved, SPV-approved, project-approved, consented, or execution-ready by reason of Rail candidacy, Rail discussion, Rail routing, Rail notation, or Rail handoff condition. **9.2.9.3** Public, capital-facing, donor-facing, insurer-facing, public finance-facing, sponsor-facing, provider-facing, or media-facing Rail references shall use approved language and state only the recorded status. **9.2.9.4** Rail claims shall be corrected where they exceed the record. **9.2.9.5** The governing rule shall be: **Rail language must say where the matter is in routing, not imply where the matter has arrived.** *** ### 9.2.10 Rail Correction **9.2.10.1** Rail records and Rail-related claims shall be correctionable. **9.2.10.2** Rail correction may be required where routeability is overstated, dependencies are omitted, public authority status is misstated, insurance-readiness is overstated, donor relevance is overstated, public finance relevance is overstated, SPV-readiness is overstated, AEP Passport finance-layer status is misstated, safeguard conditions are omitted, or handoff status is misrepresented. **9.2.10.3** Correction may include claim narrowing, route restriction, Docket entry, public-safe clarification, controlled clarification, publication reclassification, receiving-pathway notice, handoff restriction, withdrawal, supersession, archive, or renewal. **9.2.10.4** Rail correction shall occur before an incorrect Rail claim becomes reliance, market signal, public finance expectation, donor expectation, insurance expectation, provider advantage, sponsor advantage, public authority confusion, or execution overclaim. **9.2.10.5** The governing rule shall be: **Rail correction prevents routeability from being misused as readiness, approval, or execution.** *** ## 9.3 AEP Passport Finance-Readiness Layers ### 9.3.1 AEP Passport as Record, Not Certification **9.3.1.1** The AEP Passport shall be treated, for purposes of the National Investors Council, as a record-based pathway or record layer, not as certification by the National Investors Council. **9.3.1.2** AEP Passport candidate materials may include evidence, readiness layers, public authority dependencies, safeguard conditions, observability inputs, Nexus Rail linkages, Docket items, finance-readiness layers, insurance-readiness layers, donor relevance layers, public finance relevance layers, Project SPV-readiness layers, and handoff conditions. **9.3.1.3** The National Investors Council may contribute finance-readiness inputs to AEP Passport candidate pathways but shall not issue the AEP Passport, approve Passport status, certify a candidate, declare Nexus-ready status, approve financeability, approve bankability, approve insurability, approve procurement, approve public authority status, approve consent, approve a project, or authorize execution. **9.3.1.4** Any AEP Passport-related claim shall state the exact recorded status, including candidate, input, layer, under review, deferred, restricted, Docketed, corrected, superseded, archived, or issued by competent process where applicable. **9.3.1.5** The governing rule shall be: **AEP Passport finance-readiness input may support the record; it shall not become certification.** *** ### 9.3.2 Finance-Readiness Layer **9.3.2.1** The AEP Passport candidate pathway may include a finance-readiness layer. **9.3.2.2** The finance-readiness layer may identify capital-readable evidence needs, finance-readiness gaps, public authority dependencies, technical evidence dependencies, data and cyber dependencies, safeguard dependencies, revenue and cost assumptions, lifecycle assumptions, risk allocation, insurance dependencies, public finance dependencies, donor dependencies, Project SPV-readiness, National Consortium Company interface conditions, Nexus Rail routeability, and Docket issues. **9.3.2.3** The finance-readiness layer shall be no-reliance, non-advisory, non-soliciting, non-transactional, claims-limited, and correctionable. **9.3.2.4** The finance-readiness layer shall not be treated as financeability, bankability, investment readiness, capital approval, lending approval, guarantee approval, transaction readiness, or project finance approval. **9.3.2.5** The governing rule shall be: **The AEP Passport finance-readiness layer records finance questions; it shall not create finance status.** *** ### 9.3.3 Capital-Readability Layer **9.3.3.1** The AEP Passport candidate pathway may include a capital-readability layer. **9.3.3.2** The capital-readability layer may identify whether a matter is understandable to capital readers in terms of evidence basis, public-good value, technical status, governance, public authority dependency, legal pathway, procurement dependency, cost and revenue assumptions, lifecycle obligations, risk allocation, insurance-readiness, public finance relevance, donor relevance, safeguards, data and cyber conditions, SPV-readiness, and handoff limits. **9.3.3.3** Capital-readability shall not mean capital commitment, investment interest, financeability, bankability, securities suitability, lender readiness, transaction readiness, or capital availability. **9.3.3.4** The capital-readability layer shall state unresolved issues and prohibited inferences. **9.3.3.5** The governing rule shall be: **Capital-readability in an AEP Passport pathway means the matter can be read, not financed.** *** ### 9.3.4 Insurance-Readiness Layer **9.3.4.1** The AEP Passport candidate pathway may include an insurance-readiness layer. **9.3.4.2** The insurance-readiness layer may identify exposure questions, hazard questions, vulnerability questions, loss questions, resilience controls, cyber conditions, infrastructure conditions, operating responsibility, data and model dependencies, insurance questions, reinsurance questions, public authority insurance interfaces, risk-transfer questions, disaster-risk finance questions, and protection-gap issues. **9.3.4.3** Insurance-readiness shall not imply insurance approval, underwriting, coverage availability, premium indication, reinsurance support, guarantee approval, insurability, insurance advice, or insurance placement. **9.3.4.4** Insurance-readiness records shall be confidentiality-classified and competition-compliant where needed. **9.3.4.5** The governing rule shall be: **The AEP Passport insurance-readiness layer identifies risk-transfer questions, not risk-transfer approval.** *** ### 9.3.5 Public Finance Relevance Layer **9.3.5.1** The AEP Passport candidate pathway may include a public finance relevance layer. **9.3.5.2** The public finance relevance layer may identify potential relevance to public investment, public grants, public guarantees, subsidies, concessional finance, resilience finance, disaster-risk finance, climate finance, infrastructure finance, public authority funding, budget processes, public-private interface, and public-good value. **9.3.5.3** Public finance relevance shall not imply public finance allocation, funding approval, budget approval, public guarantee, grant award, subsidy approval, procurement status, government endorsement, official position, or public authority approval. **9.3.5.4** The public finance relevance layer shall be public authority-sensitive, claims-limited, and no-allocation by default. **9.3.5.5** The governing rule shall be: **The AEP Passport public finance layer may identify relevance to public finance; it shall not allocate public finance.** *** ### 9.3.6 Donor and Philanthropic Relevance Layer **9.3.6.1** The AEP Passport candidate pathway may include a donor and philanthropic relevance layer. **9.3.6.2** The layer may identify mission fit, donor relevance, philanthropic relevance, foundation relevance, CSR relevance, humanitarian relevance, development relevance, climate relevance, resilience relevance, disaster-risk relevance, public-good value, capacity-building relevance, community-support relevance, evidence needs, reporting needs, and safeguard expectations. **9.3.6.3** Donor and philanthropic relevance shall not imply donor commitment, philanthropic commitment, grant approval, pledge, award, allocation, funding pipeline, development assistance commitment, sponsorship, or endorsement. **9.3.6.4** Donor and philanthropic layer materials shall be public-safe and claims-limited where released. **9.3.6.5** The governing rule shall be: **The AEP Passport donor and philanthropic layer maps possible fit, not funding.** *** ### 9.3.7 Diligence-Gap Layer **9.3.7.1** The AEP Passport candidate pathway may include a diligence-gap layer. **9.3.7.2** The diligence-gap layer may identify unresolved issues in evidence, technical readiness, data, cyber, public authority status, legal pathway, procurement, governance, revenue and cost assumptions, lifecycle obligations, risk allocation, insurance, public finance, donor relevance, safeguards, community protocols, Indigenous protocols where applicable, environmental and social conditions, SPV-readiness, National Consortium Company interface, Nexus Rail routing, Docket status, and handoff conditions. **9.3.7.3** A diligence-gap layer shall not be treated as diligence completion, legal clearance, financial clearance, insurance clearance, donor approval, public finance approval, procurement clearance, safeguard clearance, certification, Passport issuance, project approval, or execution readiness. **9.3.7.4** The layer shall identify which gaps are blocking, restricting, deferring, Docketing, or correcting the candidate pathway. **9.3.7.5** The governing rule shall be: **The AEP Passport diligence-gap layer protects the Passport pathway by recording what remains unresolved.** *** ### 9.3.8 Project SPV-Readiness Layer **9.3.8.1** The AEP Passport candidate pathway may include a Project SPV-readiness layer. **9.3.8.2** The Project SPV-readiness layer may identify legal structure questions, governance questions, public authority approvals, procurement requirements, permits, licences, capitalization questions, revenue and cost questions, contracting questions, data rights, land or asset rights, provider-neutrality requirements, insurance questions, donor relevance, public finance relevance, safeguards, consent boundaries, lifecycle obligations, operator responsibility, National Consortium Company interface, and handoff conditions. **9.3.8.3** SPV-readiness shall not imply SPV approval, SPV formation, project approval, financeability, bankability, insurability, procurement readiness, provider selection, public authority approval, consent, or execution authority. **9.3.8.4** The SPV-readiness layer shall be conflict-reviewed where future enterprise actors may benefit from Passport visibility. **9.3.8.5** The governing rule shall be: **The AEP Passport SPV-readiness layer records what a future SPV process would require; it shall not authorize the SPV.** *** ### 9.3.9 Handoff Conditions Layer **9.3.9.1** The AEP Passport candidate pathway may include a handoff conditions layer. **9.3.9.2** The handoff conditions layer may identify possible receiving pathways, including National Council, National Leadership Council, Helix Councils, National Working Groups, GCRI evidence pathways, GRF claims and public-safe reporting pathways, GRA finance-readiness pathways, Nexus Rail pathways, National Consortium Company interface, Project SPV pathway, public authority pathway, donor pathway, public finance pathway, insurance pathway, safeguard pathway, or lawful enterprise pathway. **9.3.9.3** Handoff conditions shall include no-reliance status, confidentiality class, public authority status, finance-readiness status, insurance-readiness status, donor relevance, public finance relevance, safeguard conditions, unresolved gaps, conflicts, claims limits, and correction pathway. **9.3.9.4** Handoff conditions shall not imply handoff completion, receiving-actor approval, finance approval, insurance approval, donor approval, public finance allocation, procurement status, certification, public authority approval, SPV approval, project approval, consent, Company action, or execution authority. **9.3.9.5** The governing rule shall be: **The AEP Passport handoff layer may prepare controlled transfer of questions; it shall not transfer authority.** *** ### 9.3.10 Finance-Readiness Correction Layer **9.3.10.1** The AEP Passport candidate pathway may include a finance-readiness correction layer. **9.3.10.2** The correction layer shall record any correction affecting finance-readiness, capital-readability, insurance-readiness, donor relevance, public finance relevance, diligence gaps, SPV-readiness, National Consortium Company interface, Rail routeability, Docket status, handoff conditions, public authority dependency, safeguard dependency, or claims limits. **9.3.10.3** Correction may include narrowed language, revised status, public-safe clarification, controlled clarification, publication reclassification, participant notice, Docket entry, Rail restriction, Passport pathway restriction, handoff restriction, withdrawal, supersession, archive, or renewal. **9.3.10.4** Correction shall occur before Passport-related materials are used to imply financeability, bankability, insurability, donor support, public finance allocation, certification, Nexus-ready status, project approval, or execution readiness. **9.3.10.5** The governing rule shall be: **AEP Passport finance-readiness remains trustworthy only if correction travels inside the Passport record.** *** ## 9.4 Project SPV-Readiness ### 9.4.1 Project SPV as Separate Lawful Project Vehicle **9.4.1.1** A **Project SPV** shall be a separate lawful project vehicle, if and when formed, governed, capitalized, contracted, approved, insured, procured, and operated through its own competent legal, corporate, public authority, finance, insurance, procurement, safeguard, consent, and execution processes. **9.4.1.2** A Project SPV shall be separate from the National Investors Council, National Council, National Leadership Council, Helix Councils, National Working Groups, National Nexus Consortium public-good body, GCRI, GRF, GRA, Regional Nexus Consortiums, Global Nexus Consortium, sponsors, providers, capital readers, insurers, donors, and public authorities unless a lawful record expressly defines a relationship. **9.4.1.3** The National Investors Council may identify SPV-readiness questions but shall not create, own, govern, direct, approve, finance, insure, procure for, contract for, operate, or authorize any Project SPV. **9.4.1.4** Any SPV relationship to Nexus instruments, AEP Passports, Nexus Rails, National Models, Docket records, or handoff notes shall be governed by recorded status and lawful authority, not implication. **9.4.1.5** The governing rule shall be: **A Project SPV exists only through separate lawful formation and authority, never through Investor Council readiness discussion.** *** ### 9.4.2 Project SPV-Readiness Defined **9.4.2.1** Project SPV-readiness shall mean the recorded identification of questions, dependencies, conditions, gaps, restrictions, and lawful pathways that may need to be addressed before a Project SPV could be considered by competent actors. **9.4.2.2** SPV-readiness may include governance questions, capitalization questions, revenue and cost questions, contracting questions, public authority dependency questions, insurance questions, procurement questions, safeguard questions, legal pathway questions, data rights questions, land or asset rights questions, provider-neutrality questions, operating responsibility questions, lifecycle obligations, community and Indigenous protocol conditions where applicable, environmental and social conditions, handoff requirements, and correction needs. **9.4.2.3** SPV-readiness shall not mean that an SPV should be formed, is authorized, is approved, is financeable, is bankable, is insurable, has public authority support, has donor support, has public finance support, has procurement status, has consent, or is ready for execution. **9.4.2.4** SPV-readiness shall be no-reliance, claims-limited, conflict-reviewed, safeguard-aware, and correctionable. **9.4.2.5** The governing rule shall be: **Project SPV-readiness defines what must be examined before an SPV can exist, not that the SPV may exist.** *** ### 9.4.3 SPV-Readiness Is Not SPV Approval **9.4.3.1** SPV-readiness shall not be SPV approval. **9.4.3.2** No SPV-readiness note, National Model layer, AEP Passport finance-layer input, Nexus Rail candidate record, Docket item, Nexus Universe discussion, capital-reader room output, insurance-readiness room output, public finance relevance room output, donor relevance room output, handoff condition, or Council recommendation shall be represented as SPV approval. **9.4.3.3** SPV approval, if applicable, shall require separate lawful records, including corporate approval, governance approval, legal review, public authority approval where required, finance approval where required, insurance approval where required, procurement approval where required, safeguard approval where required, consent records where required, and execution authority. **9.4.3.4** Any statement implying SPV approval from SPV-readiness shall be corrected immediately. **9.4.3.5** The governing rule shall be: **SPV-readiness asks whether the pathway is conceivable; SPV approval decides only through separate lawful authority.** *** ### 9.4.4 SPV Governance Questions **9.4.4.1** SPV-readiness review may identify governance questions relevant to any potential Project SPV. **9.4.4.2** Governance questions may include who would own the SPV, who would control it, who would appoint directors or managers, what fiduciary duties would apply, how conflicts would be handled, how public-good conditions would travel, how National Council records would be referenced, how public authority dependencies would be respected, how safeguards would be governed, how data would be governed, how provider neutrality would be preserved, how reporting would occur, how correction would occur, and how exit, decommissioning, or archive would be handled. **9.4.4.3** The Council shall not answer such governance questions as a final authority and shall not appoint, approve, control, or govern the SPV. **9.4.4.4** Governance questions shall be routed to competent legal, corporate, public authority, finance, safeguard, Company, SPV, or other lawful pathways where relevant. **9.4.4.5** The governing rule shall be: **The Investors Council may identify SPV governance questions; it shall not become SPV governance.** *** ### 9.4.5 SPV Capitalization Questions **9.4.5.1** SPV-readiness review may identify capitalization questions relevant to a potential Project SPV. **9.4.5.2** Capitalization questions may include what capital may be required, what sources may be lawful, what public finance dependencies may exist, what donor or philanthropic relevance may exist, what debt or equity questions may arise, what guarantees may be needed, what insurance dependencies may affect capital, what operating reserves may be required, what lifecycle funding may be needed, and what regulated-perimeter issues may apply. **9.4.5.3** Capitalization questions shall not be capital solicitation, investment advice, finance approval, public finance approval, donor commitment, guarantee approval, securities offering, lending approval, valuation, term-sheet formation, or transaction structuring. **9.4.5.4** Any capitalization-related discussion shall be no-reliance, non-advisory, non-soliciting, non-transactional, and regulated-perimeter controlled. **9.4.5.5** The governing rule shall be: **The Council may identify what capitalization would need to address; it shall not capitalize the SPV.** *** ### 9.4.6 SPV Revenue and Cost Questions **9.4.6.1** SPV-readiness review may identify revenue and cost questions relevant to a potential Project SPV. **9.4.6.2** Revenue and cost questions may include capital expenditure, operating expenditure, lifecycle cost, maintenance cost, energy cost, data cost, cyber cost, insurance cost, staffing cost, replacement cost, decommissioning cost, tariff or fee assumptions, public payment assumptions, grant assumptions, subsidy assumptions, donor support assumptions, public finance assumptions, and contingent liability assumptions. **9.4.6.3** The Council shall distinguish recorded figures, estimates, assumptions, provider-supplied figures, sponsor-supplied figures, public authority figures, audited figures, unaudited figures, modelled scenarios, and unknown values. **9.4.6.4** Revenue and cost questions shall not be treated as financial forecasts, valuation, budget approval, financeability, bankability, tax advice, accounting advice, public finance approval, donor approval, or transaction support. **9.4.6.5** The governing rule shall be: **SPV revenue and cost questions make assumptions visible; they do not validate the economics.** *** ### 9.4.7 SPV Contracting Questions **9.4.7.1** SPV-readiness review may identify contracting questions relevant to a potential Project SPV. **9.4.7.2** Contracting questions may include public authority contracts, provider contracts, operator contracts, maintenance contracts, data agreements, software licences, hardware leases or purchases, insurance contracts, financing agreements, grant agreements, guarantee agreements, land or asset agreements, community benefit agreements, Indigenous protocol agreements where applicable, procurement documents, service agreements, performance obligations, warranties, liabilities, termination rights, and decommissioning obligations. **9.4.7.3** The Council shall not draft, negotiate, approve, execute, interpret as legal advice, or bind any contracting arrangement through SPV-readiness review. **9.4.7.4** Contracting questions shall be routed to competent legal, procurement, public authority, Company, SPV, provider, finance, insurance, donor, safeguard, or operational pathways where required. **9.4.7.5** The governing rule shall be: **The Council may identify contract dependencies; it shall not create contracts.** *** ### 9.4.8 SPV Public Authority Dependency Questions **9.4.8.1** SPV-readiness review may identify public authority dependency questions relevant to a potential Project SPV. **9.4.8.2** Such questions may include whether public authority approval, procurement, permits, licences, public finance, public guarantees, public utility permission, public data authorization, land access, environmental approval, emergency-management coordination, public health authority involvement, infrastructure authority involvement, municipal approval, national approval, or regulatory approval may be required. **9.4.8.3** Public authority dependency questions shall not imply public authority approval, government endorsement, public finance allocation, procurement status, permit, licence, policy adoption, official position, public warning, emergency command, or public data authorization. **9.4.8.4** Public authority dependency questions shall be capacity-classified and routed to competent public authority pathways where applicable. **9.4.8.5** The governing rule shall be: **The Council may identify public authority dependencies for a potential SPV; only public authorities can resolve them.** *** ### 9.4.9 SPV Insurance Questions **9.4.9.1** SPV-readiness review may identify insurance questions relevant to a potential Project SPV. **9.4.9.2** Insurance questions may include required coverage, insurable interest, asset coverage, liability coverage, cyber coverage, professional liability, construction risk, operational risk, business interruption, climate and disaster exposure, public authority insurance requirements, lender insurance requirements, donor insurance requirements, provider insurance obligations, reinsurance relevance, risk-transfer conditions, exclusions, and claims pathways. **9.4.9.3** SPV insurance questions shall not be treated as insurance advice, coverage approval, underwriting, premium indication, insurability determination, reinsurance support, guarantee approval, or insurance placement. **9.4.9.4** Insurance questions shall be routed to competent insurance pathways where needed. **9.4.9.5** The governing rule shall be: **SPV insurance questions identify what insurance may need to examine; they do not insure the SPV.** *** ### 9.4.10 SPV Procurement Questions **9.4.10.1** SPV-readiness review may identify procurement questions relevant to a potential Project SPV. **9.4.10.2** Procurement questions may include public procurement requirements, competitive process requirements, provider-neutral capability specifications, technical specification requirements, bid integrity, anti-corruption controls, conflict controls, contract award dependencies, vendor eligibility, local content requirements, timing, and procurement authority. **9.4.10.3** SPV procurement questions shall not create procurement status, prequalification, preferred-provider status, tender status, contract award, vendor approval, purchasing approval, provider validation, or procurement advice. **9.4.10.4** Provider-linked materials shall be source-labelled, conflict-reviewed, and separated from procurement conclusions. **9.4.10.5** The governing rule shall be: **SPV procurement questions keep provider pathways lawful; they do not select providers.** *** ### 9.4.11 SPV Safeguard Questions **9.4.11.1** SPV-readiness review shall identify safeguard questions relevant to a potential Project SPV. **9.4.11.2** Safeguard questions may include privacy, cybersecurity, sovereign data, public authority sensitivity, finance sensitivity, insurance sensitivity, donor sensitivity, commercial sensitivity, provider sensitivity, sponsor sensitivity, community sensitivity, Indigenous or protected knowledge where applicable, accessibility, environmental and social safeguards, biodiversity, health, infrastructure security, location sensitivity, consent boundaries, benefit-sharing, non-extractive engagement, public-safe reporting, and do-no-harm conditions. **9.4.11.3** SPV safeguard questions shall not constitute safeguard clearance, community consent, Indigenous consent, data authorization, publication authorization, environmental approval, social approval, project approval, finance approval, donor legitimacy, public finance approval, or execution authorization. **9.4.11.4** Safeguard questions shall travel with any SPV-readiness note, Rail record, Passport finance-layer input, Docket item, or handoff record. **9.4.11.5** The governing rule shall be: **A potential SPV is not readiness-safe unless safeguard questions travel before it.** *** ### 9.4.12 SPV Handoff Record Requirements **9.4.12.1** Any handoff toward a Project SPV pathway shall require a handoff record. **9.4.12.2** The handoff record shall identify source record, referring body, receiving pathway, purpose of handoff, SPV-readiness status, governance questions, capitalization questions, revenue and cost questions, contracting questions, public authority dependencies, insurance questions, procurement questions, safeguard questions, data and cyber conditions, community and Indigenous protocol conditions where applicable, environmental and social conditions, conflicts, claims limits, confidentiality class, no-reliance status, unresolved gaps, Docket status, Nexus Rail status, AEP Passport finance-layer status, National Consortium Company interface, and correction pathway. **9.4.12.3** The handoff record shall state that it is not SPV approval, project approval, finance approval, insurance approval, donor approval, public finance allocation, procurement status, provider selection, public authority approval, consent, certification, or execution authority. **9.4.12.4** The receiving actor shall be informed that separate lawful processes are required before any SPV formation, financing, insurance, procurement, contracting, public authority action, safeguard clearance, consent, or execution. **9.4.12.5** The governing rule shall be: **A Project SPV handoff record carries conditions into a future process; it does not create the future process.** *** ### 9.4.13 Correction of SPV-Readiness Overclaim **9.4.13.1** SPV-readiness overclaim shall be corrected wherever it appears. **9.4.13.2** SPV-readiness overclaim includes any claim or implication that a matter is SPV-approved, project-approved, financeable, bankable, insurable, procurement-ready, provider-selected, publicly approved, donor-backed, publicly financed, consented, certified, Nexus-ready, AEP Passport-approved, Rail-executed, or execution-ready because SPV-readiness was discussed, recorded, routed, presented, Docketed, or handed off. **9.4.13.3** Correction may include claim narrowing, public-safe clarification, controlled clarification, publication reclassification, role reclassification, conflict disclosure, safeguard correction, Docket entry, Rail restriction, Passport pathway correction, handoff restriction, withdrawal, supersession, archive, or suspension of participation. **9.4.13.4** Correction shall be urgent where SPV-readiness overclaim could create market reliance, capital expectation, public finance expectation, donor expectation, provider advantage, sponsor advantage, public authority confusion, community harm, or unauthorized project momentum. **9.4.13.5** The governing rule shall be: **SPV-readiness overclaim must be corrected before a question set becomes false project authority.** *** ## 9.5 National Consortium Company Finance Interface ### 9.5.1 National Consortium Company as Separate Enterprise-Stack Vehicle **9.5.1.1** A **National Consortium Company** shall be a separate enterprise-stack vehicle, where formed, capable of receiving lawful implementation-facing handoff only through competent records and applicable legal, corporate, finance, insurance, procurement, safeguard, public authority, and operational processes. **9.5.1.2** The National Consortium Company shall be separate from the National Investors Council, National Council, National Leadership Council, Helix Councils, National Working Groups, National Nexus Consortium public-good body, GCRI, GRF, GRA, Regional Nexus Consortiums, Global Nexus Consortium, public authorities, sponsors, providers, capital readers, insurers, donors, and Project SPVs unless a lawful instrument expressly provides a defined relationship. **9.5.1.3** The National Investors Council shall not create, own, govern, direct, finance, insure, procure for, approve, bind, operate, or authorize a National Consortium Company. **9.5.1.4** Company involvement shall not retroactively convert public-good readiness records into enterprise authority, project approval, finance approval, insurance approval, public finance allocation, donor commitment, procurement status, provider selection, consent, or execution authority. **9.5.1.5** The governing rule shall be: **The National Consortium Company may be a lawful receiving vehicle; it is not the National Investors Council and is not controlled by it.** *** ### 9.5.2 Finance-Interface Role **9.5.2.1** The National Investors Council may support a finance-interface role in relation to a National Consortium Company by identifying what finance-readiness, capital-readability, insurance-readiness, donor relevance, public finance relevance, diligence-gap, SPV-readiness, safeguard, public authority, and handoff conditions may need to be understood before any Company-facing process occurs. **9.5.2.2** The finance-interface role may include preparation of Company finance-interface notes, public authority dependency notes, procurement dependency notes, insurance-readiness notes, donor relevance notes, public finance relevance notes, Docket items, Nexus Rail finance-readiness notes, AEP Passport finance-layer inputs, and handoff-condition notes. **9.5.2.3** The finance-interface role shall not be Company finance, Company approval, Company mandate, Company governance, Company investment decision, Company insurance decision, Company procurement decision, Company project decision, or Company execution authority. **9.5.2.4** Any Company-facing output shall preserve no-reliance status, claims limits, safeguard conditions, public authority dependencies, unresolved gaps, conflicts, confidentiality class, and correction pathway. **9.5.2.5** The governing rule shall be: **The Council’s Company finance-interface role prepares disciplined questions for possible Company review; it does not act for the Company.** *** ### 9.5.3 Enterprise Handoff Awareness **9.5.3.1** The National Investors Council may support enterprise handoff awareness where a matter may later be routed toward a National Consortium Company, Project SPV, provider, operator, contractor, investor, insurer, donor, public finance actor, public authority, or other lawful enterprise or implementation pathway. **9.5.3.2** Enterprise handoff awareness may identify receiving-pathway readiness, public authority dependencies, finance-readiness dependencies, insurance-readiness dependencies, donor relevance, public finance relevance, procurement requirements, provider-neutrality conditions, safeguard dependencies, data conditions, legal conditions, conflict conditions, claims limits, and correction needs. **9.5.3.3** Enterprise handoff awareness shall not be handoff approval, Company approval, Project SPV approval, project approval, finance approval, insurance approval, public finance approval, donor approval, procurement status, provider selection, public authority approval, consent, certification, or execution authority. **9.5.3.4** Enterprise handoff awareness shall remain public-good stack output unless separately and lawfully accepted by a competent enterprise-stack actor. **9.5.3.5** The governing rule shall be: **Enterprise handoff awareness helps prevent unsafe handoff; it does not conduct the handoff.** *** ### 9.5.4 No Control of National Consortium Company by Investors Council **9.5.4.1** The National Investors Council shall have no control over any National Consortium Company. **9.5.4.2** The Council shall not appoint Company directors, officers, managers, advisers, investors, providers, operators, contractors, auditors, insurers, lenders, donors, or public finance actors. **9.5.4.3** The Council shall not direct Company strategy, approve Company projects, approve Company contracts, approve Company financing, approve Company insurance, approve Company procurement, approve Company budgets, approve Company operations, or bind Company conduct. **9.5.4.4** Company-linked participants in Council work shall be role-classified, conflict-reviewed, access-controlled, claims-limited, and restricted where Company interests could capture public-good finance-readiness records. **9.5.4.5** The governing rule shall be: **The Investors Council may inform possible Company-facing readiness; it shall never control the Company.** *** ### 9.5.5 Handoff Candidate Identification **9.5.5.1** The National Investors Council may identify a matter as a handoff candidate for possible future Company-facing or enterprise-facing review. **9.5.5.2** Handoff candidate identification may occur where a matter has sufficient public-good record basis, finance-readiness review, public authority dependency mapping, safeguard classification, insurance-readiness review, donor relevance mapping, public finance relevance mapping, procurement dependency identification, SPV-readiness review, Nexus Rail routeability, AEP Passport finance-layer input, or Docket treatment to justify controlled consideration by a competent receiving pathway. **9.5.5.3** Handoff candidate identification shall not imply handoff approval, Company acceptance, Company commitment, project approval, finance approval, insurance approval, donor commitment, public finance allocation, procurement status, provider selection, public authority approval, consent, certification, or execution authority. **9.5.5.4** Handoff candidates shall be labelled as candidate, deferred, restricted, blocked, Docketed, corrected, superseded, archived, or renewed according to the competent record. **9.5.5.5** The governing rule shall be: **A handoff candidate is a matter that may need controlled next review, not a matter already accepted for execution.** *** ### 9.5.6 Handoff Limits **9.5.6.1** Any handoff involving the National Investors Council shall be subject to express limits. **9.5.6.2** Handoff limits shall state what the handoff does and does not mean, including that it does not create finance approval, insurance approval, donor commitment, public finance allocation, procurement status, provider selection, public authority approval, consent, certification, Company approval, SPV approval, project approval, or execution authority. **9.5.6.3** Handoff limits shall include no-reliance status, confidentiality class, public authority dependency, finance-readiness dependency, insurance-readiness dependency, donor relevance, public finance relevance, safeguard conditions, unresolved gaps, conflicts, claims limits, receiving-pathway limits, and correction pathway. **9.5.6.4** A receiving actor shall not remove handoff limits when using the handoff material externally. **9.5.6.5** The governing rule shall be: **Handoff limits travel with the handoff or the handoff is unsafe.** *** ### 9.5.7 Conflict Review **9.5.7.1** The National Investors Council shall conduct conflict review for Company finance-interface and handoff-related matters. **9.5.7.2** Conflict review shall identify whether any participant, sponsor, provider, investor, insurer, donor, public finance actor, public authority participant, Company-linked person, Project SPV pathway actor, adviser, consultant, expert, or institutional representative may benefit from Company handoff, SPV-readiness, project visibility, National Model inclusion, Nexus Universe presentation, AEP Passport candidacy, Nexus Rail routing, Docket treatment, or capital-reader room exposure. **9.5.7.3** Conflict review may result in disclosure, recusal, role restriction, access restriction, room exclusion, independent review, claims limitation, handoff restriction, Docket entry, suspension, or correction. **9.5.7.4** Conflict review shall not be waived for convenience, sponsor pressure, provider pressure, capital-reader interest, donor interest, public finance relevance, Nexus Universe timing, or project momentum. **9.5.7.5** The governing rule shall be: **No Company-facing or SPV-facing readiness record is safe unless conflicts are visible and managed before handoff.** *** ### 9.5.8 Claims Review **9.5.8.1** The National Investors Council shall conduct claims review for any Company finance-interface, handoff candidate, Project SPV-readiness note, Nexus Rail finance-readiness note, AEP Passport finance-layer input, National Model finance layer, Nexus Universe material, or public-safe output involving potential enterprise handoff. **9.5.8.2** Claims review shall ensure that no language implies Company approval, Company mandate, SPV approval, project approval, financeability, bankability, insurability, investment interest, insurance approval, donor commitment, public finance allocation, guarantee support, procurement status, provider selection, public authority approval, consent, certification, Nexus-ready status, Rail execution, AEP Passport issuance, or execution readiness unless separately and lawfully recorded. **9.5.8.3** Claims review shall identify permitted language, prohibited language, required disclaimers, publication class, name-use limits, sponsor-use limits, provider-use limits, public authority-use limits, donor-use limits, and correction pathway. **9.5.8.4** External-facing claims shall be narrower than internal readiness records where public reliance risk exists. **9.5.8.5** The governing rule shall be: **Claims review is the barrier between enterprise handoff awareness and enterprise overclaim.** *** ### 9.5.9 Enterprise-Stack Boundary **9.5.9.1** The National Investors Council shall preserve the boundary between the public-good stack and the enterprise stack. **9.5.9.2** The public-good stack may produce evidence records, finance-readiness records, public-safe reporting inputs, National Model layers, Nexus Universe outputs, AEP Passport candidate inputs, Nexus Rail routeability notes, Docket items, safeguard conditions, and handoff-condition notes. The enterprise stack may conduct lawful implementation, finance, insurance, procurement, contracting, operations, ownership, delivery, or execution only through competent actors and separate records. **9.5.9.3** The Council shall not allow enterprise actors to use public-good readiness records as sales materials, transaction documents, procurement materials, provider validations, finance approvals, public authority approvals, consent records, or execution authorizations. **9.5.9.4** The enterprise-stack boundary shall be protected through role classification, conflict review, no-reliance language, claims limits, safeguard carry-forward, public authority dependency notation, and correctionability. **9.5.9.5** The governing rule shall be: **Public-good readiness may inform enterprise action only when the boundary remains visible, recorded, and enforceable.** *** ### 9.5.10 Correction of Company Finance-Interface Overclaim **9.5.10.1** Company finance-interface overclaim shall be corrected wherever it appears. **9.5.10.2** Company finance-interface overclaim includes any statement or implication that a National Consortium Company has approved, accepted, financed, insured, procured, endorsed, authorized, selected providers for, committed to, or executed a matter because the National Investors Council reviewed finance-readiness, identified a handoff candidate, prepared a Company interface note, routed a matter through Nexus Rails, contributed to an AEP Passport finance-layer, recorded a Docket item, or supported Nexus Universe visibility. **9.5.10.3** Correction may include claim narrowing, public-safe clarification, controlled clarification, Company notice, participant notice, sponsor notice, provider notice, capital-reader notice, donor-facing correction, public finance-facing correction, publication reclassification, handoff restriction, Docket entry, Rail restriction, AEP Passport pathway correction, withdrawal, supersession, archive, or suspension of participation. **9.5.10.4** Correction shall be urgent where Company finance-interface overclaim may create market reliance, investor expectation, insurer expectation, donor expectation, public finance expectation, provider advantage, sponsor advantage, public authority confusion, community harm, or execution momentum. **9.5.10.5** The final operating rule of this Part shall be: **A Company may receive lawful handoff only through competent records; no Investors Council record shall be allowed to masquerade as Company authority, finance, insurance, procurement, project approval, or execution.** ### Summary Handoff is a controlled transfer of questions, conditions, limits, and dependencies. It does not transfer approval, finance, insurance, donor commitment, public finance allocation, procurement status, Company authority, SPV authority, or execution authority. ### Next steps 1. Continue to [X. MOBILIZATION](/organization/cooperation/consortiums/gateways/national-councils/investors/x.-mobilization.md). 2. Review [VIII. ROOMS](/organization/cooperation/consortiums/gateways/national-councils/investors/viii.-rooms.md) for room discipline before handoff. 3. Revisit [VI. PROCEDURE](/organization/cooperation/consortiums/gateways/national-councils/investors/vi.-procedure.md) for operational controls. --- # 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/cooperation/consortiums/gateways/national-councils/investors/ix.-handoff.md?ask= ``` 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.