> 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/iv.-reading-paths.md). # IV. Reading Paths Ordered routes through the spine and the five doctrine areas of this site: the default sequence, routes for each kind of reader, and how to deepen and cross areas without misreading.
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 directive 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](/organization/institutions/nexus-standards.md) 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 · reading paths. {% 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 \[4] \[5] \[6]; 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 \[7]. {% endhint %} ## In brief A reading path is an ordered route through this site's spine and its five doctrine areas, chosen so that each page is read after the pages it depends on. The default path runs from Knowledge to Organization, Operations, Cooperation, Standardization and Acceleration. Role-specific paths reorder the middle steps for public authorities, supervisors, financial firms, technical readers, participants, researchers and implementers, but every path begins with the institutional order and ends by checking status and boundaries. [IX. Reader entry paths](/organization/introduction/knowledge/ix.-reader-entry-paths.md) gives each audience's needs \[1]. ## Summary This page gives structured reading paths through the Nexus knowledge base for different reader types. It helps institutions, technical readers, contributors, partners, and implementers find the right entry path without losing the architecture’s order. It works best with [III. Reading Rules](/organization/introduction/knowledge/iii.-reading-rules.md) and [IX. Reader Entry Paths](/organization/introduction/knowledge/ix.-reader-entry-paths.md). {% 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 %} ## 4.0 The spine route Since 21 October 2026 the site opens with a spine that holds the whole model in a few pages, so that every later page can be read in its place. The default route through the spine is: 1. [Start here](/organization/introduction/start-here.md): who is who, the status of the programme and the model in one picture. 2. [The Model](/organization/model.md): coupled risk across six sectors and the applied response of six pillars, with the [eight scenarios](/organization/model/scenarios.md). 3. [Programme](/organization/programme.md) and [the programme year](/organization/programme/the-programme-year.md): the six pillars, the eighteen handoffs, the phases and the gates G0 to G7. 4. [Governance in operation](/organization/governance-in-operation.md): the global, regional and national levels, [National Nexus](/organization/governance-in-operation/national-nexus.md), the councils and the decision rights. 5. [Finance readiness](/organization/finance-readiness.md) and the [Use by](/organization/use-by.md) page for the reader's own institution. 6. [Systems](/organization/systems.md), [Nexus Standards](/organization/standards.md) and [Reference](/organization/reference.md) when a term, system or standard needs its definition. The routes in 4.2 to 4.9 then take the reader into the five doctrine areas. Each doctrine page carries a "Where this fits" line that points back to its place in the spine. ## 4.1 Why a reading path is necessary A system such as Nexus cannot be approached as though every page carries the same weight, the same scope, or the same authority. In ordinary document environments, readers often move opportunistically: from a search result to a summary, from a summary to a diagram, from a diagram to an implementation note, and from that note to a broad institutional conclusion. That mode of reading may be tolerable where a corpus is shallow, loosely structured, or low-risk in its implications. It is not adequate for a knowledge architecture whose content spans constitutional order, governance, operating frameworks, participation systems, protocol and trust architecture, infrastructure intended for national deployment, and deployment into sensitive public-purpose environments. For that reason, the Nexus knowledge system requires a deliberate domain-by-domain reading path. This path is not designed to restrict curiosity, slow expert inquiry, or prevent direct access to specialized materials. Its purpose is to preserve interpretive order. It ensures that the reader understands not only what to read next, but why that next step follows from what has already been established. A sound reading path performs several functions at once. It reduces the risk of conceptual distortion by ensuring that foundational materials are encountered before specialized or applied materials. It improves usability by giving new readers a progression rather than a maze. It clarifies the purpose of each domain and reduces the temptation to use one area as a substitute for another. Most importantly, it creates a discipline of institutional pedagogy. The knowledge system is not merely a repository of content. It is a structured pathway through which the reader is introduced to the architecture itself. The reading path must therefore be treated as part of the design of the system and not as an optional convenience layer. ## 4.2 The general reading sequence The general reading sequence of the Nexus knowledge system is as follows: 1. **Introduction** 2. **Organization** 3. **Operations** 4. **Cooperation** 5. **Standardization** 6. **Acceleration** This sequence reflects the internal logic of the architecture. The reader begins with the **Introduction** because the knowledge system itself must be understood before any of its primary domains can be read properly. The Introduction establishes purpose, structure, interpretive rules, and the relationship among the five major areas. The reader then proceeds to **Organization** because constitutional identity, institutional role, governance, and federation provide the frame within which all later domains must be interpreted. The reader then proceeds to **Operations** because a constitutional order that cannot be understood in terms of live working discipline remains incomplete and abstract. The reader then proceeds to **Cooperation** because the architecture of participation can only be interpreted correctly once both authority and operations are clear. The reader then proceeds to **Standardization** because canonical meaning, trust architecture, semantics, protocol, conformance, and routeability must be read within a known institutional and operational context. The reader then proceeds to **Acceleration** because realization should be encountered only once the reader understands the institutional, operational, participatory, and standards-bearing architecture that realization is meant to instantiate. This is the general rule. It is the default path for any serious reader seeking a full and correct understanding of the system. ## 4.3 The reading path for new readers For a new reader, the purpose of the reading path is not exhaustive mastery at first contact. It is disciplined orientation. A new reader should begin with the **Introduction**, which explains the purpose, structure, and interpretive rules of the knowledge system. This makes clear from the outset that Nexus is neither a single organization nor a single technical platform, but a structured, multi-domain architecture. The reader should then proceed to the overview portions of **Organization**, **Operations**, **Cooperation**, **Standardization**, and **Acceleration** in that order. This permits a first-pass understanding of the five domains without requiring immediate immersion in full institutional, technical, or deployment detail. Only after that initial pass should the reader move into deeper domain-specific sections. This layered reading pattern is especially important because Nexus combines breadth with structural precision. A new reader should first understand the five domains as domains, then understand the internal logic of each, and only then proceed into specialized subdomains, annexes, profiles, or instruments. In practical terms, the new-reader path is: * **Introduction** * **Overview of Organization** * **Overview of Operations** * **Overview of Cooperation** * **Overview of Standardization** * **Overview of Acceleration** * then deeper reading according to role, need, and domain relevance This progression balances clarity with depth and prevents first-contact overload. ## 4.4 The reading path for institutional readers Institutional readers include governments, ministries, regulators, multilateral organizations, foundations, host institutions, public authorities, universities, and major ecosystem partners. These readers are often less interested in every technical detail at first than in questions of authority, legitimacy, accountability, bounded role, and real-world usability. For such readers, the most appropriate path is: 1. **Introduction** 2. **Organization** 3. **Acceleration** 4. **Standardization** 5. **Operations** 6. **Cooperation** This sequence reflects the concerns such readers typically bring. They must first understand who holds authority, how the system is governed, and how the public-good core is protected. They then need to understand how the system is intended to become real in the world through compute infrastructure, consortiums, observatory nodes (NXS-OPS), guilds and deployment pathways, and what evidence state each has today. Once that is clear, they can benefit from understanding the canonical standards and trust architecture beneath those realization pathways. Operations and Cooperation then provide the live workflows, ecosystem structures, and participation architecture that support the institutional and deployment picture. This does not replace the general rule. It is a role-sensitive entry path that remains subordinate to the same architectural order. ## 4.5 The reading path for technical and standards readers Technical architects, infrastructure partners, protocol designers, systems engineers, observability specialists, standards experts, and trust-architecture readers often arrive with a different set of priorities. Their first concern is usually not institutional ceremony but canonical structure: what the system means technically, what is invariant, what may vary, how trust is established, how interoperability is preserved, and how realization occurs without fragmenting the common rail. For such readers, the most appropriate path is: 1. **Introduction** 2. **Organization overview** 3. **Standardization** 4. **Acceleration** 5. **Operations** 6. **Cooperation** This order matters. A technical or standards reader should not begin immediately with detailed architectural or protocol materials in isolation, because the canonical architecture of Nexus is not merely technical. It is institutionally held, role-bounded, and public-good disciplined. A brief grounding in the constitutional and institutional overview is therefore necessary before entering the deeper standards corpus. The reader should then proceed to **Standardization**, because that is where the semantic spine, protocol logic, trust architecture, sovereignty framework, standards operating system, and routeability grammar are defined in their canonical form. Only once that canonical structure is understood should the reader move to **Acceleration**, where those standards are intended to become materially instantiated in compute infrastructure, observatory nodes, consortiums and deployment pathways. **Operations** follows because even the most elegant architecture must ultimately live inside actual workflows, frameworks, maintenance cycles, and reporting structures. **Cooperation** comes after that because guilds, councils, memberships, and ecosystem participation are best understood once the technical and realization order is already clear. This sequence protects technical readers from a common mistake: confusing reference architecture with implementation practice, or mistaking a realized deployment surface for the authoritative technical definition of the system. ## 4.6 The reading path for policy, governance, and public-authority readers Policy leaders, governance specialists, regulators, international civil servants, public-sector strategists, and public-authority readers often approach the system with a concern for legitimacy, institutional control, public-interest protections, safeguards, accountability, and national or regional usability. For such readers, the technical architecture matters deeply, but it matters as part of a broader governance problem rather than as an end in itself. For these readers, the most appropriate path is: 1. **Introduction** 2. **Organization** 3. **Cooperation** 4. **Standardization** 5. **Acceleration** 6. **Operations** This order reflects the fact that policy and governance readers must first understand the institutional logic of the system, then the architecture of participation and ecosystem interface, and only then the canonical doctrine and realization pathways that sit beneath and beyond them. They begin with **Organization** because legitimacy, authority, federation, public-good distinctness, and role separation are the first questions such readers must resolve. They then move to **Cooperation** because much of public-purpose governance in Nexus depends on structured participation: guilds, councils, partner interfaces, co-governance logic, and contribution pathways that preserve both breadth and safeguards. They then move to **Standardization**, because public authority cannot rely on symbolic architecture alone. Canonical meaning, trust, conformance, and routeability logic must be understood clearly if the system is to be assessed seriously. Only then should they move into **Acceleration**, where the implications for national deployment, observatory infrastructure, consortium formation, and sector realization become visible in practice. **Operations** follows last in this path not because it is less important, but because public-authority readers are often first concerned with whether the system is legitimate and governable before they examine the operational details of how it runs. ## 4.7 The reading path for ecosystem participants and contributors There is another important readership: contributors, fellows, guild members, chapter participants, partners, researchers, builders, and ecosystem actors who are neither purely institutional readers nor purely technical ones. These readers need to understand where they fit, how participation works, how contribution is structured, and how their work relates to the larger architecture. For such readers, the recommended path is: 1. **Introduction** 2. **Organization overview** 3. **Cooperation** 4. **Operations** 5. **Standardization overview** 6. **Acceleration overview** 7. then domain-specific deep reading according to role This path gives ecosystem participants enough constitutional clarity to understand the system they are joining, then moves directly into **Cooperation**, where guilds, memberships, councils, and contribution pathways are defined. From there it proceeds to **Operations**, because participation in Nexus is not informal; it is structured through frameworks, mechanisms, reporting, and production logic. Only after those two domains are understood should such readers proceed to **Standardization** and **Acceleration**, and even then often at the overview level first. Most contributors do not need to begin with full mastery of protocol architecture or deployment doctrine. They do, however, need to understand the shape of those domains and the boundaries of their own role within them. This path is particularly important because broad ecosystems often fail when participants are invited in without being given a clear mental model of the system they are entering. Nexus must do better than that. It must make participation legible before it makes specialization possible. ## 4.8 The reading path for implementers and realization partners Implementers, infrastructure partners, OEMs, systems integrators, observatory operators, compute-infrastructure stakeholders, regional hosts, and realization-side collaborators constitute another major readership. Their interest is usually concentrated on deployment, supportability, host geometry, standards alignment, and the practical conditions of making the system work under real constraints. For such readers, the most appropriate path is: 1. **Introduction** 2. **Organization overview** 3. **Standardization overview** 4. **Acceleration** 5. **Operations** 6. **Cooperation** This order ensures that implementers first understand the constitutional and public-good boundaries of the system, then the standards and trust architecture that govern realization, and only then the full deployment and realization corpus. They need **Organization overview** because implementation in Nexus is never merely technical. It sits inside a public-good-rooted, governance-bearing system in which authority, role separation, and federation matter. They need **Standardization overview** because no implementation can be serious if it is semantically or architecturally detached from the canonical rail. They then need **Acceleration** in full, because that is where compute infrastructure, observatory nodes, consortium architecture, guild-linked realization, programs, studios, accelerators, and partner interfaces are set out as the actual realization grammar of the system. **Operations** follows because implementers must eventually understand workflows, reporting, forums, mechanisms, and platform logic. **Cooperation** follows because many implementers will also sit inside guilds, partnerships, councils, or contribution structures, but they should not confuse those ecosystem roles with the primary realization architecture itself. ## 4.9 The reading path for researchers and academic readers Researchers, universities, labs, doctoral readers, policy scholars, systems thinkers, and methodological specialists often seek conceptual depth, philosophical coherence, technical seriousness, and institutional innovation. They are likely to be especially attentive to internal consistency, category formation, and the relationship between normative claims and system design. For such readers, the most appropriate path is: 1. **Introduction** 2. **Organization** 3. **Standardization** 4. **Operations** 5. **Cooperation** 6. **Acceleration** This order allows academic and research readers to first grasp the institutional thesis, then the canonical doctrinal architecture, then the live working logic of the system, then the social and ecosystem participation order, and finally the realization architecture. This is often the strongest path for readers who want to understand Nexus as a paradigm rather than merely as a deployment framework. It shows how the system is philosophically and structurally composed before it shows how that structure is expressed in collaboration and implementation. ## 4.10 Domain-specific deepening after first orientation Once the reader has completed the initial path appropriate to their role, deeper reading should occur in a second layer. For **Organization**, that deepening moves from overview into charter, foundations, governance, and federation. For **Operations**, it moves from overview into frameworks, mechanisms, reports, pillars, media, forum, and platforms. For **Cooperation**, it moves from overview into GRA, GRF, guilds, membership architecture, council interlocks, domain guild families, and ecosystem participation. For **Standardization**, it moves from overview into the Nexus Ecosystem doctrine, principles, architecture, systems, sovereignty framework, OSI, rails, conformance, and canonical reading rules. For **Acceleration**, it moves from overview into compute infrastructure (the Nexus Compute section), observatory backbone, consortium architecture, realization governance, guilds in realization, programs, studio, accelerators, partner ecosystem, safeguards, and roadmap. This second-layer pattern is important because it ensures that deep reading occurs in a domain-aware manner rather than through random traversal. It reinforces the structural logic of the system while still allowing expertise to develop in specific areas. ## 4.11 When to read across domains The reading path is sequential, but the system itself is interdependent. There are therefore moments when a reader must move laterally across domains rather than vertically deeper within one of them. A reader in **Organization** may need to consult **Standardization** to understand how public-good distinctness is expressed in the common rail. A reader in **Operations** may need to consult **Cooperation** to understand how guilds or memberships interact with production and reporting mechanisms. A reader in **Cooperation** may need to consult **Standardization** to understand why certain participation outputs are bounded by conformance and trust rules. A reader in **Standardization** may need to consult **Acceleration** to see how reference architecture is intended to be instantiated in compute infrastructure and observatory-node deployments. A reader in **Acceleration** will almost always need to consult upstream domains, because realization is inherently dependent on Organization, Operations, Cooperation, and Standardization. Cross-domain reading is therefore not exceptional; it is normal. What matters is that the reader crosses domains with structural awareness, not as though every page were equal in normative weight. ## 4.12 The reader’s responsibility A knowledge architecture can guide the reader, but it cannot read in place of the reader. A serious system requires a serious reading posture. This means the reader has responsibilities as well. The reader should not infer whole-system meaning from a single page.\ The reader should not mistake overview language for canonical rule where a deeper governing source exists.\ The reader should not treat visibility as authority.\ The reader should not assume that realization collapses the need for constitutional and standards discipline.\ The reader should not assume that a contribution pathway implies governance standing or technical authority. The reading path is therefore not only an aid. It is also an invitation to intellectual discipline. Nexus requires that discipline because it is designed to operate at the intersection of public legitimacy, institutional complexity, technical depth, and real-world consequence. ## 4.13 Final statement on the reading path The domain-by-domain reading path exists so that the reader encounters Nexus as it truly is: one coherent but differentiated system whose institutional order, operating discipline, participation architecture, canonical standards, and realization pathways must be understood in the right relation to one another. It protects new readers from confusion.\ It protects expert readers from over-reading one layer as though it were the whole.\ It protects contributors from duplicating or misplacing content.\ It protects the system from being interpreted through whichever surface happens to be most visible.\ And it protects the integrity of the whole knowledge architecture as it grows. A system of this scale can remain intelligible only if its readers are given not just content, but a structured way through it. The reading path is that structure. ## 4.14 The default path, with links | Step | Part | Start here | Read it for | | ---- | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | 1 | Knowledge | [Knowledge](/organization/introduction/knowledge.md), then [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) | How to read authority, status and boundaries | | 2 | Organization | [Organization introduction](/organization/introduction/organization.md) | Who is constituted, with what role and limits | | 3 | Operations | [Operations introduction](/organization/introduction/operations.md) | How work is produced, reviewed and published | | 4 | Cooperation | [Cooperation introduction](/organization/introduction/cooperation.md) | Who participates, how, and what is not conferred | | 5 | Standardization | [Standardization introduction](/organization/introduction/standardization.md) | Shared terms, identifiers and status vocabulary | | 6 | Acceleration | [Acceleration introduction](/organization/introduction/acceleration.md) | How capability is built and delivered, and its evidence state | *Table 1. The default reading path of section 4.2, with links. The order follows the direction of dependence set out in* [*II. Knowledge architecture*](/organization/introduction/knowledge/ii.-knowledge-architecture.md)*.* Read in three passes: 1. **Orientation.** The six introduction pages in the order above. This gives the shape of the programme without committing to detail. 2. **Depth.** The full part for the reader's question (section 4.17). 3. **Verification.** For any statement that will be relied on, the source cited on the page: the external publication, or the repository record identified by its document id. Pages are projections; the record is what binds \[1]. ## 4.15 Routes for the audiences of this site Sections 4.3 to 4.9 describe routes for broad reader types. The site is written for a set of audiences named in the documentation standard: UN agencies and other intergovernmental bodies, governments, central banks and supervisors, financial-services firms, multinationals and operators, the GCRI, GRF, GRA and Nexus Standards communities, technical readers and researchers \[1]. Every route below starts with the Knowledge and Organization introductions, because the institutional order and the reading rules govern how everything else is read. The order of the remaining steps reflects what each reader needs to assess first. | Reader | Route after Knowledge and Organization | Why this order | Check before relying on a page | | ------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | First-time reader | Operations, Cooperation, Standardization, Acceleration (introductions only) | Orientation before specialization | The status note and In brief of each page | | Governments and public authorities | Acceleration, Standardization, Cooperation, Operations | Decision rights and national control first, then how capability would be deployed and on what standards | National ownership and the boundary formulas ([I. System overview](/organization/introduction/knowledge/i.-system-overview.md)) | | UN and intergovernmental readers | Cooperation, Standardization, Acceleration, Operations | Mandate neutrality and participation routes before realization | Every citation of a UN framework is alignment, not endorsement | | Central banks and supervisors | Standardization, Acceleration, Operations, Cooperation | Method and status vocabulary before platform capability | "Finance-readiness is not finance" and the GRA boundary \[2] | | Financial-services firms | Standardization, Cooperation, Acceleration, Operations | What evidence means and who decides, before participation and platform detail | GRA "does not lend, underwrite, rate, invest, advise on or arrange transactions" \[1]\[3] | | Technical and standards readers | Standardization, Acceleration, Operations, Cooperation | Shared meaning before its realization | Status note on every capability page | | Participants and contributors | Cooperation, Operations, Standardization, Acceleration | Where they fit and how work is produced | "Participation is not consent" \[2] | | Researchers | Standardization, Operations, Cooperation, Acceleration | Concepts and methods before institutions in motion | Sources and as-of dates; disagreement between authorities is shown, not hidden | | Implementers and realization partners | Standardization, Acceleration, Operations, Cooperation | Standards that govern realization, then realization itself | "Technology readiness is not procurement approval" \[2] | *Table 2. Role-specific routes. All routes remain subordinate to the order of authority; none changes what a page means. Audiences follow the documentation standard \[1].*
Reader routes. Every reader starts with the Knowledge reading rules, then the Organization introduction. Governments go next to Acceleration; central banks, supervisors, financial firms and technical, research and implementation readers to Standardization; UN and intergovernmental readers and participants to Cooperation. Every route ends by checking status and sources.

Figure 1. Reader routes after the shared opening steps. Editorial guidance, not an authority claim; a route changes the reading order, never the meaning of a page. First-time readers follow the default path of Table 1. Source: Table 2, as of 2026-10-16.

Text description of Figure 1 Every reader starts with the Knowledge section and its reading rules (step 1), then the Organization introduction (step 2). Five audiences then take different first steps, as Table 2 sets out: governments and public authorities go next to Acceleration; central banks, supervisors and financial-services firms go next to Standardization; technical and standards readers, researchers and implementers go next to Standardization; UN and intergovernmental readers go next to Cooperation; participants and contributors go next to Cooperation. Every route ends by checking the status statement and the cited record before relying on a page. First-time readers follow the default path of Table 1 and are not drawn.
## 4.16 How the earlier routes relate to Table 2 The routes in sections 4.4 to 4.9 and those in Table 2 differ in places because Table 2 adds the audiences of the documentation standard. Where they differ, both are acceptable: a route changes the order of reading, never the meaning of a page. Institutional readers in 4.4 correspond to governments, public authorities and UN readers in Table 2; technical and standards readers in 4.5 to the technical row; policy and public-authority readers in 4.6 to the governments row; participants in 4.7, implementers in 4.8 and researchers in 4.9 to the rows of the same name. Central banks, supervisors and financial-services firms have no route in 4.3 to 4.9 and are covered by Table 2 only. ## 4.17 Deepening after the first pass, with links | Part | Where to go deeper | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Organization | [Organization part](/organization/organization.md): Overview, Architecture, Charter, Background, Foundations, Governance, Federation. Many of these pages are draft institutional instruments (L4) without an adoption record. | | Operations | [Operations part](/organization/operations.md): Frameworks, Charters, Networks, Mechanisms, Pillars, Reports, Media, Forum, Platforms. | | Cooperation | [Cooperation part](/organization/cooperation.md): Overview, Consortiums, Nexus Guilds, [Nexus Universe](/organization/programme/universe.md). | | Standardization | [Standardization part](/organization/standardization.md): Nexus Ecosystem, Nexus Sovereignty, Nexus OSI, [NXS-RLS](/organization/standardization/nexus-rail.md). | | Acceleration | [Acceleration part](/organization/acceleration.md): Overview, the build work, Nexus Compute, GCRI Campaigns, Nexus Programs, Studio, Accelerators, Charter. | *Table 3. Second-pass reading, linking section 4.10 to the parts. Section titles are kept as written; some predate the V3 system names (see* [*I. System overview*](/organization/introduction/knowledge/i.-system-overview.md)*).* When crossing areas (section 4.11), note which area owns the concept and follow its canonical page ([III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md), RR-2). Check the as-of date in the document record: a page is current only to that date. ## 4.18 Decision pending The documentation audit proposes merging this page with [IX. Reader entry paths](/organization/introduction/knowledge/ix.-reader-entry-paths.md) into a single "Reader paths" page. Structural merges await an owner decision; until then this page holds the sequences and page IX holds audience needs. ## Next steps * Read [IX. Reader Entry Paths](/organization/introduction/knowledge/ix.-reader-entry-paths.md) for use-case-based entry routes. * Read [V. Scope and Boundaries](/organization/introduction/knowledge/v.-scope-and-boundaries.md) to understand the limits of the corpus. * Start the main sequence with [Organization](/organization/introduction/organization.md). ## Related pages * Up: [Knowledge](/organization/introduction/knowledge.md) * Across: [IX. Reader entry paths](/organization/introduction/knowledge/ix.-reader-entry-paths.md) · [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) · [V. Scope and boundaries](/organization/introduction/knowledge/v.-scope-and-boundaries.md) * Counterparts: [Introduction](/organization/introduction.md) · [Organization introduction](/organization/introduction/organization.md) ## Sources 1. Nexus Documentation Standard, draft of 16 October 2026 (purpose, audiences, what world-class means; hubs, canonical pages, click depth). 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* (GRA role and what is not conferred). Internal record; owner-confirmed, counsel review pending. 4. 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/). 5. 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/). 6. 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/). 7. 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. ## 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 and In brief; fixed the inverted heading hierarchy (H3 part title above H4 sections) and removed the empty "Part IV" heading; renamed "Operation" to "Operations"; replaced "sovereign compute", "sovereign actors" and "sovereign deployment" wording; kept every reader route and added the linked default path, the three reading passes, the audience route table aligned to the standard's audience list (including central banks, supervisors and financial-services firms), the route figure, the reconciliation of old and new routes, the linked deepening table 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 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/iv.-reading-paths.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.