Purpose

The LXKeys Evidence Model separates canonical evidence identity from file storage. A Chronoscript Registry Record may reference zero, one or multiple Evidence Objects. Evidence file bytes are not embedded into the canonical Registry. Instead, the Registry preserves a deterministic Evidence Manifest that identifies the evidence set attached to the record at finalization.

Canonical Evidence Manifest

At finalization, LXKeys records an Evidence Manifest containing, for every Evidence Object: Evidence ID, role, logical label, original filename, media type, exact byte size, SHA-256 digest and disclosure class. The manifest also contains the number of objects and aggregate byte size. A SHA-256 digest of the deterministic manifest representation is stored with the Registry Record.

Evidence Object roles

primary — evidence that directly substantiates the event or object being registered.
supporting — complementary material that supports interpretation, provenance or verification.

Storage separation

The canonical Registry stores evidence identity and integrity metadata. Evidence bytes are retained in a protected Evidence Storage layer outside the public web root. Physical storage provider, logical storage key, storage class and integrity-verification status are operational state and are deliberately excluded from the canonical Evidence Manifest. They may evolve during preservation or provider migration without rewriting the finalized Registry Record, provided the retained object continues to match the digest fixed in the manifest.

Disclosure

Evidence disclosure is independent from Registry Record disclosure. An otherwise public Registry Record may reference restricted or private evidence. Public interfaces must not expose protected filenames, file locations or content unless the applicable disclosure policy permits access.

Integrity verification

LXKeys may periodically recalculate the digest of retained Evidence Objects using streamed reads so verification does not require loading an entire large object into application memory. Verification compares the observed object digest with the digest fixed in the canonical Evidence Manifest. A storage mismatch is an integrity incident; it does not rewrite the Registry Record.

Large files and long documents

Evidence delivery supports byte-range access where applicable so that compatible viewers can retrieve only the portions required for viewing. Derived representations such as text extraction, thumbnails, page indexes or search indexes may be generated for usability. Derived representations never replace the original Evidence Object or its canonical digest.

Portability

Evidence packages may be exported using common container formats for transport, but no archive container is the canonical definition of an Evidence Set. The manifest remains independently readable and specifies each constituent object separately.


Canonicalization and record binding

The canonical Evidence Manifest is bound to the finalized Record ID and Registry Sequence, never to an internal database UID. Version 1.0.0 uses LXKeys-Evidence-Canonical-JSON-1: schema object keys are ASCII identifiers and are serialized in ascending lexical order, arrays retain their defined order, strings use JSON escaping, non-negative integer values use base-10 without leading zeros, UTF-8 is used, and no insignificant whitespace is emitted. Evidence Objects are ordered by Evidence ID before canonical serialization. This rule is part of the interoperability contract and allows independent implementations to reproduce the same manifest digest. Historical records finalized before this model do not receive a fabricated manifest retroactively.

Public disclosure terminology

Public — the evidence object may be enumerated on the public Registry record and, where technically supported, previewed and downloaded.
Restricted — the evidence object remains preserved and may be represented in the canonical Evidence Manifest, but its file and descriptive details are not exposed through the public record.
Confidential — the evidence object remains outside public disclosure. Historical protocol/runtime storage may represent this level with the value `private`; this compatibility value does not authorize public enumeration.

The number displayed as public evidence on a Registry page counts only objects actually exposed as public. It must not reveal the count, filenames or descriptive metadata of restricted or confidential objects.