> 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/0.-knowledge-system.md).
# 0. Knowledge System
What the Nexus knowledge base is, its standing below binding records, the five subject areas, the reading sequence and the principles that keep it accurate.
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-0002, D-V3-0003, D-V3-0004 and D-V3-0005; 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 · 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 \[13] \[14] \[15]; 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 \[16]. The case for one model rests on the evidence that risks compound and cascade across sectors and borders \[17] and on the international frameworks that ask for whole-of-society risk governance \[18] \[19].
{% 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 Nexus knowledge base is this documentation site: a curated, public explanation of the Nexus programme, its institutions, its operating model and the Nexus systems. It is a projection of binding records, never their source. It orients readers, explains each concept once, cites the records it relies on, states status honestly per dimension and records its own corrections. It does not constitute any institution, adopt any instrument or certify any capability \[1]\[2].
*The integrated knowledge system of Nexus.*
## Summary
This page describes the **Nexus knowledge system**: the editorial structure through which this documentation is organized, interpreted and maintained. It explains how **Organization**, **Operations**, **Cooperation**, **Standardization**, and **Acceleration** fit together as one coherent architecture.
It is the best starting point for readers who need the full logic of the documentation before moving into [I. System Overview](/organization/introduction/knowledge/i.-system-overview.md), [II. Knowledge Architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md), and [III. Reading Rules](/organization/introduction/knowledge/iii.-reading-rules.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 %}
## 0.1 Purpose and standing
This document establishes the intellectual, structural, and interpretive architecture of the Nexus knowledge system. It is the recommended point of entry for the wider body of materials on this site and is best read first, as the page through which the reader understands how the whole documentation is organized, how its parts relate to one another, and how meaning is preserved across a large and growing institutional, technical and operational corpus. It is an explanatory page (authority level L5): it governs no record, and binding facts remain in law, executed instruments, the Nexus constitutional directives and the registers that pages cite (see 0.14 and 0.15) \[1]\[2].
Its purpose is not merely introductory. It performs a deeper function. It gives order to a system that would otherwise risk being misread as a collection of separate initiatives, technical papers, program descriptions, governance notes, standards texts, and implementation pathways. Nexus is none of those things in isolation. It is designed as a coherent, multi-layered architecture in which institutional, operating, participation, standards and realization questions are kept distinct but connected. This front matter exists to ensure that the reader encounters that coherence from the beginning.
The knowledge system of Nexus is designed to serve a demanding task: to make complex questions of risk, resilience, infrastructure that respects national sovereignty, institutional trust, standards-bearing interoperability, and lawful real-world realization intelligible across national, regional, and global contexts. It must therefore do more than store information. It must preserve hierarchy, clarify role, prevent contradiction, reduce duplication, and maintain fidelity between foundational doctrine and downstream application. This page sets out how the documentation is designed to support those conditions.
For that reason, it should be read as an orientation document. It does not replace charters, bylaws, standards instruments, technical frameworks or deployment papers. It explains the way they are situated, encountered and interpreted within one editorial order; it does not govern them, and where a page and a binding record disagree, the record prevails \[1].
## 0.2 Character of the knowledge system
The Nexus knowledge system is not a library in the ordinary sense. It is not a filing system for documents produced by separate teams. It is not an archive of related but independent initiatives. It is an integrated knowledge architecture for a system whose parts must remain distinct in role yet unified in meaning.
That distinction is essential. In ordinary organizations, knowledge systems often emerge after structure, after operations, and after implementation. In Nexus, the knowledge system is itself a strategic instrument. Because the system depends on role separation, public-good integrity, standards discipline, routeability without execution collapse, and realization compatible with national sovereignty across many geographies and actors, its knowledge architecture must be designed with the same seriousness as its governance and infrastructure architecture.
The knowledge system therefore performs five simultaneous functions.
First, it gives the reader a stable account of what Nexus is and what it is not.
Second, it preserves the relationship between institutions, operating methods, participation structures, standards architectures, and realization pathways.
Third, it ensures that the same concept is not silently redefined in different areas of the system.
Fourth, it allows specialization and growth without loss of coherence.
Fifth, it protects the common rail of meaning that permits the system to scale across jurisdictions, sectors, hosts, and partner environments without fragmenting into many incompatible narratives.
In this sense, the knowledge system is not supplementary to the architecture. It is one of the ways the architecture remains governable.
## 0.3 Intended use
This document is written for readers who require a serious and reliable understanding of the Nexus system before engaging any of its component parts.
It is written for public authorities and sovereign institutions that must understand where authority resides, how governance is structured, and how deployment aligns with national primacy and lawful local grounding.
It is written for multilateral, regional, and public-purpose actors that need to understand how the system connects institutional order, standards, observability, routeability, and implementation without collapsing those functions into one actor.
It is written for technical, standards, and infrastructure readers who need to know where canonical architecture is defined, where operational methods are described, and where realization and deployment materials properly belong.
It is written for contributors, partners, editors, researchers, fellows, builders, and ecosystem participants who must understand how the knowledge system is arranged in order to contribute to it responsibly and without creating duplication or interpretive drift.
It is also written for new readers in the broadest sense: those encountering Nexus for the first time and needing a disciplined, intelligible, and mature entry point into a system whose scale and ambition would otherwise be easy to misread.
## 0.4 What this document does
This document defines the structure of the Nexus knowledge system at the highest level. It establishes the five primary domains through which the system is organized and interpreted:
* **Organization**, which defines constitutional identity, institutional order, governance, and federation;
* **Operations**, which describes how work is organized: frameworks, workflows, mechanisms, reports and production logic;
* **Cooperation**, which defines governed participation, alliances, guilds, memberships, councils, and ecosystem interfaces;
* **Standardization**, which defines canonical doctrine, semantics, protocol architecture, trust logic, conformance, and routeability grammar; and
* **Acceleration**, which describes realization through compute infrastructure, observatory nodes, consortiums, guilds, programmes, studios, accelerators and deployment pathways, each with its evidence state stated separately.
This document also defines the relationship among those domains, the order in which they should be read, and the interpretive rules that protect the system from duplication, contradiction, architectural collapse, and hidden redefinition.
It therefore does not function only as an introduction. It functions as a map of scope and sequence, and it points to where authority actually sits: in the binding records described in 0.15, not in this page.
## 0.5 What this document does not do
This document does not attempt to restate the full content of the underlying corpus. It does not replace institutional charters, governance instruments, operational frameworks, guild structures, standards instruments, trust architectures, routeability papers, or realization and deployment materials.
It does not function as a substitute for constitutional governance.\
It does not function as a substitute for technical standards.\
It does not function as a substitute for implementation guidance.\
It does not function as a substitute for alliance or participation frameworks.
Its role is not to compress the whole system into one text. Its role is to make the whole system readable as one order.
## 0.6 Foundational thesis of the knowledge architecture
The foundational thesis of the Nexus knowledge system is that a serious public-good-rooted, sovereignty-respecting, standards-bearing, globally interoperable architecture cannot rely on informal narrative coherence. It requires a designed and governed knowledge order.
This is because Nexus is not a single-purpose program, a software platform, a think tank, a forum, or a delivery brand. It is a system in which constitutional identity, institutional separation, operating discipline, standards architecture, observability, routeability, and real-world realization must all remain coordinated without becoming confused. If these are not differentiated in the knowledge base, they will eventually become confused in practice.
A system of this complexity cannot be held together by terminology alone. It must be held together by structure.
For that reason, the knowledge system is designed around a disciplined progression. The reader first encounters institutional order, then live operating logic, then ecosystem participation, then canonical standards, and only then realization and deployment. This is not simply a pedagogical sequence. It is a constitutional one. It reflects the fact that authority must precede execution, operating discipline must precede collaboration at scale, common doctrine must precede localization, and realization must remain accountable to the architecture that gives it meaning.
## 0.7 The five-domain structure
The five subject areas are summarized below as orientation. Their canonical description, with the question each answers, what each does not do and the direction of dependence between them, is in [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md).
### 0.7.1 Organization
Organization is the constitutional and institutional domain of the system. It defines what Nexus is organizationally, how its core institutions are differentiated, how governance is arranged, how authority is distributed, and how the federated order of the system is structured across global, regional, national, and host levels.
It is the place where the reader understands the institutional thesis of Nexus, the distinction between the public-good core and bounded downstream interfaces, the governance bodies that hold the system together, and the federated logic through which the architecture localizes without ceasing to be one system.
Organization answers the question: **Who are we, how are we constituted, and how is authority arranged?**
### 0.7.2 Operations
Operations is the operating domain of the system. (Earlier versions of this page called it "Operation"; the site part is named Operations.) It describes how work is structured, how frameworks are applied, how mechanisms govern learning and contribution, how reports and outputs are produced, how platforms and forums function, and how the architecture is designed to behave as a working system rather than a conceptual one.
It is the place where the reader understands the practical grammar of Nexus: how work moves, how value is captured and reported, how contributions are structured, how outputs become traceable, and how continuity, correction, and discipline are maintained in the ordinary life of the system.
Operations answers the question: **How is the system designed to work in practice?**
### 0.7.3 Cooperation
Cooperation is the ecosystem and participation domain of the system. It defines how actors enter the architecture, how participation is structured, how guilds and councils are formed, how memberships and contribution pathways work, how funding and governance overlays attach to specialized domains, and how ecosystem participation remains bounded, accountable, and safeguards-aware.
It is the place where the reader understands the architecture of collaboration: not as an informal network, but as a governed, role-specific, domain-sensitive order of participation.
Cooperation answers the question: **Who participates, through what structures, and under what conditions?**
### 0.7.4 Standardization
Standardization is the canonical doctrine and architecture domain of the system. It defines the common rail of meaning, the protocol and trust order, the semantic spine, the standards operating system, the sovereignty framework, the routeability grammar, and the conformance rules through which the architecture remains one coherent system across many implementations.
It is the place where the reader understands what is canonical, what is interoperable, what is valid, what is bounded by conformance, and what must remain invariant as the system grows and localizes.
Standardization answers the question: **What is the authoritative doctrine and architecture of the system?**
### 0.7.5 Acceleration
Acceleration is the realization and deployment domain of the system. It describes how the architecture is intended to become materially and institutionally real through compute infrastructure, observatory nodes (NXS-OPS), consortiums, specialized guilds, programs, studios, accelerators, partner ecosystems, and deployment pathways across urgent and emerging domains of risk and innovation management.
It is the place where the reader understands how Nexus moves from architecture to reality: how it is hosted, built, scaled, institutionalized, and localized without ceasing to be one system.
Acceleration answers the question: **How does the system become real in the world?**
## 0.8 Interpretive sequence
The knowledge system should be read in sequence.
The reader begins with **Organization**, because institutional order and authority must be understood before any other layer can be interpreted correctly.
The reader then proceeds to **Operations**, because a constitutional design that cannot be understood in its live working form remains abstract and incomplete.
The reader then proceeds to **Cooperation**, because once authority and operating discipline are understood, the participation architecture can be interpreted without mistaking collaboration for governance or contribution for authority.
The reader then proceeds to **Standardization**, because canonical meaning, protocol discipline, trust architecture, and routeability grammar can only be understood correctly when the reader already understands the institutional and operational order into which they are placed.
The reader then proceeds to **Acceleration**, because realization must be read last: not because it is least important, but because it is the place where every earlier layer becomes operational, and therefore the place most vulnerable to being misunderstood if read in isolation.
This sequence is the interpretive spine of the entire knowledge system.
## 0.9 Cross-area discipline
The five domains are integrated, but they are not interchangeable. Each defines a different class of truth.
Organization defines institutional truth.\
Operations defines working truth.\
Cooperation defines participation truth.\
Standardization defines canonical and protocol truth.\
Acceleration defines realization truth.
These truths are related, but they are not substitutable.
A participation structure cannot redefine constitutional authority.\
A deployment pathway cannot redefine canonical doctrine.\
An operating mechanism cannot redefine institutional role.\
A standards instrument cannot replace the need for host reality and lifecycle discipline.\
A realization surface cannot absorb the meaning of the whole system.
The purpose of the knowledge architecture is to preserve this discipline in written form so that the system remains intelligible in practice.
## 0.10 Non-duplication principle
The knowledge system is governed by a strict non-duplication principle.
A concept may be referenced across areas.\
A concept may be summarized in more than one place for readability.\
A concept may have implications in multiple domains.
But a concept should not be fully defined in more than one primary area in a way that creates competing sources of authority.
Where a concept properly belongs, that area governs its full meaning. Other areas may refer to it only insofar as their own role requires.
This rule is essential for a system such as Nexus because duplication is never harmless. Over time, duplication creates interpretive drift. Interpretive drift creates institutional drift. Institutional drift eventually becomes architectural failure. The knowledge system is designed to interrupt that sequence before it begins.
## 0.11 Canonical interpretation rule
This order applies among pages of this site only. Above every page sit the binding sources in the order of authority (mandatory law and executed contracts, the Native Master legal and IP constitution, the V3 constitutional set, the registers and the other ranked sources described in 0.15), and they prevail over any page \[1]\[2]. Within the site, where ambiguity arises, the knowledge system should be interpreted according to the following order:
First, the role and scope of the relevant primary area as described in this front matter and in [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md).
Second, the internal reading rules of that area.
Third, the governing foundational documents contained within that area.
Fourth, cross-area materials that depend on but do not contradict the upstream area.
Fifth, derivative, explanatory, public-facing, or summary materials.
In practical terms, this means that realization materials do not interpret standards autonomously, participation materials do not determine governance autonomously, and public summaries do not acquire the right to redefine foundational doctrine by repetition.
## 0.12 The protective purpose of structure
The structure of the knowledge system is not only explanatory. It is protective.
It protects the public-good core from being quietly rewritten by deployment logic.\
It protects participation from being mistaken for authority.\
It protects standards from being diluted into optional guidance.\
It protects operations from becoming ad hoc.\
It protects realization from drifting into premature execution claims.\
It protects the entire system from being reduced to whichever surface is most visible at a given moment.
In this sense, the knowledge architecture is one of the safeguards of Nexus itself.
## 0.13 Final opening statement
The Nexus knowledge system should therefore be understood as the structured written expression of one integrated design for collective security, resilience, readiness, shared prosperity and sustainable continuity.
It is rooted in public-good distinctness, institutional seriousness, standards-bearing interoperability, respect for national sovereignty, disciplined routeability and realization that does not collapse into execution.
It is organized into five primary domains:
* **Organization**, which defines institutional order and authority;
* **Operations**, which describes how work is done;
* **Cooperation**, which defines governed participation and ecosystem structure;
* **Standardization**, which defines canonical doctrine and trust architecture; and
* **Acceleration**, which describes realization through compute infrastructure, observatory nodes, consortiums, guilds and deployment pathways.
This is the recommended opening frame for reading this site. The pages that follow are written to be read through it, aligned to it and developed in a manner that preserves its clarity, discipline and coherence, subject always to the binding records they cite.
## 0.14 Definition and standing
**Definition.** In this documentation, the *knowledge base* is the GitBook space published at docs.therisk.global/organization and kept in step with a Git repository. Its pages explain and link; they hold no records of their own \[1].
**Standing.** The knowledge base is a curated projection, never an authority root. Binding facts live in law, instruments executed by authorized signatories, the Nexus constitutional directives and the repository registers. A page explains those sources and cites them. Where a page and a binding source disagree, the source prevails and the page is corrected \[1]\[2]. GitBook pages are not cited by other pages as evidence for a normative claim; they cite the record \[1].
An earlier version of this page described itself as "the governing point of entry" and "the first instrument" of the system. That wording has been corrected (section 0.1): no adoption record exists for any page in this section, and an explanatory page cannot govern the records it describes. This page claims only what it does: it explains how the knowledge base is built and how to use it.
## 0.15 Where the knowledge base sits in the order of authority
The site follows a fixed order of authority, highest first \[1]\[2]:
1. mandatory law and executed contracts;
2. the Native Master legal, IP and open-source constitution (D-NEXUS-NATIVE-MASTER-1), with its legal specializations inside its legal scope;
3. the V3 constitutional set (D-V3-0001 to D-V3-0009);
4. retained operational, legal and delivery controls;
5. the correction suite;
6. Universal Runtime V7 and the Real Product directive;
7. the ecosystem truth spine, for current state;
8. subsystem directives, architecture decision records, programme waves and tasks.
A lower source never weakens a higher one, and an unresolved conflict is recorded as a blocking directive conflict rather than resolved silently \[2]. GitBook pages sit below all of these. Their own authority levels, from L0 (external authority) to L6 (historical), are set out in [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md). The "canonical interpretation rule" in section 0.11 operates only within that lowest tier, among pages.
## 0.16 What the knowledge base does
The knowledge base has six functions. Each is a commitment about how pages are written, not a claim about any system's operating state.
1. **Orient.** Give every reader a route from a one-paragraph summary to the governing detail, in a stated order ([IV. Reading paths](/organization/introduction/knowledge/iv.-reading-paths.md)).
2. **Define once.** Give each concept one canonical page and link to it elsewhere, so that the same word does not acquire different meanings on different pages ([VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md)).
3. **Cite.** Trace every factual, status or legal statement to an external primary source or to a repository record identified by its document id \[1].
4. **State status honestly.** Keep target, implementation, verification, observation and acceptance apart, and publish no single readiness score ([III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md)) \[3].
5. **Separate explanation from decision.** Describe evidence, methods and readiness without presenting any of them as a decision, approval or execution, which stay with competent authorities \[4].
6. **Correct visibly.** Record each substantive change as a dated version and keep superseded text traceable ([X. Knowledge base integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md)).
## 0.17 What the knowledge base is not
| The knowledge base is not | Why it matters | Where the real thing lives |
| --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| A constitutional instrument | Explanatory pages create no obligations, rights or reserved matters | Charters and bylaws in the Organization part, each with its own record and status |
| A register of legal facts | Names, roles, title and status bind through registers, not prose | Repository registers, cited by id \[1] |
| The [NXS-HUB](/organization/systems/nxs-hub.md) system | In the V3 architecture, institutional knowledge, records, citations and runbooks are the remit of NXS-HUB, the operating workspace and controlled portal layer for knowledge, tickets and runbooks, one of the twenty systems \[5] | The twenty systems (target architecture; see the status note at the top of this page) |
| An official publication of any UN body, government or regulator | Citing an external framework is alignment or reference, never affiliation or endorsement | The issuing body's own publication |
| Legal, financial or technical advice | Pages describe how things are designed to work | Competent advisers and authorities |
| A marketing channel | No superlatives, no readiness claims, no partnership claims without a record | Not applicable |
*Table 1. What the knowledge base is not. Source: the documentation standard, on the standing of the knowledge base and its claims discipline, as of 2026-10-16 \[1].*
## 0.18 Relationship to the institutions
The knowledge base explains the institutions of the programme; it does not speak for them. Their roles are stated in register wording on the institutional pages, and this page only points to them \[12]. In summary: GCRI Canada ([The Global Centre for Risk and Innovation](/organization/institutions/gcri.md)) 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. Technology development and infrastructure operation are governed by the applicable agreements. The full institutional order, with its limits, is explained in the [Organization introduction](/organization/introduction/organization.md). Decisions stay with competent actors.
## 0.19 Relationship to the twenty systems and shared fabrics
The twenty systems are described in the V3 constitution as one coherent, federated, independently reconstructible system of systems, organized into exactly twenty canonical systems, from [NXS-CMD](/organization/systems/nxs-cmd.md), the system command home, to [NXS-LAB](/organization/systems/nxs-lab.md), the experiments and research programme, plus shared fabrics that are not counted among them \[5]\[6]. Four of these are closest to the work of a knowledge base:
* **NXS-HUB**: institutional knowledge, records, citations, collaboration, runbooks and learning. The knowledge base explains concepts that NXS-HUB records are intended to hold; it does not replace them.
* [**NXS-NSF**](/organization/systems/nxs-nsf.md) **(trust, authorization and assurance)**, the trust, sovereignty and assurance plane for identity, policy gates and access decisions, whose remit includes public-safe release and correction governance.
* **UNI Identifier Fabric**: durable identifiers for records. "Identifier resolution is not authorization, certification or truth" \[6]. Pages in this section carry no identifier until a serial is allocated through the catalogue; serials are never typed or guessed \[1].
* **Evidence and Receipt Fabric**: append-only evidence, where a receipt proves the recorded event within scope, not broader correctness \[6].
The full list of systems and fabrics is in [I. System overview](/organization/introduction/knowledge/i.-system-overview.md).
## 0.20 International reference points
The design of the knowledge base draws on established international practice for knowledge, records and data stewardship. These are reference points, not claims of conformance or certification.
* **Records management.** ISO 15489-1:2016 sets out concepts and principles for records, including the characteristics of authoritative records: authenticity, reliability, integrity and usability \[7]. The knowledge base follows the same idea in a narrower form: the record lives in the register, and the page points to it.
* **Knowledge management.** ISO 30401:2018 specifies requirements for knowledge management systems in organizations \[8]. Its emphasis on defined roles and governance informs [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md).
* **Findable, reusable knowledge.** The FAIR Guiding Principles (findable, accessible, interoperable, reusable) for scientific data stewardship \[9] inform the use of stable addresses, explicit identifiers and machine-readable status.
* **Professional standards for public information.** The United Nations Fundamental Principles of Official Statistics, endorsed by the General Assembly in resolution 68/261 (2014), set principles of professional standards, accountability and transparency about sources and methods, and the prevention of misuse \[10]\[11]. Nexus is not an official statistics agency; the principles are cited as a benchmark for how evidence should be presented.
## 0.21 Design principles
The following statements describe how pages in this knowledge base are written. They are editorial principles for this site, derived from the documentation standard draft; each cites its source. Page-local identifiers (KS-n) are provisional.
| Id | Principle | Source |
| ---- | ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- |
| KS-1 | A page SHALL explain and cite binding records and SHALL NOT be cited by another page as evidence for a normative claim. | Documentation standard \[1] |
| KS-2 | Each concept SHALL have one canonical page; other pages SHOULD give at most a short summary and a link. | Documentation standard \[1] |
| KS-3 | Status SHALL be stated per dimension; no page SHALL publish a merged readiness label, score or percentage. | Documentation standard \[1]; D-V3-0005 \[3] |
| KS-4 | Present tense SHALL be used only for what operates now; targets are written as "is designed to". | Documentation standard \[1] |
| KS-5 | Every substantive change SHALL be recorded as a dated version; superseded text SHALL remain traceable. | Documentation standard \[1] |
| KS-6 | Relationships with external frameworks SHALL be described as alignment or reference, never conformance, endorsement or partnership. | Documentation standard \[1] |
*Table 2. Design principles of the knowledge base. In normative statements, SHALL, SHOULD and MAY report the rule of the cited source (see* [*III. Reading rules*](/organization/introduction/knowledge/iii.-reading-rules.md)*).*
## 0.22 Key terms
| Term | Meaning on this site |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ |
| Knowledge base | This documentation site; an explanatory projection of binding records |
| Binding record | Law, an executed instrument, a V3 constitutional directive or a register field that the site cites |
| Canonical page | The single page that owns a concept's full definition |
| Authority level | The L0 to L6 label in a page's document record ([VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md)) |
| Document status | DRAFT, PROPOSED, ADOPTED, SUPERSEDED or WITHDRAWN ([VII. Knowledge lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md)) |
## 0.23 Decisions pending
* **Consolidation.** A documentation audit proposed merging this page with [I. System overview](/organization/introduction/knowledge/i.-system-overview.md) and [XI. Final orientation](/organization/introduction/knowledge/xi.-final-orientation.md) into one page on how this knowledge base works. Structural merges require an owner decision; until then the three pages are kept.
* **Owner and corrections route.** The accountable owner of this section and the public corrections route have not yet been named.
## Next steps
* Continue to [I. System Overview](/organization/introduction/knowledge/i.-system-overview.md) for the high-level meaning of the Nexus knowledge system.
* Read [II. Knowledge Architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) for the five-area structure.
* Read [IV. Reading Paths](/organization/introduction/knowledge/iv.-reading-paths.md) to choose the best route through the docs.
## Related pages
* Up: [Knowledge](/organization/introduction/knowledge.md)
* Across: [I. System overview](/organization/introduction/knowledge/i.-system-overview.md) · [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) · [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md) · [XI. Final orientation](/organization/introduction/knowledge/xi.-final-orientation.md)
* Counterpart: [Organization introduction](/organization/introduction/organization.md), for the institutions whose records this site explains.
## Sources
1. Nexus Documentation Standard, draft of 16 October 2026: purpose and audiences, authority and status, naming and canonical pages. Internal editorial standard; not published.
2. Nexus constitutional directive D-V3-0002, *Directive precedence and source authority*. Internal record, cited by identifier.
3. Nexus constitutional directive D-V3-0005, *Product truth, claims and evidence*. Internal record, cited by identifier.
4. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks and non-execution*, boundary formulas. Internal record, cited by identifier.
5. Nexus constitutional directive D-V3-0003, *Twenty-system constitution*. Internal record, cited by identifier.
6. Nexus constitutional directive D-V3-0001, *Master directive V3*, shared constitutional fabrics. Internal record, cited by identifier.
7. International Organization for Standardization (2016). *ISO 15489-1:2016 Information and documentation: Records management, Part 1: Concepts and principles*. ISO, Geneva. (URL not verified.)
8. International Organization for Standardization (2018). *ISO 30401:2018 Knowledge management systems: Requirements*. ISO, Geneva. (URL not verified.)
9. Wilkinson, M. D. et al. (2016). *The FAIR Guiding Principles for scientific data management and stewardship*. Scientific Data 3, 160018. [doi.org](https://doi.org/10.1038/sdata.2016.18). Accessed 2026-10-16.
10. United Nations Statistics Division. *Fundamental Principles of Official Statistics*. [unstats.un.org](https://unstats.un.org/fpos/). Accessed 2026-10-16.
11. United Nations General Assembly (2014-01-29). *Resolution 68/261, Fundamental Principles of Official Statistics*. [docs.un.org](https://docs.un.org/en/A/RES/68/261). Accessed 2026-10-16.
12. Nexus institutional register, *Nexus institutional architecture and participation*, including the lead contracting organization and consortium stewardship notices. Internal record; owner-confirmed, counsel review pending.
13. 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/).
14. 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/).
15. 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/).
16. 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.
17. Pescaroli, G. and Alexander, D. (2018). Understanding compound, interconnected, interacting, and cascading risks: a holistic framework. *Risk Analysis* 38(11): 2245–2257. [doi:10.1111/risa.13128](https://doi.org/10.1111/risa.13128).
18. UN General Assembly (2015). *Sendai Framework for Disaster Risk Reduction 2015–2030*. A/RES/69/283. [undrr.org](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030).
19. OECD (2014). *Recommendation of the Council on the Governance of Critical Risks*. OECD/LEGAL/0405. [legalinstruments.oecd.org](https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0405).
## 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; fixed the heading hierarchy (the subtitle, formerly an H4, is now italic text and the sections, formerly H3, are now H2); corrected the "governing point of entry" and "first instrument" claims to an explanatory standing; renamed "Operation" to "Operations"; replaced "sovereign compute" and "sovereign compatibility" wording; placed the in-site interpretation rule below the order of authority; removed the unsupported "beyond Earth" scope phrase; added standing, order of authority, functions, boundaries, institutional and twenty-system relationships, international reference points, design principles, key terms, sources and this record. 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/0.-knowledge-system.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.