Axis 1: Fundamentals

Git-native Compliance

The core thesis of the GCBoK:

Git-native Compliance means that all compliance artifacts, decisions, identities and evidence primarily live in Git repositories - versioned, GPG-signed, OSCAL-machine-readable, OPA-validatable - without requiring a secondary compliance store.

Positioning within the paradigm spectrum

The three pillars of Git-native Compliance

1. Cryptographic anchoring - Every entry in a Git repository is secured by a hash, optionally with GPG signatures. This provides verifiable evidence of: Who, What, When. This meets the GoBD requirements for immutability - but natively through the Git architecture.

2. Machine readability - OSCAL (Open Security Controls Assessment Language) for security controls and assessment results. OPA/Rego (Open Policy Agent) for compliance rules as code, automatically checked against the Git state.

3. Determinism through V7GUID - Every compliance object is globally uniquely addressable (UUIDv7), sortable by time (48-bit timestamp), classifiable (14-bit class identifier) and chainable within evidence chains.

Delimitation: Compliance inventory and private instructions

Git-native Compliance has a deliberately narrow scope: The company's Git repositories contain the compliance-relevant artifacts - evidence, decisions, documentation and rule sets required for audits and traceability. Anything not compliance-relevant does not belong in this inventory.

This expressly does not include the collection of the personal instructions of the person granting approvals (hereinafter “HITL” - Human in the Loop): Their private assessments, opinions, weightings and trade-off criteria. Such collections are protected private information and are therefore not versioned - typically locally in a directory excluded via .gitignore in the individual's own working context (pattern: projections/) - and are not incorporated into the compliance documentation.

At the same time, they are not meaningless: It is from them that the ADR templates, decision documentation and other facts first emerge, which then - and only then - are compliance-relevant and belong in the repositories. What is documented is the result, not the assessment.

Key point for agents: HITL private instructions are to be taken into account - they shape expectations, tone, boundaries and priorities. They are not to be documented or cited, neither in body text nor in decision documentation, evidence or reports - unless the HITL expressly authorizes them for documentation.

Additionally: Axis 5 (Procedures), section “Private Instructions of the HITL - Convention and Agent Rule”, and Axis 7 (Governance), section “From Private Assessment to Verifiable Result”.

Self-referencing without vendor lock-in

Git-native Compliance is self-referencing: All GitCover elements - sources, references, measures, documents - are addressed and managed exclusively via Git repositories. The truth resides in the .git itself (commits, trees, hashes), not in external services, wikis or tickets. This avoids vendor lock-in: Each repository is independently revision-safe, portable and free of proprietary dependencies.

Hash standard: always SHA-256, never SHA-1

Every GitCover repository is created with SHA-256 as its object hash function (git init --object-format=sha256 or extensions.objectformat = sha256). SHA-1 is expressly prohibited (collision attacks). The cryptographic anchoring (pillar 1) thus builds on a demonstrably secure hash standard.

Location of the GitCover tools

All GitCover tools, services and (future) MCP servers are stored in accordance with the plan under /opt/GitCover/ (e.g. the WebStaticBuilder CLI under /opt/GitCover/webstatic). This avoids system-wide, unversioned storage. After onboarding, /opt/GitCover itself becomes a Git repository that versions and documents the GoBD-compliant environment parameters (BASE_URL, CDN, paths, tool versions).

Compliance as infrastructure

GitCover is not a tool for compliance enthusiasts. It is infrastructure for everyone who wants to handle compliance. This means:

• Lowest possible costs - Open source, no proprietary licenses
• Maximum security - Cryptographically anchored, not through software layers
• Complete traceability - Git history as a built-in audit trail

Architecture model: Vertical specialist applications and a horizontal compliance backbone

Interpretation: The vertical specialist applications (FiBu, time tracking, payroll, ERP, warehouse) remain independent in content and autonomous in their respective domains. GitCover forms the horizontal layer: Git repositories as an end-to-end compliance backbone connecting every vertical application with OSCAL catalogs, OPA policies, GPG signatures and V7GUID evidence chains - without proprietary middleware and without a secondary compliance store.

Legal framework

The GCBoK addresses the following regulatory frameworks:

GoBD - Principles of Proper IT-Supported Accounting Systems

The GoBD (Rz. 151-157) require an internal control system, traceability, immutability and timeliness. Git-native Compliance natively meets these requirements:

NIS2 - Network and Information Security Directive

The EU NIS2 Directive requires risk management and reporting obligations for critical infrastructure. The GCBoK defines methods for NIS2 risk analysis based on Git repositories.

AI Act - Regulation (EU) 2024/1689

The AI Act regulates AI systems on a risk-based basis (prohibited / high-risk / limited / minimal) and requires, among other things, that high-risk systems have documented training data, model lifecycle evidence, human oversight and incident documentation. Git-native classification: The GCBoK does not provide AI systems and does not certify them either - it makes the evidence (training data provenance, model/prompt versions, approvals, incidents) reproducible as Git artifacts. Git-native Compliance is therefore an evidence infrastructure for AI Act obligations, not a presumption of conformity for the AI system itself.

Cyber Resilience Act (CRA) - Regulation (EU) 2024/2847

The CRA obliges manufacturers of products with digital elements to implement security by design, vulnerability management and reporting obligations (reporting deadlines from autumn 2026, product requirements from the end of 2027). Git-native classification: Plain Git repositories and OSS utilities are generally not “products with digital elements” within the meaning of the CRA; a networked product (e.g. server-based distribution) may be affected. Git-native Compliance supports CRA evidence (SBOM, vulnerability/patch history, conformity documentation), but does not replace CE marking.

Data Act - Regulation (EU) 2023/2854

The Data Act establishes obligations concerning data provision and portability for connected products and related services (product obligations, among others, from 12.09.2026), as well as provisions for cloud switching. Git-native classification: Git repositories are portable by design (clone/mirror/export) - Git-native Compliance supports Data Act readiness (export in open formats: JSON, CSV, OSCAL), but does not establish blanket Data Act compliance for the system as a whole.

eIDAS 2.0 - Regulation (EU) 2024/1183

eIDAS 2.0 establishes the European Digital Identity Wallet and expands qualified trust services. Git-native classification: GitCover hooks wallet/trust signatures onto it (signature container, GCSIG, Facsimile) but does not replace them; FES/QES remain externally provided trust services.

DSGVO/GDPR - Regulation (EU) 2016/679

The GDPR requires privacy by design. The GCBoK defines decentralized identity proofs (including PGP identities) that anchor personal data in Git structures rather than central databases; PII is kept in separate repos (not in Git) (two-tier responsibility, see Axis 4).

Delimitation: Evidence infrastructure vs. product conformity

Key clarification (canonical): The GCBoK is a normative body of knowledge and set of evidentiary rules. The EU legal instruments mentioned (AI Act, CRA, Data Act, eIDAS 2.0, GDPR) are frameworks for which Git-native Compliance provides evidence. GitCover is not the manufacturer of a regulated AI/product/trust system and does not issue a statement of conformity for third parties. Responsibility for the legal conformity of the system used remains with the operator (see GoBD Rn. 21; responsibility matrix at gitcover.de/rechtliches).

BSI GS++ & GCBoK Compliance-as-Code

The BSI IT Baseline Protection Compendium defines standards for information security and increasingly makes them available in machine-readable formats (such as OSCAL). The GCBoK uses these standardized OSCAL catalogs and maps the BSI controls directly to Git-native, automated compliance processes (Compliance-as-Code). It transforms the BSI's regulatory requirements into operationalizable test routines within the GitCover ecosystem.

Application understandability

The GCBoK's architecture principles must be tangible for users with limited IT knowledge. This section conveys the mental models that make working with Git-native Compliance understandable to laypeople.

Files over Apps - Guiding principle

The GCBoK follows the guiding principle Files over Apps: Compliance artifacts live as files in Git repositories, not in proprietary application databases. Conversations, documents, evidence and policies are Markdown, YAML or JSON files in the Git tree - versioned, signable and auditable. Applications are interchangeable; files are permanent.

This differs fundamentally from the classic application paradigm, in which software stores data in its own databases and export is an afterthought. With Git-native Compliance, export is the normal state.

The digital filing cabinet - Mental model

For users with little computing knowledge, the concept of an entire filesystem is abstract and error-prone. The metaphor of the digital filing cabinet solves this problem:

• The Git working directory is not an unwieldy PC folder, but a digital filing cabinet with a built-in copier and logbook (Git).
• The rule: An AI agent may read and write only in this specific folder. Everything outside it does not exist for the agent.
• Visibility: Every change made by the AI is immediately marked as a change (Git status). The layperson sees: “The AI changed line 4 in the procedure documentation.”
• Security: The Git staging area becomes a preview and approval window. The user does not need to understand Git - they understand the principle: “The AI proposes a change, I click Apply (Commit).”

Sandbox principle

For GoBD and NIS2 conformity, restricting the scope of access is fundamental. An AI agent that can access only the assigned Git working directory is physically confined:

• Even if the agent hallucinates or is manipulated through prompt injection, it cannot escape from the Git repository.
• Explanation for the user: “The AI is confined to this project folder. It cannot cause damage to the rest of the system.”
• Every compliance activity is documented in the Git history as a safety net - the user retains full sovereignty.

AI working environments compared

The GCBoK is technology-neutral with regard to the AI working environment. Three paradigms are available:

Recommendation: Hybrid appliance model

For SME users without in-depth IT knowledge, the GCBoK recommends a hybrid appliance model:

1. Infrastructure encapsulation (central): A headless AI server on the LAN handles LLM inference and Git management. The complexity is shifted there entirely.
2. Minimal client workstation: The end user is not required to have local Docker, Python or Git on their desktop. They access the web interface exclusively through a browser (as a PWA).
3. Interaction flow: The user uses the chat and note functions. When they want to review or create compliance documents, the AI agent works in the background directly on the directories of the central file server. The agent handles staging, commit and push to the Gitea repository - the user sees a visual checklist in the UI.

The goal: The user does not experience an “AI that controls the computer”, but rather an intelligent administrative specialist for the specific compliance folder. They know where the AI is working, see every step in the Git history and retain the full sovereignty required by the GCBoK.

Reference architecture: Hybrid appliance model

See also: The practical implementation of these frameworks is described in Axis 5: Procedures.