____12DS — Le schéma gcpn-container-1.0 : Vue d'ensemble

Déclencheur S6

Le premier véritable processus de signature (signature GVB) a d'abord généré des fichiers .json autonomes dans le répertoire res/ — une méthode de travail qui fait gonfler le dépôt Git (constat AP : « cela gonfle inutilement le dépôt Git »). Ce constat a conduit à la correction : tous les artefacts JSON dans UN doc conteneur (.gcpn.md, extension pérenne), et le conteneur lui-même devient le schéma JSON normatif — gcpn-container-1.0.

Le schéma en un coup d'œil

{
  "$schema": "https://gitcover.org/schemas/gcpn-container-1.0.schema.json",
  "container_id": "GCPN-SIG-YYMMDD-NNN",
  "uuidV7": "<deterministisch aus ts + doc-sha256>",
  "kind": "signature-process",
  "tenant": { … },
  "referenced_doc": { … },
  "actor": { … },
  "attendees": [ … ],
  "persons": { … },
  "retention": { … },
  "signature": { … },
  "events": { … },
  "summary": { … },
  "prev_container": null,
  "next_container": null,
  "sidecar": "<Referenced-Doc>.gcpn.md.v7g.md"
}

Unicité des artefacts (constat AP1)

Chaque entité est décrite exactement une fois :

Les règles qui découlent du constat

1. JSON toujours intégré (fence MD dans le conteneur) — aucun fichier .json autonome dans l'arborescence du dépôt (éviter le gonflement).
2. Compléter plutôt que recréer : chaque nouvelle étape du processus pose un flag, intègre le nouvel artefact, met à jour summary — les artefacts JSON déjà intégrés restent immuables.
3. Sécurité des révisions grâce à Git : l'historique du conteneur se trouve dans l'historique Git du dépôt (hash de commit = preuve d'intégrité).
4. Doc mutable, artefacts JSON immuables : le MD du conteneur est modifiable (il grandit avec le dossier) ; les contenus JSON sont inaltérables — toute modification = nouvel artefact avec un nouveau SHA.
5. Commits uniquement par E1 (NO-AUTO-COMMIT).

Le document source est catalogué via le schéma sidecar

Un « schéma de doc original » séparé n'est pas nécessaire : le schéma v7g-sidecar-1.0 (.v7g.md) est le véritable schéma JSON pour un document original/source numérique — il catalogue le doc source via sha256 (identifiant de document, qui l'identifie toujours et partout, même lors de ses déplacements), locations (historique UNC), v7g_taxonomy (classe) et obsolescence/rétention. Le conteneur (referenced_doc) y renvoie — deux niveaux de schéma, aucune redondance : sidecar = catalogage du doc source, conteneur = dossier/processus.

À quoi servent les deux identifiants — V7GUID comme registre de types de documents, uuidV7 comme UID du doc de référence

Cela permet aussi de voir plus clairement à quoi servent respectivement les deux identifiants :

Cette complexité (deux identifiants au lieu d'un) apparente au premier regard est précisément le levier d'une conformité fondée sur le dépôt Git sans Vendor Lock-In : tout peut être déduit des dépôts (déterminé de manière déterministe) — non seulement les états des documents (chaîne SHA-256, expression des flags), mais aussi l'historique et les modifications (historique Git du conteneur : quelles étapes ont été ajoutées et quand ; historique du sidecar : actes de classification avec horodatages). Aucun système propriétaire ne stocke l'état — le dépôt lui-même est l'état, et tout auditeur peut reproduire la dérivation avec des outils ouverts.

Vérification sans redondance

La routine de vérification (DS04) reste en place — elle travaille avec le manifeste dans le conteneur : sha256sum par artefact confronté à events.flags_set[].sha256 ou referenced_doc.sha256 ; chaîne via chain_valid ; SHA du fac-similé confronté au tableau dans SIGNATURE_BLOCK.md.

Protocole des acquis de la recherche (AP)

---

Créé : 260913 | Partie III, article ____12DS | Série : digital-signage