Achse 2: Konzepte
V7GUID — Version-7-GUID
V7GUID (auch: Categorized UUIDv7 Identifier) ist ein Kategorisierungsschema für Identifikatoren in GitCover-Artefakten, basierend auf RFC-4122-kompatibler UUID Version 7 (zeitbasiert, sortierbar), erweitert um eine GitCover-spezifische Klassenklassifikation.
Aufbau
| Segment | Bits | Spannweite | Bedeutung |
|---|---|---|---|
| timestamp_ms | 48 | RFC 4122 UUIDv7 Basis | Millisekunden seit Unix-Epoch (sortierbar) |
| version | 4 | RFC 4122 UUIDv7 Basis | Fest: 0111 (UUIDv7) |
| rand_a | 12 | RFC 4122 UUIDv7 Basis | Deterministischer Vektor für GitCover Tenant-/Doc-/Class-/Action-Dictionaries (definiert in TOP's .gitcover Repo) |
| variant | 2 | RFC 4122 UUIDv7 Basis | Fest: 10 (RFC 4122) |
| repository_id | 12 | GitCover Erweiterung | Repo-/Tenant-Scope (aus RFC rand_a) |
| class (L1–L6 + erweiterte Kennfelder) | 62 | GitCover Erweiterung | Deterministisch belegte GitCover-Nutzlast (6-Level-Hierarchie + erweiterte Kennfelder für Compliance-Typisierung, aus RFC rand_b) |
Zweck: Deterministische, sortierbare Verknüpfung von Belegen in einer Beleg-Kette. Ermöglicht zeitliche/versionierte Rekonstruierbarkeit (GoBD: Zeitgerechtheit) ohne zentrale Sequenzdatenbank.
Norm & Implementierung: Das V7GUID-Prinzip (6-Level-Hierarchie in GUID-Bits, feste Bitbereiche, O(1)-Lookup, Cross-Repo-Referenzen) ist Bestandteil der Patentanmeldung
10 2025 003 091.6. Die kanonische Bit-Belegung (exakte Offsets/Breiten/Wertebereiche je Segment) ist normativ in der Protokoll-Spezifikationspecs/v7guid/geführt — siehe dort00_gesamtkarte.md. GCBoK stellt diese Norm dar; bei Abweichungen gilt die Spezifikation.
Class-Identifier — Segmentregister
Der GitCover Class-Identifier (das class-Segment der V7GUID) ist deterministisch aus einer sechsstufigen Business-Hierarchie aufgebaut. Jede Stufe ist 4 Bit breit (Wertebereich 0–15, also 16 mögliche Ausprägungen pro Stufe) und wird über ein normatives Dictionary im .gitcover-Repo des TOP-Verzeichnisses global belegt. Zusätzlich trägt die V7GUID mehrere erweiterte Kennfelder. Das folgende Register listet alle Segmente gruppiert mit ihrem jeweils größtmöglichen Wert auf und bildet die verbindliche Referenz für die Interoperabilität zwischen GitCover-Repos.
Business-Hierarchie (deterministische Klassifikation)
| # | Segment | Bits | Max-Value | Dictionary | Bedeutung |
|---|---|---|---|---|---|
| L1 | Entity | 4 | 15 | entities.json |
Business Entity (z. B. 1 BusinessEntities, 2 BusinessPartners) |
| L2 | Department | 4 | 15 | departments.json |
Abteilung/Bereich (z. B. 14 Portfolio, 9 IT) |
| L3 | Category | 4 | 15 | categories.json |
Kategorie (z. B. 15 Service, 14 DocSigning) |
| L4 | SubCategory | 4 | 15 | subcategories.json |
Sub-Kategorie (z. B. 14 Leistung, 13 Preisposition) |
| L5 | ProcessType | 4 | 15 | processtypes.json |
Prozesstyp (z. B. 13 ERechnung, 14 Gobd, 15 Agentic) |
| L6 | Instance | 4 | 15 | instances.json |
Instanz (z. B. 1 Default, 2 Primary) |
Die Classification-String-Notation kombiniert die sechs Stufen zu L1_L2_L3_L4_L5_L6 — z. B. 1_14_12_14_13_1 (Portfolio-Preisposition). Der Wertebereich 16⁶ = 16.777.216 deckt alle deterministischen Klassifikationen ab.
Erweiterte Kennfelder der V7GUID (Compliance-Typisierung)
Neben der 6-Level-Hierarchie trägt die V7GUID vier weitere deterministisch belegbare Kennfelder. Sie sind Kategorisierungs-/Einordnungshelfer und typisieren zusätzliche Compliance-Aspekte eines Belegs. Sie sind ausdrücklich keine Objekt-Instanz-Identifikatoren — welches konkrete Objekt gemeint ist, sagt allein der Object ID (das reine uuidv7) des Dual-Identifiers. Viele Objekte teilen sich denselben Kennfeld-Wert.
| Segment | Bits | Max-Value (Custom) |
Frage | Compliance-Dimension |
|---|---|---|---|---|
| RepositoryId | 12 | 4.095 | Wo? | Repo-/Daten-Scope (TOP + bis zu 4.095 Repos je Tenant); Mandanten-/PII-Trennung |
| ProcessTypeId | 8 | 255 | Wodurch? | Verfahren, das den Beleg erzeugte (GoBD, EN16931, AI-Act) |
| GatewayId | 16 | 65.535 | Kontrollpunkt? | Übergabe-/Freigabepunkt (Beleg-Kette, Funktionstrennung) |
| VariantId | 14 | 16.383 | Ausprägung? | Rechtskontext (Aufbewahrung §147 AO, DSGVO-Schutzstufe, IFRS/HGB) |
Hinweis:
VariantIdhieß früherInstanceId; der Name wurde geändert, weil das Feld eine Ausprägungsklasse typisiert, keine Objekt-Instanz.
Damit kodiert ein einziger Identifier mehrdimensional was, wo, wodurch, über welchen Kontrollpunkt und in welcher Ausprägung ein Beleg entstand — direkt aus der GUID prüfbar (O(1), ohne Datenbankabfrage). Beispiel einer geprüften E-Rechnung: 1_14_12_14_13_1 + RepositoryId 3 (DMS) + ProcessTypeId 12 (EN16931-Prüfung) + GatewayId 220 (Vier-Augen-Freigabe) + VariantId 10 (10-Jahre-Aufbewahrung).
Belegung: Die 4-Bit-Stufen L1–L6 sind global-kanonisch und werden ausschließlich über die Dictionaries im TOP-
.gitcover-Repo koordiniert (Austausch via GCEP/GCUCB). Für die erweiterten Kennfelder gelten eigene Dictionaries (repository_ids.json,processtype_ids.json,gateway_ids.json,variant_ids.json); der jeweils höchste Wert ist alsCustom/TenantDefinedreserviert. Nicht belegte Codes bleiben frei für spätere globale Vergabe. Normative Referenz:specs/v7guid/50_erweiterte_kennfelder_compliance.md.
Zentrales Tenant-Register
Die TenantId eines GitCover-Rechtsträgers wird nicht aus einem vergebenen Nummernkreis abgeleitet, sondern deterministisch aus den ersten 48 Bit (Millisekunden-Zeitstempel) der UUIDv7, die beim erstmaligen Anlegen des TOP-Verzeichnisses des Tenants erzeugt wird. Der Tenant-Identifier ist damit zeitgebunden, sortierbar und ohne zentrale Sequenzdatenbank eindeutig — solange keine zwei Tenants im selben Millisekunden-Zeitpunkt entstehen.
Frei wählbare Zeitquelle: Der 48-Bit-Zeitstempel muss nicht der tatsächliche Anlege-Zeitpunkt sein. Statt der Systemzeit (DateTime.Now) kann jeder Tenant die UUIDv7 aus einem explizit vorgegebenen Zeitpunkt generieren — etwa dem Gründungsdatum des Rechtsträgers oder einem beliebig anders gewählten Referenzdatum (vgl. CustomEpoch/Timestamp im TenantContext). So lässt sich der Tenant-Identifier an ein fachlich bedeutsames Datum binden; die Eindeutigkeit bleibt erhalten, solange der gewählte Millisekunden-Zeitpunkt tenant-übergreifend nicht kollidiert (weiterer Grund für die freiwillige Registrierung).
Weil GitCover-Repos über others.json-Traversen aufeinander verweisen (Cross-Repo-Auflösung physischer und logischer Pfade), muss ein Tenant-Identifier bei repo-übergreifender Nutzung eindeutig auflösbar sein. Deshalb existiert ein zentrales, freiwilliges Register.
Registrierungsmodell (freiwillig, ohne Nummernbereiche)
| Zustand | Bedeutung | Interoperabilität |
|---|---|---|
| Öffentlich registriert | Tenant-UUIDv7 ist im zentralen Register geführt (Kurzname, Rechtsträger, Zeitstempel, Status) | Kollisionsfrei auflösbar; verbindlich für others.json-Traversen zwischen Repos |
| Privat / unregistriert | Tenant-UUIDv7 existiert lokal, ist aber nicht im Register geführt | Zulässig für interne Nutzung; Kollisionsrisiko bei repo-übergreifenden Traversen (kein Konfliktschutz, keine garantierte Auflösung) |
- Keine reservierten Nummernbereiche. Da die TenantId aus dem 48-Bit-Zeitstempel entsteht, gibt es weder einen „öffentlichen" noch einen „privaten" Nummernkreis — die Unterscheidung liegt allein in der Führung im Register.
- Freiwilligkeit. Die Registrierung ist optional. Wer repo-übergreifende Interoperabilität und Kollisionsfreiheit für
others.json-Traversen benötigt, registriert seinen Tenant öffentlich. - Unveränderlichkeit. Ein registrierter Tenant-Identifier ist final und stabil; kein Re-Use nach Auflösung (Status
ARCHIVED).
Kanonische Registerinstanz: Das operative Tenant-Register wird im jeweiligen Tenant-Root unter
.gitcover/access/TENANT_GUID_REGISTER.mdgeführt (Kurzname · Rechtsträger · UUIDv7 · Zeitstempel · Status). Es ist die maßgebliche Liste registrierter Tenants.
Beleg-Ketten (Evidence Chains)
Eine Beleg-Kette verkettet Compliance-Artefakte über prev-hash-Referenzen:
- Beleg B1 — V7GUID:
...-PERSON-..., SHA256:3f2a1c..., prev: — - Beleg B2 — V7GUID:
...-INVOICE-..., SHA256:7d4e2f..., prev:3f2a1c... - Beleg B3 — V7GUID:
...-PAYMENT-..., SHA256:1b8f90..., prev:7d4e2f...
Jeder Beleg referenziert den SHA-256-Hash seines Vorgängers. Die gesamte Kette ist damit kryptographisch verankert und manipulationssicher.
Metadaten-Schema (.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"
Cryptographic Evidence Chain
Die Cryptographic Evidence Chain kombiniert drei kryptographische Primitive:
- Git-Commit-Hash — Unveränderlichkeit des Repository-State
- GPG-Signatur — Identität des Akteurs (Wer hat entschieden?)
- V7GUID — Deterministische Adressierung (Was und Wann)
Damit entsteht eine Kette, die sowohl kryptographisch verankert als auch zeitlich sortierbar ist — die Grundlage für revisionssichere Compliance-Nachweise.
Deterministische Verzweigung
Die deterministische Verzweigung ermöglicht es, Beleg-Ketten an Git-Repository-Strukturen zu binden. Durch die Kombination von:
- Git-Repositories als Compliance-Perioden (z.B.
FY2026) - V7GUID-Klassen als Dokumenttypen (INVOICE, PAYMENT, PERSON)
- OPA-Policies als Pre-Receive-Hooks (Validierung vor Commit)
entstehen reproduzierbare, audit-fähige Compliance-Strukturen — ohne manuelle Nachpflege.
Siehe auch: Die technischen Primitive (GPG, uuidV7, OSCAL) werden in Achse 4: Techniken vertieft.