Ce guide explique comment une preuve accompagne un enregistrement Chronoscript sans transformer le Registre canonique en dépôt documentaire.

1. Préparer l’enregistrement et identifier les fichiers qui constituent les preuves primary ou supporting.
2. Joindre un ou plusieurs fichiers tant que l’enregistrement reste en DRAFT.
3. LXKeys calcule une empreinte SHA-256 et la taille exacte de chaque objet.
4. Vérifier la divulgation et la classe de conservation/stockage prévue avant soumission. La classe de stockage reste un état opérationnel de conservation ; elle n’est pas intégrée à l’empreinte de l’Evidence Manifest canonique.
5. La soumission verrouille l’Evidence Set. Toute modification exige un retour explicite en DRAFT.
6. La finalisation fixe l’Evidence Manifest et son empreinte dans l’enregistrement canonique.
7. Les octets des fichiers originaux restent dans l’Evidence Storage protégé et ne peuvent être consultés ou téléchargés que selon la politique d’accès.
8. La vérification d’intégrité recalcule les empreintes des objets stockés et les compare au manifeste canonique.

Exemple — un livre

Un enregistrement de publication d’un livre peut désigner le PDF final comme preuve primary et une couverture ou des métadonnées de publication comme preuves supporting. Le Registre ne contient pas les octets du PDF. Il contient l’identité exacte de l’ensemble de preuves. Toute personne présentant ultérieurement un fichier peut calculer son empreinte et déterminer s’il est identique octet pour octet à la preuve enregistrée pour ce record.

Politique de conservation

La disponibilité à long terme dépend de la conservation des octets des fichiers ainsi que des métadonnées du Registre. LXKeys traite donc la préservation du Registry et celle des Evidence Objects comme deux responsabilités distinctes. La réplication, les sauvegardes immuables ou archivales, les tests de restauration et les migrations de fournisseur peuvent évoluer sans modifier les Registry Records finalisés.


Limite actuelle d’ingestion

LXKeys Platform 1.0.0 conserve une limite applicative de téléversement des preuves configurable par MAX_EVIDENCE_BYTES. La consultation autorisée utilise les plages d’octets et la revérification d’intégrité calcule l’empreinte en flux. Pour des objets de production très volumineux, l’ingestion devra utiliser un chemin dédié en streaming ou un envoi direct vers un stockage objet, plutôt que d’augmenter la limite multipart en mémoire sans revue d’infrastructure.


Atomic multifile attachment

Lorsqu’un utilisateur joint plusieurs fichiers dans une même opération LXKeys Platform, l’ajout des métadonnées de l’Evidence Set est transactionnel : tous les objets sont enregistrés ensemble ou aucun ne l’est. Les fichiers déjà écrits sont nettoyés si la transaction de métadonnées échoue. Cette propriété concerne l’opération d’ajout, pas une garantie de transaction distribuée entre futurs fournisseurs de stockage externes.