# VIII. GRIx Ontology

### Part 8 — GRIx Web Ontology and Interoperability Spine

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

1.1 **Status.** The GRIx Web Ontology (“GRIx-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.** GRIx-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.** GRIx-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.** GRIx-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.** GRIx-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.** GRIx-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.** GRIx-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 GRIx-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.** GRIx-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 GRIx-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 GRIx-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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.therisk.global/organization/cooperation/nexus-guilds/future-of-web/viii.-grix-ontology.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.