NEXUS JSON REGISTRY
Machine-Readable Public Registry
Version 1.0
Status: OPERATIONAL
Registry Identifier: NS:JSON
1. PURPOSE
The NEXUS JSON Registry is the machine-readable representation layer of the NEXUS Universal Standards Registry.
Its purpose is to expose structured NEXUS records in a format that can be consumed by:
software systems;
search engines;
data pipelines;
knowledge graphs;
validation tools;
researchers;
developers;
automated agents;
AI systems;
and other registries.
This page defines the canonical conceptual JSON representation used by NEXUS.
The human-readable NEXUS pages explain the system.
The JSON Registry exposes the system as structured data.
The relationship is:
HUMAN-READABLE NEXUS
↓
REGISTRY MODEL
↓
JSON REPRESENTATION
↓
MACHINE PROCESSING
2. REGISTRY IDENTITY
The NEXUS machine-readable namespace is:
NS
The canonical NEXUS namespace is:
https://www.null-state.dev/ns/
The public registry entry point is:
https://www.null-state.dev/json
The registry itself is identified as:
NS:JSON
Individual records use stable NEXUS identifiers.
Example:
NS:NEXUS:SPEC:000001
NS:NEXUS:ORG:000001
NS:NEXUS:EVIDENCE:000001
NS:NEXUS:CONF:000001
NS:NEXUS:TRUST:000001
3. WHAT THIS REGISTRY IS
The NEXUS JSON Registry is a structured publication layer.
It records:
IDENTITY
TYPE
STATUS
VERSION
SOURCE
RELATIONSHIPS
PROVENANCE
EVIDENCE
CONFORMANCE
TRUST
SCOPE
TEMPORAL STATE
CANONICAL REFERENCES
It is designed so that a machine can navigate from an object to the information needed to understand that object.
For example:
OBJECT
↓
SOURCE
↓
PROVENANCE
↓
RELATIONSHIPS
↓
EVIDENCE
↓
CONFORMANCE
↓
TRUST
4. WHAT THIS REGISTRY IS NOT
The existence of a JSON record does not automatically mean that the record is:
legally authoritative;
officially certified;
government-approved;
accredited;
universally accepted;
endorsed by another standards organization;
or independently verified.
A JSON record means that NEXUS has published a structured representation of the identified object or assertion.
NEXUS authority applies only within the scope of NEXUS's own registry, specifications, classifications, and governance.
The authority of an external organization remains determined by that organization and the applicable external framework.
5. MACHINE-READABLE PRINCIPLE
The registry follows the principle:
IF A CONCEPT IS IMPORTANT TO THE NEXUS MODEL, IT SHOULD BE REPRESENTABLE AS STRUCTURED DATA.
This includes:
objects
claims
sources
relationships
evidence
provenance
versions
statuses
reviews
conformance
trust
disputes
corrections
Human-readable prose may explain these concepts.
JSON provides their machine-readable representation.
6. ROOT REGISTRY OBJECT
The root registry document may be represented as:
{
"registry": {
"id": "NS:JSON",
"name": "NEXUS Universal Standards Registry",
"version": "1.0",
"status": "OPERATIONAL",
"namespace": "https://www.null-state.dev/ns/",
"canonical": "https://www.null-state.dev/json"
}
}
The root object identifies the registry itself.
It does not need to contain every registry record.
Large registries should be navigable through indexed collections and individual record endpoints.
7. REGISTRY INDEX
A registry index may contain:
{
"registry": "NS:JSON",
"records": [
{
"id": "NS:NEXUS:SPEC:000001",
"type": "Specification",
"status": "CURRENT",
"version": "1.0"
},
{
"id": "NS:NEXUS:ORG:000001",
"type": "Organization",
"status": "CURRENT"
}
]
}
The index is intended for discovery.
Individual records contain detailed information.
This separation allows machines to discover the registry without requiring every record to be loaded simultaneously.
8. CORE RECORD TYPES
NEXUS recognizes the following core record types:
Specification
Implementation
Organization
Dataset
Evidence
ConformanceReport
TrustRecord
Relationship
Version
Assertion
Review
ProvenanceRecord
Additional record types may be introduced through versioned NEXUS specifications.
9. COMMON RECORD STRUCTURE
A NEXUS record should generally contain:
{
"id": "NS:NEXUS:TYPE:000001",
"type": "RecordType",
"name": "Example Record",
"status": "CURRENT",
"version": "1.0",
"canonical": "https://www.null-state.dev/...",
"created": "2026-01-01T00:00:00Z",
"modified": "2026-01-01T00:00:00Z"
}
Not every record requires every property.
The exact required properties depend on record type.
10. IDENTITY
Every registered object should have a stable identifier.
Example:
{
"id": "NS:NEXUS:SPEC:000001"
}
The identifier should remain stable across ordinary metadata updates.
A versioned representation may change without changing the conceptual identity of the object.
11. TYPES
The type property identifies the semantic class of the record.
Examples:
{
"type": "Specification"
}
{
"type": "Implementation"
}
{
"type": "Evidence"
}
{
"type": "TrustRecord"
}
Machines should use type to determine how a record should be interpreted.
12. STATUS
NEXUS status values include:
CURRENT
DRAFT
PROPOSED
EXPERIMENTAL
HISTORIC
SUPERSEDED
WITHDRAWN
DISPUTED
UNKNOWN
Status refers to the NEXUS registry representation unless explicitly identified as an external status.
NEXUS should not overwrite an external organization's status with its own status.
13. EXTERNAL STATUS
Where an object has an externally defined status, NEXUS may represent it separately.
Example:
{
"status": "CURRENT",
"externalStatus": {
"source": "https://example.org/specification",
"value": "Official"
}
}
This distinction prevents a machine from confusing:
NEXUS STATUS
with:
EXTERNAL STATUS
14. VERSION
Version information should be explicit.
Example:
{
"version": "2.0"
}
A record may also contain:
{
"version": {
"value": "2.0",
"released": "2026-08-01",
"previous": "NS:NEXUS:SPEC:000001@1.0"
}
}
Version relationships must remain traceable.
15. CANONICAL REFERENCE
Where possible, a NEXUS record should provide a canonical reference.
Example:
{
"canonical": "https://example.org/specification"
}
The canonical reference identifies the relevant external or NEXUS resource.
A canonical reference does not transfer ownership or authority.
16. SOURCES
Sources may be represented directly:
{
"sources": [
{
"id": "NS:NEXUS:SOURCE:000001",
"type": "CanonicalSource",
"url": "https://example.org/source",
"version": "1.0"
}
]
}
A source should be distinguishable from an assertion derived from that source.
17. ASSERTIONS
An assertion may be represented as:
{
"id": "NS:ASSERTION:000001",
"type": "Assertion",
"subject": "NS:NEXUS:SPEC:000001",
"predicate": "publishedBy",
"object": "NS:NEXUS:ORG:000001",
"source": "NS:NEXUS:SOURCE:000001",
"status": "VERIFIED"
}
This structure allows a machine to distinguish:
SUBJECT
PREDICATE
OBJECT
SOURCE
STATUS
rather than treating the entire statement as unstructured prose.
18. RELATIONSHIPS
Relationships connect records.
Example:
{
"id": "NS:REL:000001",
"type": "Relationship",
"subject": "NS:NEXUS:IMPL:000001",
"predicate": "implements",
"object": "NS:NEXUS:SPEC:000001",
"status": "ASSERTED"
}
Supported relationship predicates include:
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
19. RELATIONSHIP STATUS
Relationships may have their own status:
ASSERTED
REVIEWED
VERIFIED
DISPUTED
WITHDRAWN
UNKNOWN
This is important because the existence of a relationship in the registry does not necessarily mean that it has been independently verified.
20. EVIDENCE REFERENCES
Evidence can be attached to assertions and relationships.
Example:
{
"id": "NS:REL:000001",
"type": "Relationship",
"subject": "NS:NEXUS:IMPL:000001",
"predicate": "implements",
"object": "NS:NEXUS:SPEC:000001",
"evidence": [
"NS:EVIDENCE:000001",
"NS:EVIDENCE:000002"
]
}
This allows machines to navigate directly from a relationship to its supporting evidence.
21. PROVENANCE REFERENCES
A record may contain provenance:
{
"provenance": [
"NS:PROV:000001"
]
}
The provenance record can identify:
source
activity
agent
time
transformation
derivation
This prevents the registry from becoming a collection of unexplained assertions.
22. EVIDENCE RECORD
Example:
{
"id": "NS:EVIDENCE:000001",
"type": "Evidence",
"subject": "NS:ASSERTION:000001",
"evidenceType": "DOCUMENTARY",
"source": "NS:NEXUS:SOURCE:000001",
"status": "VERIFIED",
"scope": "FULL",
"observedAt": "2026-08-20T12:00:00Z"
}
The evidence object should describe what it supports and within what scope.
23. CONFORMANCE RECORD
A conformance report may be represented as:
{
"id": "NS:CONF:000001",
"type": "ConformanceReport",
"subject": "NS:NEXUS:IMPL:000001",
"specification": "NS:NEXUS:SPEC:000001",
"status": "CONFORMANT",
"method": "AUTOMATED",
"evidence": [
"NS:EVIDENCE:000010"
]
}
Conformance should always be interpreted according to its declared:
scope
requirements
tests
version
method
evidence
24. CONFORMANCE RESULT
Individual tests may be represented as:
{
"testId": "T-001",
"requirement": "R-001",
"result": "PASS",
"evidence": "NS:EVIDENCE:000010"
}
Supported result values include:
PASS
FAIL
PARTIAL
NOT-APPLICABLE
NOT-TESTED
INCONCLUSIVE
DISPUTED
This makes the path from requirement to evidence machine-navigable.
25. TRUST RECORD
A trust record may be represented as:
{
"id": "NS:TRUST:000001",
"type": "TrustRecord",
"subject": "NS:NEXUS:SPEC:000001",
"trustClass": "T3",
"evidence": [
"NS:EVIDENCE:000001",
"NS:EVIDENCE:000002"
],
"reviewStatus": "REVIEWED",
"scope": "Declared registry scope"
}
Trust classifications remain contextual.
A trust classification is not a universal declaration of truth.
26. TRUST CLASSES
The NEXUS Trust Framework defines:
T0 — UNVERIFIED
T1 — SOURCE VERIFIED
T2 — INDEPENDENTLY REVIEWED
T3 — IMPLEMENTED
T4 — INTEROPERABILITY TESTED
T5 — INDEPENDENTLY ADOPTED
The JSON registry should expose the classification together with its supporting evidence and scope.
27. EVIDENCE CLASSES
Evidence strength may also be represented through:
E0 — NONE
E1 — ASSERTION
E2 — DOCUMENTARY
E3 — REPRODUCIBLE
E4 — INDEPENDENT
E5 — MULTI-SOURCE
These classifications describe evidentiary state within NEXUS.
They do not constitute legal certification, accreditation, or universal truth rankings.
28. REVIEW
A review record may be represented as:
{
"id": "NS:REVIEW:000001",
"type": "Review",
"subject": "NS:EVIDENCE:000001",
"reviewStatus": "REVIEWED",
"method": "DOCUMENTARY",
"reviewedAt": "2026-08-21T10:00:00Z",
"scope": "Source identity and version"
}
The scope of review must remain explicit.
29. PROVENANCE
Example:
{
"id": "NS:PROV:000001",
"type": "ProvenanceRecord",
"entity": "NS:EVIDENCE:000001",
"activity": "NS:ACTIVITY:000001",
"agent": "NS:AGENT:000001"
}
A provenance chain may be represented as:
SOURCE
↓
RETRIEVAL
↓
TRANSFORMATION
↓
ASSERTION
↓
EVIDENCE
↓
REVIEW
↓
RESULT
30. MACHINE NAVIGATION
A machine should be able to follow references.
Example:
NS:NEXUS:SPEC:000001
↓
NS:REL:000001
↓
NS:NEXUS:IMPL:000001
↓
NS:EVIDENCE:000001
↓
NS:PROV:000001
↓
NS:REVIEW:000001
This creates a machine-navigable knowledge graph.
31. SELF-DESCRIBING RECORDS
NEXUS records should contain enough metadata to identify their semantic role.
Example:
{
"id": "NS:NEXUS:SPEC:000001",
"type": "Specification",
"name": "Example Specification",
"status": "CURRENT"
}
Machines should not be required to infer the fundamental record type solely from page layout or surrounding prose.
32. JSON-LD COMPATIBILITY
NEXUS JSON may be represented as JSON-LD.
Example:
{
"@context": {
"nexus": "https://www.null-state.dev/ns/",
"id": "@id",
"type": "@type",
"name": "https://schema.org/name"
},
"id": "https://www.null-state.dev/registry/000001",
"type": "nexus:Specification",
"name": "Example Specification"
}
JSON-LD provides a bridge between ordinary JSON and linked-data environments.
33. SCHEMA.ORG COMPATIBILITY
Where appropriate, NEXUS may expose mappings to Schema.org concepts.
For example:
NEXUS Dataset
↓
Schema.org Dataset
or:
NEXUS Organization
↓
Schema.org Organization
Such mappings are interoperability mechanisms.
They do not mean that Schema.org defines the NEXUS registry model.
34. EXTERNAL IDENTIFIERS
NEXUS records may contain identifiers from other systems.
Example:
{
"externalIdentifiers": [
{
"system": "ExampleRegistry",
"identifier": "ABC-123"
}
]
}
External identifiers must remain distinguishable from NEXUS identifiers.
NEXUS should not rewrite external identifiers into NEXUS identifiers without preserving the original value and source.
35. CANONICALIZATION
A machine-readable record may have:
canonical identity
registry representation
external source
version
These should not be conflated.
For example:
OBJECT
↓
NEXUS RECORD
↓
EXTERNAL SOURCE
The registry record describes the object.
It is not necessarily the object itself.
36. RECORD INTEGRITY
Where technically appropriate, records may contain integrity information.
Example:
{
"integrity": {
"algorithm": "SHA-256",
"digest": "..."
}
}
Integrity metadata helps identify a particular representation.
It does not establish the truth of the content.
37. TIMESTAMPS
NEXUS records should use machine-readable timestamps where practical.
Example:
2026-08-20T12:00:00Z
Relevant temporal fields may include:
created
modified
published
observedAt
retrievedAt
reviewedAt
supersededAt
withdrawnAt
Temporal information helps preserve historical state.
38. HISTORICAL RECORDS
The registry should preserve historical information.
If:
Version 1.0
is superseded by:
Version 2.0
the earlier record should remain discoverable.
Example:
{
"id": "NS:NEXUS:SPEC:000001",
"status": "SUPERSEDED",
"supersededBy": "NS:NEXUS:SPEC:000002"
}
Historical status should not be silently rewritten to CURRENT.
39. DISPUTES
Disputes may be represented:
{
"dispute": {
"id": "NS:DISPUTE:000001",
"status": "OPEN",
"subject": "NS:ASSERTION:000001",
"reason": "Competing source interpretation"
}
}
A disputed record should remain identifiable as disputed.
The registry should not conceal substantive disagreement.
40. CORRECTIONS
Corrections may be represented:
{
"correction": {
"id": "NS:CORRECTION:000001",
"corrects": "NS:NEXUS:SPEC:000001",
"reason": "Incorrect version metadata"
}
}
Corrections preserve historical integrity while allowing the current representation to improve.
41. SCOPE
Every major classification should be capable of specifying scope.
Example:
{
"scope": {
"subject": "NS:NEXUS:IMPL:000001",
"version": "2.0",
"environment": "Declared test environment",
"coverage": "Partial"
}
}
A classification without scope may be misleading.
42. UNCERTAINTY
NEXUS JSON should be capable of representing uncertainty.
Example:
{
"status": "UNKNOWN",
"confidence": null,
"limitations": [
"Insufficient evidence for independent verification."
]
}
NEXUS should prefer explicit uncertainty over invented precision.
43. NO AUTOMATIC FACT PROMOTION
A machine-readable record must not be interpreted as:
JSON RECORD = UNIVERSAL FACT
Instead:
JSON RECORD
↓
NEXUS ASSERTION
↓
SOURCE
↓
EVIDENCE
↓
REVIEW
↓
RESULT
This distinction is essential for responsible AI consumption.
44. AI CONSUMPTION
AI systems may use the NEXUS JSON Registry as a structured information source.
An AI agent should be able to retrieve:
identity
source
version
status
relationships
evidence
provenance
review
conformance
trust
limitations
An AI system should not treat a registry entry as independent proof merely because it is machine-readable.
The preferred interpretation is:
REGISTERED
≠
PROVEN
and:
STRUCTURED
≠
AUTHORITATIVE
45. AGENT NAVIGATION
An agent may begin with:
NS:NEXUS:SPEC:000001
and follow:
source
relationships
evidence
provenance
review
conformance
trust
versions
This creates a structured path for agentic retrieval.
The agent does not need to infer the entire semantic structure from unstructured HTML.
46. REGISTRY QUERY MODEL
Future NEXUS implementations may support queries such as:
GET specification
GET implementation
GET evidence
GET provenance
GET relationship
GET conformance
GET trust
GET version
Conceptually:
/registry/{id}
may resolve a specific record.
The exact API surface may evolve independently of this conceptual JSON specification.
47. COLLECTIONS
Large record collections may be represented as:
{
"collection": "Specifications",
"count": 100,
"items": [
"NS:NEXUS:SPEC:000001",
"NS:NEXUS:SPEC:000002"
]
}
Collections should remain navigable without requiring a single enormous document.
48. PAGINATION
If a collection becomes large, pagination may be used.
Example:
{
"items": [
"NS:NEXUS:SPEC:000001",
"NS:NEXUS:SPEC:000002"
],
"next": "https://www.null-state.dev/json?cursor=..."
}
Pagination should preserve deterministic navigation.
49. ERROR MODEL
Machine-readable systems must also represent failure.
Example:
{
"error": {
"code": "RECORD_NOT_FOUND",
"message": "The requested NEXUS record does not exist.",
"requestedId": "NS:NEXUS:SPEC:999999"
}
}
Potential error categories include:
RECORD_NOT_FOUND
INVALID_IDENTIFIER
INVALID_RECORD
UNSUPPORTED_VERSION
ACCESS_UNAVAILABLE
SOURCE_UNAVAILABLE
PROVENANCE_UNAVAILABLE
Errors should not be silently converted into empty or successful responses.
50. VALIDATION
NEXUS JSON should support structural validation.
Validation may check:
identifier format
record type
required properties
allowed status values
relationship structure
date format
version structure
reference integrity
Semantic validation may additionally check:
source compatibility
version relationships
evidence scope
provenance consistency
conformance consistency
trust consistency
A structurally valid JSON document is not automatically semantically correct.
51. EXTENSIBILITY
NEXUS JSON is designed to be extensible.
New fields may be introduced through versioned specifications.
Extensions should:
use explicit names;
preserve existing semantics;
avoid redefining established fields;
document their meaning;
remain machine-readable;
preserve backward compatibility where practical.
Unknown fields should not automatically invalidate an otherwise valid record unless the applicable schema requires strict validation.
52. NAMESPACE POLICY
NEXUS-defined properties should use the NEXUS namespace.
Conceptually:
https://www.null-state.dev/ns/
External vocabularies should retain their original namespaces where appropriate.
This allows machines to distinguish:
NEXUS PROPERTY
from:
EXTERNAL VOCABULARY PROPERTY
53. CROSS-REGISTRY INTEROPERABILITY
NEXUS JSON is intended to interoperate with other information systems.
Possible relationships include:
NEXUS
↕
Schema.org
↕
JSON-LD
↕
RDF
↕
External Registries
Interoperability does not require identical semantics.
Mappings should document differences.
54. REGISTRY GRAPH
The JSON Registry and NEXUS Knowledge Graph are complementary.
JSON provides records.
The graph provides relationships.
Conceptually:
JSON
↓
RECORDS
↓
IDENTIFIERS
↓
RELATIONSHIPS
↓
GRAPH
A machine can therefore use JSON to retrieve node data and graph relationships to navigate the network.
55. PUBLIC MACHINE ENTRY POINT
The /json page is the public machine-readable entry point for NEXUS.
It should therefore remain:
stable
discoverable
structured
versioned
linked
machine-readable
human-inspectable
Where actual machine-readable endpoints become available, this page may serve as the directory to those endpoints.
56. RELATION TO THE NEXUS WEBSITE
The website contains multiple layers.
/nexus
Registry
/nexus-graph
Knowledge Graph
/registry-schema
Registry Schema
/evidence
Evidence & Provenance
/conformance
Conformance Framework
/trust
Trust Framework
/constitution
Governance Constitution
/json
Machine-Readable Registry
The /json layer connects the conceptual architecture to machine-readable publication.
57. CANONICAL NAVIGATION MODEL
A machine should be able to move through NEXUS according to:
REGISTRY
↓
OBJECT
↓
IDENTIFIER
↓
SOURCE
↓
RELATIONSHIP
↓
EVIDENCE
↓
PROVENANCE
↓
CONFORMANCE
↓
TRUST
↓
VERSION
↓
STATUS
This is the intended navigation architecture.
58. EXAMPLE COMPLETE RECORD
The following example demonstrates the intended structure:
{
"id": "NS:NEXUS:SPEC:000001",
"type": "Specification",
"name": "Example Specification",
"status": "CURRENT",
"version": "1.0",
"canonical": "https://example.org/specification",
"externalStatus": {
"source": "https://example.org/specification",
"value": "Official"
},
"sources": [
"NS:NEXUS:SOURCE:000001"
],
"relationships": [
"NS:REL:000001",
"NS:REL:000002"
],
"evidence": [
"NS:EVIDENCE:000001"
],
"provenance": [
"NS:PROV:000001"
],
"trust": [
"NS:TRUST:000001"
],
"created": "2026-08-20T12:00:00Z",
"modified": "2026-08-20T12:00:00Z"
}
This record is intentionally explicit.
A machine can discover the object's identity, status, version, source, relationships, evidence, provenance, and trust references without parsing a long human-readable essay.
59. RECORD GRAPH EXAMPLE
The complete graph may look like:
┌───────────────┐
│ SOURCE │
└───────┬───────┘
│
▼
┌───────────────┐
│ ASSERTION │
└───────┬───────┘
│
▼
┌───────────────┐ ┌───────────────┐
│ SPECIFICATION│────│ RELATIONSHIP│
└───────┬───────┘ └───────┬───────┘
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ IMPLEMENTATION│ │ EVIDENCE │
└───────┬───────┘ └───────┬───────┘
│ │
▼ ▼
┌───────────────┐ ┌───────────────┐
│ CONFORMANCE │ │ PROVENANCE │
└───────┬───────┘ └───────┬───────┘
│ │
└──────────┬──────────┘
▼
┌───────────────┐
│ TRUST │
└───────────────┘
The purpose of this structure is to preserve traceability.
60. DATA INTEGRITY PRINCIPLE
NEXUS adopts:
EVERY IMPORTANT MACHINE-READABLE CLAIM SHOULD BE TRACEABLE TO ITS SOURCE, SCOPE, AND PROVENANCE.
The JSON Registry therefore prioritizes:
IDENTITY
TRACEABILITY
VERSIONING
PROVENANCE
EVIDENCE
SCOPE
INTEROPERABILITY
HISTORICAL INTEGRITY
61. MACHINE-READABLE DOES NOT MEAN MACHINE-TRUSTED
A machine-readable statement is easier for software to process.
It is not automatically more trustworthy.
Therefore:
JSON
↓
PROCESSABLE
does not imply:
JSON
↓
TRUE
NEXUS preserves this distinction intentionally.
62. AI SAFETY PRINCIPLE
AI systems consuming NEXUS should prefer the following order:
IDENTIFY
↓
CHECK SOURCE
↓
CHECK VERSION
↓
CHECK STATUS
↓
CHECK PROVENANCE
↓
CHECK EVIDENCE
↓
CHECK REVIEW
↓
CHECK CONFORMANCE
↓
CHECK TRUST
↓
FORM RESPONSE
An agent should not stop at the first registry record if stronger evidence is available deeper in the graph.
63. PROVENANCE-FIRST RETRIEVAL
For important claims, an agent should be able to answer:
Where did this information originate?
The JSON Registry therefore exposes provenance references rather than hiding them inside implementation details.
This supports:
source-aware retrieval
evidence-aware reasoning
version-aware reasoning
uncertainty-aware reasoning
64. HUMAN AND MACHINE PARITY
NEXUS follows the principle:
THE HUMAN-READABLE REPRESENTATION AND THE MACHINE-READABLE REPRESENTATION SHOULD DESCRIBE THE SAME UNDERLYING REGISTRY STATE.
The machine representation should not secretly contain claims that are absent from the public human-readable record.
Likewise, important registry information should not exist only in prose when it can reasonably be represented structurally.
65. PUBLICATION INTEGRITY
When NEXUS publishes a machine-readable record, it should preserve:
record identity
record version
publication time
modification time
source references
provenance
status
Where applicable, integrity references may be included.
66. VERSION 1.0 STATUS
This document defines the conceptual NEXUS JSON Registry model for Version 1.0.
Future versions may add:
formal JSON Schema;
JSON-LD contexts;
API endpoints;
pagination specifications;
content negotiation;
cryptographic signatures;
verifiable credentials;
RDF serialization;
SPARQL-compatible graph access;
signed registry snapshots;
automated validation endpoints.
Such extensions must remain compatible with the foundational NEXUS principles.
67. IMPLEMENTATION REQUIREMENT
An implementation claiming compatibility with the NEXUS JSON Registry should:
expose stable identifiers;
identify record types;
preserve version information;
distinguish NEXUS status from external status;
expose source references;
support relationship references;
expose evidence where available;
expose provenance where available;
preserve uncertainty;
preserve disputes and corrections;
avoid unsupported authority claims;
remain machine-readable.
68. CONFORMANCE OF THE REGISTRY ITSELF
The NEXUS JSON Registry may itself be evaluated against the NEXUS Conformance Framework.
A future conformance report may identify:
schema version
implementation
test suite
test results
evidence
conformance result
This creates a recursive but controlled architecture:
NEXUS DEFINES REGISTRY MODEL
↓
REGISTRY IMPLEMENTATION
↓
REGISTRY TESTING
↓
REGISTRY EVIDENCE
↓
REGISTRY CONFORMANCE
The same evidence principles apply to the registry itself.
69. FUNDAMENTAL DATA MODEL
The NEXUS JSON Registry preserves the following distinctions:
OBJECT
≠
IDENTIFIER
≠
SOURCE
≠
ASSERTION
≠
RELATIONSHIP
≠
EVIDENCE
≠
PROVENANCE
≠
RESULT
≠
CLASSIFICATION
≠
INTERPRETATION
This distinction is one of the foundational properties of the system.
70. NEXUS MACHINE CONTRACT
A machine consuming NEXUS should be able to determine:
WHAT IS THIS?
through:
type
WHICH OBJECT?
through:
id
WHICH VERSION?
through:
version
WHAT IS ITS STATUS?
through:
status
WHERE DID THE INFORMATION COME FROM?
through:
sources
provenance
WHAT RELATIONSHIPS EXIST?
through:
relationships
WHAT SUPPORTS THE CLAIM?
through:
evidence
WHAT WAS TESTED?
through:
conformance
HOW STRONG IS THE EVIDENCE?
through:
trust
This is the NEXUS machine-readable contract.
71. FINAL PRINCIPLE
The purpose of the NEXUS JSON Registry is not simply to put website information into JSON.
Its purpose is to transform the NEXUS architecture into a machine-navigable reference system.
The fundamental path is:
IDENTITY
↓
SOURCE
↓
ASSERTION
↓
RELATIONSHIP
↓
PROVENANCE
↓
EVIDENCE
↓
REVIEW
↓
CONFORMANCE
↓
TRUST
↓
VERSION
↓
STATUS
A machine should be able to follow this path without depending entirely on human interpretation.
72. FINAL DECLARATION
NEXUS JSON REGISTRY
Identifier: NS:JSON
Version: 1.0
Status: OPERATIONAL
The NEXUS JSON Registry provides a public machine-readable representation layer for the NEXUS Universal Standards Registry.
It is designed for interoperability between:
HUMANS
SOFTWARE
DATA SYSTEMS
KNOWLEDGE GRAPHS
SEARCH SYSTEMS
AI SYSTEMS
AUTOMATED AGENTS
Its governing principle is:
MAKE THE REGISTRY MACHINE-READABLE WITHOUT HIDING THE EVIDENCE CHAIN.
And its architectural rule is:
IDENTITY → SOURCE → PROVENANCE → EVIDENCE → RESULT → TRUST
NEXUS does not ask machines to trust the registry blindly.
It provides machines with the structure required to inspect, navigate, compare, and evaluate the information represented by the registry.
NEXUS Universal Standards Registry
Machine-Readable Public Registry
NS:JSON — Version 1.0