99. Adoption
99.1 Nexus Governance Defined
99.1.1 Nexus Governance is the adoptable public-good governance architecture through which a country, region, subnational government, city, community, institution, sector, facility, platform, observatory, technical pathway, public authority interface, or public-value finance pathway may organize records, evidence, safeguards, dashboards, public authority boundaries, data zones, maturity states, proof packs, routeability, assurance, correction, and lawful handoff within the common Planetary Nexus Governance Rail.
99.1.2 Nexus Governance is not a single legal form, single platform, single institution, single treaty, single standards body, single certification scheme, single finance vehicle, single public authority model, single technology stack, or single operating company. It is a doctrine and operating grammar that can be adopted in different lawful, cultural, institutional, and technical contexts while preserving common compatibility.
99.1.3 Nexus Governance may be adopted by public-good institutions, national pathways, Regional Constitutional Regions, public authorities where lawful, municipalities, universities, utilities, community nodes, technical assistance programs, Competence Cells, observatory systems, institutional networks, sectoral bodies, public-value finance pathways, and downstream implementation interfaces. Each adoption must be scoped, recorded, and claims-disciplined.
99.1.4 Nexus Governance includes, at minimum, record validity, role separation, publication-class discipline, public authority capacity classification, safeguards, data custody rules, claims limits, correction routes, and maturity-state truth. Higher forms of adoption may include National Councils, Regional Stewardship Boards, Helix Councils, Sovereign Data Zones, dashboards, proof packs, controlled rooms, observatory nodes, routeability records, assurance, and full interoperability.
99.1.5 Nexus Governance is public-good infrastructure. It may support public authorities, communities, finance readers, donors, sponsors, hosts, experts, and downstream actors, but it must not be captured by them. Adoption does not convert the Rail into government, finance, procurement, certification, professional advice, execution, or platform authority.
99.1.6 Nexus Governance is modular. An actor may adopt the Records Core without adopting the Finance-Readiness Core; adopt a dashboard without capital-reader access; adopt public authority capacity records without full regional federation; adopt community nodes without national proof packs; adopt observatory methods without public dashboards. Adoption must match need, capacity, risk, law, and safeguards.
99.1.7 Nexus Governance is correctionable. Any adopted form must include the ability to challenge, correct, supersede, pause, narrow, downgrade, reset, withdraw, or reclassify records, claims, dashboards, proof packs, maturity states, public authority descriptions, data uses, AI outputs, and handoffs.
99.1.8 The doctrine is direct:
Nexus Governance is the adoptable public-good Rail for making complex risk, technology, finance, public authority, community, machine, and living-system pathways record-valid, role-separated, safeguards-bound, interoperable, and correctionable without becoming centralized power.
99.2 National Adoption
99.2.1 National Adoption is the recorded condition through which a country adopts, adapts, or operates Nexus Governance within its sovereign, legal, institutional, public authority, cultural, data, ecological, and community context. It is the country-level expression of the common Rail, grounded in national law and local truth.
99.2.2 National Adoption is not created by a launch event, press release, ministerial meeting, donor grant, hosted desk, platform setup, dashboard release, proof pack, regional inclusion, National Chair appointment, or public authority attendance. It arises only to the extent that the national records, lawful basis, host sufficiency, Council or equivalent surface, working functions, data controls, safeguards, public authority boundaries, claims discipline, and correction routes support the adopted scope.
99.2.3 National Adoption may be full or bounded. A country may adopt Nexus Governance for climate and disaster risk before adopting it for AI governance; for WEFHB pathways before public-value finance; for records and dashboards before proof packs; for public authority learning before routeability; for technical assistance before national federation. The adoption record must state the scope precisely.
99.2.4 National Adoption records should identify: (a) country pathway; (b) lawful basis; (c) adopting or hosting body; (d) national scope; (e) adopted modules; (f) modules excluded; (g) National Council, Desk, Secretariat, or equivalent functions; (h) public authority capacity; (i) Sovereign Data Zone status; (j) safeguards status; (k) language and accessibility conditions; (l) dashboard status; (m) finance-readiness status, if any; (n) maturity state; and (o) correction route.
99.2.5 National Adoption must preserve sovereignty. Adoption of Nexus Governance does not transfer state powers to Nexus bodies, regional bodies, global bodies, platforms, donors, sponsors, hosts, experts, or finance actors. Public decisions remain with competent public authorities. The Rail may support evidence, records, dashboards, public-safe summaries, technical assistance, proof packs, and correction.
99.2.6 National Adoption must preserve local plurality. A national pathway must not erase subnational governments, municipalities, Indigenous or local authorities where applicable, communities, workers, universities, utilities, civil society, protected knowledge holders, language groups, persons with disabilities, rural systems, cities, or bioregional realities. National adoption must remain correctable by place.
99.2.7 National Adoption must include no-overclaim controls. Public language should state whether adoption is supported-only, hosted, forming, active, comparable, regionalized, federated, mature, paused, narrowed, reset, or limited by domain. “Nationally adopted” must never be used as a blanket claim unless the records support broad national adoption.
99.2.8 The doctrine is direct:
National Adoption means a country has lawfully and truthfully adopted the Rail within a defined scope. It is sovereignty-compatible operating capacity, not symbolic launch, external approval, public authority substitution, or national overclaim.
99.3 Regional Adoption
99.3.1 Regional Adoption is the recorded condition through which one of the six Regional Constitutional Regions adopts, adapts, or operates Nexus Governance for regional support, comparability, observability, country-wave sequencing, corridor and basin pathways, regional safeguards, escalation, deconfliction, dashboarding, regional public-good learning, and RNFD-compatible finance-readiness where appropriate.
99.3.2 Regional Adoption does not create regional supremacy. A Regional Constitutional Region may support countries, compare records, coordinate observatory clusters, review corridor and basin pathways, and steward regional coherence, but it may not command countries, override national law, approve projects, allocate public finance, procure infrastructure, determine public authority status, or impose regional policy unless a separate lawful authority exists.
99.3.3 Regional Adoption may be bounded by function. A region may adopt Nexus Governance for Regional Secretariat records, Regional Observatory Cluster coordination, Country-Wave Sequencing, Regional Dashboard, Regional Helix Councils, Regional Risk Pathways, Regional Comparability Proof, or Regional Finance Docket readiness. Each function may mature at different speeds.
99.3.4 Regional Adoption records should identify: (a) Regional Constitutional Region; (b) regional adopting or stewardship function; (c) Regional Anchor or anchors; (d) Regional Secretariat status; (e) Regional Stewardship Board status; (f) Observatory Cluster status; (g) participating country pathways; (h) country-wave statuses; (i) regional risk pathways; (j) public authority-sensitive limits; (k) safeguards and protected knowledge conditions; (l) data-zone constraints; (m) dashboard status; (n) comparability scope; and (o) correction route.
99.3.5 Regional Adoption must preserve country-stage truth. A region cannot claim regional maturity because one country is active, one anchor is strong, one dashboard exists, one corridor is scoped, or one donor is funding the work. Regional adoption must identify exactly which regional functions are active and which remain forming, supported-only, paused, narrowed, or unadopted.
99.3.6 Regional Adoption must preserve regional difference without doctrinal drift. APAC, MENA, Africa, Europe, North America, and South America may adopt the Rail through different priorities, languages, infrastructure conditions, legal traditions, public authority structures, and risk patterns. Difference is permitted; drift into regional command, finance capture, platform centralization, or cultural extraction is not.
99.3.7 Regional Adoption must include Regional No-Drift Review. A region must periodically test whether regional adoption remains faithful to role separation, sovereignty, safeguards, anti-capture, platform subordination, finance discipline, local dignity, and correction.
99.3.8 The doctrine is direct:
Regional Adoption means the Rail operates at regional scale for support, comparability, learning, risk pathways, and correction while preserving national sovereignty, local difference, and the prohibition against regional supremacy.
99.4 Subnational Adoption
99.4.1 Subnational Adoption is the recorded condition through which a province, state, territory, municipality, city, district, basin authority, local government, bioregional structure, public utility area, local development body, or other subnational governance surface adopts or adapts Nexus Governance within its lawful authority and local context.
99.4.2 Subnational Adoption is necessary because many risks are experienced and governed below the national level: heat, flooding, wildfire, drought, water security, food systems, health access, infrastructure continuity, local networks, public transport, community sensing, local land use, utilities, waste, housing, cultural heritage, and emergency response. The Rail must be useful where people live.
99.4.3 Subnational Adoption may include city risk observatories, local dashboards, community nodes, municipal priority registers, watershed or basin records, local safeguards, local evidence systems, facility-grade readiness, public-safe communication, local technical assistance, grievance routes, and local-to-national escalation.
99.4.4 Subnational Adoption records should identify: (a) subnational actor; (b) lawful basis; (c) geography; (d) adopted modules; (e) relationship to national pathway; (f) public authority capacity; (g) local communities affected; (h) Indigenous, local, or protected knowledge relevance where applicable; (i) local data custody; (j) safeguards status; (k) dashboard or public-safe communication status; (l) escalation route; and (m) correction route.
99.4.5 Subnational Adoption must respect national law and public authority boundaries. A municipality or local body may adopt Nexus tools within its mandate, but it may not claim national adoption, regional status, public finance authority, procurement authority, regulatory authority, or emergency authority beyond its lawful capacity.
99.4.6 Subnational Adoption must remain place-based. Local names, local languages, accessibility needs, cultural contexts, local institutions, bioregional systems, public trust, informal systems, workers, vulnerable participants, and local knowledge must shape the adopted form. A subnational adoption copied from another place without local correction is not valid.
99.4.7 Subnational Adoption must connect upward and downward. Local records should feed national and regional learning where safe, but higher-level use must preserve source, sensitivity, local context, and correction rights. Subnational adoption should also return value to communities through public-safe information, capacity, safeguards, and correction.
99.4.8 The doctrine is direct:
Subnational Adoption brings the Rail to the scale of lived governance. It lets cities, provinces, territories, basins, and local institutions adopt Nexus methods without overclaiming national authority or losing place-based truth.
99.5 Sectoral Adoption
99.5.1 Sectoral Adoption is the recorded condition through which a defined sector or systems field adopts Nexus Governance to structure evidence, standards logic, safeguards, public authority boundaries, data controls, dashboards, maturity, assurance, finance-readiness, and correction within that sector. It allows the Rail to operate in technically specialized domains without becoming generic.
99.5.2 Sectoral Adoption may apply to climate and disaster risk, WEFHB governance, public health and biosecurity, cyber and information integrity, critical infrastructure, industrial systems, nuclear and radiological risk, energy systems, data centres and sovereign compute, AI and agentic systems, advanced networks, geospatial intelligence, robotics and autonomous systems, blockchain and tamper-evident records, quantum-relevant systems, bioengineering, finance-readiness, public-value finance, safeguards, and education.
99.5.3 Sectoral Adoption must be governed by sector-specific evidence, safeguards, legal, professional, and public authority requirements. A cyber pathway is not governed like a watershed pathway. A nuclear pathway is not governed like a public dashboard. A biosecurity pathway is not governed like a capital-reader room. Sectoral adoption must preserve technical specificity.
99.5.4 Sectoral Adoption records should identify: (a) sector; (b) adoption scope; (c) governing body or responsible function; (d) relevant TMD; (e) technical baselines; (f) evidence standards; (g) public authority interfaces; (h) professional boundaries; (i) data and AI controls; (j) safeguards and protected knowledge issues; (k) dashboard status; (l) finance-readiness relevance; (m) assurance requirements; and (n) correction route.
99.5.5 Sectoral Adoption must not become sectoral capture. Industry operators, vendors, professional associations, technical experts, platform providers, finance actors, or public authorities may support sectoral adoption, but they may not control the sectoral grammar in ways that privilege their interests, products, methods, or narratives.
99.5.6 Sectoral Adoption must remain interoperable with the common Rail. Sector-specific terms, baselines, evidence levels, assurance methods, and dashboards must map back to common records, publication classes, maturity states, public authority capacity, claims discipline, and correction logic. Sector depth must not become Rail fragmentation.
99.5.7 Sectoral Adoption must include no-overclaim discipline. Sectoral adoption does not create certification, regulatory compliance, procurement approval, professional opinion, safety guarantee, investment readiness, or public authority decision unless a lawful external record provides that effect.
99.5.8 The doctrine is direct:
Sectoral Adoption lets specialized fields use the Rail without flattening their technical realities. Each sector may deepen the doctrine, but none may bypass safeguards, public authority boundaries, anti-capture, or correction.
99.6 Institutional Adoption
99.6.1 Institutional Adoption is the recorded condition through which a university, utility, public-good organization, nonprofit, research institute, standards body, community organization, public authority unit, hospital, school, company, host institution, foundation, observatory, platform operator, technical assistance provider, or other institution adopts Nexus Governance within its mandate.
99.6.2 Institutional Adoption may include use of Case IDs, records and registers, publication classes, role keys, safeguards, protected knowledge controls, AI-use rules, data custody rules, dashboards, public authority capacity records, proof-pack support, competence-cell functions, training, assurance, and correction. It may be internal or connected to a national, regional, or planetary pathway.
99.6.3 Institutional Adoption records should identify: (a) institution; (b) legal status; (c) adoption authority; (d) adopted modules; (e) internal responsible function; (f) external Nexus relationships; (g) data custody roles; (h) public authority roles, if any; (i) sponsor, donor, host, or vendor relationships; (j) safeguards duties; (k) public claims permissions; (l) platform permissions; and (m) correction route.
99.6.4 Institutional Adoption must not create institutional supremacy. A university that hosts a Competence Cell does not own national truth. A utility that contributes infrastructure data does not control public dashboards. A platform provider that hosts records does not govern records. A company that sponsors a pathway does not receive endorsement. A public authority unit that learns through Nexus does not transfer public power to Nexus.
99.6.5 Institutional Adoption must preserve the institution’s lawful and professional boundaries. Institutions may adopt Nexus methods only within their mandate, legal authority, professional duties, contractual obligations, data rights, labour duties, ethical rules, and public accountability. The Rail does not license an institution to exceed its role.
99.6.6 Institutional Adoption must include internal capability. Adoption is not a logo or policy statement. The institution must train people, assign roles, manage records, protect data, enforce claims limits, support accessibility, and maintain correction. A paper adoption without operational capacity is orientation, not adoption.
99.6.7 Institutional Adoption must be portable and non-capturing. If the institution later changes host role, vendor role, sponsor role, or platform role, Nexus records, correction trails, and public-good outputs must remain usable according to the records. Institutional adoption must support the Rail, not trap it.
99.6.8 The doctrine is direct:
Institutional Adoption lets organizations operate Nexus methods within their own mandates while remaining role-bounded, non-supreme, public-good aligned, and correctionable.
99.7 Community Adoption
99.7.1 Community Adoption is the recorded condition through which a community, neighbourhood, village, Indigenous or local institution where applicable, cooperative, local node, civil society network, school, clinic, community observatory, community network, worker group, or place-based organization adopts or adapts Nexus Governance for local evidence, safeguards, public-safe communication, grievance, protected knowledge, local data custody, community sensing, correction, and local-to-national escalation.
99.7.2 Community Adoption must be grounded in dignity and self-determination. It must not convert communities into data suppliers, validation audiences, donor stories, resilience branding, finance narratives, or low-cost field infrastructure. The purpose is to give communities more power to describe, protect, correct, and govern local truth.
99.7.3 Community Adoption may include low-tech records, local Case IDs, community sensing logs, public-safe notice boards, local dashboards, protected knowledge restriction records, no-map registers, grievance routes, local validation practices, local language summaries, accessibility supports, community competence training, and escalation pathways.
99.7.4 Community Adoption records should identify: (a) community or node; (b) host or custodian; (c) local mandate or legitimacy basis; (d) adopted modules; (e) geography and place names where safe; (f) local languages; (g) accessibility needs; (h) protected knowledge controls; (i) data custody rules; (j) public authority interface; (k) safeguards and non-retaliation measures; (l) escalation route; and (m) correction route.
99.7.5 Community Adoption must not imply whole-community consent unless the relevant consent standard is lawfully and culturally satisfied. A community node, workshop, local training, or sensing program may show participation, but it does not automatically establish support for a project, finance pathway, public claim, map, or implementation handoff.
99.7.6 Community Adoption must include refusal and restriction rights. Community systems must be able to record non-consent, no-map, no-AI, no-training, no-capital-reader, no-public-disclosure, protected attribution, custodial review, and withdrawal states. Community adoption that cannot say no is extraction.
99.7.7 Community Adoption must produce local value. Communities adopting the Rail should receive usable records, safer communication, clearer public authority boundaries, correction routes, training, local evidence tools, safeguards support, and practical ability to influence national or regional records. Upward data flow without local return is prohibited.
99.7.8 The doctrine is direct:
Community Adoption is the local dignity form of the Rail. It helps communities record, protect, communicate, refuse, escalate, and correct their own truth without being reduced to data sources or consent symbols.
99.8 Alignment and Compatibility
99.8.1 Alignment and Compatibility are the doctrines through which an actor, body, pathway, standard, platform, institution, community process, public authority process, or technical system may be recognized as compatible with Nexus Governance without necessarily being fully adopted, controlled, owned, certified, or operated by Nexus bodies.
99.8.2 Alignment means that an external or adjacent process shares relevant principles, goals, records, safeguards, public-good purposes, or public-value aims with the Rail. Compatibility means that its records, methods, publication classes, authority boundaries, data rules, and correction processes can interoperate with the Rail for a defined purpose. Alignment is substantive affinity. Compatibility is operational interoperability.
99.8.3 Alignment and Compatibility records should identify: (a) aligned or compatible actor or system; (b) relationship to Nexus Governance; (c) scope of alignment; (d) scope of compatibility; (e) areas not aligned; (f) areas not compatible; (g) mapping to Nexus records; (h) safeguards equivalence or gaps; (i) public authority boundaries; (j) data and AI controls; (k) claims permissions; and (l) correction route.
99.8.4 Alignment must not be overclaimed as adoption. A standard, institution, public authority, community process, donor program, platform, or project may be aligned with Nexus principles without adopting the Rail. Public language must distinguish “aligned with,” “compatible with,” “using elements of,” “mapped to,” “supported by,” “recognized for compatibility,” and “adopted.”
99.8.5 Compatibility must not be overclaimed as equivalence. A system may be technically compatible with Case IDs but not safeguards; compatible with dashboards but not protected knowledge; compatible with proof-pack structure but not finance-readiness limits; compatible with data exchange but not public authority capacity. Compatibility must be scoped.
99.8.6 Alignment and Compatibility must include correction. If a compatible system changes its schema, weakens safeguards, overclaims authority, exposes data, adds AI processing, changes public claims, or becomes captured, compatibility may be narrowed, paused, withdrawn, or reset.
99.8.7 Alignment and Compatibility should enable plural adoption. The Rail should not require every lawful actor to become the same kind of Nexus body. Compatible public authority systems, community protocols, institutional systems, sectoral standards, and regional frameworks may connect while preserving their own identity.
99.8.8 The doctrine is direct:
Alignment and Compatibility allow the Rail to connect with diverse systems without absorbing them. Similarity is not adoption, compatibility is not equivalence, and connection remains bounded by records, safeguards, and correction.
99.9 Technical Interoperability
99.9.1 Technical Interoperability is the doctrine through which Nexus Governance enables records, platforms, dashboards, APIs, data zones, observatory nodes, proof packs, controlled rooms, maturity states, evidence objects, safeguards records, public authority records, and correction trails to connect technically without losing governance meaning.
99.9.2 Technical Interoperability is not merely data exchange. It requires semantic interoperability, authority interoperability, publication-class interoperability, role-key interoperability, correction interoperability, sensitivity interoperability, and reliance-limit interoperability. A machine-readable field that loses context is a governance risk.
99.9.3 Technical Interoperability records should identify: (a) systems connected; (b) interface type; (c) data or record objects exchanged; (d) schema mapping; (e) controlled vocabulary; (f) publication classes; (g) role-key rules; (h) data custody rules; (i) AI-use restrictions; (j) public authority capacity treatment; (k) correction propagation; (l) deprecation rules; and (m) audit logs.
99.9.4 Technical Interoperability must preserve “no” states. No-publication, no-map, no-AI, no-training, no-embedding, no-capital-reader, no-export, non-consent, protected knowledge, public authority-sensitive, community-sensitive, and restricted states must travel across systems. Interoperability that only transmits positive data and loses restrictions is unsafe.
99.9.5 Technical Interoperability must preserve lineage. Dashboards, APIs, proof packs, and regional records must be able to identify source records, update date, evidence class, uncertainty, authority basis, publication class, and correction status where role permits. Where details are restricted, the receiving system must at least carry restriction metadata.
99.9.6 Technical Interoperability must include failure and deprecation handling. If an API fails, a schema changes, a dashboard is superseded, a data source is withdrawn, a record is corrected, or a role key expires, dependent systems must know not to rely on stale outputs.
99.9.7 Technical Interoperability must avoid platform capture. Interoperability should favour open formats, documented schemas, exportability, portability, and vendor-neutral design where feasible. A technical interface must not become a monopoly pathway into the Rail.
99.9.8 The doctrine is direct:
Technical Interoperability connects systems only when governance context travels with the data. Source, sensitivity, authority, restriction, reliance, and correction must be as interoperable as the record itself.
99.10 Adoption Records
99.10.1 Adoption Records are the official records through which Nexus Governance adoption, alignment, compatibility, technical interoperability, scope, maturity, safeguards, public authority boundaries, local naming, global compatibility, claims permissions, and correction become visible, reviewable, and governable.
99.10.2 Adoption Records may include national adoption records, regional adoption records, subnational adoption records, sectoral adoption records, institutional adoption records, community adoption records, alignment records, compatibility records, technical interoperability records, module adoption records, local naming records, public claims records, maturity records, and adoption correction trails.
99.10.3 Adoption Records should identify: (a) adopting actor or system; (b) legal or institutional basis; (c) adoption type; (d) adopted modules; (e) excluded modules; (f) maturity state; (g) public authority capacity; (h) safeguards status; (i) data-zone status; (j) technical interoperability status; (k) finance-readiness relevance; (l) public claims permissions; (m) limitations; (n) review date; and (o) correction route.
99.10.4 Adoption Records must distinguish adoption level. Orientation, Records Core, Council Core, Evidence Core, Platform Core, Interoperability Core, Finance-Readiness Core, and Full Planetary Nexus Governance are different levels. A lower-level adoption is valid within scope but must not be inflated into full adoption.
99.10.5 Adoption Records must distinguish actor type. A community adoption, institutional adoption, sectoral adoption, subnational adoption, national adoption, regional adoption, and compatibility mapping have different consequences. A community adopting local evidence methods does not mean national adoption. A national dashboard does not mean regional federation. A sectoral proof-pack template does not mean finance-readiness.
99.10.6 Adoption Records must include negative and excluded states. “Not adopted,” “not compatible,” “not public-safe,” “not finance-readable,” “not regionally federated,” “not public authority approved,” “not AI-authorized,” and “not applicable” are valid adoption records. Negative records prevent overclaim.
99.10.7 Adoption Records must be dependency-linked. If a data-zone condition changes, compatibility may change. If public authority capacity is corrected, adoption claims may change. If safeguards fail, adoption may narrow. If technical interoperability breaks, dashboards may update. Adoption must remain living.
99.10.8 The doctrine is direct:
Adoption Records make adoption truthful. They show who has adopted what, for what purpose, at what level, with what limits, under what authority, and how the adoption can be corrected.
99.11 Adoption Without Overclaim
99.11.1 Adoption Without Overclaim is the doctrine that no actor may describe itself, its pathway, its platform, its community, its institution, its sector, its region, or its country as Nexus-adopted, Nexus-recognized, Nexus-certified, Nexus-approved, Nexus-aligned, Nexus-compatible, Nexus-federated, Nexus-mature, Nexus-finance-ready, or Nexus-public-safe beyond the exact scope supported by Adoption Records.
99.11.2 Adoption overclaim may occur through websites, logos, dashboards, donor reports, sponsor materials, public authority references, capital-reader materials, procurement documents, conference presentations, social media, platform badges, investor decks, community materials, or internal strategy documents that later circulate externally.
99.11.3 Adoption Without Overclaim requires controlled language. Permitted language may include “under orientation,” “records-core adopted,” “hosted-desk established,” “using Nexus-compatible records for defined scope,” “aligned with Nexus safeguards in defined pathway,” “interoperable with Nexus dashboard schema for public-safe indicators,” or “national adoption under defined domains.” The language must match the record.
99.11.4 Prohibited adoption claims include unsupported statements of official adoption, government approval, regional federation, public authority endorsement, certification, investment readiness, procurement readiness, community consent, Indigenous-informed status, public-safe status, mature operation, or full Nexus governance where records do not support those meanings.
99.11.5 Adoption Without Overclaim applies to visual claims. Logos, marks, badges, maps, colours, country placement, regional dashboard inclusion, partner lists, photographs with officials, platform labels, or proof-pack covers can imply adoption. Visual use must be governed as claims.
99.11.6 Adoption Without Overclaim requires misuse monitoring. Donors, sponsors, hosts, vendors, public authorities, capital readers, media, consultants, and internal actors may misuse adoption language. The Rail must monitor, receive reports, and correct misuse.
99.11.7 Adoption overclaim must trigger correction. Depending on severity, correction may include language revision, public-safe clarification, dashboard correction, mark withdrawal, access restriction, compatibility pause, adoption narrowing, maturity downgrade, or public notice.
99.11.8 The doctrine is direct:
Adoption Without Overclaim means that adoption is always scoped, recorded, dated, bounded, and correctionable. No actor may borrow the Rail’s legitimacy beyond the exact adoption it has earned.
99.12 Local Naming, Global Compatibility
99.12.1 Local Naming, Global Compatibility is the final doctrine of this chapter. It states that countries, regions, communities, sectors, institutions, public authorities, and local pathways may name and structure their Nexus Governance adoption in locally meaningful ways while remaining compatible with the common Rail through records, schemas, maturity states, publication classes, safeguards, and correction.
99.12.2 Local naming may reflect national language, constitutional culture, Indigenous or local protocols where applicable, institutional identity, sectoral vocabulary, public authority terminology, community usage, or bioregional meaning. A country may use a national term for its Council. A community may use its own name for a node. A sector may use technical terminology. A region may use a culturally appropriate label for its workplan. Local naming is permitted.
99.12.3 Local naming must not create incompatible meaning. If a local title implies public authority, certification, approval, recognition, finance-readiness, procurement status, or execution, the Adoption Record must clarify the actual Nexus function and claims limits. Names may be local; legal and governance effect must be precise.
99.12.4 Local naming records should identify: (a) local name; (b) language; (c) local meaning; (d) corresponding Nexus function; (e) authority implications; (f) public claims limits; (g) translation rules; (h) cultural or protected knowledge considerations; (i) dashboard label; (j) interoperability mapping; and (k) correction route.
99.12.5 Global compatibility requires mapping. Local names and structures should map to the common Rail: Records Core, Council Core, Evidence Core, Platform Core, Interoperability Core, Finance-Readiness Core, safeguards, maturity states, public authority capacity, publication classes, dashboards, and correction. Mapping allows global learning without forcing uniform vocabulary.
99.12.6 Local naming must preserve protected knowledge and language dignity. Some names, terms, or meanings may not be translated or publicly displayed. Others may require cultural mediation, local review, or public-safe substitution. Compatibility must not require unsafe translation.
99.12.7 Local naming must remain correctionable. If a local name misleads users, creates public authority confusion, erases cultural meaning, implies false maturity, or fails in translation, the name, mapping, dashboard label, or public-safe language must be corrected.
99.12.8 The final doctrine is direct:
The Nexus Governance Adoption Doctrine allows the Rail to be adopted in many lawful and cultural forms without losing compatibility. Local names may differ, institutions may differ, sectors may differ, and communities may differ, but the governance meaning must remain record-valid, role-separated, public-safe, interoperable, and correctionable.
Last updated
Was this helpful?