# XX. SAFEGUARDS

Safeguards protect people, communities, and sensitive knowledge across Nexus records, rooms, and releases.

They set boundaries for participation, consent, access, correction, public-safe communication, and lawful handoff without implying approval, deployment, or execution.

## 20.1 Safeguard Doctrine

### 20.1.1 Safeguards as Public-Good Legitimacy Infrastructure

Safeguards are the public-good legitimacy infrastructure through which Nexus protects people, communities, rights, dignity, accessibility, protected knowledge, youth, vulnerable groups, humanitarian contexts, Indigenous protocols where applicable, community trust, data integrity, public-safe reporting, lawful participation, and correctionability across Nexus records, Campaigns, Reports, Studio workflows, DRI outputs, Observatory summaries, National Portfolios, Nexus Universe arenas and rooms, Foundry builds, Academy pathways, Marketplace listings, Registry records, Grid and TRL inputs, finance-readiness records, public authority learning records, and lawful handoff dependency notes.

Safeguards are not a decorative ethics layer added after technical work. They are a condition of public-good validity. A Nexus object that is technically impressive but extractive, inaccessible, privacy-invasive, dignity-harming, youth-unsafe, community-insensitive, protected-knowledge-exposing, Indigenous-protocol-violating where applicable, humanitarian-context-insensitive, public-authority-overclaiming, finance-overclaiming, or uncorrectable is not a mature public-good object. Safeguards therefore operate at intake, classification, design, review, publication, room access, Campaign activation, public-safe transformation, Marketplace listing, Registry update, Nexus Universe routing, Grid and TRL review, finance-readiness preparation, public authority learning, handoff dependency preparation, correction, withdrawal, recall, and archive.

A Safeguard Record should identify:

1. safeguard context, including community, youth, disability, humanitarian, Indigenous protocol where applicable, protected knowledge, privacy, dignity, accessibility, language, geospatial sensitivity, health sensitivity, infrastructure sensitivity, public-safe reporting, or handoff dependency context;
2. object or pathway covered, including Report, DRI output, Observatory output, Studio workflow, Campaign, National Portfolio object, Nexus Universe room, Foundry build, Academy object, Registry record, Marketplace listing, Grid input, finance-readiness record, public authority learning record, or handoff dependency note;
3. safeguard status, including unreviewed, preliminary review, safeguard-conditioned, public-safe transformed, restricted, controlled-room-only, community-review-required, Indigenous-protocol-review-required where applicable, youth-restricted, accessibility-remediation-required, corrected, withdrawn, recalled, archived, or non-continuing;
4. participant and knowledge controls, including consent-boundary notices, privacy limits, protected knowledge restrictions, community dignity controls, youth protection, accessibility, language access, non-extractive practices, and correction routes;
5. release and access controls, including public, controlled-public, community-review-only, youth-restricted, secure-room, data-room, protected knowledge room, public authority learning-only, handoff-recipient-only, sealed, deletion-required, archive-only, or non-current status;
6. boundary notices, confirming that safeguard review is not community consent, Indigenous consent where applicable, public authority approval, legal permission, deployment authorization, procurement approval, financeability, insurability, donor approval, public finance allocation, or execution.

Safeguards create legitimacy by making public-good work answerable to those who may be affected by it. They preserve the difference between participation and consent, visibility and dignity, data and rights, knowledge and permission, learning and authority, readiness and approval, handoff context and execution.

### 20.1.2 Community Participation Without Consent Overclaim

Community participation without consent overclaim is the rule that community attendance, comments, stories, signatures, pledges, survey responses, Campaign activity, public-safe storytelling, Studio participation, National Portfolio input, Nexus Universe participation, Working Group participation, Competence Cell participation, Academy participation, DRI contribution, Observatory need contribution, Reports review, safeguard-room participation, or handoff-awareness discussion shall not be represented as consent, approval, endorsement, authorization, land access, data-use permission, AI-use permission, publication permission, deployment permission, implementation permission, public authority approval, or execution authority unless a separate lawful consent pathway expressly creates that effect.

Community participation is valuable because it brings lived-risk knowledge, local context, dignity concerns, accessibility needs, language needs, historical context, system dependency knowledge, public-safe reporting insight, safeguard concerns, and correction signals. It is not valid when converted into implied permission.

A Community Participation Boundary Record should identify:

1. community context, including place, affected group, local institution, civil society pathway, youth pathway, accessibility context, language context, public-safe context, National Portfolio relationship, Campaign relationship, Nexus Universe relationship, DRI relationship, Observatory relationship, Studio relationship, or handoff context;
2. participation type, including attendance, comment, story, signature, pledge, survey, workshop, Campaign participation, Academy participation, Studio participation, public-safe review, safeguard review, Working Group participation, Competence Cell participation, or handoff-awareness participation;
3. consent-sensitive issues, including data use, AI use, publication, translation, photography, video, mapping, geospatial display, protected knowledge, land or facility access, implementation, deployment, public authority routing, finance-readiness routing, donor routing, insurance routing, or handoff routing;
4. required boundary language, including participation-not-consent, story-not-consent, attendance-not-consent, signature-not-consent, pledge-not-consent, community-input-not-approval, public-safe-summary-not-permission, and Campaign-support-not-deployment-authorization;
5. separate consent pathway, including community process, institutional process, legal process, ethics process, data agreement, public authority process, Indigenous governance process where applicable, contractual process, or other lawful permission route;
6. correction pathway, including correction of consent overclaim, material restriction, story withdrawal, data restriction, geospatial correction, public-safe correction, public repair, notification, archive, or non-continuation.

Community participation strengthens Nexus only when it remains honest. Participation may inform records; consent must be separately obtained where consent is required.

### 20.1.3 Indigenous Protocols Where Applicable

Indigenous protocols where applicable are the safeguard rules, review pathways, consent boundaries, knowledge protections, governance interfaces, language controls, data controls, publication limits, mapping limits, AI-use limits, benefit-sharing considerations where applicable, and correction mechanisms that apply when Nexus work involves Indigenous peoples, Indigenous institutions, Indigenous lands or territories, Indigenous knowledge, Indigenous data, Indigenous ecological knowledge, Indigenous cultural context, Indigenous governance processes, Indigenous youth, Indigenous community participation, or Indigenous protocol-sensitive matters.

Nexus shall not treat Indigenous participation, invitation, attendance, story contribution, Campaign participation, data contribution, DRI contribution, Observatory signal, Studio participation, public-safe review, National Portfolio inclusion, Nexus Universe participation, or public authority interface as Indigenous consent, approval, endorsement, knowledge release, data-use permission, AI-use permission, mapping permission, publication permission, land access permission, deployment authorization, or implementation authorization unless a separate lawful and protocol-appropriate pathway expressly records such effect.

An Indigenous Protocol Safeguard Record, where applicable, should identify:

1. protocol context, including Indigenous people, community, institution, governance pathway, knowledge holder, territorial context, data context, cultural context, ecological context, language context, youth context, protected knowledge context, or public authority relationship;
2. object or activity covered, including Campaign, Report, DRI output, Observatory summary, Studio workflow, National Portfolio object, Nexus Universe room, Academy pathway, Foundry build, Registry record, Marketplace listing, Grid input, finance-readiness record, public authority learning record, or handoff dependency note;
3. protocol-sensitive material, including knowledge, data, story, map, image, recording, translation, cultural reference, ecological information, geospatial information, health information, youth information, community context, or public-safe summary;
4. required review and permission pathway, including Indigenous governance process where applicable, community review, knowledge-holder review, data steward review, public-safe review, protected knowledge review, legal boundary review, and correction pathway;
5. use restrictions, including no publication, no quotation, no translation, no mapping, no AI use, no model training, no public display, no transfer, no handoff, no commercialization, no public authority routing, no finance-readiness routing, or archive-only handling unless separately permitted;
6. boundary notices, confirming that Indigenous participation is not Indigenous consent by implication and that Nexus records do not override Indigenous governance, protected knowledge restrictions, data sovereignty, community protocols, or lawful consent requirements.

Indigenous protocol safeguards must be applied with humility, specificity, and correctionability. Where Nexus lacks adequate protocol clarity, the more protective pathway shall apply.

### 20.1.4 Protected Knowledge Restrictions

Protected knowledge restrictions are the controls that apply to knowledge, data, context, maps, stories, cultural information, ecological information, security-sensitive information, infrastructure-sensitive information, cyber-sensitive information, health-sensitive information, youth-sensitive information, community-sensitive information, Indigenous protocol-sensitive knowledge where applicable, public authority-sensitive information, handoff-recipient-only information, or other materials that cannot be safely treated as open public-good content.

Protected knowledge may be useful for learning, risk understanding, DRI interpretation, Observatory needs, Studio workflows, National Portfolio preparation, safeguard review, public authority learning, or handoff dependency clarification. Usefulness does not create openness. Nexus shall not publish, summarize, translate, map, cite, train AI on, transfer, display, route, or hand off protected knowledge unless the applicable rights, permissions, protocols, safeguards, and review conditions permit that use.

A Protected Knowledge Restriction Record should identify:

1. protected knowledge class, including community-protected, Indigenous protocol-sensitive where applicable, cultural, ecological, security-sensitive, infrastructure-sensitive, cyber-sensitive, health-sensitive, youth-sensitive, legal-sensitive, public authority-sensitive, commercially sensitive where appropriate, or handoff-recipient-only knowledge;
2. custodian and steward context, including knowledge holder, community pathway, Indigenous governance pathway where applicable, institutional steward, data steward, public-safe steward, safeguard steward, legal boundary steward, archive steward, and correction contact where appropriate;
3. access controls, including approved participants, access class, confidentiality, no-download, no-copy, no-AI, no-training, secure-room requirement, data-room requirement, protected knowledge room requirement, output review, expiration, revocation, sealing, deletion where required, and archive restrictions;
4. use restrictions, including no publication, limited summary, public-safe transformation only, no translation without review, no mapping, no geospatial disclosure, no AI processing, no training use, no handoff without separate authority, no citation, no public display, no Marketplace display, no Registry public display, or archive-only use;
5. release conditions, including public-safe transformation, aggregation, anonymization, masking, community review, Indigenous protocol review where applicable, legal review, public authority boundary review, handoff review, correction review, and archive classification;
6. boundary notices, confirming that access to protected knowledge is not permission to publish, reuse, translate, map, train AI, transfer, hand off, commercialize, deploy, or execute.

Protected knowledge restrictions protect the public-good stack from becoming an extraction mechanism. The fact that Nexus can see something does not mean Nexus may show it, use it, or transfer it.

### 20.1.5 Youth Safeguards

Youth safeguards are the controls that protect children, adolescents, students, youth participants, early-career learners where relevant, youth groups, school-based participants, youth Campaign participants, youth Academy participants, youth Nexus Universe participants, youth data subjects, youth storytellers, youth volunteers, and youth contributors from privacy risks, exploitation, unsafe contact, inappropriate labor classification, public exposure, coercion, tokenization, harassment, data misuse, AI misuse, reputational harm, and participation overclaim.

Youth participation can be powerful for learning, public-good mobilization, intergenerational legitimacy, skills formation, Campaigns, Academy pathways, Risk Academy pathways, Nexus Universe, public-safe storytelling, and public-good contribution. It must be protected by age-appropriate design, consent and permission rules, guardian or institutional requirements where applicable, privacy controls, safe-contact rules, workload limits, no-disguised-labor rules, accessibility, anti-harassment, and correction pathways.

A Youth Safeguard Record should identify:

1. youth context, including age class where appropriate, learner status, school or university context, Campaign pathway, Academy pathway, Risk Academy pathway, volunteer pathway, Studio pathway, Nexus Universe pathway, story pathway, data context, or contribution context;
2. participation controls, including age-appropriate onboarding, guardian or institutional permissions where required, safe-contact rules, supervision, anti-harassment controls, workload controls, no disguised labor, no employment by implication, withdrawal rights, and grievance pathway;
3. data and publication controls, including youth data minimization, privacy, image and media permission, public display limits, anonymization, pseudonymization, no geolocation exposure, no sensitive profiling, no automated ranking, no AI training without explicit permission where lawful, and archive limits;
4. learning and recognition controls, including learning records, proof receipts, ILA or equivalent learner record where appropriate, iCRS recognition where appropriate, micro-credential inputs where applicable, public-safe recognition, no employment guarantee, no professional qualification by implication, and correction pathways;
5. risk controls, including cyber safety, safe communications, public-safe story review, mental health sensitivity where relevant, humanitarian sensitivity, community sensitivity, accessibility, disability inclusion, non-stigmatizing language, and protection from tokenization;
6. boundary notices, confirming that youth participation is not labor exploitation, employment, public authority approval, consent by community, procurement qualification, professional licensure, deployment authorization, or execution.

Youth safeguards must be applied before participation is mobilized, not after exposure occurs.

### 20.1.6 Disability Inclusion

Disability inclusion is the safeguard doctrine that Nexus records, Campaigns, Reports, Academy pathways, Risk Academy materials, Studio workflows, DRI outputs, Observatory summaries, dashboards, Marketplace listings, Registry records, Nexus Universe rooms, public authority learning rooms, readiness rooms, secure rooms, data rooms, public-safe stories, volunteer pathways, Working Groups, Competence Cells, Foundry builds, and handoff dependency notes should be designed, reviewed, communicated, and corrected to support accessibility, reasonable accommodation where applicable, inclusive participation, non-discrimination, dignity, and usability by persons with disabilities.

Disability inclusion is not merely an accessibility checkbox. It affects how risk is observed, how public-safe reporting is written, how dashboards are visualized, how warnings are discussed in learning contexts, how Studio scenarios are interpreted, how Academy pathways are delivered, how Campaigns are mobilized, how public authority learning is structured, and how lawful handoff dependencies are recorded.

A Disability Inclusion Safeguard Record should identify:

1. accessibility context, including digital accessibility, physical accessibility, communication accessibility, language accessibility, cognitive accessibility, sensory accessibility, mobility access, assistive technology compatibility, low-bandwidth access, plain-language needs, captioning, interpretation, alternative text, accessible formats, and participation accommodations;
2. object or pathway covered, including Report, dashboard, Studio workflow, DRI output, Observatory summary, Campaign, Academy module, Nexus Universe room, Marketplace listing, Registry record, Grid input, public authority learning room, readiness room, secure room, data room, or handoff dependency note;
3. review requirements, including accessibility review, plain-language review, captioning review, visual design review, screen-reader review where applicable, mobility access review, event accessibility review, disability stakeholder review where appropriate, public-safe review, and correction review;
4. participation protections, including accommodation request process, accessible onboarding, safe communication, non-discrimination, anti-harassment, non-tokenization, privacy, youth-disability safeguards where applicable, and correction pathway;
5. release conditions, including accessibility status, remediation required, alternative format required, accessible summary required, room accommodation required, public-safe accessible release, restricted release, correction, archive, or non-continuation;
6. boundary notices, confirming that accessibility status is a safeguard and usability record, not certification, legal compliance determination, procurement approval, public authority approval, consent, deployment authorization, or execution.

Disability inclusion strengthens Nexus because systems that cannot be accessed by affected participants cannot claim public-good maturity.

### 20.1.7 Humanitarian Sensitivity

Humanitarian sensitivity is the safeguard doctrine that Nexus work involving crisis contexts, disaster-affected people, conflict-affected settings, displacement, migration, health vulnerability, food insecurity, water insecurity, energy insecurity, infrastructure failure, climate shocks, biodiversity loss, public health risk, cyber disruption, or other humanitarian conditions must avoid harm, exploitation, stigma, politicization, unsafe exposure, aid-prioritization overclaim, public warning overclaim, public authority substitution, community consent overclaim, and execution overclaim.

Humanitarian sensitivity applies to Campaigns, public-safe storytelling, DRI outputs, Observatory summaries, Studio scenarios, Reports, National Portfolios, Nexus Universe rooms, Academy pathways, Risk Academy materials, Labs streams, Foundry builds, Marketplace listings, Registry records, finance-readiness records, donor-readiness records, public finance learning records, and handoff dependency notes.

A Humanitarian Sensitivity Safeguard Record should identify:

1. humanitarian context, including disaster, conflict, displacement, migration, food insecurity, water insecurity, health crisis, energy crisis, infrastructure disruption, climate shock, nature shock, cyber disruption, community vulnerability, or protection concern;
2. affected participant or population context, including privacy, dignity, security, youth, disability, gender-related risk where relevant without unnecessary profiling, community sensitivity, Indigenous protocol where applicable, protected knowledge, geospatial sensitivity, and public-safe reporting limits;
3. risk of harm, including stigmatization, unsafe exposure, aid-prioritization overclaim, political misuse, public authority overclaim, public warning overclaim, donor overclaim, media exploitation, retraumatization, data misuse, AI misuse, or handoff misuse;
4. controls, including non-stigmatizing language, anonymization, aggregation, geospatial masking, public-safe transformation, trauma-informed review where appropriate, humanitarian actor review where appropriate, community safeguard review, protected knowledge restrictions, youth safeguards, and correction routes;
5. boundary rules, including no aid prioritization by implication, no public warning, no emergency command, no public authority action, no donor commitment, no public finance allocation, no procurement priority, no consent by participation, no deployment authorization, and no execution;
6. correction pathway, including public-safe correction, media-safe correction, story withdrawal, data restriction, dashboard correction, Report correction, Campaign correction, public repair, archive, or non-continuation.

Humanitarian sensitivity ensures that Nexus public-good work does not turn vulnerability into visibility without protection.

### 20.1.8 Non-Extractive Knowledge Practices

Non-extractive knowledge practices are the safeguard rules that prevent Nexus from taking knowledge, stories, data, lived experience, community context, Indigenous knowledge where applicable, youth contributions, volunteer labor, local expertise, public authority learning, provider contributions, university research, humanitarian context, or protected knowledge without fair purpose, clear boundaries, appropriate permission, recognition, safeguards, correction pathways, and benefit to the public-good record.

Non-extractive practice requires Nexus to ask why knowledge is being collected, who benefits, what risks arise, what rights apply, what permissions are needed, what public-safe transformation is required, what recognition is appropriate, what must remain restricted, what must be returned to participants, what must be corrected, and what must be archived or deleted.

A Non-Extractive Knowledge Practice Record should identify:

1. knowledge source, including community participant, Indigenous participant where applicable, youth participant, volunteer, learner, public authority learner, university researcher, provider contributor, humanitarian actor, civil society actor, local expert, data steward, or knowledge holder;
2. knowledge class, including story, data, metadata, observation, risk context, lived experience, ecological knowledge, technical knowledge, public authority context, humanitarian context, accessibility insight, translation, review note, or protected knowledge;
3. purpose and benefit, including public-good purpose, participant benefit where appropriate, community benefit where appropriate, learning purpose, DRI improvement, Observatory need, public-safe reporting, Academy conversion, Foundry task, National Portfolio update, safeguard improvement, or handoff dependency clarification;
4. permission and recognition, including consent where required, participation boundary, attribution, anonymity, pseudonymity, iCRS recognition where appropriate, ILA or learning record where appropriate, contribution record, proof receipt, restriction, withdrawal right, and correction pathway;
5. use and reuse limits, including data-use label, AI-use label, public-safe transformation, no-training rule, no-publication rule, no-handoff rule, no-commercialization rule, no-procurement-use rule, no-finance-use rule, no-public-authority-use rule unless separately recorded, and archive rule;
6. boundary notices, confirming that contribution is not unlimited permission, participation is not consent, visibility is not endorsement, and knowledge access is not authorization to reuse, transfer, deploy, commercialize, or execute.

Non-extractive practice is the ethical operating system of Nexus knowledge work. It ensures that knowledge becomes public-good memory without becoming appropriation.

### 20.1.9 Community-Facing Correction

Community-facing correction is the safeguard doctrine that communities, youth participants, civil society actors, Indigenous participants where applicable, public-interest participants, affected stakeholders, accessibility advocates, humanitarian actors, and other non-institutional participants must have visible, usable, safe, and non-retaliatory pathways to correct Nexus records, stories, summaries, dashboards, Reports, Campaign materials, DRI outputs, Observatory summaries, Studio outputs, National Portfolio objects, Nexus Universe materials, Marketplace listings, Registry records, Grid inputs, finance-readiness records, public authority learning records, and handoff dependency notes that affect them.

Community-facing correction is required because errors in public-good systems can harm dignity, privacy, reputation, safety, consent boundaries, cultural protocols, public authority relationships, donor relationships, public finance perception, media narratives, and future handoff contexts. Correction pathways must be understandable, accessible, multilingual where appropriate, low-burden, trauma-informed where relevant, and connected to real correction authority.

A Community-Facing Correction Record should identify:

1. correction source, including community participant, local institution, civil society actor, youth participant, accessibility advocate, Indigenous participant or institution where applicable, humanitarian actor, public-interest participant, affected stakeholder, or authorized representative;
2. affected object, including story, quote, image, map, dashboard, DRI output, Observatory summary, Studio workflow, Report, Campaign material, National Portfolio object, Nexus Universe record, Registry record, Marketplace listing, Grid input, finance-readiness record, public authority learning record, handoff dependency note, proof receipt, iCRS record, ILA record, or archive record;
3. issue class, including factual error, dignity concern, privacy concern, consent overclaim, protected knowledge exposure, Indigenous protocol issue where applicable, youth safeguard issue, accessibility issue, translation error, geospatial exposure, stigmatizing language, public authority overclaim, donor overclaim, finance or insurance overclaim, media overclaim, deployment overclaim, or execution overclaim;
4. response pathway, including acknowledgement, review, restriction, correction, redaction, removal, public-safe revision, public repair, withdrawal, recall, sealing, deletion where required, archive, or non-continuation;
5. protection controls, including reporter privacy, anti-retaliation, community safety, youth protection, protected knowledge protection, confidentiality, accessibility, language access, and escalation;
6. closure and propagation, including correction completed, correction denied with reason, notification, downstream updates, Registry correction, Marketplace correction, Report correction, Campaign correction, public-safe summary correction, handoff note correction, archive update, and recurrence-prevention action.

Community-facing correction makes safeguards enforceable from the perspective of those affected, not only from institutional review teams.

### 20.1.10 Public-Safe Summaries

Public-safe summaries are safeguard-controlled summaries that transform sensitive, complex, restricted, technical, community-sensitive, Indigenous protocol-sensitive where applicable, youth-sensitive, health-sensitive, geospatial-sensitive, cyber-sensitive, infrastructure-sensitive, public authority-sensitive, finance-sensitive, insurance-sensitive, donor-sensitive, or handoff-sensitive information into language and formats that can be safely shared with the intended audience without exposing protected knowledge, personal data, sensitive locations, security vulnerabilities, unreviewed claims, consent implications, public warning implications, public authority implications, finance implications, insurance implications, donor implications, procurement implications, deployment implications, or execution implications.

A public-safe summary is not necessarily open data, raw evidence, official warning, public authority record, official policy, procurement document, finance document, insurance document, donor commitment, consent record, deployment authorization, or execution instruction. It is a controlled communication product.

A Public-Safe Summary Record should identify:

1. source material, including Report, DRI output, Observatory summary, Studio workflow, National Portfolio object, Campaign record, Foundry build, Academy object, Nexus Universe output, Registry record, Marketplace listing, Grid input, finance-readiness record, public authority learning record, safeguard record, protected knowledge record, or handoff dependency note;
2. summary purpose, including public learning, Campaign communication, Academy use, public authority learning, community feedback, media-safe communication, Marketplace display, Registry display, Nexus Universe release, readiness room use, donor-reader use, public finance learning use, or handoff-awareness use;
3. transformation controls, including redaction, aggregation, anonymization, geospatial masking, uncertainty language, limitation language, non-stigmatizing language, accessibility, plain-language version, translation review, public authority boundary language, finance and insurance boundary language, donor boundary language, procurement boundary language, consent boundary language, deployment boundary language, and execution boundary language;
4. review status, including public-safe review, data review, AI review, cyber review, privacy review, geospatial review, safeguard review, community review, Indigenous protocol review where applicable, youth safeguard review, humanitarian sensitivity review, public authority boundary review, finance and insurance boundary review, legal boundary review, correction review, and archive status;
5. release class, including public, controlled-public, community-review-only, National Node-visible, public authority learning-only, media-safe, Campaign-safe, Marketplace-safe, Registry-safe, readiness-room-safe, secure-room summary, data-room summary, handoff-context summary, restricted, archive-only, or non-current;
6. boundary notices, confirming that public-safe summary release is not raw data release, open permission, public warning, official policy, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.

Public-safe summaries allow Nexus to communicate responsibly. They are the bridge between sensitive truth and safe public meaning.

The final Safeguard Doctrine rule is: safeguards are public-good legitimacy infrastructure. Community participation shall not be converted into consent; Indigenous protocols shall apply where relevant; protected knowledge shall remain restricted; youth shall be protected; disability inclusion shall be designed in; humanitarian sensitivity shall control vulnerable contexts; knowledge practices shall be non-extractive; correction shall be community-facing; and public-safe summaries shall communicate safely without converting learning, evidence, or participation into authority, permission, approval, deployment, or execution.

## 20.2 Community Safeguards

### 20.2.1 Lived-Risk Knowledge

Lived-risk knowledge is community knowledge arising from direct experience of hazards, disruption, vulnerability, adaptation, resilience, public service gaps, infrastructure failure, water stress, food insecurity, energy insecurity, health-system pressure, biodiversity loss, climate and nature shocks, cyber-physical disruption, displacement, degraded-mode conditions, local recovery, informal coping systems, social protection gaps, and other real-world risk conditions. Nexus shall treat lived-risk knowledge as a serious public-good input, not as anecdotal decoration, testimonial marketing, media content, or extractive story material.

Lived-risk knowledge may inform DRI records, Observatory needs, National Portfolio records, Studio scenarios, Reports, Campaigns, Academy pathways, Risk Academy materials, Foundry needs, Nexus Universe rooms, safeguard records, public authority learning records, finance-readiness questions, donor-readiness questions, public finance relevance questions, protection-gap records, risk-layering records, and handoff dependency notes. It shall not be converted into raw data, public warning, public authority decision, donor priority, insurance score, investment signal, procurement priority, community consent, deployment authorization, or execution instruction.

A Lived-Risk Knowledge Safeguard Record should identify:

1. knowledge source, including community participant, affected stakeholder, local organization, civil society actor, youth participant, humanitarian actor, public-interest participant, accessibility advocate, Indigenous participant where applicable, or other lawful knowledge contributor;
2. risk context, including hazard, system failure, WFEH-B dependency, DRR context, DRI need, Observatory need, public authority learning issue, protection gap, risk-layering question, safeguard issue, public-safe reporting need, or handoff dependency;
3. knowledge form, including story, observation, timeline, local map, access issue, service gap, infrastructure dependency, vulnerability note, coping practice, recovery lesson, public-safe concern, correction signal, or protected knowledge reference;
4. permission and use controls, including participation boundary, attribution or anonymity, publication permission, data-use label, AI-use label, translation permission, mapping permission, public-safe transformation requirement, withdrawal pathway, correction pathway, and archive rule;
5. safeguards, including privacy, dignity, non-stigmatizing language, trauma sensitivity where relevant, geospatial masking, youth protection, disability inclusion, protected knowledge restrictions, Indigenous protocol controls where applicable, and no-extraction discipline;
6. boundary notices, confirming that lived-risk knowledge is not official statistics, public warning, public authority finding, consent, open data, AI-training permission, donor prioritization, financeability, insurability, procurement priority, deployment authorization, or execution.

Lived-risk knowledge strengthens Nexus only when it is recorded with dignity, permission, context, limitation, correction, and public-safe transformation.

### 20.2.2 Local Context

Local context is the place-based, social, institutional, ecological, infrastructural, cultural, linguistic, economic, accessibility, public-service, legal, historical, and risk-specific context that determines whether Nexus records, Campaigns, Reports, DRI outputs, Observatory summaries, Studio workflows, Academy materials, Foundry builds, National Portfolio objects, Nexus Universe outputs, Registry records, Marketplace listings, finance-readiness records, public authority learning records, and handoff dependency notes are accurate, safe, usable, and legitimate in a specific community or location.

Local context shall not be treated as generic background. It may affect risk interpretation, public-safe language, mapping, data sensitivity, accessibility, translation, community dignity, protected knowledge, youth safeguards, public authority boundaries, public finance relevance, donor-readiness, insurance-readiness, operational dependencies, and lawful handoff conditions.

A Local Context Safeguard Record should identify:

1. place and community context, including geography at an appropriate public-safe level, community characteristics relevant to safeguards, language needs, accessibility needs, public service context, WFEH-B context, infrastructure context, hazard context, public authority context, and local institutional context;
2. context-sensitive objects, including DRI records, Observatory signals, maps, Studio workflows, Reports, Campaign materials, public-safe stories, National Portfolio records, Academy materials, Nexus Universe materials, Marketplace listings, Registry displays, Grid inputs, readiness questions, or handoff dependency notes;
3. local interpretation risks, including stigmatization, overgeneralization, geospatial exposure, political misuse, public authority overclaim, donor overclaim, aid-prioritization overclaim, consent overclaim, protected knowledge exposure, translation error, accessibility failure, or unsafe public release;
4. localization controls, including language adaptation, public-safe translation, accessibility adaptation, community review where appropriate, Indigenous protocol review where applicable, geospatial masking, non-stigmatizing framing, data-use limits, AI-use limits, and correction channels;
5. routing and record use, including National Portfolio update, DRI improvement, Observatory need, Studio workflow adjustment, Report clarification, Campaign correction, Academy adaptation, readiness question, handoff dependency note, correction, archive, or non-continuation;
6. boundary notices, confirming that local context records are not community consent, public authority approval, official local plan, procurement approval, donor priority, public finance allocation, deployment authorization, or execution.

Local context prevents Nexus from imposing global language on local reality. It is a safeguard against abstraction becoming harm.

### 20.2.3 Community Participation Records

Community Participation Records document the participation of communities, local organizations, civil society actors, affected stakeholders, youth groups, accessibility advocates, public-interest participants, humanitarian actors, Indigenous participants where applicable, and other community-facing actors in Nexus activities. These records preserve what participation occurred, what it meant, what it did not mean, what permissions applied, what safeguards were required, what outputs were created, what corrections were requested, and what archive status applies.

A Community Participation Record should identify:

1. participant or participant class, subject to privacy, safety, youth, dignity, protected knowledge, and public-safe controls;
2. participation pathway, including Campaign, community meeting, Studio room, safeguard room, public-safe storytelling pathway, DRI contribution, Observatory need contribution, National Portfolio pathway, Nexus Universe room, Academy pathway, Risk Academy pathway, Working Group, Competence Cell, Reports review, Marketplace or Registry feedback, readiness room, or handoff-awareness discussion;
3. participation purpose, including lived-risk knowledge contribution, local context review, public-safe language review, safeguard concern, accessibility input, translation input, correction request, DRI improvement, Observatory need, Campaign participation, learning participation, or handoff dependency clarification;
4. permissions and limits, including attribution preference, anonymity preference, publication permission, image or media permission, data-use label, AI-use label, translation permission, mapping permission, withdrawal pathway, correction pathway, and archive rule;
5. records and outputs, including participation record, contribution record, learning record, public-safe story, consent boundary record, community data control record, safeguard note, correction record, proof receipt, iCRS entry where appropriate, ILA entry where appropriate, and archive record;
6. boundary notices, confirming that community participation is not consent, endorsement, official community position, public authority approval, data-use permission beyond recorded limits, AI-use permission beyond recorded limits, deployment authorization, or execution.

Community Participation Records make participation visible without making participation coercive, extractive, or legally overstated.

### 20.2.4 Consent Boundary Records

Consent Boundary Records document the distinction between community participation and consent. They are required whenever Nexus activity may be misunderstood as community consent, Indigenous consent where applicable, data-use permission, AI-use permission, publication permission, mapping permission, photography or video permission, land or facility access, implementation permission, deployment authorization, public authority approval, or execution authority.

A Consent Boundary Record does not create consent. It records where consent is not present, where consent is outside Nexus scope, where separate permission is required, where participation is limited to learning or review, and where materials must be restricted until proper permission exists.

A Consent Boundary Record should identify:

1. consent-sensitive context, including community participation, public-safe storytelling, data contribution, DRI contribution, Observatory signal, Studio workflow, map, image, video, translation, protected knowledge, local site, public authority interface, finance-readiness routing, donor-readiness routing, insurance-readiness routing, public finance learning, or handoff dependency;
2. participation that occurred, including attendance, comment, signature, pledge, story, survey, meeting, review, Campaign participation, Academy participation, Nexus Universe participation, Working Group participation, or safeguard-room participation;
3. consent not created, including community consent, Indigenous consent where applicable, publication permission, data-use permission, AI-use permission, mapping permission, land access, facility access, deployment permission, implementation permission, handoff permission, or execution authority;
4. separate consent pathway required, including community process, Indigenous governance process where applicable, institutional approval, legal agreement, data agreement, ethics approval, public authority process, contract, land-access process, or other lawful permission route;
5. control action, including restrict, redact, anonymize, aggregate, mask location, delay release, require review, seal, delete where required, public-safe transform, route to consent pathway, correct, withdraw, recall, archive, or mark non-continuing;
6. boundary notices, confirming that participation, display, attendance, story, signature, pledge, dashboard inclusion, National Portfolio inclusion, or Nexus Universe participation is not consent by implication.

Consent Boundary Records protect Nexus from converting engagement into permission.

### 20.2.5 Community Data Controls

Community data controls govern the collection, classification, use, display, sharing, AI processing, storage, correction, withdrawal, sealing, deletion, and archive of data that relates to communities, local institutions, affected stakeholders, youth groups, community organizations, civil society actors, humanitarian contexts, Indigenous participants where applicable, lived-risk knowledge, local conditions, protected knowledge, community-sensitive locations, and community-facing safeguards.

Community data may include stories, survey responses, observations, maps, images, audio, video, contact information, participation records, vulnerability information, service gaps, infrastructure dependencies, health-related information, geospatial references, accessibility needs, language needs, local coping practices, public authority concerns, safeguard concerns, and correction requests. Community data shall not be treated as open data or AI-use-permitted data by default.

A Community Data Control Record should identify:

1. data class, including personal data, participation data, story data, survey data, lived-risk data, local context data, community-sensitive data, youth data, health-sensitive data, geospatial-sensitive data, protected knowledge, Indigenous protocol-sensitive data where applicable, public authority-sensitive data, humanitarian-sensitive data, or handoff-recipient-only data;
2. collection purpose, including public-safe reporting, DRI improvement, Observatory need, National Portfolio update, Campaign participation, Academy learning, Studio scenario, safeguard review, community correction, readiness question, donor-readiness question, public finance relevance question, or handoff dependency note;
3. data-use label, including no reuse, public-safe summary only, internal review only, community-review-only, National Node-visible, public authority learning-only, secure-room-only, data-room-only, protected knowledge room-only, handoff-recipient-only, archive-only, or deletion-required;
4. AI-use label, including no-AI use, retrieval-only with review, summarization with review, classification with review, evaluation-only, secure-room AI only, public-safe AI output only, agentic use prohibited, training prohibited, fine-tuning prohibited, or other controlled label;
5. access and release controls, including minimization, anonymization, pseudonymization, aggregation, geospatial masking, permission review, output review, retention, withdrawal, sealing, deletion where required, archive class, and correction pathway;
6. boundary notices, confirming that community data availability is not data ownership transfer, open data release, AI-use permission, publication permission, public authority record status, finance or insurance use permission, donor-use permission, consent, deployment authorization, or execution.

Community data controls ensure that community knowledge does not become a data commons by default.

### 20.2.6 Community-Sensitive Location Controls

Community-sensitive location controls govern the use of maps, coordinates, place names, facility locations, infrastructure locations, community boundaries, resource locations, hazard locations, evacuation-relevant locations, health-sensitive locations, protected knowledge locations, Indigenous protocol-sensitive locations where applicable, biodiversity-sensitive locations, water-source locations, informal settlement locations, displacement locations, shelter locations, youth-related locations, cyber-physical infrastructure locations, and any geospatial reference that could expose communities to harm.

Community-sensitive locations may be necessary for DRI, Observatory, Studio, National Portfolio, Reports, Campaigns, Nexus Universe, public authority learning, public finance learning, insurance-readiness, donor-readiness, Grid and TRL review, Marketplace display, Registry status, or handoff dependency work. Necessity does not create public display permission.

A Community-Sensitive Location Control Record should identify:

1. location class, including exact coordinate, address, facility, community boundary, infrastructure node, water source, health site, school or youth site, shelter, displacement site, protected knowledge location, Indigenous protocol-sensitive location where applicable, biodiversity-sensitive site, hazard site, or generalized area;
2. risk of exposure, including privacy harm, security harm, stigmatization, theft, exploitation, political misuse, public authority misuse, media harm, geospatial targeting, infrastructure vulnerability, protected knowledge exposure, community consent overclaim, or handoff misuse;
3. display rule, including no display, masked display, aggregated display, generalized geography, delayed display, public-safe map, controlled map, secure-room-only, data-room-only, protected knowledge room-only, public authority learning-only, handoff-recipient-only, archive-only, or deletion-required;
4. review requirements, including geospatial review, community safeguard review, privacy review, cyber review, infrastructure sensitivity review, public-safe review, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, handoff review, and correction review;
5. correction and recall, including map correction, location removal, geospatial masking, dashboard correction, Report correction, Marketplace correction, Registry correction, Studio correction, public repair, withdrawal, recall, sealing, deletion where required, archive, or non-continuation;
6. boundary notices, confirming that location display is not land access permission, facility access permission, community consent, public authority approval, operational instruction, procurement authorization, deployment authorization, or execution.

Community-sensitive location controls prevent maps from becoming harm vectors.

### 20.2.7 Community Correction Channels

Community correction channels are accessible, visible, safe, multilingual where appropriate, disability-inclusive, youth-sensitive, non-retaliatory, low-burden pathways through which community participants, local institutions, civil society actors, affected stakeholders, youth participants, accessibility advocates, humanitarian actors, Indigenous participants where applicable, and other community-facing actors may request correction, restriction, withdrawal, recall, redaction, sealing, deletion where required, public repair, archive update, or non-continuation of Nexus materials that affect them.

Community correction channels must connect to actual correction authority. They must not be symbolic feedback forms. They should be available for Campaigns, Reports, dashboards, DRI outputs, Observatory summaries, Studio workflows, public-safe stories, National Portfolio objects, Nexus Universe materials, Marketplace listings, Registry records, Grid inputs, finance-readiness records, donor-readiness materials, public finance learning materials, public authority learning records, handoff dependency notes, proof receipts, iCRS entries, ILA entries, and archive records.

A Community Correction Channel Record should identify:

1. channel access, including language, accessibility, submission method, anonymous or confidential submission option where appropriate, youth-safe route, community representative route, Indigenous protocol route where applicable, emergency-sensitive route where appropriate, and response timeline class;
2. eligible correction issues, including factual error, privacy issue, dignity concern, consent overclaim, protected knowledge exposure, Indigenous protocol issue where applicable, youth safeguard issue, accessibility failure, translation error, stigmatizing language, geospatial exposure, data-use error, AI-use error, public authority overclaim, donor overclaim, finance or insurance overclaim, aid-prioritization overclaim, deployment overclaim, or execution overclaim;
3. affected object classes, including Report, story, image, map, dashboard, DRI output, Observatory summary, Studio workflow, Campaign material, National Portfolio object, Nexus Universe record, Marketplace listing, Registry record, Grid input, finance-readiness record, public authority learning record, handoff note, learning record, contribution record, support record, or archive record;
4. triage and response, including acknowledgement, safeguard review, data review, public-safe review, geospatial review, Indigenous protocol review where applicable, youth safeguard review, legal boundary review, restriction, correction, redaction, withdrawal, recall, public repair, sealing, deletion where required, archive, or non-continuation;
5. protection controls, including reporter privacy, anti-retaliation, confidentiality, community safety, youth protection, protected knowledge protection, accessibility, language access, and escalation;
6. closure and propagation, including correction completed, correction denied with reason, downstream updates, public-safe update, Registry update, Marketplace update, Report update, Campaign update, handoff note update, archive update, and recurrence-prevention action.

Community correction channels make Nexus answerable to communities after publication, not only before publication.

### 20.2.8 No Consent by Display or Participation

No consent by display or participation is the mandatory community safeguard rule that the display of a community name, image, story, map, public-safe summary, Campaign participation count, signature count, pledge count, attendance record, workshop output, National Portfolio object, Nexus Universe record, DRI contribution, Observatory signal, Studio scenario, Marketplace listing, Registry record, Grid input, Report, media-safe material, public authority learning record, finance-readiness record, donor-readiness record, public finance relevance record, or handoff dependency note shall not be treated as community consent, Indigenous consent where applicable, data-use permission, AI-use permission, land access, facility access, publication approval, implementation approval, deployment authorization, or execution authority.

Display can create false legitimacy. Participation can be misread as agreement. Nexus shall therefore place clear boundary notices on community-facing and public-facing materials where consent risk exists, and shall correct, withdraw, recall, or archive materials that imply consent improperly.

A No Consent by Display or Participation Record should identify:

1. display or participation context, including Campaign page, Report, dashboard, map, story, Studio workflow, National Portfolio object, Nexus Universe material, Marketplace listing, Registry display, Grid input, public authority learning material, readiness room material, donor-reader material, insurance-reader material, capital-reader material, public finance learning material, or handoff dependency note;
2. consent risk, including implied community approval, implied Indigenous consent where applicable, implied publication permission, implied data-use permission, implied AI-use permission, implied land access, implied deployment permission, implied public authority approval, implied donor priority, implied financeability, implied insurability, or implied execution authority;
3. required notice, including display-not-consent, participation-not-consent, story-not-consent, map-not-permission, data-not-open, public-safe-summary-not-raw-release, Campaign-support-not-approval, National Portfolio-inclusion-not-official-plan, and Nexus Universe-participation-not-deployment-authorization;
4. control action, including revise language, remove image, remove quote, mask location, anonymize, aggregate, restrict access, require permission review, route to consent pathway, correct, withdraw, recall, publicly repair, archive, or mark non-continuing;
5. separate consent pathway, including community process, Indigenous governance process where applicable, legal process, data agreement, ethics process, public authority process, land-access process, publication permission, or contract;
6. boundary notices, confirming that Nexus will not infer consent from visibility, attendance, participation, contribution, listing, recording, or inclusion.

No consent by display or participation is the final guardrail against converting public-good visibility into permission.

The final Community Safeguards rule is: community safeguards protect lived-risk knowledge, local context, participation records, consent boundaries, community data, community-sensitive locations, community correction channels, and no-consent-by-display discipline. Community knowledge and participation may inform Nexus records, DRI, Observatory, Studio, Reports, Campaigns, National Portfolios, Nexus Universe, finance-readiness, public authority learning, and handoff dependencies; they never create consent, approval, publication permission, data-use permission, AI-use permission, land access, deployment authorization, or execution by implication.

## 20.3 Indigenous Protocol-Sensitive Controls Where Applicable

### 20.3.1 Indigenous Governance Protocols

Indigenous governance protocols are the applicable community, Nation, institutional, cultural, legal, customary, ethical, data, knowledge, language, territorial, relational, and decision pathways that must be respected where Nexus work involves Indigenous peoples, Indigenous institutions, Indigenous lands or territories, Indigenous knowledge, Indigenous data, Indigenous ecological knowledge, Indigenous cultural context, Indigenous youth, Indigenous community participation, Indigenous governance actors, Indigenous-led organizations, or Indigenous protocol-sensitive matters.

Nexus shall not assume that ordinary participation rules, public-facing consultation formats, data contribution forms, Campaign signatures, public-safe storytelling pathways, public authority learning rooms, Studio workflows, DRI contributions, Observatory signals, National Portfolio records, Nexus Universe participation, Marketplace listings, Registry records, finance-readiness rooms, donor-readiness rooms, or handoff dependency notes are sufficient where Indigenous governance protocols apply. Where protocol-sensitive context exists, Nexus must identify the applicable governance pathway before collecting, displaying, summarizing, routing, publishing, translating, mapping, modeling, training AI on, listing, registering, or handing off related knowledge or data.

An Indigenous Governance Protocol Record, where applicable, should identify:

1. protocol context, including Indigenous people, Nation, community, institution, governance body, knowledge holder, data steward, youth context, territorial context, cultural context, ecological context, language context, public authority relationship, National Portfolio relationship, Nexus Universe relationship, or handoff context;
2. governance pathway, including community process, Nation process, Indigenous institution process, knowledge-holder process, data-governance process, cultural protocol, research protocol, ethics pathway, land or site protocol, protected knowledge pathway, or other applicable review route;
3. Nexus activity covered, including Campaign, Report, DRI output, Observatory summary, Studio workflow, Academy pathway, Foundry build, National Portfolio object, Nexus Universe room, Registry record, Marketplace listing, Grid input, finance-readiness record, public authority learning record, donor-readiness record, public finance relevance record, or handoff dependency note;
4. required review, including Indigenous governance review where applicable, community review, knowledge-holder review, data steward review, public-safe review, protected knowledge review, legal boundary review, safeguard review, publication review, mapping review, AI-use review, handoff review, correction review, and archive review;
5. control status, including protocol not yet determined, protocol review required, permission required, public-safe summary permitted, restricted use only, protected knowledge room only, no publication, no mapping, no AI use, no handoff, sealed, deletion-required, archived, or non-continuing;
6. boundary notices, confirming that Nexus participation, public display, knowledge access, data access, public authority learning, donor attention, finance-readiness review, Nexus Universe participation, or handoff discussion does not override Indigenous governance protocols or create Indigenous consent by implication.

Indigenous governance protocols shall be treated as conditions of legitimacy, not procedural obstacles. Where Nexus is uncertain whether such protocols apply, the more protective pathway shall be used until the applicable governance context is clarified.

### 20.3.2 Protected Knowledge

Protected knowledge in Indigenous protocol-sensitive contexts includes Indigenous knowledge, cultural knowledge, ecological knowledge, language knowledge, sacred knowledge, ceremonial knowledge, place-based knowledge, land and water knowledge, biodiversity knowledge, seasonal knowledge, historical knowledge, oral knowledge, community memory, governance knowledge, health-related knowledge, youth-related knowledge, geospatial knowledge, and other knowledge that is subject to Indigenous protocol, custodianship, restriction, context, relational obligation, or limited permission.

Protected knowledge shall not be presumed open because it is mentioned, observed, summarized, translated, contributed, displayed, discussed, recorded, mapped, digitized, included in a National Portfolio, referenced in a DRI record, surfaced through Observatory activity, used in a Studio scenario, discussed in Nexus Universe, or stored in a Registry or archive. Access does not equal permission. Knowledge visibility does not equal knowledge release.

An Indigenous Protected Knowledge Record, where applicable, should identify:

1. knowledge class, including cultural, ecological, ceremonial, sacred, territorial, oral, historical, language, health-sensitive, youth-sensitive, biodiversity-sensitive, water-related, land-related, governance-related, or other protocol-sensitive knowledge;
2. custodian context, including Indigenous community, Nation, institution, knowledge holder, data steward, cultural steward, youth safeguard steward where applicable, protected knowledge steward, archive steward, and correction contact where appropriate;
3. permitted use, including internal review only, community review only, protected knowledge room only, public-safe summary only, restricted learning use, no publication, no quotation, no translation, no mapping, no AI use, no training, no Marketplace display, no public Registry display, no handoff, or archive-only handling;
4. access controls, including approved participants, confidentiality, no-download, no-copy, no-recording, no-AI, no-training, secure-room requirement, data-room requirement, protected knowledge room requirement, output review, expiration, revocation, sealing, deletion where required, and archive restrictions;
5. release and correction controls, including public-safe transformation, redaction, aggregation, masking, community review, Indigenous protocol review, withdrawal, correction, public repair where appropriate, recall, sealing, deletion where required, and archive classification;
6. boundary notices, confirming that protected knowledge access is not permission to publish, reuse, translate, map, cite, train AI, transfer, commercialize, hand off, deploy, or execute.

Protected knowledge controls must travel with the knowledge across all Nexus pathways. A protected knowledge restriction is not lost when the knowledge is transformed into metadata, summary, map, dashboard, model input, Report language, Registry status, Marketplace listing, finance-readiness material, public authority learning note, or handoff dependency record.

### 20.3.3 Sacred Site Controls

Sacred site controls are the restrictions that apply where Nexus work may involve sacred sites, ceremonial sites, burial sites, culturally significant places, spiritually significant landscapes, protected ecological places, Indigenous heritage locations, culturally restricted geographies, water sites, land sites, biodiversity sites, or other locations that Indigenous governance protocols or knowledge custodians identify as sensitive, restricted, or protected.

Sacred site controls shall apply not only to exact coordinates, but also to maps, photographs, videos, descriptions, routes, generalized locations, place names, satellite imagery, drone imagery, sensor records, digital twin representations, Studio scenarios, DRI records, Observatory summaries, National Portfolio maps, Reports, Campaign materials, Marketplace displays, Registry records, public authority learning materials, finance-readiness materials, donor-readiness materials, public finance learning materials, and handoff dependency notes that may expose, infer, or enable identification of a protected place.

A Sacred Site Control Record, where applicable, should identify:

1. site or location class, including sacred site, ceremonial site, burial site, heritage site, restricted ecological site, protected water site, protected land site, culturally significant landscape, biodiversity-sensitive site, or other protocol-sensitive location;
2. exposure risk, including exact coordinate exposure, place-name exposure, map inference, image exposure, route exposure, facility association, geospatial triangulation, public authority misuse, media misuse, visitor pressure, commercial exploitation, environmental harm, protected knowledge exposure, or handoff misuse;
3. display rule, including no display, no coordinate storage, masked display, generalized geography, aggregation, delayed release, protected knowledge room only, secure-room only, data-room only, community review only, public authority learning-only with restrictions, handoff-recipient-only with separate permission, archive-only, sealed, or deletion-required;
4. review pathway, including Indigenous governance review where applicable, knowledge-holder review, geospatial review, privacy review, public-safe review, safeguard review, public authority boundary review, handoff review, correction review, and archive review;
5. prohibited uses, including public mapping, open geospatial release, Marketplace display, public Registry display, AI training, tourism or promotional use, procurement use, finance or insurance use, donor visibility use, public authority routing without permission, handoff without separate authority, deployment planning, or execution;
6. boundary notices, confirming that site reference, site display, site discussion, or site inclusion is not land access permission, visitation permission, publication permission, public authority approval, community consent, Indigenous consent, deployment authorization, or execution.

Sacred site controls shall apply under a precautionary standard. If a location may be sensitive and authority is unclear, Nexus shall restrict, mask, seal, or withhold the location until the appropriate Indigenous governance pathway determines otherwise.

### 20.3.4 Indigenous Data Sovereignty Considerations

Indigenous data sovereignty considerations are the controls and review obligations that apply where Nexus collects, receives, stores, processes, summarizes, displays, models, maps, translates, shares, archives, or routes data relating to Indigenous peoples, communities, Nations, institutions, territories, knowledge, health, youth, culture, ecology, language, governance, participation, or protected places.

Indigenous data sovereignty considerations require Nexus to recognize that data may carry collective rights, relational obligations, jurisdictional considerations, governance protocols, consent requirements, custodianship requirements, access limits, use limits, AI-use restrictions, cross-border restrictions, storage restrictions, archive restrictions, and correction rights beyond ordinary data governance. Nexus shall not treat Indigenous-related data as open data, public data, training data, Marketplace data, Registry-public data, public authority data, finance-readiness data, donor-readiness data, insurance-readiness data, or handoff-recipient data by default.

An Indigenous Data Sovereignty Consideration Record, where applicable, should identify:

1. data class, including personal data, community data, collective data, participation data, story data, ecological data, cultural data, language data, health-sensitive data, youth data, geospatial data, protected knowledge data, governance data, public authority interface data, or handoff-recipient-only data;
2. governance and custodianship, including Indigenous community, Nation, institution, data steward, knowledge steward, archive steward, public-safe steward, legal boundary steward, and correction contact where appropriate;
3. data-use label, including no reuse, community-review-only, protected knowledge room only, public-safe summary only, internal review only, National Node-visible with restrictions, public authority learning-only with restrictions, secure-room-only, data-room-only, handoff-recipient-only with separate permission, archive-only, sealed, or deletion-required;
4. AI-use label, including no-AI use, no training, no fine-tuning, no agentic use, retrieval-only with review, summarization with review, secure-room AI only, public-safe AI output only, or AI-use prohibited unless separately authorized;
5. storage, access, and transfer controls, including data minimization, localization where required, cross-border controls, access approval, no-download controls, encryption, logging, output review, retention, withdrawal, correction, sealing, deletion where required, and archive classification;
6. boundary notices, confirming that Indigenous-related data availability is not data ownership transfer, open data release, AI-use permission, publication permission, public authority record status, finance or insurance use permission, donor-use permission, handoff permission, consent, deployment authorization, or execution.

Indigenous data sovereignty considerations shall be applied at the earliest point of data intake and shall continue through metadata, public-safe summaries, dashboards, models, Reports, Registry records, Marketplace listings, Studio workflows, finance-readiness materials, public authority learning records, handoff notes, correction records, and archives.

### 20.3.5 Community-Directed Attribution

Community-directed attribution is the safeguard rule that attribution, anonymity, pseudonymity, collective recognition, knowledge-holder recognition, institutional recognition, non-attribution, restricted attribution, delayed attribution, language-use recognition, cultural credit, contribution recognition, iCRS recognition where appropriate, ILA or learner recognition where appropriate, and public-safe acknowledgement must follow the applicable community, Indigenous governance, knowledge-holder, participant, privacy, youth, safety, and protected knowledge controls.

Nexus shall not decide attribution solely according to ordinary authorship, citation, branding, marketing, media, academic, open-source, donor, sponsor, or platform norms where Indigenous protocol-sensitive knowledge or participation is involved. Attribution can itself create risk, expose protected knowledge, misrepresent consent, create unwanted visibility, misallocate credit, reveal location, identify knowledge holders, or convert community knowledge into institutional property. Community-directed attribution therefore requires review before public display.

A Community-Directed Attribution Record, where applicable, should identify:

1. contribution source, including Indigenous community, Nation, institution, knowledge holder, youth participant, community participant, local organization, cultural steward, ecological knowledge contributor, translator, reviewer, or other participant;
2. attribution preference, including named attribution, collective attribution, institutional attribution, anonymous treatment, pseudonymous treatment, restricted attribution, delayed attribution, no attribution, public-safe attribution, archive-only attribution, or protected knowledge room-only attribution;
3. recognition pathway, including contribution record, proof receipt, iCRS record where appropriate, ILA entry where appropriate, public-safe acknowledgement, restricted acknowledgement, community-facing acknowledgement, Report acknowledgement, Registry metadata, Marketplace display, or archive record;
4. risk review, including privacy risk, youth risk, protected knowledge risk, sacred site risk, location inference risk, political risk, safety risk, media risk, donor visibility risk, public authority overclaim risk, sponsor or provider capture risk, and consent overclaim risk;
5. display controls, including no public name, no logo, no quote, no image, no location, no role title, no affiliation, no Marketplace display, no public Registry display, no media use, or public-safe transformed display only;
6. boundary notices, confirming that attribution is not consent, endorsement, ownership transfer, publication permission, data-use permission, AI-use permission, donor priority, public authority approval, deployment authorization, or execution.

Community-directed attribution ensures that recognition does not become exposure, appropriation, or consent overclaim.

### 20.3.6 No-AI-Training Restrictions Where Appropriate

No-AI-training restrictions where appropriate are the safeguard controls that prohibit or restrict the use of Indigenous protocol-sensitive knowledge, protected knowledge, community data, cultural knowledge, ecological knowledge, sacred site information, language data, oral knowledge, youth data, health-sensitive data, geospatial data, public authority-sensitive data, and other restricted materials for AI training, fine-tuning, embedding, evaluation, agentic workflows, synthetic data generation, model benchmarking, retrieval systems, or automated processing unless expressly permitted through the applicable governance, consent, data, legal, safeguard, and review pathway.

Nexus shall not infer AI-use permission from data access, public availability, participation, publication, public-safe summary, community display, National Portfolio inclusion, Nexus Universe participation, Registry entry, Marketplace listing, public authority learning, donor-readiness review, finance-readiness review, or handoff discussion. AI use must be separately labelled, reviewed, and controlled.

A No-AI-Training Restriction Record, where applicable, should identify:

1. material covered, including data, text, audio, image, video, map, story, transcript, translation, oral knowledge, ecological knowledge, cultural reference, sacred site reference, language material, DRI contribution, Observatory signal, Studio input, Report source, Campaign input, National Portfolio object, or protected knowledge record;
2. AI-use status, including no-AI use, no training, no fine-tuning, no embedding, no agentic use, no synthetic generation, no automated classification, retrieval-only with review, summarization with review, secure-room AI only, public-safe AI output only, or AI-use permitted only by separate recorded authority;
3. reason for restriction, including Indigenous governance protocol, protected knowledge status, privacy, youth safeguard, health sensitivity, cultural sensitivity, sacred site sensitivity, data sovereignty, copyright or license restriction, consent limitation, public-safe limitation, or handoff limitation;
4. technical and operational controls, including access restriction, dataset exclusion, model training exclusion, vector index exclusion, tool-permission restriction, logging, output review, prompt-injection controls where applicable, data-room or secure-room requirement, deletion from prohibited AI workflows where required, and archive restriction;
5. correction and incident pathway, including AI-use breach report, model contamination review, output correction, deletion where required, restriction, withdrawal, recall, notification, public repair where appropriate, archive, and non-continuation;
6. boundary notices, confirming that access to or publication of material does not authorize AI training, fine-tuning, embedding, agentic use, automated decision-making, commercial model use, deployment, or execution.

No-AI-training restrictions protect Indigenous protocol-sensitive and protected knowledge from being absorbed into systems that cannot easily return, forget, contextualize, or respect relational obligations.

### 20.3.7 Restricted Access

Restricted access is the safeguard control that limits who may see, handle, process, quote, summarize, translate, map, model, publish, route, archive, or receive Indigenous protocol-sensitive material. Restricted access applies wherever ordinary open participation, public-good publication, Marketplace discovery, Registry display, Studio demonstration, Reports use, public authority learning, finance-readiness review, donor-readiness review, insurance-readiness review, public finance learning, or handoff dependency routing could expose protected knowledge, misstate consent, violate protocol, or create harm.

Restricted access may be role-based, room-based, time-limited, purpose-limited, geography-limited, community-review-limited, Indigenous-governance-limited, secure-room-limited, data-room-limited, protected-knowledge-room-limited, archive-limited, sealed, or deletion-required.

A Restricted Access Record, where applicable, should identify:

1. restricted material, including knowledge, data, metadata, map, location, story, image, video, transcript, translation, DRI input, Observatory signal, Studio input, Report source, National Portfolio object, Campaign material, Registry metadata, Marketplace display candidate, Grid input, finance-readiness material, public authority learning material, or handoff dependency note;
2. access class, including public prohibited, controlled-public, community-review-only, Indigenous-governance-review-only, knowledge-holder-only, internal restricted, National Node-restricted, public authority learning-restricted, secure-room-only, data-room-only, protected knowledge room-only, handoff-recipient-only with separate permission, archive-only, sealed, or deletion-required;
3. approved users and roles, including knowledge holder, Indigenous governance representative where applicable, community steward, data steward, safeguard reviewer, public-safe reviewer, legal boundary reviewer, secure-room participant, data-room participant, archive steward, or approved recipient;
4. use limits, including no download, no copy, no quote, no translation, no mapping, no public summary, no AI use, no training, no Marketplace listing, no public Registry display, no donor display, no finance-readiness display, no public authority routing, no handoff, or no archive display unless separately authorized;
5. monitoring and revocation, including access logs, review cadence, expiration, revocation triggers, breach reporting, correction pathway, sealing, deletion where required, archive update, and non-continuation;
6. boundary notices, confirming that restricted access is permission to access only within recorded limits and is not permission to reuse, publish, train AI, transfer, hand off, deploy, commercialize, or execute.

Restricted access keeps sensitive materials within the smallest safe circle required for the recorded purpose.

### 20.3.8 Protected Knowledge Rooms

Protected Knowledge Rooms are controlled Nexus environments for Indigenous protocol-sensitive materials, protected knowledge, sacred site information, community-protected knowledge, cultural knowledge, ecological knowledge, language knowledge, youth-sensitive information, health-sensitive information, geospatial-sensitive information, and other restricted materials that cannot safely be handled in ordinary public, Campaign, Studio, Reports, Academy, Marketplace, Registry, readiness, public authority learning, donor-reader, finance-reader, or handoff rooms.

A Protected Knowledge Room shall be governed by access limitation, purpose limitation, no-download rules where required, no-copy rules where required, no-AI-training rules where required, output review, community or Indigenous governance review where applicable, confidentiality, correction, withdrawal, sealing, deletion where required, and archive restrictions. The room shall not be used to normalize access to protected material or to convert protected knowledge into public-good content.

A Protected Knowledge Room Record, where applicable, should identify:

1. room purpose, including protected knowledge review, Indigenous protocol review, public-safe transformation, safeguard review, restricted DRI interpretation, restricted Observatory review, restricted Studio input review, National Portfolio safeguard review, Report source review, consent-boundary review, correction review, or handoff restriction review;
2. materials handled, including protected knowledge, sacred site information, cultural context, ecological knowledge, community data, Indigenous data, maps, images, oral knowledge, language material, youth data, health-sensitive data, geospatial-sensitive data, or handoff-restricted materials;
3. participant controls, including approved participants, knowledge-holder participation where appropriate, Indigenous governance participation where applicable, safeguard steward, data steward, public-safe steward, legal boundary steward, room facilitator, confidentiality, duration, revocation, and access logs;
4. runtime controls, including no-download, no-copy, no-recording, no-AI, no-training, no-agentic-use, secure storage, output review, redaction, aggregation, masking, sealed notes where required, and room archive;
5. approved outputs, including no output, protected note, public-safe summary where permitted, restriction record, consent boundary record, safeguard record, correction record, withdrawal record, sealing record, deletion record, archive record, or non-continuation record;
6. boundary notices, confirming that Protected Knowledge Room participation is not permission to publish, reuse, translate, map, train AI, transfer, commercialize, hand off, deploy, or execute.

Protected Knowledge Rooms are trust infrastructure. They allow Nexus to protect sensitive knowledge by preventing ordinary ecosystem visibility from becoming unauthorized exposure.

### 20.3.9 Consent-Aware Handling

Consent-aware handling is the operational safeguard requiring Nexus to identify, record, respect, and revisit consent conditions, permission limits, protocol requirements, participation boundaries, withdrawal rights, correction rights, publication permissions, data-use permissions, AI-use permissions, mapping permissions, translation permissions, attribution permissions, public authority routing permissions, finance-readiness routing permissions, donor-readiness routing permissions, insurance-readiness routing permissions, public finance learning permissions, and handoff permissions where Indigenous protocol-sensitive materials or participation are involved.

Consent-aware handling recognizes that consent may be specific, collective, conditional, time-limited, revocable, purpose-limited, context-dependent, language-dependent, custodian-dependent, jurisdiction-dependent, and distinct from participation. Nexus shall not collapse one form of permission into another.

A Consent-Aware Handling Record, where applicable, should identify:

1. consent-sensitive object or activity, including knowledge contribution, data contribution, story, image, video, translation, map, DRI input, Observatory signal, Studio workflow, Report source, Campaign participation, National Portfolio inclusion, Nexus Universe participation, Registry entry, Marketplace listing, public authority learning use, finance-readiness use, donor-readiness use, insurance-readiness use, public finance learning use, or handoff dependency;
2. permission status, including permission granted for defined purpose, permission pending, permission denied, permission withdrawn, permission unclear, participation only, public-safe summary only, protected-room-only, archive-only, deletion-required, or no-use status;
3. scope of permission, including who may use, what may be used, for what purpose, in what language, in what format, in what geography, for what duration, with what attribution, with what AI-use status, with what display status, and with what correction or withdrawal rights;
4. separate permissions required, including publication, translation, mapping, AI use, training, public authority routing, donor-readiness routing, finance-readiness routing, insurance-readiness routing, public finance learning, handoff, commercialization, deployment, or implementation;
5. monitoring and review, including review cadence, expiry, change triggers, correction triggers, withdrawal process, downstream propagation, Registry update, Marketplace update, Report update, Campaign update, Studio update, handoff note update, and archive update;
6. boundary notices, confirming that consent-aware handling is required precisely because participation, display, access, contribution, and public-safe summary do not create consent by implication.

Consent-aware handling ensures that Nexus knows not only what it holds, but what it is allowed to do with what it holds.

### 20.3.10 No Indigenous Consent by Implication

No Indigenous consent by implication is the mandatory rule that Indigenous participation, attendance, story contribution, data contribution, knowledge contribution, public-safe review, Campaign participation, signature, pledge, Academy participation, Studio participation, DRI contribution, Observatory signal, National Portfolio inclusion, Nexus Universe participation, public authority learning participation, donor-reader discussion, finance-readiness discussion, insurance-readiness discussion, public finance learning discussion, Marketplace listing, Registry record, Grid input, Report reference, media-safe mention, protected knowledge room access, or handoff dependency note shall not be represented as Indigenous consent, approval, endorsement, data-use permission, AI-use permission, publication permission, mapping permission, land access permission, sacred site access permission, public authority approval, project approval, deployment authorization, implementation authorization, or execution authority.

Indigenous consent, where required, must be obtained through the applicable Indigenous governance, community, knowledge-holder, legal, ethical, data, land, institutional, or other protocol-appropriate pathway and must be separately recorded. Nexus shall not infer consent from silence, presence, visibility, participation, urgency, sponsor support, public authority interest, donor interest, finance-reader interest, public-safe transformation, or Nexus Universe momentum.

A No Indigenous Consent by Implication Record, where applicable, should identify:

1. context creating consent risk, including Campaign material, Report, dashboard, map, Studio workflow, DRI output, Observatory summary, National Portfolio object, Nexus Universe room, public authority learning material, donor-readiness material, finance-readiness material, insurance-readiness material, public finance learning material, Marketplace listing, Registry record, Grid input, media material, or handoff dependency note;
2. participation or display involved, including attendance, comment, contribution, story, data, image, map, quote, signature, pledge, review, room participation, public-safe summary, listing, registration, or archive reference;
3. consent not created, including Indigenous consent, publication permission, data-use permission, AI-use permission, mapping permission, sacred site access, land access, project approval, public authority approval, donor approval, finance-readiness approval, insurance-readiness approval, public finance approval, handoff permission, deployment authorization, or execution authority;
4. required notice, including participation-not-consent, display-not-consent, story-not-consent, data-not-permission, map-not-access, public-safe-summary-not-release, National Portfolio-inclusion-not-approval, Nexus Universe-participation-not-authorization, and handoff-note-not-consent;
5. control action, including restrict, redact, mask, anonymize, aggregate, remove, route to Indigenous governance review, route to knowledge-holder review, route to consent pathway, correct, withdraw, recall, publicly repair where appropriate, seal, delete where required, archive, or mark non-continuing;
6. boundary notices, confirming that no Nexus record, room, arena, output, listing, report, summary, contribution, participation, or handoff note creates Indigenous consent unless the applicable consent pathway separately and lawfully records that effect.

No Indigenous consent by implication is non-negotiable. It protects Indigenous governance, knowledge, lands, data, communities, and dignity from being converted into authorization by the machinery of visibility.

The final Indigenous Protocol-Sensitive Controls rule is: where applicable, Indigenous governance protocols, protected knowledge controls, sacred site controls, Indigenous data sovereignty considerations, community-directed attribution, no-AI-training restrictions, restricted access, Protected Knowledge Rooms, consent-aware handling, and no-Indigenous-consent-by-implication discipline shall govern Nexus work. These controls allow Nexus to learn, record, protect, summarize, correct, and archive with respect; they never convert Indigenous participation, knowledge access, data access, public display, public-safe summary, public authority learning, finance-readiness review, donor-readiness review, or handoff discussion into Indigenous consent, publication permission, AI-use permission, mapping permission, land access, deployment authorization, or execution by implication.

## 20.4 Protected Knowledge Controls

### 20.4.1 Protected Knowledge Defined

Protected knowledge means any knowledge, data, record, story, map, location, practice, method, observation, image, signal, cultural reference, ecological knowledge, Indigenous protocol-sensitive knowledge where applicable, community-sensitive knowledge, youth-sensitive information, health-sensitive information, humanitarian-sensitive information, cyber-sensitive information, infrastructure-sensitive information, security-sensitive information, public authority-sensitive information, legal-sensitive information, finance-sensitive or insurance-sensitive information, donor-sensitive information, handoff-recipient-only information, or other material that cannot safely be treated as open, public, reusable, AI-usable, mappable, translatable, publishable, transferable, or handoff-ready by default.

Protected knowledge may exist in raw form, summarized form, metadata form, dashboard form, map form, Report form, DRI form, Observatory form, Studio form, Campaign form, National Portfolio form, Nexus Universe form, Marketplace form, Registry form, Grid form, Academy form, Foundry form, finance-readiness form, public authority learning form, donor-readiness form, insurance-readiness form, public finance learning form, or handoff dependency form. Transformation does not remove protection unless a recorded review expressly permits the new use.

A Protected Knowledge Classification Record should identify:

1. knowledge class, including community-protected, Indigenous protocol-sensitive where applicable, sacred, cultural, ecological, health-sensitive, youth-sensitive, humanitarian-sensitive, geospatial-sensitive, cyber-sensitive, infrastructure-sensitive, public authority-sensitive, legal-sensitive, security-sensitive, finance-sensitive, insurance-sensitive, donor-sensitive, commercially sensitive where appropriate, handoff-recipient-only, archive-only, sealed, or deletion-required knowledge;
2. source and custodian, including knowledge holder, community pathway, Indigenous governance pathway where applicable, institutional steward, data steward, public-safe steward, safeguard steward, legal boundary steward, public authority steward where applicable, and archive steward;
3. Nexus object relationship, including Campaign, Report, DRI output, Observatory summary, Studio workflow, National Portfolio object, Nexus Universe output, Academy material, Foundry build, Registry record, Marketplace listing, Grid input, finance-readiness record, public authority learning record, or handoff dependency note;
4. permitted use status, including internal review only, protected knowledge room only, secure-room only, data-room only, community-review only, Indigenous-governance-review only where applicable, public-safe summary only, metadata-only record, restricted handoff-context only, sealed, deletion-required, archive-only, or non-continuing;
5. prohibited use status, including no publication, no quotation, no translation, no mapping, no geospatial display, no AI use, no AI training, no Marketplace display, no public Registry display, no public authority routing, no finance-readiness routing, no donor-readiness routing, no insurance-readiness routing, no public finance learning routing, no handoff, no commercialization, no deployment, and no execution unless separately authorized;
6. boundary notices, confirming that knowledge access, knowledge contribution, public-safe transformation, participation, display, or record existence is not permission to publish, reuse, translate, map, train AI, transfer, hand off, commercialize, deploy, or execute.

Protected knowledge shall be treated as an affirmative control category. If Nexus is uncertain whether material is protected, the more protective classification shall apply until review establishes a safer status.

### 20.4.2 Access Restriction

Access restriction is the control that limits who may view, handle, process, summarize, translate, map, model, quote, publish, route, archive, or receive protected knowledge. Access shall be purpose-limited, role-limited, time-limited, room-limited, jurisdiction-aware, safeguard-aware, correctionable, and revocable.

Access restriction applies across all Nexus environments, including Campaigns, Reports, DRI, Observatory, Studio, Academy, Foundry, National Portfolios, Nexus Universe arenas and rooms, Marketplace, Registry, Grid, finance-readiness rooms, donor-reader rooms, insurance-reader rooms, public finance learning rooms, public authority learning rooms, secure rooms, data rooms, protected knowledge rooms, media-safe rooms, correction rooms, and lawful handoff dependency contexts.

An Access Restriction Record should identify:

1. restricted material, including knowledge, data, metadata, map, image, video, audio, transcript, translation, story, DRI input, Observatory signal, Studio input, Report source, National Portfolio object, Campaign material, Registry metadata, Marketplace candidate, Grid input, finance-readiness material, public authority learning material, or handoff note;
2. access class, including public prohibited, controlled-public, internal restricted, community-review-only, Indigenous-governance-review-only where applicable, knowledge-holder-only, National Node-restricted, secure-room-only, data-room-only, protected knowledge room-only, public authority learning-restricted, finance-readiness-restricted, handoff-recipient-only with separate permission, archive-only, sealed, or deletion-required;
3. approved users and roles, including knowledge holder, community steward, Indigenous governance representative where applicable, data steward, safeguard reviewer, public-safe reviewer, legal boundary reviewer, secure-room participant, data-room participant, protected knowledge room participant, public authority learner where authorized, archive steward, or approved handoff recipient;
4. use limitations, including no download, no copy, no recording, no quotation, no translation, no mapping, no AI use, no AI training, no public summary, no Marketplace listing, no public Registry display, no donor display, no finance-readiness display, no public authority routing, no handoff, no commercialization, no deployment, and no execution unless separately authorized;
5. monitoring and revocation, including access logs, access expiry, review cadence, breach reporting, revocation triggers, correction pathway, sealing, deletion where required, archive update, and non-continuation;
6. boundary notices, confirming that restricted access is permission to access only within recorded limits and is not permission to reuse, publish, train AI, transfer, hand off, deploy, commercialize, or execute.

Access restriction is the first operational defense for protected knowledge. It prevents the public-good stack from treating sensitivity as ordinary content.

### 20.4.3 Publication Restriction

Publication restriction is the control that prevents protected knowledge from being released, quoted, summarized, displayed, mapped, visualized, published, listed, registered publicly, used in media materials, included in public-safe stories, included in Campaign materials, included in Reports, displayed in Nexus Universe, shown in Marketplace, surfaced in public Registry, or otherwise communicated beyond its approved audience unless publication review expressly permits the release class.

Publication restriction applies even where the protected knowledge is factually accurate, technically useful, public-interest relevant, or important to risk understanding. Public interest alone does not override protection. Publication must respect permission, protocol, safety, dignity, privacy, public authority boundaries, community safeguards, Indigenous protocols where applicable, and correctionability.

A Publication Restriction Record should identify:

1. source material, including protected knowledge, community-sensitive knowledge, Indigenous protocol-sensitive knowledge where applicable, health-sensitive information, youth-sensitive information, geospatial-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive material, donor-sensitive material, finance-sensitive material, insurance-sensitive material, or handoff-sensitive material;
2. proposed publication form, including Report, public-safe summary, Campaign material, dashboard, map, Studio output, DRI output, Observatory summary, Academy material, Nexus Universe material, Marketplace listing, Registry display, media-safe package, public authority learning summary, finance-readiness material, donor-readiness material, or handoff-context material;
3. publication status, including publication prohibited, publication pending review, public-safe summary permitted, aggregated release permitted, anonymized release permitted, masked release permitted, controlled-public release permitted, community-review-only, protected-room-only, restricted release, archive-only, sealed, or deletion-required;
4. review requirements, including public-safe review, privacy review, geospatial review, cyber review, infrastructure sensitivity review, health sensitivity review, youth safeguard review, humanitarian sensitivity review, community review, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, legal boundary review, handoff review, and correction review;
5. release conditions, including required redaction, aggregation, anonymization, pseudonymization, geospatial masking, uncertainty language, limitation language, non-stigmatizing language, boundary notices, attribution controls, consent-aware handling, and correction channel display;
6. boundary notices, confirming that publication permission for one release class does not create permission for other publication, reuse, translation, mapping, AI use, training, handoff, deployment, or execution.

Publication restriction keeps Nexus from confusing transparency with exposure. The correct public-good action may be to summarize safely, restrict, seal, archive, or not publish.

### 20.4.4 Translation Restriction

Translation restriction is the control that prevents protected knowledge from being translated, paraphrased, localized, summarized in another language, converted into plain-language form, adapted for accessibility, transformed into public-safe language, rendered into metadata, converted into glossary terms, or used in cross-lingual AI workflows unless the relevant permission, context, protocol, meaning, and safeguard conditions permit the translation.

Translation can change meaning, expose restricted knowledge, strip context, misattribute authority, violate Indigenous protocols where applicable, alter consent boundaries, create publication risk, enable wider circulation, or make protected knowledge searchable and reusable. Nexus shall therefore treat translation as a controlled act, not a neutral formatting step.

A Translation Restriction Record should identify:

1. material to be translated, including story, quote, oral knowledge, cultural reference, ecological knowledge, sacred or protected knowledge, community-sensitive context, legal-sensitive text, public authority-sensitive text, health-sensitive text, youth-sensitive text, geospatial-sensitive description, Report source, DRI input, Observatory signal, Studio input, or National Portfolio material;
2. translation purpose, including public-safe summary, community review, accessibility, Academy use, Report use, Campaign use, public authority learning, Nexus Universe release, Registry metadata, Marketplace listing, finance-readiness review, donor-readiness review, public finance learning, or handoff context;
3. translation status, including translation prohibited, translation pending review, translation permitted for internal review only, community-review translation, Indigenous-protocol review required where applicable, protected knowledge room-only translation, public-safe translation permitted, restricted translation, archive-only translation, sealed, or deletion-required;
4. review requirements, including source-language review, target-language review, cultural context review, community review, Indigenous protocol review where applicable, public-safe review, legal boundary review, safeguard review, accessibility review, and correction review;
5. use limitations, including no publication, no quotation, no metadata extraction, no AI translation, no machine translation, no cross-lingual embedding, no Marketplace display, no public Registry display, no handoff, no donor or finance display, and no reuse beyond recorded purpose unless separately authorized;
6. boundary notices, confirming that translation is not new consent, publication permission, open reuse permission, AI-use permission, public authority approval, handoff permission, deployment authorization, or execution.

Translation restriction protects meaning, context, and permission. A protected idea may remain protected even when translated into safer language.

### 20.4.5 AI-Use Restriction

AI-use restriction is the control that prohibits or limits the use of protected knowledge in AI systems, including training, fine-tuning, embedding, retrieval, summarization, classification, evaluation, synthetic data generation, agentic workflows, automated decision support, benchmarking, model-card preparation, system-card preparation, digital twin workflows, Studio workflows, DRI workflows, Observatory workflows, public authority learning workflows, finance-readiness workflows, and handoff workflows.

Protected knowledge shall not be treated as AI-usable because it is accessible, uploaded, summarized, publicly visible, included in a record, translated, included in metadata, entered into a secure room, included in a data room, referenced in a Report, or routed into Nexus Universe. AI use must be separately labelled and controlled.

An AI-Use Restriction Record should identify:

1. material covered, including data, text, story, transcript, image, video, audio, map, translation, oral knowledge, ecological knowledge, cultural reference, sacred site reference, protected knowledge note, DRI input, Observatory signal, Studio input, Report source, Campaign input, National Portfolio object, or metadata record;
2. AI-use status, including no-AI use, no training, no fine-tuning, no embedding, no agentic use, no synthetic generation, no automated classification, no model evaluation, retrieval-only with review, summarization with review, classification with review, secure-room AI only, public-safe AI output only, or AI-use permitted only by separate recorded authority;
3. reason for restriction, including protected knowledge status, Indigenous protocol where applicable, privacy, youth safeguard, health sensitivity, humanitarian sensitivity, sacred site sensitivity, geospatial sensitivity, cyber sensitivity, infrastructure sensitivity, data sovereignty, copyright or license restriction, consent limitation, public-safe limitation, public authority sensitivity, finance or insurance sensitivity, or handoff limitation;
4. technical controls, including dataset exclusion, model-training exclusion, vector-index exclusion, tool-permission restriction, agentic workflow prohibition, no-write-back, access restriction, logging, output review, prompt-injection controls where applicable, data-room requirement, secure-room requirement, deletion from prohibited AI workflows where required, and archive restriction;
5. incident pathway, including AI-use breach report, model contamination review, output correction, deletion where required, restriction, withdrawal, recall, notification, public repair where appropriate, archive, and non-continuation;
6. boundary notices, confirming that access, publication, summary, translation, or metadata creation does not authorize AI training, fine-tuning, embedding, agentic use, automated decision-making, commercial model use, deployment, or execution.

AI-use restriction protects knowledge from being absorbed into systems that may be difficult to audit, correct, contextualize, or withdraw.

### 20.4.6 Geospatial Masking

Geospatial masking is the control that limits, generalizes, aggregates, delays, redacts, obscures, transforms, or suppresses location information where exact or inferable geography could expose protected knowledge, sacred sites, community-sensitive locations, youth-related locations, health-sensitive locations, shelters, displacement sites, water sources, biodiversity-sensitive sites, critical infrastructure, cyber-physical systems, public authority-sensitive locations, humanitarian operations, or other sensitive places.

Geospatial masking applies to maps, dashboards, DRI records, Observatory summaries, Studio workflows, digital twins, simulations, Reports, Campaign materials, National Portfolio objects, Nexus Universe materials, Marketplace listings, Registry records, Grid inputs, public authority learning materials, finance-readiness materials, donor-readiness materials, insurance-readiness materials, public finance learning materials, handoff dependency notes, media-safe materials, and archives.

A Geospatial Masking Record should identify:

1. location object, including coordinate, address, facility, site, route, boundary, polygon, raster, satellite image, drone image, sensor location, infrastructure node, water source, health site, youth site, shelter, displacement site, sacred site, protected knowledge location, biodiversity-sensitive site, or generalized area;
2. sensitivity class, including community-sensitive, Indigenous protocol-sensitive where applicable, sacred-site-sensitive, youth-sensitive, health-sensitive, humanitarian-sensitive, cyber-sensitive, infrastructure-sensitive, biodiversity-sensitive, public authority-sensitive, public-safety-sensitive, handoff-sensitive, or archive-only;
3. masking method, including no display, coordinate removal, aggregation, generalized geography, spatial jittering where appropriate, scale reduction, delayed release, redaction, bounding area only, public-safe map, controlled map, secure-room-only map, data-room-only map, protected knowledge room-only map, handoff-recipient-only map with separate permission, sealed map, or deletion-required pathway;
4. review requirements, including geospatial review, privacy review, cyber review, infrastructure sensitivity review, community safeguard review, Indigenous protocol review where applicable, humanitarian sensitivity review, public-safe review, public authority boundary review, handoff review, correction review, and archive review;
5. release and correction controls, including map correction, location removal, masking update, dashboard correction, Report correction, Marketplace correction, Registry correction, Studio correction, public repair, withdrawal, recall, sealing, deletion where required, archive, or non-continuation;
6. boundary notices, confirming that location display, masked display, or location reference is not land access permission, facility access permission, community consent, Indigenous consent where applicable, public authority approval, operational instruction, procurement authorization, deployment authorization, or execution.

Geospatial masking prevents maps and spatial records from becoming instruments of exposure, extraction, targeting, or false authorization.

### 20.4.7 Metadata-Only Records

Metadata-only records are protected knowledge control records that preserve the existence, stewardship, class, restrictions, status, correction pathway, and archive rule of protected knowledge without exposing the protected content itself. Metadata-only treatment allows Nexus to maintain status truth, lineage, dependency awareness, review obligations, correctionability, and archive discipline where the underlying knowledge cannot be displayed, summarized, translated, mapped, processed by AI, published, or handed off.

A metadata-only record shall not be used as a loophole to disclose sensitive content indirectly. Metadata itself may be sensitive if it reveals identity, location, source, community, Indigenous protocol-sensitive context where applicable, public authority relationship, health context, youth context, humanitarian context, infrastructure context, cyber context, or handoff pathway.

A Metadata-Only Record should identify:

1. protected object reference, including non-disclosing identifier, object class, steward, lifecycle state, access class, support class where applicable, sensitivity class, and correction pathway;
2. restriction status, including content not displayed, public summary prohibited, translation prohibited, mapping prohibited, AI use prohibited, publication prohibited, Marketplace display prohibited, public Registry display prohibited, handoff prohibited unless separately authorized, sealed, deletion-required, archive-only, or non-continuing;
3. minimal metadata permitted, including title class, domain class, jurisdictional context at safe level, steward role, review status, public-safe status, restriction reason, update date, correction status, archive status, and successor link where safe;
4. metadata sensitivity review, including whether even the existence of the object may be public, controlled, restricted, protected knowledge room-only, public authority learning-only, handoff-recipient-only, sealed, or not displayable;
5. dependency and routing controls, including review required, consent required, Indigenous protocol review required where applicable, community review required, data steward review required, public-safe review required, handoff review required, correction required, archive rule, and deletion rule;
6. boundary notices, confirming that metadata existence is not content access, publication permission, reuse permission, AI-use permission, data release, public authority approval, consent, handoff permission, deployment authorization, or execution.

Metadata-only records preserve memory without exposing the protected knowledge that memory refers to.

### 20.4.8 Sealing and Archive

Sealing and archive are protected knowledge controls that restrict, preserve, close, retire, delete where required, or maintain non-current protected knowledge records under appropriate access, retention, correction, and non-use conditions. Sealing is used where protected material must not be accessed except under narrow recorded authority. Archive is used where material must be preserved as memory, evidence of process, correction history, or legal/institutional record without remaining active.

A sealed or archived protected knowledge object shall not be treated as current, public, reusable, AI-usable, publishable, mappable, translatable, handoff-ready, Marketplace-ready, Registry-public, finance-readiness-ready, donor-readiness-ready, public authority-ready, deployment-ready, or execution-ready.

A Protected Knowledge Sealing and Archive Record should identify:

1. object sealed or archived, including protected knowledge object, data object, story, map, image, DRI input, Observatory signal, Studio input, Report source, Campaign input, National Portfolio object, Registry record, Marketplace candidate, Grid input, finance-readiness material, public authority learning material, or handoff note;
2. trigger, including permission withdrawal, protocol restriction, correction, public-safe risk, data sensitivity, geospatial sensitivity, youth safeguard, health sensitivity, humanitarian sensitivity, public authority sensitivity, cyber or infrastructure sensitivity, protected knowledge incident, supersession, non-continuation, legal requirement, retention expiry, or deletion requirement;
3. status, including sealed, restricted archive, protected knowledge archive, secure-room archive, data-room archive, Indigenous protocol-sensitive archive where applicable, community-sensitive archive, public authority-sensitive archive, handoff-recipient-only archive, deletion-required, deleted where lawfully required, or non-continuing;
4. access rules, including no access, steward-only access, knowledge-holder access, Indigenous governance access where applicable, community steward access, legal boundary access, correction-only access, audit-only access, secure-room-only access, data-room-only access, protected knowledge room-only access, or separate authorization required;
5. non-current notices, including not public, not reusable, not AI-usable, not publishable, not translatable, not mappable, not Marketplace-current, not Registry-public, not handoff-current, not deployment-authorized, and not execution-authorized;
6. boundary notices, confirming that sealing and archive preserve memory or restriction and do not create permission, approval, consent, handoff authority, deployment authority, or execution authority.

Sealing and archive protect Nexus from the false assumption that every record must remain active or visible.

### 20.4.9 Protected Knowledge Incident Response

Protected knowledge incident response is the mandatory response pathway for any suspected or confirmed unauthorized access, disclosure, publication, translation, mapping, AI use, training, copying, quotation, Marketplace display, Registry display, Report inclusion, Campaign use, Studio use, DRI use, Observatory use, National Portfolio use, Nexus Universe display, public authority routing, finance-readiness routing, donor-readiness routing, insurance-readiness routing, public finance learning routing, handoff routing, commercialization, deployment, or execution use of protected knowledge.

Protected knowledge incidents shall be treated as safeguard incidents, data incidents where applicable, AI incidents where applicable, geospatial incidents where applicable, public-safe incidents where applicable, public authority boundary incidents where applicable, and handoff incidents where applicable. Response must prioritize harm reduction, restriction, notification where appropriate, correction, recall, sealing, deletion where required, public repair where appropriate, and recurrence prevention.

A Protected Knowledge Incident Record should identify:

1. incident trigger, including unauthorized access, unauthorized sharing, publication error, translation error, map exposure, geospatial exposure, AI-use breach, training breach, metadata exposure, protected knowledge room breach, data-room breach, secure-room breach, Report error, Campaign error, Marketplace error, Registry error, Studio error, DRI error, Observatory error, public authority routing error, finance-readiness routing error, donor routing error, handoff error, or archive breach;
2. affected knowledge, including protected knowledge class, sensitivity class, custodian context, community context, Indigenous protocol context where applicable, location sensitivity, data class, AI-use status, publication status, and archive status;
3. severity and harm assessment, including privacy harm, dignity harm, cultural harm, sacred site exposure, community harm, youth harm, health harm, humanitarian harm, cyber harm, infrastructure harm, legal harm, public authority harm, commercial harm, donor or finance misuse, handoff misuse, and public-safe harm;
4. immediate actions, including access revocation, takedown, redaction, geospatial masking, AI workflow stop, dataset exclusion, model contamination review, publication correction, Marketplace delisting, Registry restriction, Report correction, Campaign correction, Studio restriction, DRI correction, Observatory correction, public authority notice where appropriate, custodian notice where appropriate, public repair where appropriate, sealing, deletion where required, archive, or recall;
5. downstream propagation, including updates to Reports, Campaigns, DRI records, Observatory records, Studio workflows, Registry, Marketplace, Grid, National Portfolio, Nexus Universe outputs, finance-readiness records, public authority learning records, donor-readiness records, handoff dependency notes, proof receipts, iCRS, ILA where relevant, and archive records;
6. closure and prevention, including correction completed, recall completed, sealing completed, deletion completed where required, notices completed, governance update, access-control update, AI-use-control update, geospatial-control update, training update, template update, recurrence-prevention action, and archive update;
7. boundary notices, confirming that incident response repairs unauthorized use and does not create permission, consent, approval, public authority action, handoff authorization, deployment authorization, or execution.

Protected knowledge incident response must be fast, conservative, and custodian-aware. The system must stop exposure before debating reputational convenience.

### 20.4.10 Public-Safe Substitution

Public-safe substitution is the control that replaces protected knowledge with a safer public-good communication product where public learning is useful but the underlying protected knowledge cannot be disclosed. It may use generalized language, anonymized summaries, aggregated descriptions, masked maps, synthetic examples where appropriate and clearly labelled, non-sensitive analogues, limitation statements, confidence and uncertainty labels, public-safe diagrams, protected-knowledge-not-disclosed notices, or metadata-only references.

Public-safe substitution shall not distort the underlying meaning, imply permission, erase custodianship, fabricate certainty, create false equivalence, or conceal material limitations. It is not a license to publish protected knowledge indirectly. It is a method for communicating safely within boundaries.

A Public-Safe Substitution Record should identify:

1. protected source, including protected knowledge object, community-sensitive source, Indigenous protocol-sensitive source where applicable, sacred site information, youth-sensitive source, health-sensitive source, geospatial-sensitive source, cyber-sensitive source, infrastructure-sensitive source, public authority-sensitive source, or handoff-sensitive source;
2. substitution purpose, including public learning, Report publication, Campaign communication, Academy use, public authority learning, Nexus Universe release, Marketplace display, Registry display, Studio demonstration, readiness room use, donor-reader use, public finance learning use, or handoff-awareness use;
3. substitution method, including aggregation, anonymization, pseudonymization, generalization, masking, redaction, synthetic example, non-sensitive analogue, public-safe summary, metadata-only display, limitation statement, protected-source-withheld notice, or controlled-room summary;
4. review status, including public-safe review, custodian review where appropriate, community review where appropriate, Indigenous protocol review where applicable, data review, AI review, geospatial review, safeguard review, legal boundary review, public authority boundary review, finance and insurance boundary review, handoff review, correction review, and archive review;
5. release class, including public, controlled-public, community-review-only, National Node-visible, public authority learning-only, media-safe, Campaign-safe, Marketplace-safe, Registry-safe, readiness-room-safe, secure-room summary, data-room summary, handoff-context summary, restricted, archive-only, or non-current;
6. boundary notices, confirming that public-safe substitution is not raw knowledge release, open data release, publication permission for the source, AI-use permission, mapping permission, community consent, Indigenous consent where applicable, public authority approval, financeability, insurability, donor commitment, public finance allocation, handoff authorization, deployment authorization, or execution.

Public-safe substitution allows Nexus to communicate what can be safely understood while protecting what must not be exposed.

The final Protected Knowledge Controls rule is: protected knowledge controls define protected knowledge, restrict access, restrict publication, restrict translation, restrict AI use, mask geospatial exposure, preserve metadata-only records, seal and archive sensitive objects, respond to protected knowledge incidents, and substitute public-safe summaries where appropriate. These controls allow Nexus to preserve memory, learning, public-safe communication, correction, and lawful handoff awareness without converting protected knowledge into open content, AI training material, public authority evidence, finance or donor material, consent, deployment authorization, or execution by implication.

## 20.5 Inclusion and Accessibility

### 20.5.1 Disability Inclusion

Disability inclusion is the Nexus safeguard rule that persons with disabilities must be able to participate in, review, benefit from, correct, and challenge Nexus records, Campaigns, Reports, Academy pathways, Risk Academy materials, Studio workflows, DRI outputs, Observatory summaries, dashboards, Marketplace listings, Registry records, Nexus Universe arenas and rooms, public authority learning rooms, readiness rooms, secure rooms, data rooms, public-safe stories, volunteer pathways, Working Groups, Competence Cells, Foundry builds, finance-readiness materials, public authority learning materials, and handoff dependency notes without discrimination, avoidable exclusion, inaccessible design, unsafe exposure, or tokenization.

Disability inclusion is not a cosmetic accessibility checklist. It is a condition of public-good legitimacy. A Nexus object that cannot be read, navigated, heard, understood, corrected, or accessed by affected participants cannot claim mature public-good status. Disability inclusion must therefore be applied at design, intake, review, release, publication, event planning, room access, dashboard development, Studio workflow preparation, Marketplace listing, Registry display, Academy delivery, Campaign mobilization, Nexus Universe routing, public-safe reporting, correction, and archive.

A Disability Inclusion Record should identify:

1. disability inclusion context, including physical access, digital access, sensory access, cognitive access, communication access, language access, assistive technology compatibility, participation accommodations, event accessibility, learning accessibility, public-safe summary accessibility, and correction-channel accessibility;
2. object or pathway covered, including Report, dashboard, DRI output, Observatory summary, Studio workflow, Campaign material, Academy module, Nexus Universe room, Marketplace listing, Registry record, Grid input, public authority learning room, readiness room, secure room, data room, finance-readiness record, handoff dependency note, or archive record;
3. accessibility needs and barriers, including mobility barriers, visual barriers, hearing barriers, cognitive barriers, neurodiversity-related barriers, speech or communication barriers, language barriers, low-literacy barriers, device barriers, bandwidth barriers, captioning gaps, alternative format gaps, and plain-language gaps;
4. required controls, including accessible design, reasonable accommodation where applicable, alternative formats, captions, transcripts, alt text, keyboard navigation, screen-reader compatibility, plain-language summary, low-bandwidth version, mobile-first design, offline package, accessible venue planning, accessible facilitation, and correction pathway;
5. review and release status, including accessibility reviewed, remediation required, accessible summary required, alternative format required, accommodation required, restricted until remediated, corrected, archived, or non-continuing;
6. boundary notices, confirming that accessibility status is a public-good safeguard and usability record, not certification, legal compliance determination, procurement approval, public authority approval, consent, deployment authorization, or execution.

Disability inclusion ensures that Nexus does not build public-good systems that exclude the public they claim to serve.

### 20.5.2 Accessibility-by-Design

Accessibility-by-design is the requirement that Nexus objects, rooms, platforms, publications, dashboards, Studio workflows, Academy pathways, Campaign tools, Registry displays, Marketplace listings, Nexus Universe materials, DRI summaries, Observatory outputs, public authority learning materials, finance-readiness materials, and correction channels be designed for accessibility from the beginning rather than remediated only after exclusion occurs.

Accessibility-by-design requires accessibility to be treated as an architectural design constraint, not a late-stage formatting task. It applies to document structure, headings, navigation, color contrast, typography, language, captions, transcripts, alt text, keyboard navigation, screen-reader compatibility, mobile access, low-bandwidth access, offline access, plain-language summaries, multilingual accessibility where appropriate, and accessible correction pathways.

An Accessibility-by-Design Record should identify:

1. design object, including digital platform, website, dashboard, Report, Campaign page, Academy module, Studio workflow, Marketplace listing, Registry record, Nexus Universe room material, public authority learning material, readiness room material, finance-readiness material, or handoff dependency material;
2. design stage, including concept, intake, draft, build, review, public-safe transformation, controlled release, public release, Registry display, Marketplace listing, Nexus Universe release, correction, or archive;
3. accessibility requirements, including semantic structure, readable formatting, screen-reader compatibility, keyboard operability, alt text, captions, transcripts, plain-language summary, contrast, responsive design, low-bandwidth option, mobile-first access, offline package, accessible forms, accessible correction channel, and accessible support contact;
4. participant review, including disability stakeholder review where appropriate, accessibility reviewer review, user testing where feasible, public-safe review, language review, and correction review;
5. remediation and release controls, including remediation required, release blocked until corrected, limited release, accessible alternative required, correction required, archive with accessibility limitation notice, or non-continuation;
6. boundary notices, confirming that accessibility-by-design supports inclusion and usability and does not by itself create legal compliance certification, procurement approval, public authority approval, deployment authorization, or execution.

Accessibility-by-design prevents Nexus from treating disabled participants as afterthoughts. It builds inclusion into the rail itself.

### 20.5.3 Screen-Reader Compatibility

Screen-reader compatibility is the requirement that Nexus digital materials be structured so that screen-reader users can navigate, understand, interact with, and correct them. It applies to Reports, webpages, dashboards, forms, Campaign tools, Academy materials, Risk Academy materials, Studio interfaces, Registry records, Marketplace listings, DRI summaries, Observatory summaries, public authority learning materials, readiness room materials, Nexus Universe materials, public-safe summaries, and correction channels.

Screen-reader compatibility requires more than machine-readable text. Materials should use semantic headings, ordered structure, descriptive links, labelled form fields, meaningful table headers, accessible charts, alt text, non-image text, keyboard navigation, logical reading order, error messages that can be read, and avoidance of visual-only cues.

A Screen-Reader Compatibility Record should identify:

1. covered object, including Report, dashboard, form, Campaign page, Academy module, Studio workflow, Registry display, Marketplace listing, DRI output, Observatory summary, public authority learning material, readiness room material, Nexus Universe page, or correction channel;
2. compatibility requirements, including semantic headings, labelled controls, keyboard navigation, focus order, table headers, descriptive link text, alt text, chart descriptions, non-image text, accessible error messages, skip navigation where applicable, and logical reading sequence;
3. review status, including automated accessibility check, manual review, assistive-technology review where feasible, public-safe review, accessibility remediation required, corrected, archived, or non-continuing;
4. known limitations, including complex visualization, inaccessible third-party platform, embedded document limitations, scanned document limitation, interactive dashboard limitation, or unsupported format limitation;
5. alternative access, including accessible text version, plain-language summary, downloadable accessible document, transcript, described chart, human support channel, or offline package;
6. boundary notices, confirming that screen-reader compatibility is an accessibility control and not certification, warranty, procurement approval, public authority approval, deployment authorization, or execution.

Screen-reader compatibility ensures that Nexus status truth, learning, and correction pathways are not available only to sighted users.

### 20.5.4 Alt Text

Alt text is the accessibility control requiring meaningful text alternatives for images, diagrams, charts, maps, icons, screenshots, infographics, Studio visuals, DRI visuals, Observatory visuals, Campaign visuals, Marketplace visuals, Registry visuals, Nexus Universe visuals, Academy visuals, public authority learning visuals, readiness-room visuals, and public-safe reporting visuals.

Alt text must communicate the purpose and relevant content of the visual without overexposing protected knowledge, sensitive locations, community-sensitive details, Indigenous protocol-sensitive information where applicable, youth-sensitive information, health-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive information, finance-sensitive information, or handoff-sensitive information.

An Alt Text Record should identify:

1. visual object, including image, diagram, chart, map, dashboard screenshot, Studio output, DRI visualization, Observatory visualization, Campaign graphic, Report figure, Academy graphic, Marketplace image, Registry display, Nexus Universe visual, or media-safe material;
2. alt text purpose, including navigation, explanation, public-safe communication, learning support, chart interpretation, map summary, Campaign accessibility, Report accessibility, or correction accessibility;
3. content controls, including meaningful description, non-visual equivalent, uncertainty language where needed, limitation language, no hidden protected knowledge, no sensitive coordinate exposure, no stigmatizing description, no public authority overclaim, no finance or insurance overclaim, no consent overclaim, and no execution overclaim;
4. sensitivity review, including community sensitivity, Indigenous protocol sensitivity where applicable, protected knowledge, youth safeguard, health sensitivity, geospatial sensitivity, cyber sensitivity, infrastructure sensitivity, media sensitivity, and public-safe review;
5. correction pathway, including alt text correction, visual correction, public-safe correction, map masking, image removal, Report correction, Campaign correction, Marketplace correction, Registry correction, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that alt text is an accessibility support and does not create additional publication permission, data release, public authority status, financeability, insurability, consent, deployment authorization, or execution.

Alt text should make visuals accessible without turning accessibility into a channel for unsafe disclosure.

### 20.5.5 Captions and Transcripts

Captions and transcripts are accessibility controls required for Nexus audio, video, webinars, public-safe briefings, Academy modules, Risk Academy modules, Nexus Universe sessions, Campaign videos, Studio demonstrations, public authority learning sessions, readiness room recordings where recording is permitted, interviews, podcasts, media-safe materials, training materials, and recorded presentations.

Captions and transcripts must be accurate enough for meaningful participation, review, learning, correction, and archive. They must also be reviewed for protected knowledge, community sensitivity, Indigenous protocol sensitivity where applicable, youth safeguards, health sensitivity, public authority overclaim, finance or insurance overclaim, donor overclaim, consent overclaim, deployment overclaim, and execution overclaim before broader release.

A Captions and Transcripts Record should identify:

1. source media, including video, audio, webinar, session recording, Studio demonstration, Academy module, Campaign video, public authority learning session, readiness room material, interview, podcast, or Nexus Universe recording;
2. accessibility requirement, including captions, transcript, speaker identification where appropriate, language version, translation status, plain-language summary, audio description where needed, and accessible file format;
3. release class, including public, controlled-public, participant-only, public authority learning-only, secure-room-only, data-room-only, protected knowledge room-only, media-safe, archive-only, restricted, sealed, or deletion-required;
4. review controls, including accuracy review, public-safe review, protected knowledge review, community review where appropriate, Indigenous protocol review where applicable, youth safeguard review, public authority boundary review, finance and insurance boundary review, donor boundary review, legal boundary review, and correction review;
5. correction actions, including caption correction, transcript correction, redaction, restricted release, takedown, public repair, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that captions and transcripts are accessibility records and do not create additional publication permission, consent, public authority approval, financeability, insurability, donor commitment, deployment authorization, or execution.

Captions and transcripts make spoken Nexus work accessible and correctable, while preserving the same safeguards that apply to written records.

### 20.5.6 Plain-Language Summaries

Plain-language summaries are accessibility and public-safe communication products that explain Nexus materials in clear, understandable language without oversimplifying uncertainty, removing safeguards, hiding limitations, implying public authority action, implying finance or insurance approval, implying donor commitment, implying consent, implying deployment authorization, or implying execution.

Plain-language summaries may be required for Reports, DRI outputs, Observatory summaries, Studio workflows, Campaigns, Academy modules, Risk Academy materials, National Portfolio records, Nexus Universe outputs, Marketplace listings, Registry records, Grid and TRL context, finance-readiness materials, public authority learning records, safeguard records, and handoff dependency notes.

A Plain-Language Summary Record should identify:

1. source object, including Report, DRI output, Observatory summary, Studio workflow, National Portfolio object, Campaign material, Academy object, Registry record, Marketplace listing, Grid input, Nexus Universe output, finance-readiness record, public authority learning record, safeguard record, or handoff note;
2. audience, including community participants, youth participants, public authority learners, learners, media-safe audiences, donors, public finance learners, capital readers, insurance readers, Academy participants, Nexus Universe participants, or general public;
3. summary requirements, including clear purpose, scope, key findings, uncertainty, limitations, what the object does not mean, correction pathway, archive status, accessibility needs, language needs, and public-safe boundaries;
4. boundary language, including not policy, not warning, not decision, not certification, not procurement, not finance, not insurance, not donor commitment, not public finance allocation, not consent, not deployment authorization, and not execution;
5. review status, including plain-language review, public-safe review, accessibility review, community review where appropriate, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, donor boundary review, legal review, and correction review;
6. boundary notices, confirming that plain-language summaries improve understanding but do not replace the governing record, create new permissions, expand access rights, or authorize downstream action.

Plain-language summaries are essential because inaccessible complexity can itself become exclusion. Clarity must not become overclaim.

### 20.5.7 Low-Bandwidth Access

Low-bandwidth access is the requirement that Nexus materials and participation pathways should be usable where internet connectivity, device capacity, electricity, data affordability, platform access, or digital infrastructure are limited. This applies especially to community participation, public authority learning, Academy pathways, Campaigns, public-safe reporting, Nexus Universe participation, DRI summaries, Observatory summaries, Reports, correction channels, and National Portfolio review.

Low-bandwidth access may include lightweight pages, compressed files, text-first versions, downloadable packets, offline bundles, printable summaries, audio alternatives where appropriate, SMS or messaging-compatible summaries where lawful and safe, low-resolution optional media, no-autoplay design, asynchronous access, and local facilitator packages.

A Low-Bandwidth Access Record should identify:

1. access context, including community, national, regional, public authority, Academy, Campaign, Nexus Universe, emergency-learning, humanitarian, rural, remote, low-connectivity, degraded-mode, or mobile-only context;
2. covered materials, including Reports, public-safe summaries, Academy modules, Campaign materials, DRI summaries, Observatory summaries, Studio summaries, dashboards, Registry records, Marketplace listings, National Portfolio materials, correction channels, and handoff-awareness summaries;
3. low-bandwidth format, including text-first page, compressed PDF, accessible HTML, offline package, lightweight dashboard summary, downloadable dataset summary, printable packet, audio file, transcript, messaging summary, or local facilitator package;
4. safeguard controls, including public-safe review, data minimization, protected knowledge exclusion, geospatial masking, privacy, youth safeguards, community sensitivity, Indigenous protocol controls where applicable, and correction instructions;
5. support and correction, including local support contact, correction channel, update cadence, version control, archive status, and non-current notices;
6. boundary notices, confirming that low-bandwidth access does not reduce safeguards, expand permissions, create public authority approval, imply consent, authorize deployment, or execute implementation.

Low-bandwidth access ensures that Nexus does not equate participation with high-speed connectivity.

### 20.5.8 Mobile-First Access

Mobile-first access is the requirement that Nexus participation, learning, public-safe reporting, Campaign tools, correction channels, Academy pathways, Nexus Universe materials, Marketplace discovery, Registry status displays, DRI summaries, Observatory summaries, Reports summaries, and public authority learning materials be usable on mobile devices where mobile access is the primary or only practical access mode.

Mobile-first access requires readable layouts, accessible navigation, touch-friendly controls, low-data design, clear forms, safe identity handling, minimal file size, responsive design, offline or save-for-later options, captioned media, plain-language summaries, and secure participation pathways.

A Mobile-First Access Record should identify:

1. mobile access object, including Campaign page, correction form, Academy module, Report summary, DRI summary, Observatory summary, public authority learning material, Nexus Universe schedule, Registry display, Marketplace listing, Studio summary, readiness question form, or public-safe story form;
2. mobile usability requirements, including responsive layout, readable font size, clear headings, touch-friendly controls, low-data mode, no horizontal scrolling where avoidable, accessible forms, keyboard compatibility, screen-reader support, captioned media, and save/offline option where appropriate;
3. safety controls, including privacy, safe-session design, youth safeguards, community sensitivity, protected knowledge exclusion, geospatial exposure prevention, secure submission, and correction pathway visibility;
4. language and accessibility, including plain-language summary, multilingual access where appropriate, captions, transcripts, alt text, screen-reader compatibility, and accessible error messages;
5. review and remediation, including mobile testing, accessibility review, public-safe review, correction review, remediation required, restricted release, archive, or non-continuation;
6. boundary notices, confirming that mobile-first access is an inclusion control and does not create consent, public authority approval, financeability, insurability, donor commitment, deployment authorization, or execution.

Mobile-first access recognizes that a public-good system that only works on institutional desktops is not genuinely public-facing.

### 20.5.9 Offline Packages

Offline packages are controlled Nexus materials prepared for use without continuous internet access, including printable packets, downloadable archives, USB or local-device packages where appropriate, local facilitator kits, classroom kits, field kits, public authority learning kits, Campaign kits, Academy kits, Risk Academy kits, DRI summary packets, Observatory summary packets, National Portfolio packets, public-safe Report packets, and Nexus Universe continuation packets.

Offline packages are powerful inclusion tools but also create control risks because outdated, copied, or uncontrolled materials may circulate after correction, withdrawal, recall, supersession, archive, or non-continuation. Every offline package must therefore carry version control, correction pathway, archive notice, public-safe limits, access class, permitted-use limits, and update instructions.

An Offline Package Record should identify:

1. package class, including community packet, Academy packet, Campaign packet, public authority learning packet, DRI packet, Observatory packet, National Portfolio packet, Nexus Universe packet, readiness packet, safeguard packet, or handoff-awareness packet;
2. contents, including Reports, summaries, worksheets, learning modules, diagrams, transcripts, captions, alt text, forms, correction instructions, contact information, Registry status extract, Marketplace extract, public-safe DRI summary, Observatory summary, Studio summary, or handoff dependency summary;
3. access and use class, including public, controlled-public, participant-only, public authority learning-only, community-review-only, youth-safe, secure-room-derived summary, data-room-derived summary, protected knowledge excluded, archive-only, or restricted;
4. version and correction controls, including version number, date, steward, expiry or refresh date, correction channel, recall notice, supersession notice, archive rule, and non-current warning;
5. safeguard controls, including public-safe review, accessibility review, language review, community review where appropriate, Indigenous protocol review where applicable, protected knowledge exclusion, geospatial masking, youth safeguards, and humanitarian sensitivity;
6. boundary notices, confirming that offline package use is learning and public-safe communication only and does not create public authority action, donor commitment, financeability, insurability, procurement approval, consent, deployment authorization, or execution.

Offline packages extend access while preserving status truth.

### 20.5.10 Accessibility Correction

Accessibility correction is the pathway through which participants, learners, public authority learners, community members, disability advocates, youth participants, facilitators, reviewers, stewards, and users may report, correct, restrict, replace, withdraw, recall, archive, or mark non-continuing Nexus materials or environments that are inaccessible, exclusionary, confusing, unsafe, incompatible with assistive technology, missing captions, missing transcripts, lacking alt text, failing screen-reader access, unavailable in plain language where needed, unusable on mobile, unusable offline, too bandwidth-intensive, physically inaccessible, or otherwise exclusionary.

Accessibility correction must be treated as a substantive safeguard correction, not merely a design preference. If a Nexus output cannot be accessed by affected participants, its public-good release class, Marketplace listing, Registry display, Nexus Universe routing, Academy use, Campaign use, Report release, or handoff-context use may need correction, restriction, downgrade, withdrawal, recall, archive, or non-continuation.

An Accessibility Correction Record should identify:

1. correction source, including participant, person with disability, accessibility advocate, community member, youth participant, public authority learner, Academy learner, facilitator, reviewer, steward, or external user;
2. affected object or environment, including Report, dashboard, Campaign page, Academy module, Studio workflow, DRI output, Observatory summary, Registry display, Marketplace listing, Nexus Universe room, public authority learning room, readiness room, correction channel, offline package, mobile interface, video, audio, image, form, or archive material;
3. accessibility issue class, including screen-reader failure, keyboard navigation failure, missing alt text, missing captions, missing transcript, poor contrast, inaccessible table, inaccessible chart, inaccessible map, complex language, no plain-language summary, mobile failure, low-bandwidth failure, unavailable offline package, physical access barrier, sensory access barrier, cognitive access barrier, language access barrier, or accommodation failure;
4. severity and action, including monitor, correct, provide alternative format, provide accommodation, restrict release, downgrade release class, update Registry status, update Marketplace listing, issue correction notice, withdraw, recall, archive, or mark non-continuing;
5. downstream propagation, including updates to Reports, Campaigns, Academy, Studio, DRI, Observatory, Registry, Marketplace, Grid, Nexus Universe, public authority learning materials, finance-readiness materials, handoff notes, offline packages, and archive records;
6. closure and prevention, including correction completed, alternative provided, participant notified where appropriate, template updated, design standard updated, training updated, review cadence updated, archive updated, and recurrence-prevention action;
7. boundary notices, confirming that accessibility correction preserves inclusion and does not create certification, procurement approval, public authority approval, consent, deployment authorization, or execution.

Accessibility correction is the repair mechanism that makes inclusion real. Nexus is not accessible because it says so; it is accessible only if inaccessible outputs can be corrected.

The final Inclusion and Accessibility rule is: inclusion and accessibility require disability inclusion, accessibility-by-design, screen-reader compatibility, alt text, captions and transcripts, plain-language summaries, low-bandwidth access, mobile-first access, offline packages, and accessibility correction. These controls ensure that Nexus public-good records, rooms, platforms, learning pathways, Campaigns, Reports, Studio workflows, DRI, Observatory, Marketplace, Registry, Nexus Universe, finance-readiness, public authority learning, and handoff materials can be accessed, understood, used, and corrected by diverse participants without creating certification, public authority approval, procurement status, consent, deployment authorization, or execution by implication.

## 20.6 Humanitarian Sensitivity

### 20.6.1 Disaster-Affected People

Disaster-affected people are persons, households, communities, workers, volunteers, public-service users, youth, older persons, persons with disabilities, displaced persons, informal settlement residents, rural populations, urban populations, Indigenous peoples where applicable, and other affected stakeholders experiencing or recovering from hazard events, cascading disruption, infrastructure failure, WFEH-B stress, degraded-mode conditions, climate shocks, nature shocks, public health disruption, cyber-physical disruption, or other disaster-related impacts.

Nexus work involving disaster-affected people shall be handled with heightened humanitarian sensitivity. Their experience may inform DRI records, Observatory needs, public-safe Reports, Studio scenarios, Campaigns, Academy learning, Risk Academy learning, National Portfolio updates, Nexus Universe rooms, readiness questions, protection-gap records, risk-layering records, donor-readiness questions, public finance relevance questions, and handoff dependency notes. Their visibility shall not be used as promotional material, donor prioritization evidence, insurance scoring input, public authority warning, public finance allocation basis, consent record, deployment authorization, or execution instruction by default.

A Disaster-Affected People Safeguard Record should identify:

1. affected context, including hazard, disaster phase, displacement status where relevant, WFEH-B disruption, infrastructure dependency, public health issue, degraded-mode condition, community sensitivity, youth sensitivity, disability inclusion need, humanitarian sensitivity, and public authority context;
2. knowledge or data involved, including story, image, video, map, location, needs statement, risk observation, DRI input, Observatory signal, Studio input, Report source, Campaign material, National Portfolio note, or correction request;
3. harm risks, including privacy exposure, retraumatization, stigmatization, geospatial exposure, aid-prioritization overclaim, public warning overclaim, public authority overclaim, media exploitation, donor overclaim, finance or insurance misuse, targeting misuse, policing misuse, and handoff misuse;
4. control measures, including public-safe transformation, anonymization, aggregation, geospatial masking, trauma-informed review where appropriate, accessibility, language access, youth safeguards, disability inclusion, community correction channels, and protected knowledge restrictions;
5. permitted outputs, including public-safe summary, safeguarded Report input, DRI improvement need, Observatory need, Studio scenario input, Academy learning object, Campaign-safe material, National Portfolio update, readiness question, handoff dependency note, correction record, or archive record;
6. boundary notices, confirming that disaster-affected participation or representation is not consent, aid prioritization, donor commitment, public finance allocation, public warning, public authority action, insurance score, procurement priority, deployment authorization, or execution.

Disaster-affected people shall be treated as rights-bearing and dignity-bearing participants, not as evidence props for urgency.

### 20.6.2 Conflict-Affected People

Conflict-affected people are persons, households, communities, institutions, workers, civil society actors, humanitarian actors, displaced populations, refugees, migrants, youth, persons with disabilities, public-service users, and other affected stakeholders living under, fleeing from, recovering from, or otherwise exposed to armed conflict, political violence, insecurity, occupation, civil unrest, persecution, targeted violence, or conflict-related disruption.

Nexus work involving conflict-affected people shall apply the most protective public-safe, humanitarian, privacy, security, geospatial, protected knowledge, and no-targeting controls. Conflict-sensitive material shall not be used to expose identities, locations, routes, affiliations, protected status, service access, community networks, humanitarian operations, public authority relationships, data trails, or vulnerability profiles unless a separate lawful and safeguard-cleared pathway permits a tightly bounded use.

A Conflict-Affected People Safeguard Record should identify:

1. conflict context, including insecurity, displacement, protection risk, humanitarian access issue, community sensitivity, public authority sensitivity, cross-border sensitivity, geospatial sensitivity, cyber sensitivity, infrastructure sensitivity, health sensitivity, youth sensitivity, and protected knowledge status;
2. affected material, including personal data, story, testimony, image, video, map, route, facility, shelter, service location, DRI input, Observatory signal, Studio scenario, Report source, Campaign material, National Portfolio object, or handoff dependency note;
3. protection risks, including identification risk, retaliation risk, targeting risk, surveillance risk, policing misuse, stigmatization, political misuse, geospatial exposure, humanitarian access harm, public authority overclaim, media exploitation, donor overclaim, and finance or insurance misuse;
4. mandatory controls, including minimization, anonymization, aggregation, masking, no public location display, no operational route display, no AI training, no profiling, no targeting use, no policing use by default, restricted access, protected knowledge room handling where required, and correction channels;
5. release status, including publication prohibited, public-safe summary only, controlled-public summary, humanitarian-sensitive archive, secure-room-only, data-room-only, protected knowledge room-only, public authority learning-only with restrictions, handoff-recipient-only with separate permission, sealed, deletion-required, or non-continuing;
6. boundary notices, confirming that conflict-affected participation, data, or representation is not consent, intelligence authorization, targeting authorization, policing authorization, public authority action, donor priority, public finance allocation, deployment authorization, or execution.

Conflict-affected people shall not be made more visible than their safety permits.

### 20.6.3 Displaced Persons

Displaced persons are persons, households, families, children, youth, older persons, persons with disabilities, workers, communities, and groups who have been forced or compelled to leave their homes, habitual residences, livelihoods, schools, care networks, or community places because of disaster, conflict, climate impacts, infrastructure failure, violence, persecution, public health emergencies, environmental degradation, economic shock, or cascading WFEH-B disruption.

Nexus may learn from displacement-related risk patterns, service gaps, protection gaps, public-safe needs, data gaps, DRI needs, Observatory needs, Studio scenarios, Campaigns, National Portfolio records, Nexus Universe rooms, Academy pathways, donor-readiness questions, public finance relevance questions, and handoff dependencies. Nexus shall not expose displaced persons to tracking, profiling, policing, targeting, aid exclusion, stigma, unsafe return pressure, public authority misuse, or unauthorized handoff.

A Displaced Persons Safeguard Record should identify:

1. displacement context, including cause, phase, location at a safe level, shelter context, service-access context, WFEH-B dependency, public authority context, humanitarian context, cross-border context, youth and family sensitivity, disability inclusion needs, and protection concerns;
2. data and knowledge classes, including personal data, household data, movement data, route data, shelter data, service-use data, health-sensitive data, youth data, geospatial-sensitive data, story data, DRI input, Observatory signal, Studio input, or public-safe summary;
3. risk controls, including no exact location display, no route display, no profiling, no AI training by default, no policing use by default, no targeting use by default, no eligibility determination by Nexus, no public authority decision by Nexus, no aid prioritization by implication, and no consent by participation;
4. public-safe transformation, including aggregation, anonymization, pseudonymization, geospatial masking, delayed release, non-stigmatizing language, accessibility, language access, humanitarian sensitivity review, and correction channel display;
5. routing limits, including restricted Reports, DRI improvement, Observatory needs, Studio scenarios, public authority learning-only with restrictions, donor-readiness question, public finance relevance question, protection-gap record, handoff dependency note, archive, or deletion-required pathway;
6. boundary notices, confirming that displacement-related records are not immigration status determinations, eligibility determinations, public authority decisions, aid allocations, policing tools, targeting tools, consent records, deployment authorizations, or execution instructions.

Displacement-related learning shall support dignity, protection, and systems understanding without turning displacement into trackable exposure.

### 20.6.4 Refugees and Migrants

Refugees and migrants are persons and communities moving across or within borders for reasons that may include conflict, persecution, disaster, climate stress, economic disruption, labor mobility, family reunification, education, safety, or other complex drivers. Nexus shall treat refugee and migrant-related information as highly sensitive where disclosure, profiling, categorization, location exposure, legal-status inference, public authority routing, AI processing, or public reporting may create harm.

Nexus may support public-good learning about systems risk, WFEH-B dependencies, displacement pressures, service access, public-safe reporting, labor-market transition, SCF pathways, Academy pathways, humanitarian sensitivity, public authority learning, public finance relevance, donor-readiness, and lawful handoff dependencies. Nexus shall not classify, rank, verify, screen, police, surveil, target, adjudicate, or determine refugee or migrant status by default.

A Refugee and Migrant Safeguard Record should identify:

1. participant or population context, including refugee, asylum-seeking, migrant, internally mobile, diaspora, cross-border, labor-mobility, student, family, humanitarian, or mixed-movement context, described only at the level needed for the public-good purpose;
2. sensitive data classes, including identity, nationality, route, legal status, location, employer, family status, health status, youth status, service access, education, language, vulnerability, protection need, or community network;
3. use restrictions, including no legal-status inference, no eligibility determination, no enforcement use, no policing use by default, no targeting use by default, no AI profiling, no automated ranking, no public location display, no route display, no donor-priority overclaim, and no public authority action by Nexus;
4. safe learning uses, including public-safe aggregation, service-gap learning, WFEH-B dependency learning, workforce and competency pathway learning, humanitarian sensitivity learning, protection-gap literacy, DRI improvement, Observatory need, Studio scenario, Report summary, and National Portfolio update;
5. correction and access controls, including restricted access, anonymization, pseudonymization, language access, community correction channels, humanitarian review, public authority boundary review, archive restrictions, sealing, and deletion where required;
6. boundary notices, confirming that refugee or migrant participation, data, or representation is not consent, legal-status confirmation, public authority action, aid prioritization, donor commitment, public finance allocation, deployment authorization, or execution.

Refugee and migrant safeguards protect people from being reduced to movement data, vulnerability profiles, or institutional categories.

### 20.6.5 Humanitarian Operations

Humanitarian operations are activities, facilities, logistics, routes, personnel, partners, service points, distribution systems, health operations, shelter operations, protection operations, water and sanitation operations, food assistance operations, energy access operations, communications operations, data systems, public information channels, and coordination mechanisms undertaken by humanitarian actors, public authorities, civil society, communities, or other lawful actors in humanitarian contexts.

Nexus may learn from humanitarian operations at a public-safe level for DRR learning, DRI improvement, Observatory needs, Studio scenarios, Reports, Academy modules, National Portfolio records, donor-readiness questions, public finance relevance questions, protection-gap records, risk-layering records, and handoff dependency notes. Nexus shall not expose operational details, routes, schedules, beneficiary lists, facility coordinates, security protocols, partner identities, or sensitive logistics in ways that could create targeting, exploitation, theft, interference, public authority misuse, policing misuse, or operational harm.

A Humanitarian Operations Safeguard Record should identify:

1. operation context, including sector, service type, geographic area at a safe level, public authority relationship, humanitarian actor relationship, community relationship, WFEH-B dependency, infrastructure dependency, protection context, and security context;
2. sensitive operational information, including facility locations, routes, schedules, distribution plans, staff or volunteer identities, beneficiary information, communications channels, logistics assets, data systems, partner networks, security protocols, and operational constraints;
3. public-safe use, including aggregated learning, anonymized summary, generalized operational lesson, DRI improvement need, Observatory need, Studio scenario, Academy module, donor-readiness question, public finance relevance question, safeguard note, or handoff dependency note;
4. prohibited use, including real-time operational disclosure, targeting support, policing support by default, surveillance support, procurement direction, donor allocation by implication, public finance allocation, emergency command, deployment direction, and execution direction;
5. review controls, including humanitarian sensitivity review, security review, geospatial masking, public-safe review, public authority boundary review, protected knowledge review, data review, AI-use review, correction review, and archive review;
6. boundary notices, confirming that humanitarian operation information is not public warning, operational command, targeting authority, policing authority, aid allocation, donor commitment, public finance allocation, procurement approval, consent, deployment authorization, or execution.

Humanitarian operations safeguards ensure that learning from humanitarian work does not endanger the work or the people it serves.

### 20.6.6 Health-Sensitive Contexts

Health-sensitive contexts are contexts involving health status, disease, disability, mental health, trauma, public health risk, health-service access, health-system pressure, health infrastructure, outbreak-related learning, climate-health risk, disaster-health risk, biosecurity learning, health data, youth health, community health, humanitarian health operations, public health authority learning, or any health-related material that could stigmatize, expose, profile, or harm persons or communities.

Nexus may support health-related public-good learning through WFEH-B records, DRI, Observatory, Studio, Reports, Academy pathways, Risk Academy pathways, public authority learning, National Portfolios, Nexus Universe, donor-readiness, public finance relevance, and handoff dependency notes. Nexus shall not provide clinical advice, public health advisories, treatment recommendations, outbreak warnings, health eligibility decisions, diagnostic classifications, health ratings, insurance scores, deployment instructions, or public health authority action by default.

A Health-Sensitive Safeguard Record should identify:

1. health context, including public health, health-system resilience, climate-health, disaster-health, humanitarian health, youth health, disability-related health context, mental health sensitivity, biosecurity learning, WFEH-B dependency, health-service access, or health infrastructure dependency;
2. sensitive data class, including personal health information, community health information, service access information, health facility information, health-worker information, youth health data, disability-related data, outbreak-related data, trauma-related data, or health-sensitive geospatial information;
3. review controls, including privacy review, health-sensitive review, youth safeguard review, disability inclusion review, public-safe review, public health authority boundary review, geospatial review, AI-use review, humanitarian sensitivity review, safeguard review, legal boundary review, and correction review;
4. use limitations, including no clinical advice, no treatment guidance, no public health advisory, no outbreak warning, no diagnosis, no eligibility determination, no insurance scoring, no AI training by default, no public facility exposure, no stigmatizing language, and no handoff without separate authority;
5. permitted outputs, including public-safe health-system learning summary, WFEH-B dependency note, DRI improvement need, Observatory need, Studio scenario, Academy module, public authority learning question, donor-readiness question, public finance relevance question, handoff dependency note, correction record, or archive record;
6. boundary notices, confirming that health-sensitive Nexus materials are not clinical guidance, public health advice, public warning, public authority action, insurance determination, consent, deployment authorization, or execution.

Health-sensitive safeguards protect people from being harmed by the misuse of health-related learning.

### 20.6.7 Food and Water Insecurity Contexts

Food and water insecurity contexts are humanitarian and systems-risk contexts involving insufficient, unsafe, unreliable, unaffordable, disrupted, contaminated, conflict-affected, climate-affected, disaster-affected, infrastructure-dependent, or inequitable access to food, nutrition, water, sanitation, irrigation, supply chains, health-supporting services, ecosystem services, or related WFEH-B systems.

Nexus may support learning about food and water insecurity through DRI records, Observatory needs, WFEH-B systems maps, Studio scenarios, Reports, Campaigns, Academy pathways, Risk Academy pathways, public authority learning, National Portfolio updates, donor-readiness questions, public finance relevance questions, protection-gap records, risk-layering records, and handoff dependency notes. It shall not expose vulnerable communities, water points, food distribution points, operational routes, household conditions, health status, or sensitive locations in ways that create targeting, stigma, theft, panic, exploitation, or public authority misuse.

A Food and Water Insecurity Safeguard Record should identify:

1. insecurity context, including food availability, food access, nutrition, water access, water quality, sanitation, irrigation, supply chain, energy dependency, health dependency, biodiversity dependency, climate shock, disaster shock, conflict sensitivity, displacement sensitivity, or degraded-mode condition;
2. sensitive material, including household data, community data, service access data, water point location, distribution location, food storage location, health-related information, price or supply information where sensitive, route information, public authority-sensitive information, or humanitarian operational information;
3. risk of harm, including stigmatization, panic, theft, targeting, political misuse, aid-prioritization overclaim, donor overclaim, public finance overclaim, public warning overclaim, geospatial exposure, health exposure, and community consent overclaim;
4. public-safe controls, including aggregation, anonymization, geospatial masking, delayed release, non-stigmatizing language, humanitarian sensitivity review, community safeguard review, public authority boundary review, youth safeguards, disability inclusion, protected knowledge restrictions, and correction channels;
5. permitted outputs, including public-safe WFEH-B summary, DRI improvement need, Observatory need, Studio scenario, National Portfolio update, Academy module, Campaign-safe material, protection-gap record, public finance relevance question, donor-readiness question, handoff dependency note, correction record, or archive record;
6. boundary notices, confirming that food and water insecurity records are not aid prioritization, public warning, public authority decision, donor commitment, public finance allocation, procurement approval, consent, deployment authorization, or execution.

Food and water insecurity safeguards ensure that public-good learning does not expose communities already under stress.

### 20.6.8 Public-Safe Humanitarian Reporting

Public-safe humanitarian reporting is the controlled reporting practice through which Nexus communicates humanitarian-sensitive learning, disaster-related learning, conflict-sensitive learning, displacement-related learning, refugee and migrant context, food and water insecurity context, health-sensitive context, community risk, WFEH-B disruption, DRI summaries, Observatory summaries, Studio scenarios, Campaign outputs, National Portfolio updates, donor-readiness questions, public finance relevance questions, and handoff dependencies without exposing people, operations, locations, protected knowledge, legal status, health status, youth identity, or security-sensitive details.

Public-safe humanitarian reporting shall use minimization, aggregation, anonymization, geospatial masking, non-stigmatizing language, uncertainty language, limitation statements, accessibility, translation review, community correction channels, humanitarian sensitivity review, public authority boundary review, and protected knowledge controls. It shall not create warnings, command, aid prioritization, donor commitment, public finance allocation, public authority action, policing use, targeting use, consent, deployment authorization, or execution.

A Public-Safe Humanitarian Reporting Record should identify:

1. reporting object, including Report, public-safe summary, DRI summary, Observatory summary, Studio summary, Campaign material, National Portfolio update, Nexus Universe output, Academy material, Registry record, Marketplace listing, finance-readiness material, donor-readiness material, public finance learning material, or handoff dependency note;
2. humanitarian sensitivity class, including disaster-affected, conflict-affected, displaced persons, refugees and migrants, humanitarian operations, health-sensitive, food insecurity, water insecurity, youth-sensitive, disability-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, geospatial-sensitive, or protected knowledge;
3. transformation controls, including redaction, aggregation, anonymization, pseudonymization, geospatial masking, delayed release, non-stigmatizing language, public-safe substitution, protected knowledge exclusion, public authority boundary language, donor boundary language, public finance boundary language, finance and insurance boundary language, no-targeting language, and correction channel display;
4. review status, including humanitarian sensitivity review, community safeguard review, Indigenous protocol review where applicable, youth safeguard review, disability inclusion review, privacy review, data review, AI-use review, geospatial review, public authority boundary review, finance and insurance boundary review, legal review, public-safe review, and correction review;
5. release class, including public, controlled-public, community-review-only, public authority learning-only, donor-reader-only with restrictions, public finance learning-only with restrictions, secure-room summary, data-room summary, protected knowledge room summary, restricted, sealed, archive-only, or deletion-required;
6. boundary notices, confirming that public-safe humanitarian reporting is not public warning, emergency command, aid prioritization, donor commitment, public finance allocation, insurance score, investment signal, public authority action, policing authorization, targeting authorization, consent, deployment authorization, or execution.

Public-safe humanitarian reporting communicates what can be safely learned while protecting what must not be exposed.

### 20.6.9 No Targeting or Policing Use by Default

No targeting or policing use by default is the mandatory humanitarian sensitivity rule that Nexus records, DRI outputs, Observatory summaries, Studio workflows, Campaign data, Reports, dashboards, maps, National Portfolio objects, Nexus Universe outputs, Registry records, Marketplace listings, Grid inputs, finance-readiness records, donor-readiness records, public finance relevance records, public authority learning records, protected knowledge records, community data, displacement data, refugee or migrant data, humanitarian operations data, health-sensitive data, food or water insecurity data, and handoff dependency notes shall not be used for targeting, policing, surveillance, enforcement, eligibility denial, exclusion, profiling, detention, deportation, coercive control, military targeting, political repression, discriminatory service allocation, or harmful public authority action by default.

Where a lawful public authority or humanitarian actor has a legitimate protective mandate, Nexus materials shall still not be treated as operational targeting or policing tools unless a separate lawful process, safeguard review, data governance review, public authority boundary review, human rights review where applicable, and explicit permission pathway authorize a narrowly defined use outside Nexus. Nexus’s default is protection, learning, public-safe reporting, correction, and non-execution.

A No Targeting or Policing Use Record should identify:

1. covered object, including dataset, map, dashboard, DRI output, Observatory signal, Studio workflow, Report, Campaign record, National Portfolio object, Nexus Universe output, Registry record, Marketplace listing, finance-readiness record, public authority learning record, donor-readiness record, public finance record, safeguard record, or handoff note;
2. prohibited use, including targeting, policing, surveillance, enforcement, immigration enforcement, eligibility denial, discriminatory allocation, profiling, detention, deportation, coercive control, military targeting, public order repression, political misuse, or harm-enabling operational use;
3. sensitive population or context, including disaster-affected people, conflict-affected people, displaced persons, refugees, migrants, youth, persons with disabilities, health-sensitive groups, food-insecure communities, water-insecure communities, Indigenous peoples where applicable, humanitarian operations, protected knowledge custodians, or public authority-sensitive contexts;
4. controls, including access restriction, purpose limitation, data minimization, anonymization, aggregation, geospatial masking, no-AI-training, no-profiling, no automated decision use, public-safe review, humanitarian sensitivity review, legal boundary review, human rights review where applicable, correction pathway, sealing, and archive;
5. incident response, including access revocation, takedown, data restriction, public-safe correction, public authority boundary escalation, protected knowledge incident response, notification where appropriate, public repair where appropriate, sealing, deletion where required, archive, and non-continuation;
6. boundary notices, confirming that Nexus materials are for public-good learning, evidence, safeguards, readiness questions, and lawful handoff awareness only, and are not targeting, policing, surveillance, enforcement, eligibility, detention, deportation, military, coercive, deployment, or execution tools by default.

No targeting or policing use by default is a core humanitarian safeguard. Nexus must not allow the machinery of risk intelligence to become machinery of harm.

The final Humanitarian Sensitivity rule is: humanitarian sensitivity protects disaster-affected people, conflict-affected people, displaced persons, refugees and migrants, humanitarian operations, health-sensitive contexts, food and water insecurity contexts, and public-safe humanitarian reporting under a no-targeting-or-policing-use default. Nexus may learn, summarize, route, correct, and archive humanitarian-sensitive records for public-good purposes; it shall not expose vulnerable people, operational details, protected knowledge, sensitive locations, legal status, health status, or community vulnerability in ways that create targeting, policing, public authority overclaim, donor overclaim, aid prioritization, public finance allocation, consent, deployment authorization, or execution by implication.

## 20.7 Safeguard Boundary Rules

### 20.7.1 Participation Is Not Consent

Participation is not consent is the mandatory safeguard rule that attendance, comment, contribution, signature, pledge, survey response, story sharing, workshop participation, Campaign participation, Academy participation, Studio participation, DRI contribution, Observatory signal contribution, Reports review, public authority learning participation, Nexus Universe participation, Working Group participation, Competence Cell participation, safeguard-room participation, protected knowledge room participation, readiness-room participation, finance-readiness-room participation, donor-reader discussion, insurance-reader discussion, public finance learning discussion, Marketplace feedback, Registry feedback, Grid input, or handoff-awareness discussion shall not be represented as consent, approval, endorsement, authorization, data-use permission, AI-use permission, publication permission, mapping permission, land access permission, facility access permission, deployment authorization, implementation authorization, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, or execution authority.

Participation may create a record of engagement, learning, knowledge contribution, concern, correction, public-safe feedback, accessibility need, safeguard issue, DRI input, Observatory need, Campaign signal, Academy record, or National Portfolio context. It does not create permission beyond the recorded participation purpose. Where consent is legally, ethically, culturally, institutionally, community-required, Indigenous-protocol-required where applicable, data-required, publication-required, AI-use-required, land-access-required, or handoff-required, consent must be obtained through a separate lawful and appropriate pathway.

A Participation-Not-Consent Boundary Record should identify:

1. participation context, including Campaign, community meeting, public-safe story pathway, Academy pathway, Risk Academy pathway, Studio room, DRI pathway, Observatory pathway, Report review, National Portfolio pathway, Nexus Universe room, Working Group, Competence Cell, public authority learning room, safeguard room, protected knowledge room, readiness room, finance-readiness room, donor-reader room, insurance-reader room, public finance learning room, Marketplace or Registry feedback, or handoff-awareness pathway;
2. participant class, including community participant, Indigenous participant where applicable, youth participant, person with disability, civil society actor, humanitarian actor, public authority learner, provider contributor, sponsor-supported participant, capital reader, insurer reader, donor reader, public finance learner, university participant, Working Group participant, Competence Cell participant, or public-interest participant;
3. consent-sensitive matter, including story, quote, image, video, audio, data, protected knowledge, location, map, translation, AI use, publication, public display, Registry display, Marketplace display, public authority routing, finance-readiness routing, donor-readiness routing, insurance-readiness routing, public finance learning routing, handoff, deployment, or implementation;
4. required notice, including participation-not-consent, attendance-not-consent, signature-not-consent, pledge-not-consent, story-not-consent, data-contribution-not-open-permission, public-safe-review-not-publication-permission, and Nexus Universe-participation-not-deployment-authorization;
5. separate pathway required, including community process, Indigenous governance process where applicable, legal consent process, data agreement, ethics review, publication permission, AI-use permission, translation permission, mapping permission, land-access process, public authority process, contract, handoff agreement, or other lawful permission route;
6. correction pathway, including correction of consent overclaim, access restriction, redaction, anonymization, geospatial masking, material withdrawal, recall, public repair, sealing, deletion where required, archive, or non-continuation.

Participation is valuable because it informs Nexus. It is dangerous when converted into permission. Nexus shall preserve that distinction in every record, room, arena, publication, dashboard, listing, and handoff note.

### 20.7.2 Community Display Is Not Endorsement

Community display is not endorsement is the mandatory safeguard rule that the display of a community name, local institution, participant class, story, image, quote, map, Campaign participation count, public-safe summary, National Portfolio object, Nexus Universe material, DRI contribution, Observatory signal, Studio scenario, Report reference, Marketplace listing, Registry record, Grid input, public authority learning record, finance-readiness record, donor-readiness record, public finance relevance record, or handoff dependency note shall not be represented as community endorsement, approval, consent, mandate, authorization, public authority approval, donor priority, procurement priority, financeability, insurability, deployment authorization, or execution.

Community display may be used only where the relevant display, attribution, privacy, dignity, public-safe, accessibility, youth, protected knowledge, Indigenous protocol where applicable, geospatial, humanitarian, media-safe, and correction controls have been satisfied. Display must not convert visibility into legitimacy by implication.

A Community Display Boundary Record should identify:

1. display object, including Report, Campaign page, dashboard, map, public-safe story, image, video, quote, Studio workflow, DRI output, Observatory summary, National Portfolio record, Nexus Universe output, Registry record, Marketplace listing, Grid input, public authority learning material, finance-readiness material, donor-readiness material, public finance learning material, media-safe package, or handoff note;
2. community context, including community, place, local institution, civil society group, youth group, accessibility group, humanitarian context, Indigenous community or institution where applicable, affected stakeholder group, or public-interest pathway;
3. endorsement risk, including implied community approval, implied community mandate, implied Indigenous consent where applicable, implied donor priority, implied public authority support, implied procurement preference, implied deployment support, implied project approval, media overclaim, sponsor overclaim, provider overclaim, or public legitimacy overclaim;
4. display controls, including approved attribution, anonymity, pseudonymity, collective attribution, non-attribution, image permission, quote permission, location masking, public-safe transformation, accessibility review, language review, protected knowledge review, community review where appropriate, Indigenous protocol review where applicable, and correction channel display;
5. required notice, including display-not-endorsement, community-name-not-approval, public-safe-story-not-consent, map-not-permission, Campaign-visibility-not-mandate, National Portfolio-inclusion-not-official-plan, and Nexus Universe-display-not-deployment-authorization;
6. correction pathway, including removal, redaction, attribution correction, quote correction, image withdrawal, map masking, public-safe correction, media-safe correction, public repair, Registry correction, Marketplace correction, Report correction, Campaign correction, archive, or non-continuation.

Community display must be treated as a controlled act. Nexus shall not use community visibility as a substitute for legitimacy, consent, or authority.

### 20.7.3 Protected Knowledge Availability Is Not Permission

Protected knowledge availability is not permission is the mandatory safeguard rule that the presence, access, upload, contribution, observation, recording, discussion, summary, metadata record, secure-room review, data-room review, protected knowledge room review, Report source, DRI input, Observatory signal, Studio input, National Portfolio inclusion, Nexus Universe discussion, Registry reference, Marketplace candidate, finance-readiness reference, donor-readiness reference, public finance learning reference, public authority learning reference, or handoff dependency reference involving protected knowledge shall not be treated as permission to use, reuse, publish, translate, map, quote, cite, summarize, model, train AI, transfer, commercialize, route, hand off, deploy, or execute.

Protected knowledge remains protected even when Nexus can see it. Availability may reflect trust, error, limited access, restricted review, temporary sharing, public-safe preparation, custodian-controlled disclosure, community participation, Indigenous protocol-sensitive process where applicable, or secure-room handling. It shall not be converted into an open license or broad permission.

A Protected Knowledge Availability Boundary Record should identify:

1. available protected material, including story, data, image, video, audio, transcript, map, location, cultural knowledge, ecological knowledge, sacred knowledge, youth-sensitive information, health-sensitive information, humanitarian-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive information, finance-sensitive information, donor-sensitive information, or handoff-sensitive information;
2. availability pathway, including upload, meeting, interview, Campaign contribution, DRI contribution, Observatory signal, Studio input, Report source, National Portfolio object, secure room, data room, protected knowledge room, public authority learning room, Nexus Universe room, Registry metadata, Marketplace review, or handoff dependency pathway;
3. permitted use status, including internal review only, public-safe summary only, metadata-only record, community-review-only, Indigenous-governance-review-only where applicable, protected knowledge room only, secure-room only, data-room only, archive-only, sealed, deletion-required, or separately authorized use;
4. prohibited uses, including public release, translation, mapping, quotation, AI training, embedding, agentic use, open data release, Marketplace display, public Registry display, donor display, finance-readiness display, public authority routing, handoff, commercialization, deployment, and execution unless separately authorized;
5. required controls, including access restriction, publication restriction, translation restriction, AI-use restriction, geospatial masking, metadata-only treatment, sealing, archive, protected knowledge incident response, and public-safe substitution where appropriate;
6. boundary notices, confirming that protected knowledge availability is not permission, license, consent, public authority approval, financeability, donor approval, handoff authorization, deployment authorization, or execution.

The default rule is restriction until permission is clear. Nexus must not reward trust with exposure.

### 20.7.4 Public-Safe Summary Is Not Full Disclosure

Public-safe summary is not full disclosure is the mandatory safeguard rule that a public-safe summary, media-safe summary, Campaign-safe story, public authority learning summary, donor-reader summary, finance-readiness summary, insurance-reader summary, public finance learning summary, Marketplace description, Registry display, DRI summary, Observatory summary, Studio summary, National Portfolio summary, Nexus Universe summary, Report summary, or handoff-awareness summary shall not be represented as full disclosure of the underlying evidence, raw data, protected knowledge, community context, Indigenous protocol-sensitive knowledge where applicable, health-sensitive information, youth-sensitive information, geospatial-sensitive information, cyber-sensitive information, infrastructure-sensitive information, public authority-sensitive information, finance-sensitive information, donor-sensitive information, insurance-sensitive information, or handoff-sensitive material.

A public-safe summary is a controlled communication product. It may intentionally omit, aggregate, mask, generalize, anonymize, restrict, or substitute details to avoid harm. Its incompleteness is a safeguard, not a defect, provided that limitations and release class are accurately recorded.

A Public-Safe Summary Boundary Record should identify:

1. summary object, including Report summary, DRI summary, Observatory summary, Studio summary, Campaign story, National Portfolio summary, Nexus Universe summary, Marketplace listing, Registry display, public authority learning summary, finance-readiness summary, donor-readiness summary, public finance learning summary, media-safe material, or handoff-awareness summary;
2. source material class, including raw data, protected knowledge, community data, Indigenous protocol-sensitive material where applicable, geospatial data, health-sensitive data, youth data, humanitarian-sensitive data, cyber-sensitive data, infrastructure-sensitive data, public authority-sensitive data, finance-sensitive data, insurance-sensitive data, donor-sensitive data, or handoff-sensitive data;
3. transformation method, including redaction, aggregation, anonymization, pseudonymization, geospatial masking, public-safe substitution, generalization, delayed release, limitation statement, uncertainty language, non-stigmatizing language, metadata-only reference, or protected-source-withheld notice;
4. disclosure limits, including not raw data, not complete evidence record, not full method disclosure, not public authority record, not consent record, not complete data room, not secure room equivalent, not protected knowledge release, not handoff package, and not legal disclosure unless separately recorded;
5. review and correction, including public-safe review, safeguard review, community review where appropriate, Indigenous protocol review where applicable, data review, AI review, geospatial review, public authority boundary review, finance and insurance boundary review, handoff review, correction review, archive, and non-continuation;
6. boundary notices, confirming that public-safe summary release is not full disclosure, open data release, publication permission for the source, AI-use permission, public authority approval, financeability, insurability, donor commitment, public finance allocation, consent, handoff authorization, deployment authorization, or execution.

Public-safe summaries help Nexus communicate safely. They do not erase the need for controlled access, independent review, or separate lawful processes.

### 20.7.5 Accessibility Format Is Not New License

Accessibility format is not new license is the mandatory safeguard rule that converting Nexus material into an accessible format, including alt text, captions, transcripts, plain-language summaries, screen-reader-compatible files, audio description, accessible PDFs, HTML versions, large-print versions, easy-read versions, low-bandwidth versions, mobile-first versions, offline packages, translated accessibility materials, tactile diagrams, or assisted facilitation materials, shall not create a new license, new publication permission, new reuse permission, new AI-use permission, new data-use permission, new translation permission, new mapping permission, new public authority status, new finance-readiness status, new donor-readiness status, new handoff permission, deployment authorization, or execution authority.

Accessibility formats inherit the same access class, sensitivity class, data-use label, AI-use label, public-safe status, protected knowledge restrictions, attribution controls, correction pathway, archive rule, boundary notices, and use limitations as the source material unless a separate review lawfully assigns a more restrictive status. Accessibility must expand access for intended users without expanding rights beyond the recorded purpose.

An Accessibility Format Boundary Record should identify:

1. source material, including Report, DRI output, Observatory summary, Studio workflow, Campaign material, Academy object, Registry record, Marketplace listing, National Portfolio object, Nexus Universe output, finance-readiness material, public authority learning material, safeguard record, or handoff dependency note;
2. accessibility format, including alt text, captions, transcript, plain-language summary, screen-reader version, audio description, accessible PDF, HTML version, large-print version, easy-read version, low-bandwidth version, mobile version, offline package, translated accessibility material, or assisted facilitation material;
3. inherited controls, including access class, sensitivity class, license class, data-use label, AI-use label, publication status, protected knowledge restrictions, geospatial masking, attribution controls, release class, correction pathway, archive rule, and non-current notices;
4. use limitations, including no new publication, no new quotation, no new reuse, no new translation reuse, no AI training, no commercial reuse, no Marketplace expansion, no public Registry expansion, no public authority reliance, no finance or insurance reliance, no donor reliance, no handoff reliance, no deployment, and no execution;
5. review and correction, including accessibility review, public-safe review, protected knowledge review, community review where appropriate, Indigenous protocol review where applicable, legal boundary review, correction, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that accessibility improves usability within the recorded rights and does not create a new license, permission, authority, approval, consent, deployment authorization, or execution.

Accessibility is an inclusion obligation. It is not a rights-expansion mechanism.

### 20.7.6 Humanitarian Context Is Not Operational Command

Humanitarian context is not operational command is the mandatory safeguard rule that humanitarian-sensitive Nexus materials, including disaster-affected context, conflict-affected context, displacement context, refugee and migrant context, health-sensitive context, food and water insecurity context, humanitarian operations context, public-safe humanitarian reporting, DRI outputs, Observatory summaries, Studio scenarios, Reports, dashboards, Campaign materials, National Portfolio records, Nexus Universe outputs, donor-readiness records, public finance relevance records, public authority learning records, Marketplace listings, Registry records, Grid inputs, and handoff dependency notes shall not be represented as operational command, humanitarian coordination instruction, emergency directive, public warning, public authority order, aid allocation, targeting authorization, policing authorization, logistics instruction, deployment instruction, procurement instruction, donor commitment, public finance allocation, consent, or execution.

Nexus may learn from humanitarian context, summarize safely, identify protection gaps, identify risk-layering questions, create public-safe Reports, support Academy and Risk Academy learning, inform National Portfolios, route DRI and Observatory needs, support donor-readiness questions, support public finance relevance questions, and prepare lawful handoff dependency notes. It shall not operate humanitarian response.

A Humanitarian Non-Command Boundary Record should identify:

1. humanitarian context, including disaster, conflict, displacement, refugee or migrant context, food insecurity, water insecurity, health-sensitive setting, humanitarian operation, degraded-mode condition, infrastructure disruption, WFEH-B crisis, public authority learning setting, or Nexus Universe humanitarian session;
2. material covered, including Report, dashboard, DRI output, Observatory summary, Studio workflow, Campaign material, National Portfolio object, Marketplace listing, Registry record, Grid input, donor-readiness question, public finance relevance record, public authority learning note, or handoff dependency note;
3. command-risk issue, including warning implication, operational directive implication, aid allocation implication, logistics instruction implication, public authority order implication, targeting risk, policing risk, donor priority overclaim, public finance allocation overclaim, procurement implication, deployment implication, or execution implication;
4. required controls, including no-warning language, no-command language, no-targeting language, no-policing language, no-aid-allocation language, no-donor-commitment language, no-public-finance-allocation language, geospatial masking, humanitarian sensitivity review, public-safe transformation, access restriction, and correction pathway;
5. permitted outputs, including public-safe humanitarian summary, DRI improvement need, Observatory need, Studio scenario, Academy module, Risk Academy module, Campaign-safe material, protection-gap record, risk-layering record, donor-readiness question, public finance relevance question, handoff dependency note, correction record, and archive record;
6. boundary notices, confirming that humanitarian context is not operational command, public warning, public authority action, aid allocation, targeting authorization, policing authorization, donor commitment, public finance allocation, consent, deployment authorization, or execution.

Humanitarian sensitivity requires discipline precisely because humanitarian urgency can make overclaim seem useful. Nexus shall not allow urgency to become unauthorized command.

### 20.7.7 Safeguard Review Is Not Public Authority Approval

Safeguard review is not public authority approval is the mandatory safeguard rule that community safeguard review, Indigenous protocol review where applicable, protected knowledge review, youth safeguard review, disability inclusion review, humanitarian sensitivity review, public-safe review, privacy review, geospatial review, health-sensitive review, accessibility review, data-use review, AI-use review, media-safe review, consent-boundary review, public authority boundary review, finance and insurance boundary review, donor boundary review, public finance boundary review, or handoff review shall not be represented as public authority approval, regulatory approval, certification, procurement approval, financeability, insurability, donor approval, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.

Safeguard review determines whether a Nexus object may proceed within Nexus safeguard conditions. It does not decide whether a public authority, community, Indigenous governance body, donor, insurer, capital reader, public finance actor, procurement body, operator, host, National Consortium Company, Project SPV, provider, or other lawful actor may act outside Nexus.

A Safeguard Review Boundary Record should identify:

1. review type, including community safeguard review, Indigenous protocol review where applicable, protected knowledge review, youth safeguard review, disability inclusion review, humanitarian sensitivity review, public-safe review, privacy review, geospatial review, health-sensitive review, accessibility review, data-use review, AI-use review, media-safe review, consent-boundary review, public authority boundary review, finance and insurance boundary review, donor boundary review, public finance boundary review, or handoff review;
2. object reviewed, including Report, Campaign material, DRI output, Observatory summary, Studio workflow, National Portfolio object, Nexus Universe output, Academy material, Foundry build, Registry record, Marketplace listing, Grid input, finance-readiness material, public authority learning record, donor-readiness record, public finance record, safeguard record, or handoff dependency note;
3. review outcome within Nexus, including proceed within scope, proceed with conditions, public-safe transform, restrict, redact, mask, require accessibility remediation, require consent pathway, require Indigenous governance review where applicable, require protected knowledge room, require correction, withdraw, recall, seal, delete where required, archive, or non-continuation;
4. approval boundaries, including review-not-public-authority-approval, review-not-community-consent, review-not-Indigenous-consent, review-not-certification, review-not-procurement-approval, review-not-financeability, review-not-insurability, review-not-donor-commitment, review-not-public-finance-allocation, review-not-deployment-authorization, and review-not-execution;
5. downstream responsibility, including any separate actor must perform its own legal, public authority, procurement, finance, insurance, donor, public finance, technical, safeguard, consent, deployment, maintenance, liability, and execution review before acting;
6. correction pathway, including correction of safeguard overclaim, approval overclaim, consent overclaim, public authority overclaim, finance or insurance overclaim, donor overclaim, public finance overclaim, deployment overclaim, public-safe correction, withdrawal, recall, archive, or non-continuation.

Safeguard review is a condition of Nexus legitimacy. It is not a substitute for public authority action, community consent, Indigenous consent, regulated approval, or downstream execution responsibility.

The final Safeguard Boundary Rules rule is: participation is not consent; community display is not endorsement; protected knowledge availability is not permission; a public-safe summary is not full disclosure; an accessibility format is not a new license; humanitarian context is not operational command; and safeguard review is not public authority approval. These rules protect Nexus from converting participation, visibility, access, summaries, accessibility, humanitarian urgency, or safeguard review into consent, endorsement, permission, authority, approval, deployment authorization, or execution by implication.

<br>


---

# 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/standardization/nexus-ecosystem/ii.-structure/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.