> 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/v.-scope-and-boundaries.md).
# V. Scope and Boundaries
What this documentation covers, what it excludes and what it never publishes, with the boundaries between explanation, implication, decision and execution.
Document record · Draft · Legal review required · Updated 21 October 2026
| | |
| ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Status** | Draft. Explanatory page; it creates no rights or obligations. |
| **Legal review** | Required before final publication. |
| **Version** | 2026.10.21-r3 |
| **Updated** | 21 October 2026 · reviewed every 180 days |
| **Owner** | Documentation desk (named reviewer pending) |
| **Based on** | Nexus Documentation Standard (draft); Nexus constitutional directives D-V3-0001, D-V3-0003 and D-V3-0004; Nexus native master directive D-NEXUS-NATIVE-MASTER-1; 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 · scope and boundaries.
{% 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 \[6] \[7] \[8]; the house rules are in the [citation style](/organization/reference/citation-style.md). Where this page names finance or delivery vehicles (a project SPV, a national company and similar), they are structures that competent, lawful actors may form outside the programme under their own law and licences. The programme prepares evidence, standards and readiness; it never forms, arranges, owns or advises on a vehicle or a transaction ([Finance readiness](/organization/finance-readiness.md); [lawful handoffs](/organization/finance-readiness/lawful-handoffs.md)) \[9]. This follows the OECD blended-finance principles' separation of public purpose from commercial execution \[10]. 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)) \[11].
{% 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 scope of this knowledge base is the Nexus programme itself: its institutions, operating methods, participation routes, shared standards and the Nexus systems, described at a public-safe level. It is not an encyclopedia of global risk, not a technical manual for every deployment and not a home for contracts, counsel material or confidential instruments. Its boundaries keep explanation apart from implication, knowledge apart from decision, and the public-good core apart from commercial and delivery surfaces \[1]\[2].
## Summary
This page defines the scope of the Nexus knowledge base and the boundaries that keep it coherent. It explains what the corpus is meant to cover, what it should not absorb, and how Nexus separates foundational, contextual, public-safe, and controlled material.
It is closely linked to [VI. Structural Logic](/organization/introduction/knowledge/vi.-structural-logic.md) and [X. Knowledge Base Integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.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 %}
## 5.1 Why scope and boundaries must be stated explicitly
A mature knowledge system cannot rely on implied limits. If its scope is not stated clearly, readers will expand it by assumption. If its boundaries are not stated clearly, contributors will erode them by convenience. In a system such as Nexus, where governance, standards, ecosystem participation, infrastructure for national deployment and realization are intentionally interdependent, this is especially dangerous. The very richness of the architecture makes it vulnerable to overreach in interpretation unless the boundaries of the knowledge base are articulated with precision.
For that reason, this part defines what the Nexus knowledge system is intended to contain, what it is not intended to contain, how it relates to adjacent domains of practice, and where the limits of explanation, reliance, and implied authority must remain visible. Scope and boundaries are not editorial housekeeping. They are part of the architecture’s discipline of truthfulness.
A knowledge base that attempts to speak for everything eventually becomes unreliable. A knowledge base that refuses to state its perimeter invites misuse, misunderstanding, and silent category expansion. Nexus must avoid both failures. It must be expansive enough to reflect the integrated nature of the system, but bounded enough to preserve interpretive clarity and institutional integrity.
## 5.2 What the knowledge base is intended to cover
The Nexus knowledge base is intended to cover the full conceptual, institutional, operational, cooperative, canonical, and realization architecture of the Nexus system. It is designed to explain how the system is constituted, how it functions, how participation is organized, how standards and trust are governed, and how the whole architecture is intended to become real through infrastructure, consortiums, observatory nodes (NXS-OPS), guilds and deployment pathways.
This means the knowledge base properly includes five classes of content.
First, it includes **constitutional and institutional content**: institutional purpose, governance, federation, authority structures, public-good distinctness, role separation, and the formal order of the system.
Second, it includes **operational content**: frameworks, mechanisms, workflows, reports, media processes, forums, platforms, and other structures through which Nexus functions as a live system.
Third, it includes **participation content**: guilds, councils, memberships, ecosystem interfaces, contribution pathways, and the structured social architecture of the system.
Fourth, it includes **canonical and standards-bearing content**: doctrine, semantics, protocol architecture, trust logic, routeability grammar, sovereignty frameworks, conformance rules, and standards operating systems.
Fifth, it includes **realization content**: compute infrastructure, observatory infrastructure, consortium architecture, programs, studios, accelerators, partner ecosystems, and deployment pathways.
The knowledge base is therefore broad in scope, but its breadth is principled. It is broad because the Nexus system itself is integrated. It is not broad because it seeks to become a universal repository of everything related to risk, resilience, governance, finance, infrastructure, and innovation.
## 5.3 What the knowledge base is not intended to cover
Just as important as scope is exclusion. The Nexus knowledge base is not intended to absorb every adjacent body of knowledge, every external standard, every sector framework, or every operational detail that a downstream implementer or partner might eventually need.
It is not a general encyclopedia of global risk.\
It is not a universal library of policy literature.\
It is not a comprehensive technical manual for every deployment context.\
It is not a substitute for the internal operating manuals of partner institutions or host organizations.\
It is not a substitute for licensed execution documentation, sovereign legal instruments, procurement systems, or downstream financial or transactional materials.
The knowledge base may reference such materials, map to them, interface with them, and situate Nexus in relation to them. But it should not attempt to reproduce them in full unless they are formally integrated into the Nexus architecture and placed under appropriate governance.
This distinction is crucial because Nexus operates adjacent to many specialized fields: public administration, sovereign finance, digital public infrastructure, standards engineering, AI governance, cyber resilience, insurance, critical infrastructure, climate adaptation, disaster risk management, observability, and beyond. The knowledge base must remain capable of interfacing with all of these while preserving its own identity as the structured expression of one specific system.
## 5.4 The boundary between Nexus and the wider field
Nexus belongs to a wider field of thought and practice, but it is not identical to that field. It engages with global governance reform, collective security, infrastructure for national deployment, risk intelligence, development finance, digital public goods, standards systems, and emerging technology governance. Yet it should not be read as the totality of any of these domains.
Rather, Nexus is a system that intersects them through a specific architecture: one common rail, differentiated institutions, public-good distinctness, standards-bearing interoperability, routeability without execution collapse, and realization through infrastructure "intended to support sovereign and national deployment profiles under national control, subject to evidence for each deployment" \[4], and consortium logic.
The knowledge base must therefore maintain a double discipline.
It must be open enough to show how Nexus relates to broader international agendas, scientific frameworks, multilateral concerns, public-purpose infrastructure challenges, and sector-specific needs.
At the same time, it must be disciplined enough to show that Nexus remains a distinct architecture with its own internal order, not merely a rhetorical umbrella placed over existing agendas.
This is the boundary between Nexus and the wider field: Nexus is not the whole field, but it is a system designed to make meaningful parts of that field intelligible and operable together.
## 5.5 The boundary between foundational and derivative content
Not all content in a knowledge system carries the same weight. Some content is foundational, defining the architecture itself. Other content is derivative, explanatory, illustrative, sector-specific, partner-specific, or time-bound. The knowledge base must therefore preserve a clear distinction between foundational and derivative content.
**Foundational content** includes:
* constitutional and institutional doctrine;
* governance structures and reading rules;
* core frameworks and mechanisms where they define system behavior;
* canonical standards and protocol architecture;
* compute-infrastructure and realization doctrine where they define system form rather than merely one implementation;
* federation structures, guild design rules, and consortium architecture where they form part of the permanent architecture.
**Derivative content** includes:
* summaries and overviews written for particular audiences;
* examples, case studies, and illustrations;
* program announcements and cyclical opportunities;
* temporary initiative pages;
* partner-facing adaptations;
* public-safe briefs that simplify deeper materials;
* local or sector overlays that depend on but do not redefine foundational doctrine.
This distinction matters because readers often assign undue authority to polished or visible content. The knowledge system must help them distinguish what is explanatory from what is constitutive. Foundational material anchors meaning; derivative material extends accessibility and application.
## 5.6 The boundary between canonical and contextual content
A further boundary must be maintained between what is **canonical** and what is **contextual**.
Canonical content is content whose meaning must remain invariant across deployments, localizations, partner relationships, and explanatory contexts. This includes the common rail, the two-stack doctrine, institutional role separation, public-good distinctness, core protocol and trust logic, routeability grammar, and other elements that define the identity of the system.
Contextual content is content that may vary by geography, host, sector, corridor, policy environment, language, or operational need, so long as that variation does not violate canonical doctrine. Examples include regional consortium design, national implementation pathways, domain-specific guild emphasis, host-specific observatory deployment patterns, local capacity-building programs, and sectoral studio outputs.
The knowledge system must protect canonical content against drift while allowing contextual content to evolve where necessary. This is one of the deepest boundary disciplines in Nexus. Without it, localization becomes fragmentation. With it, the architecture can adapt without losing itself.
## 5.7 The boundary between public-safe and controlled content
Because Nexus operates in areas that may touch sensitive domains (public infrastructure, routeability, governance, finance-readiness, critical systems, market-sensitive contexts or high-consequence deployment environments), the knowledge base must also maintain a clear distinction between what is appropriate for broad public circulation and what should remain controlled, bounded, or context-specific.
Not all knowledge is equally suited to open dissemination in full detail. Some materials can be safely shared as public-facing knowledge because they concern architecture, public-purpose principles, institutional logic, high-level standards, educational content, or broadly understandable realization models.
Other materials may require controlled handling because they involve sensitive assumptions, host-level vulnerabilities, routeability implications, market-sensitive logic, dual-use concerns, escalation procedures, or detailed operating patterns that should not circulate without context or safeguards.
This does not mean the knowledge base should become opaque. It means it should become disciplined. Public-safe content should be written clearly, confidently, and responsibly. Controlled content should be governed by explicit handling rules and should not be accidentally blended into broadly accessible summaries in ways that distort either clarity or safety.
The boundary is therefore not between transparency and secrecy. It is between appropriate public intelligibility and inappropriate exposure. Some material never appears on this site at all: confidential instruments, signatory details and counsel material are not published, and the Native Master (D-NEXUS-NATIVE-MASTER-1), a controlled governance instrument, is cited by identifier only and not quoted \[1]. Section 5.17 sets out the V3 rules behind this boundary.
## 5.8 The boundary between description and implication
A persistent danger in any ambitious knowledge system is that descriptive language begins to imply more than it says. This is particularly acute in a system like Nexus, where the architecture touches readiness, routeability, deployment, observability, and structured interfaces to public authorities, finance, and infrastructure.
The knowledge base must therefore maintain a strong distinction between **description** and **implication**.
To describe a routeability object is not to imply execution.\
To describe a compute architecture intended for national deployment is not to imply adoption by any state.\
To describe a guild interface is not to imply policy authority.\
To describe a consortium pattern is not to imply formal national endorsement.\
To describe a standards-bearing architecture is not to imply that every local implementation is equally mature or equally conformance-ready.
This rule is essential for preserving truth under scale. Readers must be able to trust that the knowledge base describes states, structures, and possibilities accurately without inflating their status by tone, positioning, or rhetorical compression.
## 5.9 The boundary between knowledge and decision
The Nexus knowledge system is built to support institutional decision, public-purpose reasoning, technical design, standards-bearing interoperability, and real-world implementation. It is not, however, identical to the decisions themselves.
The knowledge base may shape decision.\
It may inform decision.\
It may structure the inputs to decision.\
It may define the canonical and operational conditions under which certain decisions become meaningful.
But a knowledge base remains a knowledge system. It is not the same as a sovereign act, a licensed financial act, a regulatory determination, a binding operational authorization, or a downstream execution event. Those may be influenced by Nexus, structured through Nexus, or routed through Nexus-compatible logic, but they remain distinct in kind.
This boundary matters because one of the strengths of Nexus is precisely that it improves legibility, trust, routeability, and institutional readiness without pretending to erase the lawful role of downstream decision-makers. The knowledge system must preserve that distinction in every area.
## 5.10 The boundary between core system and adjacent delivery surfaces
Nexus must also maintain a boundary between the **core system** and the many delivery, partner, service, or ecosystem surfaces that may gather around it. This is especially important as realization deepens.
A public-good-rooted system with strong standards, routeability, observability and compute architecture will naturally attract integrators, accelerators, hosts, OEMs, service providers, university partners, ecosystem collaborators, and domain-specialized actors. Their participation may be valuable and often necessary. But their presence must not change the identity of the core.
The knowledge base must therefore ensure that:
* the common rail remains distinct from partner offerings;
* public-good infrastructure remains distinct from commercial services;
* standards and conformance remain distinct from implementation branding;
* consortium architecture remains distinct from vendor or service concentration; and
* ecosystem breadth does not become a pretext for constitutional ambiguity.
This is not only a governance question. It is a knowledge architecture question. The way the system is described determines whether its core distinctness remains legible under growth.
## 5.11 The boundary between permanent and time-bound material
A further distinction must be maintained between what is structurally enduring and what is time-bound.
The knowledge base includes materials that should remain stable over long periods: constitutional doctrine, standards-bearing architecture, guild design rules, compute-infrastructure doctrine, federation logic, routeability grammar, and interpretive rules.
It also includes materials that are expected to change more often: cohort calls, accelerator cycles, campaign calendars, event pages, field updates, local initiatives, temporary partnerships, and evolving deployment roadmaps.
The presence of both kinds of content is not a weakness. It is a sign that the system is both principled and alive. But they must be distinguished clearly. Stable content should anchor interpretation. Time-bound content should be visibly contextualized, versioned, and situated within the larger architecture rather than allowed to drift into implied permanence.
## 5.12 The scope of future growth
The knowledge base is designed to grow, but not without discipline. Growth should occur by deepening the five domains, refining their internal structures, expanding contextual and domain-specific materials, and strengthening cross-area integrity. Growth should not occur by multiplying top-level categories, blurring foundational distinctions, or allowing new materials to bypass the existing architecture because they appear urgent or strategically attractive.
This means future growth should generally follow one of four valid patterns:
* deepening a primary domain through more precise subparts;
* extending a domain through contextual overlays that remain subordinate to canonical rules;
* adding derivative explanatory materials for new audiences;
* or documenting new realization pathways that remain bounded by the existing constitutional and standards order.
Growth outside these patterns should be treated cautiously. A system remains coherent not because it stops growing, but because it grows in ways that remain legible to itself.
## 5.13 Editorial consequence of scope and boundaries
The purpose of scope and boundaries is not to make the knowledge base restrictive or overly formal. It is to make it durable.
A durable knowledge system does not attempt to say everything.\
It says what belongs to it, and says it clearly.\
It interfaces with what lies beyond it without pretending to absorb it.\
It allows specialization without losing identity.\
It allows realization without surrendering its public-good distinctness.\
It allows growth without sacrificing intelligibility.
This is the editorial consequence of scope and boundaries. They do not reduce ambition. They allow ambition to remain trustworthy.
## 5.14 Final statement on scope and boundaries
The Nexus knowledge base is therefore broad, but not unbounded; integrative, but not indiscriminate; open, but not structurally porous; and ambitious, but not careless in what it claims.
Its scope is the Nexus system itself in its constitutional, operational, participatory, canonical, and realization dimensions.
Its boundaries preserve the distinction between foundational and derivative material, canonical and contextual material, public-safe and controlled material, description and implication, knowledge and decision, core system and adjacent delivery surfaces, and permanent and time-bound content.
These boundaries are not constraints on the architecture’s significance. They are among the reasons that significance can be preserved.
## 5.15 Scope at a glance
| In scope | Out of scope | Never published here |
| ------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
| Institutional order, roles and limits, explained from the registers | The internal manuals of partner institutions and national hosts | Confidential instruments, signatory details and counsel material \[1] |
| Operating methods, publication programmes and review processes | Licensed execution documentation, procurement files and transaction documents | Quotations of the Native Master (D-NEXUS-NATIVE-MASTER-1), which is a controlled governance instrument cited by identifier only \[1] |
| Participation routes and their safeguards | A general encyclopedia of risk, policy or finance | Credentials, security-sensitive configuration or host-level vulnerability detail |
| Shared terms, identifiers, status vocabulary and proposed standards | Full reproduction of external standards or reports (they are cited, not re-hosted) \[1] | Personal data of participants or of affected people |
| System target architecture and its evidence state | Operating instructions for any specific deployment | Emergency contacts, incident-response promises or response times \[1] |
| References to international frameworks, as context and alignment | Statements on behalf of any UN body, government, regulator or company | Claims of endorsement, partnership, certification or readiness without a record \[1] |
*Table 1. The perimeter of the knowledge base, summarizing sections 5.2, 5.3 and 5.7. Source: the documentation standard, as of 2026-10-16.*
## 5.16 Citation rules at the boundary with the wider field
Section 5.4 explains how Nexus relates to the wider field. Three rules make that boundary visible on every page:
* **Context, not endorsement.** References to the Sendai Framework, the 2030 Agenda, the IPCC, supervisory standard setters or other bodies are alignment or context only; they imply no endorsement, affiliation or partnership \[1].
* **Cite, do not re-host.** External publications are cited at their publisher's canonical address. Third-party documents are not reproduced unless a redistribution licence is recorded \[1].
* **Digital public goods.** The term "digital public good" has a specific meaning set by the Digital Public Goods Alliance through its standard and registry \[3]. This site cites that standard as a reference point only; it does not describe the Nexus systems or any Nexus output as a digital public good, and the technology behind the systems is proprietary infrastructure \[4].
## 5.17 Public-safe and controlled content under V3
Two V3 rules give section 5.7 its binding form:
* "Public-safe products are separate governed derivatives, never screenshots with informal redaction" \[2]. A public page is written for publication, not cut down from a controlled document.
* Public-safe release and correction governance fall within the remit of [NXS-NSF](/organization/systems/nxs-nsf.md), the trust, sovereignty and assurance plane for identity, policy gates and access decisions \[2].
Controlled material (detailed operating patterns, host-level vulnerabilities, market-sensitive reasoning, dual-use detail, confidential instruments) stays outside the site. A related doctrine page, [76. Protected Knowledge](/organization/organization/governance/doctrine/xiii.-architecture/76.-protected-knowledge.md), discusses protected knowledge in the governance doctrine; it is a draft institutional text, not an adopted rule.
## 5.18 The boundary formulas
Section 5.8 applies the same discipline that the V3 boundary formulas state verbatim: "Finance-readiness is not finance. Insurance-readiness is not underwriting. Verification is not certification. Participation is not consent. Public-authority learning is not approval. Technology readiness is not procurement approval. A warning-support candidate is not an official warning. A decision-support package is not an official decision." \[5]
Applied to this site:
* Describing a compute or deployment architecture does not imply that any government has adopted it.
* Describing a consortium pattern does not imply national endorsement.
* Describing a warning-support capability does not make any map or output an official warning; map events are indicative, not official warnings \[1].
* Describing a standard does not imply that any implementation conforms to it.
## 5.19 Who decides
Section 5.9 separates knowledge from decision. In institutional terms: institutions in the programme are never described as regulating, commanding, lending, investing, insuring, underwriting, rating, procuring, certifying or approving on behalf of others \[1]. Competent public authorities hold all sovereign, regulatory, fiduciary and operational decisions \[4]. Decisions stay with competent actors.
## 5.20 Core and commercial surfaces
Section 5.10 keeps the core distinct from delivery surfaces. The registers state that boundary precisely:
* The technology behind the systems is proprietary infrastructure made available to the Nexus Consortium by an external provider at arm's length as shared infrastructure for public-good and consortium purposes \[4].
* Commercial technology licences outside the not-for-profit service based on the Nexus systems require a separate agreement with a lawful rights holder or its authorized commercial seller; GCRI Canada remains the contracting party for services based on the Nexus systems and for consortium participation \[4].
* A catalogue listing, a partner page or a programme mention is not recognition, certification or partnership.
## 5.21 Foundational and derivative content in authority levels
The foundational and derivative classes of section 5.5 correspond to the authority levels used in every document record. Foundational content is usually a projection of binding canon (L2) or a draft or adopted institutional instrument (L4 or L3); derivative content is explanatory (L5). Polished, visible pages are often derivative, so a reader should check the document record before relying on a page. Authority levels are defined in [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md); growth patterns (5.12) that create, merge, split or move pages need an owner decision, and existing addresses are kept so that links do not break \[1].
## 5.22 Key terms
| Term | Meaning on this site |
| ------------------ | ------------------------------------------------------------------------------------------------ |
| Public-safe | Written for public circulation as a governed derivative, not redacted from a controlled document |
| Controlled content | Material that stays outside the site because of sensitivity, confidentiality or dual-use risk |
| Canonical content | Content that must mean the same everywhere, such as roles, boundary formulas and system names |
| Contextual content | Content that may vary by country, sector or language without contradicting canonical content |
## Next steps
* Read [VI. Structural Logic](/organization/introduction/knowledge/vi.-structural-logic.md) for the editorial discipline that enforces these boundaries.
* Read [VII. Knowledge Lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md) for content classes and maturity.
* Read [X. Knowledge Base Integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md) for trust, integrity, and public meaning.
## Related pages
* Up: [Knowledge](/organization/introduction/knowledge.md)
* Across: [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md) · [VII. Knowledge lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md) · [X. Knowledge base integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md)
* Counterparts: [76. Protected Knowledge](/organization/organization/governance/doctrine/xiii.-architecture/76.-protected-knowledge.md) (governance doctrine) · [I. System overview](/organization/introduction/knowledge/i.-system-overview.md)
## Sources
1. Nexus Documentation Standard, draft of 16 October 2026 (audiences, authority levels, external frameworks, forbidden claims, required notices, confidentiality of instruments). Internal editorial standard; not published.
2. Nexus constitutional directives D-V3-0001, *Master directive V3* (authority invariants, public-safe products), and D-V3-0003, *Twenty-system constitution* (NXS-NSF remit). Internal records, cited by identifier.
3. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://digitalpublicgoods.net/standard/). Accessed 2026-10-16.
4. Nexus institutional register, *Nexus institutional architecture and participation* (commercial channel notice). Internal record; owner-confirmed, counsel review pending.
5. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks and non-execution*, boundary formulas. Internal record, cited by identifier.
6. 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/).
7. 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/).
8. 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/).
9. [The Global Risks Alliance](/organization/institutions/gra.md). *Lawful handoffs* (finance readiness). [globalriskalliance.com/finance-readiness/handoff](https://globalriskalliance.com/finance-readiness/handoff/). Accessed 2026-10-21.
10. OECD (2018). *OECD DAC Blended Finance Principles*. [oecd.org](https://www.oecd.org/en/publications/2018/12/oecd-dac-blended-finance-principles_898d3549.html).
11. 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 V" heading and fixed heading levels; replaced "sovereign compute", "sovereign infrastructure" and "sovereign-compatible" wording with the standard form; removed em dashes; stated that confidential instruments are never published and the Native Master is cited by identifier only; added the scope table, citation rules, the V3 public-safe rules, boundary formulas, decision and commercial-channel boundaries, the authority-level mapping, key terms 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/v.-scope-and-boundaries.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.