# XVII. HANDOFF ### 17. National Consortium Companies and Project SPV Federation Interface ### 17.1 Public-Good Stack to Enterprise Stack Handoff #### 17.1.1 Public-Good Record Formation **17.1.1.1** **Public-Good Record Formation** shall mean the controlled creation, classification, versioning, review, limitation, correction, renewal, and archive of records generated within the public-good stack before any possible interface with an enterprise-stack actor, National Consortium Company, Project SPV, provider, host, operator, public authority, capital reader, insurer, donor, development actor, public finance actor, procurement body, community process, Indigenous governance process where applicable, or other lawful downstream recipient. **17.1.1.2** Public-good records may include National Model records, Regional Cluster Program Plan records, Nexus Universe outputs, evidence records, method records, observability records, ontology records, public-good software records, public authority learning records, finance-readiness records, safeguard records, provider-neutral capability maps, AEP Passport candidate inputs, Proof Receipt inputs where authorized, Nexus Rail routeability inputs, Docket items, Grid inputs, public-safe reports, correction records, and handoff-readiness records. **17.1.1.3** Public-good record formation shall be non-executing. A record produced by a National Nexus Consortium, Regional Headquarters Consortium, Global Nexus Consortium, Central Nexus Bureau, Nexus Universe pathway, GCRI-aligned technical pathway, GRF-aligned legitimacy or public-safe reporting pathway, GRA-aligned finance-readiness pathway, National Council, Helix Council, Working Group, or Nexus Competence Cell shall not by itself constitute execution, approval, procurement, finance, insurance, certification, public authority action, community consent, Indigenous consent, project authorization, or enterprise commitment. **17.1.1.4** Each public-good record intended for possible enterprise-stack interface shall identify, as applicable, source, version, record owner, record class, evidence basis, limitations, unresolved dependencies, public authority dependencies, finance and insurance dependencies, procurement dependencies, provider-neutrality conditions, sponsor-boundary conditions, safeguard conditions, protected knowledge restrictions, data and cyber restrictions, publication limits, permitted claims, prohibited claims, correction rights, withdrawal rights, supersession conditions, archive status, and express non-execution language. **17.1.1.5** Public-good record formation shall preserve the separation between readiness and authority. A record may show that a matter is ready for further review, learning, diligence, translation, routing, public-safe discussion, or handoff consideration, but shall not create the downstream decision, approval, contract, financing, insurance, procurement, permit, consent, deployment, or operation that may later be required. **17.1.1.6** Public-good records shall not be repackaged into investment materials, procurement materials, provider marketing, public authority decision records, certification materials, consent materials, project approval materials, or execution instructions unless a competent downstream actor separately and lawfully creates such materials outside the public-good stack and preserves all applicable limitations. **17.1.1.7** Public-good record formation shall be correctionable. If a record is inaccurate, incomplete, unsafe, outdated, overclaimed, misclassified, stripped of limitations, exposed beyond permission, or used as authority, financeability, certification, consent, procurement status, provider validation, project approval, or execution, the record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.2 Readiness and Dependency Mapping **17.1.2.1** **Readiness and Dependency Mapping** shall mean the structured identification of conditions, gaps, dependencies, assumptions, unresolved questions, evidence needs, safeguards, public authority requirements, finance-readiness requirements, insurance-readiness requirements, procurement conditions, technical conditions, provider-neutral capability conditions, data and cyber conditions, community conditions, Indigenous protocol conditions where applicable, environmental and social conditions, and lawful handoff conditions relevant to a possible enterprise-stack pathway. **17.1.2.2** Readiness mapping shall not be approval mapping. A mapped dependency shall not be treated as satisfied. A readiness note shall not be treated as maturity. A routeability note shall not be treated as authorization. A handoff-ready note shall not be treated as execution-ready status. **17.1.2.3** Dependency mapping shall include, as applicable: 1. public authority dependencies; 2. finance, insurance, donor, development, and public finance dependencies; 3. procurement dependencies; 4. provider, operator, host, and enterprise capacity dependencies; 5. technical and evidence dependencies; 6. data, privacy, cybersecurity, compute, and infrastructure dependencies; 7. environmental and social dependencies; 8. community and Indigenous dependencies where applicable; 9. protected knowledge restrictions; 10. accessibility and rights-related dependencies; 11. Nexus Universe, AEP Passport, Nexus Rail, Docket, and Grid dependencies; 12. correction, renewal, and archive dependencies. **17.1.2.4** Readiness and Dependency Mapping shall preserve unresolved issues. Unresolved dependencies shall not be removed, softened, or converted into strengths for narrative, sponsor, provider, public authority, finance, media, procurement, or handoff convenience. **17.1.2.5** Readiness mapping may support capital-readability, public authority learning, provider-neutral capability review, safeguard review, National Consortium Company interface, Project SPV-readiness, AEP Passport candidate preparation, Nexus Rail routeability, Docket classification, Grid input, public-safe reporting, and lawful handoff consideration, but shall not create the downstream outcome. **17.1.2.6** Readiness and Dependency Mapping shall travel with the record. A downstream recipient shall receive the dependencies together with the record and shall not be permitted to rely on the record as complete, approved, financeable, certified, consented, procured, or executable merely because it has been mapped. **17.1.2.7** Readiness and Dependency Mapping records shall be correctionable. If a dependency is omitted, understated, overstated, misclassified, prematurely treated as satisfied, or used to imply approval or execution, the mapping record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.3 Safeguard Conditions **17.1.3.1** **Safeguard Conditions** shall mean the community, Indigenous where applicable, rights, accessibility, protected knowledge, environmental, social, cultural, place-based, humanitarian, health, data, cyber, public-safe reporting, and consent-boundary conditions that must remain attached to a public-good record before, during, and after any enterprise-stack interface or handoff. **17.1.3.2** Safeguard Conditions shall be conditions, not approvals. A safeguard note, community-risk record, Indigenous protocol note, protected knowledge caution, environmental and social safeguard note, accessibility note, diaspora input, youth input, or place-based legitimacy note shall not constitute consent, consultation completion, accommodation completion, FPIC satisfaction where applicable, social license, protected knowledge authorization, land access, site approval, cultural approval, environmental approval, rights-holder approval, local authorization, project approval, or execution authority. **17.1.3.3** Safeguard Conditions shall include, as applicable: 1. community-risk conditions; 2. Indigenous protocol conditions where applicable; 3. protected knowledge restrictions; 4. data sovereignty and privacy conditions; 5. accessibility and inclusion conditions; 6. youth and future-generation considerations; 7. diaspora contribution limits; 8. environmental and social safeguards; 9. humanitarian and health-sensitive conditions; 10. infrastructure and security sensitivity conditions; 11. public-safe reporting restrictions; 12. lawful consent-boundary language; 13. downstream handoff restrictions. **17.1.3.4** Safeguard Conditions shall travel with the record. They shall not be stripped, summarized away, buried, weakened, or reclassified as optional when a record moves from the public-good stack to a National Consortium Company, Project SPV, provider, host, operator, investor, insurer, donor, development actor, public finance actor, public authority, procurement body, or other downstream recipient. **17.1.3.5** Where Indigenous peoples, Tribal actors, traditional authorities, protected knowledge holders, rights-holders, or community governance bodies may be affected, heightened boundary discipline shall apply. Participation, attendance, contribution, public-safe listing, Nexus Universe visibility, or safeguard-room presence shall not imply consent or authority to proceed. **17.1.3.6** A handoff record shall identify which Safeguard Conditions remain unresolved, which are information-only, which require downstream review, which require lawful process, which restrict publication, and which prohibit reliance until separately addressed. **17.1.3.7** Safeguard Conditions shall be correctionable. If safeguards are incomplete, tokenistic, extractive, mislocalized, misclassified, publicly unsafe, stripped from a handoff record, used as consent, or used to imply approval or execution, the safeguard record and any affected handoff record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.4 Public Authority Dependencies **17.1.4.1** **Public Authority Dependencies** shall mean the laws, approvals, permissions, public-sector decisions, policy processes, regulatory processes, procurement processes, public finance processes, data authorizations, emergency management processes, infrastructure approvals, environmental approvals, public health requirements, municipal or subnational processes, Indigenous or Tribal public-governance processes where applicable, and other public-law conditions that may be relevant to a possible enterprise-stack pathway. **17.1.4.2** Public Authority Dependencies shall not be satisfied by Nexus participation. Public authority attendance, learning, room participation, dashboard review, Nexus Universe visibility, contribution to a dependency note, Government Portfolio showcase participation, AEP Passport public authority layer discussion, Nexus Rail dependency routing, Docket input, or Grid input shall not create public authority approval, government endorsement, regulatory comfort, policy adoption, procurement status, public finance allocation, public warning, data authorization, infrastructure approval, environmental approval, project authorization, or execution authority. **17.1.4.3** A public-good record prepared for handoff shall identify, where applicable: 1. public authority bodies potentially relevant; 2. role and capacity of any public authority participant; 3. approvals or decisions not yet obtained; 4. procurement dependencies; 5. public finance dependencies; 6. regulatory dependencies; 7. data and cyber authorization dependencies; 8. environmental, land, infrastructure, health, safety, or emergency-management dependencies; 9. public authority-sensitive information restrictions; 10. public-safe reporting limits; 11. prohibited claims concerning public authority status. **17.1.4.4** Public Authority Dependencies shall be routed to competent public authority pathways only where lawful and appropriate. The public-good stack may assist learning, dependency mapping, record preparation, public-safe reporting, and handoff documentation, but shall not act for the public authority. **17.1.4.5** A National Consortium Company, Project SPV, provider, host, operator, investor, insurer, donor, development actor, or public finance actor receiving a public-good record shall remain responsible for obtaining any required public authority approvals through lawful processes. **17.1.4.6** No public-good stack body shall represent that a public authority dependency is resolved unless a competent public authority has separately and lawfully recorded the relevant decision and the claim is permitted by the applicable record. **17.1.4.7** Public Authority Dependency records shall be correctionable. If public authority participation is overclaimed, approval is implied, procurement status is suggested, public finance allocation is implied, regulatory comfort is suggested, or public authority dependency language is misused to support execution, the record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.5 Finance-Readiness Dependencies **17.1.5.1** **Finance-Readiness Dependencies** shall mean the finance, insurance, donor, development, public finance, risk-transfer, diligence, capital-readability, bankability, insurability, Project SPV-readiness, contractual, revenue, cost, guarantee, credit, risk allocation, governance, safeguards, and lawful recipient-capacity conditions that may be relevant before a downstream enterprise-stack actor can lawfully pursue finance, insurance, donor support, development finance, public finance, or transaction execution. **17.1.5.2** Finance-readiness shall not be finance. A finance-readiness note, capital-reader room output, insurance-readiness question, donor relevance note, development-readiness note, public finance relevance note, diligence-gap map, SPV-readiness input, AEP Passport finance-layer input, Nexus Rail finance-readiness input, Docket finance item, Grid finance input, or handoff-readiness note shall not constitute investment advice, financial advice, insurance advice, underwriting, guarantee, donor approval, development finance approval, public finance allocation, rating, valuation, term sheet, offering, solicitation, transaction arrangement, financeability, bankability, insurability, or capital commitment. **17.1.5.3** Finance-Readiness Dependencies shall include, as applicable: 1. public authority approvals and procurement conditions; 2. technical evidence and operational readiness; 3. safeguard and consent-boundary conditions; 4. environmental and social conditions; 5. provider, host, operator, and enterprise capacity conditions; 6. National Consortium Company or Project SPV governance conditions; 7. contractual and revenue model conditions; 8. insurance and risk-transfer conditions; 9. donor, development, and public finance conditions; 10. data, cyber, infrastructure, and security conditions; 11. legal, tax, accounting, and diligence conditions; 12. correction, withdrawal, and supersession conditions. **17.1.5.4** Finance-Readiness Dependencies shall be framed under no-reliance discipline. No recipient shall rely on public-good stack finance-readiness records as a substitute for independent legal, financial, insurance, tax, investment, accounting, technical, environmental, social, procurement, public authority, community, Indigenous where applicable, or project diligence. **17.1.5.5** A National Consortium Company or Project SPV may receive finance-readiness records only as inputs for separate lawful diligence and decision-making. Receipt shall not imply that finance has been approved or that the recipient is investment-ready. **17.1.5.6** Finance-readiness language in public-safe materials, handoff records, Nexus Universe materials, National Model summaries, and Regional Cluster Program Plans shall be reviewed for regulated-perimeter discipline. **17.1.5.7** Finance-Readiness Dependency records shall be correctionable. If a record is used as financeability, bankability, insurability, underwriting, donor approval, development finance approval, public finance allocation, transaction readiness, investment endorsement, or project approval, it shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.6 Provider-Neutrality Conditions **17.1.6.1** **Provider-Neutrality Conditions** shall mean the rules and limitations that preserve neutrality among providers, vendors, operators, hosts, manufacturers, integrators, platforms, consultants, professional firms, technology actors, infrastructure actors, and enterprise participants before any lawful downstream procurement, qualification, contracting, or implementation process. **17.1.6.2** Provider-neutrality shall prevent public-good records from becoming provider validation. Provider participation, technical contribution, sponsor support, demonstration, Nexus Universe visibility, Working Group participation, Competence Cell participation, AEP Passport input, Nexus Rail input, Docket input, Grid input, public-safe report reference, or handoff discussion shall not create provider qualification, preferred-provider status, procurement eligibility, procurement award, product approval, service approval, certification, financeability, public authority approval, consent, project authorization, or execution authority. **17.1.6.3** Provider-Neutrality Conditions shall include, as applicable: 1. provider role classification; 2. sponsor-provider relationship disclosure; 3. conflict disclosure; 4. public authority relationship disclosure where relevant; 5. procurement-neutrality language; 6. demonstration limitations; 7. claims restrictions; 8. data and cyber restrictions; 9. protected knowledge restrictions; 10. safeguard obligations; 11. public-safe reporting limits; 12. handoff limitations; 13. correction and withdrawal rights. **17.1.6.4** Provider-neutral capability mapping may identify capabilities, dependencies, gaps, interoperability issues, conditions, and readiness questions, but shall not rank, approve, certify, select, endorse, prefer, validate, or recommend providers. **17.1.6.5** A provider may become a downstream provider, contractor, operator, host, or implementer only through separate lawful procurement, contracting, public authority, enterprise, National Consortium Company, Project SPV, or other competent process outside the public-good stack. **17.1.6.6** Provider-Neutrality Conditions shall travel with handoff records. A downstream recipient shall be warned that public-good records do not replace procurement, competition, diligence, qualification, contracting, or provider-selection processes. **17.1.6.7** Provider-Neutrality Condition records shall be correctionable. If provider participation is used as validation, procurement status, financeability, certification, public authority approval, AEP Passport status, Nexus-ready status, consent, project authorization, or execution authority, the record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.7 Handoff Readiness Record **17.1.7.1** A **Handoff Readiness Record** shall be the controlling public-good stack record that determines whether a public-good output is sufficiently organized, classified, limited, and correctionable to be transmitted to a competent downstream recipient for separate lawful review, diligence, decision, procurement, finance, insurance, donor, development, public finance, community, Indigenous where applicable, environmental, data, cyber, enterprise, project, or implementation process. **17.1.7.2** A Handoff Readiness Record shall not be a handoff approval, project approval, finance approval, procurement approval, certification, consent, public authority decision, provider selection, investment memorandum, transaction document, insurance submission, donor application, public finance application, or execution mandate. **17.1.7.3** A Handoff Readiness Record shall include, at minimum: 1. record title and identifier; 2. source pathway; 3. record owner; 4. version and date; 5. downstream recipient or recipient class; 6. purpose of routing; 7. evidence basis; 8. unresolved dependencies; 9. public authority dependencies; 10. finance and insurance dependencies; 11. procurement dependencies; 12. provider-neutrality conditions; 13. sponsor-boundary conditions; 14. safeguard and consent-boundary conditions; 15. protected knowledge restrictions; 16. data, privacy, cyber, infrastructure, security, health, and humanitarian restrictions where applicable; 17. publication class; 18. permitted and prohibited claims; 19. correction, withdrawal, supersession, renewal, and archive conditions; 20. express non-execution language. **17.1.7.4** A Handoff Readiness Record may classify a record as not handoff-ready, handoff-review pending, handoff-ready with restrictions, handoff-ready for limited recipient review, handoff-ready for public authority learning, handoff-ready for finance-readiness review, handoff-ready for National Consortium Company review, handoff-ready for Project SPV-readiness review, handoff-ready for safeguard review, handoff-ready for procurement-neutral review, or archived. **17.1.7.5** The Handoff Readiness Record shall identify the difference between record maturity and downstream maturity. A mature public-good record may still be immature for finance, procurement, consent, public authority approval, or project execution. **17.1.7.6** No handoff shall occur without a Handoff Readiness Record or equivalent controlling record. **17.1.7.7** Handoff Readiness Records shall be correctionable. If a record is incomplete, unsafe, misclassified, overclaimed, routed to an improper recipient, stripped of safeguards, used as approval, or used to imply execution, the record shall be corrected, restricted, withdrawn, superseded, notified to affected recipients where appropriate, publicly clarified where necessary, or archived. *** #### 17.1.8 Lawful Handoff Trigger **17.1.8.1** A **Lawful Handoff Trigger** shall be the recorded condition or set of conditions under which a public-good stack record may be transmitted to a competent downstream recipient for separate lawful review, diligence, decision, procurement, finance, insurance, donor, development, public finance, community, Indigenous where applicable, environmental, data, cyber, enterprise, project, or implementation process. **17.1.8.2** A Lawful Handoff Trigger may arise from a National Model record, Regional Cluster Program Plan record, Nexus Universe output, public authority learning record, finance-readiness record, safeguard record, AEP Passport candidate input, Nexus Rail routeability input, Docket item, Grid input, National Consortium Company request, Project SPV-readiness request, public authority learning request, provider-neutral review request, or other recorded pathway. **17.1.8.3** A Lawful Handoff Trigger shall require: 1. a defined recipient or recipient class; 2. a lawful purpose; 3. a Handoff Readiness Record or equivalent; 4. source-record validation; 5. limitation preservation; 6. safeguard attachment; 7. public authority dependency statement; 8. finance and procurement dependency statement; 9. provider-neutrality statement; 10. data, cyber, privacy, and protected knowledge review where applicable; 11. claims permission review; 12. correction and withdrawal pathway. **17.1.8.4** A Lawful Handoff Trigger shall not occur merely because a sponsor requests it, a provider asks for it, a capital reader is interested, a public authority attended a session, a project proponent is visible, Nexus Universe generated attention, media coverage occurred, or a public-good record appears promising. **17.1.8.5** The trigger shall not convert the public-good stack into an executing party. It shall authorize transmission of a record for separate review only, not downstream approval. **17.1.8.6** The Lawful Handoff Trigger shall be logged and shall identify whether the handoff is informational, public authority-learning, finance-readiness, enterprise-review, SPV-readiness, safeguard-review, procurement-neutral, technical-review, or other classified handoff. **17.1.8.7** Lawful Handoff Trigger records shall be correctionable. If a trigger is premature, sponsor-driven, provider-driven, finance-overclaimed, public-authority-overclaimed, safeguard-incomplete, unlawful, misclassified, or used to imply approval or execution, the trigger shall be corrected, restricted, suspended, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.9 Handoff Without Execution by Public-Good Stack **17.1.9.1** **Handoff Without Execution by Public-Good Stack** shall be a mandatory principle of the Federation. A public-good stack body may prepare, classify, limit, transmit, explain, correct, supersede, withdraw, and archive public-good records, but shall not execute the downstream activity to which the record may relate. **17.1.9.2** The public-good stack shall not act as project developer, operator, contractor, public authority, procurement body, lender, fund, insurer, reinsurer, underwriter, broker, dealer, investment adviser, financial adviser, donor, development finance institution, public finance authority, certifier, standards authority by default, consent body, emergency command center, public warning body, or implementation vehicle. **17.1.9.3** Handoff shall not create agency. A downstream recipient shall not be treated as agent of GCRI, GRF, GRA, the Global Nexus Consortium, a Regional Headquarters Consortium, a National Nexus Consortium, the Central Nexus Bureau, Nexus Universe, a National Council, a Helix Council, a Working Group, a Competence Cell, or any public-good stack body merely because it receives a record. **17.1.9.4** Handoff shall not create shared liability by implication. Each downstream recipient shall remain responsible for its own independent diligence, decisions, approvals, contracts, financing, insurance, procurement, safeguards, community and Indigenous processes where applicable, data and cyber obligations, environmental and social obligations, implementation, operation, and liability. **17.1.9.5** Public-good stack participants shall not give instructions to execute. They may describe limitations, dependencies, evidence, readiness, safeguards, and handoff conditions, but shall not direct construction, procurement, financing, deployment, contracting, operation, public authority action, community process, Indigenous process, public warning, emergency response, or project implementation. **17.1.9.6** Handoff materials shall include express non-execution language and shall identify the downstream processes that remain separate and unresolved unless separately completed. **17.1.9.7** Handoff Without Execution records shall be correctionable. If handoff is described as execution, if public-good bodies are treated as executing parties, if downstream recipients imply public-good approval, or if shared liability or agency is implied, the handoff record and related claims shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.1.10 Handoff Correction **17.1.10.1** **Handoff Correction** shall be the mandatory process through which handoff-related records, claims, recipients, classifications, limitations, safeguards, dependencies, public authority references, finance-readiness references, provider-neutrality references, Nexus Universe references, AEP Passport references, Nexus Rail references, Docket references, Grid references, public-safe reports, and archive entries are corrected where the handoff is inaccurate, unsafe, incomplete, overclaimed, misused, misrouted, outdated, superseded, or execution-implying. **17.1.10.2** Handoff Correction may be triggered by: 1. premature handoff; 2. improper recipient selection; 3. missing safeguard conditions; 4. missing public authority dependencies; 5. missing finance or procurement dependencies; 6. provider-neutrality breach; 7. sponsor influence; 8. protected knowledge exposure; 9. data, cyber, privacy, infrastructure, security, health, or humanitarian sensitivity issue; 10. financeability overclaim; 11. public authority approval overclaim; 12. provider validation overclaim; 13. certification or standards overclaim; 14. consent overclaim; 15. project authorization overclaim; 16. execution implication; 17. downstream misuse. **17.1.10.3** Handoff Correction measures may include private notice, controlled clarification, public-safe clarification, recipient notice, handoff restriction, handoff suspension, handoff withdrawal, handoff supersession, limitation amendment, safeguard reattachment, publication reclassification, public-safe report correction, claim withdrawal, AEP Passport or Nexus Rail reference correction, Docket or Grid reference correction, archive notation, and downstream recipient correction notice. **17.1.10.4** Urgent Handoff Correction may occur where delay would create public authority confusion, finance reliance, procurement advantage, provider validation, certification drift, sponsor capture, consent overclaim, protected knowledge exposure, public-safe reporting harm, market confusion, reputational misuse, or execution implication. **17.1.10.5** Handoff Correction shall preserve confidentiality and public-safe discipline. Correcting a handoff shall not disclose sensitive public authority information, finance-sensitive information, provider-sensitive information, sponsor-sensitive information, community-sensitive information, Indigenous-sensitive information where applicable, protected knowledge, cyber-sensitive information, infrastructure-sensitive information, security-sensitive information, health-sensitive information, humanitarian-sensitive information, or not-for-publication information. **17.1.10.6** Handoff Correction shall be continuous and retroactive. A handoff claim shall not become valid by recipient use, sponsor use, provider use, investor use, public authority reference, Nexus Universe visibility, media circulation, archive, administrative convenience, or passage of time. **17.1.10.7** Handoff Correction records shall themselves be correctionable. If a correction is incomplete, wrong, unsafe, not implemented, publicized beyond permission, or fails to correct the underlying overclaim, the correction record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived. *** ### 17.2 National Consortium Company Interface #### 17.2.1 National Consortium Company as Separate Enterprise-Stack Vehicle **17.2.1.1** A **National Consortium Company** shall be a separate enterprise-stack vehicle that may be formed, where lawful and appropriate, to receive, evaluate, translate, organize, structure, contract, finance, partner, procure, implement, operate, or otherwise participate in downstream enterprise activity arising after public-good stack formation and handoff, subject always to its own governing documents, applicable law, public authority requirements, finance requirements, procurement requirements, safeguards, contracts, and liabilities. **17.2.1.2** A National Consortium Company shall be legally and institutionally separate from the public-good stack. It shall not be the National Nexus Consortium, Regional Headquarters Consortium, Global Nexus Consortium, Central Nexus Bureau, GCRI, GRF, GRA, Nexus Universe, National Council, Helix Council, Working Group, Competence Cell, public authority, certifier, standards authority by default, consent body, or public-safe reporting body. **17.2.1.3** The purpose of the National Consortium Company interface shall be to preserve the public-good firewall while enabling lawful downstream enterprise pathways where appropriate. Public-good bodies may form records and handoff conditions; the National Consortium Company may operate only within separate lawful enterprise authority. **17.2.1.4** The National Consortium Company shall not inherit public-good legitimacy automatically. Receiving a public-good record shall not make the Company endorsed, approved, certified, financeable, procured, provider-qualified, consented, project-authorized, AEP Passported, Nexus-ready, Nexus Node-approved, or execution-ready. **17.2.1.5** The National Consortium Company shall maintain its own governance, risk controls, conflicts process, finance controls, procurement controls, provider controls, public authority interface, safeguard process, data and cyber controls, legal compliance, contracting process, accounting records, insurance records, project records, and correction process. **17.2.1.6** Any relationship between a National Consortium Company and a National Nexus Consortium shall be documented through written interface rules that preserve separation, non-agency, non-merger, non-shared liability, claims discipline, public authority boundaries, finance boundaries, provider boundaries, safeguard boundaries, and correctionability. **17.2.1.7** National Consortium Company interface records shall be correctionable. If the Company is described as the public-good body, uses public-good records as approval, implies government endorsement, implies financeability, implies provider validation, implies consent, or collapses the public-good stack into enterprise execution, the record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.2 Country-Level Enterprise Interface **17.2.2.1** The **Country-Level Enterprise Interface** shall be the controlled interface through which a National Consortium Company may receive and evaluate public-good records from a national pathway for separate enterprise review, including readiness translation, project structuring, provider review, public authority dependency review, finance-readiness translation, procurement planning, safeguard review, and Project SPV-readiness assessment. **17.2.2.2** The Country-Level Enterprise Interface shall operate only after a lawful handoff trigger or equivalent record. It shall not bypass the National Nexus Consortium, national source records, public authority dependencies, finance dependencies, procurement dependencies, provider-neutrality conditions, safeguard conditions, or correction requirements. **17.2.2.3** The interface may include: 1. receipt of Handoff Readiness Records; 2. review of National Model inputs; 3. review of Nexus Universe outputs; 4. review of public authority dependency notes; 5. review of finance-readiness notes; 6. review of safeguard conditions; 7. review of provider-neutral capability maps; 8. review of AEP Passport and Nexus Rail candidate inputs; 9. review of Docket and Grid items; 10. review of public-safe reporting limits; 11. preparation of enterprise diligence workplans; 12. preparation of Project SPV-readiness pathways. **17.2.2.4** The Country-Level Enterprise Interface shall not convert public-good records into enterprise approval. It shall only create an enterprise review pathway within the National Consortium Company’s own lawful authority. **17.2.2.5** The National Consortium Company shall maintain separation between public-good records and enterprise records. A public-good handoff record shall be preserved as received, with limitations. Any enterprise adaptation, diligence memo, project plan, finance note, procurement note, or SPV document shall be separately labeled and shall not overwrite the public-good source record. **17.2.2.6** The interface shall include claims controls. The Company shall not publicly claim that a public-good handoff gives it national endorsement, government approval, financeability, procurement status, certification, provider validation, consent, project authorization, or execution authority. **17.2.2.7** Country-Level Enterprise Interface records shall be correctionable. If the interface bypasses national source records, strips limitations, misuses safeguards, creates finance signaling, implies public authority approval, implies provider validation, implies consent, or suggests execution without lawful enterprise authority, the interface record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.3 National Handoff Recipient Where Lawful **17.2.3.1** A National Consortium Company may act as a **National Handoff Recipient** where lawful, appropriate, and recorded. Such role shall permit the Company to receive a public-good record for separate enterprise review, diligence, structuring, coordination, procurement preparation, finance-readiness translation, Project SPV-readiness preparation, or lawful implementation planning within its own authority and subject to all unresolved dependencies. **17.2.3.2** National Handoff Recipient status shall not create project approval, procurement award, financeability, bankability, insurability, investment approval, insurance approval, donor approval, public finance allocation, provider selection, public authority approval, certification, community consent, Indigenous consent, environmental approval, permit approval, contract award, AEP Passport status, Nexus-ready status, Nexus Node status, or execution authority. **17.2.3.3** A handoff to the National Consortium Company shall include: 1. the Handoff Readiness Record; 2. source public-good records; 3. limitation schedule; 4. unresolved dependency schedule; 5. public authority dependency schedule; 6. finance, insurance, donor, development, and public finance dependency schedule; 7. procurement dependency schedule; 8. provider-neutrality conditions; 9. safeguard and consent-boundary conditions; 10. protected knowledge restrictions; 11. data, privacy, cyber, infrastructure, security, health, and humanitarian restrictions where applicable; 12. claims permissions and prohibited claims; 13. correction, withdrawal, and supersession conditions. **17.2.3.4** The Company shall acknowledge receipt in a record that confirms the limited purpose of the handoff and expressly disclaims public-good approval, public authority approval, financeability, certification, consent, project authorization, and execution authority. **17.2.3.5** The Company shall not rely on the handoff as a substitute for its own diligence, legal review, financial review, insurance review, procurement process, public authority process, safeguard process, community or Indigenous process where applicable, data and cyber review, environmental and social review, contracting, or project governance. **17.2.3.6** The Company shall comply with correction notices issued by the relevant public-good record owner. If a source record is corrected, restricted, withdrawn, or superseded, the Company shall update its internal enterprise records and downstream communications accordingly. **17.2.3.7** National Handoff Recipient records shall be correctionable. If recipient status is used as approval, financeability, procurement status, certification, provider validation, consent, project authorization, or execution authority, the handoff and recipient records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.4 Company Governance Separation **17.2.4.1** **Company Governance Separation** shall require that the governance of a National Consortium Company remain separate from the governance of the National Nexus Consortium, Regional Headquarters Consortium, Global Nexus Consortium, Central Nexus Bureau, GCRI, GRF, GRA, Nexus Universe, National Councils, Helix Councils, Working Groups, and Competence Cells. **17.2.4.2** Company directors, officers, managers, shareholders, members, advisers, committees, contractors, providers, sponsors, investors, insurers, and partners shall act under the Company’s own lawful enterprise governance and shall not use public-good roles to claim enterprise authority unless separately and lawfully appointed within the Company. **17.2.4.3** Public-good participants may, where lawful and conflict-managed, also hold Company roles, but such dual roles shall be disclosed, classified, managed, and recused where required. A person shall not use a public-good role to influence Company decisions or a Company role to influence public-good records. **17.2.4.4** Company governance shall include conflicts controls for sponsors, providers, capital actors, public authorities, media actors, community actors, Indigenous actors where applicable, technical partners, National Consortium Company affiliates, Project SPVs, and downstream project proponents. **17.2.4.5** Company governance shall not control public-good records. The Company may receive records, request clarifications, prepare enterprise analysis, and correct its own downstream materials, but shall not amend National Model records, Regional Cluster Program Plans, Nexus Universe records, AEP Passport inputs, Nexus Rail inputs, Docket items, Grid inputs, public-safe reports, or safeguard records except through the proper correction pathway. **17.2.4.6** Governance separation shall include name-use and mark-use controls. The Company shall not use Nexus, GCRI, GRF, GRA, National Nexus Consortium, Regional Headquarters, Nexus Universe, AEP Passport, Nexus Rail, Docket, Grid, or related names or marks to imply approval beyond the record. **17.2.4.7** Company Governance Separation records shall be correctionable. If governance roles collapse, conflicts are unmanaged, public-good records are controlled by Company interests, shared liability is implied, or the Company is presented as the public-good body, the governance and claims records shall be corrected, restricted, suspended, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.5 Company Claims Discipline **17.2.5.1** **Company Claims Discipline** shall govern all statements by or about a National Consortium Company concerning its relationship to Nexus, the National Nexus Consortium, the Regional Headquarters Consortium, the Global Nexus Consortium, GCRI, GRF, GRA, Nexus Universe, National Models, Regional Cluster Program Plans, AEP Passport, Nexus Rail, Docket, Grid, public-safe reports, sponsors, providers, public authorities, capital readers, communities, Indigenous actors where applicable, and Project SPVs. **17.2.5.2** Company claims shall be valid only if grounded in a controlling record identifying role, scope, country, term, pathway, public-safe listing permission, permitted language, prohibited language, limitations, public authority boundaries, finance boundaries, provider boundaries, safeguard boundaries, correction status, and archive status. **17.2.5.3** The Company shall not claim that it is endorsed, approved, certified, financeable, bankable, insurable, public-authority-approved, procurement-approved, provider-validated, consented, project-authorized, AEP Passported, Nexus-ready, Nexus Node-approved, or execution-authorized by reason of receiving public-good records or participating in Nexus pathways. **17.2.5.4** The Company shall not describe public-good outputs as project approvals, investment pipelines, procurement pipelines, official government programs, certified assets, consented projects, public finance allocations, insurance-approved projects, donor-approved projects, or execution mandates unless such status is separately created by a competent lawful process and accurately recorded. **17.2.5.5** Company claims involving sponsors, providers, public authorities, capital readers, insurers, donors, development actors, communities, Indigenous actors where applicable, media, or Project SPVs shall receive heightened review to prevent endorsement, finance, procurement, consent, or execution overclaim. **17.2.5.6** Company claims shall distinguish public-good source records from Company enterprise analysis and downstream actions. **17.2.5.7** Company Claims Discipline records shall be correctionable. If a Company claim exceeds the record, omits limitations, creates reliance, implies public authority approval, creates finance signaling, implies provider validation, implies consent, or suggests execution without lawful basis, the claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.6 Company Public Authority Boundary **17.2.6.1** The **Company Public Authority Boundary** shall require that a National Consortium Company not represent itself as a public authority, regulator, procurement body, public finance authority, public warning body, emergency command center, permitting authority, policy authority, municipal authority, Indigenous or Tribal authority where applicable, or government instrumentality unless separately and lawfully constituted and authorized. **17.2.6.2** A Company may interface with public authorities through lawful channels, including learning, dependency mapping, procurement processes, public finance processes, regulatory processes, permitting processes, infrastructure processes, environmental processes, emergency management processes, public health processes, data authorization processes, and project approval processes, but such interface shall not create approval by implication. **17.2.6.3** The Company shall maintain records for public authority interactions, including capacity, purpose, materials shared, public-safe classification, confidentiality, public authority dependencies, unresolved issues, permitted references, prohibited claims, and correction obligations. **17.2.6.4** The Company shall not use public authority attendance, emails, meetings, requests, comments, Nexus Universe participation, Government Portfolio showcase materials, public-safe reports, public authority room participation, or dependency notes as government endorsement or approval. **17.2.6.5** The Company shall obtain any required public authority approvals, permits, consents, procurement decisions, public finance decisions, environmental approvals, data authorizations, infrastructure approvals, or emergency-related permissions through separate lawful processes. **17.2.6.6** Public authority boundary language shall be included in Company communications where public authority participation could reasonably be misread as endorsement. **17.2.6.7** Company Public Authority Boundary records shall be correctionable. If Company materials imply government endorsement, regulatory comfort, procurement status, public finance allocation, data authorization, public warning, project authorization, or public authority approval without lawful basis, the record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.7 Company Finance Boundary **17.2.7.1** The **Company Finance Boundary** shall require that a National Consortium Company distinguish finance-readiness, capital-readability, insurance-readiness, donor relevance, development-readiness, and public finance relevance from actual financing, insurance, donor support, development finance, public finance allocation, investment advice, insurance advice, underwriting, guarantee, rating, placement, offering, transaction arrangement, or capital commitment. **17.2.7.2** The Company may use public-good finance-readiness records as inputs to separate lawful enterprise diligence, but shall not represent those records as investment memoranda, underwriting submissions, insurance applications, donor proposals, public finance applications, valuations, ratings, recommendations, guarantees, legal opinions, tax opinions, fairness opinions, or transaction documents unless separately created by competent actors and lawfully reviewed. **17.2.7.3** The Company shall maintain no-reliance discipline when using Nexus-derived finance-readiness records. Recipients shall be warned that such records do not substitute for independent legal, financial, insurance, tax, accounting, technical, procurement, public authority, environmental, social, community, Indigenous where applicable, data, cyber, or project diligence. **17.2.7.4** The Company shall not claim financeability, bankability, insurability, underwriting appetite, donor approval, development finance approval, public finance allocation, transaction readiness, investor endorsement, capital commitment, or project approval by reason of Nexus participation, capital-reader participation, National Investors Council involvement, GRA-aligned finance-readiness work, AEP Passport finance-layer discussion, Nexus Rail finance-readiness input, Docket input, Grid input, or Nexus Universe visibility. **17.2.7.5** Where the Company seeks finance, insurance, donor support, development finance, or public finance, it shall do so through separate lawful processes, with its own advisers, diligence, governance, disclosures, market-conduct controls, legal review, and liability. **17.2.7.6** Company finance communications shall not use public-good names or records to create unlawful reliance. **17.2.7.7** Company Finance Boundary records shall be correctionable. If Company materials convert readiness into financeability, imply capital commitment, imply insurance approval, imply donor approval, imply public finance allocation, or create transaction reliance without lawful basis, the record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.8 Company Provider Boundary **17.2.8.1** The **Company Provider Boundary** shall require that a National Consortium Company distinguish provider-neutral capability mapping and provider-candidate records from provider selection, procurement, contracting, approval, certification, qualification, or validation. **17.2.8.2** A Company may evaluate providers, hosts, operators, integrators, technology actors, consultants, manufacturers, platforms, and infrastructure actors through separate lawful enterprise processes, but shall not treat public-good provider participation as a substitute for procurement, competition, diligence, qualification, contracting, or public authority requirements. **17.2.8.3** Provider records transferred from the public-good stack shall carry provider-neutrality conditions, procurement-neutrality conditions, conflicts, sponsor relationships, public authority boundaries, finance boundaries, safeguard conditions, data and cyber conditions, protected knowledge restrictions, claims limits, correction history, and handoff limitations. **17.2.8.4** The Company shall not give preference to a provider merely because the provider participated in Nexus Universe, contributed to a Working Group, supported a Competence Cell, sponsored a pathway, contributed public-good software, appeared in an AEP Passport discussion, appeared in a Nexus Rail routing record, contributed to a Docket item, contributed to a Grid input, or supported public-safe reporting. **17.2.8.5** Company provider selection, where undertaken, shall be documented separately and shall comply with applicable law, procurement requirements, conflicts controls, technical diligence, finance requirements, safeguards, data and cyber controls, and project governance. **17.2.8.6** Company communications shall not describe provider-neutral participation as provider approval. **17.2.8.7** Company Provider Boundary records shall be correctionable. If provider participation is used as validation, procurement status, financeability, certification, public authority approval, consent, project authorization, or execution authority, the Company record and related public-good reference shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.9 Company Safeguard Boundary **17.2.9.1** The **Company Safeguard Boundary** shall require that a National Consortium Company preserve all safeguard, community, Indigenous where applicable, rights, accessibility, protected knowledge, environmental, social, cultural, place-based, humanitarian, health, data, cyber, and public-safe reporting conditions attached to any public-good record it receives. **17.2.9.2** The Company shall not treat safeguard records as consent. Receipt of community-risk notes, Indigenous protocol notes where applicable, protected knowledge cautions, diaspora inputs, youth inputs, accessibility notes, environmental and social safeguard notes, or public-safe reporting restrictions shall not create community consent, Indigenous consent, FPIC satisfaction where applicable, social license, protected knowledge authorization, land access, site approval, cultural approval, environmental approval, rights-holder approval, local authorization, project approval, or execution authority. **17.2.9.3** The Company shall maintain a safeguard register for public-good records it receives, identifying safeguard conditions, unresolved community or Indigenous issues where applicable, protected knowledge restrictions, public-safe reporting limits, downstream process requirements, recipient restrictions, correction rights, and withdrawal conditions. **17.2.9.4** The Company shall ensure that safeguard conditions travel into any enterprise analysis, project structuring, Project SPV preparation, provider review, finance-readiness work, procurement preparation, public authority interface, and handoff package. **17.2.9.5** The Company shall not use communities, Indigenous actors where applicable, civil society, diaspora, youth, accessibility advocates, or public-interest contributors as legitimacy proxies where the record does not support representative authority or consent. **17.2.9.6** Where lawful community, Indigenous, environmental, social, land, cultural, data, protected knowledge, or rights processes are required downstream, the Company shall ensure such processes are separately addressed by competent actors and not inferred from Nexus participation. **17.2.9.7** Company Safeguard Boundary records shall be correctionable. If safeguards are stripped, weakened, misclassified, used as consent, publicly exposed beyond permission, omitted from downstream records, or used to imply approval or execution, the Company record and related handoff record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.2.10 Company Correction **17.2.10.1** **Company Correction** shall be the mandatory process through which a National Consortium Company corrects, restricts, withdraws, supersedes, publicly clarifies where necessary, renews, or archives Company records, claims, public-good handoff references, public authority references, finance references, provider references, safeguard references, Nexus Universe references, National Model references, AEP Passport references, Nexus Rail references, Docket references, Grid references, Project SPV references, and downstream communications. **17.2.10.2** Company Correction may be triggered by public-good source correction, handoff correction, public authority overclaim, finance overclaim, provider validation, certification drift, procurement implication, consent overclaim, protected knowledge exposure, safeguard omission, conflict non-disclosure, sponsor capture, provider capture, market reliance, public-safe reporting error, Project SPV misuse, or execution implication. **17.2.10.3** Company Correction measures may include internal record amendment, downstream recipient notice, public-safe clarification, claim withdrawal, public listing correction, investor-material correction, procurement-material correction, provider-material correction, public authority-material correction, safeguard reattachment, handoff restriction, Project SPV document correction, suspension of reliance, withdrawal of reference, supersession, and archive notation. **17.2.10.4** The Company shall comply with correction notices issued by the relevant public-good record owner and shall not continue using corrected, withdrawn, superseded, or restricted public-good records as current support. **17.2.10.5** Company Correction shall preserve confidentiality and public-safe discipline. Correcting Company records shall not expose sensitive public authority information, finance-sensitive information, provider-sensitive information, sponsor-sensitive information, community-sensitive information, Indigenous-sensitive information where applicable, protected knowledge, cyber-sensitive information, infrastructure-sensitive information, security-sensitive information, health-sensitive information, humanitarian-sensitive information, or not-for-publication information. **17.2.10.6** Company Correction shall be continuous and retroactive. A Company claim shall not become valid by repetition, investor use, sponsor use, provider use, public authority reference, Nexus Universe visibility, media circulation, archive, administrative convenience, or passage of time. **17.2.10.7** Company Correction records shall themselves be correctionable. If a correction is incomplete, wrong, unsafe, not implemented, publicized beyond permission, or fails to correct the underlying overclaim, the correction record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived. *** ### 17.3 Project SPV Interface #### 17.3.1 Project SPV as Separate Lawful Project Vehicle **17.3.1.1** A **Project SPV** shall be a separate lawful project vehicle that may be formed, where appropriate, to hold, contract, finance, insure, procure, implement, operate, own, manage, or otherwise structure a specific project or project portfolio under separate law, governance, finance, procurement, public authority, safeguard, contract, tax, accounting, insurance, data, cyber, environmental, social, and operational requirements. **17.3.1.2** A Project SPV shall be legally and institutionally separate from the public-good stack and from the National Consortium Company unless a separate lawful relationship is expressly recorded. A Project SPV shall not be the National Nexus Consortium, Regional Headquarters Consortium, Global Nexus Consortium, Central Nexus Bureau, GCRI, GRF, GRA, Nexus Universe, National Council, Helix Council, Working Group, Competence Cell, public authority, certifier, standards authority by default, consent body, or public-safe reporting body. **17.3.1.3** The Project SPV interface shall exist to preserve role separation where public-good records are relevant to project formation, diligence, finance-readiness, procurement, public authority processes, safeguards, or implementation planning, while preventing public-good records from becoming project approval or execution authority. **17.3.1.4** A Project SPV shall not inherit Nexus legitimacy automatically. Formation of an SPV, receipt of public-good records, Nexus Universe visibility, AEP Passport discussion, Nexus Rail routeability, Docket input, Grid input, National Model reference, Regional Cluster Program Plan reference, National Consortium Company involvement, sponsor support, provider participation, capital-reader room participation, or public authority learning participation shall not create approval or readiness beyond the record. **17.3.1.5** A Project SPV shall maintain its own governance, conflicts controls, finance controls, procurement controls, provider controls, public authority interface, safeguard process, data and cyber controls, legal compliance, contracting process, accounting records, insurance records, project records, operational controls, and correction process. **17.3.1.6** Any Project SPV relationship with a National Consortium Company, public authority, provider, host, operator, investor, insurer, donor, development actor, public finance actor, community process, Indigenous governance process where applicable, or public-good body shall be separately recorded. **17.3.1.7** Project SPV interface records shall be correctionable. If a Project SPV is described as approved by Nexus, uses public-good records as project authorization, implies financeability, implies provider validation, implies public authority approval, implies consent, or collapses public-good readiness into execution, the record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.2 SPV-Readiness Input **17.3.2.1** **SPV-Readiness Input** shall mean a public-good or enterprise-stack record that identifies whether a matter may be ready for separate consideration by a Project SPV or for potential SPV formation, without creating an SPV, approving a project, or authorizing execution. **17.3.2.2** SPV-Readiness Input may arise from National Models, Regional Cluster Program Plans, Nexus Universe outputs, public authority dependency notes, finance-readiness notes, insurance-readiness notes, provider-neutral capability maps, safeguard records, AEP Passport candidate inputs, Nexus Rail routeability inputs, Docket items, Grid inputs, National Consortium Company review, or lawful handoff records. **17.3.2.3** SPV-Readiness Input shall include, as applicable: 1. project or portfolio description; 2. source record; 3. readiness stage; 4. evidence basis; 5. unresolved dependencies; 6. public authority dependencies; 7. finance and insurance dependencies; 8. procurement dependencies; 9. provider and operator dependencies; 10. host and infrastructure dependencies; 11. safeguard and consent-boundary dependencies; 12. data, cyber, privacy, and protected knowledge restrictions; 13. environmental and social dependencies; 14. governance and contracting dependencies; 15. permitted and prohibited claims; 16. correction and withdrawal conditions. **17.3.2.4** SPV-Readiness Input shall not be treated as an investment memorandum, project plan, implementation plan, finance approval, insurance approval, procurement decision, provider selection, public authority approval, environmental approval, community consent, Indigenous consent, or execution instruction. **17.3.2.5** SPV-Readiness Input shall identify whether the matter is not SPV-ready, potentially SPV-relevant, SPV-readiness under review, SPV-readiness with restrictions, SPV-ready for limited enterprise review, or archived. Such classification shall not imply execution readiness. **17.3.2.6** SPV-Readiness Input shall be used only by competent recipients within lawful processes and subject to independent diligence. **17.3.2.7** SPV-Readiness Input records shall be correctionable. If SPV-readiness is overstated, used as financeability, used as public authority approval, used as provider validation, used as consent, or used as project authorization, the input record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.3 SPV Public Authority Dependencies **17.3.3.1** **SPV Public Authority Dependencies** shall mean the laws, approvals, permits, procurement processes, regulatory processes, public finance processes, data authorizations, environmental approvals, land approvals, infrastructure approvals, health and safety approvals, emergency management processes, municipal or subnational processes, Indigenous or Tribal public-governance processes where applicable, and other public-law conditions relevant to a Project SPV or potential Project SPV. **17.3.3.2** SPV Public Authority Dependencies shall not be satisfied by Nexus participation, public authority learning rooms, Government Portfolio showcase materials, public-safe reports, Nexus Universe visibility, National Model references, Regional Cluster Program Plan references, AEP Passport public authority layer discussions, Nexus Rail dependency routing, Docket inputs, Grid inputs, National Consortium Company involvement, or Project SPV formation. **17.3.3.3** A Project SPV record shall identify all known public authority dependencies and shall distinguish dependencies that are mapped, under review, externally required, satisfied by separate lawful record, unresolved, restricted, not yet assessed, or not applicable. **17.3.3.4** Public authority names, logos, attendance, emails, comments, learning participation, dashboard review, public-stage appearance, or public finance relevance shall not be used by the Project SPV to imply endorsement or approval unless separately and lawfully authorized. **17.3.3.5** The Project SPV shall obtain any required public authority approvals through separate lawful processes and shall maintain its own records of such processes. **17.3.3.6** Public authority dependency records attached to a Project SPV shall preserve public authority-sensitive classifications and shall not be publicized beyond permission. **17.3.3.7** SPV Public Authority Dependency records shall be correctionable. If a Project SPV implies government endorsement, regulatory comfort, procurement status, public finance allocation, public warning, data authorization, environmental approval, project authorization, or public authority approval without lawful basis, the record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.4 SPV Finance and Insurance Dependencies **17.3.4.1** **SPV Finance and Insurance Dependencies** shall mean the investment, finance, insurance, reinsurance, donor, development, public finance, guarantee, credit, revenue, risk allocation, diligence, legal, tax, accounting, governance, contractual, technical, public authority, procurement, safeguard, environmental, social, data, cyber, host, operator, and provider conditions that must be separately addressed before a Project SPV can lawfully pursue, receive, rely upon, or represent finance, insurance, donor support, development finance, public finance, or transaction execution. **17.3.4.2** SPV Finance and Insurance Dependencies shall not be satisfied by finance-readiness notes, capital-reader rooms, insurance-readiness rooms, GRA-aligned finance-readiness work, National Investors Council participation, capital-reader participation, donor relevance discussions, development-readiness discussions, public finance relevance discussions, Nexus Universe visibility, AEP Passport finance-layer discussions, Nexus Rail finance-readiness inputs, Docket inputs, Grid inputs, or National Consortium Company review. **17.3.4.3** A Project SPV record shall identify, as applicable: 1. capital requirements; 2. revenue and cost assumptions; 3. risk allocation issues; 4. insurance and reinsurance requirements; 5. donor and development dependencies; 6. public finance dependencies; 7. guarantee and credit dependencies; 8. diligence requirements; 9. legal, tax, accounting, and governance requirements; 10. public authority and procurement dependencies; 11. safeguard, community, and Indigenous dependencies where applicable; 12. data, cyber, infrastructure, and security dependencies; 13. provider, host, operator, and contractor dependencies; 14. permitted and prohibited finance claims. **17.3.4.4** A Project SPV shall not claim financeability, bankability, insurability, underwriting appetite, donor approval, development finance approval, public finance allocation, transaction readiness, investor endorsement, or capital commitment unless separately supported by competent lawful records. **17.3.4.5** Finance and insurance materials prepared by or for a Project SPV shall be separate from public-good finance-readiness records and shall be subject to independent legal, financial, insurance, tax, accounting, technical, procurement, public authority, safeguard, environmental, social, community, Indigenous where applicable, data, cyber, and project diligence. **17.3.4.6** Any reference to Nexus-derived finance-readiness materials shall preserve no-reliance language and source limitations. **17.3.4.7** SPV Finance and Insurance Dependency records shall be correctionable. If finance-readiness is converted into financeability, insurance-readiness into insurability, donor relevance into donor approval, public finance relevance into public finance allocation, or capital-reader participation into investment interest, the SPV record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.5 SPV Provider and Operator Dependencies **17.3.5.1** **SPV Provider and Operator Dependencies** shall mean the provider, contractor, operator, host, platform, manufacturer, integrator, technology, infrastructure, professional service, maintenance, implementation, data, cyber, interoperability, safety, performance, capacity, procurement, and contractual conditions that must be separately addressed before a Project SPV can lawfully select, contract with, rely on, or operate through any provider or operator. **17.3.5.2** Provider and Operator Dependencies shall not be satisfied by provider-neutral participation, technical partnership, public-good software contribution, Working Group participation, Competence Cell participation, Nexus Universe demonstration, AEP Passport candidate input, Nexus Rail input, Docket technical item, Grid technical input, sponsor support, or National Consortium Company interface. **17.3.5.3** A Project SPV record shall identify: 1. required provider or operator capabilities; 2. procurement or selection pathway; 3. provider-neutral source records; 4. technical diligence requirements; 5. cybersecurity and data requirements; 6. interoperability requirements; 7. host and infrastructure dependencies; 8. safety and performance requirements; 9. contracting dependencies; 10. conflicts and sponsor-provider relationships; 11. public authority dependencies; 12. safeguard and consent-boundary dependencies; 13. permitted and prohibited provider claims. **17.3.5.4** A Project SPV shall not select, prefer, validate, approve, or contract with a provider merely because the provider participated in Nexus or contributed to public-good records. **17.3.5.5** Provider and operator selection by a Project SPV shall occur through separate lawful processes, including procurement, diligence, negotiation, conflicts review, safeguard review, public authority review where required, finance review, insurance review, and contractual governance. **17.3.5.6** Provider and operator communications shall not use Nexus participation as validation unless a separate lawful provider qualification or selection process supports the exact claim. **17.3.5.7** SPV Provider and Operator Dependency records shall be correctionable. If provider-neutral records are used as provider approval, procurement status, financeability, certification, public authority approval, consent, project authorization, or execution authority, the SPV record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.6 SPV Safeguard Dependencies **17.3.6.1** **SPV Safeguard Dependencies** shall mean the community, Indigenous where applicable, rights, accessibility, protected knowledge, environmental, social, cultural, place-based, humanitarian, health, data, cyber, public-safe reporting, consent, consultation, accommodation, environmental approval, land access, site access, cultural heritage, and rights-holder conditions that must be separately addressed before a Project SPV can lawfully proceed. **17.3.6.2** SPV Safeguard Dependencies shall not be satisfied by safeguard-room participation, community contribution, Indigenous participation where applicable, diaspora input, youth input, accessibility review, protected knowledge caution, public-safe reporting, Nexus Universe visibility, AEP Passport safeguard layer discussion, Nexus Rail safeguard condition, Docket item, Grid input, National Model reference, or Regional Cluster Program Plan reference. **17.3.6.3** A Project SPV shall maintain a safeguard dependency register identifying: 1. community-risk conditions; 2. Indigenous protocol conditions where applicable; 3. consultation or consent processes required by law or protocol; 4. protected knowledge restrictions; 5. data sovereignty and privacy conditions; 6. accessibility conditions; 7. environmental and social safeguards; 8. land, cultural, heritage, and place-based conditions; 9. humanitarian and health-sensitive conditions; 10. public-safe reporting restrictions; 11. downstream process owners; 12. unresolved issues; 13. permitted and prohibited claims; 14. correction and withdrawal conditions. **17.3.6.4** A Project SPV shall not treat participation by community, Indigenous, civil society, diaspora, youth, accessibility, or safeguard contributors as consent, approval, social license, protected knowledge authorization, land access, cultural approval, environmental approval, rights-holder approval, or project authorization. **17.3.6.5** Where lawful consultation, accommodation, FPIC, consent, environmental review, social review, land approval, cultural approval, data authorization, protected knowledge authorization, or local authorization is required, the Project SPV shall pursue such process separately through competent and lawful channels. **17.3.6.6** Safeguard dependencies shall remain attached to SPV finance, procurement, provider, public authority, insurance, donor, development, and implementation records. **17.3.6.7** SPV Safeguard Dependency records shall be correctionable. If safeguards are stripped, weakened, used as consent, publicly exposed beyond permission, omitted from downstream records, or used to imply approval or execution, the SPV record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.7 SPV Procurement Dependencies **17.3.7.1** **SPV Procurement Dependencies** shall mean the lawful procurement, competition, contracting, transparency, conflicts, public authority, provider-selection, value-for-money, integrity, anti-corruption, data, cyber, safeguard, finance, insurance, and project governance conditions that may apply before a Project SPV can select providers, vendors, operators, contractors, consultants, technology actors, platforms, manufacturers, infrastructure actors, or other counterparties. **17.3.7.2** Procurement Dependencies shall not be satisfied by Nexus participation, provider-neutral mapping, technical demonstrations, sponsor support, public authority learning rooms, National Model references, Regional Cluster Program Plan references, AEP Passport candidate input, Nexus Rail routeability, Docket input, Grid input, or Nexus Universe visibility. **17.3.7.3** A Project SPV procurement record shall identify, as applicable: 1. procurement law or policy requirements; 2. procurement authority or governance body; 3. competitive process requirements; 4. conflict and related-party controls; 5. provider-neutral source record limitations; 6. technical diligence requirements; 7. finance and insurance dependencies; 8. public authority dependencies; 9. safeguard dependencies; 10. data and cybersecurity conditions; 11. transparency and confidentiality rules; 12. prohibited claims; 13. correction and challenge pathways. **17.3.7.4** A Project SPV shall not use public-good records to shortcut procurement. Participation in Nexus shall not create preferred-provider status, shortlist status, award status, qualification status, procurement eligibility, or procurement advantage unless a separate lawful procurement process creates such status. **17.3.7.5** Sponsor-provider conflicts shall receive heightened review. A sponsor that is also a provider, investor, host, operator, public authority participant, or handoff recipient shall not use sponsorship or Nexus visibility to influence procurement. **17.3.7.6** Procurement communications shall distinguish public-good participation from procurement status. **17.3.7.7** SPV Procurement Dependency records shall be correctionable. If Nexus participation is used as procurement advantage, provider validation, public authority approval, financeability, certification, consent, project authorization, or execution authority, the procurement record and claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.8 SPV Handoff Conditions **17.3.8.1** **SPV Handoff Conditions** shall be the conditions under which a public-good record or National Consortium Company enterprise review record may be transmitted to a Project SPV or potential Project SPV for separate lawful review, diligence, structuring, governance, finance, insurance, procurement, public authority, safeguard, environmental, data, cyber, contractual, or implementation consideration. **17.3.8.2** SPV handoff shall require a lawful handoff trigger, Handoff Readiness Record or equivalent, recipient identification, purpose of transmission, source-record validation, limitation preservation, safeguard attachment, public authority dependency statement, finance and procurement dependency statement, provider-neutrality statement, data and cyber review where applicable, claims permission review, and correction pathway. **17.3.8.3** SPV Handoff Conditions shall identify whether the handoff is: 1. informational; 2. SPV-readiness review; 3. public authority dependency review; 4. finance-readiness review; 5. insurance-readiness review; 6. donor or development relevance review; 7. procurement-neutral review; 8. provider-neutral capability review; 9. safeguard review; 10. technical review; 11. enterprise structuring review; 12. not for further routing without permission. **17.3.8.4** SPV handoff shall not create project authorization. Transmission of a record to a Project SPV shall not mean the project exists, is approved, is financeable, is insurable, is procured, has selected providers, has public authority approval, has consent, is permitted, is AEP Passported, is Nexus-ready, is Nexus Node-approved, or is execution-ready. **17.3.8.5** A Project SPV receiving a handoff shall acknowledge limitation language and shall not use the public-good record beyond permitted scope. **17.3.8.6** SPV Handoff Conditions shall remain enforceable through correction, restriction, withdrawal, supersession, recipient notice, and archive notation. **17.3.8.7** SPV Handoff Condition records shall be correctionable. If handoff is premature, misrouted, used as approval, stripped of safeguards, used as financeability, used as provider validation, used as consent, or used as execution authority, the handoff record and SPV records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.9 SPV Claims Discipline **17.3.9.1** **SPV Claims Discipline** shall govern all statements by or about a Project SPV concerning its relationship to Nexus, a National Nexus Consortium, Regional Headquarters Consortium, Global Nexus Consortium, National Consortium Company, GCRI, GRF, GRA, Nexus Universe, National Models, Regional Cluster Program Plans, AEP Passport, Nexus Rail, Docket, Grid, public-safe reports, sponsors, providers, public authorities, capital readers, communities, Indigenous actors where applicable, and handoff records. **17.3.9.2** SPV claims shall be valid only if grounded in a controlling record identifying role, scope, project or portfolio, country, term, pathway, public-safe listing permission, permitted language, prohibited language, limitations, public authority boundaries, finance boundaries, provider boundaries, procurement boundaries, safeguard boundaries, correction status, and archive status. **17.3.9.3** A Project SPV shall not claim that it is approved, certified, financeable, bankable, insurable, public-authority-approved, procurement-approved, provider-validated, consented, permitted, AEP Passported, Nexus-ready, Nexus Node-approved, Docket-resolved, Grid-approved, or execution-authorized by reason of Nexus participation or public-good handoff. **17.3.9.4** A Project SPV shall not describe public-good outputs as project approvals, investment pipelines, procurement pipelines, official government programs, certified assets, consented projects, public finance allocations, insurance-approved projects, donor-approved projects, or execution mandates unless such status is separately created by a competent lawful process and accurately recorded. **17.3.9.5** SPV claims involving sponsors, providers, public authorities, capital readers, insurers, donors, development actors, communities, Indigenous actors where applicable, media, or National Consortium Companies shall receive heightened review to prevent endorsement, finance, procurement, consent, or execution overclaim. **17.3.9.6** SPV claims shall distinguish public-good source records, National Consortium Company enterprise analysis, SPV diligence, public authority processes, finance processes, procurement processes, safeguard processes, and execution decisions. **17.3.9.7** SPV Claims Discipline records shall be correctionable. If an SPV claim exceeds the record, omits limitations, creates reliance, implies public authority approval, creates finance signaling, implies provider validation, implies consent, or suggests execution without lawful basis, the claim shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived. *** #### 17.3.10 SPV Correction **17.3.10.1** **SPV Correction** shall be the mandatory process through which Project SPV records, claims, public-good handoff references, National Consortium Company references, public authority references, finance references, insurance references, donor references, development references, public finance references, provider references, procurement references, safeguard references, Nexus Universe references, National Model references, Regional Cluster Program Plan references, AEP Passport references, Nexus Rail references, Docket references, Grid references, and downstream communications are corrected, restricted, withdrawn, superseded, publicly clarified where necessary, renewed, or archived. **17.3.10.2** SPV Correction may be triggered by public-good source correction, Company correction, handoff correction, public authority overclaim, finance overclaim, insurance overclaim, donor or development overclaim, public finance overclaim, provider validation, certification drift, procurement implication, consent overclaim, protected knowledge exposure, safeguard omission, conflict non-disclosure, sponsor capture, provider capture, market reliance, public-safe reporting error, project overclaim, or execution implication. **17.3.10.3** SPV Correction measures may include internal record amendment, board notice, downstream recipient notice, investor-material correction, insurer-material correction, donor-material correction, development-material correction, public finance-material correction, procurement-material correction, provider-material correction, public authority-material correction, safeguard reattachment, handoff restriction, public-safe clarification, claim withdrawal, public listing correction, suspension of reliance, withdrawal of reference, supersession, and archive notation. **17.3.10.4** A Project SPV shall comply with correction notices issued by relevant public-good record owners and National Consortium Company records where applicable and shall not continue using corrected, withdrawn, superseded, or restricted public-good records as current support. **17.3.10.5** SPV Correction shall preserve confidentiality and public-safe discipline. Correcting SPV records shall not expose sensitive public authority information, finance-sensitive information, provider-sensitive information, sponsor-sensitive information, community-sensitive information, Indigenous-sensitive information where applicable, protected knowledge, cyber-sensitive information, infrastructure-sensitive information, security-sensitive information, health-sensitive information, humanitarian-sensitive information, or not-for-publication information. **17.3.10.6** SPV Correction shall be continuous and retroactive. An SPV claim shall not become valid by repetition, investor use, sponsor use, provider use, public authority reference, Nexus Universe visibility, media circulation, archive, administrative convenience, transaction momentum, or passage of time. **17.3.10.7** SPV Correction records shall themselves be correctionable. If a correction is incomplete, wrong, unsafe, not implemented, publicized beyond permission, or fails to correct the underlying overclaim, the correction record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived. --- # 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/charter/xvii.-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.