# XXI. LOCALIZATION
Localization adapts Nexus records, interfaces, and public-safe outputs across languages, jurisdictions, and contexts.
It sets boundaries for translation, local expression, cultural fit, and safe reuse without implying approval, deployment, or execution.
## 21.1 National Digital Public Goods Doctrine
### 21.1.1 National Localization as Public-Good Requirement
National localization as public-good requirement is the doctrine that Nexus digital public goods shall not be treated as mature, reusable, discoverable, or handoff-aware merely because they exist globally, regionally, technically, or in a common Nexus repository. A digital public good becomes nationally usable only when its language, legal context, data context, public authority boundary, safeguard context, accessibility, infrastructure context, institutional routing, National Portfolio relationship, support class, correction pathway, archive rule, and lawful handoff dependencies have been localized for the relevant national setting.
National localization is not cosmetic translation. It is a public-good control that adapts digital public goods to national sovereignty, national ownership, local realities, public authority boundaries, community safeguards, Indigenous protocols where applicable, disability inclusion, humanitarian sensitivity, national data rules, public-safe reporting, DRI and Observatory context, National Portfolio needs, Nexus Universe continuation, Registry status truth, Marketplace discovery, Grid and TRL inputs, and lawful handoff without bypass.
A National Localization Record should identify:
1. digital public good object, including software, dataset, metadata, schema, ontology, API, model, dashboard, Studio workflow, Report, learning object, Campaign object, Registry record, Marketplace listing, Grid input, National Portfolio object, Nexus Universe output, or handoff dependency note;
2. national context, including country, National Node, National Nexus Consortium pathway, National Portfolio relationship, legal context, public authority context, language context, accessibility context, data sovereignty context, infrastructure context, WFEH-B context, DRR context, DRF and DRI context, community safeguard context, and Indigenous protocol context where applicable;
3. localization requirements, including national language, plain-language summary, accessible format, local terminology, national public-safe wording, national data-use labels, national AI-use labels, national public authority boundary notices, national finance-readiness boundary notices, national safeguard notices, and national archive rules;
4. review pathway, including National Node review, National Portfolio review, data review, AI review, cyber review, privacy review, accessibility review, public-safe review, safeguard review, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, legal boundary review, Marketplace review, Registry review, Grid review, handoff review, correction review, and archive review;
5. status and release class, including unlocalized, localization in progress, nationally localized draft, nationally reviewed, nationally public-safe transformed, National Node-visible, public authority learning-only, Marketplace-listed for national discovery, Registry-updated, Grid-input-ready, handoff-context-ready, corrected, withdrawn, recalled, archived, or non-continuing;
6. boundary notices, confirming that national localization is not national policy adoption, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
National localization is the discipline that prevents digital public goods from becoming globally elegant but nationally unusable. Nexus shall treat localization as a legitimacy requirement, not a downstream convenience.
### 21.1.2 National Ownership Before Local Delivery
National ownership before local delivery is the doctrine that Nexus digital public goods shall be routed through nationally legitimate records, National Portfolios, National Nodes, National Nexus Consortium pathways, national safeguard review, national public authority learning boundaries, national data sovereignty controls, national language access, and lawful national handoff pathways before they are treated as locally deliverable, locally displayable, locally supportable, or locally handoff-aware.
National ownership does not mean national gatekeeping abuse, monopoly control, political capture, public authority substitution, sponsor control, provider control, or exclusion of communities. It means that country-level Nexus activity must be grounded in national context, national public-good memory, national legal and institutional reality, national data controls, national safeguard conditions, and national continuation pathways before any local implementation-facing actor may rely on Nexus context.
A National Ownership Record should identify:
1. national ownership pathway, including National Node, National Nexus Consortium, National Council, Helix Council, National Working Group, Competence Cell, National Portfolio, National Dense Nexus Core, Nexus Universe national pathway, or lawful handoff pathway;
2. digital public good object or pathway, including repository, software object, data object, model object, dashboard, Studio workflow, Report, Academy object, Campaign object, Registry record, Marketplace listing, Grid or TRL input, public authority learning record, finance-readiness record, or handoff dependency note;
3. national legitimacy conditions, including national stakeholder routing, public-safe review, language access, accessibility, community safeguard review, Indigenous protocol review where applicable, data sovereignty review, public authority boundary review, finance-readiness boundary review, correction pathway, and archive rule;
4. anti-bypass controls, including no global bypass, no regional supremacy, no sponsor control, no provider validation, no capital-reader control, no donor control, no public finance overclaim, no public authority substitution, no community consent overclaim, and no enterprise-stack collapse;
5. local delivery relationship, including local learning, local testing, local Studio demonstration, local Campaign participation, local Academy pathway, local public authority learning, local provider contribution, local host support, local handoff dependency, or separate lawful execution pathway;
6. boundary notices, confirming that national ownership is not public authority approval, official national plan, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
National ownership ensures that local delivery is not imposed by global capability, regional enthusiasm, provider readiness, sponsor support, or capital-reader attention. The national public-good record must come first.
### 21.1.3 National Repositories and Mirrors
National repositories and mirrors are nationally governed or nationally routed copies, mirrors, forks, registries, metadata records, object stores, package repositories, data repositories, model repositories, documentation repositories, learning repositories, Report repositories, dashboard repositories, Studio object repositories, Campaign object repositories, Registry-linked records, Marketplace-linked records, archive repositories, and controlled access environments that make Nexus digital public goods available within a national context under national access, language, data, safeguard, correction, and archive rules.
A national repository or mirror is not merely a copy. It is a national trust and continuity mechanism. It must preserve provenance, version, license class, data-use labels, AI-use labels, public-safe status, support class, sensitivity class, localization status, accessibility status, correction pathway, archive rule, dependency links, public authority boundary notices, finance-readiness boundary notices, and handoff restrictions.
A National Repository or Mirror Record should identify:
1. repository or mirror class, including code repository, dataset repository, metadata repository, model repository, documentation repository, dashboard repository, Studio repository, Academy repository, Campaign repository, Report repository, Registry mirror, Marketplace mirror, National Portfolio repository, secure-room repository, data-room repository, protected knowledge repository, or archive repository;
2. object classes hosted or mirrored, including software, data, metadata, models, ontologies, schemas, APIs, dashboards, reports, learning objects, credentials where applicable, Campaign objects, proof receipts where applicable, Registry records, Marketplace listings, Grid records, TRL records, public authority learning records, finance-readiness records, and handoff dependency notes;
3. national controls, including national steward, access class, localization status, language status, accessibility status, data sovereignty status, cross-border controls, cyber controls, privacy controls, public-safe status, protected knowledge restrictions, Indigenous protocol controls where applicable, and correction pathway;
4. provenance and synchronization, including source repository, upstream version, fork status, mirror status, dependency object, derived object, localized object, translated object, successor object, supersession rule, update cadence, correction propagation, withdrawal propagation, recall propagation, and archive synchronization;
5. release and support status, including supported, time-limited support, unsupported, unsupported-by-design, national support required, local maintainer assigned, deprecated, suspended, withdrawn, recalled, archived, or non-continuing;
6. boundary notices, confirming that national repository or mirror presence is not procurement approval, deployment authorization, production approval, security certification, public authority approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, or execution.
National repositories and mirrors turn global public-good objects into nationally maintainable infrastructure while preserving status truth and correctionability.
### 21.1.4 National Portfolio Objects
National Portfolio objects are the national digital public-good records that organize country-level Nexus context, priorities, risks, evidence needs, Observatory needs, DRI needs, WFEH-B dependencies, DRR and DRF learning needs, public authority learning questions, safeguard conditions, Campaign signals, Academy needs, Foundry build requests, Studio workflows, Registry objects, Marketplace objects, Grid and TRL inputs, finance-readiness questions, public finance relevance questions, support records, and lawful handoff dependencies.
National Portfolio objects are not official national plans by default. They are public-good memory, learning, evidence, readiness, safeguard, discovery, and continuation objects. They may inform national actors and support public authority learning, but they do not become policy, public finance allocation, procurement plan, consent record, deployment plan, or execution plan by implication.
A National Portfolio Object Record should identify:
1. object class, including National Context Record, National Systems-Risk Map, National Challenge Brief, Evidence Need Record, Observatory Need Record, Core Build Request, Safeguard Record, Public Authority Learning Record, Readiness Question Record, Competence Cell Workplan, Campaign record, Academy need record, Foundry build request, Studio workflow, DRI record, Registry object, Marketplace object, Grid input, TRL context, finance-readiness record, public finance relevance record, support record, handoff dependency note, correction record, or archive record;
2. national context, including country, National Node, National Nexus Consortium pathway, public authority learning context, language context, accessibility context, data sovereignty context, safeguard context, WFEH-B context, DRR context, DRF context, DRI context, Observatory context, Nexus Universe context, and lawful handoff context;
3. evidence and status fields, including source records, data-use labels, AI-use labels, confidence labels where applicable, uncertainty labels where applicable, review status, public-safe status, sensitivity class, localization status, accessibility status, Registry status, Marketplace status, Grid or TRL context, correction status, support class, and archive rule;
4. routing pathways, including National Working Group, Competence Cell, Academy pathway, Risk Academy pathway, Campaign pathway, Foundry pathway, Studio pathway, Reports pathway, Registry update, Marketplace listing, Grid review, Nexus Universe arena, public authority learning room, readiness room, finance-readiness room, donor-reader room, public finance learning room, handoff dependency pathway, correction, archive, or non-continuation;
5. national ownership and safeguard controls, including national ownership before local delivery, no regional supremacy, no global supremacy, data sovereignty, community safeguards, Indigenous protocol controls where applicable, disability inclusion, humanitarian sensitivity, public-safe reporting, public authority boundaries, finance-readiness boundaries, and correctionability;
6. boundary notices, confirming that National Portfolio objects are not official national plans, government policy, public authority approval, procurement approvals, public finance allocations, financeability determinations, insurability determinations, donor commitments, community consent, Indigenous consent where applicable, deployment authorizations, or execution instructions.
National Portfolio objects are the country-level memory of Nexus digital public goods. They make national continuation possible without creating national authority by implication.
### 21.1.5 National Language Access
National language access is the doctrine that Nexus digital public goods, public-safe summaries, Reports, Campaign materials, Academy materials, Risk Academy materials, Studio summaries, DRI outputs, Observatory summaries, Marketplace listings, Registry records, National Portfolio objects, Nexus Universe materials, public authority learning records, finance-readiness materials, donor-readiness materials, public finance learning materials, safeguard materials, correction channels, and handoff dependency notes should be accessible in the relevant national and local languages where public-good participation, public authority learning, community review, accessibility, safeguard review, or handoff understanding requires such access.
National language access is not simple machine translation by default. It requires legal meaning, public authority boundary meaning, safeguard meaning, consent meaning, finance-readiness boundary meaning, data-use meaning, AI-use meaning, protected knowledge restrictions, Indigenous protocol controls where applicable, and public-safe language to travel accurately across languages.
A National Language Access Record should identify:
1. source object, including Report, public-safe summary, DRI output, Observatory summary, Studio workflow, Campaign material, Academy object, Registry record, Marketplace listing, National Portfolio object, Nexus Universe material, finance-readiness material, public authority learning material, safeguard record, correction channel, or handoff dependency note;
2. language context, including official national language, local language, Indigenous language where applicable, working language, public authority language, community language, accessibility language need, plain-language need, and translation sensitivity;
3. translation and localization status, including untranslated, machine-assisted draft, human-reviewed, legally reviewed, public-safe reviewed, community-reviewed where appropriate, Indigenous protocol-reviewed where applicable, plain-language version available, accessible version available, restricted translation, prohibited translation, archived translation, or non-continuing translation;
4. meaning controls, including no loss of boundary notices, no public authority overclaim, no consent overclaim, no donor overclaim, no finance or insurance overclaim, no procurement overclaim, no warning overclaim, no deployment overclaim, no protected knowledge exposure, and no AI-use expansion through translation;
5. release and correction controls, including public release, controlled-public release, community-review-only, public authority learning-only, secure-room-only, data-room-only, protected knowledge room-only, media-safe release, correction channel, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that translation or national language access is not a new license, publication permission, data-use permission, AI-use permission, public authority approval, community consent, Indigenous consent where applicable, procurement approval, deployment authorization, or execution.
National language access ensures that Nexus does not become legitimate only for those who can read the global source language.
### 21.1.6 National Data Sovereignty
National data sovereignty is the doctrine that data, metadata, derived data, model inputs, AI-use labels, DRI datasets, Observatory datasets, National Portfolio datasets, Studio datasets, Campaign datasets, learning records, Registry records, Marketplace records, Grid records, public authority learning records, safeguard records, finance-readiness records, and handoff dependency notes that relate to a national context must be governed with respect for national law, data localization requirements, data stewardship, cross-border controls, privacy, cybersecurity, public authority sensitivity, community safeguards, Indigenous data sovereignty considerations where applicable, protected knowledge restrictions, and correctionability.
National data sovereignty does not mean automatic data isolation or national gatekeeping abuse. It means that Nexus must know where data came from, who may use it, where it may be stored, whether it may cross borders, whether AI use is allowed, whether public-safe summaries may be released, whether secure-room or compute-to-data methods are required, whether public authority sensitivity applies, whether community safeguards apply, and whether lawful handoff is restricted.
A National Data Sovereignty Record should identify:
1. data object, including raw data, processed data, public-safe data, aggregated data, synthetic data, metadata-only record, data dictionary, codebook, schema, pipeline, feature set, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, Studio dataset, Campaign dataset, Registry dataset, Marketplace dataset, Grid dataset, learning record, support record, or handoff dependency data;
2. national context and stewardship, including country, National Node, national data steward, institutional steward, community steward where applicable, Indigenous data steward where applicable, public authority steward where applicable, public-safe steward, archive steward, and correction contact;
3. data-use and AI-use labels, including open, public-safe, controlled-public, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, handoff-recipient-only, no-AI use, retrieval-only with review, summarization with review, secure-room AI only, public-safe AI output only, training prohibited, or archive-only;
4. storage and transfer controls, including national repository, national mirror, secure room, data room, compute-to-data environment, localization requirement, cross-border transfer review, encryption, access control, no-download rule, logging, retention, deletion, sealing, archive, and incident response;
5. public-safe and handoff controls, including public-safe transformation, metadata-only treatment, aggregation, anonymization, geospatial masking, public authority boundary review, finance and insurance boundary review, donor boundary review, handoff dependency review, correction, withdrawal, recall, archive, and non-continuation;
6. boundary notices, confirming that national data availability is not open data, data ownership transfer, AI-use permission, public authority record status, finance or insurance use permission, donor-use permission, public finance allocation, consent, handoff authorization, deployment authorization, or execution.
National data sovereignty is the data governance spine of national digital public goods. It ensures that reusability does not become uncontrolled extraction.
### 21.1.7 National Public Authority Boundaries
National public authority boundaries are the controls that prevent Nexus national digital public goods, National Portfolio objects, national repositories, national mirrors, DRI outputs, Observatory summaries, Studio workflows, Reports, Campaigns, Registry records, Marketplace listings, Grid and TRL records, finance-readiness records, public finance relevance records, donor-readiness records, Academy materials, Nexus Universe outputs, public-safe summaries, and handoff dependency notes from being represented as national policy, government approval, public authority action, regulation, permit, license, compliance finding, official statistics, public warning, emergency command, procurement decision, public finance allocation, public service instruction, consent, deployment authorization, or execution.
National public authority learning is permitted and valuable. Public authority substitution is prohibited. Public authority participation in national digital public goods work must be recorded as learning-only unless a separate competent public authority lawfully acts through its own process.
A National Public Authority Boundary Record should identify:
1. national object or activity, including National Portfolio object, national repository, national mirror, Report, DRI output, Observatory summary, Studio workflow, Campaign material, Marketplace listing, Registry record, Grid input, TRL record, public authority learning record, public finance relevance record, finance-readiness record, donor-readiness record, Nexus Universe output, or handoff dependency note;
2. public authority interface, including ministry, regulator, municipality, emergency management body, meteorological or hydrological service, public health authority, infrastructure authority, public finance body, public procurement body, standards-interface public body, statistical office, cross-border public institution, public utility, public service institution, or public-sector learner;
3. boundary risk, including official-plan overclaim, policy overclaim, regulatory overclaim, procurement overclaim, public finance allocation overclaim, warning overclaim, emergency command overclaim, official statistics overclaim, standards adoption overclaim, public health advisory overclaim, infrastructure approval overclaim, ministry endorsement overclaim, municipal approval overclaim, community consent overclaim, deployment overclaim, or execution overclaim;
4. required notices, including learning-only, no-decision, not national policy, not official national plan, not regulation, not permit, not license, not official statistics, not warning, not command, not procurement, not public finance allocation, not public authority approval, not consent, not deployment, and not execution;
5. name, logo, and publication controls, including public authority naming, logo use, quote use, public-safe summary, media-safe language, public authority review status, public naming permission, and correction channel;
6. boundary notices, confirming that national digital public goods may support public authority learning but do not create public authority effect unless separately and lawfully recorded by the competent public authority.
National public authority boundaries ensure that national digital public goods remain useful to public institutions without becoming unauthorized public acts.
### 21.1.8 National Handoff Without Bypass
National handoff without bypass is the doctrine that any transition from Nexus national digital public goods, National Portfolio objects, national repositories, national mirrors, DRI outputs, Observatory summaries, Studio workflows, Reports, Campaigns, Foundry builds, Academy objects, Registry records, Marketplace listings, Grid or TRL records, finance-readiness records, public authority learning records, public finance relevance records, safeguard records, or Nexus Universe outputs into downstream action must occur through nationally appropriate, lawful, recorded, safeguard-aware, public authority-aware, data-sovereignty-aware, and non-executing handoff pathways without bypassing National Nodes, National Portfolio records, community safeguards, Indigenous protocols where applicable, public authority dependencies, procurement dependencies, finance dependencies, insurance dependencies, donor dependencies, public finance dependencies, consent dependencies, or correction pathways.
National handoff without bypass does not require Nexus to execute. It requires Nexus to preserve dependency truth before any separate actor executes. National Consortium Companies, Project SPVs, public authorities acting separately, providers, operators, hosts, universities, labs, funders, insurers, donors, public finance actors, communities where appropriate, Indigenous institutions where applicable, and other lawful recipients must conduct their own review before action.
A National Handoff Without Bypass Record should identify:
1. handoff candidate object, including National Portfolio object, Report, dataset, software, model, dashboard, Studio workflow, DRI output, Observatory output, Grid record, TRL record, Registry record, Marketplace record, Campaign output, Academy object, Foundry build, safeguard record, readiness room output, Nexus Universe output, or finance-readiness record;
2. national routing pathway, including National Node, National Nexus Consortium, National Council, Helix Council, National Working Group, Competence Cell, National Portfolio, public authority learning record, readiness room, finance-readiness room, public finance learning room, safeguard room, protected knowledge room, or Handoff Dependency Arena;
3. recipient class, including National Consortium Company, Project SPV, public authority acting separately, provider, operator, contractor, host, university, lab, funder, insurer, donor, public finance actor, community actor where appropriate, Indigenous institution where applicable, or other lawful recipient;
4. dependency categories, including evidence, data, technical, software, AI, cyber, privacy, public-safe, public authority, procurement, finance, insurance, donor, public finance, safeguard, consent, legal, operational, enterprise, maintenance, liability, correction, recall, archive, and non-continuation dependencies;
5. anti-bypass controls, including no National Node bypass, no National Portfolio bypass, no public authority dependency bypass, no community safeguard bypass, no Indigenous protocol bypass where applicable, no data sovereignty bypass, no procurement bypass, no finance or insurance bypass, no donor or public finance bypass, no correction bypass, no sponsor control, no provider validation, no capital control, and no global or regional supremacy;
6. boundary notices, confirming that national handoff notes are not handoff approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, public authority action, community consent, Indigenous consent where applicable, deployment authorization, implementation authorization, or execution.
National handoff without bypass is the bridge discipline of national digital public goods. It lets records travel toward lawful actors without carrying false authority.
The final National Digital Public Goods Doctrine rule is: national digital public goods require national localization, national ownership before local delivery, national repositories and mirrors, National Portfolio objects, national language access, national data sovereignty, national public authority boundaries, and national handoff without bypass. Nexus may create, localize, mirror, translate, register, list, review, route, correct, archive, and prepare dependency-aware national digital public goods; it shall not convert them into national policy, procurement approval, public finance allocation, public authority action, community or Indigenous consent, deployment authorization, or execution by implication.
## 21.2 Localization Classes
### 21.2.1 Language Translation
Language translation is the localization class through which Nexus digital public goods, Reports, public-safe summaries, DRI outputs, Observatory summaries, Studio workflows, Campaign materials, Academy materials, Risk Academy materials, Registry records, Marketplace listings, National Portfolio objects, Nexus Universe materials, finance-readiness records, public authority learning records, safeguard records, correction channels, offline packages, and handoff dependency notes are rendered into national, official, local, working, Indigenous where applicable, community, public authority, or accessibility-relevant languages.
Language translation shall not be treated as word substitution alone. It must preserve legal meaning, safeguard meaning, public authority boundary meaning, finance-readiness boundary meaning, consent meaning, data-use meaning, AI-use meaning, protected knowledge restrictions, accessibility meaning, correction pathways, archive status, and no-conversion notices. A translated Nexus object that loses boundary discipline is not a valid localized object.
A Language Translation Record should identify:
1. source object, including software documentation, data dictionary, schema, ontology, API documentation, dashboard, 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 material, correction channel, or handoff dependency note;
2. language context, including source language, target language, national language, local language, Indigenous language where applicable, public authority language, community language, technical language, plain-language need, accessibility format, and translation sensitivity;
3. translation method, including human translation, expert translation, community-reviewed translation, legally reviewed translation, public-safe translation, accessibility translation, machine-assisted draft with human review, prohibited machine translation, restricted translation, protected knowledge room translation, or archive-only translation;
4. meaning controls, including preservation of defined terms, role separation, public authority boundaries, finance and insurance boundaries, donor and public finance boundaries, consent boundaries, public-safe limits, protected knowledge restrictions, AI-use restrictions, data-use labels, archive status, and correction notices;
5. release status, including untranslated, draft translation, reviewed translation, nationally localized translation, controlled-public translation, public translation, community-review-only translation, public authority learning-only translation, secure-room-only translation, data-room-only translation, protected knowledge room-only translation, withdrawn translation, archived translation, or non-continuing translation;
6. boundary notices, confirming that translation is not a new license, new publication permission, new data-use permission, new AI-use permission, public authority approval, community consent, Indigenous consent where applicable, procurement approval, deployment authorization, or execution.
Language translation makes Nexus nationally intelligible only when it preserves meaning, limits, and correctionability.
### 21.2.2 Legal-Context Localization
Legal-context localization is the localization class through which Nexus digital public goods are adapted to the relevant national, subnational, regional, constitutional, administrative, data, privacy, cybersecurity, public authority, procurement, public finance, nonprofit, charity, labor, youth, disability, Indigenous where applicable, humanitarian, intellectual property, open-source, AI, platform, consumer, competition, insurance, finance, and handoff legal context without turning Nexus into legal advice, compliance certification, regulatory approval, or public authority action.
Legal-context localization shall identify where legal concepts, permissions, prohibitions, dependencies, risk classifications, public authority roles, consent requirements, data restrictions, repository rules, publication rules, AI-use rules, handoff rules, and correction obligations differ across jurisdictions. It shall not state that a Nexus object is legally approved, compliant, deployable, procured, financeable, insurable, or executable unless a separate competent actor lawfully records such status outside Nexus.
A Legal-Context Localization Record should identify:
1. jurisdictional context, including country, subnational jurisdiction, applicable public authority layer, National Node context, cross-border context, data localization context, Indigenous governance context where applicable, and conflict-of-law issue where relevant;
2. legal domains reviewed, including corporate or nonprofit status, public authority boundaries, privacy, data protection, cybersecurity, AI governance, intellectual property, licensing, open-source, procurement, public finance, insurance, finance, labor, youth protection, disability access, community safeguards, Indigenous protocols where applicable, humanitarian sensitivity, competition, and handoff dependencies;
3. object affected, including repository, software, dataset, metadata, model, dashboard, Report, Campaign, Academy object, Studio workflow, Registry record, Marketplace listing, National Portfolio object, Nexus Universe output, finance-readiness record, public authority learning record, or handoff dependency note;
4. localized legal controls, including jurisdictional notice, public authority boundary notice, no-legal-advice notice, data-use label, AI-use label, license note, publication restriction, accessibility requirement, youth safeguard, protected knowledge restriction, procurement boundary, finance boundary, public finance boundary, consent boundary, and handoff dependency;
5. review and escalation, including legal boundary review, public authority boundary review, data review, AI review, safeguard review, finance and insurance boundary review, procurement boundary review, Indigenous protocol review where applicable, regulated-perimeter escalation, correction, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that legal-context localization is not legal advice, compliance approval, regulatory approval, procurement approval, public finance allocation, financeability, insurability, public authority approval, consent, deployment authorization, or execution.
Legal-context localization makes national use safer by identifying legal dependencies, not by replacing legal process.
### 21.2.3 Public Authority Terminology Localization
Public authority terminology localization is the localization class through which Nexus adapts public-sector terms, institutional names, public authority categories, regulatory references, public finance terms, procurement terms, emergency terms, warning terms, standards-interface terms, statistical terms, public health terms, infrastructure terms, municipal terms, cross-border terms, and legal-boundary notices to the relevant national and local public authority context.
Public authority terminology must be localized carefully because mistranslated or imported terminology can imply official status, policy adoption, regulatory decision, public warning, emergency command, procurement approval, public finance allocation, public authority approval, official statistics, standards adoption, consent, deployment authorization, or execution. Nexus shall not use national public authority terminology in a way that overstates public authority relationship or creates official-status confusion.
A Public Authority Terminology Localization Record should identify:
1. terminology field, including ministry, agency, regulator, municipality, public utility, emergency body, meteorological or hydrological service, public health authority, infrastructure authority, public finance body, procurement body, standards-interface body, statistical office, public service institution, cross-border public institution, or public authority learner;
2. source and localized term, including original Nexus term, national equivalent, local equivalent, official term if safe, generic term if safer, prohibited term, restricted term, and public-safe explanation;
3. boundary risk, including official-status confusion, policy overclaim, regulatory overclaim, public finance overclaim, procurement overclaim, warning overclaim, emergency command overclaim, official-statistics overclaim, standards-authority overclaim, public health advisory overclaim, infrastructure approval overclaim, consent overclaim, deployment overclaim, or execution overclaim;
4. required notices, including learning-only, no-decision, not policy, not regulation, not warning, not command, not procurement, not public finance allocation, not official statistics, not standards adoption, not consent, not deployment, and not execution;
5. review pathway, including public authority boundary review, legal boundary review, public-safe review, translation review, national localization review, media-safe review, correction review, and archive review;
6. boundary notices, confirming that terminology localization improves clarity and does not create a public authority relationship, approval, adoption, mandate, procurement status, public finance status, consent, deployment authorization, or execution.
Public authority terminology localization prevents language itself from becoming a false public act.
### 21.2.4 Technical Localization
Technical localization is the localization class through which Nexus software, APIs, SDKs, connectors, dashboards, datasets, schemas, ontologies, models, Studio workflows, repository structures, deployment-neutral packages, documentation, testing suites, security controls, accessibility features, metadata, observability methods, DRI indicators, Registry records, Marketplace listings, Grid inputs, and TRL context are adapted to national technical environments without implying production approval, procurement readiness, security certification, public authority approval, deployment authorization, or execution.
Technical localization may include adaptation to national data formats, language encoding, units, geospatial references, time zones, infrastructure constraints, connectivity levels, cybersecurity expectations, cloud and sovereign hosting constraints, repository mirrors, API endpoints, authentication patterns, accessibility requirements, local standards interfaces, and public-safe release requirements.
A Technical Localization Record should identify:
1. technical object, including repository, library, service, application, dashboard, API, SDK, connector, adapter, command-line tool, notebook, template, infrastructure-as-code, test suite, reference implementation, dataset, model, Studio workflow, Registry record, Marketplace listing, or Grid input;
2. national technical context, including hosting environment, connectivity level, cybersecurity baseline, data sovereignty requirement, language encoding, national identifiers where lawful, geospatial system, units, time zone, accessibility requirement, local infrastructure dependency, public authority learning context, and support context;
3. localization work, including configuration, translation of technical documentation, API adaptation, connector adaptation, schema mapping, ontology mapping, data dictionary adaptation, dashboard localization, testing adaptation, security review, dependency review, accessibility remediation, repository mirroring, and support classification;
4. review controls, including code review, dependency review, security review, secret scanning, SBOM review, data review, AI review, cyber review, privacy review, accessibility review, public-safe review, safeguard review, Registry review, Marketplace review, Grid review, handoff review, correction review, and archive review;
5. status, including unlocalized, technically localized draft, national technical review pending, controlled release, public-safe transformed, Registry-recorded, Marketplace-listed, supported, unsupported, deprecated, suspended, corrected, withdrawn, recalled, archived, or non-continuing;
6. boundary notices, confirming that technical localization is not production approval, security certification, procurement approval, financeability, insurability, public authority approval, consent, deployment authorization, or execution.
Technical localization makes digital public goods usable in national environments while preserving non-execution and status truth.
### 21.2.5 Data Localization
Data localization is the localization class through which Nexus data objects, metadata, datasets, data dictionaries, codebooks, schemas, pipelines, feature sets, benchmark datasets, DRI datasets, Observatory datasets, National Portfolio datasets, Studio datasets, Campaign datasets, Registry records, Marketplace records, Grid inputs, learning records, support records, public authority learning records, finance-readiness records, and handoff dependency records are governed, stored, processed, displayed, transferred, corrected, and archived according to national data context.
Data localization may require national repositories, national mirrors, local storage, secure rooms, data rooms, compute-to-data environments, cross-border transfer review, public-safe transformation, data minimization, data-use labels, AI-use labels, geospatial masking, protected knowledge restrictions, Indigenous data sovereignty considerations where applicable, public authority sensitivity controls, and deletion or sealing where required.
A Data Localization Record should identify:
1. data object, including raw data, processed data, public-safe data, aggregated data, synthetic data, metadata-only record, data dictionary, codebook, schema, pipeline, feature set, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, Studio dataset, Campaign dataset, Registry data, Marketplace data, Grid data, learning record, support record, or handoff data;
2. national data context, including country, data steward, national repository, national mirror, data sovereignty requirement, localization requirement, cross-border transfer issue, public authority sensitivity, community sensitivity, Indigenous protocol sensitivity where applicable, protected knowledge class, cyber sensitivity, infrastructure sensitivity, health sensitivity, youth sensitivity, geospatial sensitivity, and archive requirement;
3. data-use and AI-use labels, including open, public-safe, controlled-public, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth, health-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, handoff-recipient-only, no-AI use, retrieval-only with review, summarization with review, secure-room AI only, public-safe AI output only, training prohibited, archive-only, or deletion-required;
4. processing and storage controls, including minimization, purpose limitation, access control, encryption, logging, retention, deletion, sealing, compute-to-data, no-download rule, output review, data-room handling, secure-room handling, protected knowledge room handling, national mirror, and archive;
5. public-safe and release controls, including aggregation, anonymization, pseudonymization, geospatial masking, metadata-only display, public-safe summary, controlled release, Registry display, Marketplace listing, Report use, Studio use, handoff restriction, correction, withdrawal, recall, archive, and non-continuation;
6. boundary notices, confirming that data localization is not open data release, data ownership transfer, AI-use permission, public authority record status, finance or insurance use permission, donor-use permission, public finance allocation, consent, handoff authorization, deployment authorization, or execution.
Data localization ensures that reusable data remains lawful, safe, and nationally governed rather than merely portable.
### 21.2.6 Cultural Localization
Cultural localization is the localization class through which Nexus adapts language, examples, visuals, metaphors, public-safe summaries, Campaign materials, Academy content, Risk Academy content, Studio scenarios, Reports, DRI explanations, Observatory summaries, community-facing materials, public authority learning materials, Marketplace descriptions, Registry displays, Nexus Universe materials, finance-readiness materials, donor-readiness materials, public finance learning materials, and handoff notes to local culture, dignity, historical context, community norms, Indigenous protocols where applicable, religious or cultural sensitivities where relevant, disability inclusion, youth safeguards, humanitarian context, and non-extractive knowledge practices.
Cultural localization shall not stereotype, tokenize, flatten, romanticize, politicize, stigmatize, rank, exoticize, or appropriate communities. It must preserve public-safe meaning, consent boundaries, protected knowledge restrictions, language nuance, attribution preferences, community correction channels, and safeguard conditions.
A Cultural Localization Record should identify:
1. cultural context, including community, country, region, language group, local institution, diaspora context, Indigenous protocol context where applicable, youth context, disability context, humanitarian context, historical sensitivity, public authority context, and media sensitivity;
2. material localized, including Report, public-safe summary, Campaign material, Academy module, Studio scenario, dashboard, DRI output, Observatory summary, National Portfolio object, Nexus Universe material, Marketplace listing, Registry display, finance-readiness material, donor-readiness material, public finance learning material, or handoff note;
3. localization controls, including non-stigmatizing language, community dignity, protected knowledge restriction, attribution review, image review, visual review, translation review, accessibility review, public-safe review, Indigenous protocol review where applicable, humanitarian sensitivity review, and media-safe review;
4. risk controls, including no cultural appropriation, no consent overclaim, no community endorsement overclaim, no public authority overclaim, no donor priority overclaim, no aid prioritization overclaim, no financeability overclaim, no insurability overclaim, no deployment overclaim, and no execution overclaim;
5. review and correction, including community review where appropriate, cultural reviewer review where appropriate, safeguard review, public-safe review, protected knowledge review, correction channel, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that cultural localization is not community endorsement, Indigenous consent where applicable, public authority approval, donor commitment, aid prioritization, procurement approval, deployment authorization, or execution.
Cultural localization allows Nexus to be locally meaningful without becoming extractive or performative.
### 21.2.7 Accessibility Localization
Accessibility localization is the localization class through which Nexus adapts digital public goods, Reports, Campaign materials, Academy pathways, Risk Academy materials, Studio workflows, dashboards, DRI outputs, Observatory summaries, Registry records, Marketplace listings, National Portfolio objects, Nexus Universe materials, public authority learning materials, finance-readiness materials, donor-readiness materials, public finance learning materials, correction channels, offline packages, and handoff notes to the accessibility needs, disability inclusion requirements, language needs, assistive technology conditions, low-literacy contexts, device constraints, and participation realities of the national or local setting.
Accessibility localization must consider screen-reader compatibility, captions, transcripts, alt text, plain-language summaries, keyboard navigation, color contrast, mobile-first design, low-bandwidth access, offline packages, accessible forms, accessible correction channels, accessible rooms, physical accessibility where relevant, sign-language or interpretation needs where applicable, and reasonable accommodation pathways where applicable.
An Accessibility Localization Record should identify:
1. accessibility context, including disability inclusion needs, assistive technology context, language access needs, plain-language needs, literacy context, mobile access, low-bandwidth context, offline access, physical access, sensory access, cognitive access, youth accessibility, and public authority accessibility;
2. object localized, including Report, dashboard, Campaign page, Academy module, Studio workflow, DRI summary, Observatory summary, Registry display, Marketplace listing, National Portfolio material, Nexus Universe material, public authority learning material, readiness material, correction form, offline package, or handoff note;
3. accessibility controls, including screen-reader compatibility, semantic structure, alt text, captions, transcripts, audio description, plain-language summary, large-print version, low-bandwidth version, mobile version, offline package, accessible form, accessible room support, translation, and accommodation pathway;
4. review and remediation, including accessibility review, disability stakeholder review where appropriate, public-safe review, language review, mobile review, low-bandwidth review, offline package review, correction review, remediation required, restricted release, withdrawal, recall, archive, or non-continuation;
5. status, including inaccessible, accessibility review pending, remediation in progress, accessible release, alternative format available, accommodation required, low-bandwidth available, mobile-ready, offline package available, corrected, archived, or non-continuing;
6. boundary notices, confirming that accessibility localization improves usability and inclusion but does not create a new license, public authority approval, procurement approval, certification, consent, deployment authorization, or execution.
Accessibility localization makes national participation possible for people who would otherwise be excluded by design.
### 21.2.8 Low-Bandwidth Localization
Low-bandwidth localization is the localization class through which Nexus digital public goods and participation pathways are adapted for settings where internet connectivity, device capability, electricity, data affordability, platform access, cloud access, or digital infrastructure are limited, unreliable, expensive, censored, degraded, or temporarily disrupted.
Low-bandwidth localization may include lightweight pages, text-first versions, compressed documents, static dashboards, downloadable summaries, offline-first forms, printable packets, audio summaries where appropriate, messaging-compatible summaries where lawful and safe, asynchronous uploads, delayed synchronization, local repository mirrors, National Node-hosted packages, and public-safe low-data formats.
A Low-Bandwidth Localization Record should identify:
1. access setting, including rural, remote, low-connectivity, mobile-only, degraded-mode, humanitarian, disaster-affected, public authority field, school, community, National Node, Nexus Universe continuation, or infrastructure-constrained context;
2. object localized, including Report, DRI summary, Observatory summary, dashboard, Campaign material, Academy module, Studio summary, Marketplace listing, Registry record, National Portfolio object, correction channel, public authority learning material, finance-readiness summary, or handoff-awareness summary;
3. low-bandwidth format, including text-first page, compressed PDF, accessible HTML, static image with alt text, lightweight dashboard summary, downloadable packet, printable packet, local mirror, offline form, messaging summary, audio summary, transcript, or facilitator kit;
4. safeguard controls, including public-safe review, protected knowledge exclusion, data minimization, geospatial masking, youth safeguard, humanitarian sensitivity, Indigenous protocol control where applicable, accessibility review, and correction instructions;
5. version and synchronization controls, including version number, date, steward, expiry, update cadence, correction channel, recall notice, archive status, non-current warning, and synchronization with national repository or Registry status where applicable;
6. boundary notices, confirming that low-bandwidth localization does not reduce safeguards, expand permissions, create public authority approval, imply consent, authorize deployment, or execute implementation.
Low-bandwidth localization prevents Nexus from excluding communities and public authorities whose realities are not high-bandwidth.
### 21.2.9 Offline Localization
Offline localization is the localization class through which Nexus materials are packaged, versioned, translated, accessibility-adapted, safeguarded, and distributed for use without continuous internet access. Offline localization may support communities, classrooms, field teams, public authority learners, humanitarian-sensitive contexts, National Nodes, Academy cohorts, Campaign teams, Nexus Universe continuation, DRI learning, Observatory learning, Studio summary use, safeguard review, public-safe reporting, and handoff-awareness learning.
Offline localization requires strict version control because offline materials can outlive corrections. Every offline localized package must carry version number, release date, steward, language, access class, public-safe status, correction channel, recall instructions, archive status, non-current notice, and use limits.
An Offline Localization Record should identify:
1. offline package class, including community packet, Academy packet, Risk Academy packet, Campaign packet, public authority learning packet, DRI packet, Observatory packet, National Portfolio packet, Nexus Universe packet, readiness packet, safeguard packet, finance-readiness packet, donor-readiness packet, public finance learning packet, or handoff-awareness packet;
2. localized contents, including public-safe Reports, summaries, worksheets, learning modules, diagrams, captions, transcripts, alt text, forms, correction instructions, contact information, Registry status extract, Marketplace extract, DRI summary, Observatory summary, Studio summary, National Portfolio summary, or handoff dependency summary;
3. language, accessibility, and cultural controls, including national language, local language, plain-language version, screen-reader-compatible file where relevant, large-print version, captions or transcripts where relevant, cultural localization, community-safe language, Indigenous protocol controls where applicable, and humanitarian sensitivity controls;
4. use and access class, including public, controlled-public, participant-only, community-review-only, public authority learning-only, youth-safe, secure-room-derived summary, data-room-derived summary, protected knowledge excluded, restricted, archive-only, or deletion-required;
5. version and correction controls, including version number, date, steward, expiry or refresh date, correction channel, recall notice, supersession notice, archive rule, non-current warning, and downstream update method;
6. boundary notices, confirming that offline localization 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 localization extends access while preventing old or uncontrolled materials from becoming false authority.
### 21.2.10 Community-Safe Localization
Community-safe localization is the localization class through which Nexus adapts national and local digital public goods to protect community dignity, local context, lived-risk knowledge, language nuance, accessibility, youth safeguards, disability inclusion, humanitarian sensitivity, protected knowledge, community-sensitive locations, Indigenous protocols where applicable, public-safe communication, consent boundaries, public authority boundaries, donor boundaries, finance and insurance boundaries, and correction pathways.
Community-safe localization is required wherever a digital public good, Report, Campaign, DRI output, Observatory summary, Studio workflow, Academy pathway, Marketplace listing, Registry record, National Portfolio object, Nexus Universe material, finance-readiness record, public authority learning record, donor-readiness record, public finance relevance record, or handoff dependency note may affect how a community is seen, described, engaged, supported, routed, or represented.
A Community-Safe Localization Record should identify:
1. community context, including place, community, local institution, civil society pathway, youth pathway, disability inclusion context, language context, humanitarian context, public authority context, Indigenous protocol context where applicable, protected knowledge context, and local risk context;
2. localized object, including Report, Campaign material, public-safe story, dashboard, DRI output, Observatory summary, Studio workflow, Academy material, National Portfolio object, Nexus Universe material, Marketplace listing, Registry record, Grid input, finance-readiness material, public authority learning material, donor-readiness material, public finance learning material, or handoff note;
3. community-safety controls, including non-stigmatizing language, no ranking by implication, no aid-prioritization overclaim, no donor-priority overclaim, no public authority overclaim, no consent overclaim, geospatial masking, protected knowledge restriction, attribution review, image review, translation review, accessibility review, youth safeguard, humanitarian sensitivity review, and correction channel;
4. participation and consent controls, including participation-not-consent, display-not-endorsement, public-safe-summary-not-full-disclosure, data-not-open, AI-use-not-implied, map-not-permission, accessibility-format-not-new-license, and handoff-note-not-authorization;
5. review and correction, including community review where appropriate, Indigenous governance review where applicable, public-safe review, safeguard review, legal boundary review, media-safe review, correction, withdrawal, recall, archive, or non-continuation;
6. boundary notices, confirming that community-safe localization is not community endorsement, Indigenous consent where applicable, public authority approval, donor commitment, aid prioritization, procurement approval, deployment authorization, or execution.
Community-safe localization is the final test of whether national digital public goods are genuinely public-good objects rather than externally imposed artifacts.
The final Localization Classes rule is: localization includes language translation, legal-context localization, public authority terminology localization, technical localization, data localization, cultural localization, accessibility localization, low-bandwidth localization, offline localization, and community-safe localization. Localization makes Nexus digital public goods nationally usable, locally intelligible, legally bounded, technically fit, data-sovereign, culturally safe, accessible, low-bandwidth-ready, offline-capable, and community-safe; it never creates national policy, public authority approval, procurement approval, public finance allocation, financeability, insurability, donor commitment, community or Indigenous consent, deployment authorization, or execution by implication.
## 21.3 National Portfolio Object Classes
### 21.3.1 National Data Objects
National data objects are the data, metadata, datasets, data dictionaries, codebooks, schemas, pipelines, feature sets, benchmark datasets, DRI datasets, Observatory datasets, Studio datasets, Campaign datasets, Academy datasets, Registry-linked datasets, Marketplace-linked datasets, Grid inputs, public authority learning datasets, safeguard datasets, finance-readiness datasets, public finance relevance datasets, support records, correction records, archive records, and handoff-context datasets that are created, localized, mirrored, governed, reviewed, displayed, corrected, or archived within a national Nexus context.
National data objects shall be governed as national digital public goods only where their source, stewardship, data-use label, AI-use label, sensitivity class, public-safe status, localization status, data sovereignty context, cross-border status, privacy status, cyber status, protected knowledge status, Indigenous protocol status where applicable, public authority boundary status, finance and insurance boundary status, correction pathway, archive rule, and handoff dependency status have been recorded.
A National Data Object Record should identify:
1. object class, including raw data, processed data, public-safe data, aggregated data, synthetic data, metadata-only record, data dictionary, codebook, schema, pipeline, feature set, benchmark dataset, DRI dataset, Observatory dataset, Studio dataset, National Portfolio dataset, Campaign dataset, Academy dataset, Registry dataset, Marketplace dataset, Grid dataset, support dataset, public authority learning dataset, finance-readiness dataset, safeguard dataset, correction dataset, archive dataset, or handoff-context dataset;
2. national stewardship, including country, National Node, National Nexus Consortium pathway, data steward, public-safe steward, cyber steward, privacy steward, safeguard steward, community steward where applicable, Indigenous data steward where applicable, public authority learner context where applicable, and archive steward;
3. data status, including source, provenance, lineage, version, rights basis, access class, public-safe class, sensitivity class, data-use label, AI-use label, quality status, confidence status where applicable, uncertainty status where applicable, correction status, and archive status;
4. national controls, including data minimization, purpose limitation, national repository routing, national mirror routing, secure-room handling, data-room handling, compute-to-data handling, cross-border transfer review, data localization, encryption, logging, retention, deletion, sealing, geospatial masking, and protected knowledge restrictions;
5. routing and use, including DRI input, Observatory input, Studio input, Report input, Campaign input, Academy input, Registry status, Marketplace listing, Grid review, Nexus Universe routing, public authority learning, finance-readiness review, donor-readiness review, public finance learning, safeguard review, handoff dependency note, correction, archive, or non-continuation;
6. boundary notices, confirming that a national data object is not open data by default, not data ownership transfer, not AI-use permission by default, not public authority record status by default, not procurement approval, not financeability, not insurability, not donor commitment, not public finance allocation, not community consent, not Indigenous consent where applicable, not deployment authorization, and not execution.
National data objects are the factual substrate of national Nexus work. Their value depends on provenance, limits, sovereignty, safeguards, and correctionability as much as on content.
### 21.3.2 National Software Objects
National software objects are the repositories, libraries, services, applications, dashboards, APIs, SDKs, connectors, adapters, command-line tools, notebooks, templates, infrastructure-as-code, test suites, reference implementations, public-good software components, open technical baselines, documentation objects, support objects, release objects, SBOM records, vulnerability records, correction records, deprecation records, and archive records that are created, localized, mirrored, forked, reviewed, supported, listed, registered, routed, or archived for a national Nexus context.
A national software object may support public-good workflows, Academy learning, Campaign mobilization, DRI interpretation, Observatory methods, Studio workflows, National Portfolio preparation, Nexus Universe outputs, Registry status truth, Marketplace discovery, Grid and TRL review, public authority learning, finance-readiness readability, and lawful handoff context. It shall not imply production approval, security certification, procurement readiness, public authority approval, deployment authorization, or execution.
A National Software Object Record should identify:
1. software class, including repository, library, service, application, dashboard, API, SDK, connector, adapter, command-line tool, notebook, template, infrastructure-as-code, test suite, reference implementation, public-good software object, open technical baseline, localization fork, national mirror, support package, release package, or archive package;
2. national technical context, including country, National Node, national repository, national mirror, technical steward, maintainer, support class, localization status, language status, accessibility status, cybersecurity context, data sovereignty context, hosting context, API context, dependency context, and lawful handoff context;
3. release governance, including license class, contribution model, maintainer assignment, code of conduct, contribution terms, dependency review, security review, secret scanning, SBOM record, vulnerability disclosure pathway, test coverage, accessibility review, documentation review, reproducibility review, release classification, release notes, correction pathway, deprecation pathway, and archive rule;
4. national routing, including National Portfolio object, Academy object, Campaign object, DRI workflow, Observatory workflow, Studio workflow, Report workflow, Registry update, Marketplace listing, Grid input, TRL context, Nexus Universe output, public authority learning use, finance-readiness context, handoff dependency note, correction, archive, or non-continuation;
5. support and limitation status, including supported, unsupported, unsupported-by-design, time-limited support, community-supported, maintainer-supported, National Node-supported, vendor-independent, provider-contributed, deprecated, suspended, withdrawn, recalled, archived, or non-continuing;
6. boundary notices, confirming that national software object availability is not warranty, not production approval, not deployment authorization, not security certification, not procurement approval, not provider validation, not public authority approval, not financeability, not insurability, not donor commitment, not public finance allocation, not consent, and not execution.
National software objects make national digital public goods operationally reusable as learning and public-good infrastructure while preserving the public-good firewall and non-execution boundary.
### 21.3.3 National Dashboard Objects
National dashboard objects are national or localized visualization, monitoring-support, learning, reporting, status, DRI, Observatory, Campaign, National Portfolio, Marketplace, Registry, Grid, Studio, public authority learning, finance-readiness, public finance relevance, safeguard, correction, and archive dashboards that display national Nexus records under governed access, interpretation, public-safe, accessibility, and boundary controls.
A national dashboard object is not a decision system. It may display indicators, records, trends, questions, status labels, public-safe summaries, lifecycle states, support classes, correction states, Registry status, Marketplace discovery, Grid inputs, TRL context, and readiness questions. It shall not be treated as public warning, official statistics by default, public authority decision, procurement instruction, finance signal, insurance score, donor priority, public finance allocation, consent record, deployment authorization, or execution instruction.
A National Dashboard Object Record should identify:
1. dashboard class, including National Portfolio dashboard, DRI dashboard, Observatory dashboard, WFEH-B dashboard, DRR dashboard, DRF literacy dashboard, Campaign dashboard, Academy dashboard, Studio dashboard, Registry dashboard, Marketplace dashboard, Grid dashboard, TRL context dashboard, public authority learning dashboard, finance-readiness dashboard, safeguard dashboard, correction dashboard, or archive dashboard;
2. data and record basis, including source records, datasets, metadata, data-use labels, AI-use labels, confidence labels, uncertainty labels, public-safe status, review status, sensitivity class, localization status, accessibility status, correction status, and archive status;
3. national display controls, including language access, plain-language summary, screen-reader compatibility, alt text, captions where relevant, low-bandwidth version, mobile-first design, offline summary, geospatial masking, non-ranking design, no-risk-score-by-implication controls, public-safe labels, limitation display, and correction display;
4. access class, including public, controlled-public, National Node-visible, public authority learning-only, community-review-only, secure-room-only, data-room-only, protected knowledge room-only, readiness-room-only, handoff-recipient-only, archive-only, sealed, or deletion-required;
5. interpretation controls, including dashboard-not-decision, dashboard-not-warning, dashboard-not-rating, dashboard-not-official-statistics-by-default, dashboard-not-procurement, dashboard-not-finance, dashboard-not-insurance, dashboard-not-public-finance-allocation, dashboard-not-consent, dashboard-not-deployment, and dashboard-not-execution;
6. boundary notices, confirming that a national dashboard object supports learning and visualization only and does not create public authority action, official warning, official statistics, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
National dashboard objects make national Nexus status visible without making visibility decisive.
### 21.3.4 National DRI Objects
National DRI objects are national Disaster Risk Intelligence indicators, signal records, confidence labels, uncertainty labels, public-safe intelligence summaries, dashboard records, hotspot records, multi-hazard records, cascade records, WFEH-B risk records, national DRI contributions, Observatory-linked records, Studio-linked records, Reports-linked records, Campaign-linked records, public authority learning records, correction records, and archive records that support national risk literacy and public-good evidence formation.
National DRI objects shall preserve the DRI boundary discipline: intelligence is not warning; indicator is not rating; dashboard is not decision; scenario is not forecast certainty; Observatory signal is not surveillance authority; GRIx category is not legal classification; DRI output is not insurance score, investment signal, procurement priority, public authority action, consent, deployment authorization, or execution.
A National DRI Object Record should identify:
1. DRI object class, including indicator record, signal record, confidence label, uncertainty label, public-safe intelligence summary, dashboard record, hotspot record, multi-hazard record, cascade record, WFEH-B record, protection-gap input, risk-layering input, National DRI contribution, Observatory-linked record, Studio-linked record, Report-linked record, Campaign-linked record, correction record, or archive record;
2. national risk context, including country, National Node, National Portfolio relationship, WFEH-B context, DRR context, DRF literacy context, public authority learning context, community safeguard context, humanitarian sensitivity context, geospatial sensitivity context, infrastructure sensitivity context, and cross-border context where applicable;
3. evidence and data status, including data source, lineage, method status, public-safe status, sensitivity class, confidence label, uncertainty label, geospatial limits, temporal limits, data-use label, AI-use label, review status, correction status, and archive status;
4. routing pathways, including DRI improvement, Observatory need, Studio scenario, Report input, Campaign input, Academy module, Risk Academy module, National Portfolio update, Nexus Universe arena, Public Authority Learning Room, Insurance-Reader Room, Public Finance Learning Room, safeguard review, handoff dependency note, correction, archive, or non-continuation;
5. public-safe controls, including aggregation, anonymization, geospatial masking, protected knowledge restrictions, community sensitivity review, Indigenous protocol review where applicable, humanitarian sensitivity review, public warning boundary review, public authority boundary review, finance and insurance boundary review, and correction review;
6. boundary notices, confirming that National DRI objects are not public warnings, emergency commands, legal classifications, official statistics by default, insurance scores, investment signals, procurement priorities, public authority decisions, consent records, deployment authorizations, or execution instructions.
National DRI objects give national risk intelligence structure without converting intelligence into authority.
### 21.3.5 National Campaign Objects
National Campaign objects are the national Campaign records, pages, signature tools, pledge tools, support tools where lawful, volunteer tools, team records, chapter records, ambassador records, quest records, bounty records, dashboards, public-safe stories, public reports, support ledgers, correction channels, Campaign intake records, purpose records, public-safe records, support records, volunteer records, signature records, pledge records, DICE contribution records, DRI contribution records, Working Group formation records, Competence Cell formation records, Universe routing records, correction records, and archive records created or localized for national Nexus mobilization.
National Campaign objects mobilize public-good participation, learning, support, evidence, DRI inputs, Observatory needs, Academy pathways, Foundry pathways, National Portfolio activation, Nexus Universe preparation, and lawful handoff awareness. They shall not create mandate, endorsement, public authority approval, procurement status, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution by implication.
A National Campaign Object Record should identify:
1. Campaign object class, including Campaign page, Campaign intake record, purpose record, public-safe record, signature tool, pledge tool, support tool where lawful, volunteer tool, team record, chapter record, ambassador record, quest, bounty, dashboard, public-safe story, Report input, support ledger, DICE contribution record, DRI contribution record, Working Group formation record, Competence Cell formation record, Nexus Universe routing record, correction record, or archive record;
2. national campaign context, including country, National Node, National Portfolio relationship, National Council or Helix Council pathway where applicable, WFEH-B context, DRR context, DRI context, Academy context, Foundry context, Nexus Universe context, community safeguard context, language context, accessibility context, and public authority boundary context;
3. governance controls, including Campaign readiness level, claims freeze, data freeze, technical freeze, support controls, sponsor controls, provider controls, public authority boundary controls, community consent boundary controls, trust and safety controls, fraud controls, stop-the-line controls, correction channel, and archive rule;
4. participation and support records, including community participation record, youth safeguard record, accessibility record, volunteer record, support record, sponsor support record, provider contribution record, public-safe story record, signature record, pledge record, contribution record, learning record, proof receipt where applicable, iCRS entry where appropriate, ILA entry where appropriate, and consent boundary record;
5. routing pathways, including National Portfolio update, Academy pathway, Risk Academy pathway, Foundry backlog item, Studio workflow, Report input, DRI improvement, Observatory need, Registry update, Marketplace listing, Grid input, Nexus Universe arena, public authority learning room, readiness room, handoff dependency note, correction, archive, or non-continuation;
6. boundary notices, confirming that national Campaign objects do not create public mandate, endorsement, public authority action, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
National Campaign objects convert public mobilization into national public-good records without converting visibility into authority.
### 21.3.6 National Academy Objects
National Academy objects are national or localized learning objects, Academy modules, Risk Academy modules, competency objects, curriculum objects, course records, micro-learning objects, WILP records, simulation exercises, Studio learning exercises, public authority learning materials, DRI interpretation exercises, Observatory learning materials, Campaign learning materials, Foundry learning materials, micro-credential inputs, badge inputs, proof receipts, ILA-linked records, iCRS-linked records, accessibility packages, translation packages, correction records, and archive records created or localized for national Nexus capability formation.
National Academy objects support national skills, public-good literacy, risk literacy, digital public goods literacy, AI and data literacy, cyber literacy, public authority learning, DRF literacy, safeguard literacy, Campaign participation, Foundry contribution, Nexus Universe preparation, and lawful handoff context. They shall not create professional licensing, employment guarantee, immigration status, procurement qualification, public authority status, financeability, insurability, deployment authorization, or execution authority by implication.
A National Academy Object Record should identify:
1. learning object class, including Academy module, Risk Academy module, learning pathway, curriculum object, competency object, competency evidence object, WILP record, apprenticeship or practicum learning record where applicable, Studio exercise, DRI exercise, Observatory exercise, public authority learning material, Campaign learning material, Foundry learning material, micro-credential input, badge input, proof receipt, ILA record, iCRS record, accessibility package, translation package, correction record, or archive record;
2. national competence context, including country, National Node, SCF pathway, labor-market context, language context, accessibility context, youth safeguard context, disability inclusion context, public authority learning context, WFEH-B context, DRR context, DRF literacy context, DRI context, Foundry context, Campaign context, and Nexus Universe context;
3. evidence and recognition status, including learning objective, competency family, evidence requirement, assessment or review status, proof receipt status, ILA linkage, iCRS linkage, micro-credential status where applicable, badge status where applicable, recognition boundary, correction status, and archive status;
4. safeguard and labor controls, including youth safeguards, no disguised labor, no employment by implication, accessibility review, plain-language review, language access, community safeguard review, Indigenous protocol review where applicable, data-use labels, AI-use labels, privacy, and correction channel;
5. routing pathways, including Academy cohort, Risk Academy cohort, Campaign pathway, Foundry pathway, BuildGrid quest or bounty, Competence Cell, Working Group, Studio workflow, Report input, National Portfolio update, Nexus Universe arena, Registry record, Marketplace discovery, Grid input, lawful handoff context, correction, archive, or non-continuation;
6. boundary notices, confirming that National Academy objects are learning and competency records only and do not create professional licensure, employment, public authority approval, procurement qualification, immigration status, financeability, insurability, donor commitment, public finance allocation, consent, deployment authorization, or execution.
National Academy objects build national capability while preserving the difference between learning evidence and formal authority.
### 21.3.7 National Reports Objects
National Reports objects are national or localized Reports, public-safe summaries, controlled Reports, National Portfolio Reports, WFEH-B Reports, DRR Reports, DRF literacy Reports, DRI Reports, public authority learning summaries, readiness room summaries, Foundry Reports, Labs Reports, Academy Reports, Campaign Reports, Marketplace and Registry Reports, Studio Reports, safeguard Reports, finance-readiness summaries, public finance learning summaries, handoff dependency Reports, correction Reports, archive Reports, translation records, accessibility records, and release records.
National Reports objects make national Nexus learning, evidence, public-safe summaries, readiness questions, safeguard conditions, public authority learning, finance-readiness, support needs, correction, and archive intelligible to the intended audience. They shall not become official national policy, public warning, official statistics by default, procurement recommendation, finance signal, insurance score, donor commitment, public finance allocation, consent record, deployment authorization, or execution instruction.
A National Reports Object Record should identify:
1. Report class, including national public Report, controlled Report, National Portfolio Report, WFEH-B Report, DRR Report, DRF literacy Report, DRI Report, public authority learning summary, readiness room summary, Foundry Report, Labs Report, Academy Report, Campaign Report, Marketplace and Registry Report, Studio Report, safeguard Report, correction Report, archive Report, or handoff dependency Report;
2. source records, including Arena Records, Participation Records, Core Build Records, Public Authority Learning Records, Readiness Question Records, Support Records, Marketplace Listings, Registry Updates, Campaign Updates, Foundry Continuation Records, National Portfolio Updates, DRI records, Observatory records, Studio records, finance-readiness records, safeguard records, correction records, and archive records;
3. review status, including evidence review, data review, AI review, cyber review, privacy review, method review, geospatial review, public-safe review, accessibility review, language review, community review where appropriate, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, donor boundary review, legal boundary review, handoff review, correction review, and archive status;
4. release class, including public, controlled-public, National Node-visible, public authority learning-only, capital-reader room-visible, insurance-reader room-visible, donor-reader room-visible, public finance learning-only, community-review-only, secure-room summary, data-room summary, protected knowledge room summary, handoff-context-visible, restricted, archive-only, or non-current;
5. correction and archive controls, including errata, addendum, clarification, correction notice, public repair, withdrawal, recall, supersession, archive, non-current notice, successor Report, translation correction, accessibility correction, Registry update, Marketplace update, and handoff note update;
6. boundary notices, confirming that National Reports objects are not official policy, not public warning, not official statistics by default, not certification, not procurement recommendation, not financeability, not insurability, not donor commitment, not public finance allocation, not public authority decision, not consent, not deployment authorization, and not execution.
National Reports objects communicate national Nexus work only to the extent that communication is accurate, public-safe, accessible, bounded, and correctable.
### 21.3.8 National Studio Objects
National Studio objects are national or localized dashboards, simulations, digital twins, scenario workflows, AI workflows, compute-to-data workflows, secure-room workflows, data-room workflows, public authority learning workflows, readiness workflows, finance-readiness workflows, insurance-readiness workflows, donor-readiness workflows, public finance learning workflows, National Portfolio workflows, Nexus Universe demonstrations, handoff-awareness demonstrations, model cards, system cards, benchmark cards, agent workflow cards, limitation notes, correction records, and archive records.
National Studio objects allow national actors to learn from complex systems, test assumptions, visualize dependencies, interpret DRI, examine Observatory signals, understand WFEH-B cascades, explore public authority learning questions, form finance-readiness questions, review safeguards, and clarify handoff dependencies. They shall not operate, command, deploy, procure, finance, insure, allocate, consent, or execute.
A National Studio Object Record should identify:
1. Studio object class, including dashboard, simulation, digital twin, scenario workflow, AI workflow, retrieval workflow, compute-to-data workflow, secure-room workflow, data-room workflow, public authority learning workflow, readiness workflow, National Portfolio workflow, Nexus Universe demonstration, handoff-awareness demonstration, model card, system card, benchmark card, agent workflow card, limitation note, correction record, or archive record;
2. national input objects, including datasets, metadata, DRI indicators, Observatory signals, National Portfolio objects, Campaign inputs, Reports, Grid inputs, TRL records, Registry records, Marketplace listings, public authority learning questions, finance-readiness records, safeguard records, and handoff dependency notes;
3. runtime controls, including access control, data-use labels, AI-use labels, no-download, no-write-back, no-command, human-in-the-loop, human-on-the-loop, output review, logging, prompt-injection controls, tool-permission controls, kill-switch conditions, secure-room controls, data-room controls, protected knowledge controls, and room archive;
4. review controls, including data review, model review, AI review, cyber review, privacy review, geospatial review, public-safe review, accessibility review, safeguard review, public authority boundary review, finance and insurance boundary review, donor boundary review, public finance boundary review, legal boundary review, handoff review, correction review, and archive review;
5. outputs and routing, including learning record, dashboard note, limitation note, scenario record, public-safe summary, readiness question, public authority learning record, finance-readiness question, insurance-readiness question, donor-readiness question, public finance learning question, National Portfolio update, Report input, Registry update, Marketplace listing, Grid input, handoff dependency note, correction, archive, or non-continuation;
6. boundary notices, confirming that National Studio objects are not operational command, not public warning, not public authority decision, not procurement decision, not finance decision, not insurance decision, not donor commitment, not public finance allocation, not consent record, not handoff approval, not deployment authorization, and not execution.
National Studio objects help national systems learn safely by demonstrating, simulating, and reviewing without operating.
### 21.3.9 National Marketplace Objects
National Marketplace objects are national or localized Marketplace listings, discovery records, support-discovery records, learning-discovery records, contribution-discovery records, demand-signal records, Campaign listings, Academy listings, Foundry listings, Studio listings, Reports listings, DRI listings, Observatory listings, Registry-linked listings, Grid-linked listings, National Portfolio listings, Nexus Universe listings, public authority learning-visible listings, finance-readiness-visible listings, donor-reader-visible listings, public finance learning-visible listings, correction records, delisting records, and archive records.
National Marketplace objects make selected national digital public goods discoverable under governed listing rules. Discovery is not procurement. Listing is not endorsement. Support visibility is not donor commitment. Provider contribution is not provider validation. Registry linkage is not certification. Grid or TRL context is not financeability, insurability, procurement approval, public authority approval, deployment authorization, or execution.
A National Marketplace Object Record should identify:
1. listing class, including public-good discovery, support discovery, learning discovery, contribution discovery, demand-signal discovery, Campaign discovery, Academy discovery, Foundry discovery, Studio discovery, Reports discovery, DRI discovery, Observatory discovery, National Portfolio discovery, Nexus Universe discovery, handoff-awareness discovery, or archive discovery;
2. listed object, including software, dataset, metadata, model, API, dashboard, Report, learning object, Campaign object, Studio workflow, DRI output, Observatory output, Grid input, TRL context, National Portfolio object, Nexus Universe output, support opportunity, contribution opportunity, readiness question, safeguard record, or handoff-awareness object;
3. display controls, including public, controlled-public, National Node-visible, community-review-only, public authority learning-only, capital-reader room-visible, insurance-reader room-visible, donor-reader room-visible, public finance learning-only, secure-room-only, data-room-only, protected knowledge room-only, restricted, archive-only, or non-current;
4. review status, including public-safe review, data review, AI review, cyber review, privacy review, safeguard review, accessibility review, language review, community review where appropriate, Indigenous protocol review where applicable, Registry review, Marketplace review, Grid review, handoff review, correction review, and archive review;
5. correction and delisting controls, including wording correction, listing correction, support-status correction, provider-claim correction, sponsor-claim correction, public authority overclaim correction, consent overclaim correction, handoff-awareness correction, delisting, suspension, withdrawal, recall, archive, and non-continuation;
6. boundary notices, confirming that National Marketplace objects are discovery records only and do not create procurement, endorsement, vendor validation, certification, financeability, insurability, donor commitment, public finance allocation, public authority approval, consent, deployment authorization, or execution.
National Marketplace objects make national public-good objects findable without making them selected.
### 21.3.10 National Handoff Objects
National handoff objects are the dependency-aware records, notes, packages, summaries, registers, checklists, recipient responsibility notices, correction propagation notices, archive notices, and controlled-room outputs that identify what must be reviewed by separate competent actors before any national Nexus digital public good, National Portfolio object, Report, dataset, software, model, dashboard, Studio workflow, DRI output, Observatory output, Campaign output, Academy object, Foundry build, Registry record, Marketplace listing, Grid or TRL record, finance-readiness record, safeguard record, public authority learning record, or Nexus Universe output could be considered for downstream use.
A national handoff object is not handoff approval. It is a dependency map. It may identify recipients, dependencies, limitations, assumptions, safeguards, public authority conditions, procurement conditions, finance conditions, insurance conditions, donor conditions, public finance conditions, consent conditions, data conditions, AI conditions, cyber conditions, operational conditions, maintenance conditions, liability conditions, correction conditions, recall conditions, archive conditions, and non-continuation conditions. It shall not authorize deployment or execution.
A National Handoff Object Record should identify:
1. handoff object class, including Handoff Dependency Note, recipient responsibility notice, assumptions register extract, dependency register extract, diligence-gap register extract, public authority dependency record, finance-readiness record, safeguard dependency note, data dependency note, AI dependency note, cyber dependency note, public-safe summary, controlled handoff package, correction propagation notice, recall notice, archive notice, or non-continuation notice;
2. handoff candidate object, including National Portfolio object, Report, dataset, software, model, dashboard, Studio workflow, DRI output, Observatory output, Grid record, TRL record, Registry record, Marketplace record, Campaign output, Academy object, Foundry build, safeguard record, readiness room output, Nexus Universe output, or finance-readiness object;
3. recipient class, including National Consortium Company, Project SPV, public authority acting separately, provider, operator, contractor, host, university, lab, funder, insurer, donor, public finance actor, community actor where appropriate, Indigenous institution where applicable, or other lawful recipient;
4. dependency categories, including evidence, data, technical, software, AI, cyber, privacy, public-safe, public authority, procurement, finance, insurance, donor, public finance, safeguard, consent, legal, operational, enterprise, maintenance, liability, correction, recall, archive, and non-continuation dependencies;
5. anti-bypass and correction controls, including no National Node bypass, no National Portfolio bypass, no public authority dependency bypass, no data sovereignty bypass, no community safeguard bypass, no Indigenous protocol bypass where applicable, no procurement bypass, no finance or insurance bypass, no donor or public finance bypass, no correction bypass, correction propagation, withdrawal propagation, recall propagation, Registry update, Marketplace update, Grid update, National Portfolio update, and archive update;
6. boundary notices, confirming that National handoff objects are not handoff approval, not procurement approval, not financeability, not insurability, not donor commitment, not public finance allocation, not public authority action, not community consent, not Indigenous consent where applicable, not deployment authorization, not implementation authorization, and not execution.
National handoff objects allow Nexus records to travel toward lawful actors without carrying authority Nexus does not possess.
The final National Portfolio Object Classes rule is: National Portfolio object classes include national data objects, national software objects, national dashboard objects, national DRI objects, national Campaign objects, national Academy objects, national Reports objects, national Studio objects, national Marketplace objects, and national handoff objects. Together they form the national digital-public-good memory, discovery, learning, evidence, readiness, safeguard, correction, archive, and handoff layer of Nexus; they do not create national policy, procurement approval, public finance allocation, financeability, insurability, donor commitment, public authority action, community or Indigenous consent, deployment authorization, or execution by implication.
## 21.4 National Language and Metadata
### 21.4.1 Multilingual Metadata
Multilingual metadata is the national digital public-good control through which Nexus objects are described, indexed, discovered, reviewed, corrected, and archived in more than one language without losing provenance, status truth, boundary notices, access restrictions, data-use labels, AI-use labels, public-safe limits, safeguard conditions, public authority boundaries, finance-readiness boundaries, correction history, or archive meaning.
Multilingual metadata shall apply to national data objects, national software objects, national dashboard objects, national DRI objects, national Campaign objects, national Academy objects, national Reports objects, national Studio objects, national Marketplace objects, national handoff objects, National Portfolio records, Registry records, Marketplace listings, Grid and TRL records, Nexus Universe outputs, public authority learning records, finance-readiness records, donor-readiness records, public finance relevance records, safeguard records, correction records, and archive records.
A Multilingual Metadata Record should identify:
1. object identity, including object identifier, source title, localized title, language code, country context, National Node context, steward, version, lifecycle state, access class, support class, public-safe status, sensitivity class, correction status, and archive status;
2. metadata fields, including title, short description, object class, public-good purpose, keywords, GRIx categories where applicable, DRI categories where applicable, WFEH-B categories where applicable, data-use labels, AI-use labels, public authority boundary notices, finance-readiness notices, safeguard notices, license or use class, support class, and handoff restrictions;
3. language status, including source language, translated language, reviewed language, public-safe language, plain-language version, accessibility version, community-reviewed version where appropriate, Indigenous language version where applicable, public authority terminology version, and restricted-language version where applicable;
4. meaning controls, including no boundary loss, no consent overclaim, no public authority overclaim, no procurement overclaim, no finance or insurance overclaim, no donor or public finance overclaim, no legal equivalence by translation, no protected knowledge exposure, and no AI-use expansion through metadata;
5. display and discovery controls, including Registry display, Marketplace display, National Portfolio display, public authority learning display, public-safe display, controlled display, secure-room display, data-room display, protected knowledge room display, metadata-only display, archive-only display, or non-current display;
6. boundary notices, confirming that multilingual metadata improves discovery and understanding but does not create a new license, legal equivalence, publication permission, data-use permission, AI-use permission, public authority approval, procurement approval, community consent, Indigenous consent where applicable, deployment authorization, or execution.
Multilingual metadata is therefore not a translation convenience alone. It is the national discovery layer through which Nexus objects remain findable, bounded, safe, and correctable across languages.
### 21.4.2 Translation Records
Translation records are the records that document the translation, review, localization, limitation, correction, withdrawal, recall, archive, or non-continuation of Nexus materials across languages. They are required where a Nexus object is translated for national language access, public authority learning, community review, Academy use, Campaign use, Reports publication, Marketplace discovery, Registry display, Studio use, DRI interpretation, Observatory summary, finance-readiness review, donor-readiness review, public finance learning, safeguard review, Nexus Universe participation, or lawful handoff awareness.
A Translation Record should identify:
1. source object, including Report, public-safe summary, DRI output, Observatory summary, Studio workflow, Campaign material, Academy object, Registry record, Marketplace listing, National Portfolio object, Nexus Universe material, finance-readiness material, public authority learning material, safeguard record, correction channel, offline package, or handoff dependency note;
2. translation scope, including title, metadata, full text, summary, plain-language summary, public-safe summary, caption, transcript, alt text, glossary term, dashboard label, form field, legal notice, boundary notice, data-use label, AI-use label, or handoff notice;
3. translation pathway, including human translation, expert translation, technical translation, legal-boundary review, public authority terminology review, public-safe review, community review where appropriate, Indigenous protocol review where applicable, accessibility review, machine-assisted draft with human review, or machine translation prohibited;
4. review status, including draft, reviewed, approved for controlled use, approved for public-safe release, nationally localized, restricted, corrected, superseded, withdrawn, recalled, archived, or non-continuing;
5. limitation statement, including translation not legally equivalent, translation not official public authority text, translation not new license, translation not new consent, translation not new data-use permission, translation not AI-use permission, and translation subject to correction;
6. boundary notices, confirming that a Translation Record preserves language status and does not create legal advice, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, consent, deployment authorization, or execution.
Translation Records make language work auditable. They prevent translated materials from drifting away from the governing record.
### 21.4.3 Plain-Language Summaries
Plain-language summaries are national language and accessibility objects that explain Nexus materials in clear, usable, non-technical, non-extractive, public-safe language for communities, learners, public authority learners, youth participants, persons with disabilities, civil society actors, media-safe audiences, donors, public finance learners, capital readers, insurance readers, National Portfolio participants, Nexus Universe participants, and lawful handoff-context readers.
Plain-language summaries shall simplify wording without simplifying away uncertainty, limitations, safeguards, access restrictions, correction status, archive status, public authority boundaries, finance-readiness boundaries, consent boundaries, protected knowledge restrictions, or non-execution rules.
A National 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, public finance relevance record, or handoff dependency note;
2. audience and language, including national language, local language, accessibility language need, youth-friendly version, community-facing version, public authority learner version, media-safe version, low-literacy version, or plain-language translation status;
3. content requirements, including purpose, scope, what was reviewed, what is known, what is uncertain, what is restricted, what changed, what corrections exist, what the record does not mean, how to ask for correction, and where the governing record is held;
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 community consent, not Indigenous consent where applicable, not deployment authorization, and not execution;
5. review controls, including plain-language review, accessibility review, public-safe review, translation review, community review where appropriate, Indigenous protocol review where applicable, public authority boundary review, finance and insurance boundary review, donor boundary review, legal boundary review, correction review, and archive review;
6. boundary notices, confirming that plain-language summaries improve understanding but do not replace the governing record, create new permissions, expand access rights, alter legal meaning, or authorize downstream action.
Plain-language summaries make Nexus understandable without making it legally broader than the source record.
### 21.4.4 Public-Safe Summaries
Public-safe summaries are national language and metadata objects that communicate sensitive, technical, restricted, 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 material in a form that can be safely shared with the intended audience.
Public-safe summaries shall preserve public-good learning while removing or transforming unsafe details. They shall not be treated as full disclosure, raw data release, protected knowledge release, official public authority record, public warning, official policy, procurement document, finance document, insurance document, donor commitment, public finance allocation, consent record, deployment authorization, or execution instruction.
A National 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, community feedback, Campaign communication, Academy use, media-safe communication, public authority learning, 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, pseudonymization, geospatial masking, uncertainty language, limitation language, non-stigmatizing language, protected knowledge exclusion, 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. language and metadata controls, including national language, local terminology, multilingual metadata, plain-language availability, accessibility format, translation status, glossary linkage, correction channel, version, release class, and archive status;
5. review status, including public-safe review, data review, AI review, cyber review, privacy review, geospatial review, safeguard review, community review where appropriate, 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 review;
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 national language access without sacrificing protection.
### 21.4.5 Local Terminology Notes
Local terminology notes are national metadata records that explain how Nexus terms, public authority terms, risk terms, technical terms, data terms, AI terms, safeguard terms, finance-readiness terms, donor-readiness terms, public finance terms, procurement terms, community terms, Indigenous protocol terms where applicable, and handoff terms are used in the relevant national or local context.
Local terminology notes are required where a literal translation may mislead, overclaim authority, imply a legal status, erase local meaning, create public authority confusion, distort safeguard obligations, imply consent, misstate finance-readiness, or create deployment or execution overclaim.
A Local Terminology Note should identify:
1. term or phrase, including source Nexus term, local equivalent, national equivalent, public authority equivalent, technical equivalent, community-preferred term, prohibited term, restricted term, and plain-language explanation;
2. context of use, including Report, DRI output, Observatory summary, Studio workflow, Campaign material, Academy material, Registry record, Marketplace listing, National Portfolio object, Nexus Universe material, finance-readiness record, public authority learning record, safeguard record, public finance relevance record, or handoff dependency note;
3. meaning and limitation, including what the term means within Nexus, what it does not mean, whether it has legal significance, whether it has public authority sensitivity, whether it has cultural sensitivity, whether it has protected knowledge sensitivity, and whether it requires a boundary notice;
4. localization risk, including official-status confusion, legal equivalence confusion, policy overclaim, regulatory overclaim, warning overclaim, procurement overclaim, finance or insurance overclaim, donor overclaim, public finance overclaim, consent overclaim, community endorsement overclaim, deployment overclaim, or execution overclaim;
5. approved wording, including preferred term, permitted variants, prohibited variants, required notices, glossary linkage, plain-language wording, translation correction rule, and archive rule;
6. boundary notices, confirming that local terminology improves understanding and does not create legal equivalence, public authority approval, procurement approval, donor commitment, public finance allocation, consent, deployment authorization, or execution.
Local terminology notes are the guardrails that keep translated Nexus language from becoming legally or socially unsafe.
### 21.4.6 Translation Correction
Translation correction is the correction pathway for errors, ambiguities, omissions, overclaims, mistranslations, culturally unsafe wording, inaccessible translation formats, public authority terminology errors, finance-readiness errors, donor-readiness errors, public finance errors, consent-boundary errors, protected knowledge exposure, translation-induced legal confusion, translation-induced safeguard failure, or translation-induced handoff confusion.
A Translation Correction Record should identify:
1. affected translated object, including Report, public-safe summary, plain-language summary, DRI output, Observatory summary, Studio workflow, Campaign material, Academy object, Registry record, Marketplace listing, National Portfolio object, Nexus Universe material, finance-readiness material, public authority learning material, safeguard record, correction channel, offline package, local terminology note, glossary entry, or handoff dependency note;
2. correction issue, including mistranslation, missing boundary notice, incorrect public authority term, legal equivalence overclaim, procurement overclaim, public finance overclaim, finance or insurance overclaim, donor overclaim, consent overclaim, community endorsement overclaim, Indigenous protocol issue where applicable, protected knowledge exposure, accessibility issue, plain-language failure, or archive-status error;
3. severity and action, including monitor, correct, restrict, relabel, replace translation, withdraw translation, recall offline package, correct metadata, correct glossary, correct Marketplace listing, correct Registry record, notify affected readers where appropriate, public repair where required, archive, or mark non-continuing;
4. review pathway, including translator review, technical review, legal boundary review, public authority terminology review, public-safe review, accessibility review, community review where appropriate, Indigenous protocol review where applicable, finance and insurance boundary review, donor boundary review, correction review, and archive review;
5. downstream propagation, including updates to source object, translated object, metadata, National Glossary, Registry, Marketplace, Reports, Campaigns, Academy materials, Studio workflows, public authority learning materials, finance-readiness materials, offline packages, handoff notes, and archive records;
6. boundary notices, confirming that translation correction restores meaning and does not create new approval, license, consent, deployment authorization, or execution.
Translation correction is essential because mistranslation can become a boundary incident. Nexus translations must remain correctable across the full record chain.
### 21.4.7 National Glossary
National Glossary is the nationally localized controlled vocabulary for Nexus terms, institutional names, object classes, DPGF terms, NAF terms, SCF terms, DRI terms, GRIx categories, WFEH-B terms, DRR terms, DRF terms, Observatory terms, Studio terms, Campaign terms, Academy terms, Registry terms, Marketplace terms, Grid and TRL terms, finance-readiness terms, donor-readiness terms, public finance terms, public authority learning terms, safeguard terms, correction terms, archive terms, and handoff terms.
The National Glossary shall be governed as a living public-good metadata object. It shall preserve canonical definitions, local equivalents, plain-language explanations, public authority terminology notes, prohibited translations, restricted terms, boundary notices, correction history, and archive status.
A National Glossary Record should identify:
1. glossary scope, including country, National Node, language set, object families covered, institutional terms covered, risk terms covered, technical terms covered, public authority terms covered, safeguard terms covered, finance-readiness terms covered, and handoff terms covered;
2. term record fields, including canonical Nexus term, source definition, national-language equivalent, local-language equivalent, plain-language explanation, technical explanation where needed, public authority terminology note, usage examples, prohibited usage, boundary notices, related records, and correction history;
3. governance and stewardship, including glossary steward, translation steward, legal boundary reviewer, public authority terminology reviewer, public-safe reviewer, accessibility reviewer, community reviewer where appropriate, Indigenous protocol reviewer where applicable, technical reviewer, and archive steward;
4. status and versioning, including draft, reviewed, public-safe, controlled-public, national release, restricted, corrected, superseded, withdrawn, recalled, archived, or non-continuing;
5. integration pathways, including Registry metadata, Marketplace metadata, National Portfolio metadata, Reports, Academy materials, Campaign materials, Studio workflows, DRI records, Observatory summaries, public authority learning materials, finance-readiness materials, public finance learning materials, handoff notes, offline packages, and correction channels;
6. boundary notices, confirming that the National Glossary is a controlled vocabulary and explanatory instrument, not legal advice, official public authority terminology by default, public authority approval, procurement approval, consent, deployment authorization, or execution.
The National Glossary makes national Nexus language coherent, searchable, teachable, and correctable.
### 21.4.8 No Legal Equivalence by Translation
No legal equivalence by translation is the mandatory rule that a translated Nexus object, multilingual metadata field, local terminology note, plain-language summary, public-safe summary, National Glossary entry, caption, transcript, alt text, dashboard label, form field, offline package, Academy material, Campaign material, Report, public authority learning material, finance-readiness material, donor-readiness material, public finance learning material, or handoff dependency note shall not be treated as legally equivalent to the source text, legally operative in the same manner, legally authoritative, compliance-approved, officially adopted, public-authority-issued, procurement-ready, finance-ready, insurance-ready, donor-approved, public-finance-approved, consented, deployment-authorized, or execution-ready merely because it has been translated.
Where legal effect matters, the governing language, source record, legal instrument, adoption record, public authority record, contract, data agreement, license, consent record, or handoff record must be separately identified. Translation may assist understanding; it does not create legal status.
A No Legal Equivalence by Translation Record should identify:
1. translated material, including legal notice, policy-facing text, public authority-facing text, safeguard text, data-use label, AI-use label, license summary, finance-readiness notice, donor-readiness notice, public finance notice, Report, Registry record, Marketplace listing, National Portfolio object, Nexus Universe material, or handoff note;
2. governing source, including source language, source version, governing record, official repository, Registry record, legal instrument where applicable, adoption record where applicable, license record, data agreement, consent record, or handoff record;
3. translation limitation, including translation for convenience, translation for learning, translation for public-safe understanding, translation for accessibility, translation subject to correction, translation not legal advice, translation not official public authority text, and translation not controlling where source conflict exists unless separately recorded;
4. conflict rule, including source record prevails, governing language prevails, more protective safeguard prevails, more restrictive data-use label prevails, more restrictive AI-use label prevails, public authority record prevails where separately issued, legal instrument prevails where applicable, and correction required where inconsistency appears;
5. display controls, including required notice placement, source link where safe, version display, date display, correction channel, archive status, non-current notice, and limitation statement;
6. boundary notices, confirming that translation does not create legal equivalence, public authority approval, policy adoption, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
No legal equivalence by translation protects Nexus from allowing language access to become unintended legal effect.
The final National Language and Metadata rule is: national language and metadata require multilingual metadata, translation records, plain-language summaries, public-safe summaries, local terminology notes, translation correction, a National Glossary, and no-legal-equivalence-by-translation discipline. These controls make Nexus digital public goods discoverable, understandable, accessible, nationally usable, public-safe, and correctable across languages; they do not create new licenses, legal equivalence, public authority approval, procurement approval, public finance allocation, financeability, insurability, donor commitment, community or Indigenous consent, deployment authorization, or execution by implication.
## 21.5 National Data Sovereignty
### 21.5.1 National Data Classes
National data classes are the classifications through which Nexus determines how data, metadata, datasets, DRI objects, Observatory objects, Studio objects, Campaign objects, Academy records, Registry records, Marketplace records, Grid inputs, public authority learning records, safeguard records, finance-readiness records, public finance relevance records, support records, correction records, archive records, and handoff-context records may be collected, stored, processed, displayed, localized, transferred, corrected, sealed, archived, or handed off within a national context.
National data classification shall be applied before data is treated as open, public-safe, controlled, restricted, AI-usable, mappable, publishable, reusable, Marketplace-displayable, Registry-displayable, public-authority-learning-ready, finance-readiness-ready, donor-readiness-ready, public-finance-learning-ready, handoff-context-ready, or archive-ready. Classification is a sovereignty, safeguard, privacy, cybersecurity, public authority, and public-good legitimacy function.
A National Data Classification Record should identify:
1. data class, including open data, public-safe data, controlled public data, restricted data, public authority-sensitive data, community-sensitive data, Indigenous protocol-sensitive data where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, humanitarian-sensitive data, finance-sensitive data, insurance-sensitive data, donor-sensitive data, handoff-recipient-only data, archive-only data, sealed data, or deletion-required data;
2. data object, including raw data, processed data, aggregated data, synthetic data, metadata-only record, data dictionary, codebook, schema, pipeline, feature set, benchmark dataset, DRI dataset, Observatory dataset, National Portfolio dataset, Studio dataset, Campaign dataset, Registry dataset, Marketplace dataset, Grid dataset, learning record, support record, public authority learning record, finance-readiness record, safeguard record, correction record, archive record, or handoff data;
3. national context, including country, National Node, national repository, data steward, public-safe steward, privacy steward, cyber steward, community steward where applicable, Indigenous data steward where applicable, public authority learner context where applicable, and archive steward;
4. use and access labels, including access class, data-use label, AI-use label, public-safe status, sensitivity class, localization status, cross-border status, compute-to-data status, secure-room status, data-room status, protected knowledge status, correction status, retention status, and archive status;
5. control requirements, including minimization, purpose limitation, rights review, consent or permission review where required, localization review, cross-border review, encryption, logging, access control, geospatial masking, output review, public-safe transformation, sealing, deletion where required, correction, and archive;
6. boundary notices, confirming that national data classification is not open data release, data ownership transfer, AI-use permission, public authority record status, finance or insurance permission, donor-use permission, public finance allocation, community consent, Indigenous consent where applicable, handoff authorization, deployment authorization, or execution.
National data classes are the first line of sovereignty discipline. They determine whether data can travel, be seen, be summarized, be computed on, or remain sealed.
### 21.5.2 Data Localization
Data localization is the national data sovereignty control requiring certain national data objects to be stored, mirrored, processed, reviewed, accessed, summarized, archived, or retained within a national or nationally approved environment where law, public authority sensitivity, public-good legitimacy, community safeguards, Indigenous data sovereignty considerations where applicable, privacy, cybersecurity, public-safe reporting, or handoff restrictions require such treatment.
Data localization may apply to National Portfolio datasets, DRI datasets, Observatory datasets, Studio datasets, Campaign datasets, Academy records, Registry records, Marketplace records, Grid records, public authority learning records, community data, health-sensitive data, youth data, geospatial-sensitive data, infrastructure-sensitive data, cyber-sensitive data, protected knowledge, finance-readiness records, donor-readiness records, public finance relevance records, support records, correction records, and archives.
A Data Localization Record should identify:
1. localized data object, including dataset, metadata, pipeline, feature set, model input, dashboard source, DRI record, Observatory record, Studio input, Campaign record, Academy record, Registry record, Marketplace record, Grid input, public authority learning record, safeguard record, finance-readiness record, public finance record, support record, handoff note, correction record, or archive record;
2. localization basis, including national law, national data policy, public authority sensitivity, data sovereignty, privacy, cybersecurity, protected knowledge status, Indigenous data sovereignty where applicable, community safeguard, public-safe restriction, cross-border limitation, secure-room requirement, data-room requirement, compute-to-data requirement, or handoff-recipient restriction;
3. national storage and processing environment, including national repository, national mirror, sovereign cloud where applicable, national data room, secure room, compute-to-data environment, National Node repository, public authority learning environment, protected knowledge room, sealed archive, or deletion-required pathway;
4. processing controls, including purpose limitation, access control, encryption, logging, no-download controls, approved users, approved workloads, output review, AI-use controls, geospatial masking, retention, correction, withdrawal, recall, sealing, deletion where required, and archive classification;
5. synchronization controls, including upstream source relationship, national mirror status, version status, correction propagation, withdrawal propagation, recall propagation, Registry update, Marketplace update, Grid update, National Portfolio update, archive update, and non-current notices;
6. boundary notices, confirming that data localization is not public authority approval, open data release, data ownership transfer, AI-use permission, procurement approval, financeability, insurability, donor commitment, public finance allocation, consent, handoff authorization, deployment authorization, or execution.
Data localization ensures that national data remains governed by national conditions rather than being made globally portable by default.
### 21.5.3 Cross-Border Controls
Cross-border controls are the national data sovereignty rules governing whether, how, when, by whom, and under what safeguards national data objects may be transferred, mirrored, accessed, processed, summarized, published, computed on, indexed, modelled, archived, or handed off across borders. Cross-border controls apply to data movement, remote access, cloud hosting, API access, repository synchronization, AI processing, model training, metadata exposure, public-safe summaries, secure-room outputs, data-room outputs, and handoff-context records.
Cross-border controls shall be applied before national data is routed to global repositories, regional repositories, cross-border public institutions, external providers, public authorities in another jurisdiction, capital readers, insurers, donors, public finance actors, universities, labs, National Consortium Companies, Project SPVs, or other lawful recipients outside the national data context.
A Cross-Border Control Record should identify:
1. data object subject to cross-border review, including raw data, processed data, aggregated data, metadata, DRI dataset, Observatory dataset, Studio dataset, Campaign dataset, Academy record, Registry record, Marketplace record, Grid input, public authority learning record, safeguard record, finance-readiness record, support record, handoff dependency note, correction record, or archive record;
2. cross-border action, including transfer, mirror, remote access, API access, model access, AI processing, compute-to-data output review, public-safe publication, repository synchronization, cloud hosting, regional routing, global routing, handoff routing, or archive routing;
3. jurisdictional context, including source country, destination country, regional context, National Node, national steward, receiving steward, public authority sensitivity, community sensitivity, Indigenous data sovereignty where applicable, protected knowledge status, data localization requirement, conflict-of-law issue, and applicable restriction;
4. allowed transfer status, including prohibited, pending review, public-safe summary only, metadata-only, aggregated only, anonymized only, secure-room output only, data-room output only, compute-to-data output only, handoff-recipient-only with separate permission, restricted transfer, approved within scope, withdrawn, sealed, archive-only, or deletion-required;
5. control measures, including data minimization, anonymization, aggregation, geospatial masking, encryption, access control, no-download, logging, contractual restrictions where applicable, public-safe review, legal boundary review, data sovereignty review, safeguard review, Indigenous protocol review where applicable, AI-use review, output review, correction, recall, and archive;
6. boundary notices, confirming that cross-border access or transfer is not open data release, unrestricted reuse permission, AI-use permission, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, consent, handoff authorization, deployment authorization, or execution.
Cross-border controls prevent digital public goods from becoming cross-border extraction systems. National data may travel only when its sovereignty, safeguards, permissions, and correction pathways travel with it.
### 21.5.4 National Repositories
National repositories are the nationally governed storage, stewardship, versioning, access-control, release, correction, archive, and discovery environments for national data objects and related digital public goods. They may include code repositories, data repositories, metadata repositories, model repositories, documentation repositories, Report repositories, dashboard repositories, Studio repositories, Academy repositories, Campaign repositories, Registry mirrors, Marketplace mirrors, Grid repositories, secure-room repositories, data-room repositories, protected knowledge repositories, National Portfolio repositories, and archive repositories.
National repositories are not passive file stores. They are national trust infrastructure. They preserve provenance, licensing, data-use labels, AI-use labels, sensitivity class, access class, public-safe status, localization status, language status, accessibility status, correction history, public authority boundaries, safeguard conditions, support status, handoff restrictions, and archive status.
A National Repository Record should identify:
1. repository class, including national data repository, metadata repository, model repository, software repository, documentation repository, dashboard repository, Studio repository, Academy repository, Campaign repository, Report repository, Registry mirror, Marketplace mirror, Grid repository, secure-room repository, data-room repository, protected knowledge repository, National Portfolio repository, or archive repository;
2. repository steward, including National Node steward, data steward, technical maintainer, public-safe steward, safeguard steward, cyber steward, privacy steward, public authority learning steward where applicable, Indigenous data steward where applicable, protected knowledge steward, and archive steward;
3. objects hosted, including datasets, schemas, codebooks, pipelines, models, dashboards, Reports, public-safe summaries, Studio workflows, Campaign objects, Academy objects, Registry records, Marketplace listings, Grid inputs, public authority learning records, finance-readiness records, safeguard records, handoff notes, correction records, and archives;
4. governance controls, including access control, versioning, provenance, license class, data-use label, AI-use label, dependency review, cyber review, privacy review, public-safe review, safeguard review, localization review, cross-border review, support classification, release classification, correction, withdrawal, recall, sealing, deletion where required, and archive;
5. synchronization and mirror controls, including source relationship, upstream/downstream dependency, national mirror status, fork status, correction propagation, withdrawal propagation, recall propagation, supersession, non-current notice, Registry update, Marketplace update, Grid update, and handoff note update;
6. boundary notices, confirming that repository presence is not open data release, warranty, production approval, security certification, procurement approval, public authority approval, financeability, insurability, donor commitment, public finance allocation, consent, handoff authorization, deployment authorization, or execution.
National repositories are the memory and control spine of national digital public goods.
### 21.5.5 Sovereign Compute
Sovereign compute is the national data sovereignty control through which computation, analytics, AI workflows, Studio workflows, DRI processing, Observatory processing, dashboard generation, model evaluation, public-safe transformation, secure-room workflows, data-room workflows, and handoff-context preparation are performed within a nationally approved compute environment where data sovereignty, public authority sensitivity, privacy, cybersecurity, protected knowledge, Indigenous data sovereignty where applicable, community safeguards, or legal requirements make ordinary cloud or external processing unsuitable.
Sovereign compute may include national cloud, public-sector cloud, sovereign cloud, National Node compute, university compute under national controls, secure enclave, confidential computing environment, controlled room, protected knowledge room, data room, compute-to-data environment, or other nationally approved processing environment. Sovereign compute is not deployment authorization or public authority approval. It is a processing control.
A Sovereign Compute Record should identify:
1. compute environment, including national cloud, sovereign cloud, public-sector cloud, National Node compute, university-controlled compute, secure enclave, confidential computing environment, controlled room, secure room, data room, protected knowledge room, or compute-to-data environment;
2. workload class, including DRI processing, Observatory processing, Studio simulation, dashboard generation, AI evaluation, model inference, public-safe transformation, metadata generation, geospatial masking, Report preparation, Registry update, Marketplace update, Grid input preparation, finance-readiness analysis, public authority learning preparation, or handoff dependency preparation;
3. data class processed, including public-safe, controlled public, restricted, public authority-sensitive, community-sensitive, Indigenous protocol-sensitive where applicable, protected knowledge, youth data, health-sensitive data, cyber-sensitive data, infrastructure-sensitive data, geospatial-sensitive data, handoff-recipient-only, archive-only, or sealed data;
4. compute controls, including approved users, approved workloads, access logs, encryption, key management, no-download controls, no-write-back where required, AI-use controls, tool-permission controls, output review, vulnerability management, incident response, correction, sealing, deletion where required, and archive;
5. output controls, including public-safe output, metadata-only output, aggregated output, anonymized output, masked output, secure-room output, data-room output, protected knowledge room output, public authority learning output, handoff-recipient-only output, restricted output, archive-only output, or no-output status;
6. boundary notices, confirming that sovereign compute is not open data release, AI-use permission beyond recorded labels, security certification, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, deployment authorization, or execution.
Sovereign compute keeps sensitive computation close to the authority, law, safeguards, and records that govern it.
### 21.5.6 Compute-to-Data
Compute-to-data is the preferred national data sovereignty workflow for restricted, sovereign-sensitive, public authority-sensitive, rights-bearing, community-protected, Indigenous protocol-sensitive where applicable, protected knowledge, health-sensitive, youth-sensitive, cyber-sensitive, infrastructure-sensitive, geospatial-sensitive, humanitarian-sensitive, and high-risk data where the safer method is to bring approved computation to governed data rather than export data to external computation.
Compute-to-data supports Nexus Studio workflows, DRI workflows, Observatory workflows, model evaluation, AI workflows, public-safe transformation, dashboard generation, Registry updates, Marketplace summaries, Grid inputs, Reports, public authority learning, finance-readiness, donor-readiness, public finance learning, safeguard review, and handoff dependency preparation under strict access, workload, output, and archive controls.
A Compute-to-Data Record should identify:
1. data object and environment, including dataset, metadata, model input, DRI dataset, Observatory dataset, Studio dataset, National Portfolio dataset, Campaign dataset, public authority-sensitive data, community-sensitive data, protected knowledge, secure room, data room, sovereign compute environment, or protected knowledge room;
2. approved workload, including query, aggregation, anonymization, geospatial masking, feature extraction, model inference, evaluation, dashboard generation, public-safe transformation, Report summary, Registry metadata generation, Marketplace summary, Grid input preparation, public authority learning output, finance-readiness question, or handoff dependency output;
3. approved users and tools, including data steward, public-safe reviewer, safeguard reviewer, technical reviewer, AI reviewer, public authority learner where authorized, GRA-aligned readiness steward where authorized, approved model, approved script, approved notebook, approved API, and approved runtime;
4. runtime controls, including no raw data export, no unauthorized download, no external copy, no unapproved AI use, no training unless separately permitted, no agentic use unless separately permitted, logging, encryption, output review, prompt-injection controls where applicable, kill-switch conditions, and incident response;
5. output review and release, including no output, restricted output, aggregate output, anonymized output, masked output, metadata-only output, public-safe output, secure-room output, data-room output, public authority learning-only output, handoff-recipient-only output, archive-only output, correction, withdrawal, recall, sealing, or deletion where required;
6. boundary notices, confirming that compute-to-data output is not raw data release, open data release, AI-use permission, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, consent, deployment authorization, or execution.
Compute-to-data allows Nexus to learn from sensitive data without moving the data beyond its sovereign and safeguard boundaries.
### 21.5.7 Secure Rooms and Data Rooms
Secure rooms and data rooms are controlled national environments for reviewing, computing on, summarizing, translating, correcting, and archiving sensitive Nexus data and digital public-good objects under access, confidentiality, cyber, privacy, public-safe, safeguard, public authority, finance-readiness, and handoff controls. They may be physical, virtual, hybrid, or compute-based environments.
Secure rooms are used for sensitive review and controlled workflows. Data rooms are used for controlled data access, due-diligence-readable context where lawful and non-reliance controlled, public authority learning, donor-readiness review, public finance learning, insurance-readiness questions, finance-readiness questions, safeguard review, and handoff dependency awareness. Neither room is a transaction room, procurement room, public authority decision room, consent room, deployment room, or execution room by default.
A Secure Room or Data Room Record should identify:
1. room class, including secure room, data room, clean room, protected knowledge room, public authority learning room, readiness room, capital-reader room, insurance-reader room, donor-reader room, public finance learning room, Studio room, correction room, or archive room;
2. materials in scope, including datasets, metadata, DRI outputs, Observatory outputs, Studio workflows, Reports, National Portfolio objects, Campaign records, Academy records, Registry records, Marketplace records, Grid inputs, finance-readiness records, public finance relevance records, safeguard records, protected knowledge records, handoff notes, correction records, and archive records;
3. access controls, including approved participants, role class, identity verification where appropriate, confidentiality terms, access duration, access logs, no-download rules, no-copy rules, no-recording rules, no-AI rules where applicable, no-training rules where applicable, output review, access revocation, and archive rule;
4. room-purpose controls, including learning-only, public-safe review, data review, safeguard review, public authority learning, finance-readiness readability, donor-readiness readability, public finance learning, insurance-readiness question formation, handoff dependency review, correction, archive, and no-decision status where applicable;
5. incident and correction controls, including access breach response, confidentiality breach response, data incident response, AI-use incident response, protected knowledge incident response, public authority boundary correction, finance boundary correction, public-safe correction, withdrawal, recall, sealing, deletion where required, archive, and non-continuation;
6. boundary notices, confirming that secure-room or data-room access is not data ownership transfer, open data release, due diligence completion, public authority approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, consent, handoff approval, deployment authorization, or execution.
Secure rooms and data rooms make controlled learning possible without turning controlled access into permission or authority.
### 21.5.8 Public Authority-Sensitive Data
Public authority-sensitive data is national data whose use, release, display, interpretation, routing, or handoff may affect public authority functions, public services, regulatory responsibilities, emergency responsibilities, public finance responsibilities, procurement responsibilities, public health responsibilities, infrastructure responsibilities, official statistics, public warnings, cross-border public duties, or public trust. Such data may include public-sector operational context, public finance context, infrastructure context, emergency context, health context, meteorological or hydrological context, statistical context, regulatory context, procurement context, municipal context, public utility context, and public authority learning records.
Public authority-sensitive data shall not be represented as official public authority record, policy, regulation, compliance finding, public warning, emergency command, procurement decision, public finance allocation, official statistics, public health advisory, infrastructure approval, public authority endorsement, consent, deployment authorization, or execution unless a separate competent public authority lawfully records such effect.
A Public Authority-Sensitive Data Record should identify:
1. data class, including ministry-sensitive data, regulator-sensitive data, municipal-sensitive data, emergency-sensitive data, meteorological or hydrological-sensitive data, public health-sensitive data, infrastructure-sensitive data, public finance-sensitive data, procurement-sensitive data, standards-interface-sensitive data, statistical-sensitive data, cross-border public institution-sensitive data, public utility-sensitive data, or public service-sensitive data;
2. public authority context, including competent public authority class, learning context, data source, public authority participant status, official-status risk, public authority boundary status, name-use status, logo-use status, quote status, and public-safe status;
3. sensitivity risks, including policy overclaim, regulatory overclaim, public warning overclaim, emergency command overclaim, procurement overclaim, public finance allocation overclaim, official statistics overclaim, public health advisory overclaim, infrastructure approval overclaim, ministry endorsement overclaim, municipal approval overclaim, public authority dependency bypass, or execution overclaim;
4. control measures, including access restriction, public authority boundary review, legal boundary review, public-safe transformation, name-use controls, logo controls, quote controls, geospatial masking, secure-room handling, data-room handling, correction, withdrawal, recall, sealing, archive, and non-continuation;
5. release status, including public prohibited, public-safe summary permitted, public authority learning-only, controlled-public, secure-room-only, data-room-only, National Node-visible, handoff-recipient-only with restrictions, archive-only, sealed, or deletion-required;
6. boundary notices, confirming that public authority-sensitive data is not official public authority action, policy, regulation, warning, command, procurement, public finance allocation, official statistics, endorsement, consent, deployment authorization, or execution.
Public authority-sensitive data must be handled so that public-sector learning does not become public-sector action by implication.
### 21.5.9 Community-Sensitive Data
Community-sensitive data is national data relating to communities, local institutions, affected stakeholders, youth groups, civil society actors, humanitarian contexts, Indigenous participants where applicable, lived-risk knowledge, local conditions, protected knowledge, community-sensitive locations, accessibility needs, language needs, public service gaps, health context, food and water insecurity, displacement, migration, informal coping systems, safeguard concerns, and correction requests.
Community-sensitive data shall not be treated as open data, AI-usable data, mappable data, publishable data, donor-readable data, finance-readable data, insurance-readable data, public authority-routable data, handoff-ready data, or public-safe data by default. It requires purpose limitation, consent-aware handling, public-safe transformation, protected knowledge controls where applicable, community correction channels, and safeguard review.
A Community-Sensitive Data Record should identify:
1. community data class, including personal data, participation data, story data, survey data, lived-risk data, local context data, youth data, health-sensitive data, humanitarian-sensitive data, geospatial-sensitive data, protected knowledge, Indigenous protocol-sensitive data where applicable, public authority-sensitive community data, or handoff-recipient-only community data;
2. source and participation context, including community participant, local institution, civil society actor, youth participant, accessibility advocate, humanitarian actor, Indigenous participant or institution where applicable, public-interest participant, Campaign pathway, Studio pathway, DRI pathway, Observatory pathway, National Portfolio pathway, Nexus Universe pathway, or correction channel;
3. use labels, including internal review only, public-safe summary only, community-review-only, National Node-visible, public authority learning-only, donor-reader-only with restrictions, public finance learning-only with restrictions, secure-room-only, data-room-only, protected knowledge room-only, handoff-recipient-only with separate permission, no-AI use, no-training, archive-only, sealed, or deletion-required;
4. safeguard controls, including consent boundary record, attribution controls, anonymization, pseudonymization, aggregation, geospatial masking, non-stigmatizing language, youth safeguards, disability inclusion, humanitarian sensitivity, Indigenous protocol review where applicable, protected knowledge restriction, public-safe review, correction channel, and withdrawal pathway;
5. release and routing controls, including no public release unless reviewed, no Marketplace display unless public-safe, no public Registry display unless safe, no public authority routing unless boundary-reviewed, no donor routing unless safeguard-reviewed, no finance or insurance routing unless controlled and non-reliance labelled, no handoff unless separately authorized, correction, archive, and non-continuation;
6. boundary notices, confirming that community-sensitive data availability is not consent, open data release, AI-use permission, public authority approval, donor commitment, public finance allocation, financeability, insurability, handoff authorization, deployment authorization, or execution.
Community-sensitive data must remain accountable to the people and places it describes.
### 21.5.10 National Archive
National archive is the national data sovereignty mechanism through which national data objects, metadata, repositories, mirrors, DRI records, Observatory records, Studio records, Campaign records, Academy records, Reports, Registry records, Marketplace records, Grid records, public authority learning records, safeguard records, finance-readiness records, donor-readiness records, public finance relevance records, handoff dependency notes, correction records, sealed records, withdrawn records, recalled records, superseded records, and non-continuing records are preserved, restricted, corrected, deleted where required, or marked non-current under national controls.
The National Archive preserves memory without preserving authority. Archived records shall not be treated as current, public, reusable, AI-usable, publishable, mappable, translatable, Marketplace-current, Registry-current, public-authority-approved, finance-ready, insurance-ready, donor-approved, public-finance-approved, handoff-ready, deployment-authorized, or execution-ready.
A National Archive Record should identify:
1. archived object, including data object, metadata record, software object, dashboard object, DRI object, Observatory object, Studio object, Campaign object, Academy object, Report object, Registry object, Marketplace object, Grid object, public authority learning object, safeguard object, finance-readiness object, public finance relevance object, support record, handoff object, correction record, or protected knowledge record;
2. archive trigger, including lifecycle close, national cycle close, Nexus Universe cycle close, correction, supersession, withdrawal, recall, public-safe status change, data sensitivity change, public authority boundary change, safeguard change, protected knowledge restriction, consent withdrawal, legal requirement, retention expiry, deletion requirement, non-continuation, or handoff closure;
3. archive class, including public archive, controlled archive, National Node archive, public authority-sensitive archive, public finance-sensitive archive, community-sensitive archive, Indigenous protocol-sensitive archive where applicable, protected knowledge archive, secure-room archive, data-room archive, handoff-recipient-only archive, sealed archive, deletion-required pathway, deleted record, or archive-only record;
4. access and reuse controls, including public display permitted, metadata-only display, controlled access, steward-only access, knowledge-holder access where applicable, public authority learning access, correction-only access, audit-only access, no reuse, no AI use, no publication, no handoff, no Marketplace display, no public Registry display, and no deployment use;
5. successor and correction links, including successor object, superseding version, correction record, withdrawal notice, recall notice, public repair record, Registry update, Marketplace update, Grid update, National Portfolio update, Report update, handoff note update, and non-current notice;
6. boundary notices, confirming that the National Archive preserves record truth and institutional memory but does not create current approval, official status, public authority action, procurement status, financeability, insurability, donor commitment, public finance allocation, consent, handoff authorization, deployment authorization, or execution.
The National Archive is the national memory layer of Nexus data sovereignty. It protects the future from stale, corrected, withdrawn, or sensitive records being mistaken for current authority.
The final National Data Sovereignty rule is: national data sovereignty requires national data classes, data localization, cross-border controls, national repositories, sovereign compute, compute-to-data, secure rooms and data rooms, public authority-sensitive data controls, community-sensitive data controls, and national archive discipline. These controls allow Nexus to use, localize, process, summarize, correct, and preserve national data as digital public goods without converting data availability into open data, AI-use permission, public authority action, procurement approval, financeability, insurability, donor commitment, public finance allocation, community or Indigenous consent, handoff authorization, deployment authorization, or execution by implication.
## 21.6 Localization Boundary Rules
### 21.6.1 Translation Is Not Substantive Approval
Translation is not substantive approval is the mandatory localization boundary rule that translating a Nexus digital public good, Report, public-safe summary, plain-language summary, DRI output, Observatory summary, Studio workflow, Campaign material, Academy material, Registry record, Marketplace listing, National Portfolio object, Nexus Universe output, finance-readiness record, public authority learning record, safeguard record, correction channel, offline package, local terminology note, National Glossary entry, or handoff dependency note shall not be represented as approval of the translated substance, validation of the underlying object, public authority approval, legal approval, procurement approval, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, deployment authorization, or execution.
Translation may make a record readable in another language. It does not cure evidentiary gaps, legal gaps, data-use gaps, AI-use gaps, public-safe gaps, safeguard gaps, public authority dependencies, finance dependencies, insurance dependencies, donor dependencies, public finance dependencies, procurement dependencies, consent dependencies, technical dependencies, correction dependencies, archive dependencies, or handoff dependencies. A translated object remains subject to the same or stricter restrictions as the source object unless a separate recorded review lawfully changes the applicable status.
A Translation-Not-Approval Boundary Record should identify:
1. translated object, including source identifier, translated title, source language, target language, version, steward, release class, access class, public-safe status, sensitivity class, correction status, and archive status;
2. translation pathway, including human translation, expert translation, public-safe translation, technical translation, legal-boundary review, public authority terminology review, community review where appropriate, Indigenous protocol review where applicable, accessibility translation, machine-assisted draft with human review, or restricted translation;
3. substance not approved, including evidence, methods, data, model, dashboard, software, Campaign claim, Report conclusion, Registry status, Marketplace listing, Grid input, TRL context, public authority learning note, finance-readiness note, safeguard record, or handoff dependency note;
4. required notices, including translation-for-understanding-only, translation-subject-to-correction, translation-not-legal-equivalence, translation-not-public-authority-approval, translation-not-procurement, translation-not-financeability, translation-not-insurability, translation-not-donor-commitment, translation-not-public-finance-allocation, translation-not-consent, translation-not-deployment, and translation-not-execution;
5. correction pathway, including mistranslation correction, boundary notice correction, public-safe correction, terminology correction, Registry correction, Marketplace correction, Report correction, offline package recall, withdrawal, archive, or non-continuation;
6. boundary notices, confirming that translation improves access to meaning only and does not create substantive approval, validation, authorization, permission, handoff approval, deployment authority, or execution authority.
Translation shall be treated as a language-access function, not as an approval function.
### 21.6.2 Localization Is Not Public Authority Adoption
Localization is not public authority adoption is the mandatory localization boundary rule that adapting a Nexus object to national language, legal context, public authority terminology, technical environment, data context, cultural context, accessibility needs, low-bandwidth conditions, offline formats, or community-safe conditions shall not be represented as adoption by a ministry, regulator, municipality, emergency management body, meteorological or hydrological service, public health authority, infrastructure authority, public finance body, public procurement body, standards-interface public body, statistical office, cross-border public institution, public utility, public service institution, or other public authority.
Localization may make a Nexus object nationally usable for learning, review, discovery, public-safe reporting, Registry display, Marketplace discovery, National Portfolio formation, Nexus Universe continuation, public authority learning, finance-readiness readability, safeguard review, and handoff dependency awareness. It shall not create national policy, regulation, official plan, official statistics, public warning, emergency command, procurement decision, public finance allocation, public authority approval, official endorsement, consent, deployment authorization, or execution.
A Localization-Not-Adoption Boundary Record should identify:
1. localized object, including software, dataset, metadata, model, dashboard, Report, Campaign, Academy object, Studio workflow, DRI output, Observatory summary, Registry record, Marketplace listing, National Portfolio object, Nexus Universe output, finance-readiness record, safeguard record, or handoff dependency note;
2. localization class, including language translation, legal-context localization, public authority terminology localization, technical localization, data localization, cultural localization, accessibility localization, low-bandwidth localization, offline localization, or community-safe localization;
3. public authority interface, including any public-sector learner, ministry, regulator, municipality, emergency body, public finance body, public procurement body, statistical office, public health authority, infrastructure authority, standards-interface body, or cross-border public institution involved in learning, review, or terminology clarification;
4. adoption not created, including no policy adoption, no regulation, no permit, no license, no compliance finding, no official statistics, no public warning, no emergency command, no procurement approval, no public finance allocation, no public authority decision, no official endorsement, no public authority mandate, no consent, no deployment, and no execution;
5. separate adoption rule, confirming that any official public authority adoption or use must occur separately through the competent public authority’s own lawful process and be separately recorded outside the default Nexus localization record;
6. boundary notices, confirming that national localization improves fit, language access, usability, safety, and discovery but does not create public authority adoption or public authority action.
Localization may prepare a public-good object for national learning. It does not make the state adopt it.
### 21.6.3 National Portfolio Object Is Not Country Ranking
National Portfolio object is not country ranking is the mandatory localization boundary rule that a National Portfolio object, National Context Record, National Systems-Risk Map, National Challenge Brief, Evidence Need Record, Observatory Need Record, Core Build Request, Safeguard Record, Public Authority Learning Record, Readiness Question Record, Competence Cell Workplan, Campaign record, Academy record, Foundry record, Studio workflow, DRI record, Registry record, Marketplace record, Grid input, TRL context, Nexus Universe routing record, finance-readiness record, public finance relevance record, support record, correction record, archive record, or handoff dependency note shall not be represented as ranking a country, scoring a country, rating a country, prioritizing a country, certifying a country, approving a country, penalizing a country, or comparing countries for aid, investment, insurance, procurement, public finance, political, regulatory, or public authority purposes by default.
National Portfolio objects are public-good memory and readiness records. They organize national context, evidence needs, DRI needs, Observatory needs, Campaign signals, Academy needs, Foundry tasks, Studio workflows, public authority learning questions, safeguard conditions, finance-readiness questions, public finance relevance questions, and handoff dependencies. They are not country scorecards.
A National-Portfolio-Not-Country-Ranking Boundary Record should identify:
1. portfolio object, including object class, country context, National Node, source records, version, lifecycle state, access class, public-safe status, Registry status, Marketplace status, Grid or TRL context, correction status, and archive status;
2. ranking-risk context, including dashboard display, public-safe summary, Report, Marketplace listing, Registry field, DRI comparison, Observatory comparison, Grid display, support display, Nexus Universe material, donor-reader material, public finance learning material, capital-reader material, insurance-reader material, media-safe material, or public authority learning material;
3. prohibited interpretations, including country ranking, country score, country risk rating, country readiness rating, aid priority, donor priority, finance priority, investment signal, insurance score, procurement priority, public authority performance ranking, political ranking, or deployment priority;
4. permitted interpretations, including national context record, evidence need, Observatory need, DRI learning input, public-safe summary, safeguard condition, readiness question, support need, Campaign signal, Academy need, Foundry task, Studio workflow, Registry status truth, Marketplace discovery, Grid input, or handoff dependency;
5. display controls, including non-ranking design, no league tables by default, no ordinal country scoring, no color-coded country risk score by implication, no finance or insurance signal, no donor priority signal, no public authority performance implication, uncertainty labels, limitation notices, public-safe language, and correction channels;
6. boundary notices, confirming that National Portfolio objects are not country rankings, ratings, approvals, aid priorities, finance signals, insurance scores, procurement priorities, public authority decisions, consent records, deployment authorizations, or execution instructions.
National Portfolio objects shall help countries understand and organize public-good work without turning Nexus into a country-ranking system.
### 21.6.4 Community Display Is Not Consent
Community display is not consent is the mandatory localization boundary rule that displaying a community name, local institution, participant class, story, image, quote, map, Campaign participation count, signature count, pledge count, public-safe summary, local terminology note, 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, translation, accessibility format, offline package, or handoff dependency note shall not be represented as community consent, Indigenous consent where applicable, 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.
Community display may be useful for public-safe communication and national localization, but only where display controls, attribution controls, privacy controls, geospatial controls, youth safeguards, accessibility review, protected knowledge review, Indigenous protocol review where applicable, public-safe review, and correction channels are satisfied. Display is not permission.
A Community-Display-Not-Consent 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, offline package, local language version, media-safe package, or handoff note;
2. community context, including place, local institution, civil society group, youth group, accessibility group, humanitarian context, Indigenous community or institution where applicable, affected stakeholder group, language context, or public-interest pathway;
3. consent risk, including implied community approval, implied Indigenous consent where applicable, implied publication permission, implied data-use permission, implied AI-use permission, implied mapping permission, implied land access, implied deployment permission, implied public authority approval, implied donor priority, implied financeability, implied insurability, or implied execution authority;
4. required notices, including display-not-consent, participation-not-consent, story-not-consent, quote-not-consent, map-not-permission, data-not-open, public-safe-summary-not-raw-release, Campaign-visibility-not-approval, National Portfolio-inclusion-not-official-plan, Nexus Universe-display-not-deployment-authorization, and handoff-note-not-authorization;
5. control actions, 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;
6. boundary notices, confirming that Nexus shall not infer consent from visibility, attendance, participation, contribution, listing, recording, translation, localization, or inclusion.
Community display can support visibility only when it does not create false permission.
### 21.6.5 Accessibility Format Is Not New License
Accessibility format is not new license is the mandatory localization boundary rule that converting national Nexus materials into alt text, captions, transcripts, screen-reader-compatible files, accessible PDFs, HTML versions, large-print versions, easy-read versions, plain-language summaries, audio descriptions, low-bandwidth versions, mobile-first versions, offline packages, translated accessibility materials, tactile diagrams, assisted facilitation materials, or any other accessibility format 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 public finance status, new handoff permission, deployment authorization, or execution authority.
Accessibility formats inherit the source object’s access class, license class, release class, data-use labels, AI-use labels, public-safe status, sensitivity class, protected knowledge restrictions, attribution controls, geospatial controls, public authority boundaries, finance-readiness boundaries, consent boundaries, correction pathway, archive rule, and non-current status unless a separate review imposes stricter controls.
An Accessibility-Format-Not-New-License 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, public-safe summary, local terminology note, National Glossary entry, or handoff dependency note;
2. accessibility format, including alt text, caption, transcript, audio description, screen-reader version, accessible PDF, HTML version, large-print version, easy-read version, plain-language summary, low-bandwidth version, mobile-first version, offline package, tactile diagram, translated accessibility material, or assisted facilitation material;
3. inherited controls, including license, access class, release class, sensitivity class, public-safe status, data-use label, AI-use label, protected knowledge restriction, geospatial masking, attribution control, public authority boundary notice, finance and insurance boundary notice, donor boundary notice, public finance boundary notice, consent boundary notice, correction rule, and archive status;
4. prohibited expansion, including no new publication, no new reuse, no quotation expansion, no AI training, no embedding, no commercial reuse, no Marketplace expansion, no public Registry expansion, no public authority reliance, no finance or insurance reliance, no donor reliance, no public finance reliance, no handoff reliance, no deployment, and no execution;
5. correction pathway, including accessibility correction, public-safe correction, protected knowledge correction, translation correction, alt text correction, caption correction, transcript correction, offline package recall, withdrawal, archive, or non-continuation;
6. boundary notices, confirming that accessibility improves usability within recorded rights and does not create a new license, permission, authority, approval, consent, deployment authorization, or execution.
Accessibility expands access for intended users. It does not expand legal rights or operational authority.
### 21.6.6 National Hosting Is Not Execution Authority
National hosting is not execution authority is the mandatory localization boundary rule that hosting, mirroring, storing, running, displaying, indexing, registering, listing, translating, localizing, preserving, archiving, or making a Nexus digital public good available through a national repository, national mirror, National Node platform, sovereign compute environment, secure room, data room, protected knowledge room, National Portfolio repository, Marketplace mirror, Registry mirror, Academy platform, Campaign platform, Studio environment, dashboard, public authority learning room, or Nexus Universe national pathway shall not be represented as deployment authorization, production approval, public authority approval, procurement approval, security certification, operational authority, implementation authority, financeability, insurability, donor commitment, public finance allocation, community consent, Indigenous consent where applicable, handoff approval, or execution.
National hosting is a stewardship, access, localization, sovereignty, continuity, and record-control function. It may make objects available for learning, review, discovery, public-safe reporting, Registry status truth, Marketplace discovery, Grid input, Nexus Universe continuation, public authority learning, finance-readiness readability, safeguard review, correction, archive, and handoff dependency awareness. It does not authorize anyone to operate, deploy, procure, finance, insure, allocate, consent, implement, or execute.
A National-Hosting-Not-Execution Boundary Record should identify:
1. hosting environment, including national repository, national mirror, sovereign compute, secure room, data room, protected knowledge room, National Node platform, National Portfolio repository, Registry mirror, Marketplace mirror, Studio environment, Campaign platform, Academy platform, dashboard environment, offline package, or archive repository;
2. hosted object, including software, dataset, metadata, model, dashboard, Report, Campaign object, Academy object, Studio workflow, DRI output, Observatory summary, Registry record, Marketplace listing, Grid input, TRL context, finance-readiness record, public authority learning record, safeguard record, or handoff dependency note;
3. hosting purpose, including localization, access control, sovereignty, continuity, learning, review, public-safe display, national discovery, repository preservation, Registry status truth, Marketplace discovery, Grid input, Nexus Universe continuation, public authority learning, readiness question formation, correction, archive, or handoff dependency awareness;
4. execution not created, including no production approval, no deployment authorization, no operational command, no public authority decision, no procurement approval, no finance approval, no insurance approval, no donor commitment, no public finance allocation, no community consent, no Indigenous consent where applicable, no handoff approval, no implementation authorization, and no execution authority;
5. required controls, including versioning, access class, support class, release class, security review status, data-use labels, AI-use labels, public-safe status, localization status, correction status, archive status, non-current notices, support limitations, and handoff dependency notices;
6. boundary notices, confirming that national hosting preserves and makes objects available within recorded limits but does not authorize deployment, operation, procurement, finance, insurance, public finance, consent, handoff, or execution.
National hosting is infrastructure for national public-good memory. It is not the act of delivery.
The final Localization Boundary Rules rule is: translation is not substantive approval; localization is not public authority adoption; a National Portfolio object is not country ranking; community display is not consent; an accessibility format is not a new license; and national hosting is not execution authority. These rules keep national language access, localization, portfolio formation, community visibility, accessibility, and hosting from becoming approval, adoption, ranking, consent, licensing, deployment authorization, or execution by implication.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.therisk.global/organization/standardization/nexus-ecosystem/ii.-structure/xxi.-localization.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.