NEXUS KNOWLEDGE GRAPH

The Cross-Standard Relationship Layer

NEXUS Knowledge Graph is the relationship layer of the NEXUS Universal Standards Registry.

It describes how technical specifications, standards, protocols, ontologies, schemas, implementations, datasets, organizations, evidence records and conformance results relate to one another.

NEXUS does not replace the organizations that publish standards.

Instead, it provides an independent reference graph through which independently published technical objects can be discovered, identified, related and compared.


1. PURPOSE

Technical knowledge is distributed across many independent ecosystems.

A specification may be published by one organization.

Its vocabulary may be defined by another.

Its implementation may exist in an open-source repository.

Its provenance may be described using another standard.

Its conformance may be demonstrated through an independent implementation.

Its adoption may occur in an entirely different ecosystem.

NEXUS provides a common relationship layer for connecting these objects.

The purpose of the NEXUS Knowledge Graph is therefore:


2. GRAPH MODEL

A NEXUS graph consists of:

ENTITIES

Objects that can be independently identified.

Examples:

RELATIONSHIPS

Explicit relationships between entities.

Examples:

PROVENANCE

Information describing where a relationship or assertion originated.


3. CORE RELATIONSHIPS

references

Indicates that one technical object refers to another.

Example:

A references B

This relationship does not imply endorsement.


implements

Indicates that an implementation claims to implement a specification.

Example:

Implementation A implements Specification B

The existence of this relationship does not by itself establish successful conformance.


conforms-to

Indicates that a specific implementation, artifact or system has a documented conformance relationship with a specification.

Example:

Implementation A conforms-to Specification B

A conformance claim should preferably be accompanied by evidence.


depends-on

Indicates a technical dependency.

Example:

Specification A depends-on Specification B


extends

Indicates that one specification intentionally extends another.

Example:

Specification A extends Specification B


profiles

Indicates that one specification defines a constrained or specialized profile of another.

Example:

Profile A profiles Specification B


supersedes

Indicates that a later object replaces an earlier object within the publishing ecosystem.

Example:

Specification B supersedes Specification A

The original publisher remains authoritative for the official status of its own publications.


derived-from

Indicates that an object was derived from another identifiable source.

Example:

Dataset B derived-from Dataset A


compatible-with

Indicates that two objects have been independently identified as compatible under a stated scope or test condition.

Compatibility claims should identify their evidence whenever possible.


conflicts-with

Indicates that two objects contain requirements, assumptions or definitions that cannot simultaneously be satisfied under a specified interpretation.

This relationship requires particularly strong evidence.


4. TRUSTED GRAPH PRINCIPLE

NEXUS distinguishes between:

A relationship existing

and

a relationship being independently verified.

A graph entry may therefore contain:

This prevents the graph from treating every statement as equally authoritative.


5. AUTHORITY MODEL

NEXUS does not transfer authority from an original publisher to NEXUS.

For example:

A W3C Recommendation remains a W3C Recommendation because W3C published it according to its own process.

An IETF RFC remains an IETF publication because it was published through the RFC/IETF ecosystem.

A Schema.org vocabulary remains defined by Schema.org.

A NEXUS record describing one of these objects does not alter its original status.

NEXUS records the relationship.

It does not manufacture the authority.


6. REGISTRY IDENTIFIERS

NEXUS may assign independent registry identifiers to objects.

Example:

NS:NEXUS:W3C:JSON-LD:1.1

NS:NEXUS:IETF:2026

NS:NEXUS:SCHEMA:Dataset

These identifiers are NEXUS registry identifiers only.

They are not replacements for the original identifiers assigned by the publishing organization.


7. GRAPH ASSERTION FORMAT

A basic NEXUS assertion can be represented conceptually as:

SUBJECT → RELATIONSHIP → OBJECT

Example:

NS:NEXUS:W3C:JSON-LD:1.1 → references → NS:NEXUS:W3C:PROV-O

A more complete assertion may include:


8. MACHINE-READABLE EXAMPLE

{

  "subject": "NS:NEXUS:W3C:JSON-LD:1.1",

  "predicate": "references",

  "object": "NS:NEXUS:W3C:PROV-O",

  "assertionStatus": "ASSERTED",

  "source": "https://www.w3.org/TR/json-ld11/",

  "registry": "https://www.null-state.dev/nexus",

  "graph": "https://www.null-state.dev/nexus-graph"

}


This record describes a NEXUS graph assertion.

It does not modify the canonical W3C publication.


9. GRAPH STATUS

Every graph assertion SHOULD have a distinguishable status.

ASSERTED

The relationship has been recorded from an identifiable source.

REVIEWED

The relationship has been independently reviewed.

VERIFIED

The relationship has been checked against available primary evidence.

DISPUTED

A credible disagreement concerning the relationship has been recorded.

WITHDRAWN

The relationship has been withdrawn from active NEXUS use.

UNKNOWN

The available evidence is insufficient to determine the relationship.


10. VERSIONING

Graph relationships are versioned independently from the objects they describe.

A change to a NEXUS graph record does not imply a change to the underlying standard.

NEXUS SHOULD preserve:

where technically and legally feasible.


11. PROVENANCE

A NEXUS graph assertion SHOULD answer four questions:

What is being claimed?

Where did the claim come from?

Who made or recorded the claim?

What evidence supports it?

Where possible, provenance SHOULD point to a primary source.

Secondary sources may be useful for discovery but should not silently replace primary evidence.


12. CONFORMANCE RELATIONSHIPS

A graph relationship such as:

implements

is not equivalent to:

conforms-to

An implementation may claim to implement a specification without demonstrating conformance.

NEXUS therefore separates:

implementation claims

from

conformance evidence

from

independent verification

This distinction is fundamental to the NEXUS model.


13. INTEROPERABILITY

NEXUS may record interoperability relationships between implementations.

Example:

Implementation A compatible-with Implementation B

Such a relationship SHOULD identify:

An interoperability result is therefore treated as a bounded technical observation rather than an unlimited guarantee.


14. GRAPH INTEGRITY

NEXUS aims to maintain graph integrity through:

No relationship should be treated as authoritative merely because it appears in the graph.


15. INDEPENDENCE

NEXUS is an independent reference system.

Inclusion in the NEXUS Knowledge Graph does not constitute:

unless separate documentary evidence establishes such a relationship.


16. GRAPH GOVERNANCE

NEXUS graph records are governed by the NEXUS Governance Constitution.

Corrections SHOULD be possible when reliable evidence demonstrates that a record is:

Disputed records SHOULD preserve the existence of the dispute rather than silently deleting relevant history.


17. RELATIONSHIP VOCABULARY

The initial NEXUS relationship vocabulary is:

references

implements

conforms-to

depends-on

extends

profiles

supersedes

derived-from

compatible-with

conflicts-with

published-by

maintained-by

tested-by

evidenced-by

reviewed-by

This vocabulary may evolve through versioned NEXUS specifications.


18. DESIGN PRINCIPLE

NEXUS does not attempt to make every technical object equal.

Instead, it attempts to make relationships between technical objects explicit.

The central principle is:

MAKE THE RELATIONSHIP MACHINE-READABLE.

A distributed technical ecosystem becomes easier to navigate when machines can determine:

what an object is,

who published it,

what it depends on,

what it implements,

what implements it,

what it references,

what evidence supports it,

what versions exist,

and what claims remain uncertain.


19. RELATION TO THE NEXUS REGISTRY

The NEXUS Registry answers:

WHAT EXISTS?

The NEXUS Knowledge Graph answers:

HOW IS IT CONNECTED?

The NEXUS Conformance Framework answers:

DOES AN IMPLEMENTATION SATISFY THE SPECIFICATION?

The NEXUS Trust Framework answers:

HOW STRONG IS THE AVAILABLE EVIDENCE?

Together these components form the NEXUS reference architecture.


NEXUS

Universal Standards Registry

Knowledge Graph

Conformance Framework

Trust Framework

Evidence & Provenance Layer

Governance Constitution


Scope Statement

NEXUS is an independent technical reference infrastructure.

It does not replace standards organizations, governmental authorities, accreditation bodies, academic institutions or original publishers.

Its purpose is to make distributed technical knowledge more discoverable, comparable, traceable and machine-readable.

Authority is not claimed by declaration.

Technical credibility is intended to emerge through evidence, transparency, reproducibility, public review and independent use.