Research Project: GitCover.IdP
Official Recognition
The research project "Git-native Compliance for SMEs: Experimental Development of an Integrated Identity and Compliance Management System with a Taxonomic Identifier System (V7GUID)" has been recognized by the DLR Projektträger / BSFZ under § 6 FZulG as an eligible R&D project.
| Attribute | Value |
|---|---|
| Reference number | 288-335-338/2026-1 |
| Notice (positive) | 22.04.2026 |
| Type of research | In-house experimental development |
| Duration | 01.01.2025 - 31.12.2026 |
| Certification body | BSFZ at the DLR Projektträger, Bonn |
Research Content
Investigation of whether Gitea-based Git repositories can serve as a Single Source of Truth (SSOT) for an integrated identity and compliance management system for SMEs.
Core Hypotheses
| ID | Hypothesis | Research Risk |
|---|---|---|
| H1 | Git organizations can represent OAuth2 clients and permissions and manage >1,000 users | No reference implementation for >100k objects known |
| H2 | End-to-end policy-compliance chain: OPA-Rego -> OSCAL-Assessment-Results -> evidence | Mapping hierarchical permissions onto flat Rego policies is complex |
| H3 | Deterministic Git structures as containment vessel for autonomous AI agents | No reliable standards for deterministic AI containment |
Novelty Features
| ID | Feature | Reference |
|---|---|---|
| N1 | V7GUID Dual-Identifier: Integration of taxonomy into UUIDv7 | Patent application 10 2025 003 091.6 |
| N2 | AI Guard-Rails: Cryptographic Git chains for taming autonomous agents | GCUCB; VPRM concept |
| N3 | GCEP protocol: Advisory locks and bundle signing for multi-repo sync | Patent application 10 2025 003 359.1 |
BSFZ Research Questions F1-F5 (Frascati-qualified)
| # | Research Question | Uncertainty |
|---|---|---|
| F1 | V7GUID lookup O(1) with >10^6 objects in shared memory? | Hash collisions, NUMA effects |
| F2 | NativeAOT code from OSCAL/OPA-YAML binary-compatible with memory layout? | Schema evolution |
| F3 | Does a typed bus improve LLM result quality vs. JSON text? | No benchmark exists |
| F4 | Is cross-container shared memory compatible with GoBD? | Mutability vs. audit |
| F5 | Can energy consumption per compliance workflow be measurably reduced? | Metrics lacking |
Relevance for GCBoK
The BSFZ-recognized research project demonstrates the scientific-technical novelty of the GitCover core architecture from the perspective of the authorities and strengthens the normative authority of the GCBoK:
- V7GUID as a patented identification system (N1)
- GCEP/GCAL as a lock coordination mechanism (N3)
- AI Guard-Rails via deterministic Git structures (N2)
This triple confirmation (patent application + BSFZ certificate + utility model) is the empirical basis for the GCBoK's claim to position itself as a normative conceptual authority.
MADR Relevance Beyond GoBD
MADRs (Markdown Any Decision Records) are maintained in the GCBoK primarily as GoBD-compliant procedural documentation (§ 146, § 147 AO). However, the R&D finding of 21.08.2026 shows: MADRs are not GoBD-exclusive. In numerous adjacent standards and regulations, decision and control statuses are defined with their own, partly contradictory enums or kind values for "status".
Status Vocabulary in OSCAL and Regulations
| Source | Status enum / kind value |
Context |
|---|---|---|
OSCAL implementation-status |
implemented \| partial \| planned \| alternative \| not-applicable |
NIST SP 800-53 / 800-53A Control-Implementation |
| NIST Catalog | operational \| under-development |
Control state in catalogs |
| BSI IT-Grundschutz | entbehrlich \| bedingt entbehrlich \| umzusetzen \| erfüllt |
Module requirements |
| ISO 27001 Annex A | applicable \| not-applicable (+ Statement of Applicability) |
Measures plan |
| GDPR | implemented \| planned (TOM status) |
Art. 32 Technical and Organisational Measures |
| ISO 15489 | active \| superseded \| deprecated |
Records lifecycle |
| PCI-DSS | in-place \| not-in-place \| not-applicable |
Control status |
Finding: The obsolescence vocabulary used here (
active | superseded | deprecated | obsolete | review_required) covers only the post-active lifecycle. A status beforeactive(not yet decided, blocked, under consideration) is not captured anywhere.
Extended Lifecycle (pre-active statuses)
To represent considerations ("we need more information/funds/community to decide"), the vocabulary is extended by four pre-active statuses:
needs_info / needs_funds /
needs_community / needs_decision"] D -->|nein| F[active] E -->|Blocker aufgelöst| F F --> G[review_required] G --> H[deprecated] H --> I["superseded / obsolete"]
| Pre-active Status | Meaning |
|---|---|
planned |
Planned, not yet in progress |
in_consideration |
Under consideration / technical review in progress |
decision_pending |
Decision pending (e.g., awaiting GVB/FA decision) |
blocked |
Blocked; blocked_reason: needs_info \| needs_funds \| needs_community \| needs_decision |
Mapping Rule for GCBoK
When adopting foreign status vocabularies (OSCAL, NIST, BSI, ISO, GDPR, PCI-DSS) into the GCBoK taxonomy, the following applies:
- Foreign "planned/not-applicable/entbehrlich" values → map to
planned/in_consideration(pre-active). - Foreign "implemented/operational/erfüllt/in-place" values → map to
active. - Foreign "partial/under-development/bedingt entbehrlich" values → map to
decision_pendingorreview_required(depending on maturity level). - Foreign "alternative/not-applicable" values → context-dependent:
superseded(if replaced) ordeprecated(if rejected).
This mapping ensures GoBD auditability (§ 147 Abs. 6 AO, Z3 access) without losing the foreign OSCAL/regulatory vocabularies — a central contribution of GCBoK research to interoperable compliance documentation.
Phase 2 - AI Safety Research (from 2026)
From 2026 onwards, the focus expands to the safety of AI infrastructures. The research thesis: Deterministic Git structures (V7GUID) can serve as physical Guard Rails for autonomous AI agents - instead of stochastic, injectable prompts.
Delimitation from the Previous Project
| Dimension | Previous Project (2025–2026) | New Project (from 2026/2027) |
|---|---|---|
| Subject matter | Identity management, IdP, PGP/V7GUID, GPG keyring long-term verifiability, GoBD/GDPR | AI governance, guardrails instead of prompts, MCP agent |
| Technical uncertainty | Context manipulation of identity | Determinism vs. stochasticity of AI control; prompt injection resistance via Git gate |
| Module in the GCBoK | Identity & compliance core | Tooling & guardrail layer (GCUCB) |
| Reference framework | ISO/IEC 24773 | OWASP LLM Top 10, Harness Engineering, MCP |
The substantive shift from the topic of "Gitea as IdP" to "Git repos as AI guardrails instead of prompts" via GCUCB requires a separate BSFZ certificate as a new research project. The delimitation at work package level ensures that both projects remain cleanly separated and that the research allowance recognition is not jeopardized.
Research Questions (Phase 2)
- Determinism vs. stochasticity: To what extent can the control of an AI agent be deterministically captured by a versioned Git guardrail repo, so that deviations from the policy are detected at build time (not only at prompt time)?
- Prompt injection resistance: To what extent does a Git-native guardrail layer (signed, immutable, enforced via Git hook/OPA) protect against the "lethal trifecta" (private data + untrusted content + exfiltration)?
- MCP as policy enforcement point: Can an MCP server with a UI resource and iframe UI act as a policy gate that exposes only approved (signed) tools/contexts?
- Auditability: Can the Git commit history of the guardrail repo be used as a GoBD-compliant audit trail for AI decisions?
Note: The research and prototype developments by AFJD (Axel Franz Johann Druschel) are carried out in-house outside of GCC working hours. The IP remains with AFJD; the GCC is granted use on a contractual basis. This separation safeguards the non-profit status of the GCC (no concealed commercial business operation).
See also: FZulG applications and financial planning on the GCC landing page.