Axis 3: Components
Overview
The GCBoK defines six core components of the GitCover stack:
GCDMS - GitCover Document Management System
Evidence and document management system based on .v7g.md containers and metadata. Toolchain: v7g-pack, v7g-verify, v7g-sign, v7g-export.
GCPN - GitCover PrimaNota
Metadata mechanism for creating tamper-proof evidence chains (predecessor/successor) for business documents. The historical term PrimaNota denotes an ordering key that assigns a unique key for association to a business transaction - e.g., a journal entry of double-entry bookkeeping or a multi-part posting process (receivable, VAT, cost center/cost object allocation). GCPN transfers this principle to a UUIDv7 basis: Each document receives a time-ordered identifier (RFC 9562) and is chained to its predecessor and successor documents via Predecessor/Successor references.
The chaining is non-chronological: A document recorded later can be inserted as a predecessor (Predecessor-Insert) into an existing chain - crucial for GoBD Rz. 80 (progressive and retrograde examination). Match-key fields (order number, debtor, gross amount, etc.) enable automatic chain association without manual assignment.
The .v7g.md container format combines human-readable metadata (YAML + Markdown) with machine-processable business data (embedded JSON) and is stored in Git repositories whose commit hash serves as a cryptographic integrity proof.
Application areas beyond accounting: GDPR records of processing activities (Art. 30), NIS2 incident chains, MADR architecture decisions, OIDC/OAuth token lifecycle, OSCAL assessment results.
Utility model protection: File no. 20 2026 000 272.7 - in force. Protected subject matter: Container data structure for UUIDv7-based, tamper-proof business document management with dynamic Predecessor/Successor chaining. Patent application filed (47 claims).
GCUCB - GitCover Unified Communication Bus
Shared-memory-based context bus with deterministic V7GUID addressing. Central data hub between AI agents, OPA validators, and audit systems.
The Overhead Problem
| Source | Finding |
|---|---|
| RMMAP (EuroSys 2024) | Serialization = 17-72% of workflow time |
| AgentTaxo (ICLR 2025) | 20-60% of tokens = coordination overhead |
| AgentDiet (arXiv 2025) | 39.9-59.7% of input tokens are useless |
The Solution
GCUCB eliminates repeated serialization/deserialization through typed direct access to memory-mapped file regions. AI agents receive typed, V7GUID-referenced structs directly from the bus - without huge system prompts.
OPA/Rego acts as a VPRM (Verifiable Process Reward Model): Guardrails are created by a deterministic rule set, not by prompt engineering.
Distinction
| Component | Layer | Distinction from GCUCB |
|---|---|---|
| GCEP | Persistence (Git-to-Git) | Instance-to-instance; GCUCB = runtime memory bus |
| GCSYNC | Outbound (Git -> RAG) | External channel; GCUCB = internal bus |
| GCPN | Chaining logic | Evidence chains (predecessor/successor); GCUCB = transport/access |
GCEP - GitCover Exchange Protocol
Instance-to-instance exchange protocol between Git repos on different media. Semantically determined by OSCAL catalogs and OPA-defined hooks/callbacks.
IETF track planned (I-D, short name: gcep). Patent application: 10 2025 003 359.1.
Protocol Layers: ACP, MCP and GCEP
GCEP must not be confused with the AI agent protocols. All three solve different problems at different layers:
(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
| Layer | Protocol | Direction | Purpose |
|---|---|---|---|
| UI bridge | ACP (Agent Client Protocol) | UI ↔ Agent | Connects the user interface (e.g., VS Code) with the agent logic |
| AI context bridge | MCP (Model Context Protocol) | Agent ↔ Data | Structured agent access to data sources (documents, tools) |
| Repository layer | GCEP | Server ↔ Server | Replication, synchronization, and securing of state between physical Git instances |
The combination is highly relevant for management: The agent works at high speed via ACP/MCP; GCEP ensures at the underlying repository layer that commit and synchronization paths remain consistent.
Advisory Locks in the AI Era
Autonomous AI agents generate write accesses at high frequency. Without a locking protocol at the Git level, two agents acting in parallel - or an agent and a human clerk - can modify the same repositories simultaneously and produce inconsistent states (Race Conditions).
| Aspect | Advisory Lock | Mandatory Lock |
|---|---|---|
| Mechanism | Processes check the lock status voluntarily before writing | The operating system enforces the lock forcibly |
| Behavior on timeout | Agent can react strategically: postpone a subgoal, issue a UI notification | Often dead system states (deadlocks) |
| Suitability for AI agents | High - agent queries the lock status in advance (e.g., via an MCP Git server) | Low - blocks the agent pipeline |
An AI agent can query the GCEP lock status in advance ("Is this repository locked for another place of business?") and adjust its planning accordingly - instead of blocking hard.
GCAL - GitCover Advisory Lock
Distributed lock mechanism between Git repos - analogous to the PostgreSQL advisory lock, but at the repo level. Prerequisite for GCEP: Before two instances exchange data, a lock must ensure atomic handover.
GCSYNC - GitCover Sync
Outbound channel from GitCover into other data storage systems. Provides data for RAG systems, MCP servers, and Nextcloud Shares.
See also: Property rights and patent status in Property Rights. Research recognition in Research Project.