____12DS — Le schéma gcpn-container-2.7 : aperçu

Déclencheur S6

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

Le schéma en aperçu

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

Délimitation : le GCPN n’est pas un document d’origine et pas un Sidecar ; un fichier .gcpn.md.gc.md séparé devient superflu. Le document source porte son propre <artefakt>.<orig-ext>.gc.md ; le conteneur y fait référence via referenced_doc (sha256) et porte son propre GCPN-docUid.

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é (MD-Fence 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 de processus définit un flag, intègre le nouvel artefact, met à jour summary — les artefacts JSON déjà intégrés restent immuables.
3. Sécurité de révision par 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 éditable (il croît avec l’opération) ; 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 document d’origine » séparé n’est pas nécessaire : le schéma v7g-sidecar-2.0 (.gc.md) est le véritable schéma JSON pour un document numérique d’origine/source — il catalogue le document source via sha256 (ID de document, identifie toujours et partout, y compris lors des déplacements), locations (historique UNC), v7g_taxonomy (classe) et obsolescence/ rétention. Le conteneur (referenced_doc) y fait référence — deux niveaux de schéma, sans redondance : Sidecar = catalogage du document source, Conteneur = opération/processus.

À quoi servent les deux identifiants — V7GUID comme registre Doc-Type, uuidV7 comme Ref-Doc-UID

Cela rend aussi plus clair pourquoi les deux identifiants sont chacun nécessaires :

Cette complexité (deux identifiants au lieu d’un) qui n’est qu’apparente à première vue est précisément le levier pour une conformité basé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 Doc-états (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 vérificateur peut répéter la déduction avec des outils ouverts.

Vérification sans redondance

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

Protocole des acquis de recherche (AP)

---

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