Axis 1: Fundamentals

Git-native Compliance

The core thesis of 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.

Classification 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 provably establishes: 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 validated against the Git state.

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

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 lives in the .git itself (commits, trees, hashes), not in external services, wikis, or tickets. This avoids vendor lock-in: every repository is, by itself, revision-proof, 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 explicitly forbidden (collision attacks). Cryptographic anchoring (pillar 1) thus builds on a provably secure hash standard.

Location of the GitCover Tools

All GitCover tools, services, and (in future) MCP servers are placed, plan-conform, 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 versioned-documents the GoBD-conform 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 get compliance done. This means:

• Lowest possible cost — Open Source, no proprietary licenses
• Maximum security — Cryptographically anchored, not through software layers
• Complete verifiability — Git history as a built-in audit trail

Architecture Model: Vertical Specialized Applications and Horizontal Compliance Backbone

Reading: The vertical specialized applications (financial accounting, time tracking, payroll, ERP, warehouse) remain content-independent and functionally autonomous. GitCover forms the horizontal layer: Git repositories as an end-to-end compliance backbone connecting every vertical app with OSCAL catalogs, OPA policies, GPG signatures, and V7GUID evidence chains — without proprietary middleware and without a secondary compliance store.

Legal Framework

GCBoK addresses the following regulatory frameworks:

GoBD — Principles of proper computerized accounting systems (GoBD)

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

NIS2 — Network and Information Security Directive

The EU NIS2 Directive requires risk management and reporting obligations for critical infrastructures. 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). GCBoK utilizes these standardized OSCAL catalogs and maps BSI controls directly to Git-native, automated compliance processes (Compliance-as-Code). It transforms the BSI's regulatory requirements into operable validation routines within the GitCover ecosystem.

GDPR — General Data Protection Regulation

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

Application Understanding

The architectural principles of GCBoK must be tangible 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

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, auditable. Applications are replaceable; files are durable.

This differs fundamentally from the classical application paradigm, where software holds 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 copier and logbook (Git).
• The rule: An AI agent may only read and write in this specific folder. Everything outside does not exist for it.
• Visibility: Every change the AI makes 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 the preview and approval window. The user does not need to understand Git — they understand the principle: "The AI proposes a change, I click Accept (Commit)."

Sandbox Principle

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

• Even if the agent hallucinates or is manipulated through 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 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 Work Environments in Comparison

GCBoK is technology-neutral regarding the AI work environment. Three paradigms are available:

Recommendation: Hybrid Appliance Model

For SME users without deep IT knowledge, 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 fully shifted 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 browser (as PWA).
3. Interaction flow: The user uses chat and note functions. When they want to check or generate compliance documents, the AI agent works in the background directly on the central file server's directories. 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 "AI that controls the computer," but an intelligent case worker for the specific compliance folder. They know where the AI works, see every step in the Git history, and retain the full sovereignty that GCBoK demands.

Reference Architecture: Hybrid Appliance Model

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