DS02 — Le doc de signature comme type de données (JSON-Schema)

Déclencheur S1, suite

E1 a adopté une résolution (GVB) en Markdown. Il lui faut maintenant un artefact qui rende reconnaissable : Moi, E1, signe ce document à la date X dans mon rôle de Y. L'artefact doit être lisible par machine, validé par schéma et à l'épreuve des révisions — un artefact JSON selon la règle 1 du GCBoK ("JSON-First") et la règle 4 ("Schema-First").

Le type de données `signature-1.0`

Le JSON-Schema définit une signature comme document autonome dans le repo — pas comme pièce jointe, pas comme texte de mail. Structure de base (simplifiée) :

{
  "$schema": "https://gitcover.org/schemas/signature-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7 aus ts+doc-sha256>",
  "type": "signature",
  "subject": {
    "name": "Erich Mustermann",
    "role": "Geschäftsführer",
    "capacity": "handelnd unter Befreiung von § 181 BGB",
    "entity": "PARTNER-ORG"
  },
  "target": {
    "kind": "gvb",
    "title": "GVB 260825 — GF-Vertrag: Selbständigkeit",
    "sha256": "<sha256 des Quell-Dokuments>",
    "location": "\\\\vm1\\data\\org1\\repo-top\\res\\260825-shareholder-meeting-resolution.md"
  },
  "procedure": {
    "form": "textform",
    "statute": "§ 126b BGB",
    "legal_basis_ref": "GVB 260825, TOP 'Beschlussfassung in Textform'",
    "expression": "Abgabe der Erklärung in elektronischer Form (§ 371a ZPO)"
  },
  "evidence": {
    "facsimile_ref": {
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "guid_stamp": "01a09b48-4580-76f9-b789-024691b989c5"
    },
    "timestamp_utc": "2026-09-13T15:00:00Z",
    "timestamp_source": "uuidV7-RFC9562"
  }
}

Les champs obligatoires en détail

Groupe de champs	Obligatoire	Objectif
`uuidV7`	oui	ID déterministe à partir de la marque temporelle + doc-sha256 (gen-doc) — tampon GUID pour "accepted"/"signed"
`subject`	oui	Signataire : nom, rôle, pouvoir de représentation, personne morale
`target`	oui	Document source : titre, SHA-256, chemin UNC — la signature se rattache à une version concrète
`procedure`	oui	Procédure : textform/FES, norme juridique, indication de forme (§ 371a ZPO)
`evidence`	oui	Référence Facsimile (SHA-256 + tampon GUID du graphique de signature), horodatage
`signing_key_ref`	optionnel	Uniquement en partie III (cercle PII/GPG) — référence de clé, pas dans les parties I/II

Règle Schema-First : avant chaque saisie, vérifier si un schéma existe ; s'il manque, il est créé. Le doc de signature suit le même modèle que diary-entry, v7g-sidecar et les conteneurs GCPN.

Catalogisation V7GUID

Le doc de signature reçoit sa propre V7GUID-Class-Taxonomy dans le sidecar (similaire à SIGNATURE_GRAPHIC pour les assets graphiques) :

Class	Usage
`SIGNATURE_DOC`	Le doc de signature lui-même (artefact JSON)
`SIGNATURE_GRAPHIC`	Le graphique Facsimile (PNG/SVG) — déjà enregistré le 260913
`SIGNATURE_EVENT`	L'opération de signature (Accept/Deny/Sign) — DS03

Chaque classe est un candidat à la promotion pour l'OSS-Normative-Root (work/OSS/TOP/.gitcover/dictionaries/classes.json), sur le modèle du pilote 260821 (HR_REGISTER_DOC, RECEIPT_DOC etc.).

Pourquoi la signature est un document à part entière

Trois décisions de conception qui font avancer la saga :

Séparation du contenu et de la déclaration de volonté — le document source reste inchangé (Immutable-Doc) ; la signature est un artefact séparé, qui se rattache par SHA-256 à la version concrète. Une coquille dans le document source n'invalide pas la couche de signature ; une nouvelle version génère une nouvelle signature.
Signature multiple — plusieurs signataires produisent plusieurs docs de signature sur le même document source (p. ex. un GVB avec deux lignes de signature). La vérification contrôle tous les docs de signature par rapport au même SHA du document source.
Raccordabilité FES — la signature FES (partie II) ne remplace pas le doc de signature, mais le complète : le doc de signature reste la couche repo, le doc FES (Envelope-Report, PDF) est référencé comme artefact supplémentaire.

Référence Facsimile (pas d'intégration)

Important pour la qualité de la saga : le doc de signature n'intègre pas physiquement le graphique de signature. Il renvoie à celle-ci — via SHA-256 et tampon GUID (E1.Signature.transparent.FES.svg, sha256 8fcffe0b…, guid 01a09b48-4580-76f9-b789-024691b989c5). Cela rend la chaîne légère : graphique, document source et doc de signature sont vérifiables indépendamment ; la valeur probante réside dans la vérification, et non dans l'intégration.

L'intégration physique (Facsimile dans la couche PDF, de type DocuSign) relève de la partie II — là où la signature FES produit son propre doc PDF.

Résumé

Le doc de signature est un artefact JSON (schéma signature-1.0) avec les champs obligatoires subject, target, procedure, evidence.
Il se rattache par SHA-256 à une version concrète du document source.
Le graphique Facsimile est référencé (SHA-256 + tampon GUID), et non intégré — l'intégration relève de la FES (partie II).
Prochain article (DS03) : l'opération de signature en tant qu'événement.

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