> 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/cooperation/nexus-guilds/future-of-web/viii.-grix-ontology.md).

# VIII. NXS-GRX Ontology

Canonical Semantics, Lineage, and Standards Mapping for Enterprise Web Intelligence

**Where this fits:** all six sectors ([The Model](/organization/model.md)) · [Labs](/organization/programme/labs.md), [Risk Academy](/organization/programme/academy.md) · communities of practice by sector, supplying the questions of the Labs pillar; National Working Groups ([NWG](/organization/governance-in-operation/nwg.md)) · community of practice.

**In brief.** Canonical Semantics, Lineage, and Standards Mapping for Enterprise Web Intelligence Read against the international frameworks it serves ([UN General Assembly 2015](https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030); [FAO 2014](https://www.fao.org/4/bl496e/bl496e.pdf); [One Health High-Level Expert Panel (OHHLEP) et al. 2022](https://doi.org/10.1371/journal.ppat.1010537)) and the [Nexus Standards](/organization/institutions/nexus-standards.md) that govern its records ([NS-0](https://nexustandards.com/standards/ns-0/), [NS-13](https://nexustandards.com/standards/ns-13/)). "An experiment is exploratory: its results are labelled as such and become evidence only after the Foundry rebuilds and the Universe tests them." (Labs pillar boundary). Ordinary participation has no fee. Paid work, internships and fellowships are separate arrangements, and unqualified contributors never take safety-critical tasks.

{% hint style="info" %}
**Read with the current model (2026-10-21).**

* Everything this page describes is a design in formation. No national, regional or global consortium is recorded as constituted or active; the current service level is R0, information and enquiries ([Status and service levels](/organization/governance-in-operation/status-and-service-levels.md)). Where the text below reads as operation, read it as design.
* Recognition, scoring and validation record what was shown under stated conditions. None is a certification, licence, rating or approval, and no country or institution is ranked.
* Systems are named by their NXS display codes (for example [NXS-RLS](/organization/systems/nxs-rls.md) for participants, agreements, protocols, obligations and lawful handoffs); see [Systems](/organization/systems.md).
  {% endhint %}

### Part 8 — NXS-GRX Web Ontology and Interoperability Spine

#### 1. Status, Purpose, and Design Constraints

1.1 **Status.** The [NXS-GRX](/organization/systems/nxs-grx.md) (canonical data, provenance and risk) Web Ontology (“NXS-GRX-Web”) is the canonical semantic spine for all Guild outputs in the web domain. It is the required mapping layer for observables, evidence, determinations, benchmarks, and release artifacts used by the platform.

1.2 **Purpose.** NXS-GRX-Web exists to make web intelligence:\
1.2.1 **comparable** across organizations, jurisdictions, and time;\
1.2.2 **auditable** through explicit lineage and transformation records;\
1.2.3 **replayable** via stable object definitions and versioned mappings;\
1.2.4 **interoperable** with W3C/IETF/ICANN ecosystems and enterprise security tooling;\
1.2.5 **correctionable** through formal deprecation and supersession discipline.

1.3 **Design constraints (mandatory).**\
1.3.1 **Open-by-default** for schemas and mappings (Digital Public Good posture), with controlled disclosures only where required for safety.\
1.3.2 **No PII by default** in ontology objects; sensitive attributes must be minimized, redacted, or handled under restricted classes where lawful and necessary.\
1.3.3 **No implied certification**: ontology alignment does not constitute compliance or conformance.\
1.3.4 **Non-equivalence warnings** are required unless strict equivalence is proven and recorded.\
1.3.5 **Backwards-compatibility bias**: breaking changes are exceptional and must carry migration guidance and long-run support windows.

***

#### 2. Scope and Interoperability Commitments

2.1 **Scope.** NXS-GRX-Web covers the end-to-end web stack as a coupled system-of-systems, including: infrastructure dependencies, application security posture, supply chain integrity, PKI and trust stores, privacy and consent signals, identity systems, AI-on-web surfaces, content authenticity, web3 interfaces, accessibility, performance, and governance/standards mapping.

2.2 **Primary interoperability targets.** NXS-GRX-Web maintains stable mapping interfaces to:\
2.2.1 **W3C** (e.g., Web platform primitives; security/privacy/a11y relevant specifications);\
2.2.2 **IETF** (protocol RFC families relevant to web transport, DNS, PKI, security);\
2.2.3 **ICANN ecosystem** (registries/registrars policy and DNS governance artifacts where informationally relevant);\
2.2.4 **Schema.org / JSON-LD** for structured data representation;\
2.2.5 **OpenAPI** for API surface description;\
2.2.6 enterprise security taxonomies where used as mapping hooks (e.g., OWASP, CVE identifiers, CT log structures), without claiming authority over them.

2.3 **Non-equivalence doctrine.** Any “mapping” is an interoperability convenience—not a legal or technical equivalence claim—unless:\
2.3.1 the equivalence criteria are explicitly defined;\
2.3.2 supporting evidence is recorded;\
2.3.3 drift risks are documented;\
2.3.4 the equivalence claim is version-pinned and time-bounded.

***

#### 3. Canonical Object Model (Minimum Required Objects)

3.1 **Object families.** NXS-GRX-Web defines canonical object families that every artifact must reference where applicable:\
3.1.1 **Asset** (a web-relevant entity of interest: domain, site, service, application, org endpoint set);\
3.1.2 **Identity/Ownership Claim** (bounded, evidence-linked claims about control/operation, never assumed);\
3.1.3 **Endpoint** (network addressable interface: hostname, URL, IP tuple, API route);\
3.1.4 **Dependency** (CDN, hosting provider, registrar, nameserver set, third-party scripts, external APIs);\
3.1.5 **Certificate / Trust Artifact** (TLS cert, CT log entries, chain, issuer metadata, revocation signals);\
3.1.6 **Control / Configuration** (security headers, CSP/SRI usage, auth patterns, rate limits, consent mechanism markers);\
3.1.7 **Observable** (raw measured facts: header values, DNS records, performance metrics, page signals);\
3.1.8 **Event** (time-bounded occurrence: configuration change, issuance, exposure observation);\
3.1.9 **Incident** (structured incident object where evidence supports classification; includes confidence);\
3.1.10 **Vulnerability / Weakness Reference** (identifier links: CVE, CWE, OWASP categories as references);\
3.1.11 **Indicator** (IoC-style patterns where permitted and safe to publish; always confidence-labeled);\
3.1.12 **Risk Finding** (bounded statement derived from observables + tests + uncertainty);\
3.1.13 **Evidence** (inputs and test artifacts supporting findings);\
3.1.14 **Determination** (governance-grade conclusion with authority and reliance bounds—only where permitted);\
3.1.15 **Benchmark Result** (method-pinned comparative outcome with anti-gaming metadata).

3.2 **Identifiers and stability.** Every canonical object must include:\
3.2.1 a stable **object identifier** (OID) and version;\
3.2.2 **time validity** (“as-of” and measurement window);\
3.2.3 **source lineage pointer(s)** (what inputs created it);\
3.2.4 **handling class** and redaction notes if applicable.

3.3 **No identity-by-default rule.**\
3.3.1 The ontology does not presume operator identity.\
3.3.2 Ownership/attribution is represented only as **claims** supported by evidence, with confidence and contestability.\
3.3.3 Where identity is relevant, it must be minimized, legally bounded, and never used for targeting individuals.

***

#### 4. Canonical Relationships (Graph Semantics)

4.1 **Core relations.** NXS-GRX-Web provides canonical relationships enabling dependency and cascade modeling:\
4.1.1 Asset **hasEndpoint** Endpoint\
4.1.2 Endpoint **dependsOn** Dependency\
4.1.3 Dependency **providedBy** Provider (non-endorsement, informational)\
4.1.4 Endpoint **securedBy** Certificate/Trust Artifact\
4.1.5 Endpoint **exhibits** Observable\
4.1.6 Observable **supports** Evidence\
4.1.7 Evidence **supports** Risk Finding / Determination\
4.1.8 Event/Incident **affects** Asset/Endpoint/Dependency\
4.1.9 Benchmark Result **computedFrom** Method + Sample Frame + Observables\
4.1.10 Risk Finding **boundedBy** Reliance + Handling + Uncertainty + Validity Window

4.2 **Cascade modeling posture.** Relationship graphs may be used to model systemic coupling (e.g., CDN concentration, registrar consolidation, trust-store drift), but must:\
4.2.1 disclose limitations;\
4.2.2 avoid false precision;\
4.2.3 publish sensitivity and drift assumptions.

***

#### 5. Representation Formats and Packaging

5.1 **Primary serialization.** NXS-GRX-Web supports:\
5.1.1 JSON and JSON-LD for interchange and structured evidence packs;\
5.1.2 schema-bound exports for datasets and benchmarks;\
5.1.3 OpenAPI-described interfaces for platform endpoints;\
5.1.4 content-addressed bundles for reproducibility.

5.2 **Artifact packaging rule.** Every publishable artifact referencing NXS-GRX-Web must include:\
5.2.1 the ontology version used;\
5.2.2 mapping notes for external standards referenced;\
5.2.3 lineage references and transformation steps;\
5.2.4 correction path and supersession pointers.

5.3 **No hidden transformations.** Any significant transformation (filtering, enrichment, deduplication, inference layer) must be logged and, where safe, reproducibly spec’d.

***

#### 6. Lineage, Provenance, and Content-Addressing

6.1 **Lineage model.** NXS-GRX-Web requires a minimum lineage record for any derived object:\
6.1.1 input identifiers and collection windows;\
6.1.2 processing steps and parameters;\
6.1.3 test harness versions;\
6.1.4 environment fingerprints (where needed for replayability);\
6.1.5 output identifiers and hashes.

6.2 **Content-addressed artifacts.** Wherever feasible, evidence artifacts should be:\
6.2.1 hashed (content-addressed);\
6.2.2 signed when released as “Release-Ready” or higher;\
6.2.3 stored with immutable pointers and explicit deprecation metadata.

6.3 **Replayability tiers.** Lineage metadata must be sufficient to support the reproducibility ladder (RS0–RS4) as declared by the artifact.

***

#### 7. Standards Mapping Register (W3C/IETF/ICANN and Beyond)

7.1 **Mapping register.** The Guild maintains a mapping register that links NXS-GRX-Web objects and fields to:\
7.1.1 relevant W3C specs (informational mapping);\
7.1.2 relevant IETF RFCs (protocol and security mapping);\
7.1.3 ICANN governance artifacts where needed to interpret DNS ecosystem contexts;\
7.1.4 other reference standards (e.g., OWASP categories, WCAG criteria, CT log formats) as non-authoritative hooks.

7.2 **Mapping constraints.**\
7.2.1 mappings must be version-pinned;\
7.2.2 drift risk must be stated;\
7.2.3 non-equivalence warnings are mandatory unless equivalence is proven and recorded.

7.3 **Regulatory mapping posture.** Regulatory frameworks may be mapped only as:\
7.3.1 informational “hook” notes to support interoperability;\
7.3.2 never as compliance determinations;\
7.3.3 always with jurisdictional variability warnings.

***

#### 8. Ontology Governance: Change Control, Compatibility, and Deprecation

8.1 **Change classes.** Ontology changes are classified as:\
8.1.1 **Patch** (clarifications, non-breaking metadata additions);\
8.1.2 **Minor** (additive changes with backwards compatibility);\
8.1.3 **Major** (breaking changes; exceptional; requires migration plan).

8.2 **Release discipline.**\
8.2.1 every release is versioned and published with a change log;\
8.2.2 every breaking change includes migration guidance and transition period;\
8.2.3 deprecated fields remain readable for a defined window unless safety requires emergency removal.

8.3 **Appeals and disputes.** Significant ontology changes must be contestable:\
8.3.1 published rationale and evidence;\
8.3.2 dissent register entries permitted;\
8.3.3 correction and supersession discipline applies.

8.4 **Emergency safety posture.** If an ontology element enables misuse (dual-use), the Guild may:\
8.4.1 restrict detail level;\
8.4.2 redact examples;\
8.4.3 accelerate deprecation under emergency correction rules;\
8.4.4 publish a safety notice with supersession pointers.

***

#### 9. Minimum Requirements for Platform Alignment (v1.0)

9.1 **Module interoperability rule.** All v1.0 platform modules must emit and consume:\
9.1.1 canonical objects and relations;\
9.1.2 version identifiers and lineage pointers;\
9.1.3 handling class and reliance bounds on exported artifacts.

9.2 **Evidence pack compatibility.** All AEPs must:\
9.2.1 reference NXS-GRX-Web canonical objects;\
9.2.2 embed or link lineage metadata;\
9.2.3 include mapping register references where external standards are invoked.

9.3 **Benchmark comparability rule.** Benchmarks must:\
9.3.1 declare sampling frames and drift posture;\
9.3.2 publish methodology and anti-gaming measures;\
9.3.3 bind outputs to ontology and method versions.

## Sources

1. UN General Assembly (2015). Sendai Framework for Disaster Risk Reduction 2015–2030. A/RES/69/283, 3 June 2015. <https://www.undrr.org/publication/sendai-framework-disaster-risk-reduction-2015-2030>
2. FAO (2014). The Water-Energy-Food Nexus: A new approach in support of food security and sustainable agriculture. Rome: Food and Agriculture Organization of the United Nations. <https://www.fao.org/4/bl496e/bl496e.pdf>
3. One Health High-Level Expert Panel (OHHLEP), Adisasmito, W. B. et al. (2022). One Health: A new definition for a sustainable and healthy future. PLoS Pathogens 18(6): e1010537. doi:10.1371/journal.ppat.1010537. <https://doi.org/10.1371/journal.ppat.1010537>
4. Nexus Standards. NS-0: Constitution and principles. Status: PROPOSED; UNI `NXS-STD-ST-000004`. <https://nexustandards.com/standards/ns-0/>
5. Nexus Standards. NS-13: Open standards development process. Status: PROPOSED; UNI `NXS-STD-ST-000008`. <https://nexustandards.com/standards/ns-13/>
6. GCRI. The Labs pillar home. <https://therisk.global/nexus-labs/>
7. GCRI. Working groups (NWG). <https://therisk.global/consortium/national/nwg/>
8. This documentation: [Governance in operation](/organization/governance-in-operation.md); [The Model](/organization/model.md); [historical labels](/organization/reference.md).


---

# 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/cooperation/nexus-guilds/future-of-web/viii.-grix-ontology.md?ask=<question>&goal=<user_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.