Achse 3: Komponenten

Überblick

Das GCBoK definiert sechs Kernkomponenten des GitCover-Stacks:

GCDMS - GitCover Document Management System

Evidenz- und Dokumentenmanagementsystem für Git-Repositories. Die Ablage folgt der Extension-Familie .gc.*: generischer Sidecar <artefakt>.<orig-ext>.gc.md, Vorgangs-Container .gcpn.md, Signatur-Artefakt .gcsig.md, Datenartefakt .gc.json. Werkzeuge: gc-dms (Registry: scan, validate, pack, verify, check), gc-sidecar (Sidecar-Erzeugung), gc-docsign (GCSIG/Signatur), gc-v7guid (Klassen und Identitäten).

Die DMS-Registry ist ein Verzeichnis, kein Speicher: Die Originale bleiben an ihrem Ablageort; die Registry führt je Dokument den SHA-256, den object_id und die storage_locations mit Provenienz. Der object_id ist die Sidecar-docUid (keine zweite Identität); stored_by_pgid ist die registrierte DMS-Ingest-Action (z. B. pgid 183), stored_by_user_id die Person-uuidV7. Die erzeugende Action (produced_by_pgid, z. B. 180 für die Rechnung) steht getrennt im Rechnungs-/GCPN-Metadatensatz. Registry-Katalog: GCUV/TOP/compliance/process_gateways.json; normative Werte: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

Identitäten (nicht verwechseln): docUid (Instanz), sha256 (Inhalts-Anker), V7GUID (Klasse) und GCPN-docUid (Vorgang) sind vier getrennte Achsen. Nur die Dokument-docUid — aus dem Basis-Sidecar oder bei integriertem Sidecar aus source.v7g_docUid im .gcsig.md — wird Dokument-object_id; eine GCSIG-docUid bleibt Signatur-Artefakt (subject.sha = Dokument-SHA), eine GCPN-docUid bleibt Vorgang. Die Erkennung ist inhaltsgetrieben (eingebettete JSON-Schema-Instanz), nicht endungsgetrieben.

Ordnung (deterministisch): documents[] wird nach sha256 sortiert; storage_locations[] nach source_root_id, unc_path (null zuletzt), original_path und stored_at_utc. Die Serialisierung hält die Schlüsselreihenfolge stabil. Zeitliche Filter und Sortierung laufen über die uuidV7-Instanz-docUid, nicht über die Klassen-V7GUID.

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 Format .gc.md trennt menschenlesbaren Teil oben (Titel, Tabellen, Prosa) vom Daten-Artefakt unten (JSON-Code-Fence); JSON ist dem YAML als Daten-Träger vorzuziehen (JSON-First). Die Datei liegt in Git-Repositories, 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. Ein separates .gcpn.md.gc.md entfällt: Der Container trägt seine eigene GCPN-docUid und ist zugleich der Index des Vorgangs.

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-2.7, self-contained und Tree-fähig: referenced_doc, actor, retention je einmal beschrieben; events als Flags-Enum mit events_result-Bitmask und enum_ref auf die Immutable-Collection; Tree über parents[]/children[]/documents[]; summary — die eingebetteten JSON-Artefakte 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 Context 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.

Actions und OPA-Regeln sind über uuidV7 identifiziert (GCAL-/GCEP-Join); die registrierten Gates/Policy-UUIDs liegen in GCUV/TOP/compliance/{gates.json,policies/registry.json}. rule_text ist nur die Anzeige; Klassen/Typen laufen über V7GUID-Kataloge.

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.