> 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/ii.-ontology.md). # II. Ontology How the Nexus programme governs shared meaning: terms, classes, relationships and units, versioned and extended without forking, and what ontology cannot do. **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-0001, D-V3-0003, D-V3-0004 and D-V3-0005; Ontology Fabric directive (non-binding until cutover); [Nexus Standards](/organization/institutions/nexus-standards.md), as published at nexustandards.com (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 Ontology, in the Nexus programme, is the governed structure of meaning: the terms, classes, relationships, units and constraints that let people, institutions and software read the same record the same way. In the V3 architecture it belongs to the Ontology Fabric, a shared fabric outside the twenty systems, whose boundary is that classification and entailment do not establish observation or substantive truth. Ontology makes records comparable and correctable; it never makes them true, official or authorized \[1]\[3]. ## 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, 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 \[21]\[22]. 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 \[23]. 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 \[24]. For ontology, the published standards that matter most are NS-15, which binds subjects, passports, routes, engines, cells and agents to the system model; NS-3b, the dataset and product metadata profile built on STAC, DCAT and PROV-O; and NS-4, which fixes how terms are defined and versioned in every standard \[25]\[26]\[27]. The six sectors and their fifteen relations in [Coupled risk](/organization/model/coupled-risk.md) are the shared vocabulary that every sector ontology extends, and the interdependency classes of Rinaldi et al. (2001) remain the reference for how those relations are typed \[28]. Earlier text on this page referred to the Nexus Standards as a draft and to labels such as competence cells. Both are superseded; see [Reference](/organization/reference.md) for historical labels. **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 \[29]\[30]. ## 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-GRX](/organization/systems/nxs-grx.md), the global data and risk intelligence engine, which holds the risk index methodology and risk data products. * [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-DSS](/organization/systems/nxs-dss.md), the decision support system for scenario comparisons, decision options and trade-offs. * [NXS-EOP](/organization/systems/nxs-eop.md), the Earth observation, geospatial and digital-twin fabric. * [NXS-EWS](/organization/systems/nxs-ews.md), the early warning support system for watches and warning readiness, which never issues official alerts. * [NXS-AAP](/organization/systems/nxs-aap.md), the anticipatory action and preparedness system for triggers, protocols and readiness records. * [NXS-NET](/organization/systems/nxs-net.md), the network intelligence and communications resilience system. * [NXS-OPS](/organization/systems/nxs-ops.md), the observatory protocol for sovereign, local and edge observation infrastructure. * [NXS-SIG](/organization/systems/nxs-sig.md), the authorized signal, spectrum and communications integrity system. * [NXS-NXQ](/organization/systems/nxs-nxq.md), the software, capability and agent fabric for registries, licensing, APIs and connectors. The capability ledger records the Ontology Fabric as a target-state entry: declared, not yet tested and not yet observed. A target-state entry is not implementation evidence \[8]. This page is explanatory (authority level L5): it creates no obligation and adopts no vocabulary. Where it restates a binding source, the source is cited and prevails \[9]. ### Retired labels on this page {% hint style="info" %} **Retired labels.** This page's earlier text referred to a "competence cell". That label 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 ontology layer of Nexus. If **I. Order** explains why standardization is foundational to controlled meaning, status, conformance, recognition, comparability, interoperability, and protocol discipline, then **II. Ontology** explains the meaning infrastructure that makes all of those functions possible. Ontology is the system by which Nexus defines what things are, how they differ, how they relate, what state they hold, what evidence or records attach to them, what claims may be made about them, and how they may be interpreted across people, institutions, platforms, machines, jurisdictions, domains, nodes, hosts, reports, registries, Marketplace objects, Digital Public Goods, Foundry packages, Studio workflows, public authority learning environments, and lawful realization pathways. In Nexus, ontology is not a glossary. A glossary lists terms. Ontology governs meaning. It creates the controlled semantic structure through which the system can distinguish a node from a host, a listing from recognition, a public-safe report from public authority action, a conformance result from compatibility, a finance-readable object from a finance execution instrument, a Studio dashboard from public warning, and a protocol entitlement from lawful authority. This page treats ontology as the meaning infrastructure of Nexus, required for controlled vocabulary, cross-domain reasoning, AI and automation, comparability, Registry logic and public claims discipline. In the V3 architecture, shared meaning is the remit of the Ontology Fabric, and NXS-GRX binds its canonical data to that meaning (see section 2.10) \[1]\[2]. Ontology is therefore one of the deepest layers of Nexus. It is where language becomes governable. It is where records become interpretable. It is where domains become relatable. It is where AI becomes constrainable. It is where comparability becomes possible. It is where public claims become safer. It is where the common rail becomes semantically real. ## Definition and canon alignment The numbered sections from 2.1 onwards keep the full doctrine of this page. This section gives the precise definition, the international languages of ontology work, and the V3 constitutional home of shared meaning. ### Definition An **ontology** is a formal, explicit specification of the classes of things in a domain, their properties and the relationships between them, written so that both people and machines can apply it consistently. The World Wide Web Consortium (W3C) publishes the main open languages for this work: OWL 2 for ontologies \[10], SKOS for thesauri and controlled vocabularies \[11] and SHACL for shapes that validate data against constraints \[12]. In this documentation, ontology is the first layer of the [standardization order](/organization/introduction/standardization/i.-order.md): meaning comes before status, records and technical effect. Its job is to let the programme distinguish, reliably and in machine-readable form, a node from a host, a listing from a recognition, a public-safe report from a public authority decision, and a readiness record from a financial commitment. The V3 master directive makes this a requirement, not a preference: "All domain records SHALL bind to a versioned ontology or schema contract, including units, enumerations and semantic applicability" (requirement NXS-V3-0001-SEM-04) \[1]. ### Ontology, vocabulary, taxonomy, schema and registry These five layers are related but not interchangeable; section 2.7 explains why each needs the others. | Layer | What it does | Typical open standard | Nexus home | | --------------------- | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | | Controlled vocabulary | Fixes preferred labels and definitions for terms with consequence | SKOS \[11] | Ontology Fabric term | | Taxonomy | Orders categories into hierarchies | SKOS concept schemes \[11] | Ontology Fabric relationship type | | Ontology | Defines classes, properties, relationships, units and allowed inferences | OWL 2 \[10] | Ontology Fabric semantic package, property, unit definition | | Schema and shapes | Validates the structure of data and records | SHACL \[12]; JSON Schema | Ontology Fabric shape, constraint | | Registry | Records which subject holds which state, when, under whose authority | Records practice (see [IV. Registry](/organization/introduction/standardization/iv.-registry.md)) | UNI Identifier Fabric; owning systems | *Table 1. The layers of shared meaning and their homes. The Nexus homes are V3 target-state records \[3]; the standards are cited as references, not as conformance claims.* ### The Ontology Fabric in the V3 architecture The Ontology Fabric is one of thirteen shared constitutional fabrics named in D-V3-0001 §3. Shared fabrics are not counted among the twenty canonical systems; nothing is "subsystem 21" \[1]\[2]. The fabric's remit is "semantic kernel, terms, properties, relationships, mappings, units, shapes, constraints, multilingual concepts and MeaningOps", and its boundary is: "Classification and entailment do not establish observation or substantive truth" \[1]. The fabric directive names ten canonical record families and six required services \[3]: * **Records:** semantic package, term, property, relationship type, unit definition, mapping assertion, shape, constraint, semantic version, deprecation record. * **Services:** package registry, meaning resolver, shape validation, mapping service, unit service and MeaningOps impact analysis. Among the tests the directive requires are "shape validity versus factual truth" and "deprecation impact" \[3]. That pairing states the main limit of ontology in one line: a record can be perfectly well formed and still be false. | System or fabric | Relationship to ontology | Boundary | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------ | --------------------------------------------------------------------------------------------------- | | NXS-GRX, the system for canonical data, provenance, quality, uncertainty and risk products | Binds its records, indicators and units to ontology versions | NXS-GRX owns canonical data; the Ontology Fabric owns shared meaning \[1]\[2] | | NXS-NSF, the constitutional trust, authorization, policy and assurance system | Uses ontology terms in policy, purpose and disclosure rules | Ontology defines a term; NXS-NSF policy decisions and competent actors decide what may be done \[2] | | UNI Identifier Fabric | Identifies subjects and semantic packages | Identifier resolution is not authorization, certification or truth \[1] | | NXS-GRX Graph | Records typed relationships between subjects | A graph edge is an assertion with source and confidence, not causation \[1] | | NEIF and NIRF (agent workforce and routing fabrics) | Agents and routing read ontology terms as context | Agents do not own domain facts; routing is not execution \[1] | *Table 2. The Ontology Fabric and the systems and fabrics that depend on it. Shared fabrics are not counted among the twenty systems. Source: D-V3-0001 §3; D-V3-0003.* ### A map of meaning
How a term becomes a versioned contract. A term names a concept or class, to which external vocabularies map. Relationship types and units are constrained by shapes, released as a semantic version. A domain record binds to one version and is checked against its shapes: valid means well formed, not true; invalid is rejected or corrected.

Figure 1. How a term becomes a versioned contract that a record binds to. Validation shows that a record is well formed, not that it is true. The diagram shows intended design, not a record of any run. Source: V3 Ontology Fabric directive (canonical records and required tests), as of 2026-10-16.

Text description of Figure 1 A controlled term names a concept or class. An external vocabulary connects to the concept through a mapping assertion, so vocabularies are mapped rather than forked. The class has relationship types and units or enumerations. Both are constrained by shapes. Shapes are released as a semantic version; when a term is retired, a deprecation record links the version back to the term (noted on the term and version cards rather than drawn as a line). Each domain record binds to one version and is checked against its shapes at the gate "Shape valid?": a valid record is well formed, but its truth is not established by that check; an invalid record is rejected or corrected.
### Distinctions the controlled vocabulary keeps Section 2.5 lists the terms that controlled vocabulary governs. The pairs below are the distinctions the programme most needs to keep. Each is a short form of a boundary stated in the V3 constitution or the registers. | This | Is not | Source | | --------------------------------------- | ----------------------------------------- | ---------------------------------------- | | Participation | Consent | D-V3-0004 \[4] | | Public-authority learning | Approval | D-V3-0004 \[4] | | Verification | Certification | D-V3-0004 \[4] | | Finance-readiness | Finance | D-V3-0004 \[4] | | Insurance-readiness | Underwriting | D-V3-0004 \[4] | | A warning-support candidate | An official warning | D-V3-0004 \[4] | | A decision-support package | An official decision | D-V3-0004 \[4] | | A user entitlement | Authorization | D-V3-0001 §4 \[1] | | A registry entry or resolved identifier | Authorization, certification or truth | D-V3-0001 §3 \[1] | | A catalogue listing | Recognition or endorsement | This page, after the claim registry \[8] | | A hub | An office, embassy or exclusive territory | Site narrative draft \[9] | *Table 3. Distinctions the controlled vocabulary keeps. The first nine rows quote binding sources; the last two are explanatory.* Some words need a disambiguation every time they appear: * **Rail.** NXS-RLS is system 18; One Rail-Two Stacks is a doctrine; [NXS-RLS](/organization/standardization/nexus-rail.md) is a section of the Standardization part of this site \[9]. * **Plane.** It can mean a language plane, one of the platform planes, or a plane inside NXS-GRX; say which \[9]. * **UNI.** The Universal Nexus Identifier in the recorded architecture; an earlier Nexus Standards text called it "Unique Nexus Identifier", a variant \[9]. * **System display codes.** The twenty systems are named by their Nexus Standards display codes, for example NXS-NSF, NXS-GRX, NXS-DSS, NXS-EOP, NXS-EWS, NXS-AAP, NXS-NET, NXS-OPS and NXS-SIG. The first mention on a page carries a short description of what the system is for; later mentions use the code alone. Bare acronyms such as DSS, EWS or NSF also have generic meanings and are not used to name the systems. Earlier long-form expansions of NSF (a standards foundation, a sovereignty framework and a sovereignty foundation) are historical, are not printed here as names, and denote no recorded entity \[9]. {% hint style="info" %} **Nexus Observatory Protocol.** On this site, Nexus Observatory Protocol is the observation protocol owned by NXS-OPS, the observatory protocol system, in collaboration with NXS-EOP, the Earth observation, geospatial and digital-twin fabric, and NXS-SIG, 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 %} ### Principles and their sources Identifiers ONT-n are page-local and provisional. | Id | Statement | Source | Relationship | | ----- | ------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ------------------ | | ONT-1 | Every domain record SHALL bind to a versioned ontology or schema contract, including units, enumerations and semantic applicability. | NXS-V3-0001-SEM-04 \[1] | Aligned | | ONT-2 | Classification, entailment and shape validity SHALL NOT be presented as observation or substantive truth. | D-V3-0001 §3 \[1]; fabric required tests \[3] | Aligned | | ONT-3 | Each shared term SHALL have one home and one current definition; other pages and systems link to it. | D-V3-0001 §4 ("one authoritative home owner") \[1] | Aligned | | ONT-4 | Material changes to meaning SHALL create a new semantic version or deprecation record, not a silent edit. | Fabric records semantic version, deprecation record \[3]; D-V3-0001 §13 \[1] | Aligned | | ONT-5 | Equivalence with an external vocabulary SHOULD be recorded as a mapping assertion with source and scope. | Fabric record mapping assertion \[3] | Aligned | | ONT-6 | Extensions SHOULD add specificity without redefining shared terms. | This page (section 2.15) | Extends (proposal) | | ONT-7 | Canonical identifiers and codes SHALL NOT be translated; labels MAY be. | Nexus Standards naming conventions \[5] | Aligned with draft | | ONT-8 | AI systems and agents SHOULD read controlled terms with their version and SHALL NOT treat their own classifications as authoritative. | D-V3-0001 §3 (NEIF boundary); D-V3-0005 anti-inference \[1]\[6] | Aligned | *Table 4. Ontology principles and their sources.* ### Languages and translation Canonical identifiers and codes are never translated; titles and aliases may be localized per language tag, with English as the source in the Nexus Standards naming conventions \[5]. Language tags follow BCP 47 \[19]. The Ontology Fabric's remit includes multilingual concepts, so translation is a mapping between labels of one concept, not the creation of a new one \[1]. ### External anchors | External source | Use in this page | Relationship | | ----------------------------------------------- | ------------------------------------------------------------------ | -------------------------------------------------------------------- | | W3C OWL 2 \[10] | Language for classes, properties and inference | Reference | | W3C SKOS \[11] | Controlled vocabularies, thesauri and concept schemes | Reference | | W3C SHACL \[12] | Shapes and constraints for validating records | Reference | | W3C PROV-O \[13] | Provenance of records and derivations | Reference; also cited by the Nexus Standards data profile NS-3b \[5] | | W3C DCAT 3 \[14] | Catalogue metadata for datasets | Reference; also cited by the Nexus Standards data profile NS-3b \[5] | | FAIR Guiding Principles \[15] | Interoperability through shared vocabularies | Reference | | SDMX \[16] | Statistical data and metadata exchange used by official statistics | Reference for indicator semantics | | UNDRR and ISC Hazard Information Profiles \[17] | Shared hazard definitions for disaster risk work | Reference for hazard terms | | ISO/IEC 11179 \[18] | Metadata registries and data element definitions | Reference | | BCBS 239 \[20] | Data taxonomies and unified naming in bank risk data | Analogy from banking supervision | *Table 5. External anchors for shared meaning. Citation is not endorsement, affiliation or conformance.* NIS-1 (Nexus Indicator Standard v1.0.0, a draft that requires expert review) applies these ideas to indicators, with its own identifier form for indicator concepts \[7]. How NIS-1 relates to the Nexus Standards family is not yet defined. ### What ontology is not * It is not truth. Classification and entailment do not establish observation or substantive truth \[1]. * It is not authority. Defining "approval" does not approve anything; NXS-NSF policy decisions and competent actors do that \[2]. * It is not a glossary only. A term list without relationships cannot support comparison or automation (section 2.6). * It is not frozen. It changes by recorded versions and deprecations (section 2.14). * It is not owned by any participant, provider or sponsor because they use it. *** ## 2.1 Why Ontology Comes First Ontology comes first because Nexus cannot govern what it cannot name precisely, distinguish reliably, relate coherently, and correct over time. Nexus is designed to operate across evidence, observability, standards, Registry, governance, recognition, routeability, finance-readable readiness, public legitimacy, Digital Public Goods, Marketplace, Foundry, Studio, Academy, national pathways, regional federation, public authority learning, and machine-operable protocol environments. In such a system, language cannot remain informal. Words such as “risk,” “readiness,” “recognition,” “conformance,” “standing,” “routeability,” “node,” “host,” “hub,” “public-safe,” “comparability,” “interoperability,” “maturity,” “supported,” “active,” “finance-readable,” “protocol permission,” “Registry,” and “public authority learning” must not silently shift meaning from one page, institution, platform, region, report, dashboard, or implementation pathway to another. If they do, the whole architecture weakens. Reports become non-comparable. Platforms become misleading. AI systems amplify ambiguity. Marketplace listings imply false endorsement. Nodes imply false maturity. Hosts imply false authority. Public authority learning becomes misread as adoption. Finance-readable readiness becomes misread as investment opportunity. Conformance becomes self-description. Recognition becomes courtesy. Ontology prevents that drift at the root. It gives Nexus a governed meaning layer before objects are recorded, claims are made, standards are applied, systems interoperate, or protocol permissions are enforced. *** ## 2.2 What Ontology Means in Nexus Within Nexus, ontology is the formal architecture of meaning through which the system defines entities, classes, states, relationships, claims, artifacts, records, roles, pathways, outputs, events, permissions, obligations, evidence, and lifecycle conditions. Ontology answers questions such as: What kind of object is this? What class does it belong to? What state does it hold? Who or what is related to it? What evidence supports it? What record governs it? What claims may be made about it? What claims must not be implied? What can it interoperate with? What can it be compared to? What authority does it not carry? What protocol effect, if any, may attach? What happens when its meaning changes? Ontology therefore goes beyond vocabulary. A vocabulary defines terms. A taxonomy organizes categories. A schema structures data. A registry records status. A protocol expresses machine-operable permissions. Ontology relates all of them. It is the structure of meaning beneath the operating system. *** ## 2.3 The Ontology Thesis of Nexus The ontology thesis of Nexus is that **a public-good-rooted, standards-bearing, federated, and realization-capable architecture can remain coherent across domains, jurisdictions, platforms, institutions, AI systems, and execution-adjacent pathways only if meaning is governed as infrastructure rather than treated as explanatory language**. This thesis has several implications. Meaning must be versioned. Meaning must be recorded. Meaning must be controlled. Meaning must be extensible without forking. Meaning must be usable by machines and people. Meaning must be connected to evidence, confidence, status, claims, and correction. Meaning must support public-safe publication. Meaning must be strong enough for AI systems to reason over without inventing institutional authority. Meaning must preserve domain difference without allowing domain fragmentation. Meaning must be interpretable across national, regional, global, and host layers. Ontology is therefore not a support function. It is a constitutional-operating requirement of Nexus. *** ## 2.4 Meaning as Infrastructure A core Nexus principle is that meaning is infrastructure. This is not metaphorical. It is operational. If meaning is weak, the system may still appear sophisticated. It may have reports, dashboards, platforms, nodes, forums, Marketplace objects, Academy courses, AI tools, registries, and partner networks. But beneath that visible activity, semantic instability will accumulate. Weak meaning creates hidden risk. It causes different teams to use the same term differently. It causes public claims to exceed recorded truth. It causes AI systems to summarize inaccurately. It causes dashboards to appear more authoritative than they are. It causes Marketplace users to infer recognition from listing. It causes public authorities to be misrepresented. It causes finance readers to overread readiness. It causes national and regional outputs to become non-comparable. It causes records to lose portability. Meaning infrastructure prevents those failures. It makes Nexus interpretable before it becomes scalable. *** ## 2.5 Controlled Vocabulary Controlled vocabulary is the operational expression of ontology in daily Nexus life. It ensures that terms carrying institutional, technical, public, legal, or routeability consequence retain bounded and stable meanings across the ecosystem. Controlled vocabulary should govern terms such as: * Nexus; * rail; * public-good stack; * enterprise stack; * node; * host; * hub; * observatory; * Studio; * Foundry; * Marketplace; * Registry; * Digital Public Good; * conformance; * recognition; * standing; * status; * maturity; * routeability; * comparability; * interoperability; * portability; * public-safe; * public authority learning; * public authority adoption; * qualified enterprise provider; * sponsor; * strategic backer; * [National Nexus Consortium](/organization/governance-in-operation/nnc.md); * National Consortium Company; * Project SPV; * finance-readable readiness; * supported-not-comparable; * active; * mature; * deprecated; * retired; * correction. Controlled vocabulary is not style guidance. It is governance. A term may not mean whatever a local team, partner, region, domain, platform, provider, sponsor, or user finds convenient. A term that carries consequence must be defined, scoped, governed, taught, and corrected. *** ## 2.6 Why Terminology Alone Is Not Enough Terminology alone is not enough. A list of terms can reduce confusion, but it cannot support a system like Nexus by itself. Nexus requires relational meaning. It must know not only what a “node” is, but how a node relates to a host, a hub, an observatory, an expert working group (earlier text: “competence cell”, a retired label), a Studio workflow, a public authority learning environment, a Registry record, a maturity state, and a protocol entitlement. It must know not only what “recognition” means, but how recognition differs from membership, contribution, Marketplace listing, certification, conformance, public-safe publication, public authority adoption, and finance-readable readiness. It must know not only what “routeability” means, but how routeability relates to readiness translation at the GRA readiness interface, maturity records, evidence quality, public-good / enterprise handoffs, national pathways, SPV formation, and non-execution boundaries. This is why ontology matters. Ontology defines relationships. It allows Nexus to understand not only names, but structure. Without ontology, controlled vocabulary becomes a dictionary. With ontology, controlled vocabulary becomes an operating grammar. *** ## 2.7 Ontology, Taxonomies, Schemas, and Registries Ontology, taxonomy, schema, and Registry are related but distinct. **Ontology** defines the structure of meaning: entities, classes, relationships, constraints, states, and allowed interpretations. **Taxonomy** organizes categories and hierarchies. **Schema** structures data fields, formats, identifiers, attributes, and validation rules. **Registry** records the current or historical state of objects, recognitions, statuses, claims, and corrections. These layers must work together. A taxonomy without ontology may organize labels but not meaning. A schema without ontology may validate fields but not institutional consequence. A Registry without ontology may store records but not make them reliably interpretable. A platform without ontology may display information but create public misunderstanding. Nexus requires all four. Ontology gives meaning. Taxonomy organizes it. Schema operationalizes it. Registry records it. *** ## 2.8 Ontology as the Prerequisite for AI and Automation Ontology is a prerequisite for trustworthy AI and automation in Nexus. AI systems can summarize, classify, recommend, translate, route, compare, detect, and generate. But if the semantic layer beneath them is unstable, AI will not solve ambiguity. It will amplify it. An AI system may confuse public-safe publication with public authority action. It may confuse Marketplace listing with recognition. It may confuse a node under formation with an active node. It may confuse routeability with finance execution. It may confuse a public authority learner with an adopting authority. It may confuse conformance discussion with conformance result. It may confuse technical access with lawful authority. Ontology constrains these risks. It gives AI systems controlled classes, relationships, status states, claims limits, evidence links, authority boundaries, and correction pathways. In the V3 architecture, agents belong to the NEIF agent workforce fabric, whose boundary is that agents do not own domain facts or institutional authority, and the anti-inference rule forbids any interface from inferring READY, LIVE, SECURE, COMPLIANT, CONNECTED or VERIFIED from defaults, routes, fixtures, seeds, manifests or an agent assertion \[1]\[6]. In Nexus, AI may assist interpretation. It must not invent meaning. AI may support classification. It must not become hidden authority. AI may summarize records. It must not override records. AI may help users navigate the architecture. It must remain subordinate to ontology, Registry, standards, and governance. *** ## 2.9 Epistemic Governance and Ontology Ontology in Nexus is inseparable from epistemic governance. Epistemic governance means the system distinguishes information, evidence, interpretation, intelligence, claims, status, recognition, and decision. It does not treat every data point, statement, observation, report, dashboard, or AI output as equal. Ontology must therefore support: * source classification; * evidence class; * confidence level; * provenance; * method; * review state; * public-safe state; * correction state; * temporal validity; * jurisdictional scope; * domain scope; * claims scope; * and reliance boundaries. A class label without provenance is insufficient. A risk category without confidence is insufficient. A report classification without scope is insufficient. A dashboard indicator without data lineage is insufficient. A readiness label without evidence state is insufficient. Ontology makes epistemic discipline operational. It tells the system not only what something is, but how strongly, on what basis, under what limits, and with what correction pathway it may be interpreted. *** ## 2.10 NXS-GRX as a Data and Baseline System NXS-GRX, the system for canonical data, provenance, quality, uncertainty and risk products, is one of the clearest consumers of ontology in the Nexus architecture \[2]. NXS-GRX should not be understood merely as a public index or ranking. It is a baseline, comparability, update, publication, memory and compute layer for risk intelligence across the wider Nexus architecture, and it binds its records, indicators and units to versioned meaning held by the Ontology Fabric (Table 2) \[1]\[2]. Earlier text of this page called NXS-GRX "the Semantic Spine" of the programme and expanded its name. Both are withdrawn: shared meaning is the remit of the Ontology Fabric, and no long-form expansion of NXS-GRX is printed until the owner approves one (OQ-03) \[9]. NXS-GRX helps address: * semantic fragmentation; * baseline fragmentation; * domain fragmentation; * provenance fragmentation; * temporal fragmentation; * risk-category inconsistency; * public-risk comparability gaps; * and weak cross-domain intelligence. NXS-GRX matters because risk intelligence cannot become public-good infrastructure if every domain, country, platform, report, or dashboard uses different meanings. NXS-GRX gives Nexus a governed substrate for risk categories, resilience indicators, public-safe summaries, comparative baselines, evidence states, observability inputs, and cross-domain intelligence. But NXS-GRX remains bounded. An NXS-GRX signal is not public warning by default. An NXS-GRX comparison is not regulatory classification. An NXS-GRX output is not insurance determination. An NXS-GRX risk interpretation is not investment advice. NXS-GRX is data infrastructure bound to governed meaning, not execution authority. An NXS-GRX output is evidence, not a warning, rating or regulatory classification \[4]. *** ## 2.11 Ontology and NXS-NSF Earlier text of this page named a standards foundation, abbreviated NSF, "or applicable protocol authority" as the steward of canonical semantics. Neither entity is recorded, and neither is described here as existing \[5]\[9]. NXS-NSF is the thirteenth canonical system, the constitutional trust, authorization, policy and assurance system; it is a software system, not a foundation \[2]. In the Nexus Standards (status PROPOSED), NXS-NSF as a system owns and versions the proposed standards, which other systems apply without forking; the publisher of record for the standards is not named (OQ-07) \[5]. Canonical semantics still need a steward: in the V3 architecture the records of shared meaning live in the Ontology Fabric, and the decisions about what may be done with them are NXS-NSF policy decisions and the decisions of competent actors \[1]\[2]. Ontology cannot be maintained by informal usage alone. It requires institutional stewardship, version control, extension review, schema governance, conformance tooling, developer documentation, controlled interfaces, and anti-fork discipline. The items the earlier text placed under that function are, in V3 terms, held as Ontology Fabric records, NXS-NXQ package and capability records, or NXS-NSF policy records. Role-key categories correspond most closely to NXS-RLS role definitions; smart-license semantics have no recorded source and are read as research outlook \[2]\[9]. The items are: * core ontologies; * controlled vocabularies; * taxonomies; * schemas; * DSLs; * APIs; * manifests; * pack formats; * profile structures; * conformance tooling; * role-key categories; * smart-license semantics; * and Nexus Improvement Proposal processes. This does not mean any system invents public law or sovereign authority. It means the canonical semantic and technical grammar of the system is preserved. Ontology gives the common rail meaning. Versioned records and policy decisions help keep that meaning stable, extensible, and machine-operable. *** ## 2.12 Schemas, DSLs, APIs, Manifests, and Semantic Operability Ontology becomes operational through schemas, domain-specific languages, APIs, manifests, pack formats, metadata structures, and machine-readable interfaces. These are not merely developer conveniences. They are how meaning becomes enforceable and portable. A controlled term can be tied to a schema field. A schema can be tied to a profile. A profile can be tied to a control. A control can be tied to a check. A check can be tied to evidence. Evidence can be tied to a Registry record. A Registry record can be tied to a claim. A claim can be tied to a protocol entitlement. This chain is what allows Nexus meaning to move from prose to system behavior. Semantic operability means that ontology is not trapped in documentation. It becomes part of the way platforms, tools, agents, dashboards, registries, Marketplace objects, Foundry packages, and Studio workflows behave. *** ## 2.13 Ontology and NXOSI NXOSI connects ontology to operational standards infrastructure. NXOSI (described on this site as [Nexus OSI](/organization/standardization/nexus-osi.md)) is a proposed reference model; it is not a V3 system or shared fabric, it has no counterpart in the recorded architecture, and its relationship to the proposed Nexus Standards awaits owner decision \[5]\[9]. In the NXOSI view, semantics are not isolated from runtime behavior. They inform profiles, controls, checks, evidence, proof, routing, correction, and learning. This matters because Nexus does not want standards to remain static text. It wants governed meaning to become reviewable, testable, portable, and correctable across live systems. Ontology informs: * what profile applies; * what control is relevant; * what check should be run; * what evidence counts; * what proof may be portable; * what route is permitted; * what correction is required; * and what learning should feed back into the system. NXOSI therefore turns ontology into part of operational trust. It helps Nexus answer not only “what does this mean?” but “how does this meaning behave in practice?” *** ## 2.14 Ontology Versioning A serious ontology must be versioned. Domains evolve. Technologies change. New object classes emerge. Public authority contexts change. AI capabilities change. New node types, Marketplace objects, Studio workflows, Foundry packages, route classes, evidence categories, and public-safe classifications will be needed. If ontology cannot evolve, Nexus becomes brittle. If ontology evolves silently, Nexus becomes unstable. Ontology versioning solves this problem. Ontology versioning should be: * explicit; * dated; * stewarded; * documented; * reviewable; * linked to change logs; * linked to compatibility notes; * linked to migration guidance where needed; * connected to Registry and platform updates; * and subject to no-silent-edit discipline. A term can change. A class can be added. A relation can be refined. A status can be deprecated. But changes affecting meaning, claims, status, interoperability, or reliance must be traceable. Ontology continuity depends on version discipline. The V3 records express this through semantic version and deprecation record, and through the correction constitution: correction outranks continuity, and last-write-wins is prohibited for identity, policy and signed evidence (D-V3-0001 §13) \[1]\[3]. Mappings to external vocabularies are recorded as mapping assertion records, so that equivalence is an assertion with a source, not an assumption \[3]. *** ## 2.15 Ontology Extensions and the No-Fork Rule Nexus must allow ontology extensions because it works across many domains, regions, hosts, technologies, and public authority contexts. A water domain may need basin-specific terms. A health domain may need biosecurity classifications. A finance domain may need readiness and routeability categories. A regional pathway may need corridor classifications. A national pathway may need lawful-basis attributes. A Studio workflow may need dashboard output classes. A Marketplace object may need capability-specific metadata. Extensions are legitimate when they add needed specificity. But extensions must not fork the core. A domain may extend the ontology. It may not redefine common terms. A region may localize categories. It may not create incompatible status meanings. A host may add operational fields. It may not turn host status into sovereignty. A provider may propose metadata. It may not control the common rail. A public authority context may require special classifications. It may not silently convert learning into adoption. The no-fork rule preserves controlled adaptability. Nexus can grow semantically without fragmenting. *** ## 2.16 Cross-Domain Reasoning Ontology enables cross-domain reasoning. Nexus is designed for interconnected lifeline and all-of-society realities. Water, energy, food, health, biodiversity, climate, finance, infrastructure, AI, cyber, media, work, education, public authority capacity, and community systems are not isolated. A drought may affect water, food, energy, health, migration, finance, public legitimacy, and infrastructure. A cyberattack may affect energy, hospitals, telecom, water systems, public trust, insurance, and public authority capacity. A compute buildout may affect energy demand, water use, national infrastructure, AI capability, industrial policy, public authority readiness, and finance. Ontology allows these relations to be represented without collapsing each field into one generic category. It preserves domain specificity while enabling system reasoning. This is one of the deepest purposes of Nexus. The common rail does not erase domains. It relates them. *** ## 2.17 Ontology, Baselines, and Comparability Comparability depends on ontology. Two things cannot be compared meaningfully if their categories, evidence assumptions, confidence levels, status labels, timeframes, scopes, or public-safe constraints differ invisibly. Ontology supports comparability by defining: * object classes; * domain categories; * evidence classes; * time states; * location states; * jurisdictional scope; * maturity states; * support states; * public-safe states; * route classes; * conformance profiles; * and claims boundaries. Comparability is not sameness. It is disciplined translation under known conditions. A national node may be comparable to another national node only under declared criteria. A report may be comparable to another report only if evidence, scope, and method allow comparison. A Marketplace object may be comparable to another object only within its class. A risk indicator may be comparable across countries only when baseline, provenance, and temporal assumptions are aligned. Ontology is what makes these conditions explicit. *** ## 2.18 Ontology and Interoperability Interoperability also depends on ontology. Systems cannot truly interoperate if they do not share meaning. Data exchange is not enough. API connectivity is not enough. Platform integration is not enough. Two systems may exchange data and still misunderstand one another if the categories, status fields, evidence assumptions, or authority boundaries differ. Ontology supports semantic interoperability by ensuring that exchanged objects carry controlled meaning. It supports institutional interoperability by clarifying roles, statuses, authority, and claims. It supports technical interoperability through schemas, APIs, manifests, and conformance profiles. It supports public authority interoperability by classifying capacity and lawful boundaries. It supports AI interoperability by providing machine-usable semantic structure. Interoperability in Nexus is therefore disciplined translation, not mere connection. Ontology is the translation layer. *** ## 2.19 Ontology and Validity by Record Nexus is a validity-by-record system. That means important states, roles, classifications, recognitions, statuses, corrections, and lifecycle changes must be recordable and interpretable. Ontology makes those records meaningful. A record is only useful if the system knows what kind of thing it records. A “node” record must identify node class, host relation, status, maturity, scope, public-safe posture, and lifecycle state. A “provider” record must distinguish applicant, listed, qualified, suspended, deprecated, or retired status. A “public authority” record must distinguish learner, observer, consultee, adopting authority, procurement authority, regulator, or public-warning authority. A “report” record must distinguish draft, public-safe, published, corrected, superseded, withdrawn, or archived. A “recognition” record must state scope, issuer, basis, version, duration, and claim limits. Ontology makes validity by record possible because it gives records controlled meaning. Without ontology, records become entries. With ontology, records become governed memory. *** ## 2.20 Ontology and Registry Registry operationalizes ontology. The Registry records statuses, recognitions, conformance results, lifecycle states, public-safe publication states, Marketplace listings, Digital Public Goods, providers, nodes, hosts, reports, councils, guilds, members, pathways, corrections, and archived states. Ontology tells the Registry what each record means. The Registry tells the system what the current and historical state is. This relationship is essential. A Registry entry is not automatically recognition. It may be a listing record, a membership record, a correction record, a public-safe publication record, a conformance record, a maturity record, or an archive record. Ontology allows the Registry to distinguish those record classes. It prevents users from treating every record as approval. It ensures that “recorded” does not become “recognized” unless recognition is actually the recorded state. *** ## 2.21 Semantic Governance and Public Claims Ontology protects public claims. Public claims often drift because terms are vague. A true but narrow statement becomes misleading when audiences infer broader meaning. For example: A node under formation may be called a Nexus Node, but it must not imply active maturity. A public authority may attend a learning forum, but that must not imply adoption. A Marketplace object may be listed, but that must not imply endorsement. A report may be public-safe, but that must not imply public authority approval. A provider may be qualified for one scope, but that must not imply universal provider approval. A project may be finance-readable, but that must not imply investment advice or capital commitment. Ontology supports claims discipline by defining the exact class, state, scope, and implication boundary of each object. Public language should follow ontology. Media language should follow ontology. Platform labels should follow ontology. Partner language should follow ontology. AI summaries should follow ontology. Claims discipline is semantic governance in public form. *** ## 2.22 Ontology and Public-Safe Publication Public-safe publication depends on semantic classification. A public-safe output is not simply content that is well written. It is content classified as suitable for public release under defined limits. Ontology should distinguish: * public; * public-safe; * controlled; * restricted; * confidential; * sensitive; * protected knowledge; * sensitive geography; * public authority-sensitive; * market-sensitive; * procurement-sensitive; * security-sensitive; * health-sensitive; * biosecurity-sensitive; * community-reviewed; * anonymized; * redacted; * archived. These classes matter because Nexus deals with high-consequence information. A map, dashboard, report, case study, risk indicator, node record, or community contribution may be useful but not fully public. Ontology helps decide what can be published, in what form, with what caveats, and under what claims limits. It prevents public-facing clarity from becoming unsafe disclosure. *** ## 2.23 Ontology and Public Authority Capacity Public authority capacity requires controlled semantics. A public authority may appear in Nexus in many capacities: * learner; * observer; * consultee; * host; * sponsor; * competent authority; * adopting authority; * procurement authority; * regulator; * emergency authority; * public-warning authority; * implementation partner. These are not interchangeable. A public authority learner is not adopting. An observer is not approving. A consultee is not endorsing. A host is not sovereign over Nexus. A procurement authority must act through procurement law. A regulator must act through regulatory mandate. A public-warning authority must act through its own lawful process. Ontology should require capacity classification whenever public authority involvement is recorded, published, displayed, summarized, or routed. This protects public authorities, Nexus, and the public. *** ## 2.24 Ontology and Finance-Readable Readiness Finance-readable readiness also requires controlled semantics. Finance-facing language is especially vulnerable to overclaim. Ontology should distinguish: * early concept; * project concept; * routeable idea; * readiness artifact; * finance-readable record; * diligence-ready package; * sponsor-supported pathway; * capital discussion; * capital commitment; * Project SPV concept; * Project SPV formed; * investment vehicle; * financial close; * insured; * rated; * underwritten; * procured; * executed. A finance-readable object is not investment advice. A routeability record is not a credit rating. A readiness report is not underwriting. A Project SPV explainer is not securities offering. A sponsor-capital map is not capital commitment. Ontology allows Nexus to communicate with finance readers without accidentally becoming a market actor. *** ## 2.25 Ontology and Nodes, Hosts, and Hubs Nodes, hosts, and hubs require especially precise ontology because they are practical, visible, and easy to overread. A **Nexus Node** should be defined as a recorded place-based, institutional, technical, observability-bearing, learning, or runtime environment carrying a defined Nexus function under a declared status. A **Host** should be defined as the institution, environment, or operating context that supports a node, room, observatory, Academy function, Studio workflow, public authority learning environment, Digital Public Good deployment context, forum, or pathway under defined obligations. A **Hub** should be defined as a higher-density coordination, learning, observability, pathway-support, or ecosystem-support environment whose role is established by function and record, not prestige alone. Ontology must distinguish: * proposed node; * candidate node; * pilot node; * active node; * mature node; * suspended node; * retired node; * host; * backup host; * anchor host; * regional hub; * national hub; * observatory hub; * learning hub; * Studio hub; * technical hub. These states must not be blurred. A proposed node is not active. An active node is not mature by default. A host is not sovereign. A hub is not regional supremacy. A dashboard in a node is not public warning by default. Precise ontology makes runtime architecture legible without inflating it. *** ## 2.26 Ontology and Marketplace Objects Marketplace requires ontology because it contains many object types. A Marketplace may include: * apps; * connectors; * packs; * agents; * swarms; * observatory patterns; * dashboards; * Studio workflows; * training offerings; * Digital Public Goods; * implementation services; * providers; * support packages; * data products; * domain templates; * public authority learning resources. These must be typed. A connector is not a pack. A pack is not a rail. A service is not a standard. A provider profile is not endorsement. A Marketplace listing is not recognition by default. A badge is not universal approval. Ontology should define object class, support status, conformance posture, provider identity, version, lifecycle state, public-safe limits, jurisdictional limits, and claims scope. Marketplace discovery depends on semantic precision. Otherwise, visibility becomes implied trust. *** ## 2.27 Ontology and Digital Public Goods Digital Public Goods require ontology because open assets still need classification. A Digital Public Good may be: * software; * dataset; * schema; * model; * documentation; * curriculum; * dashboard; * connector; * pack; * public-safe template; * methodology; * training material; * API; * reference implementation; * standard profile. Ontology should define: * asset class; * license; * steward; * version; * support status; * maintenance status; * security status; * dependencies; * contribution rules; * public-safe posture; * compatibility; * conformance posture; * lifecycle state; * and authorized forks or variants. Open does not mean maintained. Public does not mean public-safe for all uses. Reusable does not mean endorsed. A fork is not authorized architecture by default. Ontology helps Digital Public Goods remain usable, trustworthy, and non-enclosed. *** ## 2.28 Ontology and Foundry Objects Foundry objects require semantic structure because build activity moves through stages. A Foundry object may be: * concept; * requirement; * prototype; * experiment; * package candidate; * release candidate; * maintained package; * deprecated package; * retired package; * connector; * workflow; * template; * dashboard module; * data schema; * agent; * observatory pattern; * Studio component; * Digital Public Good. Ontology should define build state, test state, support state, dependency state, conformance posture, release status, and handoff conditions. A prototype is not a release. A release candidate is not deployment authorization. A tested component is not universal conformance. A Foundry package is not public authority adoption. Ontology prevents build momentum from becoming maturity inflation. *** ## 2.29 Ontology and Studio Workflows Studio workflows require precise ontology because interfaces can appear authoritative. A Studio object may be: * dashboard; * simulation; * controlled room; * workflow; * AI assistant; * decision-support interface; * observability panel; * public authority learning environment; * scenario tool; * map; * digital twin; * risk indicator; * node interface; * host status panel. Ontology should define: * workflow class; * data source state; * update frequency; * user role; * access level; * public-safe status; * output class; * reliance boundary; * authority boundary; * correction pathway; * and public authority capacity where applicable. A dashboard is not public warning by default. A simulation is not forecast certainty. A workflow is not lawful decision-making. A controlled room is not a regulator. Ontology prevents visual and interactive power from becoming implied authority. *** ## 2.30 Ontology and Reports, Media, and Forum Outputs Reports, Media, and Forum outputs also require ontology. A report may be draft, working, public-safe, published, corrected, superseded, withdrawn, or archived. A media output may be explanatory, editorial, announcement, recap, interview, campaign content, or public-safe summary. A forum output may be transcript, summary, recommendation, issue log, learning record, media recap, report candidate, governance referral, standards question, or archive. These classes are different. A forum summary is not a report by default. A media recap is not a decision. A report draft is not a published report. A recommendation is not adoption. An interview is not institutional position unless authorized. Ontology helps users understand what kind of output they are reading and what consequence it carries. *** ## 2.31 Ontology and Membership, Guilds, Councils, Domains, and Pathways Cooperation requires ontology. Membership classes, guild roles, council states, domain families, pathway states, contributor records, sponsor roles, provider roles, public authority capacities, and national pathway stages must all be semantically defined. Ontology should distinguish: * observer; * member; * contributor; * guild participant; * guild steward; * working group participant; * council candidate; * council member; * sponsor; * strategic backer; * provider applicant; * qualified enterprise provider; * institutional member; * public authority learner; * public authority adopter; * host-linked participant; * node participant; * [National Working Group](/organization/governance-in-operation/nwg.md); * [National Nexus](/organization/governance-in-operation/national-nexus.md) Consortium; * National Consortium Company; * Project SPV. These states must not collapse. Membership is not authority. Guild participation is not standards authority. Council candidacy is not appointment. Sponsorship is not control. Provider status is not endorsement unless recorded. National Working Group is not National Nexus Consortium. National Consortium Company is not Project SPV. Ontology makes cooperation governable. *** ## 2.32 Ontology and Federation Federation depends on ontology because Nexus must operate across global, regional, national, host, and local layers without hidden centralization or fragmentation. Ontology should define: * global layer; * regional layer; * national layer; * host layer; * node layer; * corridor; * basin; * shared ecology; * support-versus-comparable status; * country wave; * regional node; * national node; * host status; * regional hub; * national primacy; * public authority capacity; * regional comparability; * local adaptation; * canonical core; * extension; * fork. Federation becomes unstable when these terms drift. A regional pathway is not regional supremacy. A corridor interface is not supranational authority. A national node is not global maturity by default. A local adaptation is not a fork if governed. Ontology allows federation to preserve local truth and global coherence at the same time. *** ## 2.33 Ontology and Public-Good / Enterprise Stack Separation Ontology must preserve the separation between the public-good stack and the enterprise / execution stack. This means defining object classes and actor roles clearly. Public-good stack objects may include: * ontology; * standards; * Registry records; * public-safe reports; * Digital Public Goods; * Academy materials; * recognition records; * conformance profiles; * public-good software; * methods; * observability records. Enterprise and execution stack objects may include: * provider services; * implementation contracts; * Marketplace service offerings; * National Consortium Companies; * Project SPVs; * commercial deployments; * infrastructure operations; * capital transactions; * delivery vehicles. These categories may interact, but they must not collapse. A public-good method is not a commercial delivery mandate. A provider service is not public-good authority. A Project SPV is not Nexus. A commercial implementation does not control the rail. Ontology keeps the boundary visible. *** ## 2.34 Semantic Governance and Public-Safe Claims Semantic governance is one of the principal safeguards for public-safe claims. Public-safe claims must be: * classed correctly; * scoped correctly; * supported by record; * aligned to status; * limited by authority boundary; * compatible with public authority capacity; * consistent with evidence quality; * reviewed where required; * and correctable. Ontology helps prevent phrases such as “approved,” “certified,” “recognized,” “active,” “mature,” “finance-ready,” “public authority-linked,” “validated,” “interoperable,” and “Nexus-aligned” from being used casually. A public-safe claim should always map to a defined class and record. If it cannot be mapped, it should not be made. *** ## 2.35 Ontology Stewardship Ontology requires stewardship. It cannot preserve itself. Ontology stewardship should include: * maintaining controlled vocabulary; * reviewing new terms; * maintaining taxonomies; * maintaining schemas; * coordinating with NXS-NSF policy decisions on standards; * coordinating with Registry; * reviewing extensions; * preventing forks; * publishing change logs; * issuing migration guidance; * reviewing public claims; * training users; * supporting AI alignment; * correcting semantic errors; * retiring deprecated terms; * and maintaining documentation. Stewardship should be institutional, not ad hoc. A meaning layer maintained by informal habit will eventually drift. A meaning layer maintained by stewardship can evolve without losing integrity. *** ## 2.36 Ontology Governance Process A serious ontology needs a governance process. The process should define how terms, classes, relations, schemas, attributes, status states, and extensions are proposed, reviewed, accepted, revised, deprecated, or retired. A governance process may include: * proposal; * intake; * classification; * impact review; * standards review; * Registry impact review; * platform impact review; * AI and automation impact review; * public-safe review; * domain consultation; * national or regional consultation where relevant; * approval; * versioning; * publication; * training update; * implementation; * correction; * archival. This process should be proportionate. Not every wording change requires full governance. But any change affecting status, claims, interoperability, protocol effect, public authority meaning, or reliance should be controlled. Ontology governance is how Nexus changes meaning without losing trust. Who decides is not yet recorded. The V3 fabric directive defines the records and services, including MeaningOps impact analysis, not an institutional decision body, and this page does not create one \[3]. Decisions stay with competent actors. *** ## 2.37 Ontology Training and Attestation Ontology must be taught. Participants who use controlled terms in reports, platforms, Registry records, Marketplace listings, public-safe publications, Studio workflows, public authority learning environments, protocols, or public claims should receive appropriate training. Training may cover: * controlled vocabulary; * role terms; * status terms; * claims limits; * public-safe language; * Registry classes; * conformance terms; * comparability terms; * public authority capacity; * finance-readable readiness; * Marketplace object classes; * node and host terminology; * AI summary rules; * correction pathways. Certain roles may require attestation before activation. A person who publishes Registry-linked records should understand Registry ontology. A person who writes public-facing claims should understand claims scope. A person who configures Studio workflows should understand authority boundaries. A person who uses AI tools should understand semantic constraints. Ontology training is part of standards integrity. *** ## 2.38 Ontology and Correctionability Ontology must be correction-capable. Semantic errors will occur. A term may be misused. A class may be inadequate. A relation may be wrong. A status may be misleading. A public claim may exceed ontology. A platform label may drift. An AI system may misclassify an object. Correction pathways should allow: * semantic correction; * term clarification; * class update; * relation update; * public claim correction; * Registry correction; * platform label correction; * schema update; * AI instruction update; * deprecated term notice; * migration note; * public clarification; * and archival record. Correction should be traceable where meaning or reliance is affected. A correctable ontology is stronger than a brittle ontology. The purpose is not to pretend meaning never changes. The purpose is to make change governable. *** ## 2.39 Ontology and No-Silent-Edit Discipline No-silent-edit discipline applies to ontology. Material changes to terms, classes, relations, schemas, status labels, public claims categories, or protocol-relevant meanings should not disappear without trace. No-silent-edit discipline may require: * version numbers; * effective dates; * change logs; * supersession notes; * deprecated term lists; * migration guidance; * compatibility notes; * steward identification; * and archive copies. This protects users who relied on earlier meanings. It protects public-facing claims. It protects AI systems from silently shifting interpretation. It protects Registry records from becoming ambiguous. It protects the common rail from memory loss. *** ## 2.40 Ontology and Future-Proofing Ontology is future-proofing infrastructure. Nexus spans fast-changing technologies and domains: AI, agentic systems, AI-RAN, O-RAN, private wireless, national compute infrastructure, cyber, robotics, drones, sensing, digital twins, geospatial intelligence, quantum-relevant systems, blockchain, DePIN, climate systems, biodiversity, health, biosecurity, disaster risk, finance, education, work, media, and public authority capacity. New object classes will emerge. New risks will appear. New public authority capacities may need classification. New Marketplace objects will be introduced. New Studio workflows will be built. New protocol states may be required. These technologies are subject domains the ontology must be able to describe. Naming them here does not present any of them as Nexus architecture; distributed-ledger, blockchain and DePIN constructs in particular are research outlook unless a recorded source shows otherwise \[9]. A future-proof ontology must be stable enough to preserve continuity and extensible enough to absorb novelty. This is why versioning, extensions, no-fork discipline, and stewardship are essential. Ontology allows Nexus to adapt without losing itself. *** ## 2.41 Ontology Failure Modes Nexus should be explicit about ontology failure modes. **Semantic drift** occurs when controlled terms acquire different meanings in different contexts. **Glossary reduction** occurs when ontology is treated as a term list rather than relational meaning infrastructure. **Taxonomy rigidity** occurs when categories cannot adapt to new realities. **Extension sprawl** occurs when domains, regions, hosts, or providers add incompatible semantic variants. **AI amplification drift** occurs when AI systems reproduce or amplify uncontrolled meanings. **Registry ambiguity** occurs when records exist but their classes and implications are unclear. **Public claims inflation** occurs when undefined or loosely defined terms allow overclaim. **Platform label drift** occurs when interface labels imply greater status than the ontology supports. **Marketplace confusion** occurs when listings, badges, support states, and recognition states are blurred. **Public authority misclassification** occurs when learning, observation, consultation, adoption, regulation, procurement, and public warning are not distinguished. **Finance-readiness overclaim** occurs when routeability or readiness terms imply finance execution. **Protocol overreach** occurs when technical permission is treated as lawful authority. **No-version failure** occurs when ontology changes without trace. **No-correction failure** occurs when semantic errors cannot be corrected. Ontology governance exists to prevent these failures. | Failure mode | First defence | | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Semantic drift; no-version failure | One home per term and versioned change (ONT-3, ONT-4) | | Glossary reduction | The five layers of Table 1 | | Taxonomy rigidity; extension sprawl | Versioned extension and mapping assertions (ONT-4, ONT-5, ONT-6) | | AI amplification drift | Versioned terms for agents; anti-inference (ONT-8) | | Registry ambiguity; public claims inflation; platform label drift; Marketplace confusion | Typed records and outputs ([IV. Registry](/organization/introduction/standardization/iv.-registry.md), [VI. Outputs](/organization/introduction/standardization/vi.-outputs.md)) | | Public authority misclassification; finance-readiness overclaim | Boundary formulas (Table 3) \[4] | | Protocol overreach | A user entitlement is not authorization \[1] | | No-correction failure | Deprecation records and correction references (ONT-4) | *Table 6. Ontology failure modes mapped to the principles of this page. Source: this page and D-V3-0001, D-V3-0004, D-V3-0005.* *** ## 2.42 Strategic Value of Ontology The strategic value of ontology is that it allows Nexus to become large without becoming semantically loose. Ontology lets many institutions use one architecture. It lets many domains remain distinct but relatable. It lets AI systems operate over controlled meaning. It lets public claims stay bounded. It lets Registry records be interpretable. It lets Marketplace objects be discoverable without becoming overclaimed. It lets Foundry packages move through controlled build states. It lets Studio workflows become powerful without becoming hidden authority. It lets reports, media, and forum outputs carry the right status. It lets public authorities engage without being misrepresented. It lets finance readers distinguish readiness from execution. It lets national and regional pathways localize without forking. It lets nodes, hosts, and hubs become legible runtime objects. In strategic terms, ontology is the semantic operating system of Nexus. It is how the system knows what it is saying before others act on it. *** ## 2.43 Final Statement on Ontology Ontology, controlled vocabulary, and semantic governance form the meaning infrastructure of Nexus. They make the architecture capable of operating across institutions, jurisdictions, domains, public authorities, platforms, AI systems, registries, standards, reports, Marketplace objects, Foundry packages, Studio workflows, Digital Public Goods, nodes, hosts, hubs, national pathways, regional pathways, and lawful realization contexts without dissolving into ambiguity. Ontology is not commentary on Nexus. It is part of Nexus. It governs what things are, how they relate, what states they hold, what claims may be made, what records mean, what may be compared, what may interoperate, what AI may infer, what public language may say, and what must be corrected when meaning drifts. Through ontology, Nexus can preserve controlled meaning while adapting to new domains, technologies, risks, institutions, and geographies. Through controlled vocabulary, Nexus can speak consistently. Through semantic governance, Nexus can prevent overclaim. Through NXS-GRX, Nexus gains a semantic and baseline spine for risk intelligence. Through schemas, APIs, manifests, profiles, and protocol interfaces, Nexus makes meaning machine-operable. Through versioning, extensions, no-fork discipline, and correctionability, Nexus evolves without losing continuity. In Nexus, meaning is infrastructure. Ontology is the infrastructure of meaning. *** ## Terms used on this page | Term | Definition | Source | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------- | | Ontology | A formal, explicit specification of classes, properties and relationships in a domain | W3C OWL 2 \[10] | | Controlled vocabulary | A set of governed terms with preferred labels and definitions | W3C SKOS \[11] | | Ontology Fabric | The V3 shared fabric for semantic kernel, terms, properties, relationships, mappings, units, shapes, constraints and multilingual concepts | D-V3-0001 §3 \[1] | | Semantic version | A released, identified version of a semantic package to which records bind | Ontology Fabric directive \[3] | | Mapping assertion | A recorded, sourced statement that a term corresponds to another vocabulary's term | Ontology Fabric directive \[3] | | Shape | A constraint set that validates the structure of a record | W3C SHACL \[12]; Ontology Fabric directive \[3] | ## Related pages * Up: [Standardization introduction](/organization/introduction/standardization.md) * Across: [I. Order](/organization/introduction/standardization/i.-order.md) · [III. Status](/organization/introduction/standardization/iii.-status.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: [Knowledge architecture](/organization/introduction/knowledge/ii.-knowledge-architecture.md) · [Nexus OSI](/organization/standardization/nexus-osi.md) · [Interoperability by default](/organization/standardization/nexus-ecosystem/iii.-infrastructure/principles/interoperability-by-default-in-the-nexus-ecosystem.md) · [Nexus Standards definition](/organization/organization/architecture/ii.-definitions/xii.-nexus-standards.md) ## Sources 1. Nexus constitutional directive D-V3-0001, *Master Architecture, Product and Production Build Directive V3.0*: section 3 shared constitutional fabrics (Ontology Fabric, UNI Identifier Fabric, NXS-GRX Graph, NEIF, NIRF); section 4 authority invariants; section 13 correction constitution; requirement NXS-V3-0001-SEM-04. Internal record, cited by identifier. 2. Nexus constitutional directive D-V3-0003, *Canonical Twenty-System Constitution and Authority Matrix* (NXS-GRX, NXS-NSF, NXS-NXQ and NXS-RLS remits). Internal record, cited by identifier. 3. Nexus V3 shared-fabric directive *Ontology Fabric V3.0 Directive* (canonical records, required services, required tests). Non-binding normative source until cutover. Internal record, cited by title. 4. Nexus constitutional directive D-V3-0004, *One Rail-Two Stacks, Non-Execution and Lawful Handoff Constitution*, boundary formulas. Internal record, cited by identifier. 5. Nexus Standards, as published at nexustandards.com (every standard PROPOSED; legal review required): standards register (NXS-NSF owns and versions), geospatial naming conventions ("canonical names never translated") and NS-3b data profile (STAC, DCAT, PROV-O), status proposed; superseded on publication: GCRI Canada, as Secretariat, is publisher of record. Draft source. 6. Nexus constitutional directive D-V3-0005, *Product Truth, Claims, Evidence and Promotion Constitution*, anti-inference rule. Internal record, cited by identifier. 7. Nexus Indicator Standard NIS-1, version 1.0.0, a draft that requires expert review. Internal record, cited by identifier. 8. Nexus release hold policy (active), claim registry and capability ledger entry for the Ontology Fabric. Internal record. 9. Nexus Documentation Standard, draft of 16 October 2026: terminology, disambiguation and research-outlook framing, with the owner decisions of 16 October 2026; institutional site narrative draft for the hub definition. Internal editorial standard. 10. W3C (2012-12-11). *OWL 2 Web Ontology Language Document Overview (Second Edition)*. [w3.org](https://www.w3.org/TR/owl2-overview/). Accessed 2026-10-16. 11. W3C (2009-08-18). *SKOS Simple Knowledge Organization System Reference*. [w3.org](https://www.w3.org/TR/skos-reference/). Accessed 2026-10-16. 12. W3C (2017-07-20). *Shapes Constraint Language (SHACL)*. [w3.org](https://www.w3.org/TR/shacl/). Accessed 2026-10-16. 13. W3C (2013-04-30). *PROV-O: The PROV Ontology*. [w3.org](https://www.w3.org/TR/prov-o/). Accessed 2026-10-16. 14. W3C (2024). *Data Catalog Vocabulary (DCAT) Version 3*. [w3.org](https://www.w3.org/TR/vocab-dcat-3/). Accessed 2026-10-16. 15. Wilkinson, M. D. et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. *Scientific Data* 3, 160018. [doi.org](https://doi.org/10.1038/sdata.2016.18). Accessed 2026-10-16. 16. SDMX sponsoring organizations. *SDMX: Statistical Data and Metadata eXchange*. [sdmx.org](https://sdmx.org/). Accessed 2026-10-16. 17. UNDRR and International Science Council (2021). *Hazard Information Profiles: Supplement to the UNDRR-ISC Hazard Definition and Classification Review*. Check for later updates before reliance. (URL not verified) 18. ISO and IEC. *ISO/IEC 11179 Information technology: Metadata registries (MDR)*, multi-part standard. (URL not verified) 19. IETF (2009). *RFC 5646, Tags for Identifying Languages* (BCP 47). [rfc-editor.org](https://www.rfc-editor.org/rfc/rfc5646). Accessed 2026-10-16. 20. Basel Committee on Banking Supervision (2013-01). *Principles for effective risk data aggregation and risk reporting* (BCBS 239). [bis.org](https://www.bis.org/publ/bcbs239.htm). Accessed 2026-10-16. 21. 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. 22. 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. 23. 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. 24. 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. 25. Nexus Standards (2026). *NS-15: System Model Binding*, UNI NXS-STD-ST-000014, status PROPOSED. [nexustandards.com/standards/ns-15](https://nexustandards.com/standards/ns-15/). 26. Nexus Standards (2026). *NS-3b: Dataset and Product Metadata Profile (STAC, DCAT, PROV-O)*, UNI NXS-STD-SW-000005, status PROPOSED. [nexustandards.com/standards/ns-3b](https://nexustandards.com/standards/ns-3b/). 27. Nexus Standards (2026). *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/). 28. Rinaldi, S. M., Peerenboom, J. P. and Kelly, T. K. (2001). Identifying, understanding, and analyzing critical infrastructure interdependencies. IEEE Control Systems Magazine 21(6): 11–25. doi:10.1109/37.969131. [doi.org](https://doi.org/10.1109/37.969131). 29. 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. 30. 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, layer table, Ontology Fabric records and services, ontology map, distinctions table, disambiguations, principles, languages, external anchors and "what ontology is not" added; drafting residue citing an unseen "source text" removed; NXS-GRX no longer called the "semantic spine" and its name no longer expanded; the earlier long-form NSF expansion and "protocol authority" replaced by NXS-NSF as a system and the Ontology Fabric; NXOSI marked as a proposed reference model; "sovereign" product wording corrected; 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/ii.-ontology.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.