Achse 3: Komponenten

Überblick

Das GCBoK definiert sechs Kernkomponenten des GitCover-Stacks:

GCDMS - GitCover Document Management System

Evidenz- und Dokumentenmanagementsystem auf Basis von .v7g.md-Containern und -Metadaten. Toolchain: v7g-pack, v7g-verify, v7g-sign, v7g-export.

GCPN - GitCover PrimaNota

Metadaten-Mechanismus zur Bildung revisionssicherer Nachweisketten (Vorgänger/Nachfolger) für Geschäftsdokumente. Der historische Begriff PrimaNota bezeichnet einen Ordnungsschlüssel, der einem Geschäftsvorfall - z.B. einem Buchungssatz der doppelten Buchführung oder einem mehrteiligen Buchungsvorgang (Forderung, Mehrwertsteuer, Kostenstelle/Kostenträger-Aufteilung) - einen eindeutigen Key für Zusammengehörigkeit zuweist. GCPN überträgt dieses Prinzip auf UUIDv7-Basis: Jedes Dokument erhält einen zeitgeordneten Identifier (RFC 9562) und wird über Predecessor/Successor-Referenzen mit seinen Vorgänger- und Nachfolger-Dokumenten verkettet.

Die Verkettung erfolgt nicht-chronologisch: Ein später erfasstes Dokument kann als Vorgänger (Predecessor-Insert) in eine bestehende Kette eingefügt werden - entscheidend für GoBD Rz. 80 (progressive und retrograde Prüfung). Match-Key-Felder (Bestellnummer, Debitor, Bruttobetrag etc.) ermöglichen automatische Kettenassoziation ohne manuelle Zuordnung.

Das Container-Format .v7g.md kombiniert menschenlesbare Metadaten (YAML + Markdown) mit maschinenverarbeitbaren Geschäftsdaten (eingebettetes JSON) und wird in Git-Repositories gespeichert, deren Commit-Hash als kryptographischer Integritätsnachweis dient.

Anwendungsgebiete über die Buchhaltung hinaus: DSGVO-Verarbeitungsverzeichnisse (Art. 30), NIS2-Incident-Ketten, MADR-Architekturentscheidungen, OIDC/OAuth-Token-Lifecycle, OSCAL-Assessment-Results.

GCPN-Signatur-Container (`.gcpn.md`) — Vorgangsbegleitung statt Einzeldateien

Für Signatur-Vorgänge konkretisiert sich GCPN als eigenständiges Prozess-Ur-Doc: Eine .gcpn.md-Datei neben dem Referenced-Doc (Namenskonvention <Referenced-Doc-Basisname>.gcpn.md) begleitet den Vorgang der Entstehung und Zeichnung — sie ist nicht das Sidecar des Referenced-Docs, sondern der Prozess-Container.

Wesentliche Konzeption:

Mutable Doc, immutable JSON-Artefakte: Das Container-MD wird für jeden neuen Prozessschritt ergänzt; die bereits eingebetteten JSON-Artefakte (Schema gcpn-container-1.0: referenced_doc, actor, retention je einmal beschrieben; events als Flags-Enum mit events_result-Bitmask, z. B. 11 = offered + accepted + sign; summary) bleiben unverändert.
Revisionssicherheit durch Git: Die Container-Historie (welche Schritte wann ergänzt wurden) liegt in der Git-Historie des Repos — der Commit-Hash dient als kryptographischer Integritätsnachweis.
Kein JSON-Bloat: JSON-Artefakte sind immer eingebettet (MD-Fence) — keine eigenständigen .json-Dateien im Repo-Baum.
GCDMS-Index-Funktion: Im optional angedockten DMS dient der Container als Index — Prozess-Navigation zu den Einzel-Docs und zur Prozessbeschreibung, statt n8n oder ähnlichen Workflow-Engines.
Immutable-Übergang: Ein signiertes Referenced-Doc wird danach immutable; der Container bleibt mutable und dokumentiert den Prozess weiter (Git- Historie = Nachweis).

Erstverwendung: GVB-Zeichnung mit Facsimile-Signatur (Teil I der Digitales Signieren, DS02–DS05).

Gebrauchsmuster-Schutz: Az 20 2026 000 272.7 - in Kraft. Geschützter Gegenstand: Container-Datenstruktur zur UUIDv7-basierten, revisionssicheren Geschäftsdokumentenverwaltung mit dynamischer Predecessor/Successor-Verkettung. Patentanmeldung eingereicht (47 Ansprüche).

GCUCB - GitCover Unified Communication Bus

Kontext-Bus für die Runtime-Koordination zwischen KI-Agenten, Policy-Validatoren und Audit-Systemen — mit deterministischer V7GUID-Adressierung der Kontextobjekte. GCUCB adressiert das Koordinations-Overhead-Problem mehrstufiger Agenten-Workflows (Serialisierungs- und Token-Kosten der Kontextübergabe) durch einen typisierten, direkt adressierbaren Bus statt textbasierter Zwischenschichten.

OPA/Rego fungiert als deterministische Guardrail-Ebene: Politik-Prüfung entsteht durch Regelwerk, nicht durch Prompt-Engineering.

Die Schutzrechtslage (Gebrauchsmuster, DPMA-Einreichung 260909) ist verankert; konkrete Architektur- und Verfahrensmerkmale sind in den Anmeldeunterlagen beschrieben und werden hier bis zur Veröffentlichung nur in allgemeiner Form dargestellt.

Abgrenzung

Komponente	Schicht	Abgrenzung zu GCUCB
GCEP	Persistenz (Git-to-Git)	Instanz-zu-Instanz; GCUCB = Runtime-Bus
GCSYNC	Outbound (Git -> RAG)	Externer Kanal; GCUCB = interner Bus
GCPN	Verkettungs-Logik	Nachweisketten (Vorgänger/Nachfolger); GCUCB = Transport/Zugriff

Marktkontext: „Ontology" ist nicht GCUCB

Der Markt adressiert derzeit dieselbe Grundproblematik — Agenten brauchen konsistenten, maschinenlesbaren Unternehmens-Context — unter dem Begriff „Ontology": Microsoft etwa liefert mit „Fabric IQ" (Preview) eine „governed, self-service knowledge graph" als semantische Schicht, die Agenten als „shared context layer" konsumieren (Entity types, Relationships, GQL-Graph, OneLake-Bindings). Das ist eine Daten- und Semantikschicht, keine Laufzeit-Transportarchitektur.

GCUCB greift dieselbe Problematik auf der Transport- und Zugriffsebene an: typisierte Kontextobjekte, deterministische V7GUID-Adressierung, Evidenz- und Policy-Kopplung zur Laufzeit. Die saubere Begriffstrennung ist bewusst: Eine Ontologie beschreibt, was die Begriffe bedeuten (bei GitCover: die L1–L6-Dictionaries, siehe Konzepte: Business-Hierarchie als Ontologie); GCUCB bestimmt, wie Agenten, Validatoren und Audit-Systeme zur Laufzeit darauf zugreifen. Beide Ebenen ergänzen sich — GCUCB ist kein Ontologie-Produkt, und die Ontologie braucht keinen Plattform-Graph, wenn sie Git-nativ im Repo lebt.

GCEP - GitCover Exchange Protocol

Instanz-zu-Instanz-Austauschprotokoll zwischen Git-Repos auf unterschiedlichen Trägern. Semantisch determiniert durch OSCAL-Kataloge und OPA-definierte Hooks/Callbacks.

IETF-Track geplant (I-D, Kurzform: gcep). Patentanmeldung: 10 2025 003 359.1.

Protokoll-Ebenen: ACP, MCP und GCEP

GCEP darf nicht mit den KI-Agenten-Protokollen verwechselt werden. Alle drei lösen unterschiedliche Probleme auf unterschiedlichen Ebenen:

graph TD A["Präsentations-Ebene / UI
(z. B. VS Code)"] -->|"Agent Client Protocol (ACP)"| B["Logik-Ebene / KI-Agent"] B -->|"Model Context Protocol (MCP)"| C["Infrastruktur- & Daten-Ebene"] C -->|"GitCover Exchange Protocol (GCEP)
mit Advisory Locks"| D["Verteilte Git-Server / VCS"] style A fill:#bbdefb style B fill:#c8e6c9 style C fill:#ffe0b2 style D fill:#f8bbd0

Ebene	Protokoll	Richtung	Zweck
UI-Brücke	ACP (Agent Client Protocol)	UI ↔ Agent	Verbindet Benutzeroberfläche (z. B. VS Code) mit der Agenten-Logik
KI-Kontext-Brücke	MCP (Model Context Protocol)	Agent ↔ Daten	Strukturierter Zugriff des Agenten auf Datenquellen (Dokumente, Tools)
Repository-Ebene	GCEP	Server ↔ Server	Replikation, Synchronisation und Sicherung des Zustands zwischen physischen Git-Instanzen

Die Kombination ist für das Management hochrelevant: Der Agent arbeitet über ACP/MCP in hoher Geschwindigkeit; GCEP sichert auf der darunterliegenden Repository-Ebene, dass Commit- und Synchronisationspfade konsistent bleiben.

Advisory Locks im KI-Zeitalter

Autonome KI-Agenten erzeugen Schreibzugriffe in hoher Frequenz. Ohne Sperrprotokoll auf Git-Ebene können zwei parallel agierende Agenten - oder ein Agent und ein menschlicher Sachbearbeiter - dieselben Repositories gleichzeitig modifizieren und inkonsistente Zustände erzeugen (Race Conditions).

Aspekt	Advisory Lock	Mandatory Lock
Wirkmechanismus	Prozesse prüfen den Sperrstatus freiwillig vor dem Schreiben	Betriebssystem erzwingt die Sperre hart
Verhalten bei Timeout	Agent kann strategisch reagieren: Subgoal verschieben, UI-Benachrichtigung ausgeben	Oft tote Systemzustände (Deadlocks)
Eignung für KI-Agenten	Hoch - Agent fragt Sperrstatus vorab ab (z. B. über einen MCP-Git-Server)	Gering - blockiert Agenten-Pipeline

Ein KI-Agent kann den GCEP-Sperrstatus vorab abfragen ("Ist dieses Repository für eine andere Betriebsstätte gesperrt?") und seine Planung entsprechend anpassen - statt hart zu blockieren.

GCAL - GitCover Advisory Lock

Distributed-Lock-Mechanismus zwischen Git-Repos - analog zum PostgreSQL Advisory Lock, jedoch auf Repo-Ebene. Voraussetzung für GCEP: Bevor zwei Instanzen Daten austauschen, muss ein Lock atomare Übergabe sicherstellen.

GCSYNC - GitCover Sync

Outbound-Kanal von GitCover heraus in andere Datenhaltungssysteme. Stellt Daten für RAG-Systeme, MCP-Server und Nextcloud Shares bereit.

Siehe auch: Schutzrechte und Patentstatus in Schutzrechte. Forschungsanerkennung in Forschungsvorhaben.