DS04 — Catalogisation des sidecars et chaîne de vérification

Déclencheur S2, suite

Le vérificateur est assis devant l'écran — pas de client Git, pas de droits d'accès au dépôt sur l'historique, uniquement le répertoire de travail du dépôt du tenant (ou un export de celui-ci). Il veut vérifier : Le document est-il authentique, qui l'a signé, la chaîne est-elle intacte ?

L'ensemble de vérification

Dans le répertoire du dossier se trouvent :

260825-shareholder-meeting-resolution.md         (Quell-Dokument)
260825-shareholder-meeting-resolution.md.gc.md  (Sidecar Quell-Dokument)
260913_signature-doc.json                                  (Signatur-Doc, DS02)
260913_signature-doc.json.gc.md                           (Sidecar Signatur-Doc)
260913_event-accepted.json                                 (Event 1, DS03)
260913_event-signed.json                                   (Event 2, DS03)
260913_event-signed.json.gc.md                            (Sidecar Events)
E1.Signature.transparent.FES.svg                         ([Facsimile](../../glossar.html#facsimile "Facsimile-Unterschrift — Glossar")-Grafik)
E1.Signature.transparent.FES.svg.gc.md                  (Sidecar Grafik)

La routine de vérification

Étape 1 : Intégrité du document source

sha256sum 260825_GVB_*.md
# → doit correspondre au .sha256 dans le sidecar 260825_*.md.gc.md
jq -r '.sha256' 260825_*.md.gc.md

Divergence = le document source a été modifié après la création du sidecar → la chaîne se rompt.

Étape 2 : Référence du document de signature

jq -r '.target.sha256' 260913_signature-doc.json
# → doit correspondre au SHA du document source (étape 1)

Le document de signature est attaché à une version concrète — pas au « document en question d'une manière ou d'une autre ».

Étape 3 : Chaîne d'événements

for f in 260913_event-*.json; do
  jq -r '"\(.event) | \(.uuidV7) | prev=\(.prev_event_sha256)"' "$f"
done
# Vérifier la chaîne : prev de ev2 == sha256(ev1) ?

Étape 4 : Graphique du fac-similé

sha256sum E1.Signature.transparent.FES.svg
# → doit correspondre à evidence.facsimile_ref.sha256 dans le document de signature et dans l'événement
# → doit correspondre au tableau dans PARTNER-ORG-repo/top/signature-block.md

Le hachage SHA-256 EST la preuve de l'originalité — pas le cachet GUID. Le SHA-256 identifie le graphique toujours et partout : les documents sources (et les graphiques) peuvent migrer (fichier déplacé, copié, déposé sous un autre nom) — l'identification subsiste via le code SHA-256, car il est calculé à partir du contenu et est indépendant du chemin et du nom. Le cachet GUID (01a09b48-4580-76f9-b789-024691b989c5) n'est en revanche qu'une caractéristique adjointe : reproductible de manière déterministe à partir de ts+sha (gc-v7guid gen-doc) et utile comme référence documentée — mais seuls le SHA-256 (et la chaîne SHA-256 des artefacts) portent l'originalité et l'identification, pas le cachet GUID.

Étape 5 : Catalogisation des sidecars

jq -r '.v7g_taxonomy[].taxonomy' *.gc.md | sort | uniq
# → classes des artefacts impliqués (SIGNATURE_DOC, SIGNATURE_EVENT, SIGNATURE_GRAPHIC)
jq -r '.obsolescence.status' *.gc.md
# → tous "active" ? Divergence = artefact obsolète/superseded

La chaîne de vérification sous forme de diagramme

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TB A["Quell-Dokument (MD)
sha256 T"] --> B["Sidecar Quell-Dokument
sha256(T)"] A --> C["Signatur-Doc
target.sha256 = T"] C --> D["Sidecar
sha256(C)"] C --> E["Event offered
prev=null"] E --> F["Event accepted
prev=sha(E)"] F --> G["Event signed
prev=sha(F)"] G --> H["Facsimile-Grafik
sha256 + guid-Stempel"] D -.-> I["Prüfer: sha256sum + jq
alle Referenzen prüfen"] B -.-> I H -.-> I style I fill:#e8eef7,stroke:#2c5282

Pourquoi sans historique Git ?

Trois raisons pour la vérification indépendante de l'historique :

Scénarios d'export — le vérificateur reçoit une copie du répertoire (ZIP, paquet de conteneur, DS10), pas le dépôt. L'historique n'y serait pas inclus.
Traçabilité GoBD — la chaîne de preuve doit subsister même si l'outil n'est plus courant dans 10 ans. SHA-256, JSON et Markdown sont durables dans le temps.
Indépendance des niveaux de preuve — l'historique Git est une preuve supplémentaire, pas la seule. La chaîne (sidecars + événements + graphique) se porte elle-même.

Cas d'erreur et leur signification

Constat	Signification	Conséquence
SHA-256 du document source ≠ sidecar	Document source modifié ultérieurement	La chaîne se rompt ; document source invalide pour cette signature
Le document de signature renvoie à un SHA de document source erroné	Signature sur une mauvaise version	Document de signature invalide (nouvelle version → nouveau document de signature)
Chaîne d'événements lacunaire (prev manquant/incohérent)	Opération incomplète	Valeur probante réduite ; preuve de l'état intermédiaire manquante
SHA du graphique ≠ tableau dans SIGNATURE_BLOCK.md	Graphique erroné/manipulé	Fac-similé invalide — niveau de signature concerné
Sidecar `obsolescence.status ≠ active`	Artefact obsolète/superseded	Le vérificateur contrôle l'artefact successeur (`superseded_by`)

Résumé

La routine de vérification est indépendante de l'historique (sha256sum + jq suffisent) et durable dans le temps (JSON, SHA-256, V7GUID — aucune dépendance à un outil).
Chaque divergence de maillon de la chaîne a une signification et une conséquence définies.
Le SHA-256 est la preuve de l'originalité et de l'identification — toujours et partout, même lorsque les documents sources/ graphiques migrent (indépendant du chemin et du nom) ; le cachet guid n'est qu'une caractéristique de référence documentée et reproductible de manière déterministe.
Article suivant (DS05) : le conteneur de signature GCPN regroupe tous les artefacts.

Créé : 260913 | Partie I, article DS04 | Série : digital-signage