Axis 3: Components

Overview

The GCBoK defines six core components of the GitCover stack:

GCDMS - GitCover Document Management System

Evidence and document management system for Git repositories. Storage follows the extension family .gc.*: generic sidecar <artefakt>.<orig-ext>.gc.md, process container .gcpn.md, signature artifact .gcsig.md, data artifact .gc.json. Tools: gc-dms (registry: scan, validate, pack, verify, check), gc-sidecar (sidecar generation), gc-docsign (GCSIG/signature), gc-v7guid (classes and identities).

The DMS registry is a directory, not a store: The originals remain at their storage location; for each document the registry maintains the SHA-256, the object_id and the storage_locations with provenance. The object_id is the sidecar docUid (no second identity); stored_by_pgid is the registered DMS ingest action (e.g. pgid 183), stored_by_user_id the person uuidV7. The generating action (produced_by_pgid, e.g. 180 for the invoice) is kept separately in the invoice/GCPN metadata record. Registry catalog: GCUV/TOP/compliance/process_gateways.json; normative values: OSS/TOP/.gitcover/dictionaries/gateway_ids.json.

Identities (do not confuse): docUid (instance), sha256 (content anchor), V7GUID (class) and GCPN-docUid (process) are four separate axes. Only the document docUid — from the base sidecar or, in the case of an integrated sidecar, from source.v7g_docUid in the .gcsig.md — becomes the document object_id; a GCSIG docUid remains a signature artifact (subject.sha = document SHA), a GCPN docUid remains the process. Detection is content-driven (embedded JSON schema instance), not extension-driven.

Ordering (deterministic): documents[] is sorted by sha256; storage_locations[] by source_root_id, unc_path (null last), original_path and stored_at_utc. Serialization keeps the key order stable. Temporal filters and sorting run via the uuidV7 instance docUid, not via the class V7GUID.

GCPN - GitCover PrimaNota

Metadata mechanism for forming audit-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. an entry in double-entry bookkeeping or a multi-part posting process (receivable, value-added tax, cost center/cost bearer allocation). GCPN transfers this principle to a UUIDv7 basis: Each document receives a time-ordered identifier (RFC 9562) and is chained via predecessor/successor references with its predecessor and successor documents.

Chaining is non-chronological: A document recorded later can be inserted as a predecessor (predecessor insert) into an existing chain - decisive for GoBD Rz. 80 (progressive and retrograde audit). Match-key fields (order number, debtor, gross amount, etc.) enable automatic chain association without manual assignment.

The .gc.md format separates the human-readable part at the top (title, tables, prose) from the data artifact at the bottom (JSON code fence); JSON is to be preferred over YAML as data carrier (JSON-first). The file resides 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 is concretized as a standalone process original document: 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. A separate .gcpn.md.gc.md is omitted: The container carries its own GCPN docUid and is at the same time the index of the process.

Key design:

• Mutable Doc, immutable JSON artifacts: The container MD is augmented for each new process step; the already embedded JSON artifacts (schema gcpn-container-2.7, self-contained and tree-capable: referenced_doc, actor, retention each described once; events as a flags enum with events_result bitmask and enum_ref to the immutable collection; tree via parents[]/children[]/documents[]; summary — the embedded JSON artifacts remain unchanged).
• Audit-proofness through Git: The container history (which steps were added when) is 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 .json files in the repo tree.
• GCDMS index function: In the optionally docked 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 thereafter; the container remains mutable and continues to document the process (Git history = evidence).

First use: GVB signing with facsimile signature (Part I of Digital Signing, DS02–DS05).

Utility Model Protection: File number 20 2026 000 272.7 - in force. Protected subject matter: Container data structure for UUIDv7-based, audit-proof business document management with dynamic predecessor/successor chaining. Patent application filed (47 claims).

GCUCB - GitCover Unified Context Bus

Context bus for runtime coordination between AI agents, policy validators and audit systems — with deterministic V7GUID addressing of 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 acts as a deterministic guardrail layer: policy checking arises through rules, not through prompt engineering.

The IP status (utility model, DPMA filing 260909) is anchored; concrete architecture and method features are described in the application documents and are presented here only in general form until publication.

Distinction

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 example, 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). That is a data and semantics layer, not a runtime transport architecture.

GCUCB addresses the same problem at the transport and access level: typed context objects, deterministic V7GUID addressing, evidence and policy coupling at runtime. The clean terminological distinction 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 them at runtime. Both levels complement each other — GCUCB is not an ontology product, and the ontology does not need a platform graph if it lives Git-natively in the repo.

GCEP - GitCover Exchange Protocol

Instance-to-instance exchange protocol between Git repos on different carriers. 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:

The combination is highly relevant for management: The agent works via ACP/MCP at high speed; GCEP ensures at the underlying repository level that commit and synchronization paths remain consistent.

Advisory Locks in the Age of AI

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 operator — can modify the same repositories simultaneously and create inconsistent states (race conditions).

An AI agent can query the GCEP lock status in advance (“Is this repository locked for another site?”) 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.

Actions and OPA rules are identified via uuidV7 (GCAL/GCEP join); the registered gates/policy UUIDs are in GCUV/TOP/compliance/{gates.json,policies/registry.json}. rule_text is only the display; classes/types run via V7GUID catalogs.

GCSYNC - GitCover Sync

Outbound channel from GitCover 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 Projects.