> 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/knowledge/ii.-knowledge-architecture.md). # II. Knowledge Architecture The canonical description of the five subject areas of this site: the burden and question of each, what each does not do, and how they depend on each other.
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 Documentation Standard (draft); Nexus constitutional directives D-V3-0001, D-V3-0003 and D-V3-0004; Nexus institutional architecture and participation; the Nexus model and the Nexus Consortium model as published on the sites (2026-10-21); the Nexus Standards governance and [NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
**Where this fits:** all six sectors · all six pillars, above all Nexus Standards and Nexus Reports for the rules of this documentation · the Nexus Consortium, with GCRI Canada as Secretariat · Publish and Renew in the cycle · reader's guide. {% hint style="info" %} **Read with the current model (21 October 2026).** The documentation itself is now organized in two layers: a spine ([The Model](/organization/model.md), [Institutions](/organization/institutions.md), [Programme](/organization/programme.md), [Governance in operation](/organization/governance-in-operation.md), [Finance readiness](/organization/finance-readiness.md), [Use by](/organization/use-by.md), [Systems](/organization/systems.md), [Nexus Standards](/organization/standards.md) and [Reference](/organization/reference.md)), and under it the five doctrine areas this section describes. Citation and identifiers follow NS-2 and NS-1, and drafting follows NS-4 \[5] \[6] \[7]; the house rules are in the [citation style](/organization/reference/citation-style.md). This page now reads against the two linked models that organize the whole documentation: [coupled risk](/organization/model/coupled-risk.md) across six sectors and fifteen relations, and [applied response](/organization/model/applied-response.md) through six pillars, eighteen handoffs and one [programme year](/organization/programme/the-programme-year.md) with gates G0 to G7 \[8]. No standards foundation or "protocol authority" exists as an institution. Standards are developed in the open by [Nexus Standards](/organization/institutions/nexus-standards.md), governed by the Global Standards Council with GCRI Canada as secretariat and publisher of record, and adoption is final for each jurisdiction \[9] \[10]; trust, authorization, mandate and policy in the systems sit in [NXS-NSF](/organization/systems/nxs-nsf.md) ([Systems](/organization/systems.md)). {% endhint %} {% 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 The knowledge architecture is the way this site divides the Nexus programme into five subject areas: Organization, Operations, Cooperation, Standardization and Acceleration. Each area answers one question and owns the full definition of its own concepts; other areas summarize and link. The areas are read in an order of dependence, so that participation, standards and realization are always interpreted against the institutions and methods they rest on. This page is the canonical description of the five areas \[1]. ## Summary This page explains why Nexus is organized into five knowledge domains and what each domain is responsible for. It defines the structural logic that prevents governance, operations, standards, participation, and realization from collapsing into one another. Read this page with [III. Reading Rules](/organization/introduction/knowledge/iii.-reading-rules.md) and [VI. Structural Logic](/organization/introduction/knowledge/vi.-structural-logic.md) to understand how the knowledge base stays coherent. {% 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 %} ## 2.1 Why the knowledge system is organized in five areas The five-area architecture of Nexus is not an editorial convenience, a website taxonomy, or a document-management preference. It is the written expression of the system’s governing discipline. Nexus can only remain coherent if its distinct forms of authority, work, participation, standard-setting, and realization are kept in proper relation to one another. The knowledge system therefore mirrors the institutional and operational logic of the architecture itself. A lesser system might allow governance, technical doctrine, collaboration, and implementation to accumulate in one undifferentiated corpus. Nexus cannot do so without losing truth. If constitutional materials are mixed with operational manuals, workflow can begin to masquerade as authority. If participation materials are mixed with standards materials, social energy can begin to redefine canonical meaning. If realization materials are mixed with constitutional materials, deployment pressure can begin to rewrite the public-good core. The five-area architecture exists to prevent those failures before they occur. Each area corresponds to a distinct burden. **Organization** carries constitutional and institutional burden.\ **Operations** carries procedural and production burden.\ **Cooperation** carries ecosystem and participation burden.\ **Standardization** carries canonical and trust-bearing burden.\ **Acceleration** carries realization and deployment burden. Because these burdens are different, their documents must be different, their reading rules must be different, and their authority must be different. The five-area architecture is therefore not merely a classification system. It is a discipline of institutional truth. ## 2.2 Organization as the constitutional and institutional domain Organization is the first domain because a reader must understand what Nexus is before they can understand what Nexus does. It is the domain in which the system’s institutional meaning is fixed. It defines the constitutional identity of the whole architecture, the role of the core institutions, the governance bodies that carry authority, the federated order through which the system localizes, and the boundaries that prevent institutional substitution. Organization should therefore be read as the place where the reader encounters the structural thesis of Nexus in institutional form. Here the reader learns that Nexus is not one organization with many programs, but one coordinated order composed of differentiated institutions and differentiated roles. Here the reader learns why GCRI, GRF and GRA must remain distinct institutions, and why NXS-NSF, the trust, sovereignty and assurance plane for identity, policy gates and access decisions, is one of the twenty Nexus systems and not an institution (earlier versions of this page paired it with a "Protocol Authority"; no such body is on record) \[1]\[4]. Here the reader learns how global coherence, regional support, national grounding, and host reality fit together. Here the reader learns what may be governed, by whom, and under what authority. Organization is also the place where the system’s deepest boundaries are fixed. It establishes what the public-good core is, what it may carry, what it may never imply, how downstream enterprise or capital-facing layers relate to it, how federation works, and how the institutional architecture remains one system across many jurisdictions and settings. If Organization is weak, every other area becomes vulnerable to drift. If Organization is strong, the rest of the system can grow without losing its center. For that reason, Organization is not a descriptive front section or a conventional institutional overview. It is the constitutional entry point of the entire knowledge system. ## 2.3 Operations as the live working domain Once the constitutional order is understood, the reader must next understand how the system behaves in practice. This is the purpose of Operations. (Earlier versions of this page called this area "Operation"; the site part is named Operations, and that name is used throughout.) Operations is the domain in which Nexus is designed to become a real working system rather than a set of institutional abstractions. It defines how work is organized, how frameworks structure practice, how production is coordinated, how mechanisms govern learning and contribution, how reports and outputs are generated, how forums and media surfaces operate, and how the system’s live processes remain traceable, reviewable, and correctable over time. Operations should not be misread as a domain of low-level administration. It is the architecture of disciplined motion. It shows how the system moves without collapsing into informality, duplication, or improvisation. It translates structural principles into working methods. It ensures that contributions become governed outputs rather than scattered activity. It ensures that learning becomes a structured institutional asset rather than a by-product of participation. It ensures that publication, reporting, coordination, and platform use all occur within one legible operating grammar. If Organization answers the question of institutional legitimacy, Operations answers the question of institutional seriousness. A system that cannot describe its own working discipline will eventually lose the trust created by its constitutional design. Nexus therefore treats operations as a first-class domain of thought, not as a secondary matter left to management custom. ## 2.4 Cooperation as the participation and ecosystem domain After constitutional form and operating discipline have been established, the reader must understand how participation enters the system. This is the role of Cooperation. Cooperation defines the architecture through which institutions, experts, communities, guilds, councils, partners, and ecosystem actors take part in Nexus without dissolving its structural integrity. It is the domain in which contribution becomes governed rather than merely welcomed. It explains how the system grows outward while preserving role clarity inward. This is especially important because Nexus is designed as a public-good-rooted, globally structured, multi-actor order. Such systems often fail because participation remains under-specified. When contribution pathways are vague, the strongest actors begin to shape meaning by presence alone. When councils and guilds are weakly defined, enthusiasm becomes a substitute for authority. When ecosystem partnerships are not properly bounded, cooperation becomes a pathway for hidden capture. Cooperation as a primary domain exists to prevent these distortions. It does so by defining councils, guilds, memberships, co-governance structures, partner interfaces, contribution pathways, safeguards, and artifact classes. It allows domain specialization to occur without fragmenting the common rail. It allows broad participation without allowing participation to rewrite constitutional order or canonical doctrine. It makes the social and ecosystem life of Nexus intelligible, accountable, and durable. Cooperation therefore answers a question deeper than “who is involved?” It answers: **How can many actors take part in one public-good-rooted architecture without turning plurality into incoherence?** ## 2.5 Standardization as the canonical domain Once the reader understands institutional order, operating discipline, and participation structure, the reader must encounter the canonical architecture that holds the system together across all of those layers. This is the role of Standardization. Standardization defines what is canonical in Nexus: the common rail of meaning, the semantic spine, the protocol and trust order, the conformance logic, the sovereignty framework, the standards operating system, and the routeability grammar that permits evidence, readiness, and bounded handoff to remain intelligible across geographies, sectors, and deployments. It is the keeper of coherence. Without Standardization, the system would risk becoming a federation of stories rather than a federation of interoperable realities. Local adaptations would drift into local doctrines. Sector-specific innovations would become hidden forks. Technical systems would evolve without canonical discipline. Terms would travel faster than their meaning. Trust would weaken because readers could no longer know whether the same words referred to the same architecture. Standardization prevents that outcome. It does not impose uniformity for its own sake. Rather, it preserves the conditions under which local variation, domain specialization, and technical realization can occur without loss of conceptual, semantic, and protocol continuity. It is what allows the system to be many-sided without becoming many systems. This is why Standardization must not be treated as a technical appendix or a specialist corner of the knowledge base. It is a primary domain because the integrity of the entire architecture depends upon it. ## 2.6 Acceleration as the realization domain Only after the reader understands institutional order, operational discipline, participation architecture, and canonical standards can the reader properly approach realization. This is the purpose of Acceleration. Acceleration is the domain in which Nexus is intended to become materially, institutionally and geographically real. It explains how compute infrastructure, observatory nodes (NXS-OPS), national and regional consortiums, specialized guilds, programmes, studios, accelerators, partner ecosystems and deployment pathways are intended to convert the architecture from a standards-bearing and institutionally governed order into a lived infrastructure of capability. This domain must come last because it is where all previous layers become visible in the world. It is the place most likely to attract attention from builders, partners, implementers, and capital-adjacent readers. For that reason, it is also the place most vulnerable to misinterpretation. If read in isolation, realization can appear to be the whole system. The five-area architecture prevents that mistake. It ensures that realization is read as realization of something already constitutionally formed, operationally disciplined, cooperatively structured, and canonically defined. Acceleration therefore does not stand apart from the other domains. It depends on them. It is the proof of their seriousness, but not their substitute. ## 2.7 The distinct question each area answers A mature knowledge architecture avoids overlap by ensuring that each major domain answers a distinct question. **Organization** answers:\ *What is the institutional form of Nexus, how is authority constituted, and how is the system federated?* **Operations** answers:\ *How does Nexus function as a real working system, and through what frameworks, mechanisms, and production logic does it maintain live discipline?* **Cooperation** answers:\ *Who participates in Nexus, through what structures, and under what role-specific safeguards, councils, guilds, and contribution pathways?* **Standardization** answers:\ *What is canonical, interoperable, trusted, and valid across the architecture, and what must remain invariant as the system evolves?* **Acceleration** answers:\ *How is the architecture intended to become real through infrastructure that supports national deployment profiles, observatory systems, consortiums, guilds, programmes and deployment pathways, and what is its evidence state today?* The more precisely these questions are kept separate, the stronger the whole knowledge system becomes. Ambiguity between them is not merely untidy. It is structurally dangerous. ## 2.8 The direction of dependence The five-area architecture is ordered not only by sequence, but by dependence. Operations depends on Organization because workflows must remain subordinate to institutional authority. Cooperation depends on Organization and Operations because participation must occur within a known institutional order and a functioning operating discipline. Standardization depends on Organization, Operations and Cooperation because canonical doctrine must be interpreted in relation to the institutions that hold it, the operations that use it, and the participation structures through which it circulates and is applied. Acceleration depends on all four previous domains because realization must remain subordinate to institutional legitimacy, operational discipline, cooperation architecture, and canonical standards if it is not to drift into fragmentation or silent redefinition. This dependence is one-directional. Realization may inform standards evolution through proper channels, but it may not redefine canonical doctrine by fact of deployment. Participation may enrich institutional life, but it may not become constitutional authority by recurrence. Operations may improve governance visibility, but they may not transform workflow into legitimacy. These are not philosophical niceties. They are practical protections for long-horizon coherence.
Direction of dependence among the five subject areas. Organization is read first; Operations depends on it; Cooperation depends on Organization and Operations; Standardization on the first three; Acceleration on all four. Acceleration feeds proposals to a review route that leads back to Standardization only through review.

Figure 1. Direction of dependence among the five subject areas. Editorial structure, not an authority claim: binding records outrank every area. The highlighted path is the default reading order; grey lines show the further dependences; realization reaches Standardization only as proposals through the review route. Source: this page, sections 2.2 to 2.8, as of 2026-10-16.

Text description of Figure 1 Organization (part 1, institutional form) is interpreted first. Operations (part 2) depends on Organization. Cooperation (part 3) depends on Organization and Operations. Standardization (part 4) depends on Organization, Operations and Cooperation. Acceleration (part 5) depends on all four. The highlighted path Organization, Operations, Cooperation, Standardization, Acceleration is the default reading order. A separate line runs from Acceleration to a review route, a gate that carries proposals only to Standardization, meaning that realization experience can propose changes to shared meaning only through the review and correction route described in [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md).
## 2.9 The rule against domain collapse A central danger in complex systems is domain collapse: the gradual tendency of one domain to speak as though it were another. An operational mechanism may begin to be treated as though it carries constitutional authority.\ A guild may begin to speak as though it defines doctrine.\ A standards artifact may begin to be treated as though it constitutes governance.\ A realization pathway may begin to imply execution authority.\ A highly visible institution may begin to be mistaken for the whole architecture. The five-area architecture is designed specifically to prevent such collapse. It does so by requiring that every document, every page, every program, every framework, and every deployment concept be located within the correct domain and interpreted accordingly. This is why the knowledge architecture matters. It is not only about navigation. It is about preserving the integrity of distinctions on which the whole system depends. The commonest forms of collapse, and the rule that prevents each, are: | Collapse | Example | Rule | | ------------------------------- | ---------------------------------------------------------- | --------------------------------------------------------- | | Method read as mandate | A reporting framework treated as an institutional decision | Organization owns roles; Operations links to them | | Participation read as authority | A guild output treated as doctrine | "Participation is not consent" \[2] | | Standard read as certificate | A conformance check described as certification | "Verification is not certification" \[2] | | Plan read as service | A deployment pathway described in the present tense | Present tense only for what operates now \[1] | | Visibility read as importance | The most visible page treated as the whole programme | Each area is complete locally and incomplete systemically | *Table 1. Forms of domain collapse and the rule that prevents each. Sources: D-V3-0004 boundary formulas and the documentation standard \[1]\[2].* ## 2.10 Local variation and common structure One of the greatest strengths of the five-area architecture is that it permits local depth without systemic fragmentation. A domain guild may become highly specialized.\ A national consortium may develop context-specific programs.\ A regional node may adopt distinctive corridor logics.\ An observatory deployment may reflect local ecological or institutional realities.\ A program or academy track may evolve for a specific field or geography. All of these variations are permissible. But they remain legible only because they occur within one organizational, operational, cooperative, standards-bearing, and acceleration-aware frame. The five-area architecture makes that possible by ensuring that local elaboration is always anchored in one common order. In this sense, the five areas are not only categories of content. They are the shared grammar that permits lawful and coherent variation across the entire ecosystem. ## 2.11 Why this architecture matters for readers For a new reader, the immediate value of the five-area architecture is clarity. It tells them where to look for authority, where to look for methods, where to look for participation structures, where to look for canonical doctrine, and where to look for realization pathways. For an institutional reader, its value is defensibility. It ensures that one can distinguish what is constitutional from what is operational, what is canonical from what is experimental, what is participatory from what is authoritative, and what is routeable from what is already execution-bearing. For an internal contributor, its value is discipline. It reduces duplication, prevents cross-domain drift, and creates a stable architecture within which new materials can be developed without weakening the whole. For the system itself, its value is longevity. A knowledge system that remains clear under scale is far more likely to preserve institutional seriousness than one that grows by accumulation alone. ## 2.12 Final statement on the five-area architecture The five-area architecture is the governing form of the Nexus knowledge system. It is the reason the whole can remain one order without becoming one undifferentiated body of text. Organization gives the system institutional form.\ Operations gives it working discipline.\ Cooperation gives it social and ecosystem depth.\ Standardization gives it canonical meaning.\ Acceleration gives it real-world realization. Together, these domains form the minimum complete structure through which Nexus can be explained, governed, built, and sustained without sacrificing clarity, legitimacy, or coherence. This is the architecture through which all further reading should proceed. ## 2.13 What each area covers on this site Sections 2.2 to 2.6 explain the burden of each area. This section adds, for each area, where it lives on this site, the reading note a reader needs and what the area does not do. The five areas are an editorial structure for this site. They are not legal entities, not governance bodies and not the twenty the Nexus systems. ### Organization **Covers.** The institutional order of the programme: institutions and their roles, charters, background, foundations, governance and federation across global, regional and national levels. On this site: the [Organization introduction](/organization/introduction/organization.md) and the [Organization part](/organization/organization.md). **Reading note.** Many pages in the Organization part are draft institutional instruments (authority level L4) without an adoption record; they are protected records whose text changes only with a per-record owner approval \[1]. Institutional roles bind through registers: GCRI Canada is the Lead Institution, Consortium Secretariat and lead contracting organization; [The Global Risks Forum](/organization/institutions/grf.md) (GRF) and [The Global Risks Alliance](/organization/institutions/gra.md) (GRA) are independent consortium stewards \[3]. NXS-NSF is one of the twenty Nexus systems, not an institution, and no standards foundation or "Protocol Authority" body is on record \[1]. **Does not.** Organization pages do not describe how the platform runs, and an explanatory overview does not amend any instrument. ### Operations **Covers.** How work is organized and published: frameworks, operational charters, networks, mechanisms, the Pillars pages, reports, media, the forum and platforms. On this site: the [Operations introduction](/organization/introduction/operations.md) and the [Operations part](/organization/operations.md). **Reading note.** [Nexus Reports](/organization/programme/reports.md) is the governed publication programme; a planned edition is never shown as published \[1]. In the V3 architecture, institutional records, citations and runbooks belong to [NXS-HUB](/organization/systems/nxs-hub.md), the operating workspace and controlled portal layer for knowledge, tickets and runbooks \[4]. "Pillars" here is the title of an Operations section and does not describe institutions. **Does not.** A working method does not confer institutional standing or authority. ### Cooperation **Covers.** How institutions and people take part: consortiums, guilds, the [Nexus Universe](/organization/programme/universe.md) programme, membership and participation pathways. On this site: the [Cooperation introduction](/organization/introduction/cooperation.md) and the [Cooperation part](/organization/cooperation.md). **Reading note.** The current council vocabulary uses three participation routes, abbreviated NNC (institutions, where the institution is the member), NLC (individual leaders in a personal capacity) and NWG (experts and delivery teams, by competence) \[1]. Nexus Universe is the annual programme of Nexus Consortiums whose governance rests with GRF \[3]. Some older pages use council labels that predate this vocabulary; their mapping awaits an owner decision. **Does not.** "Participation is not consent" \[2]. An enquiry is not membership and an application is not acceptance. ### Standardization **Covers.** Shared meaning and status: doctrine, ontology, identifiers, status vocabulary, protocol and outputs. On this site: the [Standardization introduction](/organization/introduction/standardization.md) and the [Standardization part](/organization/standardization.md) (Nexus Ecosystem, Nexus Sovereignty, Nexus OSI, [NXS-RLS](/organization/standardization/nexus-rail.md); section titles are kept as written). **Reading note.** Nexus Standards is a proposed standards programme: its documents are PROPOSED, not adopted, and no publisher of record is named \[1]. Identifiers follow the UNI Identifier Fabric, under which "Identifier resolution is not authorization, certification or truth" \[4]. Conformance language distinguishes computed, signed and recognized results; no attestation is described as a certificate \[1]. **Does not.** A standard, profile or identifier does not authorize, certify or prove anything on its own. ### Acceleration **Covers.** Realization: compute and edge infrastructure, build and composition environments, programmes, the marketplace concept, consortium realization and campaigns. On this site: the [Acceleration introduction](/organization/introduction/acceleration.md) and the [Acceleration part](/organization/acceleration.md). **Reading note.** In V3 terms, compute maps to [NXS-COR](/organization/systems/nxs-cor.md), the distributed compute system for compute, providers and regions, and [NXS-NET](/organization/systems/nxs-net.md), the network intelligence and communications resilience system; edge and observation to NXS-OPS, NXS-EOP and [NXS-EWS](/organization/systems/nxs-ews.md), the early warning support system for watches and warning readiness, which never issues official alerts; build and composition to [NXS-FAC](/organization/systems/nxs-fac.md), the mission application factory, which produces app blueprints but never runs them, and [NXS-STU](/organization/systems/nxs-stu.md), the builder and configuration workspace, which composes but never deploys; catalogue and installation to [NXS-NXQ](/organization/systems/nxs-nxq.md), the software, capability and agent fabric for registries, licensing, APIs and connectors, and [NXS-APP](/organization/systems/nxs-app.md), the mission app runtime, for app instances, routes and versions \[4]. This crosswalk is an editorial proposal awaiting owner review (see [I. System overview](/organization/introduction/knowledge/i.-system-overview.md)). The Acceleration section on the build work is narrower than the twenty systems, which the [SYSTEMS part](/organization/systems.md) documents. **Does not.** A deployment plan is not a deployment, and "Technology readiness is not procurement approval" \[2]. Every Acceleration page that describes platform capability carries the status note. ## 2.14 The areas at a glance | Area | Primary question | Typical page class | Must not be read as | | --------------- | ---------------------------------------------------------------------- | --------------------------------------- | -------------------------------------------------------- | | Organization | Who is constituted, with what role and limits? | Draft instrument (L4), explanatory (L5) | Adopted law, or a description of running services | | Operations | How is work produced, reviewed and published? | Explanatory (L5), programme | A grant of authority or standing | | Cooperation | Who participates, how, and what is not conferred? | Community and programme pages (L5) | Consent, membership or acceptance | | Standardization | What do shared terms, identifiers and status words mean? | Standard specification, doctrine (L5) | Certification, authorization or official standard status | | Acceleration | How is capability built and delivered, and what is its evidence state? | Platform and programme pages (L5) | An operating, production or “sovereign-ready” service | *Table 2. Primary question per area. Authority levels are defined in* [*VI. Structural logic*](/organization/introduction/knowledge/vi.-structural-logic.md)*; page classes in* [*VII. Knowledge lifecycle*](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md)*.* ## 2.15 Why the order serves the site's readers The order of dependence is also the order in which the risks of misreading are greatest for the audiences of this site. A government reader needs the institutional limits (Organization) before any deployment page (Acceleration); a supervisor needs the status vocabulary (Standardization) before any statement about finance-readiness; a participant needs the participation routes (Cooperation) before the methods that use contributions (Operations). The role-specific routes that follow from this are in [IV. Reading paths](/organization/introduction/knowledge/iv.-reading-paths.md) and [IX. Reader entry paths](/organization/introduction/knowledge/ix.-reader-entry-paths.md). ## 2.16 Decisions pending * **Consolidation.** The documentation audit recommends that this page become the first child of a consolidated Knowledge hub. Structural changes await an owner decision. * **Concept crosswalk.** The mapping of site section names (Compute, Edge, Foundry, Marketplace, Registry, Protocol, Ontology) to V3 systems and fabrics awaits owner review. * **Council vocabulary.** The mapping of older council labels to the NNC, NLC and NWG routes awaits an owner decision. ## Next steps * Read [III. Reading Rules](/organization/introduction/knowledge/iii.-reading-rules.md) for cross-domain interpretation rules. * Read [VI. Structural Logic](/organization/introduction/knowledge/vi.-structural-logic.md) for non-duplication and editorial control. * Continue into [Organization](/organization/introduction/organization.md) to start the full domain reading path. ## Related pages * Up: [Knowledge](/organization/introduction/knowledge.md) * Across: [I. System overview](/organization/introduction/knowledge/i.-system-overview.md) · [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) · [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md) · [IV. Reading paths](/organization/introduction/knowledge/iv.-reading-paths.md) * Counterparts: [Organization](/organization/introduction/organization.md) · [Operations](/organization/introduction/operations.md) · [Cooperation](/organization/introduction/cooperation.md) · [Standardization](/organization/introduction/standardization.md) · [Acceleration](/organization/introduction/acceleration.md) ## Sources 1. Nexus Documentation Standard, draft of 16 October 2026: site structure, terms, status wording and canonical pages. Internal editorial standard; not published. 2. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks and non-execution*, boundary formulas. Internal record, cited by identifier. 3. Nexus institutional register, *Nexus institutional architecture and participation*, including the lead contracting organization and consortium stewardship notices. Internal record; owner-confirmed, counsel review pending. 4. Nexus constitutional directives D-V3-0003, *Twenty-system constitution*, and D-V3-0001, *Master directive V3* (shared fabrics). Internal records, cited by identifier. 5. Nexus Standards. *NS-2: Citation and attribution*, UNI `NXS-STD-ST-000009`, status PROPOSED. [nexustandards.com/standards/ns-2](https://nexustandards.com/standards/ns-2/). 6. Nexus Standards. *NS-1: The UNI and the artifact catalog*, UNI `NXS-STD-ST-000001`, status PROPOSED. [nexustandards.com/standards/ns-1](https://nexustandards.com/standards/ns-1/). 7. Nexus Standards. *NS-4: Structure and drafting of Nexus Standards and documents*, UNI `NXS-STD-ST-000010`, status PROPOSED. [nexustandards.com/standards/ns-4](https://nexustandards.com/standards/ns-4/). 8. GCRI. *How Nexus works*: the six pillars, the eighteen handoffs and the eight-step cycle. [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Accessed 2026-10-21. 9. Nexus Standards. *Governance*: the Global Standards Council, technical committees, National Standards Councils and the secretariat. [nexustandards.com/governance](https://nexustandards.com/governance/). Accessed 2026-10-21. 10. Nexus Standards. *NS-13: Open standards development process*, UNI `NXS-STD-ST-000008`, status PROPOSED. [nexustandards.com/standards/ns-13](https://nexustandards.com/standards/ns-13/). ## Editorial record * As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted. 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 log: 2026-10-16 r1, upgraded to the documentation standard draft. Added the Record block, status note and In brief; removed the empty "Part II" heading and fixed heading levels; renamed "Operation" to "Operations" to match the site part; replaced "NSF / the Protocol Authority" with the V3 system definition; removed rendering residue (`&#xNAN;`) from the area questions; replaced "sovereign compute" wording; added the dependency figure, the domain-collapse table, per-area coverage and reading notes with links to every part, the areas-at-a-glance table, audience rationale, pending decisions and sources. 2026-10-16 r2, readable document record and status note; Nexus Standards system codes; Nexus Standards system naming and Nexus Observatory Protocol naming; company references removed; plain-language sources. 2026-10-21 r3, aligned with the latest sources: Where this fits line and current-model note added; institutional roles, standards governance (no standards foundation or protocol authority as an institution), councils (six [Helix councils](/organization/governance-in-operation/councils.md), [CERTs](/organization/governance-in-operation/nwg.md)), [National Nexus](/organization/governance-in-operation/national-nexus.md) and the finance boundary corrected against the Nexus model, the Nexus Consortium model and the Nexus Standards governance; retired labels mapped to successors; sources extended with the public site pages, Nexus Standards identifiers and international frameworks. --- # 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/knowledge/ii.-knowledge-architecture.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.