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, aucun droit d'accès au dépôt sur l'historique, seulement 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.v7g.md  (Sidecar Quell-Dokument)
260913_signature-doc.json                                  (Signatur-Doc, DS02)
260913_signature-doc.json.v7g.md                           (Sidecar Signatur-Doc)
260913_event-accepted.json                                 (Event 1, DS03)
260913_event-signed.json                                   (Event 2, DS03)
260913_event-signed.json.v7g.md                            (Sidecar Events)
E1.Signature.transparent.FES.svg                         ([Facsimile](../../glossar.html#facsimile "Facsimile-Unterschrift — Glossar")-Grafik)
E1.Signature.transparent.FES.svg.v7g.md                  (Sidecar Grafik)

La routine de vérification

Étape 1 : Intégrité du document source

sha256sum 260825_GVB_*.md
# → muss mit .sha256 im Sidecar 260825_*.md.v7g.md übereinstimmen
jq -r '.sha256' 260825_*.md.v7g.md

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

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

jq -r '.target.sha256' 260913_signature-doc.json
# → muss mit der Quell-Dokument-SHA (Schritt 1) übereinstimmen

Le doc de signature est rattaché à une version concrète — et non « au document, 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
# Kette prüfen: prev von ev2 == sha256(ev1)?

Étape 4 : Graphique Facsimile

sha256sum E1.Signature.transparent.FES.svg
# → muss mit evidence.facsimile_ref.sha256 im Signatur-Doc und im Event übereinstimmen
# → muss mit der Tabelle in PARTNER-ORG-repo/top/signature-block.md übereinstimmen

Le hash SHA-256 EST la preuve de l'originalité — pas le tampon GUID. Le SHA-256 identifie le graphique toujours et partout : les documents sources (et les graphiques) peuvent se déplacer (fichier déplacé, copié, enregistré sous un autre nom) — l'identification demeure grâce au code SHA-256, car il est calculé à partir du contenu et est indépendant du chemin et du nom. Le tampon GUID (01a09b48-4580-76f9-b789-024691b989c5) n'est en revanche qu'un attribut ajouté : reproductible de manière déterministe à partir de ts+sha (gc-v7guid gen-doc) et utile comme référence documentée — mais l'originalité et l'identification reposent uniquement sur le SHA-256 (et la chaîne SHA-256 des artefacts), pas sur le tampon GUID.

Étape 5 : Catalogisation des sidecars

jq -r '.v7g_taxonomy[].taxonomy' *.v7g.md | sort | uniq
# → Klassen der beteiligten Artefakte (SIGNATURE_DOC, SIGNATURE_EVENT, SIGNATURE_GRAPHIC)
jq -r '.obsolescence.status' *.v7g.md
# → alle "active"? Abweichung = Artefakt ist obsolete/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 l'historique Git ?

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

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

Anomalies et leur signification

Constat	Signification	Conséquence
SHA-256 du document source ≠ sidecar	Document source modifié a posteriori	La chaîne se rompt ; document source invalide pour cette signature
Le doc de signature renvoie à un SHA de document source erroné	Signature apposée sur une mauvaise version	Doc de signature invalide (nouvelle version → nouveau doc de signature)
Chaîne d'événements lacunaire (prev manquant/incohérent)	Dossier incomplet	Valeur probante réduite ; la preuve de l'état intermédiaire manque
SHA du graphique ≠ tableau dans SIGNATURE_BLOCK.md	Graphique erroné/manipulé	Facsimile invalide — niveau de signature affecté
Sidecar `obsolescence.status ≠ active`	L'artefact est obsolete/superseded	Le vérificateur examine l'artefact successeur (`superseded_by`)

Résumé

La routine de vérification est indépendante de l'historique (sha256sum + jq suffisent) et pérenne (JSON, SHA-256, V7GUID — aucune dépendance à un outil).
Chaque écart d'un 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 si les documents sources/graphiques se déplacent (indépendamment du chemin et du nom) ; le tampon guid n'est qu'un attribut de référence documenté 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