Axe 2 : Concepts

V7GUID - GUID de version 7

V7GUID (aussi : Categorized UUIDv7 Identifier) est un schéma de catégorisation pour les identifiants dans les artefacts GitCover, fondé sur un UUID version 7 compatible avec la RFC 4122 (basé sur le temps, triable), étendu par une classification de classes spécifique à GitCover.

Structure

Objet : liaison déterministe et triable de justificatifs dans une chaîne de justificatifs. Permet une reconstructibilité temporelle/versionnée (GoBD : conformité temporelle) sans base de données de séquence centrale.

Base temporelle : GMT/UTC (règle normative)

Les horodatages de 48 bits de tous les V7GUID et uuidV7 doivent toujours être générés et interprétés sur la base GMT/UTC (offset 0) — jamais sur la base d'un fuseau horaire local (MESZ, MEZ, etc.) :

Justification :

• Neutre vis-à-vis du fuseau horaire : un horodatage basé sur UTC est interprétable de manière unique dans le monde entier. Les indications temporelles locales (changements d'heure d'été, frontières de fuseaux horaires) ne faussent ni la triabilité ni la comparabilité.
• Convertibilité : toute application peut à tout moment convertir l'horodatage UTC dans le fuseau horaire local de l'utilisateur — en particulier les applications qui doivent tenir un horodatage (par ex. saisie du temps de travail des collaborateurs, preuves de temps de travail, suivi des délais). Le chemin inverse (temps local comme base) conduit à des ambiguïtés (passage à l'heure d'été : 03:00 CEST = 01:00 UTC existe deux fois).
• Conformité GoBD : le respect de la chronologie et la traçabilité (§ 146 AO) exigent une base temporelle immuable et univoque. UTC est la seule base qui garantit cette propriété de manière systémique.
• Cohérence avec la RFC 9562 : la norme UUIDv7 définit l'horodatage comme des millisecondes depuis l'époque Unix (UTC) ; toute génération qui s'en écarte viole la norme.

Règle de reconnaissance : lors du décodage d'un V7GUID/uuidV7, la valeur de 48 bits extraite doit toujours être lue comme UTC. L'affichage/le traitement ultérieur en heure locale s'effectue exclusivement dans la couche de présentation de l'application, jamais dans la base de l'identifiant.

Norme et implémentation : le principe V7GUID (hiérarchie à 6 niveaux dans les bits GUID, plages de bits fixes, recherche O(1), références inter-dépôts) fait partie de la demande de brevet 10 2025 003 091.6. L'attribution canonique des bits (offsets/largeurs/plages de valeurs exacts par segment) est tenue de manière normative dans la spécification de protocole specs/v7guid/ — voir notamment 00_gesamtkarte.md. GCBoK représente cette norme ; en cas d'écart, la spécification fait foi.

Class-Identifier - Registre des segments

Le Class-Identifier GitCover (le segment class du V7GUID) est construit de manière déterministe à partir d'une hiérarchie métier à six niveaux. Chaque niveau fait 4 bits de large (plage de valeurs 0–15, soit 16 valeurs possibles par niveau) et est affecté globalement via un dictionnaire normatif dans le dépôt .gitcover du répertoire TOP. En outre, le V7GUID porte plusieurs champs d'identification étendus. Le registre suivant liste tous les segments groupés avec leur valeur maximale possible respective et constitue la référence contraignante pour l'interopérabilité entre les dépôts GitCover.

Hiérarchie métier (classification déterministe)

La notation sous forme de chaîne de classification combine les six niveaux en L1_L2_L3_L4_L5_L6 — par ex. 1_14_12_14_13_1 (poste de prix Portfolio). La plage de valeurs 16⁶ = 16.777.216 couvre toutes les classifications déterministes.

Hiérarchie métier comme ontologie

Les six dictionnaires (d'Entity à Instance) forment ensemble l'ontologie GitCover : un vocabulaire partagé et lisible par machine de l'organisation — entités (par ex. Business Entity, Business Partner), leurs relations, règles et classifications. Ainsi, les humains, les validateurs et les agents IA parlent la même langue : un terme comme « ERechnung » (ProcessType 13) signifie la même chose dans chaque dépôt, chaque schéma et chaque politique.

Chez GitCover, l'ontologie est réalisée de manière native Git — non pas comme une base de données de graphes dans une plateforme :

Microsoft décrit sa couche sémantique comme un « governed, self-service knowledge graph » qui fournit aux agents un « shared context » — le même espace de problème (contexte d'agent, termes uniformes), mais résolu de manière liée à la plateforme. GitCover le résout de manière native au dépôt : l'ontologie est le fonds normatif dans le dépôt Git, non un service chez un fournisseur. Détails sur la délimitation : Glossaire (« Ontologie ») et Composants : GCUCB, contexte de marché.

Champs d'identification étendus du V7GUID (typisation de conformité)

Outre la hiérarchie à 6 niveaux, le V7GUID porte six autres champs d'identification pouvant être affectés de manière déterministe. Ils sont des aides à la catégorisation/au classement et typisent des aspects de conformité supplémentaires d'un justificatif. Ils ne sont explicitement pas des identificateurs d'instance d'objet — quel objet concret est visé est indiqué uniquement par l'Object ID (le simple uuidv7) du double identifiant. De nombreux objets partagent la même valeur de champ d'identification.

Remarque : VariantId s'appelait auparavant InstanceId ; le nom a été changé parce que le champ typise une classe de déclinaison, et non une instance d'objet. GatewayId/VariantId ont été réduits avec l'ADR-002 de 16/14 à 8/6 bits afin de libérer de la place pour status et kind — voir specs/v7guid/ADR-002_layout_v2_kind.md.

Ainsi, un seul identifiant encode de manière multidimensionnelle ce qui, où, par quoi, via quel point de contrôle, dans quel état du cycle de vie et dans quelle déclinaison un justificatif a été créé — directement vérifiable depuis le GUID (O(1), sans requête à la base de données). Exemple d'une e-facture vérifiée : 1_14_12_14_13_1 + RepositoryId 3 (DMS) + ProcessTypeId 12 (contrôle EN16931) + GatewayId 220 (validation à quatre yeux) + VariantId 10 (conservation de 10 ans).

Attribution : les niveaux de 4 bits L1–L6 sont canoniques au niveau global et sont coordonnés exclusivement via les dictionnaires du dépôt TOP .gitcover (échange via GCEP/GCUCB). Pour les champs d'identification étendus, des dictionnaires propres s'appliquent (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json) ; la valeur la plus élevée de chacun est réservée comme Custom/TenantDefined. Les codes non attribués restent libres pour une attribution globale ultérieure. Référence normative : specs/v7guid/50_erweiterte_kennfelder_compliance.md.

Gateway de processus (pgid) et registre d'actions (261026)

Le GatewayId de 8 bits typise le point de contrôle. L'identité complète du gateway de processus (pgid) est une classe V7GUID composée de repository_id + gateway_id (+ époque de classe), générée avec gc-v7guid class — pas un UUID aléatoire et non dérivée du SHA du document.

Registre (à deux niveaux) : OSS/TOP/.gitcover/dictionaries/gateway_ids.json (valeurs 8 bits) et <Tenant>/TOP/compliance/process_gateways.json (process_key, uuidV7 = pgid, repository_id, gateway_id). Le bloc GCUV 180–189 est provisoire jusqu'à l'allocation OSS : 180 création de facture, 181 PDF, 182 Verify, 183 ingestion DMS, 184 Books, 185 OP.

Séparation des rôles : produced_by_pgid est l'action productrice (par ex. gc-billing invoice) ; stored_by_pgid est l'action de stockage (gc-dms scan --apply). Le registre DMS stocke la facture, il ne la crée pas. L'object_id du DMS est la docUid du sidecar, pas un nouvel UUID de registre.

Justificatif : GCUV/TOP/compliance/{PROCESS_GATEWAYS.md,process_gateways.json} ; rapport de contrôle AFJD/FY2026/reports/261026_pruefung_rechnungsausgang_afjd-ada.md § 8.5.

Registre central des tenants

La TenantId d'une entité juridique GitCover n'est pas dérivée d'une plage de numéros attribuée, mais de manière déterministe à partir des 48 premiers bits (horodatage en millisecondes) de l'UUIDv7 généré lors de la création initiale du répertoire TOP du tenant. L'identifiant de tenant est ainsi lié au temps, triable et unique sans base de données de séquence centrale — tant que deux tenants ne sont pas créés au même instant en millisecondes.

Source temporelle librement choisissable : l'horodatage de 48 bits ne doit pas nécessairement correspondre au moment réel de création. Au lieu de l'heure système (DateTime.Now), chaque tenant peut générer l'UUIDv7 à partir d'un instant explicitement prédéfini — par exemple la date de fondation de l'entité juridique ou une date de référence choisie arbitrairement (cf. CustomEpoch/Timestamp dans le TenantContext). L'identifiant de tenant peut ainsi être lié à une date significative sur le plan métier ; l'unicité est conservée tant que l'instant en millisecondes choisi n'entre pas en collision entre tenants (raison supplémentaire de l'enregistrement volontaire).

Comme les dépôts GitCover se référencent mutuellement via des traversées others.json (résolution inter-dépôts de chemins physiques et logiques), un identifiant de tenant doit être résolvable de manière univoque lors d'une utilisation inter-dépôts. C'est pourquoi il existe un registre central et volontaire.

Modèle d'enregistrement (volontaire, sans plages de numéros)

• Aucune plage de numéros réservée. Comme la TenantId provient de l'horodatage de 48 bits, il n'existe ni plage de numéros « publique » ni « privée » — la distinction réside uniquement dans la tenue au registre.
• Caractère volontaire. L'enregistrement est optionnel. Celui qui a besoin d'une interopérabilité inter-dépôts et d'une absence de collision pour les traversées others.json enregistre publiquement son tenant.
• Immutabilité. Un identifiant de tenant enregistré est final et stable ; pas de réutilisation après dissolution (statut ARCHIVED).

Instance de registre canonique : le registre opérationnel des tenants est tenu dans la racine du tenant concerné sous .gitcover/access/TENANT_GUID_REGISTER.md (nom court · entité juridique · UUIDv7 · horodatage · statut). Il constitue la liste de référence des tenants enregistrés.

Chaînes de justificatifs (Evidence Chains)

Une chaîne de justificatifs enchaîne des artefacts de conformité via des références prev-hash :

1. Justificatif B1 - V7GUID : ...-PERSON-..., SHA256 : 3f2a1c..., prev : -
2. Justificatif B2 - V7GUID : ...-INVOICE-..., SHA256 : 7d4e2f..., prev : 3f2a1c...
3. Justificatif B3 - V7GUID : ...-PAYMENT-..., SHA256 : 1b8f90..., prev : 7d4e2f...

Chaque justificatif référence le hash SHA-256 de son prédécesseur. L'ensemble de la chaîne est ainsi ancré cryptographiquement et résistant aux manipulations.

Schéma de métadonnées (artefact de données .gc.md)

L'artefact de données figure sous forme de fence JSON à la fin du document (lisible par l'humain d'abord, données en dernier) :

{
  "docUid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "v7guid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "class": "INVOICE",
  "sha256": "7d4e2f...",
  "prev_sha256": "3f2a1c...",
  "gpg_fingerprint": "ABCD1234...",
  "timestamp_iso": "2026-06-14T11:18:00+02:00",
  "gobd_periode": "FY2026"
}

Originaux binaires et sidecars GitCover

Les justificatifs qui se présentent sous forme de fichier binaire (PDF, DOCX, EML, image) ne peuvent pas porter de métadonnées en interne dans Git. Ils sont accrochés à la chaîne de justificatifs via un sidecar GitCover (*.gc.md à côté de l'original) : le sidecar porte au minimum le sha256 de l'original ainsi que la DocID (uuidv7, identificateur d'instance) et le v7guid catégorisé (contexte). Le processus et l'attribution de la DocID à partir de l'horodatage du fichier sont décrits dans Axe 5 : Procédures ; pour l'enregistrement du tenant associé, voir Registre central des tenants ci-dessus. Pour la délimitation, il convient de noter : docUid (instance), sha256 (contenu), V7GUID (classe) et GCPN-docUid (opération) sont des axes distincts ; seule la docUid du document devient l'object_id du DMS.

Détection des métadonnées et variantes companion

La détection des métadonnées de document est guidée par le contenu, non par l'extension. Un document original possède des métadonnées lorsqu'une instance de schéma JSON intégrée les décrit :

1. Sidecar de base <artefakt>.<orig-ext>.gc.md : l'instance porte docUid (instance de document), sha256 (ancre de contenu), v7guid (classe) et locations ; le docUid est l'object_id du document.
2. Variante companion *.gcsig.md avec bloc source intégré : le GCSIG est un artefact de signature avec son propre docUid ; l'instance de document se trouve dans source.v7g_docUid, l'ancre de contenu dans subject.sha. Le DMS reprend source.v7g_docUid comme object_id du document et ne conserve la docUid GCSIG que sous la forme GCSIG:<docUid> dans les références de métadonnées.

Au cours de la durée de vie d'un document ou d'une opération, des méta-documents peuvent changer de rôle et donc de profil — de manière analogue aux variantes OOD (surcharge/polymorphisme) : la base sidecar (.gc.md) passe à un artefact de signature (.gcsig.md avec source) ; GCPN (.gcpn.md) reste l'opération et est complété de manière additive via documents[]/children[]/relations[] ; les ancres GCAL (GCPN sous .gitcover/gcal/<uuidV7>.gcpn.md) restent des ancres de processus. Un renommage ne change pas l'identité du méta-doc (docUid/opération restent), mais bien le SHA-256 du fichier ; une transformation de processus peut renommer ou recréer et fusionner des données existantes. Ce qui est déterminant, c'est l'identité de contenu, non le nom de fichier.

Conteneur d'opération (.gcpn.md) — niveau processus de la chaîne de justificatifs

À côté du catalogage par sidecar intervient le conteneur GCPN pour les opérations à plusieurs étapes (par ex. la création et la signature d'une GVB) : un .gcpn.md à côté du Referenced-Doc (<Referenced-Doc-Basisname>.gcpn.md), qui accompagne le processus comme document original de processus autonome — non comme sidecar du Referenced-Doc. Sur le plan conceptuel :

• Doc mutable avec artefacts JSON immuables (schéma gcpn-container-2.7, self-contained) : referenced_doc, actor, retention sont décrits une seule fois chacun ; arborescence via parents[]/children[]/documents[] ; les autres références passent par SHA-256 ou actor_ref — aucune redondance interne.
• Events comme enum de flags avec résultat : offered(1), accepted(2), denied(4), sign(8), withdraw(16) — les étapes parcourues donnent le bitmask events_result (par ex. 11 = offered + accepted + sign) avec confirmation chain_valid du chaînage de hash.
• Compléter au lieu de recréer : chaque nouvelle étape de processus positionne le flag, intègre le nouvel artefact et met à jour summary ; les artefacts JSON déjà intégrés restent inchangés (immuables). L'historique du conteneur est conservé de manière auditable dans l'historique Git du dépôt.
• JSON toujours intégré (fence MD) — pas de fichiers .json autonomes dans l'arborescence du dépôt (éviter le bloat).
• Fonction d'index GCDMS : dans le DMS optionnellement raccordé, le conteneur sert d'index pour la navigation de processus vers les documents individuels — au lieu de n8n ou d'engines de workflow similaires.

Un Referenced-Doc signé devient ensuite immuable (GoBD : immuabilité) ; le conteneur reste mutable et documente le processus plus avant — l'historique Git constitue la preuve.

GCPN monofichier — suivi progressif/rétrograde des justificatifs (AO, 261026)

Pour les factures et autres justificatifs, le GCPN devient un conteneur monofichier : un .gcpn.md porte documents[] (XML comme document original, PDF comme vue), le workflow create→pdf→present→accept→sign→register, events, properties.values et relations (contrat/justificatifs de coûts). XML/PDF restent des artefacts séparés ; un .gc.md séparé disparaît — le GCPN porte docUid, SHA-256, chemin et titre.

Ainsi, le GCPN est le point de convergence unique pour l'UI et le tooling ; la SAGA (création, présentation, acceptation, signature, enregistrement) se trouve entièrement dans le conteneur. Référence normative : specs/v7guid/70_belegkreise-dokumentenzuordnung.de.md § « Ein-Datei-GCPN ».

Règle de promotion : un .gc.md existant peut être enrichi dans le GCPN ; les artefacts JSON du sidecar sont intégrés (GCPN = sur-ensemble, .gc.md = sous-ensemble). Ensuite, le .gc.md séparé est redondant et peut être supprimé du système de fichiers ; l'historique Git porte la traçabilité (GoBD), le GCPN reste SSoT.

Gates/OPA : workflow.gates[].id est un uuidV7 de l'action/méthode (jointure GCAL/GCEP), workflow.gates[].rule la policy_uuid de l'identité OPA/règle ; les deux sont enregistrés (GCUV/TOP/compliance/gates.json respectivement policies/registry.json). rule_text n'est que l'affichage ; les classes/types passent par les catalogues V7GUID.

Collections immuables : les définitions immuables (ENUM/UNION/Flags) se trouvent dans OSS/TOP/.gitcover/dictionaries/immutable_collections.json et sont chargées une fois lors de l'initialisation du système. Le GCPN les référence via events.enum_ref (uuidV7) au lieu de les répéter ; le schéma 2.7 rend enum_definition optionnel (legacy). Les flags résultent des catalogues OSCAL pour GoBD/AO (profil gcpn-compliance-profile.yaml ; AO §146, GoBD Rz. 146/147) — l'ancrage de gouvernance figure dans le registre.

Identité de facture : properties.values.invoice_id est l'uuidV7 de l'Invoice Identifier ; invoice_no n'est que du texte et non un critère d'ordonnancement. Seller/Buyer sont référencés via leur Party-uuidV7 (creditor/vendor respectivement debitor/customer), non via des noms réels (PII).

Le GCPN comme protocole — l'Act comme transition d'état

Un GCPN est une forme de protocole. Dans le GCBoK, avec la conformité comme thème principal, il est souvent question d'assemblées des associés avec des résolutions, résumées dans un GVB :

Cette double signification (procès-verbal + transition d'état) est au cœur de la démontrabilité : chaque Act est décrit de manière déterministe — l'état avant est démontrable via la chaîne SHA-256 (sidecars, Referenced-Doc), l'état après via l'expression des flags et l'artefact intégré. L'historique Git du conteneur fournit la chronologie. Procédure et vérification : Axe 3 (GCPN) et Signature numérique (DS02–DS05).

Chaîne de preuves cryptographiques

La chaîne de preuves cryptographiques combine trois primitives cryptographiques :

1. Hash de commit Git - Immuabilité de l'état du dépôt
2. Signature GPG - Identité de l'acteur (qui a décidé ?)
3. V7GUID - Adressage déterministe (quoi et quand)

Il en résulte une chaîne à la fois ancrée cryptographiquement et triable dans le temps — la base de preuves de conformité auditables.

Fallback de récupération : à la fin, seuls les dépôts Git restent En cas de catastrophe, de perte d'infrastructure ou d'audit 10 ans plus tard, le dernier ensemble d'artefacts fonctionnel est le dépôt Git lui-même (ou git bundle/export ZIP). Il contient : les artefacts de code, les registres/dictionnaires .gitcover/ (JSON/JSONL), les keyrings GPG (.gitcover/keys/), les chaînes de justificatifs V7GUID. Aucune base de données, aucun serveur web, aucun service en cours d'exécution n'est nécessaire. La forensique est le dépôt Git — les paquets de contrôle HTML ne sont que des dérivés de présentation (voir Procédures : Audit-Readiness).

Branchement déterministe

Le branchement déterministe permet de lier des chaînes de justificatifs à des structures de dépôt Git. Par la combinaison de :

• Dépôts Git comme périodes de conformité (p. ex. FY2026)
• Classes V7GUID comme types de documents (INVOICE, PAYMENT, PERSON)
• Politiques OPA comme hooks pre-receive (validation avant commit)

il naît des structures de conformité reproductibles et auditables — sans maintenance manuelle ultérieure.

Voir aussi : les primitives techniques (GPG, uuidV7, OSCAL) sont approfondies dans Axe 4 : Techniques.