> 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/standardization/iii.-status.md). # III. Status How status is stated in the Nexus programme: per dimension, in five public states with their own evidence, under a claim ceiling, and never as one merged score. **Where this fits:** all six sectors · the [Nexus Standards pillar](/organization/programme/standards.md) and the [Labs](/organization/programme/labs.md) and [Foundry](/organization/programme/foundry.md) pillars that feed it · GCRI Canada as Secretariat, the Global Standards Council and each country's [National Standards Council](/organization/governance-in-operation/national-standards-council.md) · the Correction, Docket review and Renewal phases of [the programme year](/organization/programme/the-programme-year.md) · introduction to the deep doctrine. Canonical homes: [The Model](/organization/model.md) · [Nexus Standards](/organization/standards.md) · [Systems](/organization/systems.md).
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 constitutional directives D-V3-0005, D-V3-0004 and D-V3-0001; capability ledger, claim registry and release hold policy; [Nexus Standards](/organization/institutions/nexus-standards.md) (PROPOSED) [NS-10](https://nexustandards.com/standards/ns-10/) and NS-11 (proposed); the Nexus model and the Nexus Consortium model as published on the GCRI, GRF and GRA sites; Nexus Standards as published at nexustandards.com | | **Corrections** | Public corrections route to be announced; corrections are published as new dated versions. |
## In brief Status is a recorded, dated and scoped statement of what a subject has evidence for. In this documentation it is always stated per dimension, in five public states: target, implemented, verified, observed and accepted. Each state needs its own evidence, and where none exists the honest entry is "No record". No page merges these states into one readiness label, score or percentage, and no status is inferred from a default, a route, a demonstration or an assertion \[1]\[4]. ## Current position (21 October 2026) This section brings the page up to date with the published sites, the Nexus Standards and the owner's rulings of October 2026. Where the older text below differs, this section and the canonical pages it links govern. Nexus Standards is now published at [nexustandards.com](https://nexustandards.com/standards/): the foundation standards [NS-0](https://nexustandards.com/standards/ns-0/) to [NS-16](https://nexustandards.com/standards/ns-16/) and [NS-3b](https://nexustandards.com/standards/ns-3b/), the Nexus Indicator Standard NIS-1, and 348 Nexus Risk Standards in 15 series, of which the hazard family standards of NHS-1 are one. Every standard carries the status PROPOSED and a legal-review flag; none is adopted, and a UNI never certifies anything \[11]\[12]. Governance sits with a Global Standards Council, Technical Management Divisions and Technical Committees, with GCRI Canada as Secretariat and publisher of record and a National Standards Council in each country that forms one \[13]. National adoption is final: a country may adopt a standard as is, adopt it with a profile (NS-16), adapt it, or reference it only, and no global body holds a veto \[14]. Status on this page and status in the programme now use one public vocabulary. Programmes move through seven states, Exploration, In formation, Constituted, Active programme, Paused, Closed and Historical record, and the service level today is R0 \[15]. Standards carry registry statuses (OPEN, PROPOSED, PLANNED); conformance follows NS-14, whose Conformance and Assurance Panel issues no certification, accreditation or mark until a scheme is adopted, and verification follows NS-11 \[16]\[17]. A validator report is "evidence for review, not a conformance claim" \[18]. Earlier text on this page described the Nexus Standards as a draft with no publisher of record; that is superseded \[13]. **Status.** Every programme is in formation and the current service level is R0, information and enquiries; no edition of [Nexus Reports](/organization/programme/reports.md) has been released and no [Risk Academy](/organization/programme/academy.md) credential has been issued \[15]\[19]. ## Status and scope {% hint style="info" %} **Status.** System capabilities described on this page are target architecture under development. Nothing here states that a capability is in production use, certified or offered as a service. {% endhint %} **Systems named on this page.** Systems are named by their Nexus Standards display codes. Each is introduced once below; later mentions use the code alone. * [NXS-NSF](/organization/systems/nxs-nsf.md), the trust, sovereignty and assurance plane for identity, policy gates and access decisions. * [NXS-RLS](/organization/systems/nxs-rls.md), the technical rails and protocol infrastructure for protocol-governed work across institutions. * [NXS-NXQ](/organization/systems/nxs-nxq.md), the software, capability and agent fabric for registries, licensing, APIs and connectors. This page is explanatory (authority level L5). The five-state grammar used here is the interim public grammar of the Nexus Documentation Standard; its final wording, and the vocabulary of evidence labels for published findings, await owner decision (OQ-16) \[5]. The numbered sections from 3.1 onwards keep the earlier doctrine of this page, including its descriptive state lists for nodes, hosts, providers, Marketplace objects, Digital Public Goods, Foundry and Studio objects. Those lists describe lifecycle and claim vocabulary for each kind of subject; they are not public status states, and Table 6 maps each of them to the five-state grammar. ### Retired labels on this page {% hint style="info" %} **Retired labels.** This page's earlier text referred to a "competence-cell role". The label "competence cells" predates the current NNC, NLC and NWG council vocabulary, and its mapping to that vocabulary awaits owner decision (OQ-14). It is not used here as a current body. {% endhint %} ## Summary This page defines the status layer of Nexus Standardization. If **II. Ontology** defines the meaning infrastructure of Nexus, then **III. Status** explains how controlled meaning becomes earned, reviewed, recorded, bounded, and portable institutional status. Status is the discipline through which Nexus distinguishes what is merely named from what has been reviewed; what is described from what is recognized; what is compatible from what is conformant; what is supported from what is comparable; what is hosted from what is mature; what is public-safe from what is public-authority adopted; what is finance-readable from what is financed; and what is visible from what is valid. This page treats the status layer as the architecture of earned status, controlled comparability, and bounded portability. Nexus must distinguish description, review, testing, recognition, comparability, interoperability, and portability, and conformance, recognition, and interoperability profiles are the mechanisms through which controlled meaning becomes earned status. The binding rule is the V3 separation of truth dimensions, set out in the section that follows this summary \[1]. Status is therefore one of the most important trust-bearing layers of Nexus. Ontology tells Nexus what something means. Status tells Nexus what that thing has earned. Registry records that status. Protocol may express it technically. Claims discipline limits what may be said about it. Correctionability ensures that status can be narrowed, superseded, corrected, or retired when reality changes. In Nexus, status is not inferred. Status is profiled, reviewed, recorded, scoped, and bounded. ## Definition and canon alignment The numbered sections from 3.1 onwards keep the full doctrine of this page. This section states the definition precisely and sets out the binding V3 status model that the doctrine must be read against. ### Definition A **status** is a statement that a named subject holds a named state, in a named dimension, within a stated scope, on the strength of cited evidence, as of a date. It has an issuer (the system or body that recorded it), a validity window and a correction path. A status without scope, evidence or date is not a status in this sense; it is a description. Status answers one question: what has this subject earned, and how do we know? It does not answer what the subject means (that is [II. Ontology](/organization/introduction/standardization/ii.-ontology.md)), where the statement is kept (that is [IV. Registry](/organization/introduction/standardization/iv.-registry.md)) or what may be done because of it (that is [V. Protocol](/organization/introduction/standardization/v.-protocol.md)). ### Why status needs its own discipline The V3 constitution puts the core rule in four inequalities, repeated as constitutional invariants: "Target definition != implementation. Implementation != verification. Verification != observation. Observation != authority acceptance" \[1]\[3]. Each inequality closes a common route to overclaim: * a design document described as a working system; * a working system described as tested; * a tested system described as operating; * an operating system described as accepted by an authority. For a minister's adviser, a supervisor or a credit committee, these are the distinctions that matter most and are most often blurred. A single traffic light or percentage hides exactly the information they need. That is why the constitution forbids it: "No single global readiness percentage may collapse independent V3 truth dimensions" \[3]. ### The five-state public grammar | Public state | For technical subjects (systems, fabrics, capabilities) | For institutional and programme subjects | Evidence that must be cited | | --------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------ | | **Target** | Defined by a V3 directive or adopted architecture decision | Defined in a charter, bylaw, doctrine or programme design | Directive id or instrument page | | **Implemented** | Implementation state in the capability ledger (for example implemented or integrated) | Instrument adopted; entity constituted; programme constituted | Dated ledger entry; adoption or formation record | | **Verified** | Verification state in the capability ledger (for example tested or integration-verified) | Register verification state (an owner confirmation is an owner statement, not verification) | Ledger entry; register field | | **Observed** | Operational state in the capability ledger (observed in a laboratory setting at most today) | Programme active, with a dated, published record | Observation receipt; published record | | **Accepted** | Authority-accepted evidence level | Recognition or acceptance by a competent external authority | The external authority's own record | *Table 1. The five public states and the evidence each requires. Where no record exists the cell says "No record". Source: Nexus Documentation Standard, projecting D-V3-0005 and the constitutional truth inequalities \[1]\[3]\[5].* ### What the five states project The five public states are a reading aid over a richer record. D-V3-0005 defines ten independent dimensions: implementation, service, source, persistence, policy, verification, operational, release, claim and correction state. "These dimensions SHALL remain independent in APIs and evidence. No constructor, UI default, manifest presence, route existence, fixture, seed, successful unit test or generated catalog may promote them implicitly" \[1]. The promotion rule is that "a higher state requires evidence specific to that dimension". Integration tests cannot establish production observation; deployment telemetry cannot establish independent assessment; "a certificate cannot retroactively prove scientific validity outside its scope" \[1]. D-V3-0005 also defines evidence levels (from documented through tested, observed, independently assessed and authority accepted to certified), each separately scoped, time-bounded and source-linked \[1]. Those levels describe evidence, not public labels; the public vocabulary of evidence labels is an open owner question (OQ-16) \[5].
The five public states, Target, Implemented, Verified, Observed and Accepted, as separate evidence gates. Each state past Target links to its own evidence: ledger or adoption record, test or register, observation receipt, authority record. Defaults and fixtures never promote a state; correction can narrow or withdraw any state.

Figure 1. The five public states as separate evidence gates. Each state past Target is linked to the evidence it needs; nothing is promoted by inference, and correction can narrow any state. This is a reading model, not a ladder that every subject climbs. Source: D-V3-0005; Nexus Documentation Standard, as of 2026-10-16.

Text description of Figure 1 The five public states stand in the middle column: Target, Implemented, Verified, Observed and Accepted. Arrows run down the column from Target to Accepted in reading order; no arrow promotes a subject by itself. Target is defined by a V3 directive, an adopted architecture decision or a programme design. Each later state needs its own record, shown in the right column with a line labelled "needs": Implemented needs a ledger or adoption record; Verified needs test or register evidence; Observed needs an observation receipt; Accepted needs the competent authority's own record. On the left, defaults, routes, fixtures, seeds and demonstrations are marked as not evidence: a line labelled "never" shows that they never promote a subject to any state. Correction, also on the left, narrows or withdraws a state; the line is drawn to Accepted, and the card notes that correction applies to any state.
### Claim ceilings and the release hold A status statement also sits under a **claim ceiling**: the strongest claim the attached evidence allows. The claim registry permits, where evidence is attached, only four claims: integrated, observed in a laboratory setting, verified against test fixtures, and implementation complete. "Integrated" is the default for connected parts of the platform \[2]. The release hold has been active since 2026-07-21. While it is active, the registry blocks Controlled GA, Controlled Release, Production Observed and Production Proven claims, and no binding has yet been observed in use by an institution \[2]. Every claim in public text must also resolve to a claim record "with wording, scope, permitted channels, evidence references, expiry, owner, reviewer and correction/withdrawal path" (D-V3-0005) \[1]. The anti-inference rule completes the picture: "No UI may infer READY, LIVE, SECURE, COMPLIANT, CONNECTED or VERIFIED from constructor defaults, a successful health endpoint, a route registration, a fixture, a seed, a static manifest or an agent assertion" (D-V3-0005) \[1]. This page applies the same rule to prose. ### Status matrix for the subjects of this section Table 2 applies the grammar to the main subjects described in this Standardization introduction. It is the honest state of the record on 2026-10-16. | Subject | Target | Implemented | Verified | Observed | Accepted | | ------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | ------------------------------------------- | ---------------------------- | --------- | | Ontology Fabric | D-V3-0001 §3 | No record. The ledger entry is declared only, which is not implementation evidence | No record (not yet tested) | No record (not yet observed) | No record | | UNI Identifier Fabric | D-V3-0001 §3 | No record. The ledger entry is declared only | No record (not yet tested) | No record (not yet observed) | No record | | Evidence and Receipt Fabric | D-V3-0001 §3 | No record. The ledger entry is declared only | No record (not yet tested) | No record (not yet observed) | No record | | NXS-NSF | D-V3-0003 | No record. The ledger entry is declared only | No record (not yet tested) | No record (not yet observed) | No record | | NXS-RLS | D-V3-0003 | No record. The ledger entry is declared only | No record (not yet tested) | No record (not yet observed) | No record | | Nexus Standards (NS family) | Proposed only: a draft in which every document is proposed; not a recorded target | Built only in draft form; no record in the recorded architecture | No record | No record | No record | | Conformance levels verified, attested, recognized | Proposed only: draft NS-11 | In the draft only the verified level is computable; attested and recognized are not issued | No record | No record | No record | | NIS-1 indicator standard | Recorded document; a draft that requires expert review | Not assessed on this page | Expert review required; no record of review | No record | No record | *Table 2. Five-state status of the subjects of this section. Ledger states are quoted as last evaluated on 2026-08-26, which may be out of date (open question OQ-17). Claim ceiling: no claim beyond a declared target is supported for these subjects. Sources: capability ledger \[4]; D-V3-0001; D-V3-0003; Nexus Standards (PROPOSED) \[6]; NIS-1 \[7].* ### Conformance language The Nexus Standards (PROPOSED) define three conformance levels for evaluating a subject against a policy of clauses (NS-10 and NS-11, proposed) \[6]: | Level | Meaning in the draft | State in the draft | | ---------- | ------------------------------------------------------------------------- | ------------------ | | Verified | Computed: an evaluator ran the checks and recorded the outcome | Computable | | Attested | Signed: an identified party signed the evaluation record | Not issued | | Recognized | A recognition decision by NXS-NSF, the system that holds policy decisions | Not issued | *Table 3. Draft conformance levels. Source: Nexus Standards (PROPOSED) NS-11 \[6].* An attestation in the draft is a record of what an evaluator found under a verified mandate at one instant. It is evidence, not a certificate, and no certificate is issued \[6]. The international conformity assessment vocabulary draws the same line between verification, attestation and certification, where certification is a third-party attestation (ISO/IEC 17000) \[8]. The V3 boundary formula is shorter: "Verification is not certification" (D-V3-0004) \[3]. Two consequences follow for every page on this site: 1. Words such as "certified", "certificate" or "accredited" are not used for any Nexus result, unless a competent external body has issued one and its record is cited. 2. A conformance statement names the subject, the policy and its version, the level, the date, the evaluator, the evidence and the limits. "Conformant" without those is not used. ### Writing a status statement | Element | Example of the form (illustrative) | | ------------------- | --------------------------------------------------------------- | | Subject | The Ontology Fabric | | Dimension and state | Implemented: No record | | Evidence | Capability ledger entry for the Ontology Fabric (declared only) | | As of | Ledger last evaluated on 2026-08-26 | | Scope | System target architecture; no deployment profile | | Claim ceiling | No claim beyond a declared target | | Issuer | Capability ledger maintainers (not this page) | | Correction path | Ledger re-evaluation; page correction log | *Table 4. Elements of a status statement, illustrated with a row from Table 2.* ### Lifecycle and correction vocabularies Status changes over time, and the record must show how. Three lifecycle vocabularies are in use, each for a different kind of subject: | Kind of subject | States | Source | | ---------------------------- | ----------------------------------------------------------------------------------------- | ----------------------------------------------------------------- | | Documents and standards | draft, proposed, adopted (only with a recorded authority decision), superseded, withdrawn | Nexus Documentation Standard; Nexus Standards (PROPOSED) \[5]\[6] | | Programmes | exploring, forming, constituted, active, paused, archived | Site narrative draft \[5] | | Correction state of a record | current, disputed, superseded, withdrawn, recalled | D-V3-0005 correction states \[1] | *Table 5. Lifecycle vocabularies by kind of subject.* The correction constitution governs every change: "Correction outranks continuity", the prior record is preserved, dependants are traced and replacement products are issued; last-write-wins is prohibited for identity, scientific truth, legal authority, policy, financial rights, warning authority and signed evidence (D-V3-0001 §13) \[9]. ### How the earlier state lists map to the grammar The numbered sections below define several ladders and state sets: conformance levels from awareness to higher-assurance conformance (3.14); evidence quality ladders from unverified input to high-assurance evidence (3.16); pathway and node states such as supported, hosted, comparable, corridor-integrated and mature (3.21, 3.22); and twelve Digital Public Good states (3.26). Read as public status, they would compete with each other and with the V3 dimensions \[5]. They are kept as descriptive vocabularies for each kind of subject. Table 6 shows where each idea is stated as public status; the mapping is a proposal for owner review. | Earlier vocabulary | Where the idea is stated as public status | | -------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | Conformance levels (alignment, tested, operationally demonstrated, mature) | Verified and Observed states (Table 1); draft conformance levels verified, attested, recognized (Table 3) | | Evidence quality ladders | D-V3-0005 evidence levels; public label set pending OQ-16 | | Digital Public Good states (concept to retired) | Document lifecycle (Table 5); the term "digital public good" only in the sense of the Digital Public Goods Standard \[10] | | Supported, hosted, comparable, corridor-integrated, mature | Target, Implemented and Observed with explicit scope; comparability as a scoped claim | | Recognition and standing | Accepted state for external authorities; draft "recognized" level, not issued | *Table 6. Earlier status vocabularies mapped to the five-state grammar. Proposed crosswalk; not a binding record.* ### What status is not * It is not approval, endorsement or adoption by any public authority. * It is not a certificate. "Verification is not certification" \[3]. * It is not finance, insurance or a rating. "Finance-readiness is not finance" \[3]. * It is not permanent. Every state carries a date and a correction path. * It is not inferred. A route, a screen, a demonstration or a confident sentence is not evidence of any state. *** ## 3.1 Why the Status Layer Is Necessary The status layer is necessary because serious systems cannot rely on aspiration, elegance, partnership, technical sophistication, institutional prestige, or persuasive language. Nexus is designed to operate in high-consequence contexts: risk intelligence, resilience, public authority learning, infrastructure intended to support national deployment profiles (design intent, subject to evidence), Digital Public Goods, Marketplace objects, Foundry packages, Studio workflows, nodes, hosts, observatories, finance-readable pathways, [National Nexus](/organization/governance-in-operation/national-nexus.md) Consortiums, National Consortium Companies, Project SPVs, public-safe reports, conformance profiles, and lawful realization environments. In these contexts, ambiguity is not harmless. A pilot may sound mature. A host may sound sovereign. A dashboard may sound like public warning. A Marketplace listing may sound like endorsement. A provider may sound qualified because it is visible. A public authority learner may sound like an adopting authority. A finance-readable artifact may sound like an investment product. A node under formation may sound like an operational node. A report may sound like recognition. A connector may sound conformant because it integrates. The status layer prevents these errors. It makes the system capable of saying, with precision, what state an object, entity, pathway, node, output, provider, member, report, or implementation actually holds. Without this layer, Nexus would become vulnerable to false maturity, symbolic inflation, public claims drift, and trust collapse. *** ## 3.2 What Status Means in Nexus Within Nexus, status is the recorded and scoped institutional state of an object, entity, artifact, pathway, node, host, provider, report, Marketplace object, Digital Public Good, Foundry package, Studio workflow, public authority relation, or recognition-bearing result within a governed standards and Registry order. Status may describe: * whether something is proposed, draft, under review, active, supported, comparable, recognized, conformant, mature, suspended, deprecated, superseded, withdrawn, archived, or retired; * what profile has been applied; * what level of review has occurred; * what evidence supports the status; * what body or process recorded it; * what scope applies; * what claims may be made; * what claims must not be implied; * what downstream uses are permitted or prohibited; * and what correction, renewal, or expiry rules apply. Status is not a general statement of quality. It is not public relations language. It is not institutional prestige. It is not market visibility. It is not technical polish. It is a governed state within the Nexus architecture. *** ## 3.3 The Status Thesis of Nexus The status thesis of Nexus is that **a public-good-rooted, standards-bearing, federated, and realization-capable architecture can remain trustworthy only if every consequential state is earned, scoped, recorded, claim-bounded, comparable only under declared conditions, portable only within profile limits, and correctable over time**. This thesis has several implications. Self-description is not achievement. Visibility is not standing. Participation is not recognition. Compatibility is not conformance. Support is not comparability. Hosting is not maturity. Public-safe publication is not public authority adoption. Finance-readable readiness is not finance execution. Marketplace listing is not endorsement. Protocol entitlement is not lawful authority. A status-bearing system must therefore answer: What has been earned? Against what profile? On what evidence? By what review? In what scope? For what use? With what limitations? Under what lifecycle state? Subject to what correction? Status exists so that Nexus can become more useful without becoming less truthful. *** ## 3.4 Status as the Bridge Between Ontology and Registry Status sits between ontology and Registry. Ontology defines what an object is. Status defines what state the object holds. Registry records that state. Protocol may express that state in technical systems. Claims discipline governs public language about that state. For example: Ontology defines what a Nexus Node is. Status defines whether the node is proposed, pilot, active, mature, suspended, or retired. Registry records the node state. Protocol may allow or block certain node functions. Claims discipline governs whether the node may be described publicly as active, mature, comparable, or supported. This sequence matters. If status is not anchored in ontology, it becomes vague. If status is not recorded in Registry, it becomes informal. If status is not claim-bounded, it becomes overclaim. If status is not correctable, it becomes stale. The status layer turns meaning into governed state. *** ## 3.5 The Order of Earned Institutional Meaning Nexus follows an ordered sequence for earned institutional meaning. First, meaning must be governed through ontology and controlled vocabulary. Second, profiles must be defined. Third, evidence, implementation, behavior, artifact, pathway, or institutional state must be reviewed against those profiles. Fourth, conformance, non-conformance, partial conformance, supported status, or other profile result must be determined. Fifth, recognition may be recorded where appropriate. Sixth, comparability and interoperability may be asserted only within declared bounds. Seventh, public, platform, Registry, Marketplace, finance-readable, or downstream use must remain within those bounds. This sequence is one of the strongest protections against symbolic inflation. No later claim may borrow maturity from an earlier stage. A concept does not become a prototype by being named. A prototype does not become a release by being demonstrated. A release does not become conformant by being used. A conformant component does not become recognized beyond its profile. A recognized state does not become public authority adoption. A finance-readable artifact does not become investment advice. This order keeps the system honest. *** ## 3.6 Conformance Conformance in Nexus is the governed determination that an object, institution, implementation, pathway, artifact, node, host, output, Marketplace object, Digital Public Good, Foundry package, Studio workflow, or provider satisfies a defined standard, profile, control set, test suite, or review requirement within a bounded scope. Conformance is earned. It is not self-attestation by default. It is not marketing language. It is not general quality. It is not use of Nexus terminology. It is not participation in Nexus. It is not Marketplace presence. It is not technical compatibility alone. A conformance result should answer: * what was assessed; * against which profile; * under which version; * at which level; * in which scope; * using what evidence; * through what method; * by which reviewer or process; * for what duration; * with what limitations; * and with what permitted claims. Conformance narrows language. It does not broaden it. Its purpose is to make claims safer, more exact, and more reviewable. *** ## 3.7 Recognition Recognition in Nexus is the controlled institutional act by which an object, body, status, pathway, node, report, result, provider state, maturity state, or other eligible subject is acknowledged within the governance, standards, and Registry order of the system under defined meaning, defined scope, and defined reliance boundaries. Recognition is not applause. It is not courtesy. It is not endorsement by visibility. It is not partnership. It is not social approval. It is not public relations language. It is not adoption by a public authority. It is not finance execution. Recognition is a Registry-bearing status act. In the Nexus Standards (status PROPOSED), a recognition decision is a policy record of NXS-NSF, the constitutional trust, authorization, policy and assurance system; the draft level "recognized" is not issued in the draft, and no recognition decision is recorded today \[6]. Recognition in this sense is not a role of any institution, is not certification and is not acceptance by a competent external authority, which is the separate Accepted state (Table 1). It matters because Nexus contains many meaningful states that need to be legible without being inflated. An object may be supported but not comparable. A node may be active but not mature. A pathway may be recognized as under formation but not execution-ready. A provider may be listed but not qualified. A report may be public-safe but not recognition-bearing. A national group may be a working group but not a [National Nexus Consortium](/organization/governance-in-operation/nnc.md). Recognition allows Nexus to name these states in a disciplined way. It makes public meaning durable. It also prevents appearance from becoming status. *** ## 3.8 Recognition by Recorded State Only Recognition exists only by recorded state. Nothing in Nexus is recognized merely because it is visible, important, technically sophisticated, institutionally prominent, widely used, sponsored, hosted, attended, published, or partnered. Recognition must be: * classed; * scoped; * recorded; * reviewable; * claim-bounded; * stewarded; * correctable; * and subject to lifecycle state. This is a central public-trust rule. A partner logo is not recognition. A public event is not recognition. A funder relationship is not recognition. A platform page is not recognition. A provider demonstration is not recognition. A public authority conversation is not recognition. A technical integration is not recognition. Recognition without record is not recognition. This rule protects Nexus from status by appearance. *** ## 3.9 Recognition Is Bounded, Not Absolute Recognition is always bounded. A recognized object may be recognized for one class, purpose, profile, geography, domain, use, maturity level, timeframe, or pathway, and not for another. A provider may be recognized for a specific support capability, not all possible services. A node may be recognized as active, not mature. A pathway may be recognized as supported, not comparable. A Marketplace object may be recognized for compatibility, not public authority suitability. A report may be recognized as public-safe, not as a regulatory determination. A national pathway may be recognized as under formation, not as a legal consortium. A Foundry package may be recognized as a release candidate, not deployment-authorized. A bounded recognition model prevents over-broad interpretation of narrow but true results. It also supports progression. A subject can move from proposed to supported to comparable to mature without pretending every early state already carries later status. Bounded recognition is the opposite of symbolic inflation. *** ## 3.10 Interoperability Profiles Interoperability profiles are governed structures that define what kind of translation, exchange, compatibility, portability, and system-to-system relation is valid among objects, artifacts, nodes, institutions, platforms, pathways, reports, Marketplace objects, Digital Public Goods, Foundry packages, Studio workflows, and protocol environments. Interoperability is not mere data exchange. It is not API compatibility alone. It is not visual integration. It is not shared branding. It is not similar format. It is not common participation. Real interoperability requires: * controlled meaning; * defined object classes; * profile-aware translation; * evidence of compatibility where required; * declared scope; * role and authority boundaries; * public-safe limits; * lifecycle state; * and claims discipline. An interoperability profile should answer: What is interoperating? For what purpose? Under what profile? At what level? With what data or artifacts? What meaning is preserved? What meaning is not portable? What use is permitted? What use is prohibited? What review supports the claim? This is how Nexus prevents interoperability from becoming an illusion. *** ## 3.11 Profiles as the Bridge Between Meaning and Test Profiles are one of the central instruments of Nexus standardization. A profile takes controlled meaning, ontology, standards doctrine, and system rules and expresses them in a bounded form that can be reviewed, compiled, assessed, tested, implemented, or enforced where appropriate. Profiles bridge the gap between abstract meaning and operational review. A standard may define a requirement. A profile adapts that requirement to a class, context, domain, node, host, object, pathway, or use case. A control expresses what must be managed or verified. A check tests whether the control is satisfied. Evidence supports the check. A record stores the result. A claim is bounded by the record. This profile logic is central to NXOSI and to the wider Nexus approach to standards as operational infrastructure. NXOSI (described on this site as [Nexus OSI](/organization/standardization/nexus-osi.md)) is a proposed reference model, not a V3 system or shared fabric; in the Nexus Standards (PROPOSED), a profile corresponds most closely to a context bound to a policy of clauses ([NS-9](https://nexustandards.com/standards/ns-9/) and NS-10, proposed), a mapping that awaits owner review \[6]. Profiles are not summaries. They are governed instruments of assessment and consequence. *** ## 3.12 Profile Types Nexus should distinguish multiple profile types. ### 3.12.1 Scope Profiles A scope profile defines what an object, output, node, provider, pathway, or artifact actually covers. ### 3.12.2 Use Profiles A use profile defines what downstream uses are proper, improper, restricted, or prohibited. ### 3.12.3 Institutional Profiles An institutional profile governs how an institution is classified, assessed, recognized, or related to Nexus. ### 3.12.4 Artifact Profiles An artifact profile governs outputs such as evidence objects, proof objects, baseline packs, simulation packs, reports, public-safe summaries, Digital Public Goods, and governance products. ### 3.12.5 Node Profiles A node profile governs the operating state, supportability, maturity, host relationship, observability function, and interoperability status of a node. ### 3.12.6 Host Profiles A host profile defines the obligations, environment, support state, continuity capacity, data handling, public-safe posture, and role limits of a host. ### 3.12.7 Marketplace Profiles A Marketplace profile defines object class, listing state, support state, conformance posture, provider role, lifecycle state, and claims limits. ### 3.12.8 Studio Profiles A Studio profile defines workflow class, dashboard status, data source state, user role, public-safe status, reliance boundary, and authority limit. ### 3.12.9 Finance-Readiness Profiles A finance-readiness profile defines what kind of finance-readable status exists and what finance-related claims are prohibited. ### 3.12.10 Public Authority Capacity Profiles A public authority profile distinguishes learner, observer, consultee, host, sponsor, competent authority, adopting authority, procurement authority, regulator, emergency authority, public-warning authority, and implementation partner. Different subjects require different profiles. A strong standards architecture does not force all things through one generic assessment lens. *** ## 3.13 Scope Profiles and Use Profiles Scope profiles and use profiles are especially important. A scope profile answers: what does this object cover? A use profile answers: what may this object be used for? The distinction matters because an object may have a clear scope and still be inappropriate for certain uses. A report may cover disaster risk intelligence but not be suitable for public warning. A node may support observability but not routeability. A dashboard may support learning but not lawful decision-making. A Marketplace object may support internal testing but not public authority deployment. A finance-readiness artifact may support diligence preparation but not investment solicitation. A public-safe publication may be suitable for public education but not Registry-bearing recognition. Scope and use must therefore be separately recorded and separately claimed. This prevents a narrow truth from becoming a broad falsehood. *** ## 3.14 Conformance Levels Nexus should use conformance levels rather than a simple pass-or-fail model. A binary model is too blunt for complex systems. It forces early-stage but useful work into either overclaim or exclusion. It also allows weak systems to hide behind generic compliance claims. A laddered model allows truthful progress. Conformance levels may distinguish: * awareness or alignment; * documented profile mapping; * evidence-supported alignment; * tested conformance; * operationally demonstrated conformance; * monitored conformance; * portable conformance; * mature conformance; * or higher-assurance conformance where applicable. The exact ladder may vary by profile family, but the principle is stable. Conformance should state level, scope, evidence, review method, duration, and limitations. A mature standards system must be able to say more than yes or no. Nexus does that through profile-based conformance levels. The levels above are an earlier proposal of this page, not a published label set. The Nexus Standards (PROPOSED) use three conformance levels (verified, attested, recognized; Table 3), and public status is stated per dimension in the five-state grammar (Table 1) \[5]\[6]. No level on this page is, or is described as, a certificate. *** ## 3.15 Evidence Quality and Conformance Must Remain Distinct Evidence quality and conformance are related but not identical. Evidence quality concerns the strength, provenance, reliability, reproducibility, review state, confidence, and methodological integrity of the evidence base. Conformance concerns whether a subject satisfies a defined profile or requirement. A system may conform to a limited profile using moderate evidence. A system may have strong evidence for one claim but not conform to a broader operational profile. A report may have strong evidence but not be public-safe. A tool may pass a technical test but rely on weak field evidence. A node may be operational but not comparable due to insufficient evidence quality. Conflating evidence quality with conformance creates overclaim. Nexus should therefore distinguish EQL-style evidence-quality logic from CL-style conformance logic. EQL and CL are abbreviations of this page's earlier text (evidence quality ladder, conformance level); no label set under either name is published. This allows the system to say both: How strong is the evidence? And what profile has been satisfied? Both questions matter. Neither substitutes for the other. *** ## 3.16 Evidence Quality Ladders Evidence Quality Ladders help Nexus classify the evidentiary basis behind claims, profile results, conformance states, public-safe outputs, routeability notes, and recognition decisions. A ladder may distinguish: * unverified input; * contextual information; * documented evidence; * reviewed evidence; * reproducible evidence; * operational evidence; * cross-validated evidence; * high-assurance evidence. The purpose is not to create bureaucracy. It is to prevent evidence from being treated as stronger than it is. A case study is not a controlled evaluation. A pilot observation is not generalizable proof. A dashboard signal is not validated intelligence by itself. A public statement is not evidence. A report citation is not review. Evidence quality should be visible where claims depend on it. The ladder above is reasoning, not a public label set. The binding evidence vocabulary is the D-V3-0005 evidence levels, each separately scoped, time-bounded and source-linked; the public evidence labels for published findings await owner decision (OQ-16) \[1]\[5]. This is especially important for AI, disaster risk, public authority learning, finance-readable readiness, and public-safe publication. *** ## 3.17 Comparability Comparability in Nexus is a governed result that permits two or more subjects to be read together under shared criteria and declared limits. It is not sameness. It is not similarity by appearance. It is not common branding. It is not participation in the same ecosystem. It is not inclusion in the same platform. It is not membership in the same domain. Comparability depends on: * ontology; * controlled vocabulary; * profile alignment; * evidence quality; * method compatibility; * scope clarity; * maturity state; * lifecycle state; * jurisdictional relevance; * host conditions; * public authority capacity; * and claims boundaries. A national node may be comparable to another national node only under declared conditions. A disaster risk report may be comparable to another report only if methods, baselines, and evidence classes support comparison. A provider may be comparable to another provider only within a defined provider class and service scope. A finance-readable pathway may be comparable only within a defined route class. Comparability reduces friction and improves diligence, but only when earned. *** ## 3.18 Comparability Is Not Portability Comparability and portability are related but distinct. Comparability means two things may be read together under shared criteria. Portability means something may travel, be reused, translated, or applied across contexts within declared limits. A report may be comparable across countries but not portable as guidance. A tool may be portable technically but not comparable institutionally. A node may be comparable in observability terms but not portable in public authority terms. A public-safe summary may be portable as education but not as recognition. A finance-readiness framework may be comparable across project types but not portable into investment advice. Nexus must preserve this distinction. Comparability supports understanding. Portability supports movement. Neither creates execution authority by default. *** ## 3.19 Bounded Portability Bounded portability is the discipline through which Nexus allows objects, profiles, reports, Digital Public Goods, Marketplace objects, Foundry packages, Studio workflows, learning materials, and routeability artifacts to travel across contexts without losing scope or creating false authority. Portability may be bounded by: * jurisdiction; * domain; * language; * public authority capacity; * host conditions; * node state; * data availability; * evidence quality; * conformance level; * public-safe status; * licensing; * security posture; * support status; * and local lawful basis. A Digital Public Good may be portable as code but not as supported implementation. A report may be portable as learning but not as local public authority determination. A Studio workflow may be portable as a training tool but not as an operational decision system. A Marketplace connector may be portable technically but not lawful everywhere. A routeability profile may be portable conceptually but not finance-ready in all jurisdictions. Portability must therefore be declared, not assumed. *** ## 3.20 Interoperability Requires More Than Shared Format Interoperability requires more than shared format. Two systems may exchange data and still fail to interoperate meaningfully because the exchanged data carries different meanings, evidence assumptions, maturity states, public-safe constraints, or authority boundaries. True interoperability requires: * semantic interoperability; * data interoperability; * technical interoperability; * institutional interoperability; * operational interoperability; * governance interoperability; * and, where relevant, protocol interoperability. A shared API may provide technical connection. It does not guarantee semantic alignment. A common data format may support exchange. It does not guarantee institutional equivalence. A dashboard integration may display data. It does not create public warning authority. Interoperability profiles define not only the channel, but the relation. They specify what is portable, what is translated, what remains context-bound, and what downstream use is valid or invalid. *** ## 3.21 Supported, Comparable, Hosted, Corridor-Integrated, and Mature States Nexus should maintain differentiated pathway and node states. These states may include: * proposed; * candidate; * supported; * hosted; * active; * comparable under conditions; * corridor-integrated; * strategic-project-enabled; * mature; * suspended; * deprecated; * retired. These are not branding labels. They are status classes. A supported pathway is not a comparable pathway. A hosted pathway is not an independent mature node. A corridor-integrated state is not supranational authority. A strategic-project-enabled pathway is not finance execution. A mature node is not universally portable without profile limits. A host-supported environment is not host sovereignty. These distinctions matter because weak ecosystems tend to flatten them. This list is descriptive vocabulary for one kind of subject, not a set of public status states. Public status is stated per dimension in the five-state grammar (Table 1), and Table 6 maps this list to it \[1]\[5]. Nexus preserves them through status discipline. *** ## 3.22 Node Status Node status must be especially precise. A Nexus Node may move through states such as: * proposed node; * candidate node; * under assessment; * pilot node; * active node; * supported node; * hosted node; * comparable node; * corridor-integrated node; * mature node; * suspended node; * deprecated node; * retired node. Each state must be defined. A proposed node is not active. A pilot node is not mature. An active node is not comparable by default. A hosted node is not sovereign. A corridor-integrated node is not regional authority. A mature node may still be bounded by domain, host, jurisdiction, and profile. Node status should be recorded in Registry where relevant and displayed with claims limits. This list is descriptive vocabulary for one kind of subject, not a set of public status states. Public status is stated per dimension in the five-state grammar (Table 1), and Table 6 maps this list to it \[1]\[5]. The more visible a node becomes, the more exact its status language must be. *** ## 3.23 Host Status Host status must also be controlled. A host may be: * proposed host; * candidate host; * approved host for limited purpose; * active host; * backup host; * anchor host; * learning host; * observatory host; * Studio host; * node host; * suspended host; * retired host. Host status describes the role of the host in supporting an environment, node, pathway, room, observatory, Academy function, Studio workflow, or other operating surface. A host is not sovereign over Nexus. A host does not hold NXS-NSF policy authority. A host is not public authority unless it independently is one. A host does not own the common rail. A host may support runtime truth, but it does not become constitutional author. Host status must therefore state scope, obligations, public-safe limits, data responsibilities, and lifecycle state. *** ## 3.24 Provider Status Provider status must distinguish visibility from qualification. A provider may be: * interested; * applicant; * under review; * member; * listed; * supported; * qualified for defined scope; * conformance-reviewed; * suspended; * deprecated; * retired. A provider listing is not qualification. A provider qualification is not universal endorsement. A provider contribution is not standards authority. A provider Marketplace presence is not procurement preference. A provider role in one domain does not imply qualification in another. Provider status should state class, scope, service area, support state, conflict controls, cybersecurity requirements, data obligations, conformance posture, and claims limits. This protects users, public authorities, and the public-good rail from provider capture and procurement confusion. *** ## 3.25 Marketplace Status Marketplace status should distinguish object visibility from trust state. A Marketplace object may be: * proposed; * under intake; * candidate; * experimental; * listed; * supported; * conformance-reviewed; * verified, attested or recognized where applicable (draft conformance levels; no certificate is issued); * deprecated; * suspended; * retired; * archived. A listing means discoverability, not recognition by default. A supported object means support exists, not universal suitability. A badge means only what the badge scope says. A rating is not formal maturity. A featured item is not procurement preference. Marketplace status should state object class, provider, steward, version, support posture, conformance posture, public-safe limits, jurisdictional limits, lifecycle state, and Registry linkage where applicable. Marketplace status makes ecosystem buildout visible without turning visibility into trust by implication. *** ## 3.26 Digital Public Good Status Digital Public Goods require status discipline. A Digital Public Good may be: * concept; * draft; * experimental; * maintained; * supported; * public-safe; * security-reviewed; * conformance-reviewed; * deprecated; * unsupported; * archived; * retired. Open does not mean maintained. Public does not mean public-safe for all uses. Reusable does not mean endorsed. A repository does not mean supported. A fork does not mean authorized. A release does not mean universal readiness. Digital Public Good status should include license, steward, version, dependency state, maintenance state, support level, security status, public-safe posture, conformance posture, and lifecycle state. This keeps public-good software and artifacts usable without overclaim. This list is descriptive vocabulary for one kind of subject, not a set of public status states. Public status is stated per dimension in the five-state grammar (Table 1), and Table 6 maps this list to it \[1]\[5]. The term "Digital Public Good" is used on this site only in the sense of the Digital Public Goods Standard; no Nexus item is stated here to meet that standard or to be listed in its registry, and any such statement would need a licence decision and a registry record \[10]. *** ## 3.27 Foundry Status Foundry status governs build maturity. A Foundry object may be: * idea; * requirement; * scoped concept; * prototype; * experiment; * package candidate; * release candidate; * maintained package; * supported package; * deprecated package; * retired package. A concept is not a prototype. A prototype is not a release. A release candidate is not deployment authorization. A maintained package is not universal conformance. A supported package is not public authority adoption. Foundry status should state build stage, test state, documentation state, dependency state, security posture, support model, public-safe limits, and handoff state. Foundry status keeps build momentum from becoming false maturity. *** ## 3.28 Studio Status Studio status must be exact because Studio environments can appear authoritative. A Studio object may be: * concept; * learning environment; * internal workflow; * controlled room; * dashboard; * simulation; * decision-support workflow; * observability interface; * public authority learning environment; * pilot workflow; * active workflow; * retired workflow. Studio status should state: * workflow class; * user role; * access level; * data source state; * update frequency; * public-safe status; * reliance boundary; * authority boundary; * correction pathway; * and public authority capacity where relevant. A dashboard is not public warning by default. A simulation is not forecast certainty. A decision-support workflow is not lawful decision-making. A public authority learning environment is not public authority adoption. Studio status protects users from mistaking interface power for authority. *** ## 3.29 Public Authority Status Public authority status requires strong classification. A public authority may appear as: * learner; * observer; * consultee; * host; * sponsor; * competent authority; * adopting authority; * procurement authority; * regulator; * emergency authority; * public-warning authority; * implementation partner. These are different states. A learner is not adopting. An observer is not approving. A consultee is not endorsing. A host is not adopting all outputs. A sponsor is not controlling. A procurement authority acts only through procurement law. A regulator acts only through regulatory mandate. A public-warning authority acts only through lawful warning procedures. Public authority status must be recorded and communicated carefully. This protects sovereignty, public law, public trust, and Nexus legitimacy. *** ## 3.30 Finance-Readable Status Finance-readable status must be carefully bounded. A pathway or object may be: * concept; * early project idea; * routeable idea; * project-preparation candidate; * readiness artifact; * finance-readable record; * diligence-ready package; * sponsor-supported pathway; * capital discussion; * Project SPV concept; * Project SPV formed; * capital commitment; * financial close; * executed project. These states must not collapse. Finance-readable is not financed. Diligence-ready is not investment advice. A capital discussion is not capital commitment. A Project SPV concept is not a securities offering. A Project SPV formed is not financial close. A routeability record is not credit rating. A readiness report is not underwriting. Finance-readable status exists to help institutions understand preparedness and routeability without creating regulated financial consequence by implication. *** ## 3.31 National and Regional Formation Status National and regional pathway status must be disciplined. A national pathway may move through: * country interest; * national observer cluster; * national members; * national domain activity; * [National Working Group](/organization/governance-in-operation/nwg.md) proposed; * National Working Group active; * National Nexus Consortium under formation; * National Nexus Consortium formed; * National Consortium Company under preparation; * National Consortium Company formed; * Project SPV concept; * Project SPV formed. Each state must be distinguished. A national group is not a National Working Group. A National Working Group is not a National Nexus Consortium. A National Nexus Consortium is not a National Consortium Company. A National Consortium Company is not a Project SPV. A Project SPV is not the public-good architecture. Regional formation status should similarly distinguish regional interest, regional working group, regional council, regional consortium, corridor pathway, and regional implementation-support structures. Stage truth is essential to federation. *** ## 3.32 Status and Sovereign Primacy Status must preserve sovereign primacy. A Nexus status may support learning, comparability, public-safe publication, routeability, conformance, or recognition within the Nexus system. It does not override national law, public authority mandate, domestic custody decisions, procurement rules, regulatory authority, emergency authority, or public-warning powers. A comparable regional state does not erase national lawful basis. A global profile does not replace domestic authority. A regional recognition does not create sovereign adoption. A node state does not create public authority status. A Marketplace badge or listing does not replace procurement, and it is never a certificate. A finance-readable record does not replace regulated financial review. Status supports lawful interpretation. It does not usurp lawful authority. This is one of the core sovereignty-safe features of Nexus. *** ## 3.33 Status and Public Claims Discipline Status exists partly to govern public claims. A status permits certain claims and prohibits others. A listed object may claim listing if current and permitted. A conformant object may claim conformance only to the relevant profile, level, version, scope, and validity period. A recognized pathway may claim recognition only within its recorded class. A supported node may not claim maturity. A public-safe report may not claim public authority approval. A finance-readable artifact may not claim investment suitability. A provider listed in Marketplace may not claim procurement preference. A sponsor-supported activity may not claim sponsor control. Status should always produce claims guidance. Public language should be downstream from status, not upstream from ambition. *** ## 3.34 Status and Platforms Platforms must display status accurately. Platform design can create perceived authority even when content is weak. A polished page, map, dashboard, listing, badge, or directory entry may imply maturity if status is not visible. Platform status discipline should include: * current status; * lifecycle state; * profile scope; * version; * steward; * review state; * public-safe state; * Registry link where applicable; * correction notice where applicable; * supersession notice where applicable; * and claims limits. A platform page should not make a draft look final. A Marketplace object should not look recognized by default. A node map should not imply maturity. A dashboard should not imply public warning. A provider profile should not imply endorsement. Interface design is part of status governance. *** ## 3.35 Status and Registry Registry is the records-valid home of status. A status that matters should be recorded. Registry may hold records for: * recognition; * conformance; * comparability; * interoperability; * maturity; * public-safe publication; * Marketplace listing; * provider status; * Digital Public Good status; * Foundry package status; * Studio workflow status; * node status; * host status; * public authority capacity; * national pathway state; * regional pathway state; * correction; * supersession; * withdrawal; * retirement; * archive. Registry presence must itself be scoped. A Registry entry does not mean recognition unless the record class is recognition. A Registry entry may be administrative, public-safe, conformance-related, lifecycle-related, correction-related, or archival. Registry gives status memory. It does not turn every record into approval. *** ## 3.36 Status and Protocol Effect Protocol may express status technically, but protocol does not create status from nothing. A role key may express a recorded role. A smart license may enforce a recorded entitlement (smart licences are a concept of this page's earlier text with no recorded source; they are read as research outlook, and the V3 counterpart is an NXS-NXQ entitlement under an NXS-NSF policy decision) \[5]. A platform permission may reflect a status. A no-bypass rule may prevent action outside recorded authority. A revocation may implement status correction. But technical effect must remain subordinate to recorded state. A role key is not appointment unless appointment exists. A smart license is not public authority adoption. A dashboard permission is not lawful decision-making authority. A Marketplace badge is not universal approval. Protocol should enforce status; it should not invent status. This preserves constitutional truth in machine-operable systems. *** ## 3.37 Status and Non-Execution Status is non-executing by default. Conformance does not authorize execution. Recognition does not authorize procurement. Comparability does not authorize investment. Interoperability does not authorize deployment. Public-safe publication does not authorize public warning. Finance-readable readiness does not authorize underwriting, rating, insurance, lending, brokerage, placement, or investment advice. Provider qualification does not create procurement award. Node maturity does not create public authority operation. SPV status does not become securities offering by itself. Status can support downstream action by lawful actors. It does not replace those actors. This rule makes Nexus safer and more credible. *** ## 3.38 Status and Correctionability Status must be correction-capable. A conformance result may be superseded. A recognition may be narrowed. A provider status may be suspended. A Marketplace object may be deprecated. A node may move from active to suspended. A report may be corrected. A public authority capacity may be clarified. A finance-readable pathway may be downgraded. A Digital Public Good may become unsupported. A Studio workflow may be withdrawn. Correctionability ensures that status remains aligned to reality. Correction may include: * status update; * public clarification; * Registry correction; * platform label change; * claim narrowing; * supersession; * suspension; * withdrawal; * deprecation; * retirement; * archival; * or revocation of protocol effect. A correctable status system is stronger than a rigid status system. It can tell the truth as the world changes. *** ## 3.39 Status Versioning and No-Silent-Edit Discipline Status changes that affect meaning, reliance, claims, public interpretation, conformance, recognition, comparability, portability, public authority capacity, finance-readable readiness, or protocol effect should be versioned and traceable. No-silent-edit discipline may require: * status version; * effective date; * change log; * reason for change; * steward; * superseded status; * correction note; * public notice where appropriate; * Registry update; * platform update; * and protocol update where applicable. This protects users who relied on prior status. It also protects Nexus from rewriting institutional memory. A records-valid system must preserve status history. *** ## 3.40 Profile Governance and Change Control Profiles must themselves be governed. Because profiles determine assessment, conformance, comparability, portability, and claims, profile changes can affect real downstream meaning. Profile governance should address: * proposal; * review; * domain consultation; * standards authority review; * public-safe review; * Registry impact; * platform impact; * AI and automation impact; * interoperability impact; * versioning; * compatibility; * migration; * publication; * and correction. A local team should not silently change a profile for convenience. A provider should not redefine profile requirements. A region should not create incompatible profile variants. A host should not redefine maturity. Profile change control protects the common rail from hidden fragmentation. *** ## 3.41 Status and AI / Automation AI and automation must be status-aware. AI systems that summarize, classify, recommend, route, compare, or generate public-facing language must understand status classes and claims limits. An AI assistant should not describe a listed object as recognized. It should not describe a learner public authority as adopting. It should not describe a prototype as deployed. It should not describe finance-readable readiness as investment opportunity. It should not describe conformance discussion as conformance result. It should not describe a dashboard as public warning. AI outputs should be constrained by ontology, Registry, profile state, public-safe status, and claims guidance. Automation may assist status management, but it must not create final status without governed review where review is required. *** ## 3.42 Status and Reports, Media, and Forum Outputs Reports, Media, and Forum outputs must carry status. A report may be draft, working, public-safe, published, corrected, superseded, withdrawn, or archived. A media output may be explanatory, announcement, interview, campaign content, recap, public-safe summary, or correction. A forum output may be agenda, transcript, summary, recommendation, issue log, standards question, learning record, report candidate, or archive. These statuses matter. A forum recommendation is not a decision. A media recap is not recognition. A report draft is not published. A public-safe summary is not full evidence. A transcript is not governance record unless classified. Status prevents communications from becoming accidental authority. *** ## 3.43 Status and Safeguards Status must integrate safeguards. Some statuses should trigger restrictions, handling requirements, public-safe review, community consent checks, cybersecurity review, market sensitivity controls, public authority capacity review, or protected knowledge safeguards. For example: A dataset may be controlled. A map may involve sensitive geography. A community contribution may be protected. A health output may be sensitive. A finance-readiness object may be market-sensitive. A public authority workflow may be restricted. A Studio dashboard may require controlled access. A provider status may require cybersecurity review. Safeguard status should be visible to authorized users and public-safe where appropriate. Status is not only about maturity. It is also about protection. *** ## 3.44 Status and External Organizations Status is a practical resource for external organizations. A public authority can use status to understand whether an output is educational, public-safe, recognized, comparable, or adopted through its own process. A company can use status to understand whether it is a member, provider applicant, listed provider, qualified provider, Marketplace participant, or execution actor. A university can use status to distinguish research contribution, Academy partnership, expert working group role (earlier text: "competence-cell role", a retired label; see the note at the top of this page), node host, or public-good contributor. A sponsor can use status to understand support-without-control. A community organization can use status to understand protected participation, public-safe publication, consent, and correction. A provider can use status to understand listing, qualification, conformance, scope, support state, and claims limits. A national group can use status to understand the difference between national interest, National Working Group, National Nexus Consortium, National Consortium Company, and Project SPV. A finance reader can use status to distinguish routeability, finance-readable readiness, diligence preparation, capital commitment, and execution. Status makes Nexus usable without making it misleading. *** ## 3.45 Status Failure Modes Nexus should be explicit about status failure modes. **Self-description inflation** occurs when actors describe themselves as having achieved a status not reviewed or recorded. **Visibility-as-status drift** occurs when platform presence, event prominence, sponsorship, or partnership is mistaken for standing. **Pilot-to-maturity inflation** occurs when early-stage work is narrated as mature. **Host-sovereignty drift** occurs when hosting is mistaken for constitutional authority. **Listing-as-recognition drift** occurs when Marketplace listing is treated as endorsement. **Compatibility-as-conformance drift** occurs when technical integration is treated as reviewed conformance. **Comparability inflation** occurs when similar objects are treated as comparable without profile discipline. **Portability overclaim** occurs when an object is assumed reusable across contexts without scope limits. **Public authority overclaim** occurs when learning, observation, or consultation is narrated as adoption. **Finance-readiness overclaim** occurs when routeability or readiness language implies investment, underwriting, insurance, rating, or capital commitment. **Provider capture** occurs when providers use status language to imply authority or procurement preference. **Sponsor capture** occurs when support is treated as control or standing. **Protocol overreach** occurs when technical entitlement is treated as lawful authority. **Stale status failure** occurs when outdated, superseded, or suspended statuses remain visible as current. **Correction failure** occurs when status errors cannot be updated or publicly narrowed. Status governance exists to prevent these failures. | Failure mode | First defence | | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | | Self-description inflation; pilot-to-maturity inflation | Five-state grammar with cited evidence (Table 1) | | Visibility-as-status drift; listing-as-recognition drift | Anti-inference rule; recognition only by recorded decision \[1] | | Host-sovereignty drift; protocol overreach | A user entitlement is not authorization; NXS-NSF policy decisions only \[9] | | Compatibility-as-conformance drift; comparability inflation; portability overclaim | Scoped conformance statements (Table 3, Table 4) | | Public authority overclaim; finance-readiness overclaim | Boundary formulas \[3] | | Provider capture; sponsor capture | Recorded issuer and scope on every status statement (Table 4) | | Stale status failure; correction failure | As-of dates and correction states (Table 5) | *Table 7. Status failure modes mapped to the controls of this page.* *** ## 3.46 Strategic Value of Status The strategic value of status is that it makes Nexus trustworthy under scale. Status allows Nexus to say exactly what has been earned. It allows participants to progress without overclaim. It allows public authorities to engage without being misrepresented. It allows providers to participate without becoming standards authorities. It allows sponsors to support without controlling. It allows Marketplace to be useful without becoming endorsement. It allows Foundry to build without implying deployment maturity. It allows Studio to be powerful without becoming hidden authority. It allows nodes and hosts to become visible without becoming sovereign. It allows finance readers to understand readiness without triggering regulated financial claims. It allows national and regional pathways to mature stage by stage. It allows Registry to carry institutional memory. It allows protocol to enforce recorded states. In strategic terms, status is the architecture of earned institutional meaning. It lets Nexus become serious without becoming inflated. *** ## 3.47 Final Statement on Status Status is the architecture through which Nexus converts controlled meaning into earned, reviewed, scoped, recorded, comparable, interoperable, portable, public-safe, and correctable institutional state. It is the layer that prevents self-description from masquerading as achievement, visibility from masquerading as standing, compatibility from masquerading as conformance, support from masquerading as comparability, hosting from masquerading as sovereignty, public-safe publication from masquerading as public authority action, and finance-readable readiness from masquerading as finance execution. Through profiles, conformance levels, recognition records, evidence-quality ladders, scope and use profiles, institutional profiles, artifact profiles, node profiles, Marketplace status, Digital Public Good status, Foundry status, Studio status, public authority capacity, finance-readable status, national and regional formation status, claims discipline, Registry linkage, protocol subordination, correctionability, and no-silent-edit discipline, Nexus makes status precise enough to trust and bounded enough to travel. In Nexus, status is not inferred. It is not aesthetic. It is not social. It is not aspirational. It is not automatic. Status is earned, profiled, reviewed, recorded, scoped, claim-bounded, and correctable. Through Status, Nexus becomes capable of institutional trust at scale. *** ## Terms used on this page | Term | Definition | Source | | ------------------------- | --------------------------------------------------------------------------------------- | ------------------------------------- | | Status | A dated, scoped, evidenced statement that a subject holds a state in a dimension | This page | | Five-state public grammar | Target, implemented, verified, observed, accepted, each with its own evidence | Nexus Documentation Standard \[5] | | Truth dimensions | The ten independent V3 state axes from implementation to correction | D-V3-0005 \[1] | | Claim ceiling | The strongest claim allowed by the attached evidence | Claim registry \[2] | | Release hold | Policy record, active since 2026-07-21, that blocks production and Controlled GA claims | Release hold policy \[2] | | Attestation (draft) | A record of an evaluation at one instant; evidence, not a certificate | Nexus Standards (PROPOSED) NS-11 \[6] | ## Related pages * Up: [Standardization introduction](/organization/introduction/standardization.md) * Across: [I. Order](/organization/introduction/standardization/i.-order.md) · [II. Ontology](/organization/introduction/standardization/ii.-ontology.md) · [IV. Registry](/organization/introduction/standardization/iv.-registry.md) · [V. Protocol](/organization/introduction/standardization/v.-protocol.md) · [VI. Outputs](/organization/introduction/standardization/vi.-outputs.md) * Counterparts: [Reading rules](/organization/introduction/knowledge/iii.-reading-rules.md) · [System overview](/organization/introduction/knowledge/i.-system-overview.md) · [Nexus OSI](/organization/standardization/nexus-osi.md) ## Sources 1. Nexus constitutional directive D-V3-0005, *Product Truth, Claims, Evidence and Promotion Constitution*: ten truth dimensions, promotion rule, evidence levels, claim registry, correction states, anti-inference. Internal record, cited by identifier. 2. Nexus claim registry (claims permitted where evidence is attached; claims blocked while the release hold is active; institutionally observed bindings) and release hold policy (active since 21 July 2026). Internal record. 3. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks, Non-Execution and Lawful Handoff Constitution*, boundary formulas; constitutional invariants (truth inequalities; no single global readiness percentage). Internal record, cited by identifier. 4. Nexus capability ledger, target-state entries for the Ontology Fabric, UNI Identifier Fabric, Evidence and Receipt Fabric, NXS-NSF and NXS-RLS; last evaluated 26 August 2026. Internal record. 5. Nexus Documentation Standard, draft of 16 October 2026: status grammar, document status and research-outlook framing, with the open questions on status wording and ledger freshness; institutional site narrative draft for programme status. Internal editorial standard. 6. Nexus Standards, as published at nexustandards.com (every standard PROPOSED; legal review required): NS-9, NS-10 and NS-11 (contexts, clauses, policies, attestations; levels verified, attested, recognized; standards lifecycle), status proposed. Draft source. 7. Nexus Indicator Standard NIS-1, version 1.0.0, a draft that requires expert review. Internal record, cited by identifier. 8. ISO and IEC (2020). *ISO/IEC 17000:2020 Conformity assessment: Vocabulary and general principles*. (URL not verified) 9. Nexus constitutional directive D-V3-0001, *Master Architecture, Product and Production Build Directive V3.0*, section 3 shared fabrics, section 4 authority invariants and section 13 correction constitution. Internal record, cited by identifier. 10. Digital Public Goods Alliance. *Digital Public Goods Standard*. [digitalpublicgoods.net](https://www.digitalpublicgoods.net/standard). Accessed 2026-10-16. 11. Nexus Standards (2026). *The standards*: foundation standards NS-0 to NS-16 and NS-3b, the Nexus Indicator Standard NIS-1 and the Nexus Risk Standards. Every standard at status PROPOSED. [nexustandards.com/standards](https://nexustandards.com/standards/). Read 2026-10-21. 12. Nexus Standards (2026). *Nexus Risk Standards (NRS)*: 348 standards in 15 series, including the hazard family standards of NHS-1; one retired standard (NRS-U20). [nexustandards.com/standards/nrs](https://nexustandards.com/standards/nrs/). Read 2026-10-21. 13. Nexus Standards (2026). *Governance of the Nexus Standards*: Global Standards Council, Technical Management Divisions, Technical Committees, working groups, Editors, Registrar, Conformance and Assurance Panel, Ethics, Conflicts and Appeals Panel, Secretariat (GCRI Canada, publisher of record) and National Standards Councils. Status PROPOSED; legal review required. [nexustandards.com/governance](https://nexustandards.com/governance/). Read 2026-10-21. 14. Nexus Standards (2026). *Adopt and implement the Nexus Standards*: adopt as is, adopt with a profile (NS-16), adapt, or reference only; national adoption is final and no global body holds a veto. [nexustandards.com/adopt-and-implement](https://nexustandards.com/adopt-and-implement/). Read 2026-10-21. 15. GCRI (2026). *Programme status*: Exploration, In formation, Constituted, Active programme, Paused, Closed, Historical record; current service level R0. [therisk.global/consortium/programme-status](https://therisk.global/consortium/programme-status/). Read 2026-10-21. 16. Nexus Standards (2026). *NS-14: Conformance and Crosswalk to External Standards*, UNI NXS-STD-ST-000013, status PROPOSED. [nexustandards.com/standards/ns-14](https://nexustandards.com/standards/ns-14/). 17. Nexus Standards (2026). *NS-11: Verification and Monitoring*, UNI NXS-STD-ST-000007, status PROPOSED. [nexustandards.com/standards/ns-11](https://nexustandards.com/standards/ns-11/). 18. GCRI (2026). *How Nexus works*: the six pillars, their eighteen handoffs and the eight-step cycle (Question, Evidence, Build, Organize, Test, Publish, Decide, Renew). [therisk.global/nexus-cycle](https://therisk.global/nexus-cycle/). Read 2026-10-21. 19. GCRI (2026). *Nexus Reports programme*: quarterly country editions, an annual flagship and specialist series; current approved releases: none. [therisk.global/publications/nexus-reports](https://therisk.global/publications/nexus-reports/). Read 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: 2026-10-16, upgraded to the documentation standard. Record block, In brief and status sentence added; definition, five-state grammar, evidence-gate figure, claim ceiling and release hold, status matrix, draft conformance levels, status-statement form, lifecycle vocabularies and the mapping of earlier ladders added; drafting residue citing an unseen "source page" removed; competing ladders and state sets (conformance levels, evidence-quality ladders, Digital Public Good states, pathway and node states) kept as descriptive vocabularies and mapped to the five-state grammar; "certified" states and "protocol authority" corrected; smart licences framed as research outlook; failure-mode table, glossary, related pages and sources added; heading levels fixed. All numbered sections retained. * Change: 2026-10-16 r2, readable document record and status note; systems named by Nexus Standards display codes with a first-mention description; system naming; internal identifiers, paths and commit references removed from reader text; sources restated as internal records cited by identifier. * Change: 2026-10-21 r3, brought up to date with the published sites, Nexus Standards and the owner's rulings of October 2026: Where this fits line; a Current position section; Nexus Standards described as published (NS-0 to NS-16 and NS-3b, NIS-1, 348 NRS in 15 series, all PROPOSED; GCRI Canada publisher of record; governance bodies and adoption modes); the national vocabulary of National Nexus, the NNC with its six [Helix councils](/organization/governance-in-operation/councils.md), the NLC and the NWG; the finance boundary on every vehicle passage; the systems named as systems; all original sections kept. --- # 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/standardization/iii.-status.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.