This guide explains how evidence accompanies a Chronoscript record without turning the canonical Registry into a document repository.

1. Prepare the record and identify which files are primary or supporting evidence.
2. Attach one or multiple files while the record remains DRAFT.
3. LXKeys calculates a SHA-256 digest and exact byte size for every object.
4. Review disclosure and the intended preservation/storage class before submission. Storage class remains operational preservation state; it is not hashed into the canonical Evidence Manifest.
5. Submission locks the Evidence Set. Changes require an explicit return to DRAFT.
6. Finalization fixes the Evidence Manifest and its manifest digest inside the canonical record.
7. The original file bytes remain in protected Evidence Storage and may be viewed or downloaded only according to access policy.
8. Integrity verification recalculates stored-object digests and compares them with the canonical manifest.

Example — a book

A publication record for a book may identify the final PDF as primary evidence and a cover image or publication metadata as supporting evidence. The Registry does not contain the PDF bytes. It contains the exact identity of the evidence set. Anyone later presenting a file can calculate its digest and determine whether it is byte-for-byte identical to the evidence registered for that record.

Preservation policy

Long-term availability depends on preserving file bytes as well as the Registry metadata. LXKeys therefore treats Registry preservation and Evidence preservation as distinct responsibilities. Storage replication, immutable backup or archival storage, restoration testing and provider migration can evolve without changing finalized Registry Records.


Current ingestion boundary

LXKeys Platform 1.0.0 keeps an application-level evidence upload size limit configurable through MAX_EVIDENCE_BYTES. Authorized viewing uses byte-range streaming and integrity re-verification uses streamed hashing. Very large-object production ingestion should use a dedicated streaming or direct-to-object-storage path rather than increasing the in-memory multipart limit without an infrastructure review.


Atomic multifile attachment

When several files are attached in one LXKeys Platform operation, Evidence Set metadata insertion is transactional: all objects are recorded together or none are. Files already written are cleaned up if the metadata transaction fails. This property applies to the application attachment operation and is not a claim of distributed transactionality across future external storage providers.