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

Zweck: Deterministische, sortierbare Verknüpfung von Belegen in einer Beleg-Kette. Ermöglicht zeitliche/versionierte Rekonstruierbarkeit (GoBD: Zeitgerechtheit) ohne zentrale Sequenzdatenbank.

Zeitbasis: GMT/UTC (normative Regel)

Die 48-Bit-Zeitstempel aller V7GUIDs und uuidV7s sind immer auf Basis GMT/UTC (Offset 0) zu generieren und zu interpretieren - niemals auf Basis einer lokalen Zeitzone (MESZ, MEZ etc.):

Begründung:

• Zeitzone-neutral: Ein UTC-basierter Zeitstempel ist weltweit eindeutig interpretierbar. Lokale Zeitzeichen (Sommerzeitwechsel, Zeitzonen-Grenzen) verzerren die Sortierbarkeit und Vergleichbarkeit nicht.
• Umrechenbarkeit: Jede App kann den UTC-Zeitstempel jederzeit in die lokale Zeitzone des Benutzers umrechnen - insbesondere Apps, die eine Zeitmarke führen müssen (z. B. Zeiterfassung für Mitarbeiter, Arbeitszeit-Nachweise, Fristen-Tracking). Der umgekehrte Weg (lokale Zeit als Basis) führt zu Mehrdeutigkeiten (Sommerzeit-Umstellung: 03:00 CEST = 01:00 UTC existiert zweimal).
• GoBD-Konformität: Zeitgerechtheit und Nachvollziehbarkeit (§ 146 AO) erfordern eine unveränderliche, eindeutige Zeitbasis. UTC ist die einzige Basis, die diese Eigenschaft systemisch garantiert.
• Konsistenz mit RFC 9562: Der UUIDv7-Standard definiert den Zeitstempel als Unix-Epoch-Millisekunden (UTC); jede davon abweichende Generierung verletzt den Standard.

Erkennungsregel: Beim Dekodieren eines V7GUID/uuidV7 ist der extrahierte 48-Bit-Wert immer als UTC zu lesen. Anzeigen/Weiterverarbeitung in lokaler Zeit erfolgt ausschließlich in der Darstellungsschicht der App, nie in der Identifikator-Basis.

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-Spezifikation specs/v7guid/ geführt - siehe dort 00_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)

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.

Business-Hierarchie als Ontologie

Die sechs Dictionaries (Entity bis Instance) bilden zusammen die GitCover-Ontologie: ein maschinenlesbares, geteiltes Vokabular der Organisation — Entitäten (z. B. Business Entity, Business Partner), ihre Beziehungen, Regeln und Klassifikationen. Damit sprechen Menschen, Validatoren und KI-Agenten dieselbe Sprache: Ein Begriff wie „ERechnung" (ProcessType 13) bedeutet in jedem Repo, jedem Schema und jeder Policy dasselbe.

Die Ontologie ist bei GitCover Git-nativ realisiert — nicht als Graph-Datenbank in einer Plattform:

Microsoft beschreibt seine semantische Schicht als „governed, self-service knowledge graph", der Agenten „shared context" liefert — derselbe Problemraum (Agenten-Context, einheitliche Begriffe), aber platformgebunden gelöst. GitCover löst ihn repo-nativ: Die Ontologie ist der Normbestand im Git-Repo, nicht ein Dienst bei einem Anbieter. Details zur Abgrenzung: Glossar („Ontologie") und Komponenten: GCUCB, Marktkontext.

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.

Hinweis: VariantId hieß früher InstanceId; 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 als Custom/TenantDefined reserviert. 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)

• 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.md gefü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:

1. Beleg B1 - V7GUID: ...-PERSON-..., SHA256: 3f2a1c..., prev: -
2. Beleg B2 - V7GUID: ...-INVOICE-..., SHA256: 7d4e2f..., prev: 3f2a1c...
3. 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"

Binär-Originale und V7GUID-Sidecars

Belege, die als Binärdatei vorliegen (PDF, DOCX, EML, Bild), können Git-intern keine Metadaten tragen. Sie werden über ein V7GUID-Sidecar (*.v7g.md neben dem Original) in die Beleg-Kette eingehängt: Das Sidecar führt mindestens den sha256 des Originals sowie die DocID (uuidv7, Instanz-Identifikator) und die kategorisierte v7guid (Kontext). Der Prozess und die DocID-Vergabe aus dem Datei-Zeitstempel werden in Achse 5: Vorgehensweisen beschrieben; die zugehörige Tenant-Registrierung siehe Zentrales Tenant-Register oben.

Vorgangs-Container (.gcpn.md) — Prozess-Ebene der Beleg-Kette

Neben die per-Sidecar-Katalogisierung tritt der GCPN-Container für mehrstufige Vorgänge (z. B. die Entstehung und Zeichnung einer GVB): eine .gcpn.md neben dem Referenced-Doc (<Referenced-Doc-Basisname>.gcpn.md), die den Prozess als eigenständiges Prozess-Ur-Doc begleitet — nicht als Sidecar des Referenced-Docs. Konzeptionell:

• Mutable Doc mit immutable JSON-Artefakten (Schema gcpn-container-1.0): referenced_doc, actor, retention werden je einmal beschrieben; weitere Verweise laufen über SHA-256 bzw. actor_ref — keine innere Redundanz.
• Events als Flags-Enum mit Ergebnis: offered(1), accepted(2), denied(4), sign(8), withdraw(16) — die durchlaufenen Schritte ergeben die events_result-Bitmask (z. B. 11 = offered + accepted + sign) mit chain_valid-Bestätigung der Hash-Verkettung.
• Ergänzen statt neu anlegen: Jeder neue Prozessschritt setzt das Flag, bettet das neue Artefakt ein und aktualisiert summary; bereits eingebettete JSON-Artefakte bleiben unverändert (immutable). Die Container-Historie liegt revisionssicher in der Git-Historie des Repos.
• JSON immer eingebettet (MD-Fence) — keine eigenständigen .json-Dateien im Repo-Baum (Bloating vermeiden).
• GCDMS-Index-Funktion: Im optional angedockten DMS dient der Container als Index für Prozess-Navigation zu den Einzel-Docs — statt n8n oder ähnlichen Workflow-Engines.

Ein signiertes Referenced-Doc wird danach immutable (GoBD: Unveränderbarkeit); der Container bleibt mutable und dokumentiert den Prozess weiter — die Git-Historie ist der Nachweis.

GCPN als Protokoll — der Act als Zustandsübergang

Ein GCPN ist eine Form eines Protokolls. Im GCBoK mit Compliance als Hauptthema wird oft von Gesellschafterversammlungen mit Beschlüssen gesprochen, die in einem GVB zusammengefasst sind:

Diese Doppel-Deutung (Protokoll + Zustandsübergang) ist der Kern der Nachweisbarkeit: Jeder Act ist deterministisch beschrieben — der Zustand vorher ist über die SHA-256-Kette (Sidecars, Referenced-Doc) nachweisbar, der Zustand nachher über den Flags-Ausdruck und das eingebettete Artefakt. Die Git-Historie des Containers liefert die Chronologie. Verfahren und Verifikation: Achse 3 (GCPN) und Digitales Signieren (DS02–DS05).

Cryptographic Evidence Chain

Die Cryptographic Evidence Chain kombiniert drei kryptographische Primitive:

1. Git-Commit-Hash - Unveränderlichkeit des Repository-State
2. GPG-Signatur - Identität des Akteurs (Wer hat entschieden?)
3. 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.

Recovery-Fallback: Am Ende bleiben nur Git-Repos übrig Bei Katastrophe, Infrastrukturverlust oder Audit 10 Jahre später ist der letzte funktionsfähige Artefakt-Satz das Git-Repository selbst (oder git bundle/ZIP-Export). Darin enthalten: Code-Artifacts, .gitcover/ Registries/Dictionaries (JSON/JSONL), GPG-Keyrings (.gitcover/keys/), V7GUID-Belegketten. Keine Datenbank, kein Webserver, keine laufenden Services erforderlich. Die Forensik ist das Git-Repo — HTML-Prüferpakete sind nur Präsentations-Derivate (siehe Vorgehensweisen: Audit-Readiness).

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.