> 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/vii.-knowledge-lifecycle.md). # VII. Knowledge Lifecycle Content classes and maturity mapped to page classes, authority levels and document status, with versions, refresh intervals and the lifecycle of a page.
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 editorial constitution (draft); Nexus constitutional directive 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 · content lifecycle. {% 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 \[5] \[6] \[7]; 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)) \[8]. The steps follow the risk-management process of ISO 31000 \[9]. [Nexus Reports](/organization/programme/reports.md) publishes quarterly country editions and an annual flagship, after review and never to a calendar; no edition is an official risk register or a rating, and no edition has been released yet \[8]. {% endhint %} ## In brief The knowledge lifecycle describes what kind of page a reader is looking at and where it stands in time. Every page declares a page class (for example doctrine, programme, platform or standard), an authority level, a document status (draft, proposed, adopted, superseded or withdrawn), a legal state, a version, an as-of date and a refresh interval. This page keeps the eight content classes and the maturity scheme used earlier and maps them to that vocabulary \[1]. ## Summary This page defines the lifecycle of Nexus content from foundational doctrine to emerging drafts and case material. It shows how content classes, maturity, and editorial tone help readers distinguish governing texts from explanatory or provisional ones. It connects directly to [VI. Structural Logic](/organization/introduction/knowledge/vi.-structural-logic.md) and [VIII. Knowledge Governance](/organization/introduction/knowledge/viii.-knowledge-governance.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 %} ## 7.1 Why content classes must be distinguished A knowledge system of this scale cannot treat every document as though it carried the same function, maturity, or institutional force. When all content is presented as if it were equally authoritative, readers lose the ability to distinguish between what defines the architecture, what explains it, what applies it, what tests it, and what merely illustrates it. In time, this produces not only confusion of reading but distortion of action. Contributors begin to draft as if every note were a doctrine paper. Readers begin to cite contextual materials as though they were foundational instruments. Pilot documents begin to borrow the tone of settled architecture. Summaries begin to substitute for governing texts. For that reason, the Nexus knowledge system requires a clear classification of content. Content classes are not a bureaucratic ornament. They are a way of preserving maturity truth across the corpus. They make visible the difference between what is constitutive, what is operational, what is participatory, what is canonical, what is derivative, and what is provisional. They allow the reader to understand not only what a text says, but what kind of authority that text carries within the system. In a system that spans constitutional doctrine, governance, trust architecture, routeability logic, observability, infrastructure intended for national deployment, guild participation, and real-world realization, such distinction is indispensable. Without it, the knowledge base becomes rhetorically rich but structurally weak. With it, the system becomes legible, auditable, and governable even as it grows. ## 7.2 The foundational class The highest class of content on this site is the **foundational class**. It is highest among pages only; every binding record (law, executed instruments, the Native Master, the V3 constitutional set and the registers) ranks above it ([VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md)). Foundational content defines the architecture itself. It states what the system is, what its primary institutions are, what its governing doctrines are, what rules bind interpretation, and what must remain invariant across time, geography, and implementation context. Foundational content typically includes: * constitutional and institutional architecture; * governance-bearing frameworks of permanent standing; * canonical standards, semantic, protocol, and trust architecture; * routeability grammar and core reading rules; * realization doctrines where they define the permanent form of the system rather than a contingent deployment. Such material should be written with particular discipline. It should avoid unnecessary narrative inflation, avoid casual terminology, and avoid dependency on temporary examples for its basic intelligibility. Its purpose is not merely to inform. Its purpose is to anchor. Foundational content must also exhibit high stability. This does not mean it can never change. It means it should change only deliberately, with traceable reasoning, clear supersession discipline, and full awareness of downstream effects. The more foundational the content, the stronger the expectation that revisions occur rarely and only with structural care. ## 7.3 The governing operational class Below foundational content sits the **governing operational class**. This class does not define the constitutional identity of the system, but it does define how the system behaves in practice. It includes frameworks, mechanisms, reporting rules, workflow logic, participation procedures, publishing rules, review paths, and other materials that structure the ongoing life of the architecture. Operational content is not secondary in importance. It is secondary only in the sense that it depends on foundational content for its ultimate meaning. A mechanism cannot outrank the architecture that authorizes it. A workflow cannot redefine the institutional order it serves. But a system of this scale remains credible only if its operational content is as disciplined as its constitutional content. Operational content must therefore be: * precise enough to govern practice; * flexible enough to support bounded adaptation; * traceable enough to support review and correction; * and stable enough to prevent procedural drift. It should be written in a way that permits action without inviting constitutional reinterpretation. Its tone should be functional, disciplined, and transparent about scope and limits. ## 7.4 The cooperative and participatory class A separate and equally important content class is the **cooperative and participatory class**. This includes guild structures, councils, memberships, ecosystem interfaces, contribution pathways, chapter logic, partner structures, and role-specific participation documents. This class exists because participation in Nexus is never merely social. It is structurally governed. The knowledge base must therefore give contributors, members, and ecosystem participants clear pathways into the architecture without permitting informal participation to become a source of hidden authority. Participatory content differs from both foundational and operational content in one key respect: it must carry strong role clarity while also remaining welcoming, legible, and mobilizing. It must be rigorous without becoming closed. It must be open to contribution while being explicit about boundaries, safeguards, and the difference between participation, competence, standing, and institutional authority. Documents in this class should make several things visible at once: * how a reader may participate; * under what conditions a contribution becomes part of the system; * what rights and responsibilities accompany membership or role; * what safeguards apply in sensitive or consequential contexts; * and where participation ends and canonical authority begins. This content class is especially important because many ecosystem failures begin with poorly specified participation. Nexus must do the opposite: it must make participation a source of strength by making it governed, legible, and bounded. ## 7.5 The canonical technical and standards class The **canonical technical and standards class** includes materials that define the semantic, protocol, trust, routeability, and conformance architecture of the system. This content is not merely technical in the engineering sense. It is technical in the institutional sense: it defines the architecture through which meaning, interoperability, attestation, and bounded consequence travel. This class must be treated with unusual care because it is often the most vulnerable to two opposite distortions. One distortion is excessive abstraction, in which the material becomes conceptually elegant but practically detached. The other is excessive implementation bias, in which the material becomes indistinguishable from one deployment path, one platform pattern, or one temporary design preference. Canonical technical content must avoid both. It must remain general enough to govern the architecture across implementations and specific enough to remain operationally meaningful. It must preserve invariants while permitting bounded adaptation. It must define trust and protocol logic without allowing implementation convenience to become canonical doctrine by stealth. This is why the standards-bearing class should always be written with explicit attention to: * semantic precision; * scope and bounded authority; * conformance implications; * interoperability and anti-fork discipline; * and the distinction between reference architecture and local realization. ## 7.6 The realization and deployment class The **realization and deployment class** includes materials that show how the system becomes materially, geographically, institutionally, and operationally real. This includes compute infrastructure, observatory nodes (NXS-OPS), consortium architectures, programs, studios, accelerators, implementation pathways, host models, and partner ecosystems. This class has a special importance because it is the most visible proof that Nexus is more than theory. Yet it also carries special risk. Realization documents can easily begin to sound as though they define the whole system. Deployment can acquire rhetorical dominance simply because it looks concrete. The knowledge architecture must therefore ensure that realization content remains exact about its own status: highly consequential, often urgent, deeply practical, but still downstream of constitutional, operational, cooperative, and standards-bearing authority. Documents in this class should be written so that they: * demonstrate seriousness of implementation; * make infrastructure, deployment, and realization pathways legible; * preserve stage truth around readiness, routeability, and execution boundaries; * show the relation between local context and common rail; * and remain explicit about supportability, lifecycle, and host truth. The stronger realization content becomes, the more important this discipline is. Mature deployment writing does not exaggerate its authority. It demonstrates its fidelity to the architecture that authorizes it. ## 7.7 The derivative explanatory class A healthy knowledge system must also include a **derivative explanatory class**. These are materials designed to make the architecture accessible to specific audiences without restating the whole architecture in full. They may include introductory overviews, audience-specific summaries, public-facing explainers, onboarding documents, high-level briefs, orientation notes, diagrams, and educational pages. This class is legitimate and necessary. Not every reader can or should begin with the most dense foundational instruments. A public-interest reader may need a high-level explanation of guilds. A policymaker may need a brief on compute infrastructure and observatory nodes. A partner may need an introduction to the five-domain architecture. A new member may need a simplified explanation of contribution pathways. But derivative explanatory content must never be mistaken for canonical authority. Its task is translation, not reinterpretation. It should make the architecture more understandable, not more pliable. It should simplify without flattening. It should orient without overclaiming. It should always remain traceable back to the domain whose meaning it is summarizing. A mature knowledge system makes such derivative content strong, elegant, and readable, but never lets it become structurally unmoored. ## 7.8 The illustrative and case-based class Another legitimate content class is the **illustrative and case-based class**. This includes examples, pilot descriptions, use cases, case studies, narratives of practice, sector illustrations, deployment snapshots, and comparative examples. Illustrative content plays an essential role. It allows the architecture to be seen in motion. It helps readers understand how abstract concepts appear in context. It provides evidence that the system can be applied in real conditions and not merely described in ideal terms. Yet illustration must remain illustration. A case study may reveal much, but it does not by itself redefine doctrine. A pilot may demonstrate possibility, but it does not by itself create maturity. A use case may be compelling, but it does not by itself become canonical architecture. The knowledge base must preserve this distinction clearly. The purpose of this class is to illuminate, test, and enrich understanding. It is not to substitute examples for principles or implementations for architecture. ## 7.9 The provisional and emerging class A serious knowledge system must allow room for thinking that is still forming. Nexus therefore requires a **provisional and emerging class** of content: materials that are exploratory, in development, under review, or intentionally marked as not yet mature enough to be treated as settled. This class is especially important in a system operating at the frontier of governance, standards, infrastructure, and systemic risk architecture. New ideas, emerging design patterns, pilot lessons, open questions, and proposed structures must have a place in the knowledge system. But that place must not blur with settled doctrine. The provisional class therefore exists to give innovation a disciplined home. It allows experimental thinking without forcing it prematurely into the foundational or canonical layer. It preserves intellectual freedom while protecting the integrity of the system’s mature architecture. To function properly, provisional content should be clearly marked by: * its status; * the reason it remains provisional; * the pathway by which it might mature; * and the limits on reliance while that maturity is incomplete. This is one of the ways Nexus can remain both innovative and trustworthy. ## 7.10 Content maturity and stage discipline The distinction among content classes is closely related to the distinction among maturity stages. Not every text is simply “published” or “unpublished.” In a system like Nexus, content has maturity. At the highest level, content may be: * conceptual; * structured but not yet settled; * reviewed and operationally usable; * canonical or governing; * or superseded and retained for historical integrity. These maturities should not be treated casually. A concept note is not a framework. A reviewed operational guide is not a constitutional instrument. A public explainer is not a canonical standards paper. A pilot case is not a mature realization doctrine. The more clearly maturity is signaled, the more safely the system can scale. This is not merely a convenience for editors. It is part of stage truth itself. The reader should be able to know not only what a text says, but how mature its role is within the system. Section 7.17 maps these maturities to the document status shown in every document record. ## 7.11 Document lifecycle within the knowledge base Every content class in Nexus exists within a lifecycle. A mature knowledge system does not treat documents as static objects. It treats them as artifacts with states, histories, and responsibilities. A document may begin as an exploratory note. It may then be developed into a structured draft. It may undergo review and become a domain-level document. It may later be elevated into a foundational or canonical role. It may then be refined, narrowed, or superseded. Throughout, its lineage should remain traceable. This lifecycle logic matters because many knowledge systems fail by allowing documents to accumulate without state awareness. Old drafts remain visible as though current. New summaries outshine governing texts. Exploratory materials linger without status. Contradictory versions coexist. Nexus must instead ensure that each document’s place in time is as clear as its place in structure. This means lifecycle should always be visible at the level of: * status; * authority; * maturity; * supersession; * and continuing relevance. ## 7.12 The editorial logic of tone and form Different content classes require different tones and forms. Foundational and canonical materials should be written with high precision, structural clarity, and minimal rhetorical excess. Their task is definition, anchoring, and continuity. Operational materials should be written with practical clarity, procedural transparency, and traceable logic. Their task is working discipline. Participatory materials should be written with openness, structure, and safeguards-awareness. Their task is governed invitation. Realization materials should be written with material seriousness, institutional realism, and careful attention to bounded claims. Their task is implementation without overstatement. Derivative and explanatory materials should be written with elegance, accessibility, and fidelity to the authoritative source. Their task is translation without distortion. This editorial differentiation is not cosmetic. It helps the reader recognize what kind of content is being encountered and what kind of authority it carries. ## 7.13 The relationship between classes and domains Although content classes and primary domains are related, they are not identical. Every domain may contain more than one class of content. **Organization** contains foundational and explanatory content.\ **Operations** contains governing operational and derivative content.\ **Cooperation** contains participatory, explanatory, and contextual content.\ **Standardization** contains canonical, technical, and controlled explanatory content.\ **Acceleration** contains realization, operational, illustrative, and contextual content. This is why the knowledge architecture requires both domain logic and class logic. Domains tell the reader where a concept belongs. Classes tell the reader what kind of authority and maturity the specific document carries within that domain. A document’s location tells one story. Its class tells another. Both are necessary for serious interpretation. ## 7.14 Failure modes prevented by content-class discipline The discipline of content classes prevents several failure modes that become more likely as the system grows. It prevents **concept notes from hardening prematurely into doctrine**.\ It prevents **public explainers from being mistaken for authoritative sources**.\ It prevents **realization cases from being over-read as canonical architecture**.\ It prevents **operational documents from silently acquiring constitutional force**.\ It prevents **temporary material from being mistaken for stable structure**. In other words, it protects the reader from reading every page as if it were the same kind of page. That protection is essential in a system whose knowledge base must serve many audiences at once without sacrificing maturity truth. ## 7.15 Final statement on content classes and editorial logic A serious knowledge system must know not only what it says, but what kind of document is saying it. That is the function of content classes. They give the reader a disciplined way to distinguish foundational from derivative, canonical from contextual, settled from emerging, governing from illustrative, and durable from time-bound. They make the knowledge base more legible, more trustworthy, and more resilient under growth. Editorial logic then gives those classes their expression. It ensures that tone, form, density, structure, and authority remain aligned. It helps the reader recognize whether a text is anchoring the architecture, governing practice, structuring participation, defining standards, enabling realization, translating complexity, or illustrating use. Together, content classes and editorial logic ensure that the knowledge base remains not only comprehensive but intelligible, and not only intelligible but structurally trustworthy. ## 7.16 Page classes and the crosswalk from content classes The site now uses ten page classes, each with a template \[1]: section landing; constitutional instrument; doctrine or framework; programme or campaign; platform or technical system; standard specification; guild, consortium or community; report or publication; glossary or reference; historical or superseded. The eight content classes of sections 7.2 to 7.9 map to them as follows. | Content class (this page) | Current page class | Usual authority level | Note | | --------------------------------------- | ---------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- | | Foundational (7.2) | Constitutional instrument, or doctrine or framework | L2 (canon projection), L3 or L4 (instrument), L5 (doctrine) | An instrument needs an adoption record to be L3; most are L4 drafts | | Governing operational (7.3) | Programme or campaign; doctrine or framework | L5, or L4 where written as an instrument | Programme status (exploring, forming, constituted, active, paused, archived) is shown with its evidence | | Cooperative and participatory (7.4) | Guild, consortium or community | L5, or L4 for membership terms | Participation routes and what they do not confer sit side by side | | Canonical technical and standards (7.5) | Standard specification; platform or technical system | L2 or L5 | Platform pages carry the status note | | Realization and deployment (7.6) | Platform or technical system; programme or campaign | L5 | A target is never written as a running service | | Derivative explanatory (7.7) | Section landing; glossary or reference | L5 | Translation of meaning, never reinterpretation | | Illustrative and case-based (7.8) | Report or publication; examples inside other classes | L5 | Examples are labelled illustrative | | Provisional and emerging (7.9) | Not a class: any class at status DRAFT or PROPOSED | L5 | Research constructs (for example distributed-ledger ideas) are framed as research outlook unless a repository record shows otherwise \[1] | *Table 1. Crosswalk from the content classes to the page classes and authority levels. Source: the documentation standard \[1].* ## 7.17 Document status and the other record fields | Field | Values | Rule | | --------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------ | | Document status | DRAFT · PROPOSED · ADOPTED · SUPERSEDED · WITHDRAWN | ADOPTED only with an adoption record; SUPERSEDED with a link to the successor | | Legal state | Legal review required · Approved · Restricted · Prohibited | Legal review required by default; Approved only with a counsel record; agents never set Approved | | Version | YYYY.MM.DD-rN | Date of the change and revision number that day | | As of | ISO date | The date to which facts and policies are current | | Refresh | Interval by class (Table 4) | The page is reviewed at or before this interval | | Owner | Accountable desk or institutional role | Left blank ("not yet named") until the owner names it; never filled from memory | | UNI | Identifier or "pending" | Serials are allocated through the catalogue, never typed or guessed | *Table 2. Record fields. Source: the documentation standard \[1].* The maturity scheme of section 7.10 maps to document status as follows. | Maturity (7.10) | Document status | Condition | | ------------------------------------------------ | --------------- | ------------------------------------------------------------------- | | Conceptual | DRAFT | None | | Structured but not yet settled | DRAFT | None | | Reviewed and operationally usable | PROPOSED | Review recorded in the editorial record | | Canonical or governing | ADOPTED | Only where an adoption record exists; otherwise it remains PROPOSED | | Superseded and retained for historical integrity | SUPERSEDED | Link to the successor; text kept | *Table 3. Maturity mapped to document status \[1].* **Document status is about the page, not about the thing it describes.** A page about a platform capability can be ADOPTED while the capability itself is only a target; capability status is stated separately, per dimension ([III. Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md)) \[2]. ## 7.18 The lifecycle of a page Section 7.11 describes the lifecycle in prose. The figure shows the status transitions.
Document status transitions for a page. DRAFT leads to PROPOSED, then to an adoption-record gate; only with a record does the page become ADOPTED, otherwise it stays PROPOSED. ADOPTED may become SUPERSEDED. DRAFT, PROPOSED and ADOPTED may each become WITHDRAWN. Superseded and withdrawn pages are kept as history.

Figure 1. Document status transitions for a page. Design of the process, not a record of any page's history; no page in this section has reached ADOPTED. Source: the documentation standard, as of 2026-10-16.

Text description of Figure 1 The left column is the status path: a page starts as DRAFT and may become PROPOSED once review is recorded. A PROPOSED page passes a gate, "Adoption record?": it becomes ADOPTED only if an adoption record exists; otherwise it stays PROPOSED. In the middle column, an ADOPTED page may later become SUPERSEDED, with a link to its successor and its text kept; a page at DRAFT, PROPOSED or ADOPTED may become WITHDRAWN. On the right, superseded and withdrawn pages are kept as history rather than deleted, so earlier versions remain traceable.
Every substantive change adds an entry to the page's change log. A correction creates a recorded new version, never a silent edit \[1]\[3]. This follows the long-standing publishing practice of a "version of record", in which later changes are issued as identified corrections rather than unmarked replacements \[4]. ## 7.19 Refresh intervals | Kind of page | Refresh interval | | ----------------------------------- | ---------------- | | Policy pages and emerging topics | 90 to 120 days | | Foundations, including this section | 180 days | | Practice pages | 270 days | | Constitutional records | On change only | *Table 4. Refresh intervals by kind of page. A page is also refreshed when a cited source issues a new edition or a correction is accepted. Source: the documentation standard and the editorial constitution draft \[1]\[3].* A refresh resets the as-of date, re-checks every source and keeps the change history. ## 7.20 Editorial workflow states Separate from document status, the editorial constitution draft defines workflow states for producing a page: planned, claimed, researched, drafted, fact-checked, edited, visuals ready, search ready, legally cleared, approved, staged, published, refresh due and withdrawn \[3]. An AI agent never moves its own draft past the drafted state; only a named human approver marks a page approved \[3]. The review chain is described in [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md). ## 7.21 Key terms | Term | Meaning on this site | | ---------------- | ----------------------------------------------------------------------------------------------------------------------- | | Page class | The kind of document a page is, each with a template | | Authority level | L0 to L6, the standing of a page ([VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md)) | | Document status | Where a page stands in its lifecycle: DRAFT, PROPOSED, ADOPTED, SUPERSEDED or WITHDRAWN | | Legal state | Whether legal review is required, approved, restricted or prohibited | | Refresh interval | The maximum time before a page is reviewed again | ## Next steps * Read [VIII. Knowledge Governance](/organization/introduction/knowledge/viii.-knowledge-governance.md) for the stewardship model behind the lifecycle. * Read [X. Knowledge Base Integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md) for trust and public meaning. * Read [XI. Final Orientation](/organization/introduction/knowledge/xi.-final-orientation.md) for the final guided entry into the five domains. ## Related pages * Up: [Knowledge](/organization/introduction/knowledge.md) * Across: [VI. Structural logic](/organization/introduction/knowledge/vi.-structural-logic.md) · [VIII. Knowledge governance](/organization/introduction/knowledge/viii.-knowledge-governance.md) · [X. Knowledge base integrity](/organization/introduction/knowledge/x.-knowledge-base-integrity.md) * Counterpart: [III. Status](/organization/introduction/standardization/iii.-status.md) in the Standardization introduction, which covers lifecycle states for standards. ## Sources 1. Nexus Documentation Standard, draft of 16 October 2026 (page classes and authority levels, document lifecycle, templates, research constructs). Internal editorial standard; not published. 2. Nexus constitutional directive D-V3-0005, *Product truth, claims and evidence*. Internal record, cited by identifier. 3. Nexus editorial constitution and editorial policy, draft (workflow states, self-review ceiling, approval, freshness, corrections). Internal draft; not published. 4. National Information Standards Organization (2008). *NISO RP-8-2008, Journal Article Versions (JAV): Recommendations of the NISO/ALPSP JAV Technical Working Group*. [niso.org](https://www.niso.org/publications/niso-rp-8-2008-jav). Accessed 2026-10-16. 5. 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/). 6. 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/). 7. 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/). 8. 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. 9. ISO (2018). *ISO 31000:2018 Risk management: Guidelines*. Geneva: International Organization for Standardization. [iso.org/standard/65694](https://www.iso.org/standard/65694.html). ## 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 VII" heading and fixed heading levels; renamed "Operation" to "Operations"; placed the foundational class below binding records; replaced "civilizational" and "sovereign compute" wording; removed em dashes; kept all eight content classes and added the crosswalk to the documentation standard's page classes and authority levels, the record fields, the maturity-to-status mapping, the lifecycle figure, refresh intervals, workflow states, 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/vii.-knowledge-lifecycle.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.