Format du dossier de preuve

La structure physique, le cycle de vie et le scellement d'un dossier Evidence quotidien.

Le dossier de preuve décrit ce qui est documenté. Cette page décrit comment c'est structuré : le format physique défini par RS-RVP-04, destiné aux intégrateurs et aux vérificateurs indépendants.

Un dossier par contexte, par journée civile

RestorSignal produit au maximum un dossier Evidence scellé par contexte et par journée civile, consolidant tous les runs reçus pendant cette période :

storage/evidence/<tenant_id>/<evidence_id>/
├── manifest.json          (period_type, context_id, period_start/period_end, state, bundle)
├── context/                (scope — commun aux runs de la période)
├── execution/
│   ├── runs/<run_id>.json   (un fichier par run contributeur : son propre artefact/environnement/requête)
│   ├── controls.json         (tous les contrôles de tous les runs, chacun rattaché à son run source)
│   ├── errors.json
│   ├── events.ndjson
│   └── result.json           (synthèse de la période : run_count, consolidated_status)
├── references/               (référentiel, composants logiciels)
├── integrity/                 (hashes, hash racine, scellement)
└── reports/                    (rendus FR/EN)

manifest.json est l'index du dossier : period_type/period_start/period_end/context_id identifient la période couverte, et bundle porte l'enveloppe de validation de la période (ventilation par niveau, plus haut niveau démontré, statut consolidé) — distincte de l'objet EvidenceBundle mono-run défini par RS-RVP-02/RS-RVP-03, puisqu'un dossier quotidien n'a pas de run/artefact unique à décrire.

Cycle de vie

CREATED → RUNS_RECORDED → EVALUATED → SEALED

Le dossier n'est créé et ses runs enregistrés qu'une fois la période close — jamais de façon spéculative à chaque run reçu pendant la journée. Après SEALED, le dossier porte un état de validité distinct (VALID/INVALID). Un dossier SEALED n'est jamais réécrit : un run arrivant après le scellement est enregistré pour lui-même mais n'intègre jamais un dossier déjà scellé.

Résultat consolidé

Le consolidated_status de la période n'est jamais simplement le résultat du dernier run. Il suit un ordre de sévérité fixe sur l'ensemble des runs de la période :

FAIL > ERROR (NOT_TESTED / INCONCLUSIVE) > NOT_APPLICABLE > PASS

Le statut le plus défavorable observé pendant la période constitue le résultat consolidé du dossier, même si la majorité des runs de cette période sont en PASS — voir Statuts des résultats et Statuts des contrôles pour le vocabulaire sous-jacent.

Scellement

Avant SEALED : chaque fichier du dossier (hors integrity/ et manifest.json lui-même) est haché en SHA-256 (integrity/hashes.json), puis la liste triée <hash> <chemin> est elle-même hachée pour produire un hash racine déterministe (integrity/seal.json). Un vérificateur indépendant recalcule ces deux étapes pour confirmer qu'aucun fichier n'a été modifié depuis le scellement.

Conservation et vérification publique

Le retention_until d'un dossier scellé est figé au moment du scellement et ne change jamais rétroactivement. La conservation ne dépend pas du fait que l'abonnement sous-jacent reste actif : un dossier scellé et son lien de vérification publique restent disponibles jusqu'à retention_until, indépendamment du statut du compte. Voir la documentation du portail Verify pour le parcours de vérification publique.

Aller plus loin

Les règles complètes d'agrégation quotidienne — bornes de période, gestion des runs tardifs, conservation — sont définies par RS-RVP-04. Le concept mono-run d'Evidence Bundle sur lequel il s'appuie (le résultat technique scellé d'un seul run, distinct du produit quotidien décrit sur cette page) reste défini par RS-RVP-03.