> 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/iii.-reading-rules.md).
# III. Reading Rules
Rules for reading any page on this site: domain primacy, upstream reading, bounded summary, stage truth mapped to status per dimension and boundary formulas.
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-0004 and D-V3-0005; the Nexus model and the Nexus Consortium model as published on the sites (2026-10-21); the [Nexus Standards](/organization/institutions/nexus-standards.md) governance and [NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) |
| **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
**Where this fits:** all six sectors · all six pillars, above all Nexus Standards and Nexus Reports for the rules of this documentation · the Nexus Consortium, with GCRI Canada as Secretariat · Publish and Renew in the cycle · reading rules.
{% 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 \[10] \[11] \[12]; the house rules are in the [citation style](/organization/reference/citation-style.md). The cycle runs Question, Evidence, Build, Organize, Test, Publish, Decide and Renew; the competent authority decides, outside the programme ([the Nexus cycle](/organization/programme/the-nexus-cycle.md)) \[13]. The steps follow the risk-management process of ISO 31000 \[14]. 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)) \[15].
{% endhint %}
## In brief
Reading rules are the conventions a reader needs to interpret any page on this site correctly. They say which sources outrank a page, which area owns a concept, what "shall", "should" and "may" mean, how tense signals status, how status is stated per dimension instead of as one readiness score, which boundary sentences are quoted verbatim, and how corrections appear. They follow the V3 truth inequalities: target is not implementation, implementation is not verification, verification is not observation, and observation is not acceptance \[1]\[2].
## Summary
This page defines how readers should interpret content across the Nexus knowledge system. It explains **domain primacy**, **upstream interpretation**, **stage truth**, and **non-duplication** so that readers do not confuse governance, participation, standards, and realization.
Use it alongside [II. Knowledge Architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) and [IV. Reading Paths](/organization/introduction/knowledge/iv.-reading-paths.md) when navigating the docs.
{% 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 %}
## 3.1 Why cross-area reading rules are necessary
A knowledge system of this scale cannot rely on proximity, stylistic similarity, or editorial instinct to preserve coherence. Where multiple domains coexist (constitutional, operational, participatory, canonical and realization-oriented), readers will naturally attempt to infer meaning across them. That is both necessary and useful. But without explicit reading rules, the same process can generate subtle but cumulative errors: workflow can be mistaken for authority, participation can be mistaken for standing, technical specification can be mistaken for institutional mandate, and deployment can be mistaken for the whole system.
For that reason, Nexus requires cross-area reading rules. These rules are not merely editorial conventions. They are a form of governance within the knowledge architecture itself. Their purpose is to preserve role purity across the five major domains, to ensure that downstream materials do not silently redefine upstream foundations, and to keep the whole corpus interpretable as one system rather than many overlapping narratives.
The need for such rules grows with success. When a system is small, coherence can be held by memory, proximity, and a relatively narrow circle of contributors. When a system expands across institutions, jurisdictions, sectors, partners, programs, and technical environments, informal coherence collapses quickly. The knowledge base must then carry part of the burden of institutional integrity. Cross-area reading rules are the mechanism by which it does so.
## 3.2 The rule of domain primacy
The first and most important reading rule is the rule of domain primacy. Each of the five primary areas has authority over a distinct class of questions, and that authority should be respected whenever a document is interpreted.
Where the question concerns constitutional identity, institutional role, governance structure, federation, reserved matters, or authority boundaries, **Organization** is primary.
Where the question concerns frameworks, workflows, mechanisms, reports, production logic, forums, media process, or platforms as operating surfaces, **Operations** is primary.
Where the question concerns guilds, councils, memberships, ecosystem interfaces, participation pathways, contribution logic, partner engagement, or cooperative safeguards, **Cooperation** is primary.
Where the question concerns canonical doctrine, semantics, trust architecture, protocol logic, conformance, routeability grammar, sovereignty architecture, or standards operating systems, **Standardization** is primary.
Where the question concerns compute infrastructure, observatory nodes (NXS-OPS), consortiums, realization vehicles, programs, studios, accelerators, deployment pathways, or scaling in the world, **Acceleration** is primary.
Domain primacy operates among the pages of this site. Binding records (law, executed instruments, the Native Master, the V3 constitutional set and the registers) outrank every page, whichever area it sits in (rule RR-1 in 3.16) \[2]\[3].
This rule means that not every appearance of a concept carries equal authority. A page in one domain may refer to concepts governed elsewhere, but that does not shift primary interpretive authority. Primary meaning remains with the domain to which the concept properly belongs.
## 3.3 The rule of upstream interpretation
The second rule is the rule of upstream interpretation. The five areas are not only distinct; they are ordered. The order of the system determines the order of interpretation.
Organization stands upstream of Operations because no workflow, mechanism, or platform may redefine institutional authority.
Operations stands upstream of Cooperation because no participation architecture may redefine how the system produces, validates, and maintains work.
Organization, Operations and Cooperation all stand upstream of Standardization in the sense that canonical doctrine must be interpreted in relation to the institutions that hold it, the operating environment in which it is used, and the participation structures through which it circulates. At the same time, once Standardization defines canonical meaning, that meaning binds downstream realization.
Acceleration stands downstream of all four because realization is the domain in which every earlier layer becomes operationally visible. For that reason, it is the most dependent on upstream integrity and the least entitled to reinterpret upstream doctrine through practical convenience or deployment pressure.
The practical consequence of this rule is simple: if a downstream document appears to imply an interpretation that conflicts with an upstream domain’s stated meaning, the upstream meaning prevails unless and until a formal revision is made at the appropriate level.
## 3.4 The rule against reverse redefinition
A corollary of upstream interpretation is the rule against reverse redefinition.
No deployment case may redefine the standards system merely because it proves popular, urgent, or technically elegant.\
No guild output may redefine institutional authority merely because it has accumulated visibility or expertise.\
No operating framework may redefine constitutional role merely because it has become central to day-to-day activity.\
No public-facing narrative may redefine canonical doctrine merely because it communicates more simply.
The system may learn from downstream practice. It may evolve through observed reality. It may refine itself through feedback. But such refinement must move through the appropriate interpretive and governance channels. Reality informs the system; it does not automatically rewrite it.
This rule is especially important in a system like Nexus because the most visible layer is often not the most authoritative layer. Realization surfaces, partner relationships, and public-facing outputs can become more salient than the institutional and standards-bearing architecture beneath them. The rule against reverse redefinition preserves the distinction between visibility and authority.
## 3.5 The non-duplication rule
The third major rule is non-duplication. A concept should not be fully defined in more than one primary area in a way that creates parallel authorities.
This does not prohibit repetition in the ordinary sense. Some repetition is necessary. A reader entering through Acceleration may need a short explanation of routeability. A reader entering through Cooperation may need a concise description of the public-good core. A reader entering through Operations may need a brief explanation of registry logic. Such references are appropriate.
What the rule prohibits is the creation of competing full definitions. When one domain restates another domain’s central concept in complete form, especially with added nuance, modified boundaries, or implied authority, the knowledge system begins to split internally. Over time, such duplication produces not redundancy but divergence. Divergence then produces interpretive conflict, and interpretive conflict eventually produces operational and institutional drift.
The proper discipline is therefore this: each primary area should own the complete definition of its proper concepts. Other areas may summarize them only to the extent necessary for local readability and should point the reader back to the proper source of full authority.
## 3.6 The rule of bounded summary
Because total non-repetition is impossible and undesirable, the non-duplication rule must be paired with a bounded-summary rule.
A bounded summary is permitted when:
* a concept from another domain is necessary for local comprehension,
* the summary remains brief and subordinate,
* the summary does not introduce new normative meaning,
* the summary does not imply interpretive authority that belongs elsewhere, and
* the summary clearly functions as orientation rather than as full restatement.
The purpose of bounded summary is to maintain readability without sacrificing structural clarity. It allows a domain to remain self-contained enough for practical reading while preserving the primacy of the domain that properly owns the concept.
This is especially important in a public-facing and institution-facing knowledge system. Readers should not be forced into excessive navigation merely to understand basic context. At the same time, they should not be encouraged to treat every page as a full authority on every concept it mentions. The bounded-summary rule is the balance between those needs.
## 3.7 The rule of stage truth
Another essential cross-area rule is the rule of stage truth. The Nexus system depends on the distinction among different classes of maturity, force, and meaning. The knowledge architecture must preserve those distinctions explicitly.
Evidence is not standing.\
Standing is not readiness.\
Readiness is not routeability in the fullest sense.\
Routeability is not execution.\
Execution-useful structure is not execution-bearing authority.
These distinctions apply across all five areas. Organization must not imply that constitutional recognition alone creates operational maturity. Operations must not imply that a functioning workflow confers institutional standing. Cooperation must not imply that active participation creates authority. Standardization must not imply that canonical form guarantees deployability in every context. Acceleration must not imply that deployment, piloting, or adoption readiness equals licensed execution or sovereign commitment.
Stage truth is one of the deepest protections in the whole architecture because most real-world distortions occur through premature implication rather than explicit falsehood. The knowledge system must therefore remain disciplined about what any artifact, system, programme or institutional state actually means, and what it does not yet mean.
The stage-truth ladder above is kept because its distinctions are sound, but it merges different kinds of status into one sequence. Section 3.17 maps each rung to the V3 truth inequalities and to the five-state public grammar that pages now use \[1]\[3].
## 3.8 The rule of public-good distinctness
A further cross-area rule is the preservation of public-good distinctness. Because Nexus includes public-good institutions, standards-bearing infrastructures, ecosystem participation, partner interfaces, and realization pathways that may become capital-legible or deployment-facing, there is a persistent risk that the public-good core is gradually reinterpreted through the language of execution, productization, or commercial centrality.
This must not occur.
The constitutional and standards-bearing core exists to steward common meaning, trust, routeability grammar, evidence discipline, and anti-fragmentation order. It is not reducible to a commercial brand, a deployment umbrella, or a lead-generation surface for downstream actors. The knowledge architecture must reinforce this distinctness consistently.
This means:
* public-good authority must remain distinguishable from downstream delivery capability;
* canonical doctrine must remain distinguishable from implementations built upon it;
* guilds and ecosystem partnerships must remain distinguishable from execution-side institutions;
* routeability and finance-readiness must remain distinguishable from binding commercial or sovereign acts; and
* realization materials must not rhetorically absorb the constitutional center into themselves.
This rule protects legitimacy, sovereignty compatibility, procurement neutrality, and long-horizon trust.
## 3.9 The rule of safeguarded translation
Because the knowledge system serves many audiences (public authorities, multilaterals, technical builders, universities, civil society, industry, finance and communities), it must also allow translation across domains and audiences. But such translation must be safeguarded.
Safeguarded translation means that material may be adapted in tone, level of detail, and use-case emphasis for a given readership without distorting the architecture that gives it meaning. A technical standards page may be summarized for policymakers. A consortium model may be explained for partners. A guild structure may be described for new members. A compute-infrastructure paper may be reframed for public-authority readers. These are all legitimate acts of translation.
What is not legitimate is translation that changes the actual constitutional, semantic, or role-bearing meaning of the system. Translation must make the architecture more accessible, not more convenient to misread.
The rule of safeguarded translation therefore requires that all adapted summaries, public introductions, and domain-specific explanatory texts remain tethered to the canonical reading rules of the knowledge system.
## 3.10 The rule of controlled cross-reference
In a large knowledge architecture, cross-reference is a strength, not a weakness. But it must be controlled.
Every primary area should be able to point the reader to related domains when needed. Organization should point to Operations when governance depends on live procedural discipline. Operations should point to Cooperation when workflows depend on guilds or memberships. Cooperation should point to Standardization when participation is bounded by conformance or semantic rules. Standardization should point to Acceleration when canonical architecture is instantiated in real infrastructure. Acceleration should point back to all upstream domains because realization depends on them.
However, cross-reference should never function as a substitute for structural clarity. A reader must never be left unsure whether the cross-reference is orienting them, shifting authority, or creating an exception. The purpose of controlled cross-reference is to illuminate interdependence while preserving the primary scope of each domain.
## 3.11 The rule of local completeness and systemic incompleteness
Each primary area should be locally complete enough to be readable on its own terms, but no area should pretend to be systemically complete in isolation.
Organization should be complete enough that a reader can understand the institutional order without first reading every deployment or standards document.
Operations should be complete enough that a reader can understand the live functioning of the system without first reading every guild or infrastructure paper.
Cooperation should be complete enough that a reader can understand how participation is governed without first reading every operational or technical artifact.
Standardization should be complete enough that a reader can understand canonical doctrine without first reading every consortium or studio page.
Acceleration should be complete enough that a reader can understand realization without first reading every framework or bylaw.
Yet none of these domains should claim or imply that they contain the whole of Nexus in themselves. Each domain is complete locally and incomplete systemically. This is one of the most important interpretive rules in the architecture, because it protects the system against totalization by any one surface.
## 3.12 The rule of structural escalation
When new material is drafted, edited, or proposed, uncertainty should be resolved through structural escalation rather than informal accommodation.
If a new text appears to belong partly to two or more domains, the first question should not be, “Where is there room?” but, “What class of truth does this material primarily carry?” If it carries constitutional truth, it belongs under Organization. If it carries live operating truth, it belongs under Operations. If it carries participation truth, it belongs under Cooperation. If it carries canonical or protocol truth, it belongs under Standardization. If it carries realization truth, it belongs under Acceleration.
Where a document genuinely spans domains, one domain should own the primary text and other domains should contain bounded references or local summaries. Structural escalation prevents the quiet proliferation of hybrid documents that later become impossible to interpret consistently.
## 3.13 The rule of correction and supersession
The knowledge system must also preserve a discipline of correction and supersession. Because Nexus is a living architecture and not a static corpus, the knowledge base must allow refinement, clarification, replacement, and deprecation over time.
But correction must not occur by silent replacement. Supersession must not occur by drift. When a text is narrowed, amended, or replaced, that change should occur in a way that preserves lineage, interpretive continuity, and the reader’s ability to understand what changed and why.
This matters across all areas. A constitutional clarification in Organization may affect operational assumptions. A standards update in Standardization may affect realization pathways. A cooperation rule may affect participation rights. A realization refinement may expose the need for stronger safeguards. The knowledge system must therefore treat correction not as an embarrassment, but as part of its integrity model.
## 3.14 The rule of reader protection
Cross-area reading rules also serve the reader directly. They protect the reader from several predictable mistakes.
They protect the reader from mistaking the most visible layer for the most authoritative one.\
They protect the reader from thinking that a deployment case defines the whole architecture.\
They protect the reader from treating a public-facing summary as though it were canonical doctrine.\
They protect the reader from assuming that participation implies authority.\
They protect the reader from confusing routeability with execution.
In this sense, the reading rules are not only about internal coherence. They are also a form of intellectual safety for the reader, ensuring that the knowledge system can be approached by new audiences without requiring prior insider familiarity.
## 3.15 Final statement on cross-area reading rules
The cross-area reading rules of Nexus exist to preserve coherence under scale, complexity, specialization, and growth. They ensure that the five major domains remain interdependent without becoming interchangeable. They protect upstream authority from downstream pressure. They protect canonical meaning from local convenience. They protect public-good distinctness from execution drift. They protect the reader from interpretive error. And they protect the system from the gradual collapse that afflicts ambitious architectures whose documents grow faster than their internal order.
For that reason, these rules should be treated as load-bearing.
They are not appendices to content.\
They are conditions of content.\
They are not notes for editors alone.\
They are part of the architecture of Nexus itself.
This is the framework through which all subsequent domain materials should be drafted, read, and maintained.
## 3.16 The rules in summary
Sections 3.2 to 3.14 explain the cross-area rules. This section restates them, with the rules on words, tense, status and claims that apply to every page, as numbered rules with sources. Each rule has a page-local identifier (RR-n), which is provisional. They are editorial conventions for this site; they bind no institution and replace no instrument \[3].
### Authority and placement
* **RR-1. Records outrank pages.** Law, executed instruments, the Native Master (D-NEXUS-NATIVE-MASTER-1), the V3 constitutional set and the registers outrank every page. If a page conflicts with one of them, the record prevails and the page is corrected; the conflict is never resolved silently \[2]\[3].
* **RR-2. The home area owns the meaning.** Each concept has one home area and one canonical page (see [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md)). Another page may mention the concept, but its mention does not change the meaning (3.2, 3.5) \[3].
* **RR-3. Interpret upstream first.** Areas are interpreted in the order of dependence: Organization, then Operations, Cooperation, Standardization and Acceleration. Where a downstream page seems to imply something an upstream page does not say, the upstream page governs until a recorded revision changes it (3.3).
* **RR-4. No reverse redefinition.** A deployment case, guild output, operating framework or public summary does not redefine a concept by being popular, urgent or visible. Practice informs revisions only through the correction and supersession route ([VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md)) (3.4, 3.13).
* **RR-5. Summaries are bounded.** A summary of another area's concept is permitted when it is short, adds no new normative meaning, implies no authority and links to the canonical page (3.6) \[3].
### Words and tense
* **RR-6. Verbal forms.** In normative statements quoted or summarized on this site, SHALL states a requirement, SHOULD a recommendation, MAY a permission and CAN a possibility, following the conventions of the IETF (RFC 2119, clarified by RFC 8174) and of the ISO/IEC Directives, Part 2 \[4]\[5]\[6]. On an explanatory page these words report the rule of the cited source; they do not create a new one.
* **RR-7. Tense signals status.** The present tense is used only for what operates now. A target is written "is designed to"; a service not yet open "opens when"; a platform not yet established is "in development" \[3].
* **RR-8. Names are canonical.** The twenty systems carry their Nexus Standards display codes (for example [NXS-GRX](/organization/systems/nxs-grx.md), the global data and risk intelligence engine), with a short description at first mention on a page; acronyms without an approved long form are not expanded; "Nexus Observatory Protocol" means the observation protocol owned by NXS-OPS in collaboration with NXS-EOP and NXS-SIG, and other senses of "observatory" carry a note; Nexus Standards is a proposed standards programme \[3].
### Status and claims
* **RR-9. Status is stated per dimension.** No page publishes a single readiness label, maturity score, traffic light or percentage that merges dimensions \[1]\[3]. The public grammar has five states (section 3.17).
* **RR-10. Boundary formulas are quoted 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." \[7]
* **RR-11. Epistemic states stay distinct.** Reported, declared, measured, observed, estimated, forecast, simulated, reviewed, accepted and executed states are different objects. Among the V3 inequalities: Declared ≠ Verified; Forecast ≠ Fact; Simulated ≠ Executed; Signed ≠ Authoritative; Published ≠ Official; AgentGenerated ≠ StewardApproved \[8].
* **RR-12. No claim without its evidence.** Words such as live, ready, production-ready, certified, official, secure, compliant, sovereign-ready, financeable or insurable are never applied to a Nexus system, institution, standard or output without the named evidence and authorized promotion for the exact scope \[1]\[3].
* **RR-13. External frameworks are references.** A citation of a UN framework, a standard or a supervisory publication describes alignment or context. It does not imply endorsement, affiliation, partnership or conformance \[3].
### Change
* **RR-14. Corrections are visible.** A substantive change creates a new dated version recorded in the page's editorial record. Superseded text is kept and linked, not silently replaced (3.13) \[3].
* **RR-15. Translation keeps boundaries.** A translated or audience-adapted page may change tone and depth but not roles, status or boundaries. English and French institutional notices preserve the same party and title boundaries (3.9) \[3].
## 3.17 Status per dimension: the five-state grammar
The site uses the V3 truth inequalities ("Target definition != implementation. Implementation != verification. Verification != observation. Observation != authority acceptance") and the five-state public grammar of the documentation standard draft \[1]\[3].
| Public state | For systems and capabilities | For institutions and programmes | Evidence that must be cited |
| --------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| **Target** | Defined by a V3 directive or adopted architecture decision record | Defined in a charter, bylaw, doctrine or programme design | Directive id or instrument page |
| **Implemented** | Implementation state in the capability ledger | Instrument adopted; entity constituted; programme constituted | Ledger row with evaluation date; adoption or formation record |
| **Verified** | Verification state (tested, integration verified) | Register verification state; an owner confirmation is a statement, not verification | Ledger row; register field |
| **Observed** | Operational state (at most lab-observed today) | Programme active with a dated, published record | Observation receipt; published record |
| **Accepted** | Authority-accepted evidence level | Recognition by a competent external authority | That authority's own record |
*Table 1. The five public states. Where no record exists, the cell says "No record". Source: the documentation standard, projecting the ten V3 truth dimensions (D-V3-0005) \[1]\[3].*
How the stage-truth ladder of section 3.7 maps to the current vocabulary:
| Earlier term | Current reading | Boundary that applies |
| ------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------- |
| Evidence | A record at a stated evidence level (documented, configured, tested, observed, independently assessed, authority accepted), each scoped and time-bounded | A receipt proves the recorded event within scope only \[8] |
| Standing | Recognition by a competent body, shown only with that body's record | "Public-authority learning is not approval" \[7] |
| Readiness | Fitness for a stated next step, within a stated scope and evidence state | "Finance-readiness is not finance" \[7] |
| Routeability | A lawful handoff of a readiness dossier to a competent party at the programme owner's written direction | "A decision-support package is not an official decision" \[7] |
| Execution | An act by a competent actor under its own authority and contract, with a returned receipt | Decisions stay with competent actors \[7] |
*Table 2. Stage-truth terms and their current reading. Definitions of readiness and lawful handoff follow the documentation standard's glossary, drawn from draft site copy \[3].*
## 3.18 International practice behind these rules
The reading rules follow practices that readers in standards bodies, statistics offices and supervisors will recognize. Requirement keywords follow the IETF and ISO/IEC drafting conventions \[4]\[5]\[6]. The separation between a statement and its evidence state mirrors the way the UN Fundamental Principles of Official Statistics ask producers to be transparent about sources and methods \[9]. These are reference points, not claims of conformance.
## 3.19 Key terms
| Term | Meaning on this site |
| ------------------ | -------------------------------------------------------------------------------------------------------- |
| Canonical page | The single page that owns a concept's full definition; other pages link to it |
| Bounded summary | A short, non-normative mention of another area's concept with a link to its canonical page |
| Boundary formula | One of the eight verbatim "X is not Y" sentences of D-V3-0004 |
| Claim ceiling | The strongest statement a page may make about a capability, set by the evidence on record |
| Five-state grammar | Target, implemented, verified, observed, accepted, each with its own evidence |
| Stage truth | The earlier name on this page for keeping maturity states apart; now expressed by the five-state grammar |
## Next steps
* Read [IV. Reading Paths](/organization/introduction/knowledge/iv.-reading-paths.md) for role-based reading routes.
* Read [VI. Structural Logic](/organization/introduction/knowledge/vi.-structural-logic.md) for the editorial logic behind these rules.
* Continue into [Organization](/organization/introduction/organization.md) once the reading rules are clear.
## Related pages
* Up: [Knowledge](/organization/introduction/knowledge.md)
* Across: [II. Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) · [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md) · [IV. Reading paths](/organization/introduction/knowledge/iv.-reading-paths.md)
* Counterpart: [III. Status](/organization/introduction/standardization/iii.-status.md) in the Standardization introduction, which discusses status vocabularies for standards work.
## Sources
1. Nexus constitutional directive D-V3-0005, *Product truth, claims and evidence* (ten truth dimensions, promotion rule, anti-inference). Internal record, cited by identifier.
2. Nexus constitutional directive D-V3-0002, *Directive precedence and source authority*. Internal record, cited by identifier.
3. Nexus Documentation Standard, draft of 16 October 2026: authority, status grammar, terms, tense, external frameworks and the glossary. Internal editorial standard; not published.
4. Bradner, S. (1997). *Key words for use in RFCs to Indicate Requirement Levels* (RFC 2119, BCP 14). Internet Engineering Task Force. [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc2119). Accessed 2026-10-16.
5. Leiba, B. (2017). *Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words* (RFC 8174, BCP 14). Internet Engineering Task Force. [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc8174). Accessed 2026-10-16.
6. ISO and IEC (2021). *ISO/IEC Directives, Part 2: Principles and rules for the structure and drafting of ISO and IEC documents*, ninth edition, clause on verbal forms. (URL not verified.)
7. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks and non-execution*, boundary formulas. Internal record, cited by identifier.
8. Nexus constitutional directive D-V3-0001, *Master directive V3*, epistemic constitution and shared fabrics. Internal record, cited by identifier.
9. United Nations Statistics Division. *Fundamental Principles of Official Statistics* (General Assembly resolution 68/261). [unstats.un.org](https://unstats.un.org/fpos/). Accessed 2026-10-16.
10. 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/).
11. 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/).
12. 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/).
13. 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.
14. ISO (2018). *ISO 31000:2018 Risk management: Guidelines*. Geneva: International Organization for Standardization. [iso.org/standard/65694](https://www.iso.org/standard/65694.html).
15. 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 and In brief; removed the empty "Part III" heading and fixed heading levels; renamed "Operation" to "Operations"; placed domain primacy below the order of authority; replaced "sovereign compute" wording; removed em dashes; kept all fifteen rule sections and added the numbered rule summary (RR-1 to RR-15) with sources, the mapping of stage truth to the V3 inequalities and the five-state grammar, international practice, 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/iii.-reading-rules.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.