# XX. LOCALIZATION

## 20.1 National Digital Public Goods Doctrine

### 20.1.1 National localization as public-good requirement.

National localization under the Distributed Digital Public Goods Framework shall be treated as a public-good requirement for digital objects intended to support country-level capability formation, National Portfolios, National Nodes, National Working Groups, Nexus Competence Cells, Nexus Academy pathways, Risk Academy pathways, DRI workflows, Observatory workflows, Nexus Studio workflows, Nexus Universe preparation, Nexus Marketplace discovery, Nexus Registry status truth, Nexus Reports, Nexus Campaigns, and lawful handoff context. Localization shall mean more than translation. It shall include adaptation of terminology, data context, legal context, public authority context, accessibility formats, digital access realities, cultural context, community safeguards, protected knowledge controls, low-bandwidth formats, offline use, national repository routing, national data sovereignty, and national correction pathways.

National localization shall preserve the integrity of the original object while making the object usable, understandable, lawful, accessible, safe, and relevant within a national context. Localization shall not permit semantic drift, public authority overclaim, finance overclaim, procurement overclaim, certification overclaim, consent overclaim, deployment overclaim, or execution overclaim. A localized object shall remain traceable to its source object, version, steward, license, public-safe status, data-use label, AI-use label, access class, Registry status, Marketplace status, support class, correction pathway, and archive rule.

### 20.1.2 National ownership before local delivery.

DDPGF shall preserve the Nexus rule of **national ownership before local delivery**. Digital public-good objects used in national contexts shall be routed through appropriate national pathways, including National Nodes, National Nexus Consortiums, National Councils, National Working Groups, Nexus Competence Cells, public authority learning interfaces, community safeguard processes, national repositories, national language pathways, and lawful handoff recipients where applicable. External actors, global actors, regional actors, sponsors, providers, capital readers, insurers, donors, universities, or platform contributors shall not bypass national ownership by directly converting digital objects into local implementation, public claims, procurement positioning, finance positioning, public authority meaning, or community deployment.

National ownership shall not mean national gatekeeping abuse, exclusion, capture, political control, provider preference, sponsor control, or public authority substitution. It shall mean that country-level use, localization, data handling, public-safe reporting, National Portfolio integration, Nexus Universe presentation, and lawful handoff are shaped through nationally grounded, role-separated, recorded, correctionable, and public-good disciplined pathways.

### 20.1.3 National repositories and mirrors.

National repositories and mirrors may preserve nationally relevant software objects, data objects, metadata objects, model objects, ontology objects, schema objects, API objects, dashboards, learning objects, public-safe reports, DRI objects, Observatory objects, Studio workflows, Marketplace records, Registry records, National Portfolio objects, Campaign materials, accessibility versions, translations, and lawful handoff context. National repositories and mirrors shall preserve source attribution, version lineage, license terms, data-use labels, AI-use labels, public-safe status, sensitivity class, access class, support status, correction records, withdrawal records, recall records, archive labels, and no-conversion notices.

A national repository or mirror shall not override the original Registry status truth unless a new national object record is created with clear versioning and localization scope. Mirrored availability shall not imply national endorsement, public authority approval, procurement status, financeability, insurability, deployment authorization, community consent, Indigenous consent, or execution authority.

### 20.1.4 National Portfolio objects.

National Portfolio objects shall be the country-level digital public-good records that organize national needs, priorities, risk contexts, capability gaps, data assets, software assets, dashboards, learning pathways, Campaigns, DRI contributions, Observatory records, Studio workflows, Nexus Universe outputs, public authority learning records, safeguard records, readiness questions, Grid inputs, TRL notes, Marketplace listings, Registry records, Reports, and handoff dependency packages. They shall convert national signals into structured, traceable, public-good digital memory without converting that memory into authority by implication.

National Portfolio objects shall be nationally grounded, public-safe, versioned, reviewable, accessible, and correctionable. They shall not be country rankings, public authority decisions, procurement plans, investment memoranda, insurance assessments, public finance allocations, development plans by implication, emergency commands, or implementation authorizations unless separately issued by competent actors through lawful processes.

### 20.1.5 National language access.

DDPGF shall support national language access so that digital public-good objects can be understood by national stakeholders, public authority learning participants, communities, learners, contributors, universities, industry actors, capital readers, insurers, donors, civil society, media, youth, and lawful handoff recipients. National language access may include translation, plain-language summaries, glossaries, controlled vocabulary mappings, multilingual metadata, localized learning objects, public-safe summaries, audio or video formats, captions, transcripts, low-literacy formats, and community-facing explanations.

National language access shall preserve meaning, boundary notices, public-safe status, license terms, correction pathways, no-warning language, no-rating language, no-certification language, no-procurement language, no-finance language, no-consent language, no-deployment language, and no-execution language. Translation shall never be used to soften, omit, or obscure legal, safety, public-good, or no-conversion controls.

### 20.1.6 National data sovereignty.

National data sovereignty shall require that data objects, metadata objects, DRI datasets, Observatory datasets, National Portfolio datasets, learning records, community-sensitive data, Indigenous protocol-sensitive data where applicable, public authority-sensitive data, protected knowledge, health-sensitive data, youth data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, and handoff-recipient-only data are handled with regard to national law, public authority sensitivities, community safeguards, protected knowledge controls, cross-border restrictions, data localization requirements, and lawful access concerns. National data sovereignty may require national repositories, sovereign compute, compute-to-data workflows, secure rooms, data rooms, restricted access, public-safe transformation, metadata-only exposure, or archive-only status.

National data sovereignty shall not mean unrestricted national access, public authority ownership by implication, public authority approval, open data status, AI training permission, cross-border transfer permission, handoff permission, or deployment authorization. It shall mean recorded jurisdiction-sensitive governance.

### 20.1.7 National public authority boundaries.

DDPGF shall distinguish national public authority learning from national public authority action. Public authorities may participate in learning rooms, Studio workflows, National Portfolio discussions, DRI interpretation, Observatory review, Reports review, Nexus Universe arenas, readiness rooms, data rooms, secure rooms, and handoff-context discussions without creating official approval, policy adoption, regulatory decision, permit, license, public warning, public finance allocation, procurement decision, emergency command, or governmental endorsement by implication.

Any official national public authority action must occur outside default DDPGF status through competent public authority processes. DDPGF records may support learning and context, but they shall not replace national legal mandates, regulatory processes, procurement processes, emergency management systems, public finance processes, or official statistical systems.

### 20.1.8 National handoff without bypass.

National handoff under DDPGF shall transfer context, evidence, dependencies, limitations, public-safe status, data-use conditions, AI-use conditions, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive rules to lawful recipients without bypassing national ownership. National Consortium Companies, Project SPVs, public authorities, providers, operators, contractors, universities, labs, communities where appropriate, donors, insurers, capital readers, and other competent lawful actors may receive handoff context only within recorded scope.

National handoff shall not create implementation authority, procurement approval, finance approval, insurance approval, public authority approval, provider selection, community consent, Indigenous consent, deployment authorization, operational command, or execution authority. Handoff shall be routed through recorded national pathways and shall remain correctionable.

## 20.2 Localization Classes

### 20.2.1 Language translation.

Language translation shall convert DDPGF objects into national, regional, local, Indigenous, minority, or working languages where appropriate, while preserving source meaning, version labels, license terms, attribution, public-safe status, boundary notices, correction pathway, and archive rules. Translation may apply to Reports, learning objects, public-safe summaries, dashboards, Marketplace listings, Registry records, Studio workflows, API documentation, software documentation, data dictionaries, model cards, system cards, benchmark cards, Campaign materials, handoff literacy objects, and National Portfolio objects.

Each translation shall identify source version, translator or steward, review status, localization notes, semantic deviations where any, public-safe review status, accessibility status, and correction pathway. Translation shall not constitute substantive approval, legal equivalence, public authority adoption, certification, endorsement, or new license.

### 20.2.2 Legal-context localization.

Legal-context localization shall adapt explanatory materials, boundary notices, data-use labels, access rules, privacy statements, handoff notes, procurement-neutrality notices, finance-readiness notices, public authority learning notices, license explanations, and risk disclaimers to the legal vocabulary and legal sensitivities of a national or regional context. It shall identify jurisdictional dependencies, legal review needs, cross-border transfer constraints, public authority boundaries, community consent boundaries, Indigenous protocol considerations where applicable, and regulated-perimeter issues.

Legal-context localization shall not constitute legal advice, legal compliance determination, official legal interpretation, public authority approval, procurement approval, finance approval, or deployment authorization. Competent legal review remains necessary for reliance.

### 20.2.3 Public authority terminology localization.

Public authority terminology localization shall align DDPGF language with the terminology used by ministries, agencies, regulators, municipalities, emergency management bodies, public finance institutions, public procurement bodies, standards bodies, statistical offices, meteorological or hydrological services, public health authorities, infrastructure authorities, and other public institutions in a national context. Such localization shall support learning, clarity, and respectful interface.

Terminology localization shall not convert DDPGF objects into official public authority documents, public authority decisions, regulatory classifications, official warnings, public finance decisions, procurement terms, or government-endorsed materials. Any official terminology adoption must be separately recorded by competent authority.

### 20.2.4 Technical localization.

Technical localization shall adapt software, APIs, schemas, dashboards, data pipelines, models, notebooks, repositories, Studio workflows, digital twins, simulations, DRI workflows, Observatory workflows, Marketplace objects, Registry records, and National Portfolio objects to local infrastructure, language, units, formats, standards interfaces, telecom conditions, cloud or sovereign compute environments, low-bandwidth realities, security needs, and national data systems. Technical localization shall preserve source lineage, versioning, interoperability, license compliance, public-safe controls, data-use labels, AI-use labels, and correction pathways.

Technical localization shall not create production approval, security certification, procurement status, provider validation, deployment authorization, or execution authority. Localized technical objects require their own review and Registry status.

### 20.2.5 Data localization.

Data localization shall adapt data objects and data workflows to national data laws, data sovereignty expectations, data residency needs, cross-border transfer limits, data standards, statistical systems, public authority sensitivities, community safeguards, Indigenous protocol-sensitive controls where applicable, language, metadata conventions, geospatial sensitivity, and public-safe reporting needs. It may require national repositories, national metadata, secure rooms, compute-to-data, data rooms, controlled access, aggregation, masking, or metadata-only release.

Data localization shall not make data open, unrestricted, reusable, transferable, AI-training-permitted, public-authority-approved, handoff-permitted, or deployment-ready unless separately recorded. Data remains governed by rights, sensitivity, license, public-safe status, and correction rules.

### 20.2.6 Cultural localization.

Cultural localization shall adapt public-safe summaries, learning objects, Campaign materials, community guides, accessibility formats, visual examples, case studies, terminology, imagery, public narratives, and participation pathways to local cultural context without misappropriation, stereotyping, tokenization, protected knowledge exposure, or consent overclaim. Cultural localization shall be non-extractive, respectful, reviewable, and correctionable.

Cultural localization shall not create community endorsement, social license, Indigenous consent, permission to disclose protected knowledge, public authority approval, or implementation authority. Community and Indigenous contexts require separate safeguards and permission processes where applicable.

### 20.2.7 Accessibility localization.

Accessibility localization shall adapt DDPGF objects for persons with disabilities, different literacy levels, low-bandwidth contexts, mobile-first access, assistive technologies, language needs, cognitive accessibility, visual accessibility, hearing accessibility, motor accessibility, and offline access. Accessibility localization may include screen-reader compatibility, alt text, captions, transcripts, plain-language summaries, tagged documents, structured headings, accessible tables, keyboard navigation, low-resolution alternatives, audio formats, and offline packages.

Accessibility localization shall preserve license terms, source version, public-safe status, boundary notices, and correction pathways. Accessibility formats shall not create a new license, new approval, or different authority status unless separately recorded.

### 20.2.8 Low-bandwidth localization.

Low-bandwidth localization shall convert suitable objects into lightweight, compressed, text-first, mobile-accessible, static, low-media, or offline-compatible formats for national contexts with connectivity limitations, disaster-affected areas, rural communities, field teams, learners, public authority learning participants, and community users. It may include reduced dashboards, static maps, plain-language PDFs, text summaries, low-data learning modules, and cached public-safe guides.

Low-bandwidth localization shall not remove material caveats, uncertainty labels, public-safe notices, license terms, correction notices, no-warning language, no-rating language, no-certification language, no-procurement language, no-finance language, no-consent language, no-deployment language, or no-execution language.

### 20.2.9 Offline localization.

Offline localization shall prepare objects for use without continuous connectivity, including learning packs, public-safe reports, checklists, data dictionaries, schemas, public-safe maps, community guides, National Portfolio summaries, Campaign materials, and correction notices. Offline objects shall include version identifiers, date of export, expiry or review date where appropriate, update instructions, correction contact, license terms, and boundary notices.

Offline localization shall not authorize operational command, emergency warning, public authority action, deployment, procurement, finance, insurance, or execution. Offline materials must be treated as stale if superseded, withdrawn, recalled, or archived.

### 20.2.10 Community-safe localization.

Community-safe localization shall adapt materials for communities in a manner that protects privacy, dignity, agency, culture, language, safety, local context, protected knowledge, and non-extractive participation. It shall consider community-facing correction, sensitive location controls, youth safeguards, accessibility, humanitarian sensitivity, trauma-aware language, Indigenous protocols where applicable, and local risk communication practices.

Community-safe localization shall not imply community consent, Indigenous consent, endorsement, permission to implement, permission to publish protected knowledge, or permission to use community data beyond recorded scope.

## 20.3 Accessibility Requirements

### 20.3.1 Screen-reader compatibility.

DDPGF objects intended for public, learner, contributor, community, public authority learning, or Marketplace use shall be prepared for screen-reader compatibility where feasible and appropriate. This includes structured headings, meaningful link text, readable tables, tagged documents, accessible forms, semantic markup, non-image text alternatives, and navigation that does not depend solely on visual layout.

Screen-reader compatibility shall be treated as a public-good quality requirement, not a decorative enhancement. Where compatibility is incomplete, limitations shall be recorded and corrected.

### 20.3.2 Alt text.

Images, diagrams, charts, maps, dashboards, icons, screenshots, workflow visuals, and visual atlas objects shall include alt text or equivalent descriptions where public-safe and feasible. Alt text shall convey meaning without exposing sensitive geospatial details, protected knowledge, cyber-sensitive information, personal data, or unsafe operational detail. For complex technical visuals, longer descriptions or linked accessible summaries may be required.

Alt text shall preserve public-safe boundaries and shall not introduce new claims, warnings, ratings, approvals, or instructions not present in the source object.

### 20.3.3 Captions.

Audio and video objects, webinars, training modules, Nexus Universe recordings, Studio demonstrations, Campaign videos, Academy materials, Risk Academy materials, public authority learning materials, and public-safe explanatory media shall include captions or transcripts where feasible. Captions shall be accurate, accessible, time-aligned where appropriate, and translated where national language access requires it.

Captions shall preserve boundary notices and shall not omit no-conversion language where the spoken content includes authority-sensitive matters.

### 20.3.4 Plain-language summaries.

Plain-language summaries shall be provided where DDPGF objects are complex, technical, legal, scientific, data-heavy, AI-related, risk-related, public authority-sensitive, finance-readiness-related, or community-facing. Plain-language summaries shall explain purpose, scope, limitations, uncertainty, public-safe status, access conditions, correction pathway, and boundary rules in accessible language without oversimplifying or overclaiming.

Plain-language summaries shall not replace the underlying technical or legal record and shall not create approval, warning, certification, procurement, finance, consent, deployment, or execution meaning.

### 20.3.5 Low-bandwidth formats.

DDPGF shall support low-bandwidth formats for appropriate objects, including compressed documents, text-first versions, static pages, reduced media, low-resolution public-safe images, lightweight dashboards, offline learning packs, and mobile-accessible versions. Low-bandwidth formats shall retain essential metadata, version, source, license, public-safe status, correction pathway, and boundary notices.

Low-bandwidth formats shall not omit material risk, data, AI, privacy, security, safeguard, or no-conversion information.

### 20.3.6 Mobile-first access.

Mobile-first access shall be considered for public-facing, learner-facing, contributor-facing, community-facing, Campaign-facing, and Nexus Universe-facing objects. Mobile-first design shall support readable layouts, low-data operation, accessible navigation, multilingual display, offline caching where appropriate, correction notices, and safe display of public-safe content.

Mobile access shall not bypass authentication, access class, data-use restrictions, AI-use restrictions, secure-room requirements, data-room requirements, or protected knowledge controls.

### 20.3.7 Offline packages.

Offline packages shall be prepared for appropriate learning, public-safe reporting, community-facing, National Portfolio, public authority learning, and field-context materials. Offline packages shall include version date, update instructions, correction pathway, license, attribution, public-safe notices, no-warning notices, no-rating notices, no-certification notices, no-procurement notices, no-finance notices, no-consent notices, no-deployment notices, and no-execution notices where applicable.

Offline packages shall not contain sensitive data, protected knowledge, precise sensitive geospatial details, cyber-sensitive content, restricted models, personal data, or secure-room-only materials unless specifically designed as controlled offline packages with access controls.

### 20.3.8 Disability inclusion review.

Disability inclusion review shall assess whether DDPGF objects, workflows, learning materials, dashboards, Studio environments, Reports, Marketplace listings, Registry records, Campaign materials, Nexus Universe materials, and handoff literacy objects are usable by persons with disabilities and do not create avoidable exclusion. Review may include visual, auditory, motor, cognitive, neurodiversity, language, device, and connectivity considerations.

Disability inclusion review shall be recorded, correctionable, and treated as part of quality. It shall not be treated as optional where public-good access is a core purpose.

### 20.3.9 Multilingual metadata.

DDPGF shall support multilingual metadata for national and multilingual contexts, including object title, description, keywords, object class, steward, language, license, access class, public-safe status, data-use label, AI-use label, support class, correction pathway, boundary notices, and localization notes. Multilingual metadata shall enable discovery through Marketplace, status truth through Registry, searchability through repositories, and accessibility through national language access.

Multilingual metadata shall not create translation equivalence, legal equivalence, public authority adoption, endorsement, or substantive approval. Each language version shall remain versioned and correctable.

### 20.3.10 Accessibility correction.

Accessibility correction shall address inaccessible formats, missing alt text, missing captions, unreadable tables, inaccessible dashboards, incompatible screen-reader structure, missing plain-language summaries, inaccessible mobile layouts, missing translations, low-bandwidth barriers, cognitive accessibility barriers, or disability inclusion failures. Corrections shall propagate to Reports, Marketplace listings, Registry records, repositories, Academy materials, Campaign materials, Studio workflows, Nexus Universe materials, and handoff packages where affected.

Accessibility correction shall be treated as part of public-good trust and shall not require proof of harm before action is taken where barriers are evident.

## 20.4 National Portfolio Object Classes

### 20.4.1 National data objects.

National data objects shall include nationally relevant datasets, metadata records, data dictionaries, codebooks, schemas, DRI datasets, Observatory datasets, National Portfolio datasets, public-safe data, controlled data, data-room objects, compute-to-data objects, and metadata-only records. National data objects shall identify source, jurisdiction, data-use label, AI-use label, sensitivity class, rights basis, access class, public-safe status, localization status, correction pathway, and archive rule.

National data objects shall not create open data rights, AI training permission, public authority record status, cross-border transfer permission, handoff permission, or deployment authorization by default.

### 20.4.2 National software objects.

National software objects shall include localized repositories, national dashboards, national APIs, national connectors, National Node tools, national data pipelines, localized learning tools, public-good software packages, Studio components, Observatory components, DRI tools, and National Portfolio workflow tools. National software objects shall preserve source lineage, license, dependencies, support status, security status, localization notes, public-safe status, and correction pathway.

National software objects shall not create warranty, procurement recommendation, provider validation, security certification, deployment authorization, or execution authority.

### 20.4.3 National dashboard objects.

National dashboard objects shall include public-safe National Portfolio dashboards, DRI dashboards, Observatory dashboards, Campaign dashboards, Academy dashboards, Studio dashboards, Grid dashboards, Marketplace dashboards, Registry dashboards, and handoff dependency dashboards. They shall display source notes, update cadence, confidence and uncertainty labels where applicable, sensitivity controls, no-warning notices, no-rating notices, no-official-map notices, correction notices, and public-safe status.

National dashboard objects shall not be public authority decisions, official maps, warnings, rankings, ratings, insurance scores, investment signals, procurement tools, or operational command surfaces.

### 20.4.4 National DRI objects.

National DRI objects shall include national DRI indicators, indicator definitions, confidence labels, uncertainty labels, risk-intelligence summaries, hotspot records, cascade records, multi-hazard records, national contribution records, public-safe DRI summaries, DRI dashboards, correction records, and archive records. National DRI objects shall be aligned with GRIx, DICE, Observatory, Reports, Studio, Marketplace, Registry, Grid, TRL, Nexus Universe, and National Portfolio pathways.

National DRI objects shall not be official warnings, public authority ratings, insurance scores, country rankings, procurement signals, finance signals, or public authority decisions.

### 20.4.5 National Campaign objects.

National Campaign objects shall include Campaign pages, pledges, signatures, volunteer records, support records, public-safe stories, Campaign dashboards, Campaign reports, Campaign DICE contributions, Campaign DRI contributions, Working Group formation records, Competence Cell formation records, Nexus Universe routing records, correction records, and archive records. They shall be localized to national language, public-safe context, legal context, community context, and accessibility needs.

National Campaign objects shall not create mandates, votes, public authority approval, donor commitments, procurement status, financeability, community consent, Indigenous consent, employment, or execution authority.

### 20.4.6 National Academy objects.

National Academy objects shall include localized courses, modules, units, lessons, labs, scenarios, simulations, Studio exercises, WILP objects, micro-credentials, badges, instructor packs, plain-language summaries, national learning pathways, Risk Academy materials, public authority learning materials, and handoff literacy objects. They shall preserve competency mapping, source lineage, accessibility, translation versioning, credential boundaries, and correction pathways.

National Academy objects shall not create professional licenses, employment guarantees, public authority credentials, procurement qualifications, deployment authorization, or execution authority by default.

### 20.4.7 National Reports objects.

National Reports objects shall include National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF Reports, DRI Reports, DICE Reports, GRIx Reports, Observatory Reports, Foundry Reports, Campaign Reports, Academy Reports, Labs Reports, Risk Agency Reports, Nexus Universe Reports, Grid and TRL Reports, handoff context notes, correction reports, and archive reports. National Reports objects shall be public-safe, versioned, cited, translated where appropriate, accessible, and correctionable.

National Reports objects shall not be country rankings, public authority decisions, public warnings, financeability claims, procurement recommendations, certification, endorsement, deployment authorization, or execution authority.

### 20.4.8 National Studio objects.

National Studio objects shall include national dashboards, simulations, digital twins, AI workflows, data workflows, public authority learning workflows, readiness workflows, handoff demonstration workflows, secure review workflows, and public-safe output workflows. They shall be governed by access controls, no-download rules where applicable, no-write-back rules, no-command rules, output review, AI-use controls, logging, shutdown triggers, and archive rules.

National Studio objects shall not authorize deployment, public authority action, operational command, finance, procurement, insurance, community implementation, Indigenous-context implementation, or enterprise execution.

### 20.4.9 National Marketplace objects.

National Marketplace objects shall include localized listings for software, data, models, APIs, dashboards, Studio workflows, learning objects, reports, Campaigns, Foundry objects, National Portfolio objects, public-safe DRI objects, Observatory objects, and handoff context objects. They shall include title, description, version, steward, license, access class, support class, review status, Registry status, correction pathway, localization status, language, and boundary notices.

National Marketplace objects shall not create procurement, endorsement, validation, financeability, insurability, public authority approval, provider preference, handoff permission, or implementation authority.

### 20.4.10 National handoff objects.

National handoff objects shall include evidence context, data context, method context, Studio context, Grid context, TRL context, public-safe status, safeguard status, public authority dependencies, legal dependencies, finance and insurance questions, procurement boundaries, provider-neutrality notes, sponsor-boundary notes, recipient responsibilities, correction pathways, recall pathways, and archive rules prepared for lawful national recipients. They shall be nationally routed and boundary-disciplined.

National handoff objects shall not create implementation authority, IP transfer, data rights, procurement approval, finance approval, insurance approval, public authority approval, provider selection, community consent, Indigenous consent, deployment authorization, operational command, or execution authority.

## 20.5 Community and Protected Knowledge Controls

### 20.5.1 Community participation without consent overclaim.

Community participation in DDPGF localization, National Portfolios, Campaigns, Studio workflows, Observatory workflows, DRI contributions, public-safe reporting, Academy pathways, Nexus Universe preparation, Reports, or handoff-context review shall be recorded respectfully and accurately without converting participation into consent, endorsement, approval, social license, implementation permission, data-use permission, protected knowledge permission, or handoff authorization by implication. Participation may support learning, context, correction, and public-safe interpretation, but consent requires separate lawful and context-appropriate records where consent is required.

DDPGF shall use participation records, consent boundary records, public-safe summaries, and community-facing correction to prevent tokenization and overclaim.

### 20.5.2 Indigenous protocol-sensitive controls where applicable.

Where Indigenous institutions, communities, knowledge, territories, languages, data, governance protocols, sacred sites, protected knowledge, cultural materials, ecological knowledge, or participation are involved, DDPGF shall apply Indigenous protocol-sensitive controls. These controls may require restricted access, protected knowledge rooms, community-directed attribution, withholding of location information, no-AI-training restrictions, controlled translation, non-public archives, specific consent processes, special review, or non-release.

Indigenous protocol-sensitive controls shall not be overridden by open licensing, public-good publication, data commons logic, AI reuse, Marketplace discovery, national portfolio visibility, public authority learning, or handoff interest. Indigenous consent, where applicable, must be separately and lawfully recorded.

### 20.5.3 Protected knowledge restrictions.

Protected knowledge shall be excluded from ordinary publication, unrestricted licensing, open repositories, AI training, Marketplace exposure, public dashboards, public reports, public maps, public learning objects, or handoff packages unless a lawful, protocol-compliant, and consent-aware permission pathway authorizes a defined use. Protected knowledge may be represented only as metadata, generalized public-safe summary, controlled access record, secure-room object, protected knowledge room object, or archive record where appropriate.

Protected knowledge restrictions shall apply even where the knowledge is useful for resilience, WFEH-B systems, DRI, Observatory workflows, public authority learning, or innovation. Usefulness shall not override rights, safety, or protocols.

### 20.5.4 Youth safeguards.

Youth safeguards shall apply to national learning objects, Campaign participation, ILA-linked objects, iCRS records, WILP objects, portfolio displays, public recognition, Marketplace profiles, Registry records, community-facing materials, data objects, AI-use workflows, and public-safe reporting involving youth. Youth safeguards shall include privacy protection, restricted display, appropriate permissions, age-appropriate language, safe participation routes, anti-exploitation controls, data minimization, AI-use limits, and correction pathways.

Youth participation shall not create employment, public display rights, AI training permission, procurement relevance, public authority status, consent for broad data use, or handoff eligibility by implication.

### 20.5.5 Disability inclusion.

Disability inclusion shall be embedded in national localization, translation, accessibility, learning, dashboards, Reports, Marketplace listings, Registry records, Studio workflows, Campaigns, National Portfolios, Nexus Universe materials, and handoff literacy objects. DDPGF shall identify and correct barriers affecting persons with disabilities, including inaccessible formats, missing captions, missing alt text, screen-reader incompatibility, cognitive complexity, inaccessible forms, poor mobile access, or lack of alternative formats.

Disability inclusion shall not be treated as symbolic compliance. It shall be a condition of public-good usefulness and shall be recorded as part of object quality.

### 20.5.6 Humanitarian sensitivity.

Humanitarian sensitivity shall apply where objects involve disaster-affected people, conflict-affected people, displaced persons, refugees, migrants, humanitarian operations, health risks, food insecurity, water insecurity, vulnerable populations, or crisis-affected communities. Materials shall avoid harmful disclosure, political misuse, targeting, stigma, surveillance, false certainty, public warning confusion, or operational command overclaim.

Humanitarian-sensitive objects shall not be used as public authority decisions, emergency commands, targeting tools, immigration tools, policing tools, insurance tools, procurement tools, or finance tools by default.

### 20.5.7 Non-extractive knowledge practices.

DDPGF localization and National Portfolio work shall use non-extractive knowledge practices. Communities, local actors, Indigenous institutions where applicable, youth, persons with disabilities, civil society, public-interest actors, universities, and local experts shall not be treated merely as data sources, validation props, publicity assets, or implementation conduits. Participation shall be purposeful, protected, attributed where appropriate, compensated or supported where applicable, privacy-respecting, and correctionable.

Non-extractive practice shall require clarity on purpose, use, access, attribution, limits, benefits, correction, and withdrawal pathways.

### 20.5.8 Community-facing correction.

Community-facing correction shall provide routes for communities and affected participants to correct, challenge, withdraw, contextualize, update, or object to DDPGF objects that misrepresent local context, expose sensitive information, misuse protected knowledge, overstate consent, create stigma, use inaccurate language, disclose unsafe locations, or produce harmful public narratives. Correction pathways shall be accessible, multilingual where appropriate, plain-language, low-bandwidth where needed, and responsive.

Community-facing correction may trigger Registry updates, Marketplace changes, Reports corrections, dashboard revisions, Studio shutdowns, Campaign corrections, National Portfolio corrections, handoff recall, archive, or non-continuation.

### 20.5.9 Public-safe summaries.

Public-safe summaries shall be used to make national, community, technical, risk, data, AI, geospatial, Observatory, DRI, Studio, Grid, TRL, and handoff materials understandable without exposing sensitive details or creating authority overclaims. Public-safe summaries shall include scope, limitations, uncertainty, confidence where applicable, public-safe transformation notes, access limits, correction pathway, and boundary notices.

Public-safe summaries shall not be official warnings, official maps, public authority decisions, ratings, rankings, certifications, procurement recommendations, finance claims, consent records, deployment approvals, or execution authorizations.

### 20.5.10 Archive controls.

Archive controls shall preserve national, localized, translated, community-facing, protected knowledge, accessibility, and National Portfolio objects according to rights, privacy, sensitivity, public-safe status, correction needs, and institutional memory. Archives may be open, controlled, secure, sealed, metadata-only, or deleted where lawful and required. Archive records shall preserve source lineage, localization history, translation history, correction history, access class, sensitivity class, and boundary notices.

Archive status shall not revive current authority, current consent, current public authority meaning, current support, current deployment authorization, or execution authority.

## 20.6 Localization Boundary Rules

### 20.6.1 Translation is not substantive approval.

Translation of a DDPGF object into any national, regional, local, Indigenous, minority, or working language shall not constitute substantive approval, legal approval, technical approval, public authority approval, certification, endorsement, validation, procurement approval, finance approval, insurance approval, community consent, Indigenous consent, deployment authorization, or execution authority. Translation is a language-access function unless separately recorded otherwise.

### 20.6.2 Localization is not public authority adoption.

Localization of terminology, data context, legal context, public authority vocabulary, technical configuration, dashboard format, learning content, report content, Marketplace listing, Registry record, Studio workflow, or National Portfolio object shall not constitute public authority adoption, official policy, regulatory guidance, public finance allocation, procurement decision, permit, license, emergency warning, official map, or governmental endorsement. Public authority adoption requires a separate competent public authority process.

### 20.6.3 National Portfolio object is not country ranking.

A National Portfolio object, national dashboard, national DRI object, national report, national Marketplace object, national Registry record, national Studio workflow, national Grid input, national TRL note, or national handoff object shall not be interpreted as a country ranking, country score, comparative national rating, investment ranking, insurance ranking, procurement ranking, governance score, or public authority performance score by default. National Portfolio objects support national capability formation and public-good memory, not ranking.

### 20.6.4 Community display is not consent.

Display of community participation, community data, community stories, community needs, community priorities, community-facing summaries, community maps, Campaign records, or National Portfolio community context shall not imply community consent, social license, endorsement, implementation permission, data-use permission, protected knowledge permission, Indigenous consent, or handoff authorization. Consent must be separately and lawfully recorded where required.

### 20.6.5 Accessibility format is not new license.

Conversion of an object into an accessible format, including screen-reader-compatible text, alt text, captions, transcripts, audio, plain-language summaries, low-bandwidth versions, mobile versions, or offline packages, shall not create a new license, expand rights, remove restrictions, authorize derivatives beyond license terms, permit AI training, permit redistribution, permit commercial use, or override data-use, AI-use, public-safe, protected knowledge, privacy, security, or access controls.

### 20.6.6 National hosting is not execution authority.

National hosting, national repository mirroring, national localization, national data localization, sovereign compute use, National Node infrastructure, national Marketplace listing, national Registry record, national Studio workflow, national Nexus Universe presentation, or national handoff packaging shall not create execution authority, deployment authorization, public authority action, procurement approval, finance approval, insurance approval, provider selection, operational command, community implementation, Indigenous-context implementation, or enterprise execution. National hosting is an infrastructure and localization posture; execution requires separate lawful authority and competent actors.


---

# Agent Instructions: Querying This Documentation

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

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

```
GET https://docs.therisk.global/organization/operations/frameworks/distributed-digital-public-goods-framework-ddpgf/xx.-localization.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.