NEXUS EVIDENCE & PROVENANCE LAYER

Evidence, Provenance, Traceability and Verifiable Context

Version: 1.0
Status: FOUNDATIONAL
Identifier: NS:EVIDENCE
Layer: Evidence & Provenance
Registry: NEXUS Universal Standards Registry


1. PURPOSE

The NEXUS Evidence & Provenance Layer defines a structured framework for representing the evidence, provenance, derivation, transformation, review history and contextual basis associated with information recorded in the NEXUS ecosystem.

Its purpose is simple:

Every important claim should have a traceable path to its source, evidence and provenance.

NEXUS does not treat a statement as authoritative merely because it appears in a registry.

A registry record may contain:

These objects have different epistemic and technical properties.

The Evidence & Provenance Layer exists to preserve those distinctions.

It answers questions such as:

NEXUS therefore treats evidence and provenance as first-class infrastructure rather than optional metadata.


2. SCOPE

The NEXUS Evidence & Provenance Layer applies to information represented within or referenced by NEXUS, including:

This framework does not establish legal rules of evidence.

It does not determine the legal admissibility of evidence in courts or other proceedings.

Its purpose is technical, informational and provenance-oriented:

to make the origin, transformation, support and status of information traceable.


3. FUNDAMENTAL PRINCIPLE

NEXUS separates the following concepts:

SOURCE

→

ACQUISITION

→

TRANSFORMATION

→

ASSERTION

→

EVIDENCE

→

REVIEW

→

RESULT

→

CLASSIFICATION

These objects MUST NOT be silently collapsed into one another.

A source is not automatically an assertion.

An assertion is not automatically evidence.

Evidence is not automatically proof of universal truth.

A classification is not automatically external authority.

A cryptographic hash is not proof that the underlying content is true.

A citation is not necessarily independent verification.

A registry entry is not necessarily a canonical source.

The evidence chain must preserve these distinctions.


4. SOURCE

A Source is an identifiable origin from which information may be obtained.

Examples include:

A source SHOULD have, where available:

NEXUS MUST distinguish between the identity of a source and the claims made by that source.


5. SOURCE AUTHORITY

NEXUS does not automatically become the authoritative source merely because it registers another source.

For example:

If an organization publishes a technical specification and NEXUS records it, the organization remains the source of that specification.

NEXUS may provide:

NEXUS MUST NOT silently transfer source authority to itself.

The general rule is:

Registration does not equal authorship.

And:

Indexing does not equal endorsement.

And:

Classification does not equal external certification.


6. ASSERTIONS

An Assertion is a statement represented as a claim about an object, relationship, event, property or state.

Examples:

Assertions SHOULD identify:

An assertion MUST NOT be presented as independently established fact merely because it exists in the registry.


7. EVIDENCE

Evidence is information that supports, documents, tests, demonstrates or otherwise provides an observable basis for an assertion.

Evidence may include:

Evidence SHOULD be connected to the specific assertion it supports.

A broad citation should not automatically be interpreted as support for every statement contained in a record.


8. EVIDENCE IS CONTEXTUAL

Evidence must be evaluated in context.

The same evidence may support one claim strongly while providing little or no support for another.

For example:

A repository may demonstrate that a software implementation exists.

It does not, by itself, establish that:

Evidence must therefore be bound to the claim it actually supports.


9. EVIDENCE CLASSES

NEXUS defines the following evidence classes.

E0 — NONE

No supporting evidence has been identified.

This does not establish that the associated assertion is false.

It means only:

No evidence has been recorded in the applicable evidence chain.


E1 — ASSERTION

The information is based primarily on an identified assertion.

The assertion may have a source, but independent supporting evidence has not yet been established.


E2 — DOCUMENTARY

The assertion is supported by identifiable documentary material.

Examples:


E3 — REPRODUCIBLE

The evidence includes sufficient information, artifacts or procedures to permit meaningful reproduction of the observation or result.

Reproducibility may require:


E4 — INDEPENDENT

The evidence has been independently examined, reproduced or observed by a party not responsible for the original claim.

Independence MUST be evaluated in context.

A party may be independent for one purpose while having a relationship relevant to another.


E5 — MULTI-SOURCE

The assertion is supported by multiple materially distinct sources or evidence paths.

Multi-source support SHOULD identify:

Multiple copies of the same underlying claim do not automatically constitute independent evidence.


10. EVIDENCE TYPES

NEXUS recognizes the following evidence types.

DOCUMENTARY

Published or recorded textual material.

SOURCE-CODE

Code or executable source associated with an implementation.

REPOSITORY

A versioned repository containing identifiable artifacts or development history.

AUTOMATED-TEST

Machine-generated test output.

MANUAL-TEST

Human-performed test or inspection.

HYBRID-TEST

A combination of automated and manual procedures.

INTEROPERABILITY-TEST

Evidence that independently identifiable systems interacted according to a defined protocol, interface or specification.

DEPLOYMENT

Evidence derived from an identifiable deployment or operational environment.

OBSERVATION

Directly observed behavior or state.

RESEARCH

Evidence originating from structured research activity.

REPRODUCTION

Independent reproduction of an earlier observation, result or experiment.

SIGNED-ARTIFACT

An artifact accompanied by a cryptographic signature or equivalent integrity/authenticity mechanism.

HASH

A cryptographic digest associated with a specific artifact.

TIMESTAMP

A record of when an artifact, event or observation was recorded.

MULTI-SOURCE

Evidence assembled from multiple distinct sources.


11. EVIDENCE STATUS

Each evidence object SHOULD have a status.

AVAILABLE

The evidence is currently accessible.

VERIFIED

The evidence has been checked against defined verification criteria.

REPRODUCIBLE

The evidence can be independently reproduced under a defined procedure.

DISPUTED

A material challenge has been raised concerning the evidence or its interpretation.

INVALID

The evidence has been determined to be invalid for the relevant purpose.

UNAVAILABLE

The evidence existed or was referenced but cannot currently be accessed.

SUPERSEDED

The evidence remains historically relevant but has been replaced by a newer applicable evidence record.


12. PROVENANCE

Provenance describes the history and origin of an entity, observation, assertion or artifact.

NEXUS treats provenance as a chain rather than a single field.

A provenance chain may include:

ORIGIN

→

ACQUISITION

→

PROCESSING

→

TRANSFORMATION

→

DERIVATION

→

PUBLICATION

→

REVIEW

→

USE

This allows systems to understand not only what information exists, but how that information came to exist in its current form.


13. PROVENANCE OBJECTS

The NEXUS provenance model is compatible in concept with established provenance modeling approaches, including the W3C PROV family of concepts.

NEXUS uses three fundamental categories:

ENTITY

A physical, digital or conceptual object.

Examples:

ACTIVITY

An operation, event or process that acts upon entities.

Examples:

AGENT

An entity responsible for or associated with an activity.

Examples:

These categories allow provenance to be represented without pretending that the final representation is identical to its source.


14. PROVENANCE RELATIONSHIPS

NEXUS may represent provenance using relationships such as:

wasDerivedFrom

Indicates that one entity was derived from another.

wasGeneratedBy

Connects an entity to the activity that generated it.

wasAttributedTo

Connects an entity to an agent associated with its creation or maintenance.

used

Indicates that an activity used an entity.

wasAssociatedWith

Connects an activity with an associated agent.

wasInfluencedBy

Represents a broader influence relationship where a more specific provenance relationship is not appropriate.

specializationOf

Indicates that one entity represents a more specific version or specialization of another entity.

alternateOf

Indicates that two entities represent alternative forms or representations of related content.

These relationships are intended to make derivation and responsibility explicit.


15. NEXUS PROVENANCE CHAIN

The canonical NEXUS provenance chain is:

SOURCE

→

ACQUISITION

→

TRANSFORMATION

→

ASSERTION

→

EVIDENCE

→

REVIEW

→

RESULT

→

CLASSIFICATION

For example:

A specification is retrieved from its publisher.

↓

The retrieved document is identified and stored or referenced.

↓

A parser extracts structured metadata.

↓

NEXUS creates a registry assertion.

↓

The assertion is linked to the source document.

↓

The record is reviewed.

↓

The review produces a result.

↓

The registry assigns an internal classification where appropriate.

The resulting NEXUS record MUST preserve the relationship between the original source and the derived representation.


16. TRANSFORMATION INTEGRITY

NEXUS may normalize, parse, transform or summarize external information.

When this occurs, NEXUS MUST distinguish:

WHAT THE SOURCE SAYS

from

WHAT NEXUS DERIVED FROM THE SOURCE.

A transformation does not become part of the original source merely because NEXUS performed it.

Examples of transformations include:

The transformation SHOULD be recorded as provenance.


17. DERIVED INFORMATION

Derived information is information produced from one or more existing sources.

Examples:

Derived information SHOULD identify:

A derived record MUST NOT be represented as though it were directly published by the original source.


18. CRYPTOGRAPHIC INTEGRITY

Cryptographic hashes may be used to identify or verify the integrity of an artifact.

For example:

SHA-256

may provide a stable digest associated with a particular byte sequence.

A matching hash can help establish:

However:

Integrity is not truth.

A valid hash does not prove that the underlying content is correct.

Likewise:

A digital signature may provide evidence that an artifact was signed by a particular key or authority under an applicable signature system.

It does not automatically establish that every claim contained within the artifact is true.

NEXUS therefore separates:

IDENTITY

INTEGRITY

AUTHENTICITY

AUTHORITY

TRUTH

These are different properties.


19. TIMESTAMPS

Evidence SHOULD include timestamps where relevant.

Possible timestamps include:

Timestamps SHOULD identify the applicable time standard where necessary.

A timestamp indicates when something was recorded or occurred.

It does not by itself establish the correctness of the associated information.


20. CANONICAL REFERENCES

Evidence references SHOULD use stable identifiers whenever possible.

A reference may include:

A generic homepage SHOULD NOT automatically be treated as precise evidence for a detailed technical claim.

Where possible, evidence should point to the smallest stable source location that materially supports the assertion.


21. VERSION BINDING

Evidence SHOULD be bound to a specific version where the source is versioned.

For example:

Specification X — Version 2.1

should not silently be used as evidence for a claim about:

Specification X — Version 3.0

unless the relationship between those versions is explicitly established.

NEXUS therefore treats version as part of provenance.

A provenance record SHOULD preserve:


22. EVIDENCE QUALITY DIMENSIONS

Evidence may be evaluated along several dimensions.

AUTHENTICITY

Can the origin of the evidence be reasonably established?

INTEGRITY

Can unauthorized alteration be detected?

PROVENANCE

Is the history of the evidence known?

RELEVANCE

Does the evidence actually relate to the assertion?

SPECIFICITY

Does it support the particular claim being made?

COMPLETENESS

Does the evidence cover the necessary scope?

REPRODUCIBILITY

Can the result be reproduced?

INDEPENDENCE

Was the evidence generated or reviewed independently where required?

RECENCY

Is the evidence sufficiently current for the intended purpose?

These dimensions SHOULD be considered separately.

No single dimension automatically determines the overall quality of evidence.


23. EVIDENCE SCOPE

Every evidence record SHOULD define its scope.

Scope may include:

A test performed on one implementation under one configuration MUST NOT automatically be generalized to all implementations.

A research result obtained under one experimental condition MUST NOT automatically be interpreted as universal.

A source published at one point in time MUST NOT automatically represent its author's current position.


24. REPRODUCIBILITY

Where reproducibility is claimed, the evidence record SHOULD provide enough information to permit meaningful independent reproduction.

Depending on context, this may include:

A claim of reproducibility SHOULD NOT be made merely because instructions exist.

Reproducibility should be connected to an actual reproducible procedure or observation.


25. INDEPENDENCE

Independence is contextual.

An evaluator may be independent from the implementation author while still relying on the same underlying source.

Two reports may appear independent while both copying the same original assertion.

Therefore NEXUS SHOULD distinguish:

MULTIPLE SOURCES

from

INDEPENDENT SOURCES.

Where possible, provenance should reveal common ancestry.


26. EVIDENCE CHAIN OF CUSTODY

NEXUS may maintain a technical chain of custody for evidence artifacts.

This may include:

This mechanism is intended for technical traceability.

It does not claim to establish legal chain-of-custody requirements in any jurisdiction.


27. REVIEW

Evidence may be reviewed by:

Review status may include:

NOT-REVIEWED

IN-REVIEW

REVIEWED

VERIFIED

DISPUTED

WITHDRAWN

A review status MUST identify what was actually reviewed.

Review of the existence of a document is not equivalent to review of every technical claim inside the document.


28. EVIDENCE AND CONFORMANCE

Evidence and conformance are related but distinct.

The conformance layer answers:

Does a defined subject satisfy defined requirements under a defined evaluation scope?

The evidence layer answers:

What information supports the assertion or result?

The canonical relationship is:

REQUIREMENT

→

TEST

→

EVIDENCE

→

RESULT

→

CONFORMANCE STATUS

A conformance claim without an identifiable evidence chain SHOULD be treated as weaker than one with reproducible and independently reviewable evidence.


29. EVIDENCE AND TRUST

Trust classification depends partly on evidence quality.

The relationship may be represented as:

CLAIM

→

EVIDENCE

→

REVIEW

→

TRUST CLASSIFICATION

NEXUS trust classifications remain contextual.

A high trust classification for one property does not automatically imply trust for every other property of the same object.


30. EVIDENCE AND THE KNOWLEDGE GRAPH

Evidence is a first-class graph object.

A graph may represent:

SPECIFICATION

— published-by →

ORGANIZATION

SPECIFICATION

— supported-by →

EVIDENCE

EVIDENCE

— derived-from →

SOURCE

EVIDENCE

— generated-by →

ACTIVITY

ACTIVITY

— associated-with →

AGENT

ASSERTION

— supported-by →

EVIDENCE

This allows machines to traverse the evidence chain instead of treating a registry record as an isolated statement.


31. EVIDENCE AND AI SYSTEMS

AI systems SHOULD NOT collapse:

SOURCE

into

CLAIM

or:

CLAIM

into

FACT.

An AI agent consuming NEXUS information SHOULD preserve the distinction between:

When answering a question, an agent SHOULD prefer evidence-linked information over unsupported assertions.

An agent SHOULD be able to state:


32. AI EVIDENCE PATH

The recommended machine reasoning path is:

OBJECT

→

IDENTIFIER

→

SOURCE

→

ASSERTION

→

PROVENANCE

→

EVIDENCE

→

REVIEW

→

CONFORMANCE

→

TRUST

→

VERSION

→

STATUS

The existence of a NEXUS record MUST NOT cause an AI system to skip this chain.


33. NO EVIDENCE ≠ FALSE

NEXUS explicitly distinguishes absence of evidence from evidence of absence.

If no evidence has been recorded, the appropriate state may be:

E0 — NONE

or:

UNKNOWN

or:

NOT-EVALUATED

depending on context.

NEXUS MUST NOT automatically convert:

“No evidence recorded”

into:

“The claim is false.”

Likewise, the existence of evidence does not automatically mean that the claim is universally true.

Evidence must be interpreted within scope.


34. EVIDENCE ≠ AUTHORITY

Evidence may support a claim without granting institutional authority.

A technical report may be strong evidence.

A test result may be strong evidence.

A government publication may be an authoritative source for a particular governmental matter.

A standards organization may be authoritative for its own publication process.

NEXUS may record these relationships.

It does not acquire the source's external institutional authority merely by recording them.


35. CONFLICTING EVIDENCE

When evidence conflicts, NEXUS SHOULD preserve the conflict rather than silently selecting one side.

A conflict record may include:

Possible states include:

UNRESOLVED

UNDER-REVIEW

PARTIALLY-RESOLVED

RESOLVED

DISPUTED

The existence of a conflict SHOULD remain visible when materially relevant.


36. CORRECTIONS

If an evidence record is found to contain an error, NEXUS SHOULD NOT silently overwrite the historical record.

Instead, it SHOULD preserve:

Historical integrity is part of provenance integrity.


37. WITHDRAWAL

Evidence may be withdrawn when:

Withdrawal SHOULD preserve the historical existence of the record while clearly marking its current status.

Withdrawal does not necessarily mean that the underlying event never occurred.


38. PRIVACY

NEXUS evidence systems SHOULD minimize unnecessary personal information.

Evidence SHOULD NOT expose sensitive or identifying information merely because it is technically available.

Where appropriate, systems should use:

Public traceability must not become an excuse for unnecessary disclosure.


39. SECURITY

Evidence infrastructure SHOULD protect:

Security mechanisms MAY include:

Security mechanisms should be documented rather than implied.


40. MACHINE-READABLE EVIDENCE RECORD

A conceptual NEXUS evidence record may be represented as:

{

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

  "type": "Evidence",

  "status": "VERIFIED",

  "evidenceClass": "E3",

  "evidenceType": "AUTOMATED-TEST",

  "supports": [

    "NS:NEXUS:ASSERTION:000001"

  ],

  "source": {

    "id": "NS:NEXUS:SOURCE:000001",

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

  },

  "artifact": {

    "name": "test-results.json",

    "mediaType": "application/json",

    "sha256": "HASH-REPRESENTATION"

  },

  "activity": {

    "id": "NS:NEXUS:ACTIVITY:000001",

    "type": "AUTOMATED-TEST"

  },

  "agent": {

    "id": "NS:NEXUS:AGENT:000001",

    "type": "SoftwareAgent"

  },

  "version": "1.0",

  "scope": {

    "implementation": "NS:NEXUS:IMPLEMENTATION:000001",

    "environment": "DEFINED-TEST-ENVIRONMENT"

  },

  "created": "2026-01-01T00:00:00Z",

  "reviewStatus": "REVIEWED",

  "limitations": [

    "Evidence applies only to the declared implementation and test environment."

  ]

}


This representation is conceptual.

Implementations MAY extend the model while preserving the distinction between evidence, provenance, source and assertion.


41. MACHINE-READABLE PROVENANCE RECORD

A conceptual provenance record may be represented as:

{

  "id": "NS:PROV:000001",

  "type": "ProvenanceRecord",

  "entity": "NS:NEXUS:REGISTRY:000001",

  "wasDerivedFrom": [

    "NS:NEXUS:SOURCE:000001"

  ],

  "wasGeneratedBy": "NS:NEXUS:ACTIVITY:000001",

  "wasAttributedTo": "NS:NEXUS:AGENT:000001",

  "used": [

    "NS:NEXUS:SOURCE:000001"

  ],

  "created": "2026-01-01T00:00:00Z",

  "method": "NEXUS-REGISTRY-NORMALIZATION",

  "methodVersion": "1.0"

}


The purpose is to make the derivation of a registry record inspectable by machines.


42. JSON-LD COMPATIBILITY

NEXUS evidence and provenance records MAY be represented using JSON-LD.

A conceptual representation may include:

{

  "@context": {

    "id": "@id",

    "type": "@type",

    "prov": "http://www.w3.org/ns/prov#",

    "evidence": "https://www.null-state.dev/ns/evidence#"

  },

  "id": "https://www.null-state.dev/evidence/NS:EVIDENCE:000001",

  "type": "evidence:Evidence",

  "evidence:evidenceClass": "E3",

  "prov:wasDerivedFrom": {

    "id": "NS:NEXUS:SOURCE:000001"

  }

}


The exact context used by production implementations SHOULD be versioned and documented.

NEXUS SHOULD maintain compatibility with established semantic-web and provenance practices while preserving its own registry semantics.


43. EVIDENCE IDENTIFIERS

Evidence objects SHOULD receive stable identifiers.

Recommended form:

NS:EVIDENCE:<LOCAL-ID>

Examples:

NS:EVIDENCE:000001

NS:EVIDENCE:000002

NS:EVIDENCE:000003

Provenance records may use:

NS:PROV:<LOCAL-ID>

Examples:

NS:PROV:000001

NS:PROV:000002

Identifiers SHOULD remain stable even when the evidence record is updated.

Version changes SHOULD be represented separately.


44. EVIDENCE RECORD LIFECYCLE

A typical evidence lifecycle is:

DISCOVERED

↓

IDENTIFIED

↓

ACQUIRED

↓

NORMALIZED

↓

LINKED

↓

REVIEWED

↓

VERIFIED

↓

REPRODUCED

↓

PUBLISHED

↓

UPDATED

↓

SUPERSEDED

or:

DISPUTED

or:

WITHDRAWN

Not every evidence record will pass through every state.

The lifecycle should reflect actual events rather than an idealized process.


45. SOURCE ACQUISITION

When external material is acquired, NEXUS SHOULD record, where practical:

Acquisition metadata allows later users to determine what material was actually used to create a registry record.


46. NORMALIZATION

NEXUS may normalize heterogeneous sources into a common registry model.

Examples include:

Normalization MUST NOT erase meaningful distinctions contained in the source.

If a source uses a specific terminology, NEXUS may map it to an internal vocabulary, but the original terminology SHOULD remain recoverable where relevant.


47. PROVENANCE OF AUTOMATED AGENTS

Automated agents may participate in evidence processing.

An automated process SHOULD identify:

For example:

AGENT: NEXUS-PARSER

VERSION: 1.4.0

ACTIVITY: METADATA-EXTRACTION

INPUT: SOURCE-0001

OUTPUT: RECORD-0001

This allows machine-generated transformations to remain traceable.


48. HUMAN REVIEW

Where human review occurs, NEXUS MAY record:

The existence of human review does not automatically establish correctness.

The review must be interpreted according to its scope and methodology.


49. AUTOMATED VERIFICATION

Automated verification may include:

Automated verification SHOULD report:

A successful automated check proves only what the check was designed to establish.


50. EVIDENCE GRANULARITY

Evidence should be as granular as reasonably practical.

For example:

Weak:

Source: Organization Website

Stronger:

Source: Organization X / Specification Y / Version 2.1 / Section 4.3

Even stronger where technically appropriate:

Source: Specification Y / Version 2.1 / Section 4.3 / Stable fragment / Retrieved timestamp / Integrity reference

Granular evidence improves:


51. EVIDENCE DEPENDENCY

Evidence may depend on other evidence.

For example:

CONFORMANCE RESULT

may depend on:

TEST OUTPUT

which may depend on:

TEST PROCEDURE

which may depend on:

SPECIFICATION VERSION

The dependency chain SHOULD remain explicit.

This enables systems to identify where a result ultimately derives from.


52. EVIDENCE GRAPH

The NEXUS Evidence Graph can be represented conceptually as:

SOURCE

↓

ARTIFACT

↓

ACTIVITY

↓

DERIVED ENTITY

↓

ASSERTION

↓

EVIDENCE

↓

REVIEW

↓

RESULT

↓

CLASSIFICATION

This graph allows downstream systems to traverse backward from a classification to the underlying evidence.


53. TRACEABILITY REQUIREMENT

A significant NEXUS claim SHOULD be traceable to one or more of:

If no such path exists, the record SHOULD explicitly indicate the absence of supporting evidence.

Traceability is preferable to implied certainty.


54. EVIDENCE EXPIRATION AND RECENCY

Evidence may become outdated.

Examples:

NEXUS SHOULD therefore preserve both:

HISTORICAL VALIDITY

and

CURRENT APPLICABILITY.

These are not necessarily the same.


55. HISTORICAL INTEGRITY

Historical evidence SHOULD remain identifiable after supersession.

A record may therefore be:

HISTORIC

without being:

INVALID.

For example, an older specification may remain valid evidence of what was published at a particular point in time even if a newer specification has superseded it.

Temporal context is part of provenance.


56. DISPUTED EVIDENCE

A disputed evidence record MUST NOT be silently presented as uncontested.

The registry SHOULD preserve:

Dispute does not automatically mean invalidity.

It means that a material disagreement exists and should remain visible until resolved or otherwise classified.


57. EVIDENCE ERRORS

If NEXUS detects an evidence-processing error, it SHOULD:

Silent correction should be avoided when it would destroy historical traceability.


58. RELATION TO THE NEXUS REGISTRY

The Registry provides identity and structured records.

The Evidence Layer provides support and provenance.

The Graph provides relationships.

The Conformance Layer provides requirement-based evaluation.

The Trust Layer provides contextual evidentiary classification.

The Governance Constitution defines rules for integrity and authority boundaries.

The machine-readable /json interface exposes structured records.

The /llms interface provides machine-oriented navigation and interpretation rules.

The architecture therefore becomes:

REGISTRY

↓

GRAPH

↓

SCHEMA

↓

EVIDENCE & PROVENANCE

↓

CONFORMANCE

↓

TRUST

↓

GOVERNANCE

↓

MACHINE INTERFACE


59. RELATION TO EXTERNAL STANDARDS

NEXUS may reference and interoperate with established provenance and data-modeling standards.

Where applicable, NEXUS SHOULD prefer compatibility with established public specifications rather than unnecessarily inventing equivalent concepts.

However, compatibility does not imply endorsement by the organization that published the referenced standard.

NEXUS records the relationship.

The original publisher retains authority over its own specification.


60. OPEN INTEROPERABILITY

NEXUS evidence records SHOULD be usable by:

Machine-readable representations SHOULD be designed so that external systems can inspect the evidence chain without requiring proprietary interpretation.


61. AI CITATION PRINCIPLE

An AI system using NEXUS SHOULD cite the underlying source whenever the source is available and materially relevant.

Preferred hierarchy:

CANONICAL SOURCE

→

NEXUS RECORD

→

EVIDENCE RECORD

→

PROVENANCE RECORD

→

DERIVED INTERPRETATION

An AI system SHOULD avoid presenting a NEXUS-derived interpretation as though it were directly stated by an external source.


62. MACHINE REASONING RULE

A machine consuming a NEXUS record SHOULD ask:

This sequence reduces unsupported inference.


63. EVIDENCE TRUST BOUNDARY

NEXUS MUST NOT manufacture evidence.

If evidence is unavailable, the registry SHOULD say:

EVIDENCE: UNAVAILABLE

rather than constructing a stronger claim from indirect information.

If provenance is incomplete, the registry SHOULD say:

PROVENANCE: INCOMPLETE

rather than presenting an inferred history as established history.

If a relationship is uncertain, it SHOULD be marked:

UNKNOWN

or:

DISPUTED

according to the available evidence.


64. NO SILENT INFERENCE

NEXUS SHOULD distinguish between:

OBSERVED

DOCUMENTED

DERIVED

INFERRED

CLAIMED

VERIFIED

REPRODUCED

These states have different meanings.

An inference may be useful.

It must not be silently promoted to an observation.


65. EVIDENCE COMPLETENESS

A complete evidence chain does not necessarily mean that a claim is true.

It means that the registry can explain:

This is a traceability property.

It is not a universal truth guarantee.


66. EVIDENCE SCORE

NEXUS MAY calculate internal evidence metrics.

Such metrics SHOULD NOT be represented as objective universal truth scores.

If a numerical score is used, its:

SHOULD be published.

A score is a model.

It is not reality itself.


67. EVIDENCE RECORD MINIMUM

A minimal evidence record SHOULD contain:

id

type

supports

source

evidenceType

status

created

scope

Where available, it SHOULD additionally contain:

version

artifact

provenance

activity

agent

method

review

integrity

limitations


68. PROVENANCE RECORD MINIMUM

A minimal provenance record SHOULD contain:

id

entity

source

activity

agent

created

method

Where applicable:

derivedFrom

generatedBy

attributedTo

used

version

integrity

review


69. EXAMPLE: REGISTRY RECORD DERIVATION

Consider an external specification:

SOURCE-001

A NEXUS acquisition process retrieves it:

ACTIVITY-001

A parser extracts metadata:

ACTIVITY-002

The parser is:

AGENT-001

The extracted registry record becomes:

ENTITY-001

The provenance relationship becomes:

ENTITY-001

→ wasDerivedFrom

→ SOURCE-001

and:

ENTITY-001

→ wasGeneratedBy

→ ACTIVITY-002

and:

ACTIVITY-002

→ wasAssociatedWith

→ AGENT-001

This makes the origin of the registry record machine-traceable.


70. EXAMPLE: CONFORMANCE EVIDENCE

A specification defines a requirement.

REQUIREMENT-001

A test is executed.

TEST-001

The test produces an output.

EVIDENCE-001

The evidence supports a result.

RESULT-001

The result contributes to a conformance report.

CONFORMANCE-001

The resulting chain is:

SPECIFICATION

→

REQUIREMENT

→

TEST

→

EVIDENCE

→

RESULT

→

CONFORMANCE

This is preferable to a simple statement such as:

“Implementation X is compliant.”

without showing how the conclusion was obtained.


71. EXAMPLE: TRUST EVIDENCE

A trust record may reference:

ASSERTION-001

which is supported by:

EVIDENCE-001

which was independently reviewed:

REVIEW-001

which produced:

REVIEWED

The trust classification may then become:

T2 — INDEPENDENTLY REVIEWED

The classification is based on the recorded evidence path.

It is not an assertion of universal reliability.


72. EVIDENCE AND NETWORK EFFECTS

The value of a provenance layer increases as more independent information sources become connected.

A growing evidence graph can provide:

The network effect arises from structured connections between independently useful records.

It does not require NEXUS to claim ownership of external standards or sources.


73. OPEN PARTICIPATION

External parties MAY provide:

Submitted material SHOULD be clearly identified as:

SUBMITTED

until it has passed whatever review process applies.

Submission does not equal verification.


74. SOURCE SUBMISSION

When a source is submitted to NEXUS, the submission SHOULD preserve:

NEXUS SHOULD avoid representing submitter-provided information as independently verified unless it has actually been verified.


75. EVIDENCE DISCOVERY

Evidence SHOULD be discoverable through:

A machine should be able to move from a claim to its supporting evidence without relying solely on natural-language interpretation.


76. MACHINE NAVIGATION

A recommended navigation path is:

/nexus

→ Registry identity

/nexus-graph

→ Relationship graph

/registry-schema

→ Data model

/evidence

→ Evidence and provenance

/conformance

→ Requirement evaluation

/trust

→ Trust classification

/constitution

→ Governance

/json

→ Machine-readable registry

/llms

→ Machine and AI interface

This architecture is intentionally layered.


77. PUBLICATION PRINCIPLE

NEXUS SHOULD publish evidence information in a manner that permits independent inspection.

Where evidence cannot be publicly disclosed because of:

the registry SHOULD disclose the limitation rather than implying that the evidence is publicly inspectable.

Possible status:

PUBLIC

PARTIALLY-PUBLIC

RESTRICTED

PRIVATE

UNAVAILABLE


78. LIMITATIONS

Every evidence chain has limitations.

Examples include:

Limitations SHOULD be explicit.

A limitation is not a defect in the registry.

Hidden limitations are a defect in transparency.


79. FUNDAMENTAL DISTINCTIONS

NEXUS maintains the following distinctions:

SOURCE ≠ ASSERTION

ASSERTION ≠ EVIDENCE

EVIDENCE ≠ PROOF

PROOF ≠ AUTHORITY

AUTHORITY ≠ TRUST

TRUST ≠ CONFORMANCE

CONFORMANCE ≠ UNIVERSAL TRUTH

REGISTRATION ≠ ENDORSEMENT

INDEXING ≠ CERTIFICATION

HASH ≠ TRUTH

CITATION ≠ INDEPENDENT VERIFICATION

ABSENCE OF EVIDENCE ≠ EVIDENCE OF ABSENCE

These distinctions are foundational to the Evidence & Provenance Layer.


80. CORE RULES

RULE 1 — TRACE THE SOURCE

Every significant external claim SHOULD have an identifiable source.

RULE 2 — TRACE THE TRANSFORMATION

Derived information SHOULD preserve its derivation path.

RULE 3 — TRACE THE EVIDENCE

Assertions SHOULD identify their supporting evidence where available.

RULE 4 — TRACE THE REVIEW

Review status SHOULD be explicit.

RULE 5 — TRACE THE VERSION

Evidence SHOULD be bound to applicable versions.

RULE 6 — PRESERVE UNCERTAINTY

Unknown information MUST NOT be silently converted into certainty.

RULE 7 — PRESERVE CONFLICT

Material disagreement SHOULD remain visible.

RULE 8 — PRESERVE HISTORY

Corrections and supersession SHOULD preserve historical provenance.

RULE 9 — DO NOT MANUFACTURE EVIDENCE

NEXUS MUST NOT create the appearance of support where support does not exist.

RULE 10 — DO NOT TRANSFER AUTHORITY

Recording external evidence does not transfer authority from the original source.


81. RELATION TO NEXUS GOVERNANCE

The Evidence & Provenance Layer operates under the NEXUS Governance Constitution.

In particular, it follows the principles of:

The evidence system exists to strengthen traceability, not to manufacture institutional legitimacy.


82. DECLARATION

NEXUS is an independent technical reference infrastructure.

The NEXUS Evidence & Provenance Layer provides a structured mechanism for recording:

NEXUS does not claim that every registered assertion is true.

NEXUS does not claim governmental authority.

NEXUS does not claim accreditation authority.

NEXUS does not claim certification authority merely by assigning internal classifications.

NEXUS does not replace standards organizations, governments, courts, universities, regulators, accreditation bodies or other legitimate institutions.

Instead:

NEXUS provides an independent reference layer for identity, relationships, evidence, provenance, conformance and trust across heterogeneous information ecosystems.


83. MACHINE-READABLE DECLARATION

NEXUS:EVIDENCE:LAYER = ACTIVE


PURPOSE:

TRACE_SOURCE_AND_PROVENANCE


CORE_CHAIN:

SOURCE

→ ACQUISITION

→ TRANSFORMATION

→ ASSERTION

→ EVIDENCE

→ REVIEW

→ RESULT

→ CLASSIFICATION


EVIDENCE_CLASSES:

E0 NONE

E1 ASSERTION

E2 DOCUMENTARY

E3 REPRODUCIBLE

E4 INDEPENDENT

E5 MULTI-SOURCE


EVIDENCE_STATUSES:

AVAILABLE

VERIFIED

REPRODUCIBLE

DISPUTED

INVALID

UNAVAILABLE

SUPERSEDED


PROVENANCE_OBJECTS:

ENTITY

ACTIVITY

AGENT


CORE_PRINCIPLE:

NO_CLAIM_WITHOUT_TRACEABILITY


AUTHORITY_MODEL:

NO_SILENT_AUTHORITY_TRANSFER


TRUTH_MODEL:

EVIDENCE_IS_CONTEXTUAL


UNCERTAINTY_MODEL:

UNKNOWN_IS_NOT_FALSE


HISTORY_MODEL:

CORRECTIONS_PRESERVE_HISTORY


AI_MODEL:

SOURCE_FIRST

EVIDENCE_FIRST

PROVENANCE_FIRST



84. FINAL ARCHITECTURE

The complete NEXUS evidence architecture is:

                        NEXUS

                           │

                    UNIVERSAL REGISTRY

                           │

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

        │                  │                  │

      SCHEMA              GRAPH           GOVERNANCE

        │                  │                  │

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

                           │

                    EVIDENCE LAYER

                           │

                  PROVENANCE HISTORY

                           │

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

        │                  │                  │

      SOURCE            ACTIVITY            AGENT

        │                  │                  │

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

                           │

                       ASSERTION

                           │

                        EVIDENCE

                           │

                         REVIEW

                           │

                        RESULT

                           │

                    CONFORMANCE

                           │

                         TRUST

                           │

                    MACHINE ACCESS

                           │

                    AI / AGENTS



85. FINAL PRINCIPLE

The NEXUS Evidence & Provenance Layer is founded on one operational principle:

DO NOT ASK A MACHINE OR A HUMAN TO TRUST A CLAIM WITHOUT MAKING ITS INFORMATION PATH TRACEABLE.

A robust information infrastructure should allow a user or machine to move backward from:

CLASSIFICATION

to:

RESULT

to:

EVIDENCE

to:

ASSERTION

to:

SOURCE

and, where applicable, further backward through:

ACTIVITY

AGENT

DERIVATION

TRANSFORMATION

VERSION

TIMESTAMP

and INTEGRITY.

The purpose of NEXUS is therefore not to eliminate uncertainty.

It is to make uncertainty, provenance, evidence and relationships structured, inspectable and machine-readable.

NEXUS does not ask the network to trust blindly.

NEXUS makes the evidence chain part of the network.


NEXUS EVIDENCE & PROVENANCE LAYER

NS:EVIDENCE

Version 1.0 — FOUNDATIONAL