> 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/ix.-reader-entry-paths.md).
# IX. Reader Entry Paths
What each audience needs from this site, the boundaries that matter most to it, and the entry paths for UN bodies, states, supervisors, firms and contributors.
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 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](/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 · entry paths by reader.
{% 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 \[8] \[9] \[10]; 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 \[11]. 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 ([status and service levels](/organization/governance-in-operation/status-and-service-levels.md)) \[12].
{% 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
Reader entry paths match each audience of this site to what it needs, the boundaries it should check first and the questions it should bring. The site is written for 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. Every audience reads the same pages; what differs is the entry point and the checks that matter most \[1].
## Summary
This page maps the Nexus knowledge base to different reader types and use cases. It helps sovereigns, institutions, technical experts, contributors, partners, researchers, and realization teams enter the system through the right sequence.
It builds on [IV. Reading Paths](/organization/introduction/knowledge/iv.-reading-paths.md) and prepares readers for [XI. Final Orientation](/organization/introduction/knowledge/xi.-final-orientation.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 %}
## 9.1 Why reader types must be defined
A knowledge system of this scale cannot assume a single ideal reader. Nexus speaks simultaneously to public institutions of states, multilateral actors, technical architects, researchers, ecosystem participants, infrastructure partners, funders, civil-society institutions, and implementation actors. Each of these readers approaches the system with a different problem, a different threshold of familiarity, a different tolerance for abstraction, and a different need for certainty about what the architecture means in practice.
If the knowledge base is written as though all readers are the same, it will fail in two directions at once. It will become too dense and structurally remote for those who need orientation, and too shallow or rhetorically generalized for those who need precision. The answer is not to fragment the knowledge system into unrelated versions of itself. The answer is to define reader types and give each of them a disciplined path into one common architecture.
This is especially important in Nexus because reading is not a neutral act. A sovereign reader may infer governance implications. A technical reader may infer architectural constraints. A partner may infer participation rights. A realization actor may infer deployment maturity. A funder may infer readiness. A researcher may infer theoretical claims. The knowledge system must therefore anticipate not only what readers seek, but what kinds of conclusions they are likely to draw from what they read.
For that reason, reader types are not a marketing device or a user-experience convenience. They are an interpretive safeguard. They help ensure that each audience encounters the architecture through the right entry points, at the right level of abstraction, and in the right sequence of authority.
## 9.2 The general reader
The general reader is someone encountering Nexus for the first time without prior immersion in its institutional or technical logic. This reader may be intelligent, serious, and highly capable, but does not yet possess the internal vocabulary of the system. Such a reader often needs three things above all: orientation, distinctions, and confidence that the architecture is coherent.
The general reader should not be asked to begin with deep protocol doctrine, operational mechanisms, or specialized deployment models. Nor should this reader be left with only rhetorical summaries that conceal the seriousness of the system. The correct entry path is one that introduces the architecture in broad but disciplined terms.
For the general reader, the knowledge system should first answer:
* What is Nexus?
* Why does it exist?
* How is it organized?
* What are its major domains?
* How should one continue reading?
The general reader therefore begins with the Introduction, then the high-level overviews of the five primary domains, and only after that moves into deeper materials based on need. This path privileges orientation before specialization and prevents early overload without sacrificing architectural truth.
## 9.3 The institutional reader
The institutional reader includes ministries, regulators, multilaterals, public authorities, national and regional public actors, universities, host institutions, and major strategic organizations. This reader’s first concern is rarely product detail. It is legitimacy, bounded authority, governance discipline, federation, role separation, and the relationship between public-good architecture and real-world implementation.
The institutional reader must first understand:
* who holds what role;
* how authority is structured;
* how the public-good core is protected;
* how realization relates to governance;
* and how the system respects sovereignty, federation, and public-purpose constraints.
For this reason, the institutional entry path should move first through the Introduction and Organization, then into Acceleration and Standardization, before moving to Operations and Cooperation. This sequence allows the institutional reader to first see the constitutional and realization-bearing shape of the system, then the canonical standards logic beneath it, and only afterward the detailed operating and participatory machinery.
Institutional readers are especially sensitive to implication. A knowledge system that fails to clarify bounded authority, public-good distinctness, and non-execution discipline will appear risky or immature to them. The entry path must therefore surface those disciplines early and clearly.
## 9.4 The sovereign and public-authority reader
Within the broader institutional class, sovereign and public-authority readers deserve special attention because the questions they ask are often more exacting. They must determine not only whether the architecture is coherent, but whether it can coexist with national primacy, public accountability, lawful local grounding, and the realities of public administration and infrastructure stewardship.
This reader is likely to ask:
* Does this architecture respect sovereignty?
* Where does authority sit and where does it not sit?
* How do national and regional structures relate?
* What is the status of observatory infrastructure and of compute infrastructure intended for national deployment?
* What is implied, and what is not implied, by routeability and readiness?
For such readers, the knowledge system must highlight federation, host logic, public-good distinctness, routeability boundaries, and realization pathways early. It must also avoid the common error of speaking as though the existence of a technical or institutional model implies public adoption or sovereign endorsement. Public-authority readers are often alert to hidden overreach. The knowledge base should reward that alertness by being exact.
Their entry path should therefore place strong emphasis on Organization, Acceleration, and Standardization, with Operations and Cooperation following as the system deepens.
## 9.5 The technical reader
The technical reader includes architects, engineers, protocol specialists, infrastructure partners, observability specialists, semantic and standards practitioners, security and trust experts, and technical strategists. This reader seeks precision, coherence, architecture, and implementation discipline. They are often less patient with rhetorical framing and more attentive to whether the system has a true canonical spine.
The technical reader will often ask:
* What is the common rail?
* What is canonical and what is contextual?
* What is the role of the protocol and trust architecture?
* How do node, cluster, and core relate?
* How do observatory systems, routeability objects, and standards operating systems connect?
For such readers, the system must provide a clear route from institutional context into canonical architecture and then into realization. They need enough constitutional and public-good framing to understand that Nexus is not merely a technical stack, but once that frame is set, they must be able to move quickly into Standardization and Acceleration.
Technical readers are especially vulnerable to a different kind of misreading: the tendency to mistake reference architecture for total architecture. The knowledge system should help them see that technical structure in Nexus is inseparable from governance, participation, and bounded realization. The best path therefore begins with a light institutional grounding, then moves into Standardization in depth, and then into Acceleration as the realization of that canonical structure.
## 9.6 The standards and protocol reader
This reader overlaps with the technical reader but has a more specific concern: canonical meaning, conformance, trust, interoperability, anti-fork discipline, and standards-bearing coherence. They are less interested in implementation for its own sake than in whether the system can remain one architecture across many localizations and specializations.
The standards reader asks:
* What is canonical?
* What can vary and what cannot?
* How is trust established and maintained?
* How do semantics, identity, conformance, and routeability relate?
* What prevents derivative drift?
For this reader, Standardization is central, but it should not be entered without first understanding the institutional order that gives standards their authority. Organization therefore remains a necessary precursor, even if only at overview level. Acceleration then follows, because realization is where standards are tested against the world and where anti-fragmentation discipline is most likely to be strained.
This reader must also be protected from reading contextual adaptation as canonical change. The knowledge base should therefore surface the distinction between reference architecture, sector profiles, realization overlays, and local deployment patterns clearly and repeatedly.
## 9.7 The ecosystem participant
The ecosystem participant includes guild members, fellows, chapter contributors, university collaborators, civil-society partners, community actors, strategic contributors, and domain specialists entering Nexus through participation rather than through formal institutional or technical channels.
This reader often needs to know:
* Where do I fit?
* Through what structure do I participate?
* What is the difference between contribution and authority?
* What outputs can I help create?
* What safeguards and boundaries apply?
The correct entry path for this reader is not heavily constitutional or deeply technical at first. It should provide enough organizational framing to make the architecture intelligible, then move into Cooperation, then Operations, and only after that into broader standards and realization materials as relevant.
This path matters because participatory ecosystems often fail when contributors are welcomed before they are oriented. In such environments, enthusiasm substitutes for structure and visibility substitutes for role clarity. Nexus must instead make participation governable by making it legible from the outset.
The ecosystem participant should leave early reading with a clear sense that contribution is valued, but bounded; that guilds are meaningful, but not substitutes for institutional authority; and that participation is strongest when it is aligned to one common architecture rather than many informal interpretations.
## 9.8 The partner reader
The partner reader includes accelerators, incubators, OEMs, systems integrators, telecom and infrastructure actors, research partners, service providers, strategic institutions, and organizations that may collaborate with Nexus without becoming its constitutional center. This reader is usually pragmatic. They want to understand fit, role, boundaries, interfaces, and where value and responsibility sit.
This reader asks:
* Where can we participate?
* What are the public-good boundaries?
* What is open, and what is bounded?
* What is canonical, and what is implementation-specific?
* How do partnership and realization relate without collapsing into control?
The partner reader should first understand the organizational and cooperative logic of the system, then the standards and acceleration layers that define interfaces, conformance expectations, realization environments, and the distinction between core architecture and adjacent delivery surfaces.
This is especially important because partner readers can otherwise misinterpret Nexus as either too closed to engage or too open to structure. The knowledge system must show a middle path: rigorous public-good distinctness, combined with clearly bounded and useful routes for participation, collaboration, and realization support.
## 9.9 The research and academic reader
The research and academic reader seeks conceptual coherence, methodological seriousness, comparative architecture, theoretical originality, and the relation between philosophy, governance, infrastructure, standards, and institutional design. This reader is often especially attentive to internal consistency and to whether a system claims more than it can justify.
This reader asks:
* What is the conceptual thesis of Nexus?
* What distinguishes it from a platform, a network, or a governance program?
* How do its domains fit together?
* What is its model of truth, trust, and realization?
* What is original in its architecture?
For this reader, the strongest path begins with the Introduction, then Organization, then Standardization, then Operations, then Cooperation, and finally Acceleration. This sequence allows the architecture to appear first as a paradigm, then as a standards-bearing order, then as a working system, then as a participation architecture, and only then as a realization environment.
Researchers often require density, nuance, and traceability rather than simplification. The knowledge system should therefore reward serious reading by making the architecture explicit, internally structured, and resistant to rhetorical inflation.
## 9.10 The realization reader
The realization reader includes deployment actors, compute-infrastructure stakeholders, observatory operators, national and regional implementers, consortium builders, infrastructure hosts, and those who need to understand how Nexus becomes materially present in the world.
This reader often asks:
* What is the deployment architecture?
* How are compute infrastructure and observatory nodes (NXS-OPS) designed to function, and what is their evidence state?
* What is the role of national and regional consortiums?
* How do guilds, programs, studio, and accelerators fit into implementation?
* What are the boundaries between realization, routeability, and execution?
This reader is often drawn immediately toward Acceleration. Yet the knowledge system must prevent a realization-first reading from becoming a realization-only reading. For that reason, even realization readers should begin with enough Introduction, Organization, and Standardization to understand the architecture that realization is meant to instantiate.
Once that is achieved, Acceleration can then be read in full depth, supported by Operations and Cooperation as necessary. This protects the realization reader from misreading the system as a deployment program detached from its institutional and canonical foundations.
## 9.11 The funding and capital reader
There is also a reader whose interest is not strictly institutional, technical, or participatory, but financial in the broad sense: foundations, catalytic backers, strategic investors, development-finance actors, philanthropic institutions, and capital-adjacent partners who need to understand readiness, legitimacy, bounded interfaces, and non-execution discipline.
This reader is especially sensitive to:
* governance credibility;
* architectural seriousness;
* routeability versus execution;
* public-good distinctness;
* and the existence of clean, bounded realization surfaces.
For such readers, the path should move through Introduction, Organization, Acceleration, Standardization, and then Cooperation and Operations as needed. They must understand both the legitimacy and the realization architecture of the system before any capital-adjacent logic is introduced. The knowledge base must be particularly exact here, because overstatement in this area can quickly produce misaligned expectations about what Nexus is prepared to do and what remains the responsibility of downstream actors.
The boundary for this reader is exact. [The Global Risks Alliance](/organization/institutions/gra.md) (GRA) is the consortium steward for the finance, insurance and development-readiness interface; the register confers on it no regulated financial activity, and GRA does not lend, underwrite, rate, invest, advise on or arrange transactions \[1]\[3]. "Finance-readiness is not finance. Insurance-readiness is not underwriting." \[2] Readiness outputs support a competent institution's own independent review; they are not approvals, ratings or offers of finance. Capital decisions stay with the competent financial institutions and authorities. Section 9.16 adds the reference points that finance readers will apply.
## 9.12 Use cases of reading
Different readers do not merely have different identities; they have different use cases.
Some readers come to orient themselves before deciding whether to engage.\
Some come to evaluate institutional legitimacy.\
Some come to understand whether the architecture is technically serious.\
Some come to contribute to a guild or a program.\
Some come to assess deployment pathways.\
Some come to understand whether the system is suitable for national or regional adoption.\
Some come to compare Nexus with other models.\
Some come to evaluate whether a particular realization surface is trustworthy.
The knowledge system should therefore support not only audience types but use-case types. A reader may be an institutional actor one day and a realization reader the next, depending on the task at hand. The reading path should accommodate such shifts by remaining structured, transparent, and domain-aware rather than assuming one stable reader identity.
## 9.13 Entry paths and structural honesty
A strong knowledge architecture is not one that forces every reader into the same route. It is one that offers multiple entry paths without surrendering structural honesty.
This means a technical reader may begin with Standardization, but the knowledge base should still signal the necessity of Organization and Acceleration. A partner may begin with Cooperation, but the system should still show that Organization and Standardization govern its meaning. A realization actor may begin with Acceleration, but the knowledge base should still make clear that realization does not define the whole.
This is the essence of structural honesty: allowing flexible entry while preserving interpretive hierarchy. The system must remain hospitable without becoming loose.
## 9.14 Final statement on readers, use cases, and entry paths
The Nexus knowledge system is written for many readers, but it must not become many systems in response. Its task is not to produce separate architectures for separate audiences. Its task is to provide one coherent architecture that different readers can enter through different, disciplined paths.
That is why reader types, use cases, and entry paths matter. They allow the system to be accessible without dilution, precise without exclusion, and broad without losing coherence.
A well-governed reading path is therefore one of the hidden strengths of the architecture. It makes the corpus more usable, but also more truthful. It allows each reader to encounter the system at the right point without being misled about what the system is, where authority sits, or how the whole holds together.
## 9.15 The audiences of this site
Sections 9.2 to 9.11 describe reader types by role. The documentation standard names the audiences the site is written for; the table below gives each one's needs, first checks and starting point \[1]. The ordered routes are in [IV. Reading paths](/organization/introduction/knowledge/iv.-reading-paths.md).
| Audience | What it needs from the site | Boundaries to check first | Start with |
| ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| UN agencies and other intergovernmental bodies | Mandate neutrality; alignment with the 2030 Agenda and the Sendai Framework stated as design intent; decision rights left with competent authorities | No endorsement, affiliation or partnership is implied by citing a UN framework; UN agencies are audiences and sources, not partners unless a record says so \[1] | [I. System overview](/organization/introduction/knowledge/i.-system-overview.md), then [Cooperation](/organization/introduction/cooperation.md) |
| Governments and public authorities | Sovereignty and decision rights preserved; no procurement preference; national control of data by design, subject to evidence | Country coverage is not a mandate; "A decision-support package is not an official decision" \[2]; a research profile of a country is not a constituted national programme \[1] | [Organization](/organization/introduction/organization.md), then [Acceleration](/organization/introduction/acceleration.md) |
| Central banks and supervisors | Method transparency; exact separation of readiness from finance; no financial-stability, rating or approval claims | "Finance-readiness is not finance"; "Insurance-readiness is not underwriting" \[2] | [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md), then [Standardization](/organization/introduction/standardization.md) |
| Financial-services firms, insurers and development-finance institutions | What evidence means for credit, insurance and markets; diligence questions; who decides | GRA, the finance, insurance and development-readiness interface, carries out no regulated financial activity; see 9.11 \[3] | [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md), then [Cooperation](/organization/introduction/cooperation.md) |
| Multinationals and operators | Dependency and supply-chain methods; the licensing channel; rights in data and outputs; what the platform does today versus target | Commercial licences need a separate executed agreement; platform capability is target architecture under a release hold \[3]\[4] | [V. Scope and boundaries](/organization/introduction/knowledge/v.-scope-and-boundaries.md), then [Acceleration](/organization/introduction/acceleration.md) |
| GCRI, GRF, GRA and Nexus Standards communities | Participation routes, governance, standards status, how to correct the record | "Participation is not consent" \[2]; Nexus Standards are PROPOSED, not adopted \[1] | [Cooperation](/organization/introduction/cooperation.md), then [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md) |
| Technical and standards readers | Canonical names, identifiers, status vocabulary, architecture boundaries | "Verification is not certification" \[2]; identifier resolution is not authorization \[4] | [I. System overview](/organization/introduction/knowledge/i.-system-overview.md), then [Standardization](/organization/introduction/standardization.md) |
| Researchers | Concepts, methods, sources, honest uncertainty | Sources are cited at their latest edition; disagreements are shown, not hidden \[1] | [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md), then [Standardization](/organization/introduction/standardization.md) |
| First-time readers | Orientation without overload | A target is not a running service | [Knowledge](/organization/introduction/knowledge.md), then the five introductions |
*Table 1. Audiences, needs and first checks. Audiences follow the documentation standard; boundaries follow D-V3-0004 and the register notices \[1]\[2]\[3].*
## 9.16 Notes for specific audiences
Four audiences need more than a table row, because the boundaries that matter to them are easy to misread.
### Finance, insurance and capital readers
Readers from banks, insurers and supervisors will judge any evidence offered through the programme against their own data standards. For risk data in banking, the reference point is the Basel Committee's *Principles for effective risk data aggregation and risk reporting* (BCBS 239) \[5]; for statistical data quality more broadly, the IMF Data Quality Assessment Framework \[6]. Nexus pages cite these as context; no conformance with them is claimed. The GRA boundary in section 9.11 applies in full.
### Governments and public authorities
National counterparts own the agenda, data and decisions. Named national hosts and anchor institutions run national programmes under written agreements with a recorded local mandate; they do not represent a country or exercise public powers unless those are lawfully conferred \[3]. "Sovereign" appears on this site only for a public authority's own powers or as design intent: The systems are "intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment" \[3].
### UN and intergovernmental readers
The site cites UN frameworks as context and alignment. It does not speak for any UN body, and no page should be read as a claim of UN adoption, endorsement or approval \[1]. Data stewardship principles that UN readers will recognize, such as those in the UN Secretary-General's Data Strategy, are cited as reference points only \[7].
### Participants and contributors
Participation routes, fees and member counts are stated only where a record exists. An enquiry is not membership and an application is not acceptance \[1]. The current council vocabulary uses three routes, abbreviated NNC, NLC and NWG; some older pages use council labels that predate it, and their mapping awaits an owner decision. Check the [Cooperation introduction](/organization/introduction/cooperation.md) for the current routes.
## 9.17 Flexible entry, one meaning
A reader may enter anywhere (9.13). Wherever they enter, the page they land on should show its authority level, its status and the boundaries that apply, and should link back to the institutional order and the reading rules. This is what lets the site be entered flexibly without being read loosely \[1]. For any statement that matters, follow the page's citation to the record (9.12).
## Next steps
* Read [X. Knowledge Base Integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md) for the trust model behind the corpus.
* Read [XI. Final Orientation](/organization/introduction/knowledge/xi.-final-orientation.md) for the final guided handoff into the five domains.
* Begin the main sequence with [Organization](/organization/introduction/organization.md).
## Related pages
* Up: [Knowledge](/organization/introduction/knowledge.md)
* Across: [IV. Reading paths](/organization/introduction/knowledge/iv.-reading-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: [Cooperation introduction](/organization/introduction/cooperation.md) · [Organization introduction](/organization/introduction/organization.md)
## Sources
1. Nexus Documentation Standard, draft of 16 October 2026 (audiences, terms, external frameworks and forbidden claims, including the draft site copy rules cited there). 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* (roles and what is not conferred; positioning; commercial channel notice). Internal record; owner-confirmed, counsel review pending.
4. Nexus constitutional directive D-V3-0001, *Master directive V3* (UNI Identifier Fabric boundary), and the release-hold record. Internal record, cited by identifier.
5. Basel Committee on Banking Supervision (2013-01). *Principles for effective risk data aggregation and risk reporting* (BCBS 239). Bank for International Settlements. [bis.org](https://www.bis.org/publ/bcbs239.htm). Accessed 2026-10-16.
6. International Monetary Fund. *Data Quality Assessment Framework* (DQAF). [dsbb.imf.org](https://dsbb.imf.org/dqrs/dqaf). Accessed 2026-10-16.
7. United Nations (2020). *Data Strategy of the Secretary-General for Action by Everyone, Everywhere*. [un.org](https://www.un.org/en/content/datastrategy/). Accessed 2026-10-16.
8. 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/).
9. 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/).
10. 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/).
11. 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.
12. GCRI. *Programme status* (programme states and service levels; current level R0). [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). 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, status note and In brief; removed the empty "Part IX" heading and fixed heading levels; renamed "Operation" to "Operations"; replaced "sovereign institutions", "sovereign actors" and "sovereign compute" wording; added the GRA boundary sentence to the funding and capital reader (9.11); kept every reader type and added the standard audience table (UN bodies, states, central banks and supervisors, financial-services firms, multinationals), notes for finance, government, UN and participant readers with external reference points, 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/ix.-reader-entry-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.