> 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/vi.-structural-logic.md). # VI. Structural Logic The order of authority this site follows, the L0 to L6 page authority levels, and the non-duplication rules that keep each definition in one canonical home.
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-0002 and D-V3-0003; 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 · editorial logic. {% 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 \[7] \[8] \[9]; 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 \[10]. {% endhint %} ## In brief Structural logic is the set of rules that decides which source wins when two disagree and where each concept is defined. Binding records outrank every page: law and executed contracts first, then the Native Master legal and IP constitution, then the V3 constitutional directives and the other ranked sources. Below them, each page declares an authority level from L0 (external authority) to L6 (historical). Each concept has one canonical home, and other pages link to it rather than restate it \[1]\[2]. ## Summary This page explains the editorial structure that keeps the Nexus knowledge base coherent under growth. It defines **single source of truth**, **concept anchoring**, **controlled extension**, and **non-duplication** as structural safeguards. It reinforces the system rules set in [III. Reading Rules](/organization/introduction/knowledge/iii.-reading-rules.md) and the scope controls in [V. Scope and Boundaries](/organization/introduction/knowledge/v.-scope-and-boundaries.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 %} ## 6.1 Why non-duplication is a structural requirement In a knowledge system of this scale, duplication is not a cosmetic flaw; it is a structural risk. When the same concept is defined multiple times across different domains, even with minor variations in wording, the system begins to diverge internally. Over time, those variations accumulate into competing interpretations, and competing interpretations eventually produce institutional confusion, operational inconsistency, and weakened trust. Nexus cannot afford such drift. Its architecture depends on precision: institutional roles must remain distinct, standards must remain canonical, participation must remain bounded, and realization must remain subordinate to the public-good and standards-bearing core. Non-duplication is therefore not an editorial preference; it is a condition of system integrity. The purpose of this Part is to define how duplication is avoided, how concepts are anchored, how editorial authority is distributed, and how the knowledge base remains one coherent system rather than a collection of parallel narratives. ## 6.2 The principle of single source of truth At the center of non-duplication is the principle of a **single source of truth**. Every core concept in Nexus must have one primary location where it is fully defined, governed, and maintained. That location carries authoritative meaning. All other references to that concept must remain subordinate to it. Examples include: * Institutional roles (GCRI, GRF, GRA) → defined under **Organization**, as projections of the registers; [NXS-NSF](/organization/systems/nxs-nsf.md), the trust, sovereignty and assurance plane for identity, policy gates and access decisions, is not an institution but one of the twenty Nexus systems, defined with the twenty systems in [I. System overview](/organization/introduction/knowledge/i.-system-overview.md) * Frameworks and mechanisms → defined under **Operations** * Guilds, councils, and participation structures → defined under **Cooperation** * Canonical doctrine, protocol, and standards → defined under **Standardization** * Compute infrastructure, observatory nodes and realization pathways → defined under **Acceleration** Other domains may reference these concepts, but they must not redefine them in full. This ensures that when a concept evolves, it evolves in one place, and the entire system remains aligned. Without this discipline, the system would fragment into multiple partial truths, each locally coherent but globally inconsistent. ## 6.3 The editorial hierarchy of authority Non-duplication requires not only discipline of placement, but clarity of authority. Authority comes first from outside the site. Binding records outrank every page, in the order of authority set out in 6.15: law and executed contracts, the Native Master, the V3 constitutional set, retained controls, the correction suite, Universal Runtime V7 and the Real Product directive, the truth spine, and subsystem directives \[1]\[2]. An earlier version of this page ranked "Foundational Doctrine", meaning pages on this site, as the highest authority. That was wrong: it omitted law, executed instruments, the Native Master, the V3 directives and the registers, all of which outrank any page. The hierarchy below is kept, corrected, because it is useful within its proper scope: it applies only among pages, inside the lowest tier of that order, and each page also declares its authority level (6.16). Among pages, the knowledge system operates with a clear editorial hierarchy: 1. **Foundational pages (highest among pages, below every binding record)** * Institutional definitions, as projections of the registers (L2) or draft instruments (L4) * Canonical standards and protocol * Reading rules and architectural principles 2. **Primary Domain Definitions** * Full definitions within each of the five areas * Domain-specific structures and rules 3. **Derived and Contextual Content** * Summaries, overviews, adaptations * Sectoral or regional contextualization 4. **Illustrative and Narrative Content (lowest authority)** * Examples, case studies, explanatory narratives * Public-facing simplifications Authority flows downward, not upward. A narrative example cannot redefine a domain rule.\ A contextual adaptation cannot redefine canonical doctrine.\ An operational document cannot redefine institutional authority.\ A realization case cannot redefine standards. This hierarchy ensures that the knowledge base remains stable under expansion and adaptation. ## 6.4 The role of cross-reference instead of repetition To maintain readability without duplication, Nexus relies on **cross-reference** rather than repetition. Where a concept is required in multiple domains, the correct approach is: * briefly orient the reader with a bounded summary; * explicitly point to the authoritative source; * avoid restating the concept in full or introducing variation. For example: A page in Acceleration may refer to routeability, but the full definition remains in Standardization.\ A page in Cooperation may refer to institutional roles, but the full definition remains in Organization.\ A page in Operations may reference guild structures, but the full definition remains in Cooperation. Cross-reference preserves both clarity and discipline. It allows the reader to navigate the system without forcing each page to become self-sufficient at the cost of duplication. ## 6.5 The rule of concept anchoring Every major concept in Nexus must be **anchored**, that is, tied to a defined domain, a stable definition, and a known interpretive context. Concept anchoring requires: * a clearly identified home domain; * a canonical definition; * stable terminology; * explicit boundaries of meaning; * and consistent usage across the system. Unanchored concepts are one of the fastest routes to systemic confusion. When a term begins to appear in multiple places without a fixed definition, it becomes flexible in the wrong way. Flexibility then becomes ambiguity, and ambiguity eventually becomes inconsistency. Anchoring ensures that: * “routeability” means the same thing across all domains; * “compute infrastructure” intended for national deployment is not reinterpreted as generic hosting, nor described as sovereign in itself; * “guilds” are not confused with informal networks; * “standards” are not mistaken for guidelines; * “acceleration” is not reduced to conventional innovation programs. Anchoring protects the semantic integrity of the system. ## 6.6 The rule of controlled extension As the knowledge system grows, new concepts will emerge. These must be introduced through **controlled extension**, not spontaneous insertion. Controlled extension requires that: * new concepts are placed within the correct domain; * their relationship to existing concepts is explicitly defined; * they do not duplicate existing concepts under new names; * they do not blur boundaries between domains; * and they are anchored before they are widely used. This prevents the proliferation of near-duplicates: concepts that appear new but overlap with existing structures in ways that create confusion rather than clarity. Controlled extension allows the system to evolve while preserving coherence. ## 6.7 The rule against parallel structures A particularly dangerous form of duplication is the emergence of **parallel structures**. This occurs when: * two domains define similar frameworks independently; * multiple participation systems evolve without alignment; * different parts of the system create competing versions of the same mechanism; * or different realization pathways imply different underlying architectures. Parallel structures create fragmentation even when each structure is internally coherent. They make it impossible for readers, contributors, and partners to know which structure is authoritative. The rule is therefore clear: There must be one canonical structure for each class of function. Where variation is necessary, it must occur as a contextual adaptation of the canonical structure, not as a competing system. ## 6.8 The rule of terminological discipline Language is not neutral in a system like Nexus. Terms carry structural meaning. If terminology is used loosely, the architecture becomes unstable. Terminological discipline requires that: * core terms are defined once and used consistently; * synonyms are avoided where they create ambiguity; * metaphor is used carefully and never as a substitute for definition; * new terms are introduced only when necessary; * and informal language does not replace canonical terminology in authoritative contexts. For example: “Rail” must not be casually replaced with “platform” or “network” when those terms carry different implications.\ “Standards” must not be used interchangeably with “guidelines.”\ “Consortium” must not be confused with “partnership.”\ “Observatory” must retain its specific architectural meaning: “Nexus Observatory Protocol” means the observation protocol owned by NXS-OPS in collaboration with NXS-EOP and NXS-SIG, and observatory nodes are NXS-OPS nodes (see 6.18). Terminological discipline is essential because Nexus operates at the intersection of multiple domains where language already carries heavy prior meaning. Without discipline, semantic drift is inevitable. ## 6.9 The rule of editorial separation Editorial separation ensures that each domain remains distinct in tone, purpose, and content. Organization must read as constitutional and institutional.\ Operations must read as procedural and functional.\ Cooperation must read as participatory and ecosystem-oriented.\ Standardization must read as canonical and precise.\ Acceleration must read as realization-oriented and materially grounded. If these tones collapse into one another, readers lose the ability to distinguish authority from description, or doctrine from application. Editorial separation therefore reinforces structural separation. ## 6.10 The rule of iterative coherence Non-duplication is not achieved once; it must be maintained over time. As new content is added, existing content must be revisited to ensure continued coherence. This requires: * periodic review of definitions and their usage across domains; * alignment of new materials with existing structures; * correction of drift before it accumulates; * and disciplined supersession where older material is replaced. The system must evolve, but it must do so coherently. Iterative coherence ensures that growth strengthens the architecture rather than diluting it. ## 6.11 The role of editorial governance Because non-duplication is structural, it requires governance. Editorial governance ensures that: * new content is placed correctly; * duplication is identified and resolved; * cross-domain alignment is maintained; * terminology remains consistent; * and the knowledge system evolves according to its own rules. This is not a centralized control function in the conventional sense. It is a structural discipline that must be upheld across all contributors and domains. Without editorial governance, even a well-designed architecture will fragment under growth. ## 6.12 The balance between clarity and redundancy Non-duplication must not come at the cost of readability. A knowledge system that forces readers to navigate excessively in order to understand basic concepts becomes inaccessible. The balance is achieved through: * bounded summaries where necessary; * clear cross-references; * consistent terminology; * and strong anchoring of concepts. The goal is not minimal repetition, but **controlled repetition**: enough to support understanding, not enough to create competing meanings. ## 6.13 Failure modes prevented by non-duplication The discipline of non-duplication prevents several critical failure modes: * **Semantic drift**, where the same term comes to mean different things; * **Authority confusion**, where multiple domains appear equally authoritative; * **Institutional drift**, where roles blur over time; * **Operational inconsistency**, where different parts of the system behave differently; * **Fragmentation**, where parallel structures emerge; * and **loss of trust**, where readers cannot rely on the system to be internally consistent. These are not theoretical risks. They are common in large, multi-domain systems. Nexus is designed to prevent them through explicit structure. ## 6.14 Final statement on structural non-duplication Structural non-duplication is one of the quiet foundations of Nexus. It ensures that the system remains one architecture even as it expands across domains, institutions, geographies, and applications. It preserves clarity under scale.\ It preserves authority under growth.\ It preserves meaning under adaptation.\ It preserves trust under complexity. A system that avoids duplication is not merely well-organized. It is resilient. It can grow without losing coherence, adapt without losing identity, and expand without fragmenting. This is the editorial logic that underpins the Nexus knowledge base and ensures that it remains a durable, authoritative, and globally intelligible system. ## 6.15 The order of authority When sources disagree, the site follows this order, 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 (the nine allowlisted constitutional files only). 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. An unresolved conflict is recorded as a blocking directive conflict, not resolved silently. V3 authority is target definition; it is not evidence of implementation, deployment, observation, validation or acceptance \[2]. For legal and institutional statements, the order is: mandatory law; instruments executed by authorized signatories; accepted terms; the generated Institutional Architecture and Participation Statement; then explanatory documents \[1]\[3]. Facts bind through registers, not prose.
The order of authority, highest first, in two columns of four ranks: law and executed contracts; the Native Master constitution; the V3 constitutional set; retained controls; the correction suite; Universal Runtime V7 and the Real Product directive; the truth spine; subsystem records. GitBook pages, levels L0 to L6, explain these sources and sit below every rank.

Figure 1. The authority ladder, highest first: ranks 1 to 4 in the left column, ranks 5 to 8 in the right. GitBook pages explain the ranked sources and sit below all of them; the editorial hierarchy of 6.3 operates only inside that box. Source: the documentation standard, projecting the directive precedence policy (D-V3-0002), as of 2026-10-16.

Text description of Figure 1 From highest to lowest: rank 1, mandatory law and executed contracts; rank 2, the Native Master legal, IP and open-source constitution, cited by its identifier D-NEXUS-NATIVE-MASTER-1; rank 3, the V3 constitutional set D-V3-0001 to D-V3-0009, which defines targets; rank 4, retained operational, legal and delivery controls; rank 5, the correction suite; rank 6, Universal Runtime V7 and the Real Product directive; rank 7, the ecosystem truth spine for current state; rank 8, subsystem directives, architecture decision records, programme waves and tasks. A final link from rank 8 shows that GitBook pages, at authority levels L0 to L6, explain these sources and do not rank among them.
## 6.16 Page authority levels Every page declares one authority level in its document record \[1]. | Level | Meaning | Examples on this site | Rule | | --------------------------------------- | ------------------------------------------------------------- | -------------------------------------------------------- | ------------------------------------------------------------------------- | | **L0** External authority | Text or data issued by an external body | UN resolutions, the Sendai Framework, ISO standards | Cited, never reproduced beyond short quotation | | **L1** Executed instrument | An instrument signed by authorized signatories, with evidence | None recorded | Cited only when the executed record exists | | **L2** Binding canon projection | A page that summarizes a binding repository record | Summaries of the twenty systems or the boundary formulas | Cites the directive id; the record wins over the page | | **L3** Adopted institutional instrument | A charter, bylaw or policy with an adoption record | None verified | Requires a cited adoption record | | **L4** Draft institutional instrument | An owner-drafted instrument without an adoption record | Most charter and governance instrument pages | Protected record; carries a draft notice | | **L5** Explanatory | Explains, interprets or describes; creates no obligation | This page and the whole Knowledge section | Traces each normative-sounding statement to L0-L3 or labels it a proposal | | **L6** Historical or superseded | Kept for history; no current effect | Pages based on superseded directives; retired labels | Carries a historical notice; text kept unchanged | *Table 1. Page authority levels. Source: the documentation standard as of 2026-10-16 \[1].* Two consequences follow. First, a page is never cited by another page as evidence for a normative claim; it cites the record \[1]. Second, the presentation of a page (length, polish, position in the navigation) says nothing about its authority; only the document record does. The four tiers of the editorial hierarchy in 6.3 sit inside levels L2 to L5: foundational pages are usually L2 or L4, primary domain definitions L2 or L5, derived and illustrative content L5. ## 6.17 One concept, one home: canonical pages The single-source-of-truth principle of 6.2 is applied through canonical pages. Every core concept has one canonical home where it is fully defined and maintained; other pages give at most a short summary and link there \[1]. | Concept | Binding source | Canonical page on this site | | ---------------------------------------------- | ----------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Institutional roles and limits | Registers and the Institutional Architecture and Participation Statement \[3] | [Organization introduction](/organization/introduction/organization.md) | | The twenty systems and shared fabrics | D-V3-0003, D-V3-0001 | [I. System overview](/organization/introduction/knowledge/i.-system-overview.md) | | The five subject areas | This site's structure | [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) | | Status grammar, claim rules, boundary formulas | D-V3-0005, D-V3-0004 | [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) | | Page classes and document status | Documentation standard draft | [VII. Knowledge lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md) | | Review and approval of pages | Documentation standard draft and the editorial constitution draft | [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md) | *Table 2. Canonical homes for concepts used across this section.* When a concept is needed elsewhere, the page gives a bounded summary of one or two sentences, links to the canonical page, and adds no new meaning, exception or authority (6.4). ## 6.18 Terminology practice and commonly confused terms The terminological discipline of 6.8 follows established terminology practice: a concept is defined by its genus and distinguishing features, one preferred term is chosen, and synonyms are recorded as such rather than used interchangeably \[4]\[5]. For concept schemes published as data, the W3C Simple Knowledge Organization System (SKOS) separates preferred labels, alternative labels and definitions in the same way \[6]. These are reference points, not claims of conformance. Terms that are easily confused on this site: | Term | Distinct from | How to tell them apart | | ------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------- | | [NXS-RLS](/organization/systems/nxs-rls.md), system 18, the technical rails and protocol infrastructure for protocol-governed work across institutions | One Rail-Two Stacks (doctrine); the [NXS-RLS](/organization/standardization/nexus-rail.md) Standardization section | Use the system id, the word "doctrine" or the section title | | Nexus Observatory Protocol (observation protocol of NXS-OPS, with NXS-EOP and NXS-SIG) | NXS-OPS observatory nodes; an evidence-layer concept on some pages | The protocol is the shared observation discipline of the observatory ecosystem; other senses carry a note | | The twenty systems | The [SYSTEMS part](/organization/systems.md) | The Acceleration section on the build work is narrower than the systems | | NXS-NSF, a system | Any "foundation" | No standards foundation or similar body is on record; Nexus Standards is a proposed standards programme | | Standard (proposed Nexus Standards) | Guideline; official or national standard | Nexus Standards are PROPOSED; none has official status | | Consortium | Partnership; a single legal person | The Nexus Consortium is not presumed to be an incorporated person | *Table 3. Commonly confused terms. Sources: the documentation standard, on terms and boundary formulas \[1].* ## Next steps * Read [VII. Knowledge Lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md) for content classes and maturity levels. * Read [VIII. Knowledge Governance](/organization/introduction/knowledge/viii.-knowledge-governance.md) for stewardship and review roles. * Read [X. Knowledge Base Integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md) for trust and integrity controls. ## Related pages * Up: [Knowledge](/organization/introduction/knowledge.md) * Across: [III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) · [V. Scope and boundaries](/organization/introduction/knowledge/v.-scope-and-boundaries.md) · [VII. Knowledge lifecycle](/organization/introduction/knowledge/vii.-knowledge-lifecycle.md) * Counterparts: [0. Knowledge system](/organization/introduction/knowledge/0.-knowledge-system.md) · [Standardization introduction](/organization/introduction/standardization.md) ## Sources 1. Nexus Documentation Standard, draft of 16 October 2026 (audiences, order of authority, page authority levels, commonly confused terms, canonical pages). Internal editorial standard; not published. 2. Nexus constitutional directive D-V3-0002, *Directive precedence and source authority*, and the directive precedence policy. Internal record, cited by identifier. 3. Nexus institutional register, *Nexus institutional architecture and participation*. Internal record; owner-confirmed, counsel review pending. 4. International Organization for Standardization (2022). *ISO 704:2022 Terminology work: Principles and methods*. ISO, Geneva. (URL not verified.) 5. International Organization for Standardization (2019). *ISO 1087:2019 Terminology work and terminology science: Vocabulary*. ISO, Geneva. (URL not verified.) 6. World Wide Web Consortium (2009-08-18). *SKOS Simple Knowledge Organization System Reference*, W3C Recommendation. [w3.org](https://www.w3.org/TR/skos-reference/). Accessed 2026-10-16. 7. 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/). 8. 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/). 9. 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/). 10. GCRI. *How Nexus works*: the six pillars, the eighteen handoffs and the eight-step cycle. [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Accessed 2026-10-21. ## Editorial record * As of: 2026-10-16. Refresh: every 180 days, or sooner when a governing source changes. * Drafting: AI-assisted. Human review: pending; no named reviewer or approver yet. * Corrections: a public corrections route has not yet been published. Corrections will be recorded as new dated versions, not silent edits. * Change log: 2026-10-16 r1, upgraded to the documentation standard draft. Added the Record block and In brief; removed the empty "Part VI" heading and fixed heading levels; corrected the editorial hierarchy (6.3), which had ranked site pages as the highest authority, by placing it below the order of authority; replaced "NSF" as an institutional role with the V3 system; replaced "sovereign compute" wording; removed em dashes; added the order of authority with the authority-ladder figure, the L0 to L6 levels, canonical homes, terminology practice, a confused-terms table and sources. 2026-10-16 r2, readable document record and status note; Nexus Standards system codes; Nexus Standards system naming and Nexus Observatory Protocol naming; company references removed; plain-language sources. 2026-10-21 r3, aligned with the latest sources: Where this fits line and current-model note added; institutional roles, standards governance (no standards foundation or protocol authority as an institution), councils (six [Helix councils](/organization/governance-in-operation/councils.md), [CERTs](/organization/governance-in-operation/nwg.md)), [National Nexus](/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/vi.-structural-logic.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.