# XX. SAFEGUARDS

### 20. Safeguards, Data, Protected Knowledge, and Public-Good Firewall

### 20.1 Federation Safeguards

#### 20.1.1 Safeguards as Federation Conditions

**20.1.1.1** **Federation Safeguards** shall be mandatory conditions of the Nexus Consortium Federation and shall apply across the global, regional, national, council, helix, Working Group, Competence Cell, Nexus Universe, AEP Passport, Nexus Rail, Docket, Grid, public-safe reporting, sponsorship, partnership, handoff, National Consortium Company, Project SPV, provider, public authority learning, capital-reader, media, community, Indigenous where applicable, and enterprise-interface pathways.

**20.1.1.2** Safeguards shall include, without limitation, public-good purpose safeguards, non-execution safeguards, role-separation safeguards, public authority boundary safeguards, finance and insurance boundary safeguards, procurement-neutrality safeguards, provider-neutrality safeguards, sponsor support-without-control safeguards, community and Indigenous consent-boundary safeguards where applicable, protected knowledge safeguards, data protection safeguards, confidentiality safeguards, cyber safeguards, infrastructure-sensitivity safeguards, public-safe reporting safeguards, accessibility safeguards, anti-capture safeguards, correction safeguards, and lawful handoff safeguards.

**20.1.1.3** Safeguards shall not be optional policy preferences, reputational statements, or public relations language. They shall be operating conditions that determine whether a record may be created, circulated, published, routed, relied upon, escalated to Nexus Universe, referenced in AEP Passport or Nexus Rail pathways, entered into Docket or Grid processes, provided to a public authority learner, provided to a capital reader, provided to a sponsor or provider, provided to a National Consortium Company, provided to a Project SPV, or transmitted through a handoff pathway.

**20.1.1.4** Safeguards shall be attached to the record, not merely to the meeting or institution that generated the record. A safeguard condition recorded at national level shall not disappear when the record is reviewed at regional or global level. A safeguard condition recorded in Nexus Universe shall not disappear when the record is routed to AEP Passport, Nexus Rail, Docket, Grid, public-safe reporting, handoff, National Consortium Company review, or Project SPV review.

**20.1.1.5** Safeguards shall be interpreted restrictively where ambiguity may create public harm, legal risk, protected knowledge exposure, public authority confusion, finance reliance, procurement advantage, provider validation, sponsor capture, community or Indigenous consent overclaim, public warning confusion, or execution implication.

**20.1.1.6** Safeguards shall be documented in the applicable register, record, report, room file, handoff file, or correction file and shall identify the safeguard owner, source, scope, sensitivity class, conditions, permitted uses, prohibited uses, downstream routing limits, correction pathway, renewal date, and archive status.

**20.1.1.7** Federation Safeguards shall be correctionable. If a safeguard is omitted, weakened, misclassified, stripped from a record, ignored in public-safe reporting, overridden by sponsor or provider interest, misused as consent, misused as approval, or bypassed in handoff, the relevant record, claim, report, pathway, access, or handoff shall be corrected, restricted, suspended, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.2 Safeguards Travel With Records

**20.1.2.1** **Safeguards Travel With Records** shall mean that every safeguard condition attached to a record shall remain attached to that record throughout its lifecycle, including creation, review, classification, circulation, publication, translation, summarization, Nexus Universe use, AEP Passport or Nexus Rail use, Docket or Grid use, public-safe reporting, handoff, enterprise review, correction, supersession, withdrawal, renewal, and archive.

**20.1.2.2** Safeguard conditions shall not be separated from the record for convenience, formatting, public-facing presentation, sponsor communication, provider communication, finance-readiness discussion, public authority learning, media use, regional synthesis, global aggregation, handoff packaging, National Consortium Company review, Project SPV review, or public-safe summarization.

**20.1.2.3** A record carrying safeguards shall include, as applicable:

1. source of the safeguard;
2. affected persons, communities, groups, data, systems, locations, knowledge, or institutions;
3. sensitivity classification;
4. publication restrictions;
5. data and confidentiality restrictions;
6. protected knowledge restrictions;
7. community and Indigenous protocol conditions where applicable;
8. public authority dependencies;
9. finance and procurement dependencies;
10. provider-neutrality and sponsor-boundary conditions;
11. public-safe reporting limits;
12. handoff restrictions;
13. correction and withdrawal rights;
14. renewal and archive conditions.

**20.1.2.4** If a record is summarized, translated, excerpted, converted into a deck, turned into a dashboard, included in a Nexus Universe session, referenced in a public-safe report, or routed to a downstream recipient, the safeguard conditions shall be preserved in substance and shall not be reduced in a way that creates a misleading impression.

**20.1.2.5** Where safeguard conditions cannot be safely disclosed in public materials, the public material shall preserve the existence of unresolved or restricted safeguard conditions through public-safe limitation language without exposing sensitive details.

**20.1.2.6** A downstream recipient shall not claim lack of awareness of safeguard conditions where the conditions were attached to the record or referenced in the handoff package.

**20.1.2.7** Safeguards-travel records shall be correctionable. If a safeguard is dropped, hidden, mistranslated, summarized away, omitted from a handoff package, excluded from public-safe reporting, or ignored by a recipient, the record and all affected downstream materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.3 Safeguards Travel Across Global, Regional, and National Layers

**20.1.3.1** **Safeguards Travel Across Global, Regional, and National Layers** shall mean that safeguard conditions originating at national, local, community, Indigenous where applicable, technical, public authority, data, cyber, infrastructure, finance-readiness, or protected knowledge level shall remain enforceable when a record moves upward to regional or global synthesis and when global or regional materials move downward into national or enterprise pathways.

**20.1.3.2** Global aggregation shall not dilute national safeguards. Regional synthesis shall not override country safeguards. National gateway formation shall not erase local, community, Indigenous, data, cyber, infrastructure, or protected knowledge restrictions. Nexus Universe visibility shall not publicize sensitive safeguard material unless separately authorized.

**20.1.3.3** A regional or global record that incorporates national or local safeguard material shall preserve source, scope, geographic limits, sensitivity class, public-safe classification, community and Indigenous protocol conditions where applicable, publication restrictions, data restrictions, consent-boundary language, correction rights, and archive status.

**20.1.3.4** Where a global or regional report discusses countries, corridors, hazards, communities, ecosystems, public authorities, infrastructure, providers, capital pathways, or handoff themes, it shall identify safeguard limits at a level of detail that prevents overclaim while protecting sensitive information.

**20.1.3.5** Cross-layer safeguards shall prevent the misuse of regional or global status to imply national consent, community consent, Indigenous consent, public authority approval, protected knowledge authorization, public finance allocation, financeability, procurement status, certification, provider validation, project authorization, or execution.

**20.1.3.6** When a national record is corrected, withdrawn, superseded, restricted, or archived for safeguard reasons, affected regional and global records shall be reviewed and corrected accordingly.

**20.1.3.7** Cross-layer safeguard records shall be correctionable. If regional or global synthesis strips safeguards, misstates country conditions, exposes protected knowledge, weakens consent boundaries, or converts local input into global legitimacy, the affected records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.4 Safeguards Travel Into Handoff

**20.1.4.1** **Safeguards Travel Into Handoff** shall mean that all safeguard conditions attached to a public-good record shall remain attached when the record is transmitted to a National Consortium Company, Project SPV, provider, host, operator, public authority, investor, insurer, donor, development actor, public finance actor, procurement body, community process, Indigenous governance process where applicable, environmental process, data process, cyber process, or other downstream recipient.

**20.1.4.2** Handoff shall not remove safeguard obligations. A Handoff Readiness Record shall identify safeguard conditions, consent-boundary conditions, protected knowledge restrictions, data and privacy restrictions, public authority dependencies, finance dependencies, procurement dependencies, provider-neutrality conditions, sponsor restrictions, publication limits, correction rights, withdrawal rights, supersession conditions, and archive status.

**20.1.4.3** Safeguard conditions in handoff may include:

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. consent-boundary language;
13. downstream process requirements.

**20.1.4.4** Handoff recipients shall not treat safeguard records as approval, consent, social license, consultation completion, FPIC satisfaction where applicable, protected knowledge authorization, environmental approval, land access, cultural approval, rights-holder approval, local authorization, project approval, or execution authority.

**20.1.4.5** If a handoff recipient cannot comply with safeguard conditions, the handoff shall be restricted, suspended, withdrawn, or routed to correction rather than allowed to proceed under incomplete or unsafe assumptions.

**20.1.4.6** Safeguards shall remain enforceable after handoff through correction notices, recipient notices, withdrawal notices, supersession notices, public-safe clarifications where necessary, and archive notations.

**20.1.4.7** Handoff safeguard records shall be correctionable. If safeguards are omitted from handoff, misread by recipients, stripped in enterprise documents, converted into consent, used as approval, or bypassed for finance, procurement, provider, sponsor, or execution purposes, the handoff and all affected records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.5 Safeguards Apply to Nexus Universe

**20.1.5.1** **Safeguards Apply to Nexus Universe** shall mean that all Nexus Universe activities, including the one-year mobilization cycle, one-month Nexus Core build, one-week live operation, public stage, controlled rooms, technical rooms, public authority learning rooms, capital-reader rooms, sponsor rooms, provider-neutral rooms, safeguard rooms, media rooms, AEP Passport rooms, Nexus Rail rooms, Docket and Grid rooms, handoff discussions, public-safe reports, correction, and renewal, shall be subject to Federation Safeguards.

**20.1.5.2** Nexus Universe visibility shall not reduce safeguard obligations. High-profile public stages, large audiences, sponsor presence, public authority attendance, capital-reader attendance, media coverage, provider demonstrations, global participation, regional delegation, national delegation, or public-safe reporting shall increase the need for safeguard review rather than reduce it.

**20.1.5.3** Nexus Universe safeguard controls shall include, as applicable:

1. room classification;
2. participant capacity classification;
3. public-safe listing review;
4. public authority boundary notices;
5. finance no-reliance notices;
6. provider-neutrality notices;
7. sponsor support-without-control notices;
8. community and Indigenous consent-boundary notices where applicable;
9. protected knowledge restrictions;
10. data and cyber restrictions;
11. accessibility and translation controls;
12. media controls;
13. live correction capacity;
14. post-cycle correction and renewal.

**20.1.5.4** Safeguard rooms shall not be consent rooms. Public authority rooms shall not be approval rooms. Capital-reader rooms shall not be investment rooms. Provider-neutral rooms shall not be validation rooms. Sponsor-supported rooms shall not be control rooms. Media rooms shall not be public warning rooms. Handoff rooms shall not be execution rooms.

**20.1.5.5** Nexus Universe materials shall not expose restricted, confidential, public authority-sensitive, finance-sensitive, provider-sensitive, sponsor-sensitive, community-sensitive, Indigenous-sensitive where applicable, protected-knowledge-sensitive, cyber-sensitive, infrastructure-sensitive, security-sensitive, health-sensitive, humanitarian-sensitive, or not-for-publication information.

**20.1.5.6** Live-operation safeguards shall be monitored in real time. Session titles, room descriptions, public-stage scripts, participant biographies, sponsor references, provider references, public authority references, finance-readiness references, safeguard references, AEP Passport references, Nexus Rail references, Docket or Grid references, handoff references, and public-safe reports shall be correctable during the live week.

**20.1.5.7** Nexus Universe safeguard records shall be correctionable. If Nexus Universe activities create safeguard overclaim, public authority confusion, finance reliance, provider validation, sponsor capture, consent implication, protected knowledge exposure, public warning confusion, or execution implication, the relevant materials, access, session, report, claim, and record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.6 Safeguards Apply to AEP Passports and Rails

**20.1.6.1** **Safeguards Apply to AEP Passports and Rails** shall mean that AEP Passport candidate records, Proof Receipt references where authorized, AEP layers, Nexus Rail candidate records, routeability inputs, public authority dependency layers, finance-readiness layers, provider-neutrality layers, safeguard layers, Docket and Grid references, Nexus Universe references, and handoff-readiness references shall carry all applicable safeguard conditions.

**20.1.6.2** AEP Passport and Nexus Rail pathways shall not convert safeguard input into approval. Candidate status, layer preparation, Proof Receipt input, routeability input, Nexus Universe discussion, public-safe reference, Docket item, Grid input, or handoff-readiness shall not create public authority approval, financeability, procurement status, provider validation, certification, community consent, Indigenous consent, protected knowledge authorization, project authorization, Nexus-ready status, AEP Passport status, Nexus Node status, or execution.

**20.1.6.3** AEP Passport and Nexus Rail safeguard layers shall identify, as applicable:

1. public authority dependencies;
2. finance and insurance dependencies;
3. procurement dependencies;
4. provider-neutrality conditions;
5. sponsor-boundary conditions;
6. community and Indigenous safeguard conditions where applicable;
7. protected knowledge restrictions;
8. data and cyber conditions;
9. infrastructure and security sensitivities;
10. public-safe reporting limits;
11. handoff restrictions;
12. correction and withdrawal conditions.

**20.1.6.4** AEP Passport or Nexus Rail public-safe language shall distinguish candidate, input, layer, Proof Receipt reference where authorized, routeability, discussion, public-safe reference, issued status where lawfully issued, and execution by separate competent actors.

**20.1.6.5** AEP Passport and Nexus Rail registers shall not accept candidate records from which safeguards have been removed, hidden, misclassified, or unresolved beyond acceptable routing conditions.

**20.1.6.6** Any AEP Passport or Nexus Rail pathway that becomes associated with protected knowledge, sensitive infrastructure, security-sensitive data, community-sensitive information, Indigenous-sensitive information where applicable, or public authority-sensitive information shall be restricted unless a public-safe publication pathway is separately approved.

**20.1.6.7** AEP Passport and Nexus Rail safeguard records shall be correctionable. If candidate status is overclaimed, safeguards are stripped, protected knowledge is exposed, public authority approval is implied, financeability is implied, provider validation is implied, consent is implied, or execution is suggested, the relevant record, claim, report, register entry, or handoff shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.7 Safeguards Apply to Public-Safe Reporting

**20.1.7.1** **Safeguards Apply to Public-Safe Reporting** shall mean that every public-safe report, public-stage material, website text, deck, press release, media statement, sponsor material, provider material, investor material, public authority material, Nexus Universe report, National Model summary, Regional Cluster Program Plan summary, AEP Passport reference, Nexus Rail reference, Docket summary, Grid summary, handoff reference, correction notice, renewal notice, and archive summary shall be reviewed against applicable safeguards before publication or external circulation.

**20.1.7.2** Public-safe reporting shall not disclose restricted, confidential, public authority-sensitive, finance-sensitive, provider-sensitive, sponsor-sensitive, community-sensitive, Indigenous-sensitive where applicable, protected-knowledge-sensitive, cyber-sensitive, infrastructure-sensitive, security-sensitive, health-sensitive, humanitarian-sensitive, or not-for-publication information.

**20.1.7.3** Public-safe reporting safeguards shall include:

1. source-record validation;
2. public authority language review;
3. finance-readiness and no-reliance language review;
4. provider and sponsor language review;
5. community and Indigenous language review where applicable;
6. protected knowledge review;
7. data and cyber review;
8. infrastructure and security review;
9. accessibility review;
10. translation and localization review;
11. media-risk review;
12. correction-readiness review.

**20.1.7.4** Public-safe reporting shall distinguish learning from official action, readiness from financeability, contribution from validation, safeguard input from consent, public-safe reporting from public warning, candidate status from approval, handoff-readiness from execution, and record maturity from downstream maturity.

**20.1.7.5** Where a safeguard condition cannot be publicly described, public-safe reporting shall use appropriate limitation language rather than omit the condition or imply that no limitation exists.

**20.1.7.6** Public-safe reporting shall not be used to create sponsor promotion, provider marketing, investment promotion, procurement advantage, government endorsement, certification, community consent, Indigenous consent, public warning, or execution instruction.

**20.1.7.7** Public-safe reporting safeguard records shall be correctionable. If public-safe reporting is inaccurate, unsafe, overbroad, incomplete, misleading, sponsor-captured, provider-validating, public-authority-overclaiming, finance-signaling, consent-implying, protected-knowledge-exposing, public-warning-implying, or execution-implying, the report and related records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.8 Safeguards Apply to Sponsorship and Partnership

**20.1.8.1** **Safeguards Apply to Sponsorship and Partnership** shall mean that all anchors, hosts, sponsors, strategic partners, knowledge partners, technical partners, public-good software contributors, qualified enterprise provider candidates, capital readers, public authority learners, community and safeguard contributors, media and public-safe reporting contributors, and other support participants shall be subject to safeguard conditions as a condition of participation.

**20.1.8.2** Sponsorship and partnership shall not reduce safeguard obligations. Contribution size, venue control, market power, public authority relationships, capital strength, technical capability, academic prestige, media reach, host status, philanthropic status, community relationships, Indigenous relationships where applicable, or public visibility shall not permit a sponsor or partner to control safeguards.

**20.1.8.3** Sponsorship and partnership safeguard controls shall include:

1. conflict disclosure;
2. influence restrictions;
3. support-without-control conditions;
4. provider-neutrality conditions;
5. finance no-reliance conditions;
6. public authority boundary conditions;
7. procurement-neutrality conditions;
8. community and Indigenous consent-boundary conditions where applicable;
9. protected knowledge restrictions;
10. data and cyber obligations;
11. claims limits;
12. correction and termination rights.

**20.1.8.4** Sponsors and partners shall not use participation to claim community legitimacy, Indigenous legitimacy where applicable, public authority approval, financeability, provider validation, certification, procurement status, project authorization, Nexus-ready status, AEP Passport status, Nexus Node status, or execution authority.

**20.1.8.5** Where a sponsor or partner is also a provider, investor, insurer, donor, development actor, public finance actor, public authority participant, media actor, host, technical platform, National Consortium Company participant, Project SPV participant, or downstream handoff recipient, heightened safeguard review shall apply.

**20.1.8.6** Sponsor and partner materials shall be reviewed for safeguard accuracy before public use.

**20.1.8.7** Sponsorship and partnership safeguard records shall be correctionable. If a sponsor or partner weakens safeguards, creates capture risk, misuses community or Indigenous participation as consent, pressures public-safe reporting, creates finance signaling, creates provider validation, or implies execution, the relevant role, access, claim, record, support arrangement, or public-safe listing shall be corrected, restricted, suspended, terminated, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.9 Safeguards Apply to Enterprise Interfaces

**20.1.9.1** **Safeguards Apply to Enterprise Interfaces** shall mean that safeguards attached to public-good records shall remain binding conditions when records interface with National Consortium Companies, Project SPVs, providers, hosts, operators, sponsors, investors, insurers, donors, development actors, public finance actors, procurement bodies, public authorities, community processes, Indigenous governance processes where applicable, environmental processes, data processes, cyber processes, and other downstream lawful actors.

**20.1.9.2** Enterprise interfaces shall not treat public-good safeguards as historical context only. Safeguards shall be active conditions of review, diligence, routing, public-safe reporting, handoff, procurement, finance-readiness, insurance-readiness, provider selection, project governance, and implementation planning.

**20.1.9.3** Enterprise-interface safeguard controls shall include:

1. handoff safeguard schedule;
2. recipient acknowledgement;
3. public authority dependency statement;
4. finance and procurement dependency statement;
5. provider-neutrality statement;
6. sponsor-boundary statement;
7. community and Indigenous consent-boundary statement where applicable;
8. protected knowledge and data restriction statement;
9. publication restriction statement;
10. correction and withdrawal pathway;
11. downstream recipient notice process;
12. archive linkage.

**20.1.9.4** National Consortium Companies and Project SPVs shall preserve safeguards in their own enterprise records, diligence files, public authority materials, finance materials, procurement materials, provider materials, safeguard registers, public-safe materials, and downstream communications.

**20.1.9.5** Enterprise actors shall not use public-good safeguards as evidence of consent, approval, certification, public authority clearance, financeability, procurement status, provider validation, project authorization, or execution authority.

**20.1.9.6** If an enterprise actor cannot preserve safeguards, the interface shall be paused, restricted, withdrawn, or corrected.

**20.1.9.7** Enterprise-interface safeguard records shall be correctionable. If enterprise materials strip safeguards, convert safeguards into approval, misuse protected knowledge, create consent overclaim, create finance or procurement reliance, imply public authority approval, or create execution implication, the enterprise-interface record and affected claims shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.1.10 Safeguard Correction

**20.1.10.1** **Safeguard Correction** shall be the mandatory process through which safeguard-related errors, omissions, misclassifications, unsafe publications, overclaims, consent implications, protected knowledge exposures, community misrepresentations, Indigenous protocol failures where applicable, data and confidentiality breaches, sponsor or provider capture, public authority confusion, finance reliance, handoff misuse, and enterprise-interface failures are corrected.

**20.1.10.2** Safeguard Correction may apply to global, regional, national, Nexus Universe, AEP Passport, Nexus Rail, Docket, Grid, public-safe reporting, sponsorship, partnership, Working Group, Competence Cell, National Model, Regional Cluster Program Plan, handoff, National Consortium Company, Project SPV, provider, public authority learner, capital-reader, media, and archive records.

**20.1.10.3** Safeguard Correction measures may include:

1. record amendment;
2. sensitivity reclassification;
3. access restriction;
4. public-safe correction;
5. withdrawal of public material;
6. supersession notice;
7. recipient notice;
8. safeguard reattachment;
9. handoff suspension;
10. room restriction;
11. sponsor or provider restriction;
12. participant reclassification;
13. protected knowledge containment;
14. data breach pathway;
15. public-safe clarification;
16. archive notation.

**20.1.10.4** Urgent Safeguard Correction shall occur where delay may cause protected knowledge exposure, community harm, Indigenous protocol harm where applicable, privacy harm, public authority confusion, finance reliance, procurement advantage, provider validation, sponsor capture, public warning confusion, or execution implication.

**20.1.10.5** Safeguard Correction shall not expose the sensitive information it seeks to protect. Public clarification shall be carefully limited where disclosure would increase harm.

**20.1.10.6** Safeguard Correction shall be linked to all affected records and downstream recipients.

**20.1.10.7** Safeguard Correction records shall themselves be correctionable. If a correction is incomplete, inaccurate, unsafe, publicized beyond permission, or fails to correct the underlying safeguard failure, the correction record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived.

***

### 20.2 Data and Confidentiality

#### 20.2.1 Personal Information

**20.2.1.1** **Personal Information** shall mean information relating to an identified or identifiable individual, including names, contact details, role information, affiliations, biographies, attendance records, images, recordings, signatures, communications, location information, identifiers, demographic information, participation records, access records, conflict disclosures, financial or professional information, safeguard-related information, and any other information that applicable law treats as personal information or personal data.

**20.2.1.2** Personal Information processed within the Federation shall be collected, used, stored, accessed, transferred, published, corrected, retained, and deleted only for lawful, necessary, proportionate, recorded, and role-appropriate purposes.

**20.2.1.3** Personal Information shall not be exposed through public-safe reporting, Nexus Universe materials, participant lists, public-stage materials, websites, sponsor materials, provider materials, media materials, handoff packages, National Consortium Company records, Project SPV records, or public authority materials unless a lawful basis, publication permission, role classification, and public-safe review support the disclosure.

**20.2.1.4** Sensitive personal information, including health information, vulnerable-person information, children or youth information, community-sensitive information, Indigenous-sensitive information where applicable, humanitarian information, conflict-related information, biometric information, precise location information, or safety-sensitive information, shall receive heightened protection.

**20.2.1.5** Personal Information shall be classified according to sensitivity and shall be subject to access controls, confidentiality obligations, security measures, retention rules, correction rights, and breach-response pathways.

**20.2.1.6** Participation in Nexus shall not waive privacy rights or authorize unrestricted use of Personal Information.

**20.2.1.7** Personal Information records shall be correctionable. If Personal Information is inaccurate, excessive, misclassified, exposed beyond permission, used for an unauthorized purpose, transferred improperly, retained improperly, or included in public materials without authority, the record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived lawfully.

***

#### 20.2.2 Public Authority-Sensitive Information

**20.2.2.1** **Public Authority-Sensitive Information** shall mean information relating to public authorities, governments, regulators, municipalities, public finance bodies, public infrastructure bodies, emergency authorities, public health bodies, public enterprises, Indigenous or Tribal public-governance bodies where applicable, courts, legislatures, public-sector processes, public procurement, public finance, regulatory learning, policy development, official correspondence, non-public deliberations, security-sensitive public functions, or other public-law matters that is not appropriate for unrestricted disclosure.

**20.2.2.2** Public Authority-Sensitive Information shall be collected, used, circulated, published, routed, or handed off only within the scope authorized by the relevant public authority, public-sector participant, lawful basis, confidentiality condition, and Nexus record.

**20.2.2.3** Public authority learning shall not convert Public Authority-Sensitive Information into public information. Participation in a public authority room, Government Portfolio showcase preparation, Nexus Universe session, National Model discussion, Regional Cluster Program Plan discussion, AEP Passport layer discussion, Nexus Rail dependency mapping, Docket or Grid review, or public-safe reporting process shall not authorize disclosure beyond the record.

**20.2.2.4** Public Authority-Sensitive Information shall be classified according to sensitivity, including controlled, restricted, confidential, public authority-sensitive, infrastructure-sensitive, security-sensitive, procurement-sensitive, public finance-sensitive, regulatory-sensitive, data-sensitive, health-sensitive, or not-for-publication.

**20.2.2.5** Public-safe reports may reference public authority themes only through approved language that avoids public authority approval, government endorsement, regulatory comfort, procurement status, public finance allocation, public warning, project authorization, or execution implication.

**20.2.2.6** Handoff of Public Authority-Sensitive Information shall require a lawful purpose, source permission, recipient classification, confidentiality obligations, public authority boundary language, and correction pathway.

**20.2.2.7** Public Authority-Sensitive Information records shall be correctionable. If such information is disclosed beyond permission, used to imply approval, used to create procurement or public finance advantage, misquoted, misclassified, or routed to an improper recipient, the record and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.2.3 Commercially Sensitive Information

**20.2.3.1** **Commercially Sensitive Information** shall mean non-public information relating to an enterprise, provider, sponsor, host, partner, National Consortium Company, Project SPV, investor, insurer, donor, development actor, public finance actor, contractor, operator, platform, manufacturer, integrator, consultant, professional firm, or other commercial or enterprise participant, including business plans, pricing, technical designs, trade secrets, product roadmaps, customer information, contracts, negotiations, proposals, financial information, market strategy, intellectual property, procurement information, diligence materials, and competitive information.

**20.2.3.2** Commercially Sensitive Information shall be used only for the recorded purpose for which it was provided and shall not be exposed through public-safe reporting, Nexus Universe materials, public-stage discussions, sponsor materials, provider materials, media materials, public authority materials, handoff packages, National Model summaries, Regional Cluster Program Plan summaries, AEP Passport or Nexus Rail references, Docket or Grid summaries, or archive materials unless expressly authorized.

**20.2.3.3** Commercial sensitivity shall not be used to hide public-good limitations, safeguard conditions, conflicts, provider-neutrality conditions, sponsor influence, public authority dependencies, finance dependencies, procurement dependencies, correction obligations, or prohibited claims.

**20.2.3.4** Provider and sponsor materials shall be reviewed to prevent conversion of confidential commercial contribution into public validation or procurement advantage.

**20.2.3.5** Commercially Sensitive Information shall be subject to access controls, confidentiality obligations, conflict controls, source-record limitations, publication restrictions, correction rights, and archive conditions.

**20.2.3.6** Handoff of Commercially Sensitive Information shall identify the recipient, purpose, allowed use, restrictions, confidentiality obligations, and correction pathway.

**20.2.3.7** Commercially Sensitive Information records shall be correctionable. If such information is disclosed beyond permission, used as provider validation, used as procurement advantage, used as finance signal, misclassified, or routed improperly, the record and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.2.4 Finance-Sensitive Information

**20.2.4.1** **Finance-Sensitive Information** shall mean non-public or reliance-sensitive information relating to finance-readiness, capital-readability, investment interest, insurance-readiness, underwriting, donor relevance, development finance, public finance, guarantees, risk-transfer, diligence, valuation, revenue assumptions, cost assumptions, credit, risk allocation, SPV-readiness, transaction structure, legal terms, tax treatment, accounting treatment, investor communications, insurer communications, donor communications, public finance communications, or market-sensitive matters.

**20.2.4.2** Finance-Sensitive Information shall be handled under no-reliance, non-advisory, non-solicitation, non-placement, non-underwriting, non-rating, non-guarantee, non-transactional, non-fiduciary, and non-executing discipline unless a separate competent lawful process applies outside the public-good stack.

**20.2.4.3** Finance-Sensitive Information shall not be disclosed through public-safe reports, Nexus Universe materials, public-stage materials, sponsor materials, provider materials, media materials, National Model summaries, Regional Cluster Program Plan summaries, AEP Passport or Nexus Rail references, Docket or Grid summaries, or handoff summaries unless expressly authorized and reviewed for regulated-perimeter risk.

**20.2.4.4** Capital-reader participation, finance-readiness discussion, insurance-readiness discussion, donor relevance discussion, public finance relevance discussion, GRA-aligned finance-readiness work, National Investors Council involvement, AEP Passport finance-layer input, Nexus Rail finance-readiness input, Docket or Grid input, or handoff-readiness shall not be used to imply financeability, bankability, insurability, underwriting appetite, donor approval, public finance allocation, transaction readiness, capital commitment, or project approval.

**20.2.4.5** Finance-Sensitive Information shall be classified, access-controlled, versioned, and recorded with source limitations, no-reliance language, permitted use, prohibited claims, recipient restrictions, correction rights, and archive conditions.

**20.2.4.6** Handoff of Finance-Sensitive Information shall require a lawful purpose, recipient capacity, no-reliance notice, confidentiality obligations, finance boundary language, and correction pathway.

**20.2.4.7** Finance-Sensitive Information records shall be correctionable. If such information creates reliance, is disclosed beyond permission, implies financeability, implies insurance approval, implies donor approval, implies public finance allocation, or is routed improperly, the record and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.2.5 Provider-Sensitive Information

**20.2.5.1** **Provider-Sensitive Information** shall mean non-public or competitive information relating to providers, vendors, operators, hosts, platforms, manufacturers, integrators, technology actors, infrastructure actors, consultants, professional firms, enterprise participants, provider candidates, provider-neutral capability maps, technical demonstrations, technical dependencies, product information, service information, performance information, cybersecurity information, customer information, contracts, pricing, implementation plans, or procurement-relevant materials.

**20.2.5.2** Provider-Sensitive Information shall be handled under provider-neutrality and procurement-neutrality discipline. It shall not be used to validate, prefer, rank, certify, select, endorse, approve, or promote a provider unless a separate competent lawful process creates that status.

**20.2.5.3** Provider-Sensitive Information shall not be exposed through public-safe reports, Nexus Universe materials, public-stage materials, sponsor materials, media materials, public authority materials, National Model summaries, Regional Cluster Program Plan summaries, AEP Passport or Nexus Rail references, Docket or Grid summaries, or handoff summaries unless expressly authorized and reviewed for procurement and competition risk.

**20.2.5.4** Provider participation in Nexus, Working Groups, Competence Cells, Nexus Universe, AEP Passport candidate pathways, Nexus Rail pathways, Docket or Grid pathways, public-good software contribution, technical partnership, sponsorship, hosting, or handoff discussion shall not be used to imply provider validation.

**20.2.5.5** Provider-Sensitive Information shall be access-controlled, conflict-reviewed, source-limited, and classified with permitted uses, prohibited claims, correction rights, and archive conditions.

**20.2.5.6** Handoff of Provider-Sensitive Information shall preserve procurement-neutrality and shall warn recipients that public-good provider records do not replace procurement, diligence, qualification, contracting, or provider-selection processes.

**20.2.5.7** Provider-Sensitive Information records shall be correctionable. If such information is disclosed beyond permission, creates procurement advantage, implies provider validation, creates finance signaling, exposes cyber or infrastructure risk, or is routed improperly, the record and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.2.6 Community-Sensitive Information

**20.2.6.1** **Community-Sensitive Information** shall mean information relating to communities, affected stakeholders, local institutions, civil society actors, rights-holders, vulnerable groups, diaspora groups, youth, accessibility needs, lived-risk knowledge, local risk conditions, social vulnerabilities, place-based concerns, environmental justice issues, health-sensitive conditions, humanitarian conditions, land-use concerns, livelihood concerns, cultural concerns, safety concerns, or community safeguard issues that may create harm if misused or publicly exposed.

**20.2.6.2** Community-Sensitive Information shall be handled with heightened care and shall not be extracted, published, commercialized, used for sponsor or provider advantage, routed to finance or procurement actors, included in public-safe reports, or transferred to enterprise actors unless the relevant record permits the use and safeguards are preserved.

**20.2.6.3** Community participation shall not imply consent. Community-Sensitive Information shall not be used to claim community endorsement, social license, consent, local approval, project authorization, public authority approval, financeability, provider validation, or execution.

**20.2.6.4** Community-Sensitive Information shall be classified according to sensitivity, including controlled, restricted, confidential, community-sensitive, health-sensitive, humanitarian-sensitive, place-sensitive, public-safe summary only, or not-for-publication.

**20.2.6.5** Public-safe reporting may describe community themes only in a manner that avoids identification, harm, retaliation risk, misrepresentation, extractive use, consent overclaim, and protected knowledge exposure.

**20.2.6.6** Handoff of Community-Sensitive Information shall require purpose limitation, recipient restrictions, safeguard attachment, consent-boundary language, confidentiality obligations, and correction pathway.

**20.2.6.7** Community-Sensitive Information records shall be correctionable. If such information is exposed beyond permission, used extractively, misrepresents communities, implies consent, creates harm, or is routed improperly, the record and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.2.7 Indigenous and Protected Knowledge Where Applicable

**20.2.7.1** **Indigenous and Protected Knowledge Where Applicable** shall mean knowledge, information, practices, data, locations, cultural expressions, ecological knowledge, traditional knowledge, sacred knowledge, community-held knowledge, governance knowledge, land-based knowledge, water-based knowledge, health-related knowledge, biodiversity knowledge, cultural heritage information, language information, stories, protocols, maps, boundaries, site information, and other sensitive knowledge held by or associated with Indigenous peoples, Tribal actors, traditional authorities, protected knowledge holders, or communities that require heightened protection.

**20.2.7.2** Indigenous and Protected Knowledge shall not be collected, recorded, summarized, translated, mapped, analyzed, digitized, modeled, published, routed, commercialized, used in AI systems, used in observability systems, used in digital twins, used in AEP Passport pathways, used in Nexus Rail pathways, included in Docket or Grid materials, or handed off unless the applicable lawful and protocol-based conditions are satisfied.

**20.2.7.3** Indigenous participation, where applicable, shall not imply consent to use knowledge. Attendance, contribution, public-safe listing, Nexus Universe participation, safeguard-room participation, National Model input, Regional Cluster Program Plan input, AEP Passport safeguard input, Nexus Rail safeguard condition, Docket input, Grid input, or handoff discussion shall not imply consultation completion, accommodation completion, FPIC satisfaction, rights waiver, land approval, cultural approval, Indigenous data authorization, protected knowledge authorization, or consent.

**20.2.7.4** Protected Knowledge shall be classified at the highest necessary sensitivity level and may be designated not-for-publication, not-for-digitization, not-for-AI-use, not-for-geospatial-mapping, not-for-handoff, not-for-commercial-use, not-for-translation, not-for-aggregation, or not-for-public-safe-summary where required.

**20.2.7.5** Public-safe reporting shall not disclose Protected Knowledge. Where public reporting is appropriate, it shall use non-extractive, non-identifying, permission-based, public-safe summaries that preserve limitations and do not expose sensitive details.

**20.2.7.6** Handoff involving Indigenous or Protected Knowledge shall require specific recorded authorization, recipient restrictions, use limitations, confidentiality obligations, safeguard conditions, correction rights, withdrawal rights, and archive controls.

**20.2.7.7** Indigenous and Protected Knowledge records shall be correctionable. If Protected Knowledge is exposed, extracted, misclassified, translated without authority, mapped without authority, digitized without authority, used in AI or analytics without authority, routed beyond permission, or used as consent or approval, the record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.2.8 Infrastructure-Sensitive Information

**20.2.8.1** **Infrastructure-Sensitive Information** shall mean information relating to critical infrastructure, essential services, energy systems, water systems, food systems, health systems, communications systems, transport systems, ports, airports, logistics, data centers, cloud infrastructure, telecommunications, AI-RAN or O-RAN systems, compute infrastructure, cyber infrastructure, industrial systems, emergency systems, public safety systems, geospatial assets, sensing networks, Earth observation systems, digital twins, security systems, or infrastructure vulnerabilities that may create risk if disclosed.

**20.2.8.2** Infrastructure-Sensitive Information shall be classified, access-controlled, and handled in a manner that prevents misuse, vulnerability exposure, security risk, public safety risk, cyber risk, operational disruption, market misuse, public authority confusion, or hostile exploitation.

**20.2.8.3** Infrastructure-Sensitive Information shall not be disclosed through public-safe reports, Nexus Universe materials, public-stage materials, media materials, sponsor materials, provider materials, National Model summaries, Regional Cluster Program Plan summaries, AEP Passport or Nexus Rail references, Docket or Grid summaries, or handoff materials unless expressly authorized and reviewed for safety and security risk.

**20.2.8.4** Observability, dashboarding, digital twin, sensing, geospatial, AI, cyber, compute, and telecommunications materials shall be reviewed for infrastructure sensitivity before publication or handoff.

**20.2.8.5** Public-safe reporting may describe infrastructure themes, dependencies, resilience needs, and readiness questions without exposing vulnerabilities, locations, access points, operating details, security controls, failure modes, or sensitive dependencies.

**20.2.8.6** Handoff of Infrastructure-Sensitive Information shall require recipient capacity, purpose limitation, security obligations, confidentiality terms, public authority dependency review, cyber review, and correction pathway.

**20.2.8.7** Infrastructure-Sensitive Information records shall be correctionable. If such information is exposed, misclassified, routed improperly, used to imply public authority approval, or creates security, cyber, operational, or public safety risk, the record and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.2.9 Security-Sensitive Information

**20.2.9.1** **Security-Sensitive Information** shall mean information that may affect public safety, national security, community safety, organizational security, site security, personnel security, emergency management, conflict sensitivity, humanitarian safety, cyber safety, supply chain security, infrastructure security, or the safety of vulnerable persons, communities, participants, public authorities, providers, or facilities.

**20.2.9.2** Security-Sensitive Information shall be collected and used only where necessary, classified at an appropriate sensitivity level, access-controlled, and protected from public disclosure, improper routing, hostile exploitation, surveillance misuse, retaliation risk, or operational harm.

**20.2.9.3** Security-Sensitive Information shall not be included in public-safe reports, Nexus Universe materials, public-stage materials, media materials, sponsor materials, provider materials, National Model summaries, Regional Cluster Program Plan summaries, AEP Passport or Nexus Rail references, Docket or Grid summaries, or handoff materials unless expressly authorized and reviewed for security risk.

**20.2.9.4** Security-sensitive records may include security conditions, not sensitive details, where public-safe limitation language is necessary to explain why information is withheld.

**20.2.9.5** Particular care shall apply in fragile, conflict-affected, humanitarian, emergency, disaster, public health, infrastructure, cyber, and politically sensitive contexts.

**20.2.9.6** Handoff of Security-Sensitive Information shall require a lawful purpose, recipient capacity, confidentiality obligations, use restrictions, security controls, public authority dependency review where applicable, and correction pathway.

**20.2.9.7** Security-Sensitive Information records shall be correctionable. If such information is exposed, misclassified, routed improperly, used for unauthorized surveillance, creates retaliation risk, or increases security risk, the record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.2.10 Cyber-Sensitive Information

**20.2.10.1** **Cyber-Sensitive Information** shall mean information relating to cybersecurity architecture, vulnerabilities, credentials, access controls, keys, logs, incidents, threat models, systems configurations, network diagrams, APIs, software dependencies, exploitability, penetration testing, security assessments, cloud environments, AI systems, data pipelines, model pipelines, compute environments, edge systems, telecommunications systems, observability systems, digital twins, or other cyber-relevant materials that may create security risk if disclosed.

**20.2.10.2** Cyber-Sensitive Information shall be classified, access-controlled, protected, and handled under security-by-design and correctionability discipline. It shall not be disclosed through public-safe reporting, Nexus Universe materials, public-stage materials, provider materials, sponsor materials, media materials, National Model summaries, Regional Cluster Program Plan summaries, AEP Passport or Nexus Rail references, Docket or Grid summaries, or handoff materials unless expressly authorized and security-reviewed.

**20.2.10.3** Cyber-Sensitive Information shall include, without limitation:

1. vulnerabilities;
2. exploit paths;
3. credentials and secrets;
4. access logs;
5. security architecture;
6. network diagrams;
7. incident details;
8. threat intelligence;
9. system configurations;
10. software supply chain information;
11. AI model security information;
12. compute and cloud controls;
13. telecommunications and edge controls;
14. operational security information.

**20.2.10.4** Public-safe reporting may describe cyber themes, maturity questions, dependencies, and correction items without exposing exploitable detail.

**20.2.10.5** Handoff of Cyber-Sensitive Information shall require recipient security capacity, purpose limitation, confidentiality obligations, access controls, encryption or secure transfer where appropriate, incident-response contact, correction pathway, and archive controls.

**20.2.10.6** Public-good software, technical partner, provider candidate, observability, AEP Passport, Nexus Rail, Docket, Grid, and Nexus Core records shall be reviewed for cyber sensitivity before publication or handoff.

**20.2.10.7** Cyber-Sensitive Information records shall be correctionable. If cyber-sensitive material is exposed, misclassified, routed improperly, creates exploit risk, or is used beyond authorized scope, the record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.2.11 Confidentiality Breach Correction

**20.2.11.1** **Confidentiality Breach Correction** shall be the mandatory process through which unauthorized access, disclosure, publication, transmission, use, retention, translation, summarization, aggregation, handoff, or exposure of confidential, restricted, sensitive, protected, personal, public authority-sensitive, finance-sensitive, provider-sensitive, sponsor-sensitive, community-sensitive, Indigenous-sensitive where applicable, infrastructure-sensitive, security-sensitive, cyber-sensitive, health-sensitive, humanitarian-sensitive, or not-for-publication information is corrected.

**20.2.11.2** Confidentiality Breach Correction shall apply across all global, regional, national, Nexus Universe, AEP Passport, Nexus Rail, Docket, Grid, public-safe reporting, sponsorship, partnership, Working Group, Competence Cell, National Model, Regional Cluster Program Plan, handoff, National Consortium Company, Project SPV, provider, public authority learner, capital-reader, media, and archive pathways.

**20.2.11.3** Breach correction measures may include:

1. containment;
2. access suspension;
3. recipient notice;
4. source-owner notice;
5. public authority notice where required;
6. privacy notice where required;
7. takedown request;
8. deletion or return request;
9. correction of public materials;
10. reclassification;
11. credential rotation where applicable;
12. cyber incident response where applicable;
13. safeguard reattachment;
14. handoff suspension;
15. sponsor or provider restriction;
16. archive notation;
17. post-incident review.

**20.2.11.4** Breach correction shall be proportionate to harm risk, legal requirements, public-safe reporting requirements, affected persons, affected communities, affected public authorities, affected enterprise actors, and affected downstream recipients.

**20.2.11.5** Breach correction shall not expose additional sensitive information. Public clarification shall be limited where disclosure would worsen harm.

**20.2.11.6** Breach correction shall include root-cause review, including whether the breach arose from misclassification, access-control failure, public-safe reporting failure, sponsor or provider misuse, public authority confusion, finance-room misuse, safeguard failure, handoff failure, cyber failure, or archive failure.

**20.2.11.7** Confidentiality Breach Correction records shall themselves be correctionable. If a correction is incomplete, inaccurate, unsafe, not implemented, publicized beyond permission, or fails to prevent recurrence, the correction record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived.

***

### 20.3 Protected Knowledge and Community Safeguards

#### 20.3.1 Protected Knowledge Controls

**20.3.1.1** **Protected Knowledge Controls** shall govern any knowledge, information, data, practice, location, cultural expression, technical insight, ecological insight, community insight, Indigenous knowledge where applicable, traditional knowledge, sacred knowledge, confidential knowledge, security-sensitive knowledge, or place-based knowledge that requires heightened protection because disclosure, extraction, aggregation, digitization, commercialization, AI use, mapping, translation, or handoff may create harm.

**20.3.1.2** Protected Knowledge shall not be collected, recorded, stored, digitized, summarized, translated, modeled, mapped, analyzed, used in AI systems, used in digital twins, used in observability systems, included in public-safe reports, routed to AEP Passport or Nexus Rail pathways, entered into Docket or Grid records, transferred to sponsors or providers, or handed off to enterprise actors unless the applicable record expressly permits the use.

**20.3.1.3** Protected Knowledge Controls shall include, as applicable:

1. prior classification;
2. source permission;
3. use limitation;
4. access restriction;
5. non-publication condition;
6. non-translation condition;
7. non-digitization condition;
8. non-AI-use condition;
9. non-geospatial condition;
10. non-commercialization condition;
11. non-handoff condition;
12. withdrawal right;
13. correction right;
14. archive restriction.

**20.3.1.4** Protected Knowledge shall not be generalized into public claims where doing so could expose source communities, locations, practices, vulnerabilities, rights, or sensitive context.

**20.3.1.5** Where Protected Knowledge informs a public-safe output, the output shall use non-extractive limitation language and shall avoid revealing the knowledge itself unless expressly authorized.

**20.3.1.6** Protected Knowledge Controls shall apply to all participants, including sponsors, providers, public authorities, capital readers, media contributors, National Consortium Companies, Project SPVs, researchers, technical partners, and public-good software contributors.

**20.3.1.7** Protected Knowledge Control records shall be correctionable. If Protected Knowledge is collected without authority, exposed, mistranslated, summarized unsafely, mapped, digitized, modeled, used in AI, routed, commercialized, or handed off beyond permission, the record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.3.2 Indigenous Protocol Controls Where Applicable

**20.3.2.1** **Indigenous Protocol Controls Where Applicable** shall govern any participation, knowledge, data, lands, waters, cultural heritage, governance protocols, traditional knowledge, ecological knowledge, community knowledge, protected knowledge, consultation, accommodation, FPIC, consent, representation, public-safe reporting, Nexus Universe participation, AEP Passport or Nexus Rail routing, Docket or Grid input, handoff, National Consortium Company interface, or Project SPV interface involving Indigenous peoples, Tribal actors, Indigenous governance bodies, traditional authorities, or Indigenous knowledge holders.

**20.3.2.2** Indigenous Protocol Controls shall apply whether the context arises at global, regional, national, local, community, Nexus Universe, AEP Passport, Nexus Rail, Docket, Grid, public-safe reporting, handoff, enterprise, provider, sponsor, public authority, finance, media, research, technical, or public-good software level.

**20.3.2.3** Indigenous participation shall not imply consultation completion, accommodation completion, FPIC satisfaction, rights waiver, land approval, cultural approval, Indigenous data authorization, protected knowledge authorization, community consent, project approval, or execution authority.

**20.3.2.4** Indigenous Protocol Controls shall identify, as applicable:

1. relevant Indigenous governance or protocol context;
2. represented capacity, if any;
3. lawful basis for participation;
4. knowledge-use permissions;
5. data sovereignty conditions;
6. publication restrictions;
7. mapping restrictions;
8. AI-use restrictions;
9. protected knowledge conditions;
10. consent-boundary language;
11. withdrawal and correction rights;
12. downstream handoff restrictions.

**20.3.2.5** No person or institution shall claim to represent an Indigenous people, community, nation, Tribal actor, governance body, rights-holder, or protected knowledge holder unless a separate lawful and protocol-consistent record supports that representation.

**20.3.2.6** Public-safe reporting shall not simplify Indigenous protocol conditions into generic community participation language where doing so would weaken rights, protocols, consent boundaries, data sovereignty, protected knowledge controls, or lawful process requirements.

**20.3.2.7** Indigenous Protocol Control records shall be correctionable. If Indigenous participation is misrepresented, protocol conditions are ignored, protected knowledge is exposed, consent is implied, representation is overstated, data sovereignty is violated, or handoff occurs beyond permission, the relevant records, claims, materials, and pathways shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.3.3 Community Data Controls

**20.3.3.1** **Community Data Controls** shall govern data relating to communities, affected stakeholders, vulnerable groups, diaspora groups, youth, accessibility needs, local institutions, civil society actors, humanitarian settings, health-sensitive contexts, environmental justice issues, place-based vulnerabilities, community assets, community risks, local infrastructure, livelihoods, cultural practices, social networks, and other community-sensitive matters.

**20.3.3.2** Community data shall be collected and used only for lawful, necessary, proportionate, recorded, and safeguard-consistent purposes. It shall not be collected merely because a community participant attends a meeting, joins a room, participates in Nexus Universe, contributes to a National Model, or engages with a public-good pathway.

**20.3.3.3** Community Data Controls shall include:

1. purpose limitation;
2. data minimization;
3. access control;
4. public-safe classification;
5. non-extractive use conditions;
6. community-sensitive publication review;
7. consent-boundary language;
8. protected knowledge review;
9. privacy review;
10. handoff restrictions;
11. correction and withdrawal rights;
12. archive controls.

**20.3.3.4** Community data shall not be used for sponsor targeting, provider marketing, investor opportunity screening, procurement advantage, public authority overclaim, surveillance, enforcement, discrimination, community profiling, or extraction.

**20.3.3.5** Public-safe reporting may describe community data themes only through aggregated, non-identifying, permission-based, risk-aware summaries where appropriate.

**20.3.3.6** Handoff of community data shall require specific purpose, recipient restrictions, confidentiality obligations, safeguard attachment, and correction pathway.

**20.3.3.7** Community Data Control records shall be correctionable. If community data is collected unnecessarily, exposed, used extractively, misclassified, routed improperly, used as consent, or used for sponsor, provider, finance, procurement, surveillance, or execution purposes beyond the record, the data record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived.

***

#### 20.3.4 Sensitive Location Controls

**20.3.4.1** **Sensitive Location Controls** shall govern information about locations, sites, routes, corridors, facilities, infrastructure, community places, Indigenous sites where applicable, sacred sites, cultural sites, ecological sites, protected areas, vulnerable settlements, critical infrastructure, security-sensitive sites, humanitarian sites, health facilities, shelters, emergency facilities, data centers, telecommunications assets, energy assets, water assets, ports, airports, logistics nodes, or other locations where disclosure may create harm.

**20.3.4.2** Sensitive location information shall not be mapped, published, geocoded, digitized, included in dashboards, used in digital twins, used in AI models, disclosed in Nexus Universe materials, included in public-safe reports, routed to sponsors or providers, or handed off unless authorized and security-reviewed.

**20.3.4.3** Sensitive Location Controls shall include, as applicable:

1. geospatial sensitivity classification;
2. mapping restriction;
3. coordinate suppression;
4. aggregation;
5. anonymization where appropriate;
6. access restriction;
7. public-safe summary rules;
8. public authority dependency review;
9. community and Indigenous protocol review where applicable;
10. infrastructure and security review;
11. handoff restriction;
12. correction pathway.

**20.3.4.4** Public-safe reporting shall avoid exposing exact locations where such disclosure may increase risk to people, communities, infrastructure, protected knowledge, ecosystems, or security.

**20.3.4.5** AEP Passport, Nexus Rail, Docket, Grid, observability, dashboard, digital twin, and Nexus Universe records shall be reviewed for sensitive location risk before publication or handoff.

**20.3.4.6** Sensitive location information shall not be used to imply consent, site approval, infrastructure approval, land access, cultural approval, environmental approval, public authority approval, project authorization, or execution.

**20.3.4.7** Sensitive Location Control records shall be correctionable. If sensitive location information is exposed, mapped, digitized, routed, or published beyond permission, the record and affected materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.3.5 Public-Safe Summarization

**20.3.5.1** **Public-Safe Summarization** shall mean the process of converting sensitive, controlled, restricted, confidential, protected, public authority-sensitive, finance-sensitive, provider-sensitive, community-sensitive, Indigenous-sensitive where applicable, infrastructure-sensitive, security-sensitive, cyber-sensitive, health-sensitive, humanitarian-sensitive, or not-for-publication information into a lawful, non-extractive, non-identifying, limitation-preserving, correctionable public-safe summary.

**20.3.5.2** Public-safe summaries shall preserve the existence of relevant limitations without exposing sensitive content. Where the underlying record cannot be described safely, the summary shall state that certain information is withheld or restricted for safeguard, confidentiality, public authority, finance, protected knowledge, data, cyber, infrastructure, security, humanitarian, health, or other public-safe reasons.

**20.3.5.3** Public-Safe Summarization shall include review for:

1. source-record permission;
2. sensitivity classification;
3. identifiability risk;
4. protected knowledge exposure;
5. community or Indigenous protocol risk where applicable;
6. public authority overclaim;
7. finance reliance;
8. provider validation;
9. sponsor influence;
10. public warning confusion;
11. consent overclaim;
12. execution implication;
13. accessibility and translation accuracy;
14. correction readiness.

**20.3.5.4** Public-safe summaries shall not convert restricted information into public information merely by paraphrasing. Paraphrase, aggregation, translation, anonymization, or visualization shall be reviewed for residual disclosure risk.

**20.3.5.5** Public-safe summaries shall not be used to hide material limitations that would be necessary to prevent reliance.

**20.3.5.6** Public-safe summaries shall link to the applicable source record, claims register, public-safe reporting register, correction register, and archive status where appropriate.

**20.3.5.7** Public-Safe Summarization records shall be correctionable. If a summary is inaccurate, unsafe, overbroad, misleading, identifying, extractive, consent-implying, protected-knowledge-exposing, or execution-implying, it shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.3.6 Consent-Language Controls

**20.3.6.1** **Consent-Language Controls** shall govern all references to consent, approval, support, endorsement, acceptance, social license, consultation, accommodation, FPIC, community approval, Indigenous approval, rights-holder approval, local authorization, land access, cultural approval, protected knowledge authorization, environmental approval, or equivalent language.

**20.3.6.2** Consent-language shall not be used unless a competent and lawful record supports the exact claim and the claim is permitted by that record.

**20.3.6.3** The following shall not be described as consent: participation, attendance, contribution, public-safe listing, Nexus Universe visibility, safeguard-room participation, community input, Indigenous input where applicable, diaspora input, youth input, accessibility review, protected knowledge caution, National Model contribution, Regional Cluster Program Plan contribution, AEP Passport safeguard input, Nexus Rail safeguard condition, Docket input, Grid input, public-safe reporting input, handoff restriction, or silence.

**20.3.6.4** Consent-related terms shall be avoided where the record supports only learning, consultation initiation, stakeholder input, safeguard note, dependency mapping, public-safe reporting input, or unresolved condition.

**20.3.6.5** Where consent or consultation processes are external to the public-good stack, public-safe materials shall state that such processes, if required, must occur separately through competent and lawful channels.

**20.3.6.6** Consent-language shall receive heightened review in public-safe reports, sponsor materials, provider materials, investor materials, public authority materials, media materials, Nexus Universe materials, AEP Passport or Nexus Rail references, Docket or Grid summaries, handoff records, National Consortium Company materials, and Project SPV materials.

**20.3.6.7** Consent-language records shall be correctionable. If a consent-related statement is unsupported, ambiguous, misleading, extractive, overbroad, or execution-implying, the claim and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.3.7 No Extraction by Participation

**20.3.7.1** **No Extraction by Participation** shall mean that participation in Nexus-related activities shall not authorize extraction of knowledge, data, legitimacy, consent, community insight, Indigenous knowledge where applicable, public authority credibility, capital credibility, media visibility, technical capability, provider capability, sponsor influence, or public-good status beyond the recorded scope.

**20.3.7.2** A participant’s attendance, contribution, presence, title, identity, institutional affiliation, community role, Indigenous role where applicable, public authority role, capital role, provider role, sponsor role, media role, or public-stage visibility shall not be extracted into claims, marketing, public-safe reports, investor materials, provider materials, sponsor materials, procurement materials, public authority materials, AI systems, datasets, dashboards, digital twins, maps, or handoff materials unless the applicable record permits that use.

**20.3.7.3** No Extraction by Participation shall apply especially to:

1. communities;
2. Indigenous peoples and knowledge holders where applicable;
3. vulnerable groups;
4. youth;
5. diaspora participants;
6. public authorities;
7. public finance readers;
8. capital readers;
9. providers;
10. technical contributors;
11. media contributors;
12. sponsors;
13. research participants;
14. public-good software contributors.

**20.3.7.4** Participation shall not be converted into endorsement, consent, approval, financeability, provider validation, certification, procurement status, public authority action, public warning, project authorization, or execution.

**20.3.7.5** Records shall identify permitted uses of participant contributions and shall prohibit unapproved extraction, reuse, translation, aggregation, commercialization, AI training, public listing, or handoff.

**20.3.7.6** Participants may be granted withdrawal or correction rights according to the applicable record, law, and safeguard conditions.

**20.3.7.7** No Extraction by Participation records shall be correctionable. If participation is used beyond scope, extracted into unauthorized claims, used for sponsor or provider advantage, used as consent, used as public authority approval, used as finance signal, or routed beyond permission, the relevant records and materials shall be corrected, restricted, withdrawn, deleted where required, superseded, publicly clarified where necessary, or archived.

***

#### 20.3.8 Handoff Safeguard Conditions

**20.3.8.1** **Handoff Safeguard Conditions** shall be the safeguard terms attached to any record transmitted from the public-good stack to a 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, environmental process, data process, cyber process, or other downstream recipient.

**20.3.8.2** Handoff Safeguard Conditions shall include, where applicable:

1. source-record limitations;
2. community-sensitive information restrictions;
3. Indigenous protocol conditions where applicable;
4. protected knowledge restrictions;
5. consent-boundary language;
6. privacy and data-use restrictions;
7. sensitive location restrictions;
8. infrastructure and security restrictions;
9. cyber restrictions;
10. publication restrictions;
11. provider-neutrality conditions;
12. finance no-reliance conditions;
13. public authority dependency statements;
14. procurement dependency statements;
15. recipient use limitations;
16. correction and withdrawal rights.

**20.3.8.3** A recipient shall acknowledge that the handoff does not create consent, approval, public authority action, financeability, procurement status, provider validation, certification, project authorization, or execution authority.

**20.3.8.4** Handoff Safeguard Conditions shall remain attached to downstream enterprise documents, diligence files, finance-readiness files, procurement files, provider files, public authority materials, project files, SPV files, and public-safe materials.

**20.3.8.5** A recipient shall not strip, weaken, reinterpret, or ignore safeguard conditions because of commercial urgency, sponsor preference, provider preference, capital-reader interest, public authority interest, media interest, project momentum, or administrative convenience.

**20.3.8.6** If Handoff Safeguard Conditions cannot be preserved, the handoff shall be paused, restricted, withdrawn, or corrected.

**20.3.8.7** Handoff Safeguard Condition records shall be correctionable. If a handoff omits safeguards, a recipient breaches safeguard terms, protected knowledge is exposed, consent is implied, or execution occurs under unsafe assumptions, the handoff and affected downstream records shall be corrected, restricted, withdrawn, superseded, notified to affected recipients where appropriate, publicly clarified where necessary, or archived.

***

#### 20.3.9 Protected Knowledge Incident Response

**20.3.9.1** **Protected Knowledge Incident Response** shall be the mandatory response pathway for any suspected or confirmed unauthorized collection, access, disclosure, publication, translation, mapping, digitization, modeling, AI use, aggregation, commercialization, transfer, handoff, public-safe reporting, or downstream use of Protected Knowledge.

**20.3.9.2** Protected Knowledge incidents may include:

1. disclosure beyond permission;
2. public-safe summary failure;
3. unauthorized translation;
4. unauthorized geospatial mapping;
5. unauthorized AI or analytics use;
6. unauthorized digital twin use;
7. unauthorized observability use;
8. unauthorized handoff;
9. unauthorized sponsor or provider use;
10. unauthorized public authority or finance use;
11. unauthorized media use;
12. consent overclaim;
13. community or Indigenous protocol breach where applicable;
14. archive exposure;
15. cybersecurity compromise.

**20.3.9.3** Incident response shall include containment, access suspension, source-owner notice, affected community or Indigenous protocol notice where applicable and appropriate, recipient notice, takedown or deletion request, public-safe correction where necessary, handoff suspension, publication withdrawal, register correction, root-cause review, and recurrence prevention.

**20.3.9.4** Incident response shall not disclose additional Protected Knowledge. Public communications shall be carefully limited to prevent further exposure.

**20.3.9.5** Where applicable law, protocol, or record conditions require notification, consultation, withdrawal, deletion, return, restricted archive, or other remedy, the response shall follow those requirements.

**20.3.9.6** Protected Knowledge incidents shall be linked to affected public-safe reports, Nexus Universe materials, AEP Passport or Nexus Rail records, Docket or Grid records, handoff records, National Consortium Company records, Project SPV records, sponsor or provider materials, and archive records.

**20.3.9.7** Protected Knowledge Incident Response records shall be correctionable. If the incident response is incomplete, unsafe, inaccurate, delayed, publicized beyond permission, or fails to contain the harm, the response record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived under protective conditions.

***

#### 20.3.10 Protected Knowledge Correction

**20.3.10.1** **Protected Knowledge Correction** shall be the mandatory process through which records, summaries, translations, maps, dashboards, models, AI outputs, observability records, digital twins, Nexus Universe materials, public-safe reports, AEP Passport records, Nexus Rail records, Docket records, Grid records, handoff records, National Consortium Company records, Project SPV records, sponsor materials, provider materials, public authority materials, finance materials, media materials, and archives are corrected following a Protected Knowledge issue.

**20.3.10.2** Protected Knowledge Correction may include withdrawal, deletion where required, restriction, redaction, reclassification, public-safe clarification, recipient notice, translation withdrawal, map suppression, model-output removal, AI-use restriction, dashboard correction, handoff suspension, sponsor or provider restriction, source-owner notice, archive restriction, and supersession.

**20.3.10.3** Protected Knowledge Correction shall prioritize harm prevention, source respect, lawful obligations, protocol compliance, data sovereignty, community safety, Indigenous protocol integrity where applicable, and prevention of further dissemination.

**20.3.10.4** Correction shall not expose the Protected Knowledge being corrected. Public-facing corrections shall be limited to what is necessary to prevent reliance and shall not reveal sensitive content.

**20.3.10.5** Corrected or withdrawn Protected Knowledge shall not remain in AI training sets, public dashboards, maps, public-safe reports, sponsor materials, provider materials, media materials, handoff packages, enterprise records, or archives unless lawful retention is required under protective conditions.

**20.3.10.6** Protected Knowledge Correction shall include downstream tracing to identify where the material traveled and what derivative records were affected.

**20.3.10.7** Protected Knowledge Correction records shall themselves be correctionable. If a correction fails to remove exposure, fails to notify necessary recipients, fails to protect source conditions, or creates new exposure, the correction record shall be corrected, restricted, superseded, publicly clarified where necessary, or archived under protective conditions.

***

### 20.4 Public-Good Firewall

#### 20.4.1 Public-Good Stack Separation

**20.4.1.1** **Public-Good Stack Separation** shall mean the institutional, legal, operational, records, claims, finance, procurement, provider, safeguard, public authority, and execution separation between the Nexus public-good stack and the enterprise stack.

**20.4.1.2** The public-good stack shall include, as applicable, GCRI-aligned technical and evidence functions, GRF-aligned public-good legitimacy and claims functions, GRA-aligned finance-readiness and capital-readability functions, the Global Nexus Consortium, Regional Headquarters Consortiums, National Nexus Consortiums, Central Nexus Bureau support functions, Nexus Universe public-good operations, National Councils, Helix Councils, Working Groups, Competence Cells, public-safe reporting pathways, AEP Passport candidate pathways, Nexus Rail candidate pathways, Docket pathways, Grid pathways, and handoff-readiness pathways.

**20.4.1.3** The public-good stack shall form records, evidence, methods, observability, ontology, public-safe reports, readiness notes, learning rooms, safeguard records, claims controls, correction records, and handoff-readiness records. It shall not execute projects, procure providers, allocate finance, provide insurance, certify systems by default, grant consent, issue public warnings, command emergencies, operate projects, or act as a project developer, contractor, operator, fund, lender, underwriter, broker, public authority, or procurement body.

**20.4.1.4** Public-good stack roles shall not be collapsed into National Consortium Company roles, Project SPV roles, provider roles, sponsor roles, investor roles, insurer roles, donor roles, development actor roles, public finance roles, procurement roles, public authority roles, community consent roles, Indigenous consent roles where applicable, or project execution roles.

**20.4.1.5** Public-good stack records may inform downstream review only through lawful handoff, with limitations and safeguards preserved.

**20.4.1.6** Public-good stack communications shall include non-execution and role-separation language where needed to prevent confusion.

**20.4.1.7** Public-Good Stack Separation records shall be correctionable. If public-good bodies are described as executing, approving, financing, procuring, certifying, consenting, warning, commanding, or operating beyond their role, the records and claims shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.2 Enterprise Stack Separation

**20.4.2.1** **Enterprise Stack Separation** shall mean that National Consortium Companies, Project SPVs, providers, hosts, operators, contractors, investors, insurers, reinsurers, donors, development actors, public finance actors, procurement bodies, public authorities acting in their own lawful capacities, community processes, Indigenous governance processes where applicable, environmental processes, data processes, cyber processes, and project implementers operate outside the public-good stack under separate lawful authority, governance, diligence, contracts, liabilities, and correction obligations.

**20.4.2.2** Enterprise-stack actors may receive public-good records only through lawful handoff or another controlling record and shall not treat such records as approval, financeability, procurement status, provider validation, certification, consent, public authority action, project authorization, or execution authority.

**20.4.2.3** Enterprise-stack actors shall maintain their own records, including governance records, finance records, procurement records, provider records, safeguard records, public authority records, data and cyber records, environmental and social records, community and Indigenous process records where applicable, project records, insurance records, contract records, correction records, and archive records.

**20.4.2.4** Enterprise-stack actors shall not use public-good names, marks, records, reports, Nexus Universe visibility, AEP Passport candidate status, Nexus Rail routeability, Docket input, Grid input, or public-safe summaries to imply approval beyond the record.

**20.4.2.5** Enterprise Stack Separation shall prevent hidden agency, implied joint venture, shared liability, institutional merger, sponsor capture, provider capture, finance capture, public authority capture, consent overclaim, and execution drift.

**20.4.2.6** Where a person or institution holds both public-good and enterprise-stack roles, conflicts shall be disclosed, classified, managed, and recused where necessary.

**20.4.2.7** Enterprise Stack Separation records shall be correctionable. If enterprise actors collapse roles, misuse public-good records, imply Nexus approval, strip safeguards, create finance or procurement reliance, imply consent, or suggest execution authority from public-good participation, the relevant enterprise-interface and public-good records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.3 Sponsor Support Without Control

**20.4.3.1** **Sponsor Support Without Control** shall be a mandatory firewall condition that permits sponsors to support Nexus-related pathways without controlling public-good agenda, governance, records, participants, room access, public-safe reporting, technical outputs, public authority learning, finance-readiness, safeguard outcomes, AEP Passport or Nexus Rail routing, Docket or Grid classification, handoff conditions, correction, renewal, or archive.

**20.4.3.2** Sponsor support may include financial support, in-kind support, convening support, infrastructure support, knowledge support, technical support, public-safe reporting support, Nexus Universe support, regional or national activation support, council or helix support, Working Group support, Competence Cell support, or handoff-readiness support within recorded limits.

**20.4.3.3** Sponsor Support Without Control shall prohibit pay-to-approve, pay-to-certify, pay-to-rank, pay-to-access-public-authority, pay-to-access-capital-readers, pay-to-validate-provider, pay-to-influence-safeguards, pay-to-create-handoff, pay-to-enter-AEP-Passport, pay-to-enter-Nexus-Rail, pay-to-resolve-Docket, pay-to-pass-Grid, and pay-to-execute structures.

**20.4.3.4** Sponsor visibility shall not imply sponsor authority, endorsement of sponsor products or services, provider validation, financeability, procurement status, public authority approval, community consent, Indigenous consent, project authorization, Nexus-ready status, AEP Passport status, Nexus Node status, or execution.

**20.4.3.5** Sponsor conflicts shall be heightened where the sponsor is also a provider, investor, insurer, donor, public authority participant, media actor, host, technical platform, National Consortium Company participant, Project SPV participant, or downstream handoff recipient.

**20.4.3.6** Sponsor claims and materials shall be reviewed before use and shall preserve support-without-control language.

**20.4.3.7** Sponsor Support Without Control records shall be correctionable. If sponsor support becomes control, appears to become control, is publicly described as control, weakens safeguards, creates finance signaling, creates provider validation, creates public authority confusion, implies consent, or creates execution implication, the sponsor role, access, claim, support record, and public-safe listing shall be corrected, restricted, suspended, terminated, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.4 Provider Contribution Without Validation

**20.4.4.1** **Provider Contribution Without Validation** shall be a mandatory firewall condition that permits providers, vendors, operators, hosts, platforms, manufacturers, integrators, technology actors, infrastructure actors, consultants, professional firms, public-good software contributors, and other enterprise participants to contribute knowledge, technical input, software, demonstrations, capability information, infrastructure insight, observability inputs, Nexus Core support, Working Group input, Competence Cell input, Nexus Universe input, AEP Passport candidate input, Nexus Rail input, Docket input, Grid input, or handoff-readiness input without receiving validation by default.

**20.4.4.2** Provider contribution shall not create provider approval, preferred-provider status, qualification, certification, standards conformance, procurement status, product approval, service approval, public authority approval, financeability, community consent, Indigenous consent, project authorization, Nexus-ready status, AEP Passport status, Nexus Node status, or execution authority.

**20.4.4.3** Provider records shall identify contribution scope, provider-neutrality conditions, procurement-neutrality conditions, conflicts, sponsor relationships, public authority relationships, finance relationships, safeguard obligations, data and cyber obligations, public-safe listing permissions, permitted claims, prohibited claims, correction rights, and archive status.

**20.4.4.4** Provider-neutral capability mapping may identify capabilities, gaps, dependencies, interoperability issues, evidence needs, safeguards, and readiness questions, but shall not rank, endorse, validate, recommend, select, approve, or certify providers.

**20.4.4.5** Provider participation in Nexus Universe, public-good software, Working Groups, Competence Cells, AEP Passport pathways, Nexus Rail pathways, Docket pathways, Grid pathways, public-safe reporting, or handoff discussions shall not be used as marketing validation.

**20.4.4.6** Any downstream provider selection shall occur through separate lawful procurement, contracting, diligence, public authority, enterprise, National Consortium Company, Project SPV, or other competent process.

**20.4.4.7** Provider Contribution Without Validation records shall be correctionable. If provider participation is used as validation, procurement status, financeability, certification, public authority approval, consent, project authorization, Nexus-ready status, AEP Passport status, Nexus Node status, or execution authority, the provider record, claim, public-safe listing, and affected downstream materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.5 Capital Readability Without Capital Control

**20.4.5.1** **Capital Readability Without Capital Control** shall be a mandatory firewall condition that permits finance-readiness, capital-readability, insurance-readiness, donor relevance, development-readiness, public finance relevance, disaster-risk finance, diligence-gap, SPV-readiness, AEP Passport finance-layer, Nexus Rail finance-readiness, Docket, Grid, and handoff-readiness discussions without allowing capital actors to control the public-good stack.

**20.4.5.2** Capital readers, investors, insurers, reinsurers, donors, development actors, public finance readers, philanthropic actors, infrastructure finance professionals, risk-transfer experts, and finance-adjacent participants may contribute readability questions and diligence-gap insight only within no-reliance, non-advisory, non-solicitation, non-placement, non-underwriting, non-rating, non-guarantee, non-transactional, non-fiduciary, and non-executing limits.

**20.4.5.3** Capital participation shall not create financeability, bankability, insurability, investment interest, underwriting appetite, insurance approval, donor approval, development finance approval, public finance allocation, transaction readiness, capital commitment, project approval, or execution authority.

**20.4.5.4** Capital readers shall not control public-good agenda, public-safe reporting, public authority learning, technical evidence, safeguards, provider-neutrality, AEP Passport or Nexus Rail routing, Docket or Grid classification, handoff decisions, or Nexus Universe programming.

**20.4.5.5** Finance-readiness outputs shall preserve unresolved dependencies, including public authority, procurement, technical, provider, safeguard, community, Indigenous where applicable, environmental, social, data, cyber, governance, legal, tax, accounting, and project dependencies.

**20.4.5.6** Finance-readiness language shall be reviewed for regulated-perimeter discipline and no-reliance requirements before publication or handoff.

**20.4.5.7** Capital Readability Without Capital Control records shall be correctionable. If capital participation becomes control, creates finance signaling, implies financeability, suppresses safeguards, influences provider selection, implies public authority approval, or creates execution implication, the finance-readiness record, claim, access, and affected materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.6 Public Authority Learning Without Public Authority Capture

**20.4.6.1** **Public Authority Learning Without Public Authority Capture** shall be a mandatory firewall condition that permits public authorities, public-sector institutions, public finance readers, procurement learners, regulatory learners, municipal and subnational actors, infrastructure authorities, emergency management learners, public health bodies, Indigenous or Tribal public-governance bodies where applicable, and other public-sector participants to engage in learning without converting Nexus into a public authority or converting public authority participation into approval.

**20.4.6.2** Public authority learning may include dependency mapping, Government Portfolio awareness, procurement-neutral learning, regulatory-learning records, public finance relevance awareness, public-safe dashboard review, Nexus Universe room participation, AEP Passport public authority context layers, Nexus Rail public authority dependency routing, Docket and Grid public authority inputs, correction, and renewal.

**20.4.6.3** Public authority participation shall not create public authority approval, government endorsement, regulatory comfort, policy adoption, procurement status, public finance allocation, data authorization, emergency action, public warning, infrastructure approval, environmental approval, project authorization, or execution authority.

**20.4.6.4** Public authority actors shall not control public-good records, public-safe reports, finance-readiness outputs, provider-neutrality outcomes, sponsor arrangements, safeguard outcomes, community or Indigenous consent pathways where applicable, AEP Passport or Nexus Rail routing, Docket or Grid classification, handoff records, or Nexus Universe program architecture unless a separate lawful public authority process applies to its own official action.

**20.4.6.5** Public authority names, logos, titles, photographs, quotations, attendance, email domains, or official affiliations shall not be used to imply endorsement unless separately and lawfully authorized.

**20.4.6.6** Public authority language shall distinguish learning, observation, dependency mapping, official process, official decision, and execution.

**20.4.6.7** Public Authority Learning Without Public Authority Capture records shall be correctionable. If public authority learning is used as approval, procurement signal, public finance signal, regulatory comfort, public warning, project authorization, or execution, the relevant record, claim, report, public-safe listing, and downstream materials shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.7 Community Participation Without Consent Overclaim

**20.4.7.1** **Community Participation Without Consent Overclaim** shall be a mandatory firewall condition that permits communities, Indigenous actors where applicable, civil society, rights-aware organizations, diaspora actors, youth actors, accessibility advocates, protected knowledge holders where lawfully participating, environmental and social safeguard contributors, humanitarian actors, local institutions, public-interest researchers, and place-based legitimacy contributors to participate without their participation being converted into consent, approval, endorsement, authorization, social license, protected knowledge authorization, project approval, or execution authority.

**20.4.7.2** Community and Indigenous participation may support safeguard input, lived-risk knowledge, local context, vulnerability awareness, resilience priorities, accessibility needs, public-safe reporting input, protected knowledge cautions, National Model input, Regional Cluster Program Plan input, Nexus Universe safeguard rooms, AEP Passport safeguard layers, Nexus Rail safeguard conditions, Docket and Grid safeguard items, handoff restrictions, correction, and renewal.

**20.4.7.3** Participation shall not imply consultation completion, accommodation completion, FPIC satisfaction where applicable, rights waiver, land approval, cultural approval, Indigenous data authorization, protected knowledge authorization, environmental approval, community consent, Indigenous consent, local authorization, project authorization, or execution.

**20.4.7.4** No participant shall be treated as speaking for all affected communities, Indigenous peoples, rights-holders, future generations, diaspora groups, or places unless a separate lawful and protocol-consistent record supports that representation.

**20.4.7.5** Community and Indigenous safeguard records shall preserve confidentiality, protected knowledge restrictions, data restrictions, publication limits, consent-boundary language, withdrawal rights, correction rights, and handoff restrictions.

**20.4.7.6** Public-safe reporting shall not use community or Indigenous participation for legitimacy marketing, sponsor validation, provider validation, finance signaling, public authority approval, project authorization, or execution claims.

**20.4.7.7** Community Participation Without Consent Overclaim records shall be correctionable. If participation is tokenistic, extractive, misrepresented, used as consent, used as approval, used as legitimacy-washing, exposes protected knowledge, or supports execution implication, the relevant record, claim, public-safe report, handoff, or enterprise material shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.8 Media Visibility Without Legitimacy Capture

**20.4.8.1** **Media Visibility Without Legitimacy Capture** shall be a mandatory firewall condition that permits media, civic communication, public-safe reporting, public-interest storytelling, accessibility, translation, localization, knowledge translation, and public-stage visibility without allowing media visibility to become legitimacy, approval, public warning, finance signal, provider validation, sponsor promotion, consent, project authorization, or execution authority.

**20.4.8.2** Media and public-safe reporting contributors may support public meaning, transparency, knowledge translation, public-safe reporting, civic literacy, correction notices, archive summaries, Nexus Universe public-stage communication, National Model summaries, Regional Cluster Program Plan summaries, and public-good explanation within recorded claims controls.

**20.4.8.3** Media visibility shall not validate a participant, sponsor, provider, project, public authority relationship, finance pathway, AEP Passport candidate, Nexus Rail candidate, Docket item, Grid input, National Consortium Company, Project SPV, community claim, Indigenous claim where applicable, or handoff pathway.

**20.4.8.4** Public communications shall distinguish reporting from endorsement, public-safe publication from public warning, public meaning from approval, finance-readiness literacy from financeability, safeguard visibility from consent, and showcase from project authorization.

**20.4.8.5** Media materials shall not disclose restricted, confidential, protected knowledge, public authority-sensitive, finance-sensitive, provider-sensitive, sponsor-sensitive, community-sensitive, Indigenous-sensitive where applicable, cyber-sensitive, infrastructure-sensitive, security-sensitive, health-sensitive, humanitarian-sensitive, or not-for-publication information.

**20.4.8.6** Media and public-stage materials shall be corrected where they distort roles, overstate maturity, imply approval, create reliance, or expose sensitive information.

**20.4.8.7** Media Visibility Without Legitimacy Capture records shall be correctionable. If media visibility becomes legitimacy capture, sponsor promotion, provider validation, finance signaling, public authority endorsement, consent overclaim, public warning confusion, project authorization, or execution implication, the relevant media material, public-safe report, claim, listing, and record shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.9 Handoff Without Role Collapse

**20.4.9.1** **Handoff Without Role Collapse** shall be a mandatory firewall condition that allows public-good records to be transmitted to competent downstream recipients while preserving the separation between record formation, readiness, review, decision, finance, procurement, consent, project authorization, and execution.

**20.4.9.2** Handoff shall not convert the public-good stack into a 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.

**20.4.9.3** Handoff shall not make a downstream recipient the agent of the public-good stack, and shall not create hidden agency, implied joint venture, shared liability, institutional merger, public authority substitution, finance substitution, procurement substitution, safeguard substitution, consent substitution, or execution authority.

**20.4.9.4** Handoff records shall identify source, version, recipient, purpose, evidence basis, unresolved dependencies, public authority dependencies, finance dependencies, procurement dependencies, provider-neutrality conditions, sponsor-boundary conditions, safeguard and consent-boundary 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.

**20.4.9.5** Downstream recipients shall remain responsible for their own legal, financial, insurance, tax, accounting, technical, procurement, public authority, environmental, social, community, Indigenous where applicable, data, cyber, contract, project, implementation, operational, and liability processes.

**20.4.9.6** Public-safe handoff claims shall be rare, limitation-heavy, and approved only where publication does not create reliance or confusion.

**20.4.9.7** Handoff Without Role Collapse records shall be correctionable. If handoff is used as approval, financeability, procurement status, provider validation, certification, consent, project authorization, execution authority, agency, shared liability, or public authority substitution, the handoff record and affected downstream records shall be corrected, restricted, withdrawn, superseded, publicly clarified where necessary, or archived.

***

#### 20.4.10 Firewall Correction

**20.4.10.1** **Firewall Correction** shall be the mandatory process through which any breach, weakening, ambiguity, overclaim, role collapse, public-good-to-enterprise confusion, sponsor control, provider validation, capital control, public authority capture, community consent overclaim, media legitimacy capture, handoff misuse, or execution implication is corrected.

**20.4.10.2** Firewall Correction may apply to global, regional, national, Nexus Universe, AEP Passport, Nexus Rail, Docket, Grid, public-safe reporting, sponsorship, partnership, Working Group, Competence Cell, National Model, Regional Cluster Program Plan, handoff, National Consortium Company, Project SPV, provider, public authority learner, capital-reader, media, safeguard, and archive records.

**20.4.10.3** Firewall Correction triggers shall include, without limitation:

1. public-good stack described as executing;
2. enterprise actor described as public-good authority;
3. sponsor influence over public-good outputs;
4. provider participation described as validation;
5. capital-reader participation described as financeability;
6. public authority learning described as approval;
7. community or Indigenous participation described as consent;
8. media visibility used as legitimacy capture;
9. handoff described as project authorization;
10. AEP Passport or Nexus Rail candidate status described as approval;
11. Docket or Grid input described as resolution or maturity approval;
12. public-safe reporting described as public warning;
13. National Consortium Company or Project SPV claims collapse public-good and enterprise roles;
14. protected knowledge or sensitive data exposed through role collapse.

**20.4.10.4** Firewall Correction measures may include claim withdrawal, public-safe clarification, role reclassification, access restriction, sponsor restriction, provider-candidate restriction, capital-reader restriction, public authority reference correction, safeguard reattachment, handoff suspension, enterprise-interface restriction, mark-use restriction, publication withdrawal, record supersession, correction notice, termination, non-renewal, and archive notation.

**20.4.10.5** Urgent Firewall Correction shall occur where delay may create reliance, public authority confusion, finance signaling, procurement advantage, provider validation, certification drift, consent overclaim, protected knowledge exposure, public warning confusion, market confusion, reputational misuse, or execution implication.

**20.4.10.6** Firewall Correction shall preserve public-safe discipline and shall not expose sensitive information merely to correct role collapse.

**20.4.10.7** Firewall Correction records shall themselves be correctionable. If a correction fails to restore role separation, is incomplete, inaccurate, unsafe, publicized beyond permission, or creates a new 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/xx.-safeguards.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.