# XXII. HANDOFF

Nexus Agile Framework Handoff defines the **NAF lawful handoff and enterprise interface model** for controlled context transfer, downstream diligence, National Consortium Companies, Project SPVs, procurement neutrality, finance-readiness, and recipient responsibility. This section explains how **handoff packages, dependency records, evidence transfer, recipient classes, and correction pathways** move public-good outputs into lawful downstream environments without creating approval, procurement status, financeability, consent, deployment authority, or execution.

This section sets the operating model for **handoff doctrine**, **handoff package architecture**, **lawful recipients**, **finance-readiness without finance**, and **handoff governance boundaries**. It helps Nexus route evidence, methods, Studio context, Grid and TRL context, and public-safe records into downstream diligence while preserving provider neutrality, sponsor boundaries, public authority boundaries, recipient accountability, and non-executing discipline.

### What this section covers

* Lawful handoff doctrine, package structure, and recipient responsibilities.
* Finance-readiness, procurement neutrality, and public authority boundaries in downstream use.
* Governance controls that keep handoff recorded, correctionable, and non-executing.

Use this section with the [NAF overview](/organization/operations/frameworks/nexus-agile-framework-naf.md), [XV. GRID](/organization/operations/frameworks/nexus-agile-framework-naf/xv.-grid.md), [XVI. REGISTRY](/organization/operations/frameworks/nexus-agile-framework-naf/xvi.-registry.md), [XVII. REPORTS](/organization/operations/frameworks/nexus-agile-framework-naf/xvii.-reports.md), [XX. UNIVERSE](/organization/operations/frameworks/nexus-agile-framework-naf/xx.-universe.md), and [XXI. AGENCY](/organization/operations/frameworks/nexus-agile-framework-naf/xxi.-agency.md) to connect handoff packages with readiness evidence, records, reporting, advisory support, and lawful downstream routing.

## 22.1 Handoff Doctrine

### 22.1.1 Handoff Defined.

22.1.1.1 Handoff shall mean the controlled, recorded, bounded, and correctionable transfer of public-good context from NAF into a lawful downstream environment where competent actors may independently evaluate, adopt, procure, finance, insure, authorize, contract, implement, deploy, operate, maintain, regulate, or execute according to their own legal authority, diligence, governance, procurement, finance, insurance, consent, professional, technical, and operational responsibilities.

22.1.1.2 Handoff shall not be a project approval, procurement recommendation, investment recommendation, insurance approval, public finance allocation, public authority decision, public warning, consent determination, deployment authorization, technical certification, maturity certification, provider validation, sponsor endorsement, warranty, service-level commitment, operational instruction, or execution command. It shall be a boundary-preserving bridge from public-good records to lawful downstream responsibility.

22.1.1.3 Handoff may occur only where the relevant evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive linkage have been recorded at a level appropriate to the handoff class.

22.1.1.4 Handoff shall preserve the one-rail, two-stacks discipline of NAF. The public-good stack may produce evidence, learning, records, Reports, Registry status, Marketplace discovery, Studio workflows, Grid inputs, TRL notes, National Portfolio memory, Nexus Universe outputs, and handoff dependency packages. The enterprise stack, public authority stack, finance stack, insurance stack, procurement stack, community-consent stack, and implementation stack shall remain separate unless a competent lawful actor separately and expressly assumes responsibility within its own authority.

### 22.1.2 Handoff as Context Transfer.

22.1.2.1 Handoff shall transfer context, not control. Context may include what was observed, studied, built, reviewed, tested within scope, simulated, classified, recorded, corrected, published, listed, registered, demonstrated, or prepared through NAF.

22.1.2.2 Context transfer may include Reports, evidence packs, method notes, data availability statements, AI-use statements, model cards, system cards, benchmark cards, agent workflow cards, Studio workflow records, Grid inputs, TRL evidence notes, DRI summaries, GRIx mappings, Observatory records, Campaign records, Academy records, Foundry build records, Marketplace listings, Registry records, National Portfolio records, Nexus Universe records, and correction records.

22.1.2.3 Context transfer shall include scope limits, assumptions, dependencies, exclusions, uncertainty, confidence labels where applicable, public-safe status, data restrictions, AI-use restrictions, cyber restrictions, privacy restrictions, safeguard status, protected knowledge restrictions, support class, release class, and reliance label.

22.1.2.4 Context transfer shall not allow a recipient to claim that Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, a Nexus Consortium, a National Node, a Working Group, a Competence Cell, a Campaign, a Foundry team, a reviewer, a maintainer, a sponsor, a provider, a public authority learning participant, or any other NAF participant has approved, endorsed, certified, financed, insured, procured, consented to, deployed, or executed the downstream activity unless separately and lawfully recorded.

### 22.1.3 Handoff as Dependency Transfer.

22.1.3.1 Handoff shall transfer dependencies by making explicit what must be resolved outside NAF before any lawful downstream action may occur. Dependencies may include public authority approvals, permits, licenses, procurement steps, contracting steps, professional review, engineering sign-off, safety review, cybersecurity review, privacy assessment, data rights, cross-border transfer review, community process, Indigenous protocol process where applicable, protected knowledge permission, insurance diligence, finance diligence, donor diligence, public finance process, environmental review, labor review, operational readiness, and implementation governance.

22.1.3.2 Dependency transfer shall be recorded through Dependency Registers, Assumptions Registers, Diligence-Gap Registers, Handoff Dependency Registers, public authority dependency notes, legal dependency notes, finance and insurance question notes, procurement boundary notes, safeguard dependency notes, recipient responsibility notes, correction pathways, recall pathways, and archive records.

22.1.3.3 A dependency record shall not mean the dependency has been satisfied. It shall mean the dependency has been identified, described, routed, and preserved for downstream diligence.

22.1.3.4 No unresolved dependency shall be treated as waived by reason of NAF participation, Nexus Universe visibility, Marketplace listing, Registry status, Grid input, TRL note, Report publication, Studio demonstration, Campaign success, public authority attendance, sponsor support, provider contribution, capital-reader interest, insurance-reader interest, donor interest, community participation, or National Portfolio inclusion.

### 22.1.4 Handoff as Evidence Transfer.

22.1.4.1 Handoff may transfer evidence within recorded scope. Evidence may include research records, testbed records, method notes, datasets, metadata, model cards, system cards, benchmark records, software records, dashboard records, Studio workflow outputs, simulation notes, digital twin assumptions, DRI indicator records, GRIx category mappings, Observatory signals, review records, public-safe summaries, Grid inputs, TRL evidence notes, Reports, Registry records, Marketplace records, and correction records.

22.1.4.2 Evidence transfer shall include evidence sufficiency status, method sufficiency status, data sufficiency status, AI-use sufficiency status, cyber sufficiency status, privacy sufficiency status, safeguard sufficiency status, reproducibility status, support status, limitations, assumptions, dependencies, and correction history.

22.1.4.3 Evidence transfer shall not convert evidence into approval. Evidence may inform downstream diligence, but it shall not substitute for regulatory approval, public authority decision, procurement evaluation, finance diligence, underwriting, professional certification, safety approval, community consent, Indigenous consent where applicable, or deployment authorization.

22.1.4.4 Evidence transferred through handoff shall remain subject to correction, withdrawal, recall, supersession, archive, and non-continuation where error, overclaim, changed conditions, safeguard concerns, data issues, AI issues, cyber issues, privacy issues, public-safe issues, protected knowledge issues, public authority boundary issues, finance boundary issues, procurement boundary issues, consent boundary issues, deployment boundary issues, or execution boundary issues arise.

### 22.1.5 Handoff as Recipient Responsibility.

22.1.5.1 Handoff shall place responsibility on the recipient to determine whether and how to use the transferred context, dependencies, evidence, records, outputs, or notes. The recipient shall remain responsible for independent diligence, legal authority, procurement, finance, insurance, contracting, permits, licenses, approvals, consents, professional review, cybersecurity, privacy, data rights, safeguards, deployment, operations, maintenance, monitoring, correction, and execution.

22.1.5.2 Recipient responsibility shall apply to National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, funders, insurers, donors, universities, labs, community actors where appropriate, and other competent lawful actors.

22.1.5.3 No recipient may rely on a handoff package as a substitute for its own governance, diligence, technical review, legal review, financial review, insurance review, procurement review, public authority process, consent process, professional responsibility, operating responsibility, or implementation accountability.

22.1.5.4 Recipient misuse, overclaim, misrepresentation, unsafe reliance, failure to correct, improper public claim, provider validation claim, sponsor control claim, procurement overclaim, finance overclaim, insurance overclaim, public authority overclaim, consent overclaim, deployment overclaim, or execution overclaim may trigger Handoff Correction, Handoff Recall, Registry update, Marketplace delisting, public-safe notice, Report correction, archive update, and downstream notice where appropriate.

### 22.1.6 Handoff Without Authority Transfer.

22.1.6.1 Handoff shall not transfer authority from Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, Nexus Consortiums, National Nodes, Working Groups, Competence Cells, Foundry teams, Campaigns, Academy programs, Risk Agency experts, Labs, reviewers, maintainers, sponsors, providers, public authority learning participants, or any NAF participant to a recipient.

22.1.6.2 Handoff shall not create agency, partnership, joint venture, fiduciary duty, public authority delegation, procurement authority, finance authority, insurance authority, standards authority, certification authority, consent authority, deployment authority, operational control, or execution authority by implication.

22.1.6.3 Any authority required for downstream activity shall arise only from the recipient’s own lawful status, public authority process, corporate authority, contractual authority, professional authority, regulatory authorization, procurement award, finance documentation, insurance documentation, consent record, permit, license, approval, operational mandate, or other competent legal basis outside NAF.

22.1.6.4 Handoff documents shall include express no-authority-transfer notices and shall identify the separate authority pathways required for downstream action.

### 22.1.7 Handoff Without Execution by Nexus.

22.1.7.1 Nexus shall not execute through handoff. NAF may prepare, record, package, route, explain, publish, list, register, demonstrate, review, correct, recall, and archive handoff context, but shall not become the downstream executor by reason of those activities.

22.1.7.2 Handoff shall not cause Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, a Nexus Consortium, a National Node, a Working Group, a Competence Cell, a Foundry team, a Campaign, a Risk Agency expert, a reviewer, a maintainer, a sponsor, a provider, or a public authority learning participant to become project developer, contractor, operator, funder, lender, insurer, broker, underwriter, public authority, procurement body, consent body, emergency command body, deployment authority, or execution vehicle.

22.1.7.3 If a downstream actor seeks implementation services, operational services, finance, insurance, procurement, public authority action, legal advice, professional services, engineering sign-off, cybersecurity certification, data processing, field deployment, construction, integration, emergency response, or execution, that activity must be separately structured outside NAF’s default handoff posture through competent lawful actors.

22.1.7.4 The absence of execution by Nexus shall not prevent lawful recipients from using NAF outputs as context for independent action, provided that all boundary notices, legal requirements, data restrictions, safeguard requirements, public authority dependencies, procurement rules, finance rules, insurance rules, consent requirements, deployment requirements, and correction obligations are respected.

### 22.1.8 Handoff as Controlled Public-Good-to-Enterprise Bridge.

22.1.8.1 Handoff shall be the controlled bridge between the public-good stack and lawful downstream action. It shall permit the public-good stack to inform enterprise, public authority, finance, insurance, donor, university, community, and implementation environments without collapsing public-good legitimacy into enterprise execution.

22.1.8.2 The bridge shall be controlled by Handoff Intake, Handoff Classification, Handoff Review, Handoff Recipient Records, Handoff Dependency Registers, Handoff Correction, Handoff Recall, Handoff Archive, no-conversion rules, public-safe notices, procurement-neutrality notices, finance-readiness notices, public authority notices, consent notices, sponsor-boundary notices, provider-neutrality notices, and execution-boundary notices.

22.1.8.3 The bridge shall be open enough to make evidence useful and controlled enough to prevent overclaim, capture, enclosure, misrepresentation, unsafe reliance, procurement distortion, finance distortion, insurance distortion, public authority confusion, consent overclaim, deployment overclaim, or execution by implication.

22.1.8.4 Handoff shall be successful when it makes downstream responsibility clearer, not when it makes Nexus appear to have approved or executed the downstream activity.

## 22.2 Handoff Package Architecture

### 22.2.1 Evidence Context.

22.2.1.1 Each Handoff Package shall include Evidence Context sufficient to describe the evidence basis of the package within scope. Evidence Context may include research records, evidence packs, method notes, testbed records, review records, data records, model records, software records, dashboard records, Studio records, DRI records, GRIx records, Observatory records, Grid inputs, TRL notes, Reports, Registry status, Marketplace status, Nexus Universe records, and correction history.

22.2.1.2 Evidence Context shall identify evidence class, source class, review status, sufficiency status, limitations, assumptions, dependencies, exclusions, confidence labels where applicable, uncertainty labels where applicable, reproducibility status, support status, release class, public-safe status, and archive rule.

22.2.1.3 Evidence Context shall not create approval, certification, public authority decision, procurement readiness, financeability, insurability, provider validation, deployment authorization, or execution.

### 22.2.2 Data Context.

22.2.2.1 Each Handoff Package shall include Data Context where data is relevant. Data Context shall identify data sources, metadata, lineage, rights review, sensitivity class, data-use labels, AI-use labels, access class, public-safe transformation status, retention rules, deletion or sealing rules, cross-border controls, data sovereignty issues, data localization issues, privacy issues, youth data issues, health data issues, cyber-sensitive data issues, infrastructure-sensitive data issues, geospatial-sensitive data issues, community-sensitive data issues, Indigenous protocol-sensitive data where applicable, protected knowledge, and archive status.

22.2.2.2 Data Context may include open data, public-safe data, controlled public data, restricted data, public authority-sensitive data, community-sensitive data, protected knowledge, handoff-recipient-only data, archive-only data, metadata-only records, synthetic data, aggregated data, or secure-room outputs.

22.2.2.3 Data Context shall not create data rights, open data permission, AI training permission, public authority approval, handoff permission, unrestricted reuse, deployment authorization, or execution.

### 22.2.3 Method Context.

22.2.3.1 Each Handoff Package shall include Method Context sufficient to explain the methods used, including research design, data processing, analytical approach, model approach, DRI method, GRIx mapping method, Observatory method, Studio workflow method, simulation method, digital twin assumptions, evaluation method, review method, public-safe transformation method, safeguard review method, and correction method.

22.2.3.2 Method Context shall identify scope, assumptions, limitations, intended use, prohibited use, review status, reproducibility status, standards-aware mappings where applicable, conformance questions where applicable, and method correction history.

22.2.3.3 Method Context shall not create method certification, standards conformance, regulatory approval, professional approval, public authority decision, procurement status, financeability, deployment authorization, or execution.

### 22.2.4 Studio Context.

22.2.4.1 Each Handoff Package that involves Studio workflows shall include Studio Context, including dashboard workflow records, digital twin workflow records, scenario workflow records, AI workflow review records, data-room workflow records, secure-room workflow records, public authority learning workflow records, readiness-room workflow records, capital-reader room workflow records, insurance-reader room workflow records, Nexus Universe workflow records, and handoff demonstration workflow records where applicable.

22.2.4.2 Studio Context shall identify data basis, model basis, assumptions, uncertainty, confidence, sensitivity, limitations, scenario scope, public-safe interpretation, access controls, role-based permissions, no-write-back rules, no-command rules, output review, logging, AI-use restrictions, data export restrictions, shutdown triggers, correction triggers, and archive rules.

22.2.4.3 Studio Context shall not create deployment authorization, operational command, public authority decision, AI determination, finance approval, underwriting approval, certification, or execution.

### 22.2.5 Grid and TRL Context.

22.2.5.1 Each Handoff Package shall include Grid and TRL Context where readiness information is relevant. Grid and TRL Context shall identify Grid inputs, TRL 1–10 evidence notes, evidence sufficiency, method sufficiency, data sufficiency, AI-use sufficiency, cyber sufficiency, public-safe sufficiency, safeguard sufficiency, support sufficiency, reproducibility sufficiency, correction sufficiency, readiness class, review gates, downgrade triggers, suspension triggers, withdrawal triggers, reinstatement conditions, correction propagation, public-safe notices, and handoff recall status.

22.2.5.2 TRL Context shall identify scope and shall not be generalized beyond the recorded system, environment, evidence basis, and review class.

22.2.5.3 Grid and TRL Context shall not create certification, maturity certification, procurement readiness, financeability, insurability, public authority approval, deployment authorization, or execution.

### 22.2.6 Public-Safe Status.

22.2.6.1 Each Handoff Package shall include Public-Safe Status, including release class, audience class, no-warning language, no-approval language, no-finance language, no-procurement language, no-certification language, no-consent language, no-deployment language, no-execution language, sensitive geospatial controls, cyber-sensitive controls, biosecurity-sensitive controls, protected knowledge controls, privacy controls, youth controls, accessibility controls, translation status, public repair status, and correction notices.

22.2.6.2 Public-Safe Status shall define what may be disclosed, to whom, in what form, with what limitations, under what correction pathway, and with what archive rule.

22.2.6.3 Public-Safe Status shall not convert a controlled, restricted, or handoff-recipient-only object into a public object.

### 22.2.7 Safeguard Status.

22.2.7.1 Each Handoff Package shall include Safeguard Status where affected stakeholders, communities, Indigenous institutions where applicable, protected knowledge, youth, disability inclusion, accessibility, humanitarian sensitivity, privacy, rights, public interest, or non-extractive engagement issues are present.

22.2.7.2 Safeguard Status shall identify community safeguards, Indigenous protocols where applicable, protected knowledge controls, youth safeguards, disability inclusion needs, accessibility needs, humanitarian sensitivity, public-interest participation, community-facing correction, consent boundary status, and unresolved safeguard dependencies.

22.2.7.3 Safeguard Status shall not constitute community consent, Indigenous consent where applicable, rights clearance, legal approval, public authority approval, deployment authorization, or execution.

### 22.2.8 Public Authority Dependencies.

22.2.8.1 Each Handoff Package shall identify Public Authority Dependencies where downstream action may require public authority review, approval, permit, license, regulation, procurement decision, public finance allocation, emergency command, public warning, data access, infrastructure access, environmental review, public health review, safety review, or other official action.

22.2.8.2 Public Authority Dependencies shall distinguish public authority learning from public authority action. A public authority learning record may be included, but it shall not be represented as official action.

22.2.8.3 Public Authority Dependencies shall remain unresolved unless a competent public authority separately and lawfully records the relevant action outside NAF.

### 22.2.9 Legal Dependencies.

22.2.9.1 Each Handoff Package shall identify Legal Dependencies where downstream use may require corporate authority, contractual authority, IP rights, license rights, data rights, privacy review, cross-border transfer authorization, labor review, professional authorization, engineering review, cybersecurity review, environmental review, health review, community process, Indigenous protocol process where applicable, procurement authority, finance authority, insurance authority, public authority approval, or other legal basis.

22.2.9.2 Legal Dependencies shall be recorded as dependencies, not legal determinations by default. Unless separately stated under an authorized legal engagement, NAF outputs shall not constitute legal advice, legal opinion, compliance determination, or legal clearance.

22.2.9.3 Legal Dependencies shall remain the responsibility of the recipient and competent lawful actors.

### 22.2.10 Finance and Insurance Questions.

22.2.10.1 Each Handoff Package may include Finance and Insurance Questions where relevant, including capital-readability, insurance-readiness, donor-readiness, public finance relevance, protection gaps, risk layering, assumptions, dependencies, diligence gaps, no-reliance statements, non-solicitation status, non-transactionality status, and regulated-perimeter issues.

22.2.10.2 Finance and Insurance Questions shall support literacy and diligence preparation, not finance execution or underwriting.

22.2.10.3 Finance and Insurance Questions shall not constitute investment advice, financial advice, securities advice, valuation, bankability determination, financeability determination, underwriting, insurance advice, insurance approval, donor commitment, public finance allocation, procurement decision, or execution.

### 22.2.11 Procurement Boundaries.

22.2.11.1 Each Handoff Package shall include Procurement Boundaries where any provider, supplier, vendor, contractor, sponsor, Marketplace listing, software object, data object, Studio workflow, Grid input, TRL note, Report, demonstration, or implementation pathway may be misread as procurement status.

22.2.11.2 Procurement Boundaries shall include no preferred provider, no procurement recommendation, no supplier approval, no vendor validation, no tender support by implication, independent diligence required, provider contribution controls, Marketplace listing controls, and public authority procurement dependency notes.

22.2.11.3 Procurement Boundaries shall prevent use of NAF outputs as procurement shortcuts, vendor approvals, technical approvals, tender endorsements, supplier rankings, or procurement specifications unless separately and lawfully adopted by a competent procurement authority outside NAF.

### 22.2.12 Provider-Neutrality Notes.

22.2.12.1 Each Handoff Package shall include Provider-Neutrality Notes where providers, technical contributors, software contributors, cloud contributors, data contributors, infrastructure contributors, sponsors, vendors, contractors, consultants, or implementation actors are referenced.

22.2.12.2 Provider-Neutrality Notes shall identify provider contribution, review status, support class, conflicts, restrictions, non-validation status, no-preference status, and independent diligence requirements.

22.2.12.3 Provider-Neutrality Notes shall not validate providers, approve vendors, recommend suppliers, certify technologies, create procurement status, create financeability, create public authority approval, or authorize deployment.

### 22.2.13 Sponsor-Boundary Notes.

22.2.13.1 Each Handoff Package shall include Sponsor-Boundary Notes where sponsors, funders, supporters, hosts, in-kind contributors, infrastructure supporters, venue supporters, cloud supporters, compute supporters, media supporters, or other supporters are referenced.

22.2.13.2 Sponsor-Boundary Notes shall identify support type, support restrictions, acknowledgement rules, conflict review, no-control status, public display status, use limitations, correction pathway, and archive rule.

22.2.13.3 Sponsor-Boundary Notes shall not create sponsor control, governance rights, editorial rights, procurement preference, provider validation, financeability, public authority approval, consent, deployment authorization, or execution.

### 22.2.14 Recipient Responsibilities.

22.2.14.1 Each Handoff Package shall include Recipient Responsibilities. Recipient Responsibilities shall state that the recipient is responsible for independent diligence, legal authority, procurement, finance, insurance, contracting, permits, licenses, approvals, consents, professional review, engineering review, cybersecurity review, privacy review, data rights, safeguards, deployment, operations, maintenance, monitoring, correction, and execution.

22.2.14.2 Recipient Responsibilities shall also require the recipient to preserve attribution, boundary notices, data restrictions, AI-use restrictions, public-safe status, safeguard status, correction obligations, recall obligations, archive notices, no-conversion rules, provider-neutrality rules, sponsor-boundary rules, and no-overclaim rules.

22.2.14.3 Recipient Responsibilities shall prohibit misrepresentation of NAF outputs as approval, certification, procurement readiness, financeability, insurance approval, public authority action, consent, deployment authorization, or execution.

### 22.2.15 Correction and Recall Pathways.

22.2.15.1 Each Handoff Package shall include Correction and Recall Pathways. These pathways shall specify how errors, changed conditions, unsafe reliance, overclaims, data issues, AI issues, cyber issues, privacy issues, public-safe issues, protected knowledge issues, safeguard concerns, public authority boundary incidents, finance boundary incidents, procurement boundary incidents, provider validation incidents, sponsor control incidents, consent overclaim incidents, handoff overclaim incidents, deployment overclaim incidents, and execution overclaim incidents shall be handled.

22.2.15.2 Correction and Recall Pathways may include notice to recipient, claims freeze, data freeze, technical freeze, Marketplace delisting, Registry status update, Report correction, Studio workflow suspension, Grid downgrade, TRL note revision, handoff recall, public-safe notice, withdrawal, supersession, archive, and non-continuation.

22.2.15.3 Correction and Recall shall preserve trust without converting NAF into the downstream operator. Recipients shall remain responsible for correcting downstream reliance, downstream claims, downstream implementations, downstream communications, and downstream consequences.

## 22.3 Lawful Recipients

### 22.3.1 National Consortium Companies.

22.3.1.1 National Consortium Companies may be lawful recipients of Handoff Packages where a country-level enterprise-stack vehicle has been separately formed, authorized, governed, and prepared to receive public-good context for lawful downstream diligence, contracting, implementation preparation, or execution outside NAF’s default public-good posture.

22.3.1.2 A National Consortium Company recipient shall remain legally separate from public-good consortiums, GCRI, The Global Risks Forum, The Global Risks Alliance, Nexus pillars, Nexus mechanisms, public authorities, sponsors, providers, and Project SPVs unless a separate lawful relationship is expressly recorded.

22.3.1.3 Handoff to a National Consortium Company shall not create public authority status, procurement award, finance approval, insurance approval, community consent, Indigenous consent where applicable, deployment authorization, or execution by Nexus.

### 22.3.2 Project SPVs.

22.3.2.1 Project SPVs may be lawful recipients of Handoff Packages where a project-level enterprise-stack vehicle has been separately formed, authorized, governed, and prepared to receive public-good context for lawful downstream diligence, contracting, finance, insurance, procurement, implementation, deployment, or operations outside NAF.

22.3.2.2 Project SPVs shall remain responsible for their own corporate authority, project governance, finance, insurance, procurement, permits, licenses, approvals, consents, technical review, engineering review, cybersecurity, privacy, data rights, safeguards, deployment, operations, maintenance, and execution.

22.3.2.3 Handoff to a Project SPV shall not make Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, a Nexus Consortium, a National Node, a Working Group, a Competence Cell, a sponsor, a provider, a reviewer, or a maintainer responsible for project execution.

### 22.3.3 Public Authorities.

22.3.3.1 Public authorities may be lawful recipients of Handoff Packages for learning, evidence review, public-good context, policy learning, resilience planning, public finance learning, procurement learning, public-safe reporting, DRI interpretation, GRIx interpretation, Observatory interpretation, Studio scenario learning, Grid and TRL context, National Portfolio review, and lawful downstream public authority process.

22.3.3.2 Handoff to public authorities shall distinguish public authority learning from official action. Official action must occur through competent public authority processes outside NAF unless separately and lawfully recorded.

22.3.3.3 Handoff to public authorities shall not create public authority approval, public warning, emergency command, permit, license, regulation, public finance allocation, procurement decision, official adoption, deployment authorization, or execution by implication.

### 22.3.4 Providers.

22.3.4.1 Providers may be lawful recipients of Handoff Packages where they require context to understand public-good evidence, data restrictions, technical needs, Studio workflows, Grid inputs, TRL context, public-safe status, safeguard status, public authority dependencies, procurement boundaries, provider-neutrality requirements, sponsor-boundary requirements, and downstream diligence responsibilities.

22.3.4.2 Provider receipt of a Handoff Package shall not validate the provider, approve the provider, prefer the provider, certify the provider, recommend procurement, authorize deployment, or imply that the provider has any special status.

22.3.4.3 Providers shall remain responsible for their own products, services, warranties, contracts, professional obligations, security, privacy, data rights, compliance, implementation, operations, and execution.

### 22.3.5 Operators.

22.3.5.1 Operators may be lawful recipients where operational context, technical context, readiness context, safety dependencies, cyber dependencies, data dependencies, public authority dependencies, safeguard dependencies, deployment dependencies, maintenance dependencies, or correction dependencies must be understood before lawful operations.

22.3.5.2 Operators shall remain responsible for operational readiness, operational safety, workforce readiness, permits, approvals, cybersecurity, privacy, service levels, incident response, maintenance, monitoring, user support, and operational execution.

22.3.5.3 Handoff to operators shall not create operational authorization, service-level warranty, public authority approval, procurement award, financeability, insurance approval, consent, deployment authorization, or execution by Nexus.

### 22.3.6 Contractors.

22.3.6.1 Contractors may be lawful recipients where handoff context is needed to support independent contracting, implementation planning, technical review, procurement response, project scoping, risk review, safeguard review, or downstream execution outside NAF.

22.3.6.2 Contractor receipt of a Handoff Package shall not constitute procurement award, tender support, supplier approval, vendor validation, technical certification, public authority approval, financeability, insurance approval, deployment authorization, or execution by Nexus.

22.3.6.3 Contractors shall remain responsible for their own contracts, qualifications, permits, professional duties, safety obligations, labor obligations, insurance, warranties, performance, and execution.

### 22.3.7 Funders.

22.3.7.1 Funders may be lawful recipients where handoff context supports no-reliance learning, diligence questions, public-good context, National Portfolio understanding, readiness question review, assumptions review, dependency review, diligence-gap review, and lawful downstream finance processes outside NAF.

22.3.7.2 Funder receipt of a Handoff Package shall not constitute solicitation, investment advice, financial advice, valuation, bankability determination, financeability determination, public finance allocation, donor commitment, grant approval, or transaction.

22.3.7.3 Funders shall remain responsible for their own diligence, legal authority, investment processes, grant processes, finance processes, public finance processes, regulated obligations, documentation, approvals, and decisions.

### 22.3.8 Insurers.

22.3.8.1 Insurers may be lawful recipients where handoff context supports no-reliance learning, insurance-readiness questions, DRF context, DRI context, assumptions review, dependency review, diligence-gap review, National Portfolio context, public-safe Reports, and lawful downstream insurance or reinsurance processes outside NAF.

22.3.8.2 Insurer receipt of a Handoff Package shall not constitute underwriting, insurance advice, coverage approval, risk score, premium indication, insurability determination, actuarial certification, or commitment.

22.3.8.3 Insurers shall remain responsible for their own underwriting, regulated obligations, actuarial processes, coverage decisions, policy documents, claims processes, and insurance execution.

### 22.3.9 Donors.

22.3.9.1 Donors may be lawful recipients where handoff context supports public-good learning, support planning, grant-readiness questions, donor-readiness questions, Campaign support context, National Portfolio context, Nexus Universe context, Academy context, Foundry context, Reports context, and lawful support processes outside NAF.

22.3.9.2 Donor receipt of a Handoff Package shall not constitute donor commitment, grant approval, financeability, public finance allocation, procurement status, public authority approval, consent, deployment authorization, or execution.

22.3.9.3 Donors shall remain responsible for their own grant processes, diligence, support decisions, restrictions, reporting, legal compliance, and funding documentation.

### 22.3.10 Universities and Labs.

22.3.10.1 Universities and Labs may be lawful recipients where handoff context supports research translation, Labs continuation, Academy pathways, WILPs, micro-credentials, public-safe publication, data governance, AI governance, cyber and privacy review, ethical review, protected knowledge controls, Foundry routing, Reports routing, and National Portfolio support.

22.3.10.2 University and Lab receipt of a Handoff Package shall not constitute research ethics approval, academic credit, professional qualification, technology approval, public authority approval, procurement status, financeability, consent, deployment authorization, or execution.

22.3.10.3 Universities and Labs shall remain responsible for their own ethics, governance, academic standards, research compliance, data rights, IP rights, employment status, student safeguards, fieldwork safety, and institutional decisions.

### 22.3.11 Community Actors Where Appropriate.

22.3.11.1 Community actors may be lawful recipients where handoff context supports community learning, public-safe communication, safeguard review, local resilience planning, Campaign participation, National Portfolio input, protected knowledge handling, correction, or downstream community-led processes.

22.3.11.2 Handoff to community actors shall be non-extractive, privacy-protective, accessibility-aware, language-aware, safeguard-aware, and sensitive to community governance, Indigenous protocols where applicable, protected knowledge, youth safeguards, disability inclusion, humanitarian sensitivity, and consent boundaries.

22.3.11.3 Community actor receipt of a Handoff Package shall not constitute community consent, Indigenous consent where applicable, public authority approval, procurement status, financeability, deployment authorization, or execution.

### 22.3.12 Other Competent Lawful Actors.

22.3.12.1 Other competent lawful actors may receive Handoff Packages where their role, authority, responsibility, jurisdiction, capability, and lawful basis are recorded.

22.3.12.2 Such actors may include regulated professionals, standards-interface actors, humanitarian organizations, utilities, infrastructure operators, emergency management bodies, civil society institutions, cooperatives, professional associations, labor organizations, development actors, technology stewards, repository stewards, or other actors capable of receiving context without converting NAF outputs into authority.

22.3.12.3 Handoff to other competent lawful actors shall remain subject to recorded scope, recipient responsibilities, boundary notices, correction pathways, recall pathways, and archive rules.

## 22.4 Finance-Readiness Without Finance

### 22.4.1 Capital-Readability.

22.4.1.1 Capital-readability shall mean the preparation of public-good records in a form that helps capital readers understand context, assumptions, dependencies, diligence gaps, risk questions, evidence status, National Portfolio relevance, public authority dependencies, safeguard status, support status, and handoff conditions.

22.4.1.2 Capital-readability may support structured questions, no-reliance summaries, diligence-gap registers, dependency registers, assumptions registers, public-safe Reports, readiness notes, and handoff dependency packages.

22.4.1.3 Capital-readability shall not constitute investment advice, valuation, bankability determination, financeability determination, solicitation, securities activity, public finance allocation, donor commitment, procurement status, or execution.

### 22.4.2 Insurance-Readiness Questions.

22.4.2.1 Insurance-readiness questions shall identify what insurers or reinsurers may need to understand, review, or independently diligence in relation to risk, resilience, protection gaps, DRI context, assumptions, dependencies, data quality, evidence status, safeguard status, operational readiness, public authority dependencies, and handoff conditions.

22.4.2.2 Insurance-readiness questions may inform literacy and diligence preparation, but shall not determine insurability.

22.4.2.3 Insurance-readiness questions shall not constitute underwriting, risk pricing, coverage approval, premium indication, actuarial certification, insurance advice, insurance score, or insurance commitment.

### 22.4.3 Donor-Readiness Questions.

22.4.3.1 Donor-readiness questions shall identify what donors, foundations, development actors, humanitarian funders, philanthropic actors, or public-good supporters may need to understand before considering support.

22.4.3.2 Donor-readiness questions may include public-good purpose, evidence status, National Portfolio relevance, Campaign relevance, Academy relevance, Foundry relevance, Reports relevance, DICE relevance, DRI relevance, safeguard status, public-safe status, support needs, dependency needs, correction status, and archive status.

22.4.3.3 Donor-readiness questions shall not constitute donor solicitation by default, donor commitment, grant approval, funding approval, financeability, public finance allocation, procurement status, or execution.

### 22.4.4 Public Finance Relevance Questions.

22.4.4.1 Public finance relevance questions shall identify whether and how a public-good record may be relevant to public finance learning, resilience investment learning, DRF learning, protection-gap understanding, public authority learning, National Portfolio development, public finance diligence, or lawful downstream public finance processes.

22.4.4.2 Public finance relevance questions shall include public authority dependencies, legal dependencies, procurement boundaries, budget authority dependencies, public finance process dependencies, safeguard status, evidence status, and no-reliance notices.

22.4.4.3 Public finance relevance questions shall not allocate public funds, approve budgets, approve projects, authorize procurement, create public authority commitments, create financeability, or execute public finance functions.

### 22.4.5 Assumptions Registers.

22.4.5.1 Assumptions Registers shall record assumptions used in evidence, models, scenarios, forecasts, simulations, Studio workflows, Grid inputs, TRL notes, Reports, National Portfolios, finance-readiness questions, insurance-readiness questions, donor-readiness questions, public finance relevance questions, and handoff dependency packages.

22.4.5.2 Assumptions Registers shall identify assumption source, scope, confidence, uncertainty, dependency, review status, sensitivity, correction history, and archive rule.

22.4.5.3 Assumptions Registers shall not transform assumptions into facts, approvals, forecasts of certainty, financeability, insurability, procurement status, public authority decisions, deployment authorization, or execution.

### 22.4.6 Dependency Registers.

22.4.6.1 Dependency Registers shall record technical, legal, public authority, data, AI, cyber, privacy, safeguard, finance, insurance, donor, public finance, procurement, operational, community, Indigenous protocol where applicable, protected knowledge, support, maintenance, correction, and archive dependencies.

22.4.6.2 Dependency Registers shall distinguish identified dependencies from satisfied dependencies.

22.4.6.3 Dependency Registers shall not waive, satisfy, approve, or replace downstream requirements.

### 22.4.7 Diligence-Gap Registers.

22.4.7.1 Diligence-Gap Registers shall identify unresolved questions that downstream recipients, public authorities, funders, insurers, donors, operators, contractors, providers, National Consortium Companies, Project SPVs, universities, labs, communities, or other lawful actors must independently evaluate before acting.

22.4.7.2 Diligence-Gap Registers may include evidence gaps, data gaps, method gaps, AI gaps, cyber gaps, privacy gaps, safeguard gaps, legal gaps, finance gaps, insurance gaps, procurement gaps, operational gaps, consent gaps, deployment gaps, and correction gaps.

22.4.7.3 Diligence-Gap Registers shall not create negative ratings, positive ratings, approval, rejection, financeability, insurability, procurement readiness, public authority decision, consent, deployment authorization, or execution.

### 22.4.8 No-Reliance Statements.

22.4.8.1 No-Reliance Statements shall accompany finance-readiness, insurance-readiness, donor-readiness, public finance relevance, readiness-room, capital-reader room, insurance-reader room, donor-reader room, and handoff context materials.

22.4.8.2 No-Reliance Statements shall state that the materials are for public-good learning, context, diligence preparation, and dependency awareness, and are not investment advice, financial advice, securities advice, valuation, bankability determination, financeability determination, underwriting, insurance advice, donor commitment, grant approval, public finance allocation, procurement decision, legal advice by default, public authority decision, consent, deployment authorization, or execution.

22.4.8.3 No-Reliance Statements shall not remove recipient responsibility for independent diligence, professional review, legal review, finance review, insurance review, procurement review, public authority process, consent process, and execution accountability.

### 22.4.9 Non-Solicitation.

22.4.9.1 Handoff materials shall be non-soliciting by default. They shall not solicit investments, securities transactions, loans, insurance products, donor commitments, public finance allocations, procurement awards, contracts, grants, or other transactions unless a separate lawful process outside NAF expressly authorizes such activity.

22.4.9.2 Non-solicitation shall apply to Reports, Marketplace listings, Registry records, Nexus Universe materials, readiness-room materials, capital-reader room materials, insurance-reader room materials, donor-reader room materials, public finance learning materials, and Handoff Packages.

22.4.9.3 Any solicitation, if lawful and intended, shall be separately prepared, authorized, reviewed, and issued outside NAF’s default public-good handoff posture.

### 22.4.10 Non-Transactionality.

22.4.10.1 Handoff shall be non-transactional by default. It shall not close transactions, approve investments, bind insurers, award procurement, allocate public finance, execute contracts, create donor commitments, create provider agreements, or authorize implementation.

22.4.10.2 Non-transactionality shall protect the public-good stack from capture, overclaim, reliance confusion, regulated-perimeter breach, procurement distortion, finance distortion, insurance distortion, sponsor control, provider validation, and execution by implication.

22.4.10.3 Transactions, if any, shall occur only through competent lawful actors, appropriate legal documentation, independent diligence, procurement processes where applicable, finance processes where applicable, insurance processes where applicable, public authority processes where applicable, and consent processes where applicable outside NAF.

## 22.5 Procurement Neutrality

### 22.5.1 No Preferred Provider.

22.5.1.1 NAF handoff shall not identify any provider, sponsor, vendor, contractor, consultant, platform, cloud service, software, model, dataset, infrastructure, dashboard, Studio workflow, Marketplace listing, Registry object, or Foundry output as a preferred provider by implication.

22.5.1.2 Where providers are referenced, the Handoff Package shall identify provider-neutrality notes, contribution status, review status, support class, conflicts, limitations, and independent diligence requirements.

22.5.1.3 No preferred provider status may be claimed from Nexus participation, sponsor support, provider contribution, Nexus Universe demonstration, Marketplace listing, Registry record, Grid input, TRL note, Report, Campaign output, Studio workflow, or handoff note.

### 22.5.2 No Procurement Recommendation.

22.5.2.1 Handoff shall not recommend procurement of any good, service, technology, provider, supplier, contractor, consultant, platform, software, dataset, model, infrastructure, or implementation pathway.

22.5.2.2 Procurement decisions must be made by competent procurement authorities or lawful private procurement actors through their own procurement rules, technical evaluation, competition processes, legal review, budget authority, conflict controls, and due diligence.

22.5.2.3 Handoff materials may describe context, dependencies, evidence, needs, risks, and readiness questions, but shall not rank suppliers, award tenders, recommend vendors, approve procurement, or structure procurement outcomes by implication.

### 22.5.3 No Supplier Approval.

22.5.3.1 No Handoff Package shall approve any supplier. Supplier approval, vendor onboarding, contractor qualification, procurement qualification, technical qualification, safety qualification, cybersecurity qualification, privacy qualification, or public authority supplier status must be separately determined by competent lawful actors.

22.5.3.2 Supplier participation in Nexus, National Portfolios, Campaigns, Foundry, Labs, Reports, Marketplace, Registry, Studio, Grid, Nexus Universe, Risk Agency, or handoff does not create supplier approval.

22.5.3.3 Any supplier approval claim based on NAF participation shall be treated as a procurement overclaim and may trigger correction, public-safe notice, Marketplace delisting, Registry update, handoff recall, withdrawal, or archive.

### 22.5.4 No Vendor Validation.

22.5.4.1 Provider contribution, technical demonstration, software contribution, data contribution where lawful, infrastructure support, sponsor support, Studio demonstration, Marketplace listing, Registry record, Grid input, TRL note, Report inclusion, Nexus Universe visibility, or handoff reference shall not validate a vendor.

22.5.4.2 Vendor validation may occur only through independent lawful diligence, technical review, procurement process, certification process where applicable, public authority process where applicable, or contractual process outside NAF.

22.5.4.3 Vendor validation overclaims shall be corrected and may require public-safe notice, claims freeze, delisting, status update, handoff recall, or withdrawal.

### 22.5.5 No Tender Support by Implication.

22.5.5.1 Handoff materials shall not be used as tender support, bid endorsement, procurement specification, preferred supplier evidence, sole-source justification, technical compliance certificate, or vendor scoring evidence by implication.

22.5.5.2 A recipient may use NAF materials as background context only where lawful and where procurement rules permit, subject to boundary notices, data restrictions, public-safe status, provider-neutrality notes, sponsor-boundary notes, and independent diligence.

22.5.5.3 Any tender use requiring formal support, technical specification, legal review, procurement support, or expert reliance must be separately authorized, reviewed, and documented outside NAF’s default handoff posture.

### 22.5.6 Independent Diligence Required.

22.5.6.1 Independent diligence shall be required before any downstream procurement, contracting, finance, insurance, public authority action, consent process, deployment, operation, or execution.

22.5.6.2 Independent diligence may include technical diligence, legal diligence, financial diligence, insurance diligence, cybersecurity diligence, privacy diligence, data rights diligence, safeguard diligence, professional diligence, procurement diligence, public authority diligence, community process, Indigenous protocol process where applicable, environmental review, safety review, and operational readiness review.

22.5.6.3 NAF outputs may inform diligence but shall not replace it.

### 22.5.7 Provider Contribution Controls.

22.5.7.1 Provider contributions to Handoff Packages shall be identified, attributed where appropriate, conflict-reviewed, support-classified, license-reviewed, public-safe reviewed, provider-neutrality reviewed, procurement-neutrality reviewed, and correctionable.

22.5.7.2 Provider contributions shall not control evidence, Reports, Registry status, Marketplace listing, Studio workflow, Grid input, TRL note, National Portfolio content, public authority learning, readiness questions, or handoff conclusions.

22.5.7.3 Provider contributions shall not create provider validation, supplier approval, procurement preference, financeability, public authority approval, deployment authorization, or execution.

### 22.5.8 Marketplace Listing Controls.

22.5.8.1 Marketplace listings included in or referenced by Handoff Packages shall be governed as discovery objects only. Listing shall not create procurement, endorsement, certification, warranty, support guarantee, provider validation, financeability, public authority approval, deployment authorization, or execution.

22.5.8.2 Marketplace listing controls shall include metadata review, public-safe review, license review, support class review, provider-neutrality review, sponsor-boundary review, procurement-neutrality review, finance-boundary review, correction, delisting, withdrawal, and archive.

22.5.8.3 Where a Marketplace listing is relevant to handoff, the Handoff Package shall state that the recipient must conduct independent diligence before any procurement, contracting, deployment, or operational use.

## 22.6 Public Authority Boundary in Handoff

### 22.6.1 Public Authority Dependencies.

22.6.1.1 Handoff shall identify public authority dependencies where downstream activity may require public authority action, including permits, licenses, approvals, regulations, procurement decisions, public finance allocations, public warnings, emergency commands, public health actions, environmental approvals, infrastructure access, data access, land access, spectrum authorization, utility coordination, or other official processes.

22.6.1.2 Public authority dependencies shall be recorded as dependencies, not as approvals.

22.6.1.3 No public authority dependency shall be treated as satisfied by public authority attendance, public authority learning participation, Nexus Universe presence, room participation, Report review, Studio demonstration, Grid input, TRL note, Marketplace listing, Registry record, National Portfolio inclusion, or Handoff Package receipt.

### 22.6.2 Public Authority Learning Record.

22.6.2.1 A Public Authority Learning Record may accompany Handoff Packages where public authorities have participated in learning, observation, scenario review, Studio workflow review, Report review, DRI interpretation, GRIx interpretation, Observatory interpretation, readiness-room activity, public finance learning, procurement boundary discussion, or handoff dependency discussion.

22.6.2.2 Public Authority Learning Records shall include no-decision, no-warning, no-command, no-regulatory-action, no-procurement, no-public-finance-allocation, no-permit, no-license, no-approval, and no-execution notices.

22.6.2.3 Public Authority Learning Records shall not be represented as public authority approval, official adoption, regulation, permit, license, public warning, public finance allocation, procurement decision, emergency command, deployment authorization, or execution.

### 22.6.3 Non-Decision Rooms.

22.6.3.1 Non-Decision Rooms shall include public authority learning rooms, readiness rooms, capital-reader rooms, insurance-reader rooms, donor-reader rooms, public finance learning rooms, secure rooms, data rooms, Studio rooms, community safeguard rooms, protected knowledge rooms, media-safe rooms, and correction rooms where decisions are not being made by NAF.

22.6.3.2 Non-Decision Rooms may support learning, interpretation, review, question formation, safeguard review, public-safe reporting, dependency mapping, diligence-gap identification, and correction.

22.6.3.3 Non-Decision Rooms shall not create public authority decisions, finance decisions, insurance decisions, procurement decisions, donor commitments, consent decisions, deployment decisions, or execution decisions.

### 22.6.4 Official Action Outside NAF.

22.6.4.1 Official action shall occur outside NAF through competent public authority processes, competent corporate processes, competent procurement processes, competent finance processes, competent insurance processes, competent legal processes, competent consent processes, competent professional processes, and competent implementation processes.

22.6.4.2 NAF may inform official action by providing public-good context, but shall not substitute for official action.

22.6.4.3 Official action may not be implied from any NAF record, output, Report, Marketplace listing, Registry record, Grid input, TRL note, Studio workflow, Campaign, Nexus Universe output, Risk Agency advisory note, National Portfolio record, or Handoff Package.

### 22.6.5 Public Finance Outside NAF.

22.6.5.1 Public finance decisions, allocations, appropriations, budget commitments, grants, guarantees, concessional finance, blended finance, subsidies, procurement-linked finance, development finance approvals, and other public finance actions shall occur outside NAF through competent public finance authorities and lawful processes.

22.6.5.2 Public finance learning may occur within NAF, but public finance action shall not.

22.6.5.3 Public finance relevance questions, donor-readiness questions, capital-readability notes, readiness-room discussions, and Handoff Packages shall not create public finance allocation, budget approval, financeability, or transaction.

### 22.6.6 Permits, Licenses, and Approvals Outside NAF.

22.6.6.1 Permits, licenses, approvals, authorizations, clearances, regulatory determinations, environmental approvals, public health approvals, safety approvals, spectrum authorizations, infrastructure permits, data authorizations, land access approvals, and other official permissions shall occur outside NAF through competent authorities.

22.6.6.2 Handoff Packages shall identify permit, license, and approval dependencies where known or reasonably apparent within scope.

22.6.6.3 Handoff Packages shall not create, imply, accelerate, waive, replace, or satisfy permits, licenses, or approvals.

### 22.6.7 Public Warnings Outside NAF.

22.6.7.1 Public warnings, emergency alerts, evacuation notices, official risk notices, public health warnings, infrastructure warnings, weather warnings, disaster warnings, security warnings, and emergency communications shall occur outside NAF through competent public authorities or competent authorized actors.

22.6.7.2 NAF may produce public-safe risk intelligence summaries, DRI outputs, Observatory summaries, Studio scenarios, Reports, and learning materials, but these shall not be public warnings.

22.6.7.3 Handoff Packages shall include no-warning notices where risk intelligence, DRI, Observatory, Studio, hazard, vulnerability, exposure, or resilience materials are included.

### 22.6.8 Emergency Command Outside NAF.

22.6.8.1 Emergency command, incident command, operational command, resource allocation, emergency deployment, disaster response, humanitarian coordination, infrastructure operation, public safety action, and crisis execution shall occur outside NAF through competent lawful actors.

22.6.8.2 NAF may support crisis-learning, after-action learning, scenario learning, resilience literacy, public-safe reporting, and handoff dependency awareness, but shall not command emergency action.

22.6.8.3 No Handoff Package shall be used as an emergency command, operational instruction, deployment order, public warning, or resource allocation authority.

## 22.7 Handoff Governance

### 22.7.1 Handoff Intake.

22.7.1.1 Handoff Intake shall begin when an object, record, Report, build, Studio workflow, Grid input, TRL note, National Portfolio item, Nexus Universe output, Campaign output, Risk Agency output, Labs output, Academy output, Marketplace listing, Registry record, DRI output, GRIx mapping, Observatory signal, or other NAF output is proposed for lawful downstream use, review, continuation, diligence, or implementation context.

22.7.1.2 Handoff Intake shall record requester, proposed recipient, recipient class, purpose, scope, object class, source pathway, jurisdictional context, data class, AI-use class, cyber class, privacy class, public-safe class, safeguard class, public authority class, finance and insurance class, procurement class, consent class, deployment class, execution risk, correction status, and archive status.

22.7.1.3 Handoff Intake shall reject, defer, restrict, reroute, or escalate any proposed handoff that lacks sufficient context, has unresolved boundary risk, contains unsafe public claims, creates provider validation risk, creates sponsor control risk, creates public authority confusion, creates finance or insurance overclaim, creates procurement distortion, creates consent overclaim, creates protected knowledge risk, or creates execution by implication.

### 22.7.2 Handoff Classification.

22.7.2.1 Handoff Classification shall classify proposed handoff by release class, access class, recipient class, reliance class, evidence class, data class, AI-use class, cyber class, privacy class, public-safe class, safeguard class, public authority dependency class, finance-readiness class, insurance-readiness class, donor-readiness class, public finance relevance class, procurement boundary class, consent boundary class, deployment boundary class, and execution boundary class.

22.7.2.2 Handoff Classification shall distinguish learning-only handoff, public-safe context handoff, controlled advisory handoff, secure-room handoff, data-room handoff, Studio-context handoff, Grid-context handoff, TRL-context handoff, National Portfolio handoff, Nexus Universe continuation handoff, handoff-recipient-only package, and archive-only handoff.

22.7.2.3 Classification shall determine review requirements, notices, access controls, recipient obligations, correction pathway, recall pathway, and archive rule.

### 22.7.3 Handoff Review.

22.7.3.1 Handoff Review shall verify that the Handoff Package contains appropriate evidence context, data context, method context, Studio context, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive linkage.

22.7.3.2 Handoff Review may require evidence review, method review, data review, AI-use review, cyber review, privacy review, public-safe review, safeguard review, protected knowledge review, geospatial sensitivity review, biosecurity sensitivity review, public authority boundary review, finance boundary review, insurance boundary review, procurement boundary review, provider-neutrality review, sponsor-boundary review, legal dependency review, and archive review.

22.7.3.3 Handoff Review shall not approve downstream execution. It shall approve only whether the Handoff Package may be released within a defined release class and boundary status.

### 22.7.4 Handoff Recipient Record.

22.7.4.1 A Handoff Recipient Record shall identify the recipient, recipient class, lawful basis for receipt, role, jurisdictional context, intended use, prohibited use, access class, reliance class, confidentiality status, data permissions, AI-use permissions, public-safe obligations, safeguard obligations, public authority dependencies, finance and insurance boundaries, procurement boundaries, consent boundaries, deployment boundaries, execution boundaries, correction obligations, recall obligations, and archive obligations.

22.7.4.2 The Handoff Recipient Record shall confirm that the recipient is responsible for independent diligence and downstream action.

22.7.4.3 The Handoff Recipient Record shall not create endorsement, certification, procurement approval, finance approval, insurance approval, public authority approval, consent, deployment authorization, or execution.

### 22.7.5 Handoff Dependency Register.

22.7.5.1 A Handoff Dependency Register shall record all dependencies associated with a Handoff Package, including evidence dependencies, data dependencies, method dependencies, technical dependencies, AI dependencies, cyber dependencies, privacy dependencies, public-safe dependencies, safeguard dependencies, public authority dependencies, legal dependencies, finance dependencies, insurance dependencies, donor dependencies, public finance dependencies, procurement dependencies, consent dependencies, deployment dependencies, operational dependencies, support dependencies, correction dependencies, recall dependencies, and archive dependencies.

22.7.5.2 Each dependency shall include owner where known, status, unresolved questions, review needs, risk level, boundary status, due pathway where applicable, and correction pathway.

22.7.5.3 The Handoff Dependency Register shall not satisfy the dependencies it records.

### 22.7.6 Handoff Correction.

22.7.6.1 Handoff Correction shall occur where a Handoff Package, Handoff Recipient Record, Handoff Dependency Register, Marketplace listing, Registry record, Report, Studio workflow, Grid input, TRL note, National Portfolio record, Nexus Universe output, Risk Agency output, Campaign output, Foundry output, Labs output, Academy output, DRI output, GRIx mapping, Observatory signal, public-safe summary, or downstream claim contains error, overclaim, changed condition, unsafe reliance, boundary breach, safeguard concern, data issue, AI issue, cyber issue, privacy issue, protected knowledge issue, public authority overclaim, finance overclaim, insurance overclaim, procurement overclaim, provider validation claim, sponsor control claim, consent overclaim, deployment overclaim, or execution overclaim.

22.7.6.2 Handoff Correction may include claims freeze, data freeze, technical freeze, recipient notice, public-safe notice, Report correction, Marketplace delisting, Registry status update, Studio suspension, Grid downgrade, TRL revision, Handoff Dependency Register update, Handoff Recipient Record update, handoff recall, withdrawal, supersession, archive, and non-continuation.

22.7.6.3 Handoff Correction shall be propagated to affected recipients, repositories, Reports, Marketplace listings, Registry records, National Portfolios, Nexus Universe records, Nexus Network memory, Nexus Rails routing, and downstream handoff packages where appropriate.

### 22.7.7 Handoff Recall.

22.7.7.1 Handoff Recall shall occur where a Handoff Package or a material part of it must no longer be used for downstream reliance, diligence, learning, implementation context, public-safe communication, or continuation because of error, unsafe reliance, boundary breach, changed conditions, corrected evidence, withdrawn data, protected knowledge issue, public authority issue, finance issue, insurance issue, procurement issue, consent issue, deployment issue, execution issue, or other serious concern.

22.7.7.2 Handoff Recall shall include recall trigger, affected package, affected recipients, recall scope, required recipient action, public-safe notice where applicable, Registry update, Marketplace update, Report correction where applicable, Studio suspension where applicable, Grid update where applicable, TRL update where applicable, archive action, and closure record.

22.7.7.3 Handoff Recall shall not make Nexus responsible for downstream execution. Recipients remain responsible for stopping, correcting, disclosing, withdrawing, modifying, or otherwise addressing downstream reliance and downstream actions in accordance with their own obligations.

### 22.7.8 Handoff Archive.

22.7.8.1 Handoff Archive shall preserve Handoff Packages, Handoff Intake records, Handoff Classification records, Handoff Review records, Handoff Recipient Records, Handoff Dependency Registers, Handoff Correction records, Handoff Recall records, withdrawal records, supersession records, non-continuation records, and archive notices.

22.7.8.2 Handoff Archive shall include archive date, archive reason, access class, sensitivity class, public-safe status, support status, correction history, recall history, successor link where applicable, retention rule, deletion or sealing rule where applicable, and archive-not-current notice.

22.7.8.3 Handoff Archive shall preserve institutional memory without implying current validity, active support, approval, certification, procurement status, financeability, insurance approval, public authority decision, consent, deployment authorization, or execution.

## 22.8 Handoff Boundaries

### 22.8.1 Context Is Not Authorization.

22.8.1.1 Handoff context shall not authorize downstream action. Context may inform recipients, but authorization must arise from competent lawful authority, including public authority approval, corporate authority, contractual authority, procurement authority, finance authority, insurance authority, legal authority, professional authority, consent authority, deployment authority, or operational authority outside NAF.

22.8.1.2 No Handoff Package, Report, Registry record, Marketplace listing, Studio workflow, Grid input, TRL note, DRI output, GRIx mapping, Observatory signal, National Portfolio update, Nexus Universe output, Campaign output, Foundry output, Risk Agency note, Academy record, or Labs record shall be represented as authorization.

### 22.8.2 Readiness Is Not Finance.

22.8.2.1 Readiness context, including Grid status, TRL notes, evidence sufficiency, method sufficiency, data sufficiency, AI-use sufficiency, cyber sufficiency, public-safe sufficiency, safeguard sufficiency, support sufficiency, reproducibility sufficiency, National Portfolio readiness, Nexus Universe readiness, finance-readiness question status, insurance-readiness question status, donor-readiness question status, and handoff dependency readiness, shall not constitute finance.

22.8.2.2 Readiness shall not be represented as investment advice, bankability, financeability, insurance approval, donor commitment, public finance allocation, procurement readiness, or transaction readiness.

22.8.2.3 Finance, if any, must occur separately through competent lawful actors, independent diligence, lawful documentation, regulated processes where applicable, and appropriate authorizations outside NAF.

### 22.8.3 Evidence Is Not Approval.

22.8.3.1 Evidence transferred through handoff shall not constitute approval. Evidence may be relevant to downstream diligence, but it shall not replace approval by competent actors.

22.8.3.2 Evidence shall not be represented as public authority approval, regulatory approval, technical certification, safety approval, cybersecurity certification, privacy compliance determination, procurement approval, provider validation, finance approval, insurance approval, consent, deployment authorization, or execution.

22.8.3.3 Evidence shall remain bounded by its recorded scope, method, assumptions, limitations, review status, public-safe status, safeguard status, correction status, and archive status.

### 22.8.4 Recipient Is Responsible.

22.8.4.1 The recipient shall be responsible for all downstream decisions, claims, diligence, procurement, finance, insurance, public authority processes, legal processes, professional processes, consent processes, deployment, operation, maintenance, monitoring, correction, recall response, public communication, and execution arising from or informed by a Handoff Package.

22.8.4.2 The recipient shall not imply that Nexus, GCRI, The Global Risks Forum, The Global Risks Alliance, any Nexus Consortium, any National Node, any Working Group, any Competence Cell, any Campaign, any Foundry team, any Risk Agency expert, any reviewer, any maintainer, any sponsor, any provider, any public authority learning participant, or any NAF participant has assumed recipient responsibility.

22.8.4.3 Recipient responsibility includes the obligation to stop, correct, withdraw, revise, disclose, or otherwise address downstream reliance if a Handoff Package is corrected, recalled, withdrawn, superseded, archived, or marked non-continuing.

### 22.8.5 Nexus Does Not Execute.

22.8.5.1 Nexus does not execute through handoff. NAF’s role is to create and route public-good context, records, learning, evidence, readiness notes, public-safe knowledge, Registry status, Marketplace discovery, Studio workflows, Grid inputs, TRL context, National Portfolio memory, Nexus Universe outputs, and Handoff Packages.

22.8.5.2 Execution shall occur only through competent lawful actors outside NAF, including public authorities, National Consortium Companies, Project SPVs, providers, operators, contractors, funders, insurers, donors, universities, labs, communities where appropriate, and other lawful recipients acting within their own authority and responsibility.

22.8.5.3 No handoff shall convert Nexus into a project developer, operator, contractor, procurement body, fund, lender, insurer, broker, underwriter, regulator, public authority, emergency command body, consent body, deployment authority, or execution vehicle by implication.

### 22.8.6 Handoff Can Be Recalled or Corrected.

22.8.6.1 Every Handoff Package shall remain correctionable, recallable, withdrawable, supersedable, archivable, and non-continuable. Handoff shall not create permanent validity, permanent readiness, permanent support, permanent permission, permanent authority, or permanent reliance.

22.8.6.2 Handoff Correction or Handoff Recall may occur because of error, changed conditions, unsafe reliance, overclaim, misuse, boundary breach, data issue, AI issue, cyber issue, privacy issue, protected knowledge issue, safeguard concern, public authority issue, finance issue, insurance issue, procurement issue, provider validation issue, sponsor control issue, consent issue, deployment issue, execution issue, support issue, or archive requirement.

22.8.6.3 The final Handoff rule of Part XXII is that NAF may transfer context, dependencies, evidence, methods, Studio records, Grid and TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive linkage only through controlled, recorded, nationally routed where applicable, standards-aware, public-safe, safeguard-aware, sponsor-bounded, provider-neutral, public-authority-bounded, finance-bounded, insurance-bounded, procurement-neutral, consent-bounded, correctionable, recallable, archive-capable, and non-executing handoff governance. No Handoff Package, handoff discussion, handoff room, handoff arena, recipient record, dependency register, readiness note, public authority learning record, capital-readability note, insurance-readiness question, donor-readiness question, public finance relevance question, Marketplace listing, Registry status, Report, Studio workflow, Grid input, TRL note, National Portfolio object, Nexus Universe output, Campaign output, Foundry output, Risk Agency note, DRI output, GRIx mapping, Observatory signal, sponsor support record, provider contribution record, or archive record shall become authorization, approval, certification, financeability, investment advice, underwriting, procurement recommendation, public authority decision, public warning, emergency command, community consent, Indigenous consent where applicable, deployment authorization, operational control, agency, warranty, or execution by implication.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/operations/frameworks/nexus-agile-framework-naf/xxii.-handoff.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.