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, value-added tax, 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 review). Match-key fields (order number, customer, 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 cryptographic proof of integrity.
Application areas beyond accounting: GDPR records of processing activities (Art. 30), NIS2 incident chains, MADR architecture decisions, OIDC/OAuth token lifecycle, OSCAL assessment results.
GCPN Signature Container (.gcpn.md) — Process Accompaniment Instead of Individual Files
For signature processes, GCPN takes concrete form as a standalone process ur-doc: a .gcpn.md file next to the Referenced-Doc (naming convention <Referenced-Doc-Basisname>.gcpn.md) accompanies the process of creation and signing — it is not the sidecar of the Referenced-Doc, but the process container.
Essential conception:
- Mutable Doc, immutable JSON artifacts: the container MD is extended for each new process step; the already embedded JSON artifacts (schema
gcpn-container-1.0:referenced_doc,actor,retentioneach described once;eventsas a flags enum withevents_resultbitmask, e.g., 11 = offered + accepted + sign;summary) remain unchanged. - Tamper-proofing through Git: the container history (which steps were added when) is stored in the Git history of the repo — the commit hash serves as cryptographic proof of integrity.
- No JSON bloat: JSON artifacts are always embedded (MD fence) — no standalone
.jsonfiles in the repo tree. - GCDMS index function: in the optionally attached DMS, the container serves as an index — process navigation to the individual docs and to the process description, instead of n8n or similar workflow engines.
- Immutable transition: a signed Referenced-Doc becomes immutable afterwards; the container remains mutable and continues to document the process (Git history = evidence).
First use: GVB signing with facsimile signature (Part I of the Digital Signing, DS02–DS05).
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
Context bus for runtime coordination between AI agents, policy validators, and audit systems — with deterministic V7GUID addressing of the context objects. GCUCB addresses the coordination overhead problem of multi-stage agent workflows (serialization and token costs of context handover) through a typed, directly addressable bus instead of text-based intermediate layers.
OPA/Rego serves as a deterministic guardrail layer: policy checking arises from the rule set, not from prompt engineering.
The IP rights situation (utility model, DPMA filing 260909) is anchored; concrete architectural and procedural features are described in the filing documents and are presented here only in general form until publication.
Delimitation
| Component | Layer | Distinction from GCUCB |
|---|---|---|
| GCEP | Persistence (Git-to-Git) | Instance-to-instance; GCUCB = runtime bus |
| GCSYNC | Outbound (Git -> RAG) | External channel; GCUCB = internal bus |
| GCPN | Chaining logic | Evidence chains (predecessor/successor); GCUCB = transport/access |
Market context: "Ontology" is not GCUCB
The market currently addresses the same fundamental problem — agents need consistent, machine-readable enterprise context — under the term "Ontology": Microsoft, for instance, delivers with "Fabric IQ" (Preview) a "governed, self-service knowledge graph" as a semantic layer that agents consume as a "shared context layer" (Entity types, Relationships, GQL graph, OneLake bindings). This is a data and semantic layer, not a runtime transport architecture.
GCUCB tackles the same problem at the transport and access level: typed context objects, deterministic V7GUID addressing, evidence and policy coupling at runtime. The clean terminological separation is deliberate: An ontology describes what the terms mean (at GitCover: the L1–L6 dictionaries, see Concepts: Business hierarchy as ontology); GCUCB determines how agents, validators, and audit systems access it at runtime. The two levels complement each other — GCUCB is not an ontology product, and the ontology needs no platform graph when it lives Git-natively in the repo.
GCEP - GitCover Exchange Protocol
Instance-to-instance exchange protocol between Git repos on different platforms. Semantically determined by OSCAL catalogs and OPA-defined hooks/callbacks.
IETF track planned (I-D, short form: 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 access by the agent to data sources (documents, tools) |
| Repository layer | GCEP | Server ↔ Server | Replication, synchronization, and safeguarding of state between physical Git instances |
The combination is highly relevant for management: the agent works via ACP/MCP at high speed; GCEP ensures at the underlying repository layer that commit and synchronization paths remain consistent.
Advisory Locks in the AI Age
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 | The agent can react strategically: postpone a subgoal, issue a UI notification | Often dead system states (deadlocks) |
| Suitability for AI agents | High - the 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 out into other data storage systems. Provides data for RAG systems, MCP servers, and Nextcloud Shares.
See also: IP rights and patent status in IP Rights. Research recognition in Research Project.