NS-4: Structure and drafting of Nexus Standards and documents (v0.2

This revision turns NS-4 from a document template into the drafting rules of the Nexus Standards. Version 0.1 fixed the front matter that gives a document its identity and provenance, and that front matter is retained unchanged in clause 9.

What 0.1 did not do was say how a standard states a requirement, how a reader distinguishes a requirement from advice, and how a conformance claim can be tested. Mature standards bodies settled these questions long ago [ISO-D2; RFC2119; RFC8174; W3C-P]. This revision adopts their settled practice in the Nexus voice and adds what a machine-readable programme needs: a register in which every requirement can be found, tested and traced.

A standard is useful to the degree that two independent parties, reading it, reach the same judgement about whether a thing conforms. Four drafting disciplines serve that end:

• a fixed structure, so the reader knows where to look;
• a controlled vocabulary of obligation, so the reader knows what is required;
• atomic requirements, so each can be tested on its own;
• a stated test, so the judgement does not depend on who makes it.

1.1 This document specifies:

• the structure of Nexus Standards and of the specifications, policies and technical notes of the programme;
• the verbal forms that express requirements, recommendations, permissions and possibilities;
• the rules for writing requirements and for registering them;
• the front matter and structure of other documents of the ecosystem (clause 9).

1.2 It applies to every document of categories ST (standard), PO (policy), TN (technical note) and PC (proposal) drafted after its adoption, and to every existing NS document when that document is next revised. Clause 9 applies to documents of categories RP, DC, DL, WP, PP, AR, BK, CP and TH.

1.3 It does not specify the content of any standard, the development process (NS-13), or conformity assessment (NS-14 and NXS-STD-DC-000032).

The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references only the edition cited applies. For undated references the latest edition applies.

• NS-1, *The UNI and the artifact catalog*
• NS-2, *Citation and attribution*
• NS-13, *Standards development process*
• NS-14, *Conformance and crosswalk*
• registry/requirements.yaml, *Register of normative requirements* (NXS-STD-DS-000013)

3.1 requirement: an expression in the content of a document conveying objectively verifiable criteria to be fulfilled and from which no deviation is permitted if conformance with the document is to be claimed (after [ISO-D2]).

3.2 recommendation: an expression conveying that, among several possibilities, one is recommended as particularly suitable, without excluding others.

3.3 permission: an expression conveying consent or liberty to do something.

3.4 possibility: an expression conveying that something is materially, physically or causally possible.

3.5 conformance target: the kind of thing to which a requirement applies, for example a record, a dataset, a software release, an organisation or a process.

3.6 test method: the procedure by which conformance with a requirement is determined. It is one of:

• automated: by a published executable test;
• inspection: by examination of an artifact against stated criteria;
• audit: by examination of records and practice over a period;
• demonstration: by observed performance.

3.7 normative: content that a claimant satisfies in order to claim conformance. informative: content that explains, illustrates or credits, and that a claimant need not satisfy.

4.1 NS4-R5. A Nexus Standard shall contain the following elements in this order. An element marked conditional may be omitted only when it would be empty.

4.2 NS4-R6. The scope shall be written as statements of fact. It shall not contain requirements.

4.3 NS4-R7. A normative reference shall be cited by identifier and, where a dated edition is intended, by year. The text of an external document shall not be reproduced (NS14-R1).

4.4 NS4-R8. A term defined in clause 3 shall be defined once, as a substitutable phrase without an article, and shall be used with that meaning throughout the document.

4.5 Clauses are numbered in arabic numerals to at most four levels (4.2.1.3). Annexes are lettered (Annex A).

5.1 NS4-R9. The following verbal forms shall be used, and only with these meanings.

5.2 NS4-R10. The words "must", "required", "mandatory" and "is to" shall not be used to express a requirement. The word "must" may appear only to describe an external constraint, such as a law of nature or a legal duty that the document does not itself create.

5.3 The forms of clause 5.1 correspond to the keywords of [RFC2119] as clarified by [RFC8174]. A Nexus document that is also published as an internet specification may state that correspondence.

6.1 NS4-R11. Each requirement shall be atomic: it states one obligation on one conformance target.

6.2 NS4-R12. Each requirement shall be identified by a requirement identifier of the form <DOC>-R<n>, where <DOC> is the document's short code (for example NS4, IHP, NRS-C17) and <n> is a positive integer. The identifier shall be written in bold at the start of the sentence that contains the requirement. Identifiers are never reused. A withdrawn requirement keeps its identifier with status WITHDRAWN.

6.3 NS4-R13. A requirement shall be verifiable. It shall state, or refer to, the criteria by which conformance is judged. Words without a stated criterion, such as "appropriate", "adequate", "sufficient", "timely" and "state-of-the-art", shall not be used as the sole criterion of a requirement.

6.4 NS4-R14. A requirement that depends on a quantity shall state the quantity, its unit and its tolerance, in accordance with the units and measurement standard of the programme once adopted (proposed NRS-C24).

6.5 NS4-R15. Notes and examples shall be informative and shall not contain requirements.

6.6 A requirement may refer to another document. A reference to a requirement in another document cites its identifier.

7.1 NS4-R16. Every requirement of an adopted or proposed Nexus document shall be recorded in registry/requirements.yaml with the following:

• identifier;
• document UNI;
• clause;
• verbal form;
• the conformance target;
• the test method (clause 3.6);
• the reference of the executable test, where the method is automated;
• status.

7.2 NS4-R17. A requirement shall have one of the statuses PROPOSED, IN_COMMENT, ADOPTED, SUPERSEDED or WITHDRAWN. The status of a requirement shall not run ahead of the status of its document.

7.3 NS4-R18. The validator shall refuse:

• a register entry whose identifier does not appear in the clause it cites;
• a document requirement identifier that is not registered;
• an automated requirement without a test reference once the document is in comment.

7.4 The register is the source from which conformance checklists, test suites and the requirement pages of the site are generated.

8.1 NS4-R19. The conformance clause shall state:

• the conformance targets;
• any conformance levels or classes;
• the requirements each level or class comprises;
• the form of a conformance claim.

8.2 NS4-R20. A conformance claim shall cite:

• the document's UNI and version;
• the level or class claimed;
• the evidence quality level (EQL) of the supporting evidence;
• the date of the claim;
• the party making it.

A claim never states or implies certification unless an accredited certification under the conformity assessment scheme supports it.

9.1 NS4-R1. Front matter, or the first-line UNI, shall be present in every document. The record shall be minted before the document is shared.

--- uni: NXS-GRX-RP-M002-000007 version: 1.2.0 title: ... creators: [{ name: ..., orcid: ... }] publisherRef: GCRI_CANADA publicationDate: 2026-10-16 legalState: LEGAL_REVIEW_REQUIRED claimCeiling: INTEGRATED derivedFrom: [NXS-GRX-DS-M002-000003@2.0.0] conformsTo: [NS-0, NS-1, NS-2, NS-4] language: en ---

Plain Markdown without front matter starts with Nexus-UNI: <uni> on the first line (NS1-R5). HTML carries <meta name="nexus-uni"> and the Schema.org JSON-LD of the record (NS-7). Word-processor, PDF and slide formats carry the UNI on the title page and in the document properties.

9.2 Documents other than standards follow this structure:

• Summary: what the document is, for whom, its claim ceiling and its legal state, in one paragraph.
• Scope and definitions.
• Body.
• Evidence and provenance: datasets, records, models and runs, cited by UNI (NS-2).
• Limitations.
• Conformance: the standards and clauses claimed (NS-14).
• References.
• Change log.

9.3 NS4-R2. Every number, figure and map in a document shall cite its source UNI (NS-2, NS-5).

9.4 NS4-R3. The limitations section shall be present. It shall state the claim ceiling and the legal state in plain words.

9.5 NS4-R4. Versions shall be semantic in accordance with the maintenance procedure (NXS-STD-DC-000028). A changed number or conclusion is a new version with a change-log line and digest.

10.1 NS4-R21. Standards shall be written in plain, impersonal and precise language. Each sentence shall carry a single idea where a requirement is stated.

10.2 NS4-R22. Abbreviations shall be expanded at first use in each document.

10.3 NS4-R23. No document shall name, promote or disparage a for-profit company, product or mark, except where a normative reference to a published standard requires it, and then only by the standard's identifier.

10.4 NS4-R24. The English text is the reference text. Translations follow the policy on accessibility and languages (NXS-STD-PO-000002).

11.1 The conformance target of this document is a document of the categories listed in 1.2.

11.2 A document conforms to NS-4 when it satisfies NS4-R1 to NS4-R24 as they apply to its category. Requirements NS4-R5 to NS4-R20 apply to standards, policies, technical notes and proposals. Requirements NS4-R1 to NS4-R4 and NS4-R21 to NS4-R24 apply to every document.

[ISO-D2], [RFC2119], [RFC8174], [W3C-P] in governance/programme/BIBLIOGRAPHY.md.