> 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/operations/iv.-networks.md). # IV. Networks The network layer of Nexus operations: geographic working groups, embedded capability, regions and planned hubs, and the limits on what a network may claim. **Where this fits:** all six sectors · Nexus Universe · National Nexus, regions and hubs · the whole programme year · doctrine · read with [The Model](/organization/model.md), [Programme](/organization/programme.md), [Governance in operation](/organization/governance-in-operation.md) and [Reference](/organization/reference.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** | Nexus constitutional directives D-V3-0003 (*Twenty-system constitution*) and D-V3-0004 (*One Rail-Two Stacks and non-execution*); the owner decision of 11 October 2026 on Nexus institutional architecture and participation; the consortium programme participation pillars and service levels and the consortium geography (six regions, fifteen hubs, all planned), in the Nexus institutional register; the Nexus Documentation Standard (draft of 16 October 2026); the sites' model, the Nexus Consortium model, the [Nexus Standards](/organization/institutions/nexus-standards.md) feeds and the owner rulings of 21 October 2026 (source pack) | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
## In brief A network, in this documentation, is a distributed working structure that carries Nexus work into regions, countries and institutions without creating a separate centre of authority. The original chapter names two forms: geographic working groups and embedded capability units, earlier called competence cells. In the consortium programme records, national participation runs through the [National Nexus Consortium](/organization/governance-in-operation/nnc.md) (NNC), the [National Leadership Council](/organization/governance-in-operation/nlc.md) (NLC) and the National Working Groups (NWG), within six regions and fifteen hubs that are all recorded as planned. Networks support work; they do not decide it \[1]\[4]. {% hint style="success" %} **Aligned to the current model (21 October 2026).** This page was brought up to date with the sites' model, the Nexus Consortium model, the live public sites and the owner rulings (see [Reference](/organization/reference.md) and the [Sources library](/organization/reference/sources.md)). Where the earlier design text below differs, these points govern: * National participation runs through National Nexus: a National Desk, a National Model, a National Portfolio and three participation pillars, the NNC (institutions, through the five Helix pathways or the Financial Institutions and Regulators pathway), the NLC (leaders in a personal capacity) and the NWG (expert work by competence, with six domain response teams, the CERTs) \[17]\[18]. See [National Nexus](/organization/governance-in-operation/national-nexus.md). * The geography is six programme regions with fifteen planned hubs, which are coordination roles and never offices; all are in formation \[19]. See [Regions and hubs](/organization/governance-in-operation/regions-and-hubs.md). * Embedded capability units, earlier called competence cells, now map to NWG assignments and the CERTs; the CERTs support preparedness, observation, verification, mapping, exercises, evidence and learning and are not emergency services, incident command or privileged network-access teams \[20]. See [NWG](/organization/governance-in-operation/nwg.md). * Finance and delivery vehicles named in the earlier text (Project SPVs, National Consortium Companies) are structures that competent, lawful actors may form outside the programme, under their own law and licences; the programme never forms, owns, arranges or advises on a vehicle or a transaction, and readiness evidence is not a financing decision \[21]\[22]. See [Lawful handoffs](/organization/finance-readiness/lawful-handoffs.md). * Everything described here is in formation. No national programme is recorded as constituted or active, and the current service level is R0, information and enquiries \[23]. See [Status and service levels](/organization/governance-in-operation/status-and-service-levels.md). {% endhint %} {% hint style="info" %} **How to read this page.** This page explains a design; it constitutes no network, working group, hub or council. Where the text uses the present tense or "must" and "should", it states the intended discipline of the design, not a description of operating groups. The working-group and competence-cell pages of the [Operations part](/organization/operations/networks.md) hold the regional detail. {% endhint %} ## Status, scope and terms of this page **Status in the five-state grammar.** Target: networks are described in this documentation and the participation pillars and geography are defined in the consortium programme records \[4]. Implemented: No record (this page cites no formation record for any working group, competence cell, national consortium or hub). Verified: No record. Observed: No record. Accepted: No record. A proposed working group is not an active working group (section 4.29). The current service level of the consortium programme is R0, "Information and enquiries" \[4]. A target definition is not an implementation \[7]. **Participation pillars in the programme records.** In the National Nexus Consortium (NNC), "The institution is the member." In the National Leadership Council (NLC), "The selected individual is the member, in personal capacity." In the National Working Groups (NWG), "Assignments and responsibility follow competence." Ordinary NWG participation has no fee, and unqualified contributors never take safety-critical tasks \[4]. The geographic working groups in this chapter are closest to the NWG; how the earlier competence-cell design maps to the pillars awaits owner decision (OQ-14) \[9]. | Region (recorded geography) | Planned hubs | Hub state | | ------------------------------- | -------------------------------------------- | --------- | | Africa | Senegal, Kenya, South Africa | Planned | | Asia and the Pacific | India, Singapore, Japan | Planned | | Europe and Eurasia | United Kingdom, France, Switzerland, Türkiye | Planned | | Latin America and the Caribbean | Brazil | Planned | | Middle East and North Africa | United Arab Emirates, Saudi Arabia | Planned | | North America | Canada, United States | Planned | *Table 1. The six regions and fifteen hubs recorded in the recorded consortium geography; every hub is recorded as planned. Hubs are coordination roles, not offices. Registry count and design property, not an operating footprint. Source: consortium geography source \[4]; public site draft \[8], as of 2026-10-16.* **Two regional groupings.** The original chapter and the deep reference use eight geographic working groups: Africa, Asia, Australia, Europe, MENA, North America, South America and the United Kingdom. That is a historical grouping of this documentation. The recorded consortium geography in Table 1 uses six regions; in it, Australia falls within Asia and the Pacific, the United Kingdom is a planned hub within Europe and Eurasia, and South America falls within Latin America and the Caribbean. Until the owner decides how the two are reconciled, the eight-group list below is read as earlier design text, not as a set of constituted groups \[4]\[9]. **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) and summarized in [I. Order](/organization/introduction/operations/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](/organization/programme/universe.md) 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 \[1]\[2]. 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 \[5]\[9]. **Words that name systems or programmes.** "Foundry" here refers to a design area of this documentation; elsewhere in the Nexus records the build work belongs to the [Foundry pillar](/organization/programme/foundry.md) and the technical architecture to the twenty Nexus systems. Where earlier design text speaks of "Studio" workflows, environments or runtime, this page names the system [NXS-STU](/organization/systems/nxs-stu.md), the builder and configuration workspace, which composes but never deploys; its remit is "visual composition, dashboards, maps, forms, workflow experiences, reusable artifacts and deployment profiles", and build and assembly belong to [NXS-FAC](/organization/systems/nxs-fac.md), the mission application factory \[5]. "Marketplace" has no V3 system of that name; the nearest are [NXS-NXQ](/organization/systems/nxs-nxq.md), the software, capability and agent fabric, for software, packages, connectors, models, entitlements and capability lifecycle, and [NXS-APP](/organization/systems/nxs-app.md), the mission app runtime, for the application catalog \[5]. "Registry", "Agency" and "recognition" are used in the general sense of recorded status and support; they do not describe a statutory register, a government agency or a recognition decision held by any named institution \[9]. "Sovereign" is used only for the powers of public authorities or as design intent for deployments under national control, subject to evidence for each deployment \[9]. {% 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 %} **Role words in older design text.** Where this chapter refers to "GRF recognition", "GRF claims review", "GRA routeability review" or "protocol" review, it describes functions in the earlier design text of this corpus. An older binding instrument, the Universal Runtime directive V7 (section 2.5), associates GRF with registry, recognition and maturity records, claims discipline, stakeholder formation and public-safe reporting, and GRA with finance and insurance readiness and diligence translation \[10]. The current public wording does not present GRF as a recognition, conformance or certification body, and GRA "does not lend, underwrite, rate, invest, advise on or arrange transactions, and readiness work is not approval" \[8]. How the two wordings are reconciled awaits owner decision (conflict X-23 in the documentation standard) \[9]. {% hint style="info" %} **Earlier council labels.** This page keeps some labels from earlier versions of this corpus (`Nexus Competence Cells`). They are now mapped to the current model (rulings R3 to R5 of 21 October 2026, following the Nexus Consortium model \[18]): Competence Cells to National Working Group assignments and the CERTs; Helix Councils, in the earlier sense, to the six Helix councils of the NNC; Investor Councils to the Financial Institutions and Regulators pathway, led with GRA; National Councils to the NLC or the NNC by function; Council Bureau and Technical Secretariat to the Consortium Secretariat held by GCRI Canada. Where they appear below they describe earlier design text, not current or constituted bodies; [Councils](/organization/governance-in-operation/councils.md) and the [Reference](/organization/reference.md) glossary hold the mapping \[8]\[9]. {% endhint %} ## The network layer at a glance
The network layer as a design. GCRI Canada, the Consortium Secretariat, sits above six regions and fifteen hubs, all recorded as planned; national programmes run within this geography. Each holds three pillars: NNC, NLC and NWG. Geographic groups are closest to the NWG; how capability units (earlier competence cells) map to the pillars awaits OQ-14. NWG evidence goes to competent authorities.

Figure 1. The network layer as a design: regions, planned hubs and national programmes, with the three participation pillars and the earlier GitBook network forms shown against them. A design, not a record of any constituted group; every hub is planned and the competence-cell mapping awaits owner decision (OQ-14). Source: consortium programme and geography sources [4] and this chapter, as of 2026-10-16.

Text description of Figure 1 The left column shows GCRI Canada, Consortium Secretariat and lead institution, above six regions, and the regions above fifteen hubs, every one recorded as planned; hubs are coordination roles, not offices. National participation runs within this geography through a national programme under a national host. The national programme holds three participation pillars: the National Nexus Consortium (NNC) for institutions, the National Leadership Council (NLC) for leaders in their own capacity and the National Working Groups (NWG) for experts by competence. Two earlier forms from this chapter are shown in the middle column: the geographic working groups, linked by a grey line to the NWG, which they are closest to; and the embedded capability units, earlier called competence cells, shown without a link because their mapping to the three pillars awaits owner decision (OQ-14). Working-group evidence goes to competent authorities, who decide.
## Summary This page defines the network layer of Nexus Operations. If **III. Charters** defines bounded working modes, **IV. Networks** defines the distributed structures through which chartered and framework-guided work becomes present across regions, institutions, hosts, communities, nodes, platforms, companies, public authorities, universities, and operating environments. Networks are the distributed working structures of Nexus. They allow the operating system to carry work beyond a single center without becoming fragmented. They distribute attention, capability, contextual intelligence, local interpretation, host readiness, institutional memory, and practical continuity across the ecosystem. The operating corpus identifies two especially important network forms: **geographic working groups** and **competence-cell structures for institutions and corporations** (an earlier label; see the note above). Geographic working groups distribute attention, contextual intelligence, and regional operating interpretation. Competence cells distribute actual capability inside institutions, companies, hosts, universities, public authority interfaces, consortiums, and other operating environments. Together, they form the first visible network architecture of Nexus Operations. Networks matter because Nexus cannot remain truthful, resilient, or realization-capable if its working life remains concentrated in one place, one headquarters, one central team, one dominant geography, or one narrow institutional culture. Nexus must be present where signals arise, where hosts operate, where communities experience risk, where public authorities engage, where providers deliver, where universities train, where companies build, where observatories sense, and where national and regional pathways become real. The network layer is therefore not a social accessory. It is operational infrastructure. *** ## 4.1 Why Networks Matter in a System Like Nexus A constitutional-operating system of the scale and ambition of Nexus cannot rely on a single center of action. Its purposes are too broad, its geographies too varied, its institutional interfaces too differentiated, its technologies too complex, its host realities too specific, and its realization pathways too distributed for central concentration to remain truthful or resilient. If Nexus depended on one headquarters logic, one narrow team structure, one geography, one institutional environment, or one dominant operating culture, it would become brittle where it needs to be adaptive. It would become abstract where it needs to be host-truthful. It would become overcentralized where it needs distributed legitimacy and capability. It would begin to confuse central visibility with real operating presence. Networks exist to prevent that failure. They are the distributed working structures through which Nexus carries operational life across regions, institutions, sectors, nodes, hosts, platforms, communities, and enterprise environments while remaining aligned to one common architecture. A network gives the operating system: * local and regional listening capacity; * distributed working capacity; * contextual interpretation; * host and node awareness; * public authority interface support; * institutional continuity; * competence formation; * contribution pathways; * escalation routes; * and preparatory depth for lawful realization. Networks allow Nexus to be distributed without becoming incoherent. *** ## 4.2 What Networks Are in Nexus A network in Nexus is a structured operating arrangement through which capability, coordination, information flow, contextual intelligence, and bounded responsibility are distributed across multiple actors or environments while remaining aligned to the wider constitutional, methodological, public-good, standards-bearing, and federated architecture. A Nexus network is not simply a mailing list of interested actors. It is not merely a coalition formed around shared sentiment. It is not a convenience layer for event participation. It is not an informal community without responsibilities. It is not a contact map. It is not a vendor channel. It is not a donor geography. It is not a substitute for governance. A true Nexus network carries operational consequence. It supports working continuity, capability-building, local interpretation, cross-domain exchange, issue escalation, report development, public-safe learning, platform use, competence formation, and the structured movement of activity through the operating system. A Nexus network should have: * a clear purpose; * a defined relation to the five-domain architecture; * bounded participation conditions; * visible role logic; * connection to frameworks and charters; * records and reporting expectations; * safeguards channels; * output or capability relevance; * and a connection to institutional memory. Without these features, a group may be socially valuable, but it is not yet a fully operational network in the Nexus sense. *** ## 4.3 The Network Thesis of Nexus The network thesis of Nexus is that **a federated public-good operating system becomes truthful only when capability, attention, context, and memory are distributed in structured forms close enough to real environments to understand them, but disciplined enough to remain aligned to one common architecture**. This thesis has several implications. Capability must not remain centralized. Regional and local realities must not be interpreted only from a distance. Institutions must be able to carry Nexus methods internally. Companies must be able to participate through bounded competence rather than loose affiliation. Hosts must be supported where they actually operate. Communities must have pathways that do not reduce them to sources of information. Public authorities must have structured learning and interface pathways. Providers must be integrated without becoming public-good authorities. Working groups must be active without becoming governance bodies by implication. Competence cells must strengthen institutions without creating private forks. Networks therefore make the architecture socially, geographically, institutionally, and operationally real. They are how Nexus becomes distributed without becoming disordered. *** ## 4.4 Networks as De-Risking Infrastructure Networks are also de-risking infrastructure. They reduce operational risk by distributing attention and capability. They reduce contextual risk by allowing local, regional, and institutional realities to surface before decisions, reports, programs, or realization pathways overclaim themselves. They reduce centralization risk by preventing the entire operating system from depending on a small group of people or one institutional location. They reduce continuity risk by embedding competence inside institutions, corporations, hosts, universities, and national or regional structures. They reduce public-safe risk by making it easier to detect sensitive context, protected knowledge, public authority implications, market sensitivity, procurement sensitivity, and community concerns earlier. They reduce realization risk by identifying whether host capacity, public authority interface, provider readiness, node maturity, and operational support actually exist. A weak network extracts signals. A strong network builds capability. Nexus requires the second. *** ## 4.5 The Primary Network Forms The current operating corpus identifies two especially important network forms: * **geographic working groups**; * **competence cells for institutions and corporations**. These two forms are complementary. Geographic working groups distribute attention, interpretation, coordination, and regional intelligence. Competence cells distribute embedded capability, continuity, and practical method inside organizations and host environments. Together, they create a network architecture that is social, institutional, geographic, technical, and operational at once. Geographic working groups help Nexus understand where it is acting. Competence cells help institutions carry Nexus work responsibly. Geographic working groups make distributed context visible. Competence cells make distributed capability durable. The combination is essential. A network of attention without competence becomes consultative but weak. A network of competence without geographic and contextual awareness becomes technical but abstract. Nexus requires both. *** ## 4.6 Geographic Working Groups Geographic working groups create territorial, regional, national, and corridor-facing operating surfaces for Nexus. The corpus identifies geographic working groups including **Africa**, **Asia**, **Australia**, **Europe**, **MENA**, **North America**, **South America**, and the **United Kingdom**. This eight-group list is a historical grouping of this documentation; the recorded consortium geography uses six regions with fifteen planned hubs (Table 1), and the reconciliation awaits owner decision \[4]\[9]. This confirms that Nexus recognizes the need for operating structures that can engage with geography, institutional context, legal environment, market conditions, cultural realities, public authority settings, infrastructure systems, and host conditions rather than treating the world as one undifferentiated deployment surface. Geographic working groups are not symbolic regional chapters. They are bounded operating environments through which the wider Nexus architecture can be interpreted, coordinated, and advanced under geographic and territorial conditions. They may support: * regional and territorial priority identification; * public authority learning; * institutional mapping; * host and node readiness discovery; * regional report development; * safeguards identification; * community and protected knowledge concerns; * public-safe interpretation; * corridor and cross-border issue spotting; * working group formation; * competence-cell development; * local provider and partner mapping; * Academy and training needs; * Marketplace and Foundry localization signals; * and handoffs into national or regional pathways. A geographic working group gives Nexus an operating presence in context without creating a separate version of Nexus. *** ## 4.7 Regionality Without Fragmentation Geographic working groups exist so Nexus can be regionally attentive without becoming regionally fragmented. Their purpose is not to create local doctrines. Their purpose is to carry one doctrine, one common rail, one public-good architecture, one standards-bearing system, and one operating discipline through many regional realities. This distinction is fundamental. A geographic working group may interpret context. It may not fork canonical meaning. It may identify local priorities. It may not redefine Nexus. It may support public authority learning. It may not become the public authority. It may support regional reports. It may not create recognition by itself. It may help identify host readiness. It may not activate a host without proper process. It may support Marketplace localization. It may not create Marketplace recognition. It may support provider mapping. It may not create procurement preference. Regionality is a strength when it deepens truth. It becomes a risk when it becomes fragmentation. The network layer must therefore preserve both context and coherence. *** ## 4.8 Geographic Working Groups as Operational Intelligence Structures Geographic working groups can function as operational intelligence structures. They are close enough to particular environments to detect signals, tensions, institutional openings, host realities, capability gaps, public authority questions, safeguards concerns, and emerging constraints earlier and more accurately than a distant center might. This does not mean every geographic working group becomes an observatory in the technical sense. It means that every serious operating network should improve the system's ability to read the environments in which it acts. Geographic working groups may help identify: * shifts in institutional readiness; * public authority interface opportunities; * host and node opportunities; * regional sensitivities; * protected knowledge concerns; * corridor or cross-border coordination needs; * local capability gaps; * training needs; * provider availability; * translation requirements; * standards interpretation issues; * report topics; * platform needs; * and areas where the connection between standards, participation, and realization remains weak. When functioning well, geographic working groups increase responsiveness and truthfulness. They allow Nexus to see more of the world without pretending that visibility itself constitutes authority. *** ## 4.9 The United Kingdom as a Distinct Working Group The inclusion of the **United Kingdom** alongside **Europe** is operationally significant in the earlier design. In the recorded consortium geography, the United Kingdom is one of four planned hubs in the Europe and Eurasia region, recorded as planned \[4]. It shows that Nexus geographic working structures are not purely continental abstractions. They may reflect legal, institutional, financial, regulatory, diplomatic, academic, standards, market, or ecosystem realities that warrant distinct working treatment even where broader regional logic also exists. This is an example of contextual precision. A working group may be formed because a geography has distinct operating relevance, not merely because it fits a continental map. The United Kingdom may require distinct treatment because of its legal systems, financial and insurance markets, universities, policy ecosystem, standards environment, public authority structures, infrastructure actors, and international institutional role. This does not make the United Kingdom separate from European or global coherence. It means that the operating network can recognize meaningful granularity where it supports better work. Nexus networks should be precise enough to reflect reality without multiplying unnecessary structures. *** ## 4.10 Geographic Working Groups and Federation Geographic working groups must be distinguished from federation bodies. A geographic working group is an operating structure. It may support context, coordination, learning, investigation, contribution, and preparation. A Regional [NXS-NET](/organization/systems/nxs-net.md) (network topology and continuity) Network, Regional Public-Good Consortium, Regional Stewardship Board, or National Nexus Consortium may carry more formal federation, governance, or institutional significance. A geographic working group may help prepare, inform, or support such structures, but it does not become them by default. This distinction matters. A working group may identify regional readiness. It does not create regional authority. A working group may support national formation. It does not create a National Nexus Consortium. A working group may convene interested actors. It does not create a council. A working group may gather evidence. It does not create recognition. A working group may surface providers. It does not create qualification. Geographic working groups are vital preparatory and operational structures. They should not be overread as formal governance or federation bodies unless properly transformed through the relevant process. *** ## 4.11 Geographic Working Groups and Public-Safe Claims Geographic working groups often sit close to public meaning because they work in named geographies. This creates claim risk. A geographic working group should not imply that Nexus is formally adopted in a region or country unless that status is recorded. It should not imply public authority endorsement because a public authority participated. It should not imply national maturity because a national discussion occurred. It should not imply provider approval because companies joined. It should not imply community legitimacy because community voices were heard. It should not imply regional comparability because multiple countries participated. Public-facing language about geographic working groups should state their status carefully. A working group may be exploratory, active, supported, under formation, public-facing, internal, regional, national, corridor-based, or archived. Its public claims must match its recorded status. This protects both the working group and the region it serves. *** ## 4.12 Competence Cells as Embedded Operating Capacity (earlier label) If geographic working groups distribute attention and coordination, competence cells distribute actual operating capacity. A **Competence Cell** is a bounded, capability-bearing unit embedded within an institutional, corporate, host, academic, public authority, consortium, node, or community-relevant environment to carry Nexus methods, systems, practices, learning, records, public-safe discipline, and operational continuity in a persistent way. A competence cell is not merely a task force. It is not merely a training cohort. It is not merely a local club. It is not merely a branded partnership. It is an embedded operating organ of the wider architecture. Competence cells matter because a distributed architecture cannot depend entirely on external coordination. It must cultivate places where real competence is present, reproducible, and organizationally situated. A competence cell is one of the ways Nexus becomes part of institutional capability rather than remaining an external concept. *** ## 4.13 Competence Cells for Institutions (earlier label) Institutional competence cells are especially important because many environments relevant to Nexus are public, multilateral, academic, nonprofit, community-based, research-oriented, or hybrid. Such institutions often require not only knowledge of Nexus, but the ability to translate Nexus methods into internal process, local interpretation, observability, reporting, public authority learning, data handling, training, and interface with governance or standards pathways. An institutional competence cell may support: * local architectural understanding; * structured use of Nexus frameworks; * investigation and report preparation; * public-safe review awareness; * evidence and record handling; * observatory and node-related activity; * Academy and training pathways; * registry-facing activity; * data and privacy discipline; * public authority learning support; * safeguards and protected knowledge handling; * platform use; * and coordination with the wider Nexus operating system. Institutional competence cells are continuity tools. They help prevent the common pattern in which a system enters an institution through one enthusiastic person and disappears when that person leaves, changes role, or loses capacity. A competence cell makes institutional learning less fragile. *** ## 4.14 Competence Cells for Corporations and Enterprise Environments (earlier label) Corporate and enterprise competence cells are equally important, but they must be bounded carefully. Nexus expects companies, providers, integrators, OEM partners, cloud partners, telecom partners, software developers, infrastructure actors, insurers, finance readers, and other enterprise environments to participate in realization pathways. That participation must be serious, capable, and disciplined. A corporate competence cell may support: * internal literacy on Nexus methods and boundaries; * role separation between public-good and enterprise activity; * provider qualification readiness; * standards and interoperability awareness; * data, privacy, cyber, and public-safe discipline; * Marketplace participation; * Foundry contribution; * NXS-STU integration; * Digital Public Good support; * report or evidence contribution; * routeability and finance-readable readiness understanding; * and structured collaboration with public-good and institutional surfaces. A corporate competence cell should not be treated as corporate ownership of Nexus. It is not a license to make public-good claims. It is not recognition. It is not procurement preference. It is not public authority status. It is not standards or NXS-NSF policy authority. It is an internal capability structure that helps an enterprise participate responsibly. This is a strong design choice because it makes enterprise participation more serious and more bounded at the same time. *** ## 4.15 Competence Cells for Hosts, Nodes, and Runtime Environments (earlier label) Competence cells may also be essential for hosts, nodes, and runtime environments. A host institution carrying a Nexus Node, observatory environment, NXS-STU instance, public authority learning environment, Digital Public Good deployment, or regional hub function requires persistent capability. It cannot rely only on external experts. A host or node competence cell may support: * host onboarding; * node readiness; * data handling; * cybersecurity practices; * public-safe interpretation; * NXS-STU workflow operation; * dashboard status awareness; * observatory signal handling; * edge-node coordination; * controlled-room discipline; * local training; * issue reporting; * continuity planning; * degraded-mode operation; * and node lifecycle review. This is especially important in high-consequence contexts involving compute under national control, AI, AI-RAN, O-RAN, private wireless, disaster risk, public dashboards, critical infrastructure, health, water, energy, biodiversity, or public authority learning. Runtime competence is not optional. It is the difference between a system that can be locally supported and one that remains dependent on distant expertise. *** ## 4.16 Competence Cells and Academy Pathways (earlier label) Competence cells should be linked to Academy and learning pathways. The Academy provides the learning architecture. Competence cells provide situated environments where learning becomes practice. This connection may include: * role-based training; * credential pathways; * work-integrated learning; * public authority learning; * provider onboarding; * community science training; * safeguards training; * data and privacy training; * cybersecurity training; * standards literacy; * report-writing practice; * Digital Public Good maintenance; * Marketplace and Foundry literacy; * NXS-STU workflow training; * node operations training. Credentials or learning records may support competence-cell roles, but they do not create authority by themselves. A trained person is not automatically a decision-maker. A credentialed person is not automatically a governance officer. A competence cell member is not automatically a spokesperson. Academy creates readiness. Governance and records create authority. *** ## 4.17 Competence Cells and the Sustainable Competency Framework (earlier label) Competence cells are practical expressions of the **Sustainable Competency Framework (SCF)**. SCF defines how competence is identified, developed, assessed, renewed, and connected to role readiness. Competence cells are where that competence becomes embedded in real operating environments. This makes competence cells more than training recipients. They are capability-bearing structures. They may help: * identify local competency needs; * support role readiness; * maintain institutional memory; * host work-integrated learning; * provide feedback on framework usability; * identify gaps in public-safe practice; * support localization; * strengthen provider readiness; * and help assess whether a host, node, or institution can carry more advanced Nexus work. Competence cells therefore turn SCF from abstract capability design into lived operational capacity. *** ## 4.18 Networks and Chartered Working Modes Networks should operate through chartered working modes. A geographic working group may conduct investigations, collaborate on reports, host volunteers, support community input, or coordinate public authority learning. Each mode should be governed by the relevant charter. A competence cell may participate in collaboration, investigation, Digital Public Good maintenance, platform support, report production, NXS-STU workflow training, or Marketplace preparation. Each activity should remain scoped. Networks are not excuses for informal work. The **Investigation Charter** should govern inquiry. The **Collaboration Charter** should govern joint production. The **Volunteers Charter** should govern voluntary contribution. Future charters may govern node operations, public authority learning, controlled rooms, community science, data stewardship, Marketplace review, Foundry contribution, or NXS-STU workflows. Networks provide distributed structure. Charters provide bounded conduct. Together, they make distributed work trustworthy. *** ## 4.19 Networks and the Operating Spine Networks must be connected to the operating spine. Signals may arise in a geographic working group or competence cell. Those signals should enter intake, triage, and routing where appropriate. A working group may identify a report topic. It should be scoped, assigned, reviewed, and recorded. A competence cell may identify a Digital Public Good issue. It should enter issue tracking and maintenance workflow. A host may identify a node readiness gap. It should be routed to node operations, Academy, technical review, or governance escalation. A provider may identify integration requirements. They should be routed through provider, Marketplace, Foundry, or standards pathways. A public authority may raise a question. It should be classified by capacity and routed accordingly. The operating spine prevents networks from becoming isolated. It allows distributed inputs to become structured work rather than scattered conversations. *** ## 4.20 Networks and Records Networks must leave records proportionate to their significance. Records may include: * working group status records; * participant lists; * meeting notes; * workstream records; * issue logs; * geographic signal notes; * competence-cell activity records; * training records; * report contributions; * public-safe review notes; * platform activity logs; * node readiness records; * host support records; * handoff records; * correction records; * closure records. Not every network record is public. Not every record is a governance act. Not every working group output is authoritative. But meaningful activity should be classifiable and traceable. Records protect networks from becoming informal memory systems. They also protect participants by clarifying what they did, what they did not do, and what status their work holds. *** ## 4.21 Networks and Public Authority Interfaces Networks often sit close to public authority interfaces. A geographic working group may include ministries, municipalities, agencies, regulators, emergency managers, public infrastructure bodies, public health institutions, or public research organizations. A competence cell may be hosted inside or near a public authority or public institution. This creates both value and risk. Public authorities can provide lawful context, public-purpose understanding, domain knowledge, host opportunities, policy learning, and implementation realism. But their presence must not be overread. A public authority participant may be a learner, observer, consultee, host, sponsor, competent authority, adopting authority, procurement authority, regulator, emergency authority, or public-warning authority. These are different capacities. A working group meeting with public authorities is not adoption. A public authority presence in a network is not endorsement. A public institution hosting a competence cell is not public authority approval of all Nexus outputs. A public authority learning pathway is not public decision-making. Network operations must classify public authority capacity carefully. *** ## 4.22 Networks and Community, Indigenous, and Protected Knowledge Networks must protect community, Indigenous, local, ecological, cultural, and protected knowledge. Geographic working groups and competence cells may be close to communities, lands, waters, sensitive ecosystems, infrastructure, cultural knowledge, local observations, or place-based experience. This proximity is valuable, but it creates obligations. Networks must not extract local knowledge merely to improve central outputs. They must not publish sensitive geography without safeguards. They must not convert protected knowledge into dashboards, reports, Marketplace objects, Digital Public Goods, or finance-readable artifacts without consent, context, and public-safe review. They must not use community presence as legitimacy theatre. Networks should support protected participation, consent, attribution, local benefit, public-safe summaries, correction rights, and withdrawal or narrowing where appropriate. The rule is: **Distributed networks must strengthen local actors, not merely harvest local intelligence.** *** ## 4.23 Networks and Providers Networks may include qualified enterprise providers, corporate competence cells, technical partners, systems integrators, cloud providers, telecom providers, OEM partners, software teams, cybersecurity providers, data providers, and implementation actors. Provider participation can be valuable. Providers often understand implementation constraints, technical feasibility, support models, integration risks, security issues, and lifecycle needs. But provider participation must remain bounded. A provider in a network is not endorsed by default. A provider contribution does not create procurement preference. A provider-supported competence cell does not become provider-controlled. A provider's technical implementation should not define standards by gravity. A provider's platform access does not create authority. Provider participation should be governed through qualification, conflicts rules, public-safe claims, data handling, procurement neutrality, interoperability, and role separation. Networks should enable provider realism without provider capture. *** ## 4.24 Networks and Public-Good / Enterprise Stack Separation Networks often operate at the boundary between public-good and enterprise activity. This boundary must remain visible. A geographic working group may identify an implementation opportunity. It does not become a Project SPV. A competence cell inside a company may build capacity. It does not become public-good authority. A provider may support a Digital Public Good. It does not own the common rail. A network may surface Marketplace needs. It does not create Marketplace recognition. A working group may prepare national pathways. It does not become a National Consortium Company. A host may support a node. It does not become sovereign over Nexus. Networks may support enterprise pathways, but they must not become enterprise capture surfaces. The public-good stack may inform execution. Execution must not redefine the public-good stack. *** ## 4.25 Networks and Reports, Media, and Forum Networks are major sources of reports, media, and forum activity. A geographic working group may produce a regional brief, host a forum, generate media content, or support a public-safe report. A competence cell may produce technical notes, training materials, implementation reflections, node-readiness documentation, or Digital Public Good documentation. These outputs must follow operational status and public-safe discipline. A working group note is not a public report. A forum summary is not governance. A media story is not recognition. A competence-cell technical note is not a standard. A regional brief is not a regional mandate. Network outputs should be routed into Reports, Media, Forum, Registry, Marketplace, or other pathways according to their status. Networks create valuable material. Operation ensures it is not overclaimed. *** ## 4.26 Networks and Digital Public Goods Networks are important to Digital Public Goods because they supply real-world use cases, localization needs, maintenance signals, bug reports, documentation needs, accessibility issues, translation needs, and adoption feedback. A competence cell may support Digital Public Good maintenance. A geographic working group may identify localization needs. A host may test a workflow. A provider may contribute a connector. A university may support documentation or validation. A community may identify usability or public-safe concerns. These contributions should be recorded and governed. A local adaptation should not become a fork by accident. A bug report should enter the maintenance workflow. A translation should preserve canonical meaning. A provider contribution should follow licensing and stewardship rules. Networks help Digital Public Goods remain alive, but DPGF and governance keep them coherent. *** ## 4.27 Networks and Marketplace, Foundry, and NXS-STU Networks also connect to Marketplace, Foundry, and NXS-STU. A geographic working group may identify demand for a Marketplace object. A competence cell may help test a Foundry package. A host may operate an NXS-STU workflow. A provider may propose an integration. A university may support validation. A national network may identify adoption barriers. These connections are useful, but they must preserve boundaries. A Marketplace need is not Marketplace approval. A Foundry test is not production readiness. An NXS-STU workflow trial is not public authority decision-making. A provider integration is not standards conformance by default. A working group recommendation is not procurement approval. Networks should feed Marketplace, Foundry, and NXS-STU through recorded pathways, not informal influence. *** ## 4.28 Networks and Realization Readiness The network layer acts as a bridge toward lawful realization. Geographic working groups can identify where realization pathways may be viable, where consortium logic is maturing, where observatory-node environments may be suitable, where public authority interfaces are becoming meaningful, where local providers exist, where hosts are ready, and where ecosystem capability is deep enough to move beyond exploratory work. Competence cells can become durable sites through which realization becomes supportable. They make it possible for implementation to emerge from actual local and institutional capability rather than being imposed from outside. This is why networks belong in Operation and not only in Acceleration. They are one of the ways the operating system prepares the conditions under which realization can later become truthful and sustainable. Networks do not execute by default. They prepare, inform, support, and strengthen the conditions for lawful execution. *** ## 4.29 Network Governance and Activation Because networks distribute attention, capability, and influence, they must remain governed. A network should have: * recorded purpose; * status; * scope; * lead or steward; * participation conditions; * relation to frameworks and charters; * record expectations; * public-safe rules; * safeguards channels; * output rules; * handoff pathways; * review cycle; * closure or suspension pathway. Network activation should not be implied merely by interest. A proposed working group is not an active working group. An active working group is not a council. A competence cell under formation is not a mature competence cell. A corporate competence cell is not provider recognition. A regional working group is not a Regional Nexus Consortium. A network should be activated by record and maintained through ongoing discipline. *** ## 4.30 Network Lifecycle Networks should have lifecycle states. Possible states include: * proposed; * forming; * active; * pilot; * supported; * mature; * held; * corrective; * suspended; * archived; * closed; * superseded; * retired. Lifecycle discipline prevents network sprawl. A working group that no longer meets should not appear active. A competence cell that has lost capacity should not be treated as mature. A geographic network that has changed scope should be updated. A network that has completed its purpose should close or transition. A network that becomes harmful, inactive, or misaligned should be corrected, suspended, or retired. Networks must be living structures, not permanent labels. *** ## 4.31 Networks and Institutional Memory One of the most practical values of networks is that they preserve institutional memory across distributed settings. A centralized archive may hold documents, but it cannot by itself preserve situated operational understanding. Working groups and competence cells preserve how Nexus has been understood, interpreted, and enacted in real environments. They carry knowledge of: * local institutional histories; * public authority relationships; * host conditions; * community concerns; * provider experiences; * report history; * platform lessons; * node readiness; * training gaps; * implementation barriers; * public-safe sensitivities; * and prior decisions or corrections. This makes networks a form of memory infrastructure. In a long-horizon architecture, memory cannot be held only at the center. It must be distributed in governed forms. *** ## 4.32 Networks and the Ethics of Distributed Work A well-designed network architecture is also an ethical instrument. It reduces the burden on a central few. It distributes opportunity and responsibility more fairly. It makes participation more visible. It allows local and regional realities to matter. It reduces the chance that a global architecture is sustained by hidden concentration of labor, knowledge, or interpretive power. But networks can become extractive if they merely pull intelligence, legitimacy, labor, or visibility from distributed participants without creating real capability or institutional depth in return. Nexus must avoid that pattern. Working groups and competence cells should therefore be designed not only as sources of distributed benefit to the system, but as structures through which distributed participants and institutions themselves become stronger. Network legitimacy depends on reciprocity. *** ## 4.33 Network Failure Modes Nexus should be explicit about network failure modes. **Network theatre** occurs when a network is announced but does not carry real work, records, capability, or continuity. **Regional fragmentation** occurs when geographic working groups begin creating local doctrine or claims inconsistent with the common rail. **Hidden authority** occurs when network leaders or participants acquire de facto authority through visibility, access, or centrality. **Competence-cell branding** occurs when an institution claims a competence cell without real capability. **Corporate capture** occurs when enterprise competence cells or providers influence public-good meaning, standards, or claims. **Volunteer extraction** occurs when networks rely on unpaid contribution without support, recognition, or boundaries. **Signal extraction** occurs when local intelligence is taken without building local capacity. **Public authority overclaim** occurs when public authority participation is presented as adoption or endorsement. **Provider preference drift** occurs when network participation becomes informal procurement advantage. **Memory loss** occurs when network activity is not recorded. **Network sprawl** occurs when networks multiply without purpose, cadence, or closure. **Node confusion** occurs when working groups, hosts, competence cells, and nodes are conflated. **Forum substitution** occurs when network convenings are treated as governance. **Report overclaim** occurs when network outputs are presented beyond their status. The network layer exists to prevent these failures by making distributed work bounded, recorded, capable, reciprocal, and aligned. *** ## 4.34 Strategic Value of Networks The strategic value of networks is that they make Nexus capable of operating in the real world without losing coherence. They give Nexus distributed attention. They create regional and territorial intelligence. They develop institutional capability. They support competence formation. They connect public authorities, companies, universities, communities, providers, hosts, and contributors. They make Digital Public Goods more maintainable. They help platforms become usable. They prepare reports and public-safe outputs. They identify Marketplace, Foundry, and NXS-STU needs. They support host and node readiness. They create pathways toward national and regional formation. They prepare lawful realization without becoming execution. They make Nexus less dependent on a single center. In strategic terms, networks are one of the reasons Nexus can be federated, practical, and public-good-rooted at the same time. They distribute the capacity to carry the architecture. *** ## 4.35 Final Statement on Networks Networks are the distributed working structures of the Nexus operating system. Through geographic working groups and competence cells, they create a living fabric of coordination, capability, contextual intelligence, memory, public-safe awareness, and preparatory depth across regions, institutions, hosts, companies, universities, public authorities, communities, providers, platforms, and operational environments. They matter because Nexus cannot be truthful, resilient, or realization-capable if all of its working life remains concentrated in one place. Networks ensure that the architecture is present where it needs to be present, while still remaining aligned to one common order. Geographic working groups distribute attention and interpretation. Competence cells distribute capability and continuity. Together, they allow Nexus to listen, learn, build, support, remember, and prepare for realization without becoming centralized or fragmented. Networks are how Nexus becomes operationally distributed without losing itself. *** ## Networks and the participation pillars | Network form in this chapter | Nearest recorded pillar | Boundary recorded in the programme records | Status | | --------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------- | | Geographic working group | National Working Groups (NWG): "Assignments and responsibility follow competence." | Ordinary participation has no fee; unqualified contributors never take safety-critical tasks | No record of any formed group | | Institutional competence cell (earlier label) | Mapping pending (OQ-14); institutional participation runs through the National Nexus Consortium (NNC), where "The institution is the member." | Institutional membership does not create a Council seat, and no contribution decides a technical conclusion, public authority or procurement treatment | No record | | Corporate competence cell (earlier label) | Mapping pending (OQ-14) | A company's participation does not buy standing, recognition or procurement preference | No record | | Leadership presence in a network | National Leadership Council (NLC): "The selected individual is the member, in personal capacity." | An employer does not own a personal seat | No record | *Table 2. How the network forms of this chapter relate to the participation pillars recorded in the programme records. Mapping for orientation only; the owner has not ruled on the earlier labels. Source: consortium programme source \[4]; the documentation standard \[9].* The programme records also place "Six domain response teams" under the Working Groups and states that they "are not emergency services, incident command or privileged network-access teams" \[4]. No network described on this page is an emergency service. ## International reference points | Reference | What it offers | How this page relates | | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------- | | OECD *Recommendation on Open Government* (2017) \[11] | Transparency, integrity, accountability and stakeholder participation in public governance | Networks and public authority interfaces (section 4.21) | | Ostrom, E. (2010), polycentric governance \[12] | How many centres of decision can govern shared resources without one centre | Regionality without fragmentation (section 4.7) | | Wenger, E. (1998), communities of practice \[13] | How groups that share a domain learn through practice | Working groups and embedded capability as sites of learning (sections 4.8 and 4.16) | | OECD *Recommendation on the Governance of Critical Risks* (2014) \[14] | Whole-of-society governance of critical risks | Why networks must reach public authorities and communities (section 4.1) | | *Sendai Framework for Disaster Risk Reduction 2015-2030* \[15] | Priorities for understanding and governing disaster risk at all levels | Local and regional attention in networks; alignment, not endorsement | | *United Nations Declaration on the Rights of Indigenous Peoples* (2007) \[16] | Rights of Indigenous Peoples, including over their knowledge | Networks and protected knowledge (section 4.22) | *Table 3. International reference points for the network layer. Alignment for orientation only; naming a body is not a claim of partnership, endorsement or conformance.* ## What networks are not A network is not a council, a federation body, a national consortium, a government office, a hub office or an emergency service. A working group may gather evidence and prepare work; it does not decide, recognize, qualify providers or speak for a public authority. "Participation is not consent" and "Public-authority learning is not approval" (D-V3-0004) \[3]. Decisions stay with competent actors. ## Networks and the twenty systems As editorial alignment only, not a claim of operating service, network work would rely on [NXS-HUB](/organization/systems/nxs-hub.md), the operating workspace and controlled portal layer for knowledge, tickets and runbooks, for "Institutional knowledge, records, citations, collaboration, tickets, runbooks, meetings, learning, support and service knowledge"; on NXS-NSF for identity authorization, mandate and delegation; on [NXS-COR](/organization/systems/nxs-cor.md), the distributed compute system for compute, providers and regions, for "Compute, nodes, clusters, runtimes, workload placement, infrastructure lifecycle, capacity and execution observation" where nodes and hosts are involved; and on [NXS-POR](/organization/systems/nxs-por.md), the applied-domain public solutions and portals system, for external delivery surfaces (D-V3-0003) \[5]. System capability: target architecture. A release hold is in force: no capability has yet been observed in live use, and no capability is described beyond the stage of integrated components, with laboratory or test evidence cited only where it is attached \[6]. ## Terms used on this page | Term | Meaning on this page | Source | | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------- | --------------- | | Network | A distributed working structure that carries work without becoming a separate authority | This page | | Geographic working group | A regional or national group for context, coordination and preparation; nearest pillar NWG | This page; \[4] | | Competence cell | Earlier label for an embedded capability unit inside an institution; now mapped to NWG assignments and the CERTs (ruling R5) | \[9] | | Hub | A planned regional coordination role; "coordination roles, not offices" | \[8] | | NNC, NLC, NWG | National Nexus Consortium, National Leadership Council and National Working Groups, the three participation pillars | \[4] | | Polycentric governance | Governance by many interacting centres of decision rather than one | \[12] | ## Related pages * Up: [Operations](/organization/introduction/operations.md) * Across: [I. Order](/organization/introduction/operations/i.-order.md) · [III. Charters](/organization/introduction/operations/iii.-charters.md) · [V. Mechanisms](/organization/introduction/operations/v.-mechanisms.md) · [VI. Pillars](/organization/introduction/operations/vi.-pillars.md) · [IX. Forum](/organization/introduction/operations/ix.-forum.md) * Counterparts: [Networks in the Operations part](/organization/operations/networks.md) · [Working groups](/organization/operations/networks/working-groups.md) · [Competence cells (earlier label)](/organization/operations/networks/competence-cells.md) · [Systems](/organization/systems.md) · [VI. Federation](/organization/introduction/organization/vi.-federation.md) · [IV. Councils](/organization/introduction/cooperation/iv.-councils.md) ## Sources 1. Nexus institutional register: owner decision of 11 October 2026 on Nexus institutional architecture and participation (owner-confirmed; counsel review pending): positioning, roles and the table of what is not conferred. Internal record. 2. Nexus institutional register: legal entity profile notices on the lead contracting organization, institutional independence, consortium stewardship and platform ownership (owner-confirmed); ecosystem execution register (every instrument in draft). Internal record. 3. 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. 4. Nexus institutional register: consortium programme and consortium geography (participation pillars NNC, NLC and NWG; service levels R0 to R5 and the current service level R0, "Information and enquiries"; six regions and fifteen hubs, all recorded as planned). Internal record. 5. Nexus constitutional directive D-V3-0003, *Twenty-System Constitution* (canonical order, identifiers and remits of the twenty systems). Internal record, cited by identifier. 6. Nexus institutional register: release hold policy (in force) and claim register. Internal record. 7. Nexus constitutional directive D-V3-0001, *Master Directive V3*, and the constitutional invariants ("Authenticated != Authorized. Entitled != Authorized. Deny by default." and "Target definition != implementation. Implementation != verification. Verification != observation. Observation != authority acceptance."); the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1) is cited by identifier only and not quoted. Internal record, cited by identifier. 8. Public institutional site draft (not yet published; owner direction, not a binding record): institutional boundary sentences for GRF and GRA, council mapping note retiring earlier labels, GCRI ecosystem services (Registry, Campaigns, Labs, Foundry, Agency, Reports), [Nexus Reports](/organization/programme/reports.md) programme, Nexus Universe, platform registry counts. Draft source. 9. Nexus Documentation Standard, draft of 16 October 2026 (including conflict X-23 and open questions OQ-14 and OQ-22); owner decisions of 16 October 2026; introduction operations audit of 16 October 2026. Internal editorial records; not published. 10. Nexus constitutional directive, *Global Universal Runtime Directive V7*, section 2.5 (older institutional allocation of functions to GCRI, GRF and GRA). Internal record, cited by identifier. 11. OECD (2017). *Recommendation of the Council on Open Government*, OECD/LEGAL/0438. [legalinstruments.oecd.org](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0438). Accessed 2026-10-16. 12. Ostrom, E. (2010). Beyond markets and states: polycentric governance of complex economic systems. *American Economic Review* 100(3), 641-672. [doi.org](https://doi.org/10.1257/aer.100.3.641). Accessed 2026-10-16. 13. Wenger, E. (1998). *Communities of Practice: Learning, Meaning, and Identity*. Cambridge University Press. (URL not verified) 14. OECD (2014). *Recommendation of the Council on the Governance of Critical Risks*, OECD/LEGAL/0405. [legalinstruments.oecd.org](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405). Accessed 2026-10-16. 15. United Nations General Assembly (2015). *Sendai Framework for Disaster Risk Reduction 2015-2030*, endorsed by resolution A/RES/69/283. [docs.un.org](https://docs.un.org/en/A/RES/69/283). Accessed 2026-10-16. 16. 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. 17. GCRI (2026). *National Nexus: National Desk, National Model, National Portfolio and the NNC, NLC and NWG participation pillars*. [therisk.global](https://therisk.global/consortium/national/). Accessed 2026-10-21. 18. GCRI (2026). *How Nexus Consortium works*, the Nexus Consortium model as published on the GCRI site. [therisk.global](https://therisk.global/consortium/). Accessed 2026-10-21. 19. GCRI (2026). *Six programme regions*: fifteen planned hubs as coordination roles, never offices. [therisk.global](https://therisk.global/consortium/regions/). Accessed 2026-10-21. 20. GCRI (2026). *Working groups: the National Working Groups (NWG) and the domain response teams*. [therisk.global](https://therisk.global/consortium/national/nwg/). Accessed 2026-10-21. 21. The Global Risks Alliance (2026). *Lawful handoffs*: one-to-one handoffs released on the owner's written direction. [globalriskalliance.com](https://globalriskalliance.com/finance-readiness/handoff/). Accessed 2026-10-21. 22. The Global Risks Alliance (2026). *Finance and insurance readiness*. [globalriskalliance.com](https://globalriskalliance.com/finance-readiness/). Accessed 2026-10-21. 23. GCRI (2026). *Programme status*: programme states and the current service level R0. [therisk.global](https://therisk.global/consortium/programme-status/). Accessed 2026-10-21. ## Editorial record * As of: 2026-10-21. 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, reading note and status statement added; NNC, NLC and NWG participation pillars and the six recorded regions with fifteen planned hubs added; the eight GitBook working groups presented as a historical grouping pending owner decision; competence-cell headings marked as an earlier label with the OQ-14 note; institutional roles aligned to register wording; "protocol authority" no longer presented as an institution; "sovereign compute" recast as compute under national control; network figure, pillar mapping table, international reference points, boundaries, twenty-system alignment, terms and sources added; heading levels corrected; all original sections kept. * Change: 2026-10-16 r2, owner decisions of the second round applied: readable document record, plain-language status notes and sources, Nexus Standards display codes for systems, Nexus Observatory Protocol, and no company named. * Change: 2026-10-21 r3, aligned to the current model: "Where this fits" line; alignment note on the six pillars, the [programme year](/organization/programme/the-programme-year.md), National Nexus (NNC, NLC, NWG, CERTs), the Helix councils, the finance boundary, quarterly Nexus Reports, the [Risk Academy](/organization/programme/academy.md) issuance rule and the current service level R0; earlier council labels mapped under rulings R3 to R5; sources added from the public sites, the Nexus Standards and the external reference register; the earlier design text kept in full. --- # 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/operations/iv.-networks.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.