> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/introduction/acceleration/v.-programs.md). # V. Programs Nexus programmes as target designs: the ten recorded offerings, the anchor programme families, accelerators and Academy, with their entry routes and limits. **Where this fits:** all six sectors · the [Foundry pillar](/organization/programme/foundry.md), with [Labs](/organization/programme/labs.md), [Nexus Universe](/organization/programme/universe.md) and [Risk Academy](/organization/programme/academy.md) · the [Nexus Consortium](/organization/institutions/nexus-consortium.md) and [National Nexus](/organization/governance-in-operation/national-nexus.md) · the Planning, Readiness preparation and Controlled build phases of [the programme year](/organization/programme/the-programme-year.md) · introduction to the deep doctrine. Canonical homes: [The Model](/organization/model.md) · [Systems](/organization/systems.md) · [Finance readiness](/organization/finance-readiness.md).
Document record · Draft · Legal review required · Updated 21 October 2026 | | | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Status** | Draft. Explanatory page; it creates no rights or obligations. | | **Legal review** | Required before final publication. | | **Version** | 2026.10.21-r3 | | **Updated** | 21 October 2026 · reviewed every 180 days | | **Owner** | Documentation desk (named reviewer pending) | | **Based on** | The consortium programme operating functions, offerings O01 to O10, participation pillars, service levels and separations, and the owner decision of 11 October 2026 on Nexus institutional architecture and participation, with GCRI Canada as lead contracting organization, in the Nexus institutional register; the consortium directives D-NEXUS-CONSORTIUM-PUBLIC-ARCHITECTURE-2 and D-NEXUS-CONSORTIUM-STAKEHOLDER-READINESS-3; Nexus constitutional directives D-V3-0003 (*Twenty-system constitution*) and D-V3-0004 (*One Rail-Two Stacks and non-execution*); the Nexus Documentation Standard (draft of 16 October 2026); the Nexus model and the Nexus Consortium model as published on the GCRI, GRF and GRA sites; [Nexus Standards](/organization/institutions/nexus-standards.md) as published at nexustandards.com | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
{% hint style="info" %} **Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service. {% endhint %} ## In brief A Nexus programme, in this documentation, is a governed pathway through which institutions, public authorities, researchers, communities and providers build the capability to use the shared rail: learning, applied work, simulation, readiness review and, where lawful, a handoff toward deployment. The main branch records ten programme offerings (O01 to O10) with stated questions, deliverables, entry routes and boundaries. All are designs at service level R0, information and enquiries; no programme, cohort or accelerator is recorded as running \[5]. ## Current position (21 October 2026) This section brings the page up to date with the published sites, the Nexus Standards and the owner's rulings of October 2026. Where the older text below differs, this section and the canonical pages it links govern. **Systems, not products.** The technology this page refers to is the [twenty Nexus systems](/organization/systems.md), each named by its display code (for example [NXS-COR](/organization/systems/nxs-cor.md) for compute and runtimes, [NXS-NET](/organization/systems/nxs-net.md) for networks, [NXS-FAC](/organization/systems/nxs-fac.md) for builds and verification, [NXS-NXQ](/organization/systems/nxs-nxq.md) for packages and capability lifecycle, [NXS-APP](/organization/systems/nxs-app.md) for the application catalogue and [NXS-RLS](/organization/systems/nxs-rls.md) for agreements and lawful handoffs). The build work is the [Foundry pillar](/organization/programme/foundry.md): "a configured or simulated capability is not a validated result, and a National Portfolio entry is not an investment decision" \[20]. Technology, infrastructure and service providers work with the Nexus Consortium at arm's length under written agreements. Programmes are now described as mission families of [Nexus Universe](/organization/programme/universe.md), governed by GRF, with the GCRI technical office preparing scientific and data readiness and GRA running the finance-readiness track. Action Week has ten tracks, from scientific methods and data to public evidence and communication \[21]. Learning runs through [Risk Academy](/organization/programme/academy.md): "a completion record is not a licence to practise, and no credential is issued until an accountable issuer, an assessment method and a revocation path are on record"; GCRI Canada is issuer of record \[22]\[20]. **Finance boundary.** National Consortium Companies and Project SPVs are structures that competent, lawful actors may form outside the programme, under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction, and readiness evidence is not a financing decision \[23]\[24]. Where this page describes such vehicles, read it with [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md) and [National portfolios](/organization/finance-readiness/national-portfolios.md). **National vocabulary.** A country programme is [National Nexus](/organization/governance-in-operation/national-nexus.md): a National Desk, a National Model, a National Portfolio and three participation pillars, the [National Nexus Consortium (NNC)](/organization/governance-in-operation/nnc.md), which institutions join through one of the six [Helix councils](/organization/governance-in-operation/councils.md) (State and Public Authorities, Industry and Operators, Academia and Research, Civil Society and Media, Community and Indigenous, and the cross-cutting Financial Institutions and Regulators pathway); the [National Leadership Council (NLC)](/organization/governance-in-operation/nlc.md) of leaders in a personal capacity; and the [National Working Groups (NWG)](/organization/governance-in-operation/nwg.md), with six domain response teams (CERTs) that are not emergency services. No national, regional or global consortium is recorded as constituted; all six regions and fifteen planned hubs are in formation, and the current service level is R0, information and enquiries \[25]\[26]. **Status.** Every programme is in formation and the current service level is R0, information and enquiries; no edition of [Nexus Reports](/organization/programme/reports.md) has been released and no [Risk Academy](/organization/institutions/risk-academy.md) credential has been issued \[26]\[27]. ## Status, scope and terms of this page **Programme status.** Programme status vocabulary: exploring, forming, constituted, active, paused, archived \[8]. For every programme family and offering on this page: Target: designed (this page and the consortium programme source \[5]). Implemented (constituted): No record. Verified: No record. Observed (active, with a dated published record): No record. Accepted: No record. The current service level is R0: "Enquiries go to the regional and country desks through the enquiry form, which gives each one a reference, or by email. Online applications, contribution payments, computing allocations and event registration open only when their service team, terms and review capacity are in place" \[5]. **Institutions.** The institutional roles that bear on this page are stated once, in register wording, on [I. Order of the Organization introduction](/organization/introduction/organization/i.-order.md): GCRI Canada ([The Global Centre for Risk and Innovation](/organization/institutions/gcri.md)) is Lead Institution, Consortium Secretariat and lead contracting organization; [The Global Risks Forum](/organization/institutions/grf.md) (GRF) is a consortium steward for leadership, dialogue and Nexus Universe programme governance; [The Global Risks Alliance](/organization/institutions/gra.md) (GRA) is a consortium steward for the finance, insurance and development-readiness interface; and competent public authorities keep all sovereign, regulatory, fiduciary and operational decisions \[3]. Standards discipline sits with [NXS-NSF](/organization/systems/nxs-nsf.md), the trust, sovereignty and assurance plane for identity, policy gates and access decisions, and Nexus Standards is a proposed standards programme with no publisher of record \[1]\[9]. **Programme names.** The anchor programme families in sections 5.12 to 5.26 keep their names as written, pending an owner ruling on proper names \[9]. "Sovereign Compute Program" names a programme about a public authority's control over its own estate; "sovereign" is not a product attribute \[3]. "Programs" in the page title is kept as a proper name; the text uses "programme". {% hint style="info" %} **Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol system, in collaboration with [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric, and [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. Together these three systems form the observatory ecosystem. **Nexus of Observatories.** Every Nexus platform and system includes its own observatory capability, covering remote sensing, in-situ instruments and edge deployments. Across every area where these observatories are implemented, including implementation pilots in programme areas, they form the Nexus of Observatories, which is part of the not-for-profit programme architecture. On this site, "Nexus Observatory" refers only to this observatory capability and to the protocol above. {% endhint %} {% hint style="info" %} **Earlier council labels.** This page still uses some labels from earlier versions of this corpus (investor council and helix participation, `Nexus Competence Cells`). These labels predate the current national vocabulary: National Nexus, with the National Nexus Consortium (NNC) and its six Helix councils, the National Leadership Council (NLC) and the National Working Groups (NWG) with their domain response teams ([Governance in operation](/organization/governance-in-operation.md)). Investor Council is a historical label whose nearest current counterpart is the Financial Institutions and Regulators pathway, led with GRA; the mapping of Competence Cells awaits owner decision ([Reference](/organization/reference.md)). Where they appear below they describe earlier design text, not current or constituted bodies \[8]\[9]. {% endhint %} ## Summary This page defines **Programs** within Nexus Acceleration. If **II. Compute** defines the technical estate intended for national control, **III. Edge** defines the distributed observatory and local-reality layer, and **IV. The Foundry pillar and the systems** defines the governed build, production, packaging, verification, and lifecycle architecture, then **V. Programs** defines the structured human and institutional pathways through which Nexus becomes understood, adopted, practiced, localized, tested, and carried by real organizations. Nexus Programs are the realization pathways of the ecosystem. They are not generic initiatives, campaign themes, educational slogans, pilot labels, or short-term projects. A Nexus Program is a governed pathway of action through which institutions, public authorities, universities, companies, communities, providers, sponsors, councils, guilds, national groups, regional groups, and implementation actors can enter the common rail, build capability, test readiness, form operating practice, and progress toward lawful deployment. Programs matter because architecture alone does not create capability. Standards alone do not train institutions. Compute alone does not produce adoption. Observatory Nodes alone do not create public trust. Foundry packages alone do not create readiness. [NXS-STU](/organization/systems/nxs-stu.md) (the builder and configuration workspace, which composes but never deploys) workflows alone do not create lawful use. Marketplace listings alone do not create responsible implementation. Consortiums alone do not create operational maturity. Programs are the layer through which the system becomes teachable, usable, participable, repeatable, locally meaningful, and institutionally absorbable. Through Programs, Nexus moves from architecture to capability. Through Accelerators, Nexus moves from capability to concentrated realization. Through Academy, Nexus moves from knowledge to competence. Through Simulation, Nexus moves from theory to rehearsed readiness. Through public authority learning, Nexus moves from exposure to lawful capacity. Through community and Indigenous knowledge pathways, Nexus moves from observation to safeguarded participation. Through social enterprise and open collaboration, Nexus moves from public-good design to distributed economic and civic participation. Through national and regional program pathways, Nexus moves from global architecture to sovereign-compatible deployment. *** ## 5.1 Why Programs Exist Programs exist because Nexus must be usable by the world it is designed to serve. A system may have sophisticated governance, standards, protocols, registries, compute estates, observatory nodes, and production environments, but still fail if people and institutions do not have structured ways to understand it, enter it, practice it, test it, adapt it, and carry it. Nexus operates across many contexts: * public authorities; * ministries; * municipalities; * universities; * communities; * Indigenous and local knowledge systems; * public-good institutions; * companies; * providers; * sponsors; * finance readers; * disaster risk and emergency systems; * climate and nature systems; * critical infrastructure; * telecom and edge environments; * AI and data systems; * National Nexus Consortiums; * Regional Nexus Consortiums; * National Consortium Companies; * Project SPVs; * and host institutions. These actors do not all begin at the same maturity level. Some need orientation. Some need public authority learning. Some need technical literacy. Some need observability pathways. Some need governance training. Some need domain packs. Some need simulation. Some need provider readiness. Some need community safeguards. Some need finance-readable readiness. Some need legal and institutional formation. Some need a full accelerator pathway. Programs exist to organize these differentiated entry points without fragmenting the common rail. They give Nexus a way to meet actors where they are while guiding them toward shared standards, public-good discipline, role separation, and lawful realization. *** ## 5.2 What Programs Mean in Nexus Within Nexus, Programs are structured, governed, repeatable, capability-building and realization-oriented pathways that translate the architecture into practical work. A Nexus Program may include: * orientation; * training; * Academy modules; * simulation; * exercises; * public authority learning; * community engagement; * Indigenous knowledge safeguards; * domain labs; * technical workshops; * Foundry-linked build pathways; * runtime practice based on NXS-STU; * observatory pathways; * node readiness; * host readiness; * provider onboarding; * sponsor orientation; * finance-reader literacy; * public-safe publication training; * national working group formation; * council and guild participation; * domain pack preparation; * accelerator tracks; * Marketplace readiness; * and lawful handoff pathways. Programs are not free-floating activities. They are tied to the wider Nexus architecture. A program should state: * its purpose; * its public-good rationale; * its steward or responsible pathway; * its relation to Nexus institutions; * its target participants; * its capability logic; * its outputs; * its maturity stages; * its public-safe boundaries; * its role boundaries; * its connection to Compute, Edge, Foundry, NXS-STU, Marketplace, Consortiums, or Campaign; * and its route to continuation, deployment, or completion. A program is valuable when it creates capability that can be recorded, repeated, improved, and connected back to the common rail. *** ## 5.3 The Programs Thesis of Nexus The Programs thesis of Nexus is that **a public-good-rooted, standards-bearing, sovereignty-compatible architecture can become real only if it has structured pathways that develop human capability, institutional readiness, public authority learning, community participation, technical literacy, provider discipline, sponsor understanding, finance-readable interpretation, and deployment maturity before and alongside technical realization**. This thesis has several implications. People must be trained before systems are trusted. Institutions must understand roles before they use outputs. Public authorities must understand capacity boundaries before dashboards are presented to them. Communities must have safeguard pathways before local knowledge is used. Providers must understand claims discipline before implementation. Sponsors must understand no-control before funding public-good capacity. Finance readers must understand readiness without treating it as execution. National groups must understand the chain from interest to working group, consortium, company, and Project SPV. Programs therefore reduce the gap between architecture and action. They turn complexity into navigable pathways. They make adoption progressive rather than abrupt. They allow Nexus to scale without pretending that every participant is ready for full deployment on day one. *** ## 5.4 Programs as Realization Pathways, Not Generic Initiatives A Nexus Program is not a general initiative. It is not a public-relations campaign. It is not a theme. It is not a loose set of events. It is not a pilot label. It is not a donor project. It is not an informal community of interest. A Nexus Program is a realization pathway. It is designed to create movement from understanding to capability, from capability to readiness, from readiness to structured deployment, and from deployment to lifecycle learning. This requires discipline. Every program should have: * defined scope; * intended participants; * stage model; * learning architecture; * output classes; * public-safe rules; * records; * correction pathway; * maturity pathway; * governance link; * and continuation logic. Programs prevent Acceleration from becoming only infrastructure deployment. They ensure that people, institutions, communities, and ecosystems can actually carry what Nexus builds. *** ## 5.5 Programs in the Acceleration Stack Programs sit between architecture and deployment. They connect the other Acceleration layers. **Compute** gives programs technical estate. **Edge** gives programs local observability and field truth. **Foundry** gives programs packages, workflows, playbooks, evidence templates, and deployment units. **NXS-STU** gives programs live or controlled runtime environments for learning, simulation, dashboards, and workflow practice. **Marketplace** gives programs discoverable tools, packs, providers, services, and training objects. **Consortiums** give programs institutional fields, councils, working groups, national pathways, and regional support. **Campaign** gives programs large-scale activation and public narrative momentum. Programs are therefore the adoption and capability layer of Acceleration. They make the rest of the stack usable. *** ## 5.6 Programs as the Human Acceleration Layer Nexus cannot accelerate through technology alone. The most important constraint in many contexts will not be compute capacity. It will be human and institutional capacity. Programs address this by developing: * conceptual literacy; * standards literacy; * governance literacy; * public-safe literacy; * evidence literacy; * data literacy; * AI-use literacy; * public authority capacity literacy; * finance-boundary literacy; * node operation capability; * host readiness; * provider discipline; * sponsor discipline; * community safeguard capability; * council and guild readiness; * and lifecycle responsibility. A technically strong rail can fail if users do not understand it. A public dashboard can mislead if operators do not understand public-safe boundaries. A finance-readable pack can be misused if readers do not understand non-execution. A public authority learning environment can be overclaimed if participants do not understand capacity classifications. Programs build the competence required for trustworthy use. *** ## 5.7 Academy as the Core Learning Infrastructure of Programs **Risk Academy** is the core learning infrastructure of the Programs layer. Academy provides structured learning pathways for individuals, institutions, councils, guilds, providers, public authorities, community participants, sponsors, developers, operators, students, and national or regional actors. Academy may include: * foundational Nexus orientation; * public-good stack training; * one rail / two stacks training; * non-execution training; * standards and ontology literacy; * Registry and status literacy; * protocol and entitlement literacy; * public-safe publication training; * evidence and proof training; * [NXS-GRX](/organization/systems/nxs-grx.md) (the global data and risk intelligence engine) training; * Edge and Observatory Node training; * NXS-STU user training; * Foundry builder training; * Marketplace training; * public authority learning modules; * finance-reader training; * sponsor no-control training; * community safeguards training; * Indigenous knowledge protection training; * provider claims training; * node operator training; * council readiness training; * national pathway training; * Project SPV boundary training; * and train-the-trainer programs. Academy makes the architecture teachable. Programs make Academy applied. Together, they create the human capability layer of Nexus. *** ## 5.8 Program Stages Nexus Programs should operate through clear stages. A typical program pathway may include: ### 5.8.1 Orientation Participants learn what Nexus is, what the relevant program covers, what role separation requires, what public-good and enterprise boundaries apply, and what the pathway may lead to. ### 5.8.2 Literacy Participants develop specific knowledge of standards, governance, domain concepts, public-safe rules, evidence logic, technical components, finance boundaries, or public authority capacity. ### 5.8.3 Capability Formation Participants begin practicing with tools, templates, workflows, simulations, domain packs, NXS-STU environments, or Foundry outputs. ### 5.8.4 Applied Work Participants work on real or realistic contexts, such as a city, watershed, institution, corridor, public authority learning case, community observatory, domain pack, or readiness pathway. ### 5.8.5 Readiness Review The program assesses whether the participant, institution, node, host, provider, community, or national group is ready for deeper pathway progression. ### 5.8.6 Accelerator or Deployment Pathway Where maturity is sufficient, the program may feed into a Nexus Accelerator, Foundry package, NXS-STU runtime, Marketplace object, National Working Group, National Nexus Consortium, National Consortium Company, Project SPV, or other lawful implementation pathway. The company and SPV steps are taken, if at all, by competent actors outside the programme. ### 5.8.7 Lifecycle Learning Programs should capture lessons, corrections, gaps, public-safe issues, training needs, and future improvements. This staged approach protects Nexus from asking too much too early. It allows maturity to build truthfully. *** ## 5.9 Program Outputs Programs should produce typed outputs. Program outputs may include: * orientation records; * completion records; * training materials; * Academy modules; * simulation exercises; * readiness reports; * public-safe summaries; * working group records; * domain pack requirements; * node-readiness notes; * host-readiness notes; * public authority learning records; * community safeguard records; * sponsor no-control records; * provider onboarding records; * finance-reader learning records; * maturity progression records; * accelerator intake records; * Foundry requirements; * NXS-STU workflow feedback; * Marketplace readiness notes; * national pathway records; * and correction notices. These outputs must be classified. A training completion is not authority. A readiness note is not certification. A simulation report is not public warning. A public authority learning record is not adoption. A provider onboarding record is not procurement approval. A sponsor participation record is not sponsor control. Program outputs create continuity only when they state what they are and what they are not. *** ## 5.10 Nexus Accelerators Within the Program Layer Nexus Accelerators are structured deployment-intensification pathways inside the broader Programs architecture. They are not generic incubators. They are not venture demo days. They are not startup contests. They are not publicity exercises. A Nexus Accelerator is a governed pathway that helps a domain, city, institution, sovereign pathway, regional corridor, infrastructure system, public authority learning environment, or public-purpose use case move from intent and capability toward operating readiness under standards, governance, compute, observability, Foundry, NXS-STU, Academy, host, public-safe, finance-readable, and lawful handoff discipline. An accelerator may include: * domain definition; * challenge framing; * actor mapping; * host assessment; * data and observability assessment; * domain pack selection; * Foundry package preparation; * NXS-STU workflow rehearsal; * public authority learning sessions; * community safeguards; * sponsor structure; * provider onboarding; * finance-readable readiness preparation; * simulation; * readiness review; * and deployment pathway design. Accelerators create concentrated motion. Programs build the broader field that makes such motion possible. *** ## 5.11 Accelerator Non-Execution Boundaries Accelerators must preserve non-execution boundaries. An accelerator cohort is not deployment. An accelerator graduation is not certification. An accelerator report is not recognition unless separately recorded. An accelerator demo is not public authority adoption. An accelerator dashboard is not public warning. An accelerator readiness product is not investment advice. An accelerator sponsor is not a controller. An accelerator participant is not a qualified provider by default. An accelerator concept is not a formed Project SPV. The accelerator model is powerful only when it preserves stage truth. Its purpose is to close readiness gaps, not manufacture false maturity. *** ## 5.12 Anchor Program Families The Nexus program architecture includes anchor program families. These are the primary public-purpose and realization pathways through which the architecture enters the world. The anchor program families are: * Sovereign Compute Program; * Risk Management; * Community Science; * Systems Innovation; * Reverse Mentorship; * Social Enterprise; * Open Collaboration; * Indigenous Knowledge; * Sustainable Development; * Anticipatory Action. These are not isolated verticals. They are interdependent pathways within one realization architecture. Each should have its own curriculum, operating model, output logic, maturity path, public-safe rules, and connection to the wider Nexus stack. *** ## 5.13 Sovereign Compute Program The **Sovereign Compute Program** is the pathway through which institutions, countries, regions, hosts, universities, public authorities, providers, and enterprise actors learn, assess, design, prepare, and adopt compute environments under national control. As a program, the Sovereign Compute Program translates the technical estate into institutional readiness. It may include: * orientation to compute under national control; * systems-family literacy; * dense core design pathways; * regional cluster literacy; * node and host readiness; * data residency analysis; * public authority capacity training; * cloud, edge, and hybrid architecture pathways; * AI fabric training; * cybersecurity and privacy training; * degraded-mode planning; * serviceability assessment; * partner and OEM readiness; * procurement-neutral specification; * public-good / enterprise separation; * and lifecycle planning. The program should help participants understand that compute under national control is not simply cloud localization. It is a governed technical estate involving compute, observability, evidence, trust, access, serviceability, and sovereignty-compatible operation. A Sovereign Compute Program outcome may support future deployment, but it is not deployment by itself. In the institutional records the closest recorded offering is O03, Sovereign Data, Compute and AI Capability, whose boundary is that "A blueprint is not an installed environment, and requested capacity is not allocated capacity" \[5]. *** ## 5.14 Risk Management Program The **Risk Management Program** is the pathway through which institutions move from fragmented risk awareness to integrated, evidence-bearing, cross-domain, anticipatory risk capability. Nexus Risk Management should address: * systemic risk; * cascading risk; * climate risk; * disaster risk; * infrastructure risk; * cyber-physical risk; * public health and One Health risk; * biodiversity and nature risk; * supply-chain and logistics risk; * finance-readable risk; * public authority capacity risk; * AI and exponential technology risk; * and institutional resilience. The program may include: * integrated risk-governance training; * NXS-GRX literacy; * observability training; * scenario and simulation exercises; * domain risk packs; * institutional risk architecture design; * readiness diagnostics; * public-safe risk communication; * public authority learning; * and correctionability training. Risk Management in Nexus is not static compliance. It is a governed intelligence and readiness pathway. It helps institutions understand risk as a living system rather than a periodic report. *** ## 5.15 Community Science Program The **Community Science Program** is the pathway through which local observation, civic participation, lived experience, and place-based intelligence can contribute to Nexus under safeguard discipline. Community Science may include: * community observatory pathways; * citizen science methods; * local environmental monitoring; * community resilience mapping; * participatory sensing; * local hazard reporting; * public-safe dashboards; * accessibility and language support; * community review circles; * local data rights; * protected participation; * grievance and correction pathways; * and community-facing Academy modules. Community Science must be neither decorative nor extractive. A community contribution is not open data by default. A local participant does not speak for all community interests by default. A community dashboard is not community endorsement unless recorded. Community Science gives local knowledge a pathway into the rail while preserving dignity, consent, restrictions, safeguards, and correction rights. *** ## 5.16 Systems Innovation Program The **Systems Innovation Program** is the pathway through which Nexus supports structured experimentation across domains, institutions, technologies, and ecological systems. It may include: * systems design labs; * cross-domain challenge programs; * policy simulation; * public-purpose innovation sprints; * domain pack ideation; * Foundry build challenges; * NXS-STU workflow prototyping; * public authority learning labs; * field-to-Foundry feedback sessions; * ecosystem mapping; * and transformation pathway design. Systems Innovation in Nexus is not novelty for its own sake. It is disciplined experimentation connected to standards, ontology, evidence, public-good governance, and lifecycle learning. It helps participants design integrated solutions where problems cross institutional boundaries. *** ## 5.17 Reverse Mentorship Program The **Reverse Mentorship Program** is the pathway through which younger practitioners, emerging technologists, students, community innovators, and nontraditional knowledge holders can inform senior institutional actors and governance stewards. This program responds to a major failure in many institutions: learning moves too slowly upward. Reverse Mentorship may include: * intergenerational cohorts; * youth and emerging-practitioner councils; * leadership learning sessions; * frontier technology briefings; * community innovator exchanges; * digital culture and AI literacy exchanges; * climate and future-systems dialogues; * and structured learning records. Reverse Mentorship does not replace governance. It informs governance. It gives Nexus a way to reduce generational lag, keep institutional learning alive, and make future-facing intelligence visible to decision-makers. *** ## 5.18 Social Enterprise Program The **Social Enterprise Program** is the pathway through which mission-aligned ventures, community enterprises, public-interest businesses, local providers, and social innovators can participate in the Nexus ecosystem. It may support: * social enterprise design; * mission-aligned venture formation; * Marketplace readiness; * provider pathway orientation; * community enterprise models; * local resilience business models; * public-good sustainability models; * sponsor-supported enterprise pathways; * readiness evidence for actors who consider a National Consortium Company outside the programme; * Project SPV literacy; * and local implementation capability. Social Enterprise is important because Nexus must not treat economic activity as separate from public purpose. But the program must preserve boundaries. A social enterprise is not a public-good steward by default. A mission-aligned company is not a public authority. Marketplace participation is not recognition. Provider readiness is not procurement approval. Social Enterprise creates public-purpose economic pathways without allowing enterprise activity to capture the public-good stack. *** ## 5.19 Open Collaboration Program The **Open Collaboration Program** is the pathway through which contributors, developers, researchers, institutions, universities, communities, and partners can collaborate on Nexus-aligned public-good and technical work. It may include: * open-source contribution pathways; * Digital Public Good maintenance; * open standards workshops; * schema and ontology contributions; * issue triage; * documentation sprints; * public-safe template improvement; * data dictionary work; * community translation; * GitHub or repository workflows; * contributor governance; * maintainer training; * and open collaboration events. Open Collaboration is governed openness. It is not uncontrolled contribution. It must preserve: * licensing; * contributor agreements where required; * security review; * code review; * public-safe review; * semantic governance; * versioning; * attribution; * and maintainer authority. Open Collaboration allows Nexus to grow as a public-good architecture without becoming incoherent. *** ## 5.20 Indigenous Knowledge Program The **Indigenous Knowledge Program** is the pathway through which Indigenous epistemologies, stewardship practices, governance perspectives, relational knowledge, place-based knowledge, and long-horizon ecological intelligence may engage Nexus under respect, consent, protection, and self-determination. This program must be designed with exceptional care. It may include: * Indigenous-led participation pathways; * knowledge protection protocols; * community-defined restrictions; * place-based stewardship programs; * Indigenous data governance; * cultural knowledge safeguards; * sensitive geography controls; * benefit and reciprocity models; * public-safe translation rules; * governance dialogue; * and Indigenous-led review processes. Indigenous Knowledge must not be extracted into datasets. It must not be reduced to content. It must not be used for legitimacy signaling without authority. It must not be translated into public outputs without consent and safeguards. The program should support interfaces between Indigenous knowledge systems and Nexus observability without forcing Indigenous knowledge to become the property of the rail. *** ## 5.21 Sustainable Development Program The **Sustainable Development Program** is the pathway through which Nexus supports resilient, equitable, long-horizon development across communities, institutions, sectors, and territories. This program is not a generic SDG label. It is the structured route through which Nexus connects public-purpose infrastructure, observability, risk intelligence, finance-readable evidence, public authority learning, social enterprise, community science, and regional/national pathways to real development challenges. It may include: * development-readiness pathways; * resilient infrastructure planning; * WEFH systems pathways; * biodiversity and nature pathways; * city and regional resilience programs; * public-good observatory support; * development finance readiness; * community capacity building; * public-safe progress reporting; * and sustainability-linked Academy modules. Sustainable Development in Nexus must remain evidence-bearing and systems-aware. It should avoid vague impact claims. It should distinguish activity, output, outcome, contribution, and impact. *** ## 5.22 Anticipatory Action Program The **Anticipatory Action Program** is the pathway through which Nexus helps institutions reduce the distance between early signals and lawful, disciplined, prepared response. It may include: * early signal literacy; * trigger design; * readiness states; * scenario planning; * simulation exercises; * pre-event planning; * playbook development; * public authority learning; * community preparedness; * disaster risk intelligence; * public-safe communication; * finance-readable preparedness evidence; * after-action learning; * and correction loops. Anticipatory Action is not automatic action. A trigger is not a public warning. A preparedness workflow is not emergency command. A simulation is not operational instruction. A readiness state is not public authority action. The program helps institutions prepare earlier while preserving lawful authority, public-safe boundaries, and non-execution discipline. *** ## 5.23 Public Authority Learning Program Public Authority Learning should be treated as a major cross-cutting program pathway. It supports public authorities in understanding Nexus without implying adoption, delegation, approval, or official use by default. Public Authority Learning may include: * orientation to Nexus; * public authority capacity classification; * dashboard literacy; * NXS-STU workflow demonstrations; * public-safe reporting literacy; * public warning boundary training; * procurement-neutral standards guidance; * literacy in compute under national control; * data residency and privacy sessions; * simulation exercises; * public records considerations; * emergency authority boundaries; * public health authority boundaries; * finance non-execution literacy; * and lawful handoff pathways. A public authority learning session is not adoption. A public authority dashboard view is not approval. A public authority simulation is not emergency command. A public authority participant is not a delegation of legal power. This pathway is essential for sovereignty-compatible adoption. *** ## 5.24 Provider Readiness Program Nexus should include a Provider Readiness pathway within Programs. Qualified providers are necessary for implementation, support, maintenance, localization, integration, cybersecurity, data pipelines, cloud deployment, edge deployment, node support, Marketplace services, and customer success. Provider Readiness may include: * Nexus architecture training; * role separation training; * claims discipline; * data governance; * public-safe rules; * finance-boundary rules; * NXS-STU training; * Foundry training; * Marketplace listing requirements; * support obligations; * provider qualification pathways (no certificate is issued); * partner agreements; * security requirements; * conflict policies; * and audit readiness. Provider Readiness does not automatically create procurement preference. It does not make a provider standards authority. It does not make a provider public-good steward. It prepares providers to operate within Nexus without overclaiming their role. *** ## 5.25 Sponsor Orientation Program Sponsors may support Nexus public-good capacity, but they must understand support-without-control. A Sponsor Orientation Program may cover: * public-good sustainability; * sponsor no-control; * public-safe review; * claims discipline; * community safeguards; * public authority boundaries; * finance-boundary language; * registry and recognition boundaries; * open-source maintenance support; * correction reserves; * accessibility and translation support; * public accountability reporting; * and sponsor exit rules. A sponsor contribution is not control. A sponsor report is not verified impact unless supported by record. Sponsor support is not public authority approval. Sponsor visibility is not recognition. Sponsor Orientation protects Nexus from funding-driven capture. *** ## 5.26 Finance-Reader Literacy Program Finance readers need structured orientation so they can use Nexus outputs responsibly. Finance-Reader Literacy may include: * finance-readable evidence concepts; * literacy in GRA finance-readiness mappings; * resilience evidence; * project-readiness evidence; * disaster risk finance evidence; * adaptation finance evidence; * sponsor-capital frameworks; * portfolio observability; * reliance boundaries; * non-advice language; * non-underwriting language; * non-rating language; * parametric-trigger support boundaries; * Project SPV boundary training; * and finance non-execution discipline. A finance-readable output is not a finance decision. A project-readiness pack is not bankability. A portfolio resilience dashboard is not investment advice. A parametric-trigger support pack is not payout determination. The Finance-Reader Literacy pathway allows Nexus to support finance without becoming finance. *** ## 5.27 Council, Guild, and Membership Program Pathways Programs should support the cooperation architecture. Participants may enter Nexus through members, guilds, councils, domains, working groups, and pathways. Program pathways may prepare participants for: * membership; * good-standing requirements; * guild contribution; * domain participation; * council readiness; * leadership development; * literacy for the Financial Institutions and Regulators pathway (earlier label: investor council literacy); * Helix pathway participation (earlier label: helix participation); * workstream ownership; * records-valid acts; * conflict and recusal rules; * public claims discipline; * and correction responsibilities. Membership is not authority. Guild participation is not governance. Council candidacy is not appointment. Working group participation is not recognition. Programs help participants understand these distinctions before deeper roles are granted. *** ## 5.28 National and Regional Program Pathways Programs should support national and regional formation. A national pathway may move through: * country orientation; * public authority learning; * stakeholder mapping; * National Working Group formation; * domain program activation; * council formation; * National Nexus Consortium formation; * the boundary with National Consortium Companies, which competent actors consider outside the programme; * provider readiness; * sponsor alignment; * public-safe outputs; * and readiness evidence for actors who consider a Project SPV outside the programme, where appropriate. A regional pathway may include: * corridor program design; * regional observability pathways; * regional support logic; * cross-country learning; * shared ecology programs; * regional council and working group support; * support-versus-comparable classification; * and regional-to-national handoff. These pathways must preserve stage truth. A national program is not a National Nexus Consortium. A National Working Group is not a National Consortium Company. A Project SPV concept is not a formed SPV. A regional program is not regional supremacy. Programs make formation disciplined. *** ## 5.29 Programs and Marketplace Programs should connect to Marketplace without being reduced to Marketplace. Programs may produce Marketplace-ready objects such as: * training modules; * domain packs; * public-safe templates; * NXS-STU workflow packages; * Foundry build packages; * simulation packs; * provider services; * Academy courses; * community science toolkits; * finance-reader learning packs; * public authority learning packs; * and implementation support offerings. Marketplace makes these objects discoverable. Programs create capability around them. A Marketplace listing is not program completion. A programme learning record is not a Marketplace listing or a certificate: "A learning record is not a professional licence or a promise of employment" \[5]. A training object is not authority. The relationship should be governed by object typing, status, support, claims, and lifecycle rules. *** ## 5.30 Programs and Foundry Programs and Foundry should form a learning loop. Programs reveal needs. Foundry converts needs into packages. Programs test packages. Foundry improves packages. Programs identify training gaps. Foundry improves tools and workflows. Programs surface public-safe issues. Foundry updates templates. Programs reveal host conditions. Foundry refines deployment units. This loop is one of the strongest mechanisms for Nexus maturity. Programs prevent Foundry from building in abstraction. Foundry prevents Programs from remaining informal. *** ## 5.31 Programs and NXS-STU Programs should use NXS-STU as a controlled runtime learning and practice environment. NXS-STU may support: * dashboards; * simulations; * exercises; * workflow training; * public authority learning; * domain pack practice; * node operation training; * evidence review; * public-safe output preparation; * and finance-reader learning. NXS-STU use in Programs must preserve boundaries. A training dashboard is not operational authority. A simulation is not real-world warning. A scenario exercise is not lawful decision-making. An NXS-STU output in a program is not public-safe publication unless reviewed. Programs should teach users how to use NXS-STU responsibly before live deployment. *** ## 5.32 Programs and Edge Programs should make Edge usable by people and institutions. Edge-related programs may include: * observatory node training; * local sensing pathways; * field validation; * community science methods; * Indigenous knowledge safeguards; * node operator training; * data stewardship; * confidence and uncertainty literacy; * drift detection literacy; * evidence-candidate handling; * public-safe map preparation; * and local-to-regional observability training. Edge data is powerful. Programs teach users how not to overread it. They help participants distinguish signals, observations, evidence candidates, and decisions. This is essential for public trust. *** ## 5.33 Programs and Compute Programs should prepare institutions to adopt and govern compute. Compute-related programs may include: * literacy in compute under national control; * host readiness; * node readiness; * data custody; * cybersecurity; * degraded-mode operation; * serviceability; * lifecycle support; * public authority capacity; * provider roles; * AI fabric governance; * communications resilience; * and sustainability planning. Compute adoption without programmatic preparation creates risk. Programs turn compute from infrastructure into institutional capability. *** ## 5.34 Programs and Public-Safe Outputs Programs often produce public-facing outputs. These may include: * reports; * briefings; * learning summaries; * public dashboards; * public authority learning summaries; * community reports; * sponsor reports; * case studies; * media materials; * Academy materials; * and campaign outputs. Public-safe discipline must apply. Program outputs should not expose sensitive information, overstate maturity, imply adoption, imply authority, imply finance effect, imply community endorsement, or imply sponsor control. A program page should state status, scope, audience, and non-effect where needed. Programs should model the claims discipline they teach. *** ## 5.35 Program Governance Programs require governance. Program governance should address: * program approval; * program steward; * scope; * curriculum; * participant eligibility; * public-safe review; * community safeguards; * Indigenous knowledge protocols; * public authority capacity; * provider participation; * sponsor role; * finance-reader boundaries; * data governance; * output classification; * training records; * progression criteria; * accelerator intake; * Marketplace readiness; * correction; * withdrawal; * renewal; * and decommissioning. Programs should not be launched as informal activity when they carry institutional meaning. A mature program architecture must be record-valid, role-separated, and correction-capable. *** ## 5.36 Program Records Program records may include: * program charter; * curriculum version; * participant records; * cohort records; * training completion records; * simulation records; * exercise records; * public authority learning records; * community safeguard records; * sponsor no-control records; * provider readiness records; * finance-reader training records; * outputs; * corrections; * public-safe reviews; * readiness assessments; * progression records; * and archive records. Records protect both Nexus and participants. They show what occurred. They show what did not occur. They help prevent training, participation, or attendance from being overclaimed as authority or maturity. *** ## 5.37 Program Maturity Model Programs themselves should have maturity states. A program may be: * concept; * proposed; * scoped; * pilot; * active; * supported; * repeatable; * verified for internal use where applicable (no certificate is issued); * Marketplace-ready where applicable; * accelerator-linked; * nationally localized; * regionally adapted; * suspended; * retired; * or archived. A pilot program should not be described as a mature program. A regionally adapted program should not be described as universally portable. A retired program should not appear current. Program maturity should be visible in the knowledge base and Registry where material. *** ## 5.38 Program Sustainability Programs require sustainability. A program should identify how it will be funded, maintained, updated, taught, supported, translated, corrected, and retired. Program sustainability may include: * membership support; * Academy fees; * sponsorship under no-control rules; * public authority support; * enterprise package allocation; * Marketplace revenue; * training revenue; * public-good reserves; * grants; * philanthropic support; * and national or regional contributions. Sustainability must not create capture. Funding a program does not allow a sponsor to control curriculum, findings, public-safe outputs, recognition, or progression. Programs should not be launched without a maintenance and update plan. No programme fee, contribution or revenue line is recorded. Contribution payments open only when their service team, terms and review capacity are in place, and ordinary working-group participation has no fee \[5]. *** ## 5.39 Program Accessibility and Translation Programs must be accessible to intended audiences. Accessibility may include: * plain-language materials; * expert materials; * multilingual versions; * screen-reader compatible formats; * low-bandwidth options; * recorded sessions; * printable guides; * visual explainers; * glossary support; * regional localization; * community briefings; * and role-specific learning paths. Accessibility does not mean oversimplification. A plain-language version must preserve boundaries, uncertainty, non-effect, and claims discipline. Programs should be rigorous enough for experts and navigable enough for broader institutional use. *** ## 5.40 Programs and External Organizations Programs are designed so external organizations can use Nexus as a resource. A public authority can use programs for learning, public-safe literacy, observability, simulation, and lawful adoption preparation. A company can use programs for provider readiness, Marketplace participation, Foundry understanding, NXS-STU use, and enterprise boundary discipline. A university can use programs for research-to-practice pathways, Academy, Community Science, Open Collaboration, Digital Public Goods, and working groups (earlier label: competence cells). A sponsor can use programs to support public-good capacity without control. A community organization can use programs for Community Science, safeguards, local observability, and correction pathways. A finance reader can use programs to understand finance-readable evidence without mistaking it for finance execution. A national group can use programs to move from orientation to working group, consortium, company, and Project SPV readiness. Programs make Nexus teachable as a global resource. *** ## 5.41 Program Failure Modes Nexus should be explicit about program failure modes. **Program-as-brand failure** occurs when a program is a name without operating model, curriculum, outputs, records, or pathway. **Training-without-capability failure** occurs when participants attend sessions but do not gain usable competence. **Pilot trap failure** occurs when programs generate one-off pilots that never become reusable packages, records, or deployment units. **Readiness inflation** occurs when program participation is described as maturity, certification, adoption, or deployment. **Public authority overclaim** occurs when public authority learning is described as approval, adoption, warning authority, or official decision. **Sponsor capture** occurs when sponsors shape program content, outputs, claims, or public-safe review. **Provider capture** occurs when providers use program participation to imply qualification, procurement preference, or standards authority. **Community extraction** occurs when local knowledge is gathered without safeguards, benefit, consent, or correction rights. **Indigenous knowledge extraction** occurs when Indigenous knowledge is translated into the rail without Indigenous-led governance and protection. **Finance overclaim** occurs when finance-reader training or project-readiness work is treated as investment advice, underwriting, rating, or capital commitment. **Academy credential inflation** occurs when learning completion is described as professional authority beyond scope. **Marketplace drift** occurs when program outputs are listed or sold without support, status, or claims discipline. **Decommissioning failure** occurs when programs end without archiving, withdrawal, correction, or transition. Program governance exists to prevent these failures. *** ## 5.42 Strategic Value of Programs The strategic value of Programs is that they turn Nexus into a living architecture. Programs allow Nexus to: * educate without oversimplifying; * build capability without overclaiming readiness; * support public authorities without becoming public authority; * engage communities without extracting knowledge; * support Indigenous knowledge without appropriating it; * activate providers without surrendering standards; * orient sponsors without allowing control; * support finance readers without executing finance; * prepare national and regional pathways without inflating stage; * train users for NXS-STU and Foundry; * prepare hosts for Compute and Edge; * produce Academy pathways; * create accelerator readiness; * and turn field learning into system improvement. In strategic terms, Programs are the social and institutional operating layer of Acceleration. They make Nexus inhabitable. *** ## 5.43 Final Statement on Nexus Programs Nexus Programs are the structured realization pathways through which the Nexus Ecosystem converts architecture into human capability, institutional readiness, applied deployment, and public-purpose impact. They are the layer through which public authorities learn without being overclaimed, communities participate without extraction, Indigenous knowledge is protected rather than appropriated, providers become disciplined rather than self-authorizing, sponsors support without control, finance readers understand without executing finance, universities contribute without losing research integrity, and national or regional actors progress without false maturity. Through the Sovereign Compute Program, Risk Management, Community Science, Systems Innovation, Reverse Mentorship, Social Enterprise, Open Collaboration, Indigenous Knowledge, Sustainable Development, Anticipatory Action, Academy, public authority learning, provider readiness, sponsor orientation, finance-reader literacy, simulation, accelerator pathways, national formation, and regional adaptation, Nexus creates a program architecture broad enough to be useful and disciplined enough to remain coherent. Programs are where the rail becomes teachable. Programs are where participation becomes capability. Programs are where capability becomes readiness. Programs are where readiness can enter acceleration. Programs are where acceleration becomes responsible. They ensure that Nexus does not become only a doctrine, platform, standard, dashboard, marketplace, or infrastructure estate. They ensure that Nexus becomes a lived, learned, practiced, safeguarded, and institutionally carried public-good architecture. *** ## Next steps Read **VI. Marketplace** to understand how program outputs, training objects, packs, providers, connectors, services, and deployment-support resources become discoverable and usable under governed rules. Read **VII. Consortiums** to understand how programs move into regional, national, institutional, company, and Project SPV pathways. The company and SPV steps are taken, if at all, by competent actors outside the programme. Read **VIII. Campaign** to understand how mature programs become part of coordinated global activation. Read **IV. The Foundry pillar and the systems** to understand how program needs become packages, workflows, deployment units, and Marketplace objects. Read **III. Edge** to understand how Community Science, Indigenous Knowledge, Risk Management, and Anticipatory Action connect to observatory nodes and local reality. *** ## The ten programme offerings recorded in the institutional register The consortium programme in the institutional records states ten offerings. Each names the question it answers, the work, the deliverables, an entry route, a boundary and the canonical systems it draws on. They are the most precise recorded statement of what a Nexus programme is meant to do, and they are designs: "Where the programme is a target architecture, verbs say 'is designed to'" \[5]. *Table 1. Programme offerings O01 to O10. Questions and boundaries quoted from the consortium programme source \[5]; status per the Nexus Documentation Standard \[9], as of 2026-10-16.* | Id | Offering | Question it answers (quoted) | Boundary (quoted) | Systems named | Status | | --- | ------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | O01 | National Risk, Innovation and Portfolio Baseline | "What systems matter most, where are material dependencies and evidence gaps, and which capabilities or interventions deserve further work?" | "National adoption is a separate decision of the competent authority. A country profile never implies a government commission where none exists." | [NXS-CMD](/organization/systems/nxs-cmd.md), NXS-GRX, [NXS-DSS](/organization/systems/nxs-dss.md), [NXS-NST](/organization/systems/nxs-nst.md), [NXS-POR](/organization/systems/nxs-por.md) | Target only; implemented, verified, observed, accepted: No record | | O02 | Sector and Critical-Infrastructure Resilience | "How could a shock propagate through essential services, and which changes warrant testing?" | "Participation gives Nexus no control of operational technology. Exercises carry no live actuation, incident command or warning authority." | NXS-GRX, NXS-DSS, NXS-NET, NXS-OPS, NXS-NST | Target only; implemented, verified, observed, accepted: No record | | O03 | Sovereign Data, Compute and AI Capability | "What technical environment can support national work without unnecessary dependency or loss of control?" | "A blueprint is not an installed environment, and requested capacity is not allocated capacity." | NXS-COR, NXS-NET, NXS-NSF, NXS-NXQ, NXS-FAC | Target only; implemented, verified, observed, accepted: No record | | O04 | Responsible Innovation and Interoperability Testbeds | "Does a candidate technology solve the intended problem under representative operating conditions?" | "Sponsorship never influences a result. Testbed participation is not a regulatory sandbox, a certification or a procurement status." | [NXS-LAB](/organization/systems/nxs-lab.md), NXS-FAC, NXS-NXQ, NXS-STU, NXS-APP | Target only; implemented, verified, observed, accepted: No record | | O05 | Multi-Hazard and Anticipatory-Action Preparedness | "Can evidence, warnings, institutions and preparedness actions work together under pressure?" | "Public-safety exercises carry clear simulation marking and stop-work controls. Nexus is not an emergency-dispatch service." | [NXS-EWS](/organization/systems/nxs-ews.md), [NXS-AAP](/organization/systems/nxs-aap.md), NXS-EOP, NXS-DSS, NXS-NST | Target only; implemented, verified, observed, accepted: No record | | O06 | Cross-Border and Shared-System Missions | "Which interdependencies cross borders, mandates or organisations, and how can compatible evidence improve decisions?" | "Federation creates no treaty, customs arrangement, sovereignty transfer or right to move data." | NXS-GRX, NXS-RLS, NXS-NSF, NXS-NET, NXS-DSS | Target only; implemented, verified, observed, accepted: No record | | O07 | Finance, Insurance and Development Readiness | "What evidence does a competent financial institution need to evaluate resilience needs and possible interventions?" | "No promise of funding, underwriting, a bankability rating, capital or a transaction. Readiness evidence is not a financing decision." | NXS-GRX, NXS-DSS, NXS-RLS, NXS-CMD, NXS-POR | Target only; implemented, verified, observed, accepted: No record | | O08 | Leadership, Academy and Workforce Formation | "What human capability must improve for the programme to last?" | "A learning record is not a professional licence or a promise of employment." | [NXS-HUB](/organization/systems/nxs-hub.md), NXS-STU, NXS-LAB, NXS-CMD | Target only; implemented, verified, observed, accepted: No record | | O09 | Annual Universe Missions and Contributed Infrastructure | "Which of the year's missions need temporary technical intensity and a controlled proving environment?" | "Neither membership nor sponsorship guarantees a compute allocation." | NXS-COR, NXS-NET, NXS-LAB, NXS-FAC, NXS-APP | Target only; implemented, verified, observed, accepted: No record | | O10 | Research, Publications and Evidence Services | "What can responsibly be concluded and shared from the accumulated work?" | "No paid favourable editorial position and no guaranteed publication outcome." | NXS-POR, NXS-GRX, NXS-LAB, NXS-HUB | Target only; implemented, verified, observed, accepted: No record | ## Anchor programme families and the recorded offerings The anchor programme families in sections 5.12 to 5.26 are this documentation's vocabulary. Table 2 shows the recorded offering each family is closest to, so that a reader can find the main-branch boundary that applies. The mapping is editorial and awaits owner review. *Table 2. Programme families mapped to recorded offerings. Mapping by this documentation, as of 2026-10-16.* | Family (section) | Closest recorded offering | Status | | ---------------------------------------- | -------------------------------------------------- | --------- | | Sovereign Compute Program (5.13) | O03; O09 for contributed infrastructure | No record | | Risk Management Program (5.14) | O01, O02 | No record | | Community Science Program (5.15) | O05, O10; community stakeholder route | No record | | Systems Innovation Program (5.16) | O04 | No record | | Reverse Mentorship Program (5.17) | O08 | No record | | Social Enterprise Program (5.18) | O04 | No record | | Open Collaboration Program (5.19) | O10, O04 | No record | | Indigenous Knowledge Program (5.20) | O01, O02, O06, O10 through the rights-holder route | No record | | Sustainable Development Program (5.21) | O01, O06 | No record | | Anticipatory Action Program (5.22) | O05 | No record | | Public Authority Learning Program (5.23) | O01, O05 through the government and agency routes | No record | | Provider Readiness Program (5.24) | O04, O09 | No record | | Sponsor Orientation Program (5.25) | Philanthropy route (O08, O09, O10) | No record | | Finance-Reader Literacy Program (5.26) | O07 | No record | Where a stakeholder route is named, its boundary also applies. For example, for Indigenous and rights-holder institutions: "No fee to raise harms; protected knowledge never enters public examples or model training"; for development institutions: "A readiness record is not loan approval, a grant award or procurement qualification"; for students and volunteers: "No fee for ordinary participation and no unsupervised high-consequence assignment" \[5]. ## How a participant moves through service levels
Programme service levels as a staircase. R0, information, is the current level. An opening gate (service team, terms and review capacity in place) leads to R1 enquiry with a durable receipt, then R2 application, R3 commitment through a specific agreement, R4 operation by authorised users and R5 public release with independent release authority.

Figure 1. Programme service levels R0 to R5. Only R0 is in effect; later levels open when their service team, terms and review capacity are in place. A design of the sequence, not a record of any participant. Source: consortium programme source [5], as of 2026-10-16.

Text description of Figure 1 R0, information, is the current level: visitors can understand the architecture and current programme state. A gate (service team, terms and review capacity in place) must be passed before R1, enquiry with a durable receipt; then R2, application with current terms and an appeal route; R3, commitment through a specific agreement with the correct parties; R4, operation by authorised users; and R5, public release with independent release authority.
The same source records the separations that keep programme stages honest: "A submitted application" is not "membership"; "A payment" is not "an appointment or access to restricted data"; "An infrastructure offer" is not "an allocation"; "A report candidate" is not "a released publication"; "Readiness evidence" is not "a financing or underwriting decision" \[5]. ## Who participates: the three pillars Programme participation runs through three national pillars recorded in the institutional register \[5]: * **National Nexus Consortium (NNC).** "The institution is the member." Institutions take part through one of five Helix pathways (State and Public Authorities; Industry and Operators; Academia and Research; Civil Society and Media; Community and Indigenous) or the Financial Institutions and Regulators pathway. "Institutional membership does not create a Council seat, and no contribution decides a technical conclusion, public authority or procurement treatment." * **National Leadership Council (NLC).** "The selected individual is the member, in personal capacity." Leaders follow a Leadership Baseline, an Annual Leadership Contribution Plan, quarterly work and a Year-One Gateway. "Selection precedes payment." * **National Working Groups (NWG).** "Assignments and responsibility follow competence." "Ordinary participation has no fee", and "unqualified contributors never take safety-critical tasks". Six domain response teams sit under the Working Groups; they "are not emergency services, incident command or privileged network-access teams". **Programme rule ACC-V-1.** No programme, cohort or accelerator SHALL be described as constituted, active or completed without a dated published record; until then its status is "No record" (source: the Nexus Documentation Standard \[9]; consortium programme separations \[5]). **Programme rule ACC-V-2.** Every programme description SHALL state its entry route and boundary and SHALL NOT state a fee unless a fee record exists (source: consortium programme offerings and current service level \[5]). ## What programmes are not * They are not running. No programme, cohort, accelerator, Academy course or exercise is recorded as active \[5]. * They are not certification. "Testbed participation is not a regulatory sandbox, a certification or a procurement status" \[5]. * They are not appointments or employment. A year of leadership service "produces a reviewed next state, not an automatic governance appointment" \[5]. * They are not finance. "Readiness evidence is not a financing decision" \[5]. * They are not membership by enquiry. An enquiry gets a reference and a named next step and creates no membership, contract or commitment \[8]. * They are not decisions. "Public-authority learning is not approval", and "A decision-support package is not an official decision" \[2]. * They are not local offices. "A planned hub" is not "an operational site", and the fifteen hubs are coordination roles, not offices \[5]\[7]. * They are not runtime authority. Programme work would run on shared fabrics such as the Universal Runtime, which "does not grant purpose, legal authority, scientific validity or entitlement" \[6]. * They are not purchasable outcomes. "No support buys appointments, findings, consent or procurement advantage" \[5]. ## International context (alignment, not endorsement) * **Public-sector innovation.** The OECD Observatory of Public Sector Innovation collects and analyses public-sector innovation practice, including government innovation programmes \[10]; it is a reference for the accelerator and Academy design in sections 5.6 to 5.11, not a source for that design. * **Open science and open collaboration.** The UNESCO Recommendation on Open Science (2021) frames open collaboration, shared infrastructure and equity in science \[11]; it is a reference for sections 5.15 and 5.19. * **Disaster risk reduction and anticipatory action.** The Sendai Framework for Disaster Risk Reduction 2015-2030 \[12], the Anticipation Hub \[13], OCHA's anticipatory action work \[14] and the UN Early Warnings for All initiative \[18] frame the Risk Management and Anticipatory Action programme families. * **Indigenous knowledge.** The United Nations Declaration on the Rights of Indigenous Peoples \[15] and the CARE Principles for Indigenous Data Governance \[16] frame section 5.20. * **Sustainable development.** The 2030 Agenda for Sustainable Development \[17] frames section 5.21. * **Digital public goods.** The Digital Public Goods Standard is the external test for any programme output described as a digital public good \[19]. Naming these publications implies no partnership, endorsement or recognition. ## Terms used on this page * **Programme.** A governed pathway of learning, applied work and readiness review; a design until constituted. * **Offering.** One of the ten recorded programme offerings O01 to O10 in the institutional records. * **Accelerator.** A time-bound, intensified programme pathway that closes readiness gaps; not a start-up accelerator, and its graduation is not certification (sections 5.10 and 5.11). * **Academy.** The learning infrastructure of programmes (section 5.7); a learning record is not a licence. * **Service level.** The recorded stage of programme service, from R0 (information) to R5 (public release); R0 is current. * **Helix pathway.** One of five institutional participation pathways of the NNC, with the cross-cutting Financial Institutions and Regulators pathway. ## Related pages * Up: [Acceleration](/organization/introduction/acceleration.md) * Across: [I. Order](/organization/introduction/acceleration/i.-order.md) · [II. Compute](/organization/introduction/acceleration/ii.-compute.md) · [III. Edge](/organization/introduction/acceleration/iii.-edge.md) · [IV. The Foundry pillar and the systems](/organization/introduction/acceleration/iv.-foundry.md) · [VI. Marketplace](/organization/introduction/acceleration/vi.-marketplace.md) · [VII. Consortiums](/organization/introduction/acceleration/vii.-consortiums.md) · [VIII. Campaign](/organization/introduction/acceleration/viii.-campaign.md) * Counterparts: [Nexus Programs](/organization/acceleration/nexus-programs.md) · [Accelerators](/organization/acceleration/accelerators.md) · [III. Members](/organization/introduction/cooperation/iii.-members.md) · [VI. Pathways](/organization/introduction/cooperation/vi.-pathways.md) ## Sources 1. Nexus constitutional directive D-V3-0003, *Canonical Twenty-System Constitution and Authority Matrix* (canonical order, remits, completeness and non-ownership rules). Internal record, cited by identifier. 2. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks, Non-Execution and Lawful Handoff Constitution* (public-good rail, enterprise and sovereign execution stack, consequential action envelope, boundary formulas). Internal record, cited by identifier. 3. Nexus institutional register, *Nexus institutional architecture and participation*: owner decision of 11 October 2026 on GCRI Canada as lead contracting organization (owner-confirmed; counsel review pending), with the legal entity profile notices on operating structure, the lead contracting organization, consortium stewardship, institutional independence, platform ownership and the commercial channel (owner-confirmed; title and instruments unverified). Internal record. 4. Nexus institutional register: release hold policy (in force since 21 July 2026; permitted profiles internal development, pull-request preview, isolated test and non-certified research; blocked profiles include sovereign, marketplace and certified public-good) and claim register. Internal record. 5. Nexus institutional register, consortium programme: operating functions, conversion chain, programme offerings O01 to O10 with their questions, deliverables, entry routes, boundaries and system mappings, decision rights, service levels R0 to R5, current service level R0, separations and case routes; drawing on the consortium directives D-NEXUS-CONSORTIUM-PUBLIC-ARCHITECTURE-2 and D-NEXUS-CONSORTIUM-STAKEHOLDER-READINESS-3. Internal record. 6. Nexus constitutional directive D-V3-0001, *Master Directive V3* (shared constitutional fabrics and their boundary sentences), and the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1). Internal record, cited by identifier; the Native Master is not quoted. 7. Nexus institutional register, consortium geography: six regions and fifteen planned hubs, every hub planned; hubs are coordination roles, not offices. Internal record. 8. Public institutional site draft (not yet adopted; owner direction, not a binding record): controlled vocabulary, council vocabulary NNC, NLC and NWG with the note retiring earlier labels, programme status vocabulary and institutional boundary sentences for GRF and GRA. Draft source. 9. Nexus Documentation Standard, draft of 16 October 2026 (purpose and audiences, authority and status, naming, external frameworks and sources), the owner decisions of 16 October 2026 and the introduction audit of 16 October 2026. Internal editorial records; not published. 10. OECD. *Observatory of Public Sector Innovation* (OPSI). [oecd-opsi.org](https://oecd-opsi.org/). Accessed 2026-10-16. 11. UNESCO. *Open science* (about the UNESCO Recommendation on Open Science, 2021). [unesco.org](https://www.unesco.org/en/open-science/about). Accessed 2026-10-16. 12. United Nations General Assembly (2015). *Sendai Framework for Disaster Risk Reduction 2015-2030*, endorsed by A/RES/69/283. [docs.un.org](https://docs.un.org/en/A/RES/69/283). Accessed 2026-10-16. 13. Anticipation Hub. *Anticipation Hub* (knowledge platform on anticipatory action). [anticipation-hub.org](https://www.anticipation-hub.org/). Accessed 2026-10-16. 14. United Nations Office for the Coordination of Humanitarian Affairs. *Anticipatory action*. [unocha.org](https://www.unocha.org/anticipatory-action). Accessed 2026-10-16. 15. United Nations General Assembly (2007). *United Nations Declaration on the Rights of Indigenous Peoples*, A/RES/61/295. [docs.un.org](https://docs.un.org/en/A/RES/61/295). Accessed 2026-10-16. 16. Carroll, S. R. et al. (2020). The CARE Principles for Indigenous Data Governance. *Data Science Journal*, 19(1), 43. [datascience.codata.org](https://datascience.codata.org/articles/10.5334/dsj-2020-043). Accessed 2026-10-16. 17. United Nations General Assembly (2015). *Transforming our world: the 2030 Agenda for Sustainable Development*, A/RES/70/1. [docs.un.org](https://docs.un.org/en/A/RES/70/1). Accessed 2026-10-16. 18. United Nations. *Early Warnings for All* initiative (overview page). [un.org](https://www.un.org/en/climatechange/early-warnings-for-all). Accessed 2026-10-16. 19. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/standard). Accessed 2026-10-16. 20. GCRI (2026). *How Nexus works*: the six pillars, their eighteen handoffs and the eight-step cycle (Question, Evidence, Build, Organize, Test, Publish, Decide, Renew). [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Read 2026-10-21. 21. The Global Risks Forum (2026). *Nexus Universe at GRF*: the annual programme, gates G0 to G7 and the ten Action Week tracks. [globalriskforum.com/nexus-universe](https://globalriskforum.com/nexus-universe/). Read 2026-10-21. 22. Risk Academy (2026). *Academy in the ecosystem*: completion records from Risk Academy; courses authored by GCRI, GRF and GRA. [risksacademy.com/ecosystem](https://risksacademy.com/ecosystem/). Read 2026-10-21. 23. The Global Risks Alliance (2026). *Finance and insurance readiness*: readiness evidence is not a financing decision. [globalriskalliance.com/finance-readiness](https://globalriskalliance.com/finance-readiness/). Read 2026-10-21. 24. The Global Risks Alliance (2026). *Lawful handoffs*: readiness evidence is released one to one on the owner's written direction, with no introduction and no pay tied to any transaction. [globalriskalliance.com/finance-readiness/handoff](https://globalriskalliance.com/finance-readiness/handoff/). Read 2026-10-21. 25. GCRI (2026). *How Nexus Consortium works*, with *National Nexus*, *Six programme regions* and *Programme status* (seven programme states; current service level R0, information and enquiries). [therisk.global/consortium](https://therisk.global/consortium/). Read 2026-10-21. 26. GCRI (2026). *Programme status*: Exploration, In formation, Constituted, Active programme, Paused, Closed, Historical record; current service level R0. [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Read 2026-10-21. 27. GCRI (2026). *Nexus Reports programme*: quarterly country editions, an annual flagship and specialist series; current approved releases: none. [therisk.global/publications/nexus-reports](https://therisk.global/publications/nexus-reports/). Read 2026-10-21. ## Editorial record * As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted (an AI agent drafted this revision). Human review: pending; no named reviewer or approver yet. * Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits. * Change: 2026-10-16, upgraded to the documentation standard draft. Record block, In brief and programme status section ("No record" per dimension) added; "source page" residue removed; certification wording recast as verification or qualification; fees marked as unrecorded; "Sovereign Compute" family linked to offering O03; retired council labels flagged and Helix pathways named; offerings table O01 to O10, family-to-offering map, service-level figure, separations, participation pillars, rules ACC-V-1 and ACC-V-2, external context, terms, sources and related pages added; heading levels corrected; all original sections kept. * Change: 2026-10-16 r2, readable document record and status note; Nexus Standards display codes for systems; system naming; Nexus Observatory Protocol note; ownership and licensing statements rewritten without naming any company; internal paths, commit references and status codes replaced with plain words. * Change: 2026-10-21 r3, brought up to date with the published sites, Nexus Standards and the owner's rulings of October 2026: Where this fits line; a Current position section; Nexus Standards described as published ([NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) and [NS-3b](https://nexustandards.com/standards/ns-3b/), NIS-1, 348 NRS in 15 series, all PROPOSED; GCRI Canada publisher of record; governance bodies and adoption modes); the national vocabulary of National Nexus, the NNC with its six Helix councils, the NLC and the NWG; the finance boundary on every vehicle passage; the systems named as systems; all original sections kept. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.therisk.global/organization/introduction/acceleration/v.-programs.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.