Axis 1: Fundamentals

Git-native Compliance

The core thesis of the GCBoK:

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

Positioning in 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 makes it provable: Who, What, When. This corresponds to the GoBD requirements for immutability - however, 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), chronologically sortable (48-bit timestamp), classifiable (14-bit class identifier) and chainable in voucher chains.

Self-Referencing without Vendor Lock-In

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

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

Every GitCover repository is created with SHA-256 as the 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 verifiably secure hash standard.

Location of the GitCover Tools

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

Compliance as Infrastructure

GitCover is not a tool for compliance enthusiasts. It is infrastructure for everyone who wants to get compliance done. 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 Business Applications and Horizontal Compliance Backbone

How to read it: The vertical business applications (financial accounting, time tracking, payroll, ERP, warehouse) remain independent in content and autonomous in their respective domains. GitCover forms the horizontal layer: Git repositories as a continuous compliance backbone that connects every vertical app with OSCAL catalogs, OPA policies, GPG signatures and V7GUID voucher 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 fulfills these requirements natively:

NIS2 - Network and Information Security Directive

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

BSI GS++ & GCBoK Compliance-as-Code

The BSI IT-Grundschutz Compendium defines standards for information security and increasingly provides them in machine-readable formats (such as OSCAL). The GCBoK uses these standardized OSCAL catalogs and maps the BSI controls directly onto Git-native, automated compliance processes (Compliance-as-Code). It transforms the regulatory requirements of the BSI into operationalizable audit routines within the GitCover ecosystem.

GDPR - General Data Protection Regulation

The GDPR requires Privacy by Design. The GCBoK defines decentralized identity credentials (also PGP identities) that anchor personal data not in central databases but in Git structures.

Application Understanding

The architecture principles of the GCBoK must be graspable for users with limited IT knowledge. This section conveys the mental models that make working with Git-native Compliance understandable for laypersons.

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, vouchers and policies are Markdown, YAML or JSON files in the Git tree - versioned, signable, auditable. Applications are interchangeable; files are permanent.

This differs fundamentally from the classic application paradigm, in which software keeps the data in its own databases and export is a subsequent necessity. With Git-native Compliance, export is the normal state.

The Digital File Folder - Mental Model

For users with little computer knowledge, the concept of an entire file system is abstract and error-prone. The metaphor of the digital file folder solves this problem:

• The Git working directory is not a confusing PC folder, but a digital file folder with a built-in photocopier and logbook (Git).
• The rule: An AI agent may only read and write in this specific folder. Everything outside does not exist for it.
• The visibility: Every change the AI makes is immediately marked as a change (Git status). The layperson sees: "The AI changed line 4 in the process documentation."
• The safety: The Git staging area becomes the preview and approval window. The user does not need to understand Git - they understand the principle: "The AI suggests a change, I click Apply (Commit)."

Sandbox Principle

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

• Even if the agent hallucinates or is manipulated via prompt injection, it cannot break out of the Git repository.
• The explanation for the user: "The AI is locked in this project folder. It cannot cause any damage in 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 in Comparison

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

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 in the LAN handles LLM inference and Git management. The complexity is shifted entirely there.
2. Minimal client workstation: The end user is not burdened with local Docker, Python or Git on their desktop. They access the web interface exclusively via the browser (as a PWA).
3. Interaction flow: The user uses 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 controlling the computer", but rather an intelligent case worker for the specific compliance folder. They know where the AI is working, see every step in the Git history and retain the full sovereignty that the GCBoK requires.

Reference Architecture: Hybrid Appliance Model

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