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, basé sur l'UUID version 7 compatible RFC 4122 (basée sur le temps, triable), étendu d'une classification de classes spécifique à GitCover.

Structure

Objectif : liaison déterministe et triable de justificatifs au sein d'une chaîne de justificatifs. Permet une reconstitution temporelle/versionnée (GoBD : Zeitgerechtheit) sans base de données de séquences centrale.

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

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

Justification :

• Neutralité de fuseau horaire : un horodatage basé sur UTC est interprétable de manière univoque dans le monde entier. Les indications d'heure locales (changement d'heure d'été, limites de fuseaux horaires) ne faussent ni la triabilité ni la comparabilité.
• Convertibilité : chaque application peut à tout moment convertir l'horodatage UTC dans le fuseau horaire local de l'utilisateur - en particulier les applications qui doivent tenir une marque temporelle (p. ex. gestion des temps des employés, justificatifs de temps de travail, suivi des échéances). Le chemin inverse (heure locale comme base) conduit à des ambiguïtés (passage à l'heure d'été : 03:00 CEST = 01:00 UTC existe deux fois).
• Conformité GoBD : la Zeitgerechtheit et la traçabilité (§ 146 AO) exigent une base temporelle immuable et univoque. UTC est la seule base qui garantisse cette propriété de manière systémique.
• Cohérence avec la RFC 9562 : la norme UUIDv7 définit l'horodatage comme millisecondes depuis l'époque Unix (UTC) ; toute génération s'en écartant viole la norme.

Règle de détection : lors du décodage d'un V7GUID/uuidV7, la valeur 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 du GUID, plages de bits fixes, recherche O(1), références cross-repo) fait partie de la demande de brevet 10 2025 003 091.6. L'attribution canonique des bits (offsets/largeurs/plages de valeurs exacts pour chaque segment) est régie de manière normative dans la spécification du protocole specs/v7guid/ - voir 00_gesamtkarte.md à cet endroit. GCBoK représente cette norme ; en cas d'écart, la spécification prévaut.

Class-Identifier - Registre des segments

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

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

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

Champs de caractérisation étendus de la V7GUID (typage de conformité)

Outre la hiérarchie à 6 niveaux, la V7GUID porte quatre autres champs de caractérisation attribuables de manière déterministe. Ce sont des auxiliaires de catégorisation/classement et ils typent des aspects de conformité supplémentaires d'un justificatif. Ils ne sont expressément pas des identifiants d'instance d'objet - quel objet concret est visé, seul l'Object ID (le uuidv7 pur) de l'identifiant dual le précise. De nombreux objets partagent la même valeur de champ de caractérisation.

Remarque : VariantId s'appelait auparavant InstanceId ; le nom a été modifié car le champ type une classe de variante, pas une instance d'objet.

Ainsi, un seul identifiant code de manière multidimensionnelle quoi, où, par quoi, via quel point de contrôle et dans quelle variante un justificatif a été créé - vérifiable directement depuis le GUID (O(1), sans requête en base de données). Exemple de facture électronique vérifiée : 1_14_12_14_13_1 + RepositoryId 3 (DMS) + ProcessTypeId 12 (vérification EN16931) + GatewayId 220 (approbation à quatre yeux) + VariantId 10 (conservation de 10 ans).

Attribution : les niveaux 4 bits L1–L6 sont canoniques à l'échelle globale et coordonnés exclusivement via les dictionnaires du repo .gitcover du TOP (échange via GCEP/GCUCB). Pour les champs de caractérisation étendus s'appliquent des dictionnaires propres (repository_ids.json, processtype_ids.json, gateway_ids.json, variant_ids.json) ; la valeur la plus élevée de chacun est réservée en tant que 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.

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 qui est générée lors de la création initiale du répertoire TOP du tenant. L'identifiant de tenant est ainsi lié au temps, triable et univoque sans base de données de séquences centrale - tant que deux tenants ne naissent pas à la même milliseconde.

Source temporelle librement choisissable : l'horodatage 48 bits ne doit pas nécessairement correspondre au moment réel de la création. Au lieu de l'heure système (DateTime.Now), chaque tenant peut générer l'UUIDv7 à partir d'un moment explicitement prédéfini - par exemple la date de fondation de l'entité juridique ou toute autre date de référence choisie librement (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 préservée tant que le moment en millisecondes choisi n'entre pas en collision entre tenants (raison supplémentaire pour l'enregistrement volontaire).

Comme les repos GitCover se référencent mutuellement via des parcours others.json (résolution cross-repo des chemins physiques et logiques), un identifiant de tenant doit être résoluble de manière univoque en cas d'utilisation inter-repos. 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 48 bits, il n'existe ni plage de numéros « publique » ni plage « privée » - la distinction réside uniquement dans la tenue dans le registre.
• Volontariat. L'enregistrement est facultatif. Quiconque a besoin d'interopérabilité inter-repos et d'absence de collisions pour les parcours others.json enregistre publiquement son tenant.
• Immuabilité. Un identifiant de tenant enregistré est définitif et stable ; aucune réutilisation après dissolution (statut ARCHIVED).

Instance de registre canonique : le registre de tenants opérationnel est tenu à la racine du tenant concerné sous .gitcover/access/TENANT_GUID_REGISTER.md (nom court · entité juridique · UUIDv7 · horodatage · statut). C'est la liste faisant foi des tenants enregistrés.

Chaînes de justificatifs (Evidence Chains)

Une chaîne de justificatifs enchaîne les 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 hachage SHA-256 de son prédécesseur. Toute la chaîne est ainsi ancrée cryptographiquement et à l'épreuve des manipulations.

Schéma de métadonnées (.v7g.md)

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 V7GUID

Les justificatifs existant sous forme de fichier binaire (PDF, DOCX, EML, image) ne peuvent pas porter de métadonnées en interne dans Git. Ils sont raccordés à la chaîne de justificatifs via un sidecar V7GUID (*.v7g.md à côté de l'original) : le sidecar contient au minimum le sha256 de l'original ainsi que la DocID (uuidv7, identifiant d'instance) et la v7guid catégorisée (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 de tenant associé, voir Registre central des tenants ci-dessus.

Cryptographic Evidence Chain

La Cryptographic Evidence Chain 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 chronologiquement - la base de preuves de conformité à l'épreuve des audits.

Recovery-Fallback : au final, il ne reste que les repos Git En cas de catastrophe, de perte d'infrastructure ou d'audit 10 ans plus tard, le dernier jeu d'artefacts fonctionnel est le dépôt Git lui-même (ou l'export git bundle/ZIP). Il contient : artefacts de code, registres/dictionnaires .gitcover/ (JSON/JSONL), trousseaux de clés GPG (.gitcover/keys/), chaînes de justificatifs V7GUID. Aucune base de données, aucun serveur web, aucun service en cours d'exécution requis. La forensique, c'est le repo Git — les paquets d'audit HTML ne sont que des dérivés de présentation (voir Procédures : Audit-Readiness).

Ramification déterministe

La ramification déterministe permet de lier les chaînes de justificatifs aux structures de dépôts Git. Par la combinaison de :

• dépôts Git en tant que périodes de conformité (p. ex. FY2026)
• classes V7GUID en tant que types de documents (INVOICE, PAYMENT, PERSON)
• policies OPA en tant que hooks pre-receive (validation avant commit)

il en résulte 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.