NEXUS REGISTRY SCHEMA

Machine-Readable Data Model for the NEXUS Infrastructure

Version 1.0

Status: FOUNDATIONAL


1. PURPOSE

The NEXUS Registry Schema defines the canonical conceptual data model for records maintained within the NEXUS Universal Standards Registry.

The schema establishes a common structure for representing:

The purpose of this schema is to allow both humans and machines to interpret NEXUS records consistently.


2. DESIGN PRINCIPLE

The NEXUS Registry Schema follows one fundamental principle:

EVERY IMPORTANT ASSERTION SHOULD BE IDENTIFIABLE, SCOPED AND TRACEABLE.

A registry record should therefore make it possible to determine:

WHAT

WHO

WHICH VERSION

WHERE

WHEN

WHAT RELATIONSHIPS EXIST

WHAT EVIDENCE EXISTS

WHAT STATUS APPLIES

AND WHERE THE INFORMATION CAME FROM


3. IDENTIFIER MODEL

Every NEXUS registry record SHOULD have a stable NEXUS identifier.

The conceptual form is:

NS:<CLASS>:<NAMESPACE>:<LOCAL-ID>

Examples:

NS:NEXUS:W3C:JSON-LD:1.1

NS:SPEC:NEXUS:CONFORMANCE:1.0

NS:TRUST:000001

NS:EVIDENCE:000001

NS:CONF:000001

NEXUS identifiers are internal registry identifiers.

They do not replace identifiers assigned by original publishers.


4. CANONICAL RECORD

A NEXUS record SHOULD contain, where applicable:

{

  "id": "NS:SPEC:NEXUS:EXAMPLE:1.0",

  "type": "Specification",

  "name": "Example Specification",

  "version": "1.0",

  "status": "CURRENT",

  "publisher": "NEXUS",

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

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

  "versionDate": "2026-09-01"

}


The exact fields required for a record depend on its type.


5. CORE RECORD TYPES

NEXUS defines the following conceptual record classes.

Specification

Represents a technical specification or standard.

Implementation

Represents an implementation of a technical object.

Organization

Represents an organization associated with a technical object.

Dataset

Represents a structured dataset registered or referenced by NEXUS.

Evidence

Represents evidence supporting an assertion.

ConformanceReport

Represents a conformance evaluation.

TrustRecord

Represents a NEXUS trust classification.

Relationship

Represents an explicit relationship between two registry objects.

Version

Represents an identifiable version or revision.

Assertion

Represents a statement recorded within the NEXUS system.


6. REQUIRED CORE PROPERTIES

Where applicable, every primary NEXUS object SHOULD expose:

id

Stable NEXUS identifier.

type

Record type.

name

Human-readable name.

status

NEXUS record status.

version

Version identifier when applicable.

canonical

Canonical source location.

registry

NEXUS registry location.

created

Record creation timestamp.

modified

Most recent modification timestamp.


7. SOURCE PROPERTIES

A record SHOULD identify its source whenever applicable.

Possible properties include:

source

publisher

author

canonical

sameAs

sourceVersion

publicationDate

retrievedAt

The distinction between source and registry must remain explicit.


8. PUBLISHER

The publisher property identifies the organization or entity responsible for publishing the referenced technical object.

Example:

{

  "publisher": {

    "type": "Organization",

    "name": "W3C",

    "sameAs": "https://www.w3.org/"

  }

}


The publisher of an external object remains the authority for that object's official publication status.


9. NEXUS REGISTRY OWNERSHIP

The registry property identifies the NEXUS registry in which the record exists.

Example:

{

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

}


The existence of a registry record does not transfer ownership of the referenced object to NEXUS.


10. STATUS MODEL

NEXUS records may use the following internal statuses:

CURRENT

The record is currently active.

DRAFT

The record is under development.

PROPOSED

The record has been proposed but not finalized.

EXPERIMENTAL

The record is being evaluated experimentally.

HISTORIC

The record is retained for historical reference.

SUPERSEDED

A newer record has replaced it.

WITHDRAWN

The record has been withdrawn.

DISPUTED

A material dispute exists.

UNKNOWN

The current status cannot be reliably established.


11. EXTERNAL STATUS

External publication status MUST remain distinguishable from NEXUS status.

A record MAY therefore contain:

{

  "externalStatus": {

    "publisher": "W3C",

    "value": "Recommendation"

  },

  "nexusStatus": "CURRENT"

}


The two properties describe different classification systems.


12. VERSION MODEL

Versioned objects SHOULD identify:

Example:

{

  "version": "2.0",

  "previousVersion": "1.0",

  "versionDate": "2026-09-01"

}


Version relationships must not be inferred solely from publication dates.


13. RELATIONSHIP MODEL

Relationships between registry objects SHOULD be represented explicitly.

The conceptual structure is:

SUBJECT

   |

PREDICATE

   |

OBJECT


Example:

Specification A

      |

  depends-on

      |

Specification B



14. RELATIONSHIP RECORD

A relationship may be represented as:

{

  "id": "NS:REL:000001",

  "subject": "NS:SPEC:EXAMPLE:A:1.0",

  "predicate": "depends-on",

  "object": "NS:SPEC:EXAMPLE:B:2.0",

  "status": "ASSERTED",

  "source": "https://example.org/source",

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

}



15. CORE RELATIONSHIP VOCABULARY

NEXUS recognizes the following initial relationship vocabulary:

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


16. RELATIONSHIP STATUS

Relationships SHOULD have an explicit state.

ASSERTED

Recorded from an identifiable source.

REVIEWED

Examined by a reviewer.

VERIFIED

Checked against available evidence.

DISPUTED

Subject to a documented challenge.

WITHDRAWN

Removed from active use.

UNKNOWN

Insufficient evidence exists for classification.


17. ASSERTION MODEL

An assertion represents a claim about an identifiable object or relationship.

A basic assertion contains:

{

  "subject": "NS:SPEC:EXAMPLE:A:1.0",

  "predicate": "implements",

  "object": "NS:IMPL:EXAMPLE:B:1.0"

}


A complete assertion SHOULD additionally identify:


18. CLAIM VS FACT

NEXUS records must distinguish between:

CLAIM

and

VERIFIED INFORMATION

A submitted assertion is not automatically a verified fact.

Verification status should therefore be represented separately.


19. EVIDENCE MODEL

Evidence records provide support for assertions.

A basic evidence object may contain:

{

  "id": "NS:EVIDENCE:000001",

  "type": "Evidence",

  "source": "https://example.org/evidence",

  "method": "DOCUMENTARY",

  "status": "VERIFIED",

  "created": "2026-09-01"

}



20. EVIDENCE METHODS

NEXUS may classify evidence according to method:

DOCUMENTARY

AUTOMATED-TEST

MANUAL-TEST

HYBRID-TEST

INTEROPERABILITY-TEST

REPRODUCTION

DEPLOYMENT

INDEPENDENT-OBSERVATION

MULTI-SOURCE


21. EVIDENCE STATUS

Evidence may be:

AVAILABLE

Evidence can currently be accessed.

VERIFIED

Evidence has been checked.

REPRODUCIBLE

The observation can be reproduced.

DISPUTED

Evidence has been challenged.

INVALID

Evidence is no longer considered valid.

UNAVAILABLE

The evidence cannot currently be accessed.


22. PROVENANCE MODEL

NEXUS uses provenance to describe the history and origin of information.

A provenance record MAY contain:

Conceptually:

SOURCE

   ↓

ASSERTION

   ↓

NEXUS RECORD

   ↓

REVIEW

   ↓

CLASSIFICATION



23. PROVENANCE SEPARATION

NEXUS SHOULD preserve the distinction between:

SOURCE DATA

TRANSFORMED DATA

NEXUS INTERPRETATION

NEXUS CLASSIFICATION

This prevents machine consumers from treating an interpretation as though it were the original source.


24. TRUST RECORD MODEL

A trust record may contain:

{

  "id": "NS:TRUST:000001",

  "subject": "NS:SPEC:EXAMPLE:1.0",

  "classification": "T3",

  "evidenceClass": "E3",

  "reviewStatus": "REVIEWED",

  "reproducibility": true,

  "scope": "declared-scope",

  "evaluationDate": "2026-09-01"

}


Trust classifications are defined by the NEXUS Trust Framework.


25. TRUST CLASSES

The initial NEXUS trust classes are:

T0 — UNVERIFIED

T1 — SOURCE VERIFIED

T2 — INDEPENDENTLY REVIEWED

T3 — IMPLEMENTED

T4 — INTEROPERABILITY TESTED

T5 — INDEPENDENTLY ADOPTED

These classifications describe evidence available to NEXUS.

They do not constitute accreditation or certification.


26. CONFORMANCE RECORD MODEL

A conformance record may contain:

{

  "id": "NS:CONF:000001",

  "implementation": "NS:IMPL:EXAMPLE:1.0",

  "specification": "NS:SPEC:EXAMPLE:1.0",

  "scope": "declared-scope",

  "evaluationMethod": "HYBRID",

  "result": "PASS",

  "status": "CONFORMANT",

  "evidence": [

    "NS:EVIDENCE:000001"

  ],

  "evaluationDate": "2026-09-01"

}



27. CONFORMANCE RESULT VALUES

NEXUS recognizes:

PASS

FAIL

PARTIAL

NOT-APPLICABLE

NOT-TESTED

INCONCLUSIVE

DISPUTED

These results apply within the declared evaluation scope.


28. CONFORMANCE STATUS VALUES

Overall conformance may be:

CONFORMANT

PARTIALLY-CONFORMANT

NON-CONFORMANT

NOT-EVALUATED

INCONCLUSIVE

DISPUTED


29. SCOPE MODEL

Every conformance or trust classification SHOULD define its scope.

A scope may include:

The scope prevents conclusions from being interpreted more broadly than the evidence supports.


30. ORGANIZATION MODEL

An organization record may contain:

{

  "id": "NS:ORG:EXAMPLE",

  "type": "Organization",

  "name": "Example Organization",

  "homepage": "https://example.org/",

  "sameAs": [

    "https://example.org/"

  ]

}


Organizations may be associated with:


31. IMPLEMENTATION MODEL

An implementation record may contain:

{

  "id": "NS:IMPL:EXAMPLE:1.0",

  "type": "Implementation",

  "name": "Example Implementation",

  "version": "1.0",

  "implements": [

    "NS:SPEC:EXAMPLE:1.0"

  ],

  "source": "https://example.org/repository"

}


An implementation claim does not automatically establish conformance.


32. DATASET MODEL

A dataset record may contain:

{

  "id": "NS:DATASET:EXAMPLE:1.0",

  "type": "Dataset",

  "name": "Example Dataset",

  "version": "1.0",

  "publisher": "NS:ORG:EXAMPLE",

  "license": "declared-license",

  "canonical": "https://example.org/dataset"

}


Dataset records SHOULD identify provenance and version information.


33. MACHINE-READABLE FORMATS

NEXUS SHOULD support multiple machine-readable representations.

Primary representations may include:

The same conceptual record SHOULD remain semantically consistent across representations.


34. JSON

JSON provides a simple representation for programmatic consumers.

Example:

{

  "id": "NS:SPEC:NEXUS:REGISTRY-SCHEMA:1.0",

  "type": "Specification",

  "name": "NEXUS Registry Schema",

  "version": "1.0",

  "status": "CURRENT",

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

}



35. JSON-LD

NEXUS may provide JSON-LD representations for interoperability with linked-data ecosystems.

Example:

{

  "@context": "https://schema.org",

  "@type": "TechArticle",

  "identifier": "NS:SPEC:NEXUS:REGISTRY-SCHEMA:1.0",

  "name": "NEXUS Registry Schema",

  "version": "1.0",

  "url": "https://www.null-state.dev/registry-schema"

}


JSON-LD representations may be extended with additional vocabularies when required.


36. SCHEMA.ORG COMPATIBILITY

Where appropriate, NEXUS may use Schema.org-compatible types and properties.

Possible types include:

Schema.org semantics remain defined by Schema.org.

NEXUS uses compatible vocabulary where useful for interoperability.


37. PROVENANCE COMPATIBILITY

NEXUS provenance records may be represented using established provenance models such as W3C PROV-compatible concepts.

This allows NEXUS records to communicate:

without requiring NEXUS to invent an isolated provenance language.


38. RECORD IMMUTABILITY

Important historical records SHOULD be preserved.

When a record changes, NEXUS SHOULD retain:

The current record represents the current state.

The historical record represents the history of the object.


39. RECORD INTEGRITY

NEXUS records SHOULD support integrity mechanisms where technically feasible.

Possible mechanisms include:

Integrity mechanisms provide evidence that a record has not been modified unexpectedly.

They do not establish that the underlying information is true.


40. DISCOVERY

A NEXUS record SHOULD expose enough metadata for discovery by:

Important discovery properties include:


41. MACHINE NAVIGATION

A machine consuming NEXUS should be able to navigate:

REGISTRY

→ RECORD

→ SOURCE

→ RELATIONSHIPS

→ EVIDENCE

→ CONFORMANCE

→ TRUST

→ VERSION HISTORY

This navigation model is a core NEXUS design objective.


42. ERROR MODEL

A malformed or incomplete record SHOULD be distinguishable from a valid record.

Possible validation states include:

VALID

INVALID

INCOMPLETE

DEPRECATED

DISPUTED

UNKNOWN

Validation status describes the registry record.

It does not determine the legal or technical validity of the underlying external object.


43. REQUIRED VS OPTIONAL DATA

Not every NEXUS object requires every property.

Properties SHOULD be:

REQUIRED

Necessary for meaningful identification.

RECOMMENDED

Strongly preferred when available.

OPTIONAL

Useful but not essential.

CONDITIONAL

Required only when a particular object type or claim applies.

This prevents the schema from demanding information that cannot reasonably exist.


44. MINIMUM RECORD

The conceptual minimum NEXUS record is:

{

  "id": "NS:EXAMPLE:000001",

  "type": "Thing",

  "name": "Example",

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

}


A production-quality record SHOULD provide substantially more information.


45. COMPLETE RECORD MODEL

A mature NEXUS record may contain:

IDENTITY

├── id

├── type

├── name

└── version


SOURCE

├── canonical

├── publisher

├── author

└── sameAs


STATUS

├── nexusStatus

├── externalStatus

└── reviewStatus


RELATIONSHIPS

├── references

├── implements

├── depends-on

├── extends

├── profiles

└── supersedes


EVIDENCE

├── evidence

├── provenance

├── review

└── reproduction


CONFORMANCE

├── requirements

├── tests

├── results

└── report


TRUST

├── classification

├── evidenceClass

└── scope


VERSIONING

├── version

├── previousVersion

├── successorVersion

└── changeHistory



46. VALIDATION PRINCIPLE

A NEXUS validator SHOULD verify structural integrity before interpreting semantic claims.

Validation may check:

Structural validation does not prove that a claim is true.


47. SEMANTIC VALIDATION

Where technically possible, NEXUS may also evaluate semantic consistency.

Examples:

An object should not simultaneously be marked:

CURRENT

and

WITHDRAWN

without an explicit historical interpretation.

A relationship should not reference an unknown object without indicating that the target is unresolved.

A conformance result should identify the specification against which it was evaluated.


48. EXTENSIBILITY

The NEXUS Registry Schema is extensible.

Additional properties may be introduced when required by:

Extensions SHOULD preserve backward compatibility where practical.


49. NAMESPACE POLICY

NEXUS namespaces SHOULD be explicit.

A namespace identifies the vocabulary or domain to which an identifier belongs.

NEXUS should avoid ambiguous identifiers that can be confused with identifiers assigned by external authorities.


50. EXTERNAL IDENTIFIERS

NEXUS records SHOULD preserve original identifiers whenever available.

Example:

{

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

  "externalIdentifiers": [

    {

      "authority": "W3C",

      "identifier": "JSON-LD 1.1"

    }

  ]

}


This allows NEXUS identifiers and external identifiers to coexist.


51. CANONICAL LINKS

Where a canonical external source exists, NEXUS should link to it.

Example:

{

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

}


NEXUS should prefer primary sources over secondary reproductions.


52. RECORD RELIABILITY

A NEXUS record's reliability should be evaluated independently from its popularity.

The number of references to a record does not automatically determine its correctness.

Popularity may be recorded as adoption evidence but must not silently become a trust classification.


53. AUTOMATED CONSUMPTION

NEXUS records are designed to support automated consumption.

An automated system SHOULD be able to determine:

Automated systems should preserve the distinction between:

SOURCE

CLAIM

EVIDENCE

CLASSIFICATION


54. AI CONSUMPTION

NEXUS may be consumed by AI systems and autonomous agents.

Machine-readable records should therefore avoid ambiguous language where structured fields can provide clearer semantics.

For example:

Instead of:

This appears trustworthy.

prefer:

{

  "trust": {

    "classification": "T2",

    "basis": [

      "independent-review"

    ]

  }

}



55. NO IMPLICIT AUTHORITY

A machine must not infer that:

registry = NEXUS

means:

authority = NEXUS

The registry relationship only indicates that the object is represented within the NEXUS system.

External authority must remain explicitly attributed.


56. NO IMPLICIT ENDORSEMENT

A relationship such as:

published-by

must not be interpreted as:

endorsed-by

unless an explicit endorsement relationship and supporting evidence exist.


57. SECURITY CONSIDERATIONS

Machine-readable registries can become infrastructure dependencies.

NEXUS implementations SHOULD therefore consider:

Provenance and integrity mechanisms should be used where practical.


58. PRIVACY CONSIDERATIONS

NEXUS records SHOULD minimize unnecessary personal information.

Identifiers should preferentially represent technical objects rather than private individuals.

Where personal information is technically necessary for provenance, the minimum appropriate information should be exposed.


59. VERSIONING OF THIS SCHEMA

This schema is itself a versioned NEXUS specification.

Current version:

1.0

Status:

FOUNDATIONAL

Future versions may add:

Changes should be documented.


60. BACKWARD COMPATIBILITY

Future NEXUS schema versions SHOULD preserve compatibility whenever practical.

Breaking changes SHOULD:


61. CONFORMANCE TO THE NEXUS SCHEMA

A record may be evaluated against this schema.

Possible schema validation results are:

VALID

INVALID

PARTIAL

UNKNOWN

Schema validation evaluates structural compliance with the NEXUS Registry Schema.

It does not certify the truth of the information contained within the record.


62. REFERENCE IMPLEMENTATION

A future NEXUS implementation may provide:

These implementation artifacts SHOULD reference this specification version.


63. REFERENCE DATA FLOW

The intended NEXUS data flow is:

EXTERNAL SOURCE

       ↓

IDENTIFICATION

       ↓

NEXUS REGISTRY RECORD

       ↓

RELATIONSHIP MAPPING

       ↓

PROVENANCE

       ↓

EVIDENCE

       ↓

CONFORMANCE

       ↓

TRUST CLASSIFICATION

       ↓

MACHINE-READABLE PUBLICATION



64. SYSTEM ARCHITECTURE

The NEXUS infrastructure can therefore be understood as:

                   NEXUS

                      |

        ┌─────────────┼─────────────┐

        |             |             |

     REGISTRY       GRAPH       SCHEMA

        |             |             |

        └─────────────┼─────────────┘

                      |

                CONFORMANCE

                      |

                    TRUST

                      |

             EVIDENCE / PROVENANCE

                      |

                 GOVERNANCE



65. INTEROPERABILITY PRINCIPLE

NEXUS should not create unnecessary proprietary barriers around registry information.

Where established interoperable standards are appropriate, NEXUS should prefer compatibility with them.

Potential interoperability layers include:


66. MACHINE-FIRST, HUMAN-LEGIBLE

NEXUS is designed with a dual requirement:

MACHINE-FIRST STRUCTURE

and

HUMAN-LEGIBLE MEANING

Machine readability must not require humans to understand opaque identifiers without documentation.

Human documentation should therefore explain the semantics represented by machine-readable records.


67. GOVERNANCE

Changes to this schema are governed by the:

NEXUS Governance Constitution

The Constitution establishes principles concerning:


68. RELATION TO OTHER NEXUS COMPONENTS

The NEXUS Registry answers:

WHAT EXISTS?

The NEXUS Knowledge Graph answers:

HOW IS IT CONNECTED?

The NEXUS Registry Schema answers:

HOW IS IT REPRESENTED?

The NEXUS Conformance Framework answers:

DOES IT SATISFY THE REQUIREMENTS?

The NEXUS Trust Framework answers:

HOW STRONG IS THE EVIDENCE?

The Evidence & Provenance Layer answers:

WHERE DID THE EVIDENCE COME FROM?

The Governance Constitution answers:

HOW IS THE SYSTEM GOVERNED?


69. FUNDAMENTAL DATA PRINCIPLE

NEXUS records should preserve the distinction between:

OBJECT

IDENTIFIER

SOURCE

ASSERTION

RELATIONSHIP

EVIDENCE

RESULT

CLASSIFICATION

INTERPRETATION

These concepts must not be silently collapsed into one field.


70. FINAL PRINCIPLE

The NEXUS Registry Schema exists so that the NEXUS infrastructure can speak in a consistent machine-readable language.

Its fundamental chain is:

IDENTITY

→ SOURCE

→ RELATIONSHIP

→ PROVENANCE

→ EVIDENCE

→ CONFORMANCE

→ TRUST

→ VERSION

→ STATUS

A machine consuming NEXUS should be able to follow this chain without relying solely on natural-language interpretation.


NEXUS REGISTRY SCHEMA

Version 1.0

Status: FOUNDATIONAL

Machine-Readable Data Model

Universal Standards Registry

Knowledge Graph

Conformance

Trust

Evidence & Provenance

Governance


NEXUS

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

https://www.null-state.dev/registry-schema