GitCover Symbol GCBoKGitCover Body of Knowledge

Forschungsvorhaben: GitCover.IdP

Behördliche Anerkennung

Das Forschungsvorhaben "Git-native Compliance für KMU: Experimentelle Entwicklung eines integrierten Identity- und Compliance-Management-Systems mit taxonomischem Identifier-System (V7GUID)" wurde vom DLR Projektträger / BSFZ nach § 6 FZulG als förderfähiges FuE-Vorhaben anerkannt.

Attribut Wert
Vorgangsnummer 288-335-338/2026-1
Bescheid (positiv) 22.04.2026
Forschungsart Eigenbetriebliche experimentelle Entwicklung
Laufzeit 01.01.2025 - 31.12.2026
Bescheinigungsstelle BSFZ beim DLR Projektträger, Bonn

Forschungsinhalt

Untersuchung, ob Gitea-basierte Git-Repositories als Single Source of Truth (SSOT) für ein integriertes Identity- und Compliance-Management-System für KMU dienen können.

Kern-Hypothesen

ID Hypothese Forschungsrisiko
H1 Git-Organisationen können OAuth2-Clients und Permissions abbilden und >1.000 Benutzer verwalten Keine Referenzimplementierung für >100k Objekte bekannt
H2 Durchgängige Policy-Compliance-Kette: OPA-Rego -> OSCAL-Assessment-Results -> Nachweise Hierarchische Berechtigungen auf flache Rego-Policies komplex
H3 Deterministische Git-Strukturen als Containment-Vessel für autonome KI-Agenten Keine verlässlichen Standards für deterministisches AI Containment

Neuartigkeitsmerkmale

ID Merkmal Bezug
N1 V7GUID Dual-Identifier: Integration von Taxonomie in UUIDv7 Patentanmeldung 10 2025 003 091.6
N2 AI Guard-Rails: Kryptographische Git-Ketten zur Zahmung autonomer Agenten GCUCB; VPRM-Konzept
N3 GCEP-Protokoll: Advisory Locks und Bundle-Signierung für Multi-Repo-Sync Patentanmeldung 10 2025 003 359.1

BSFZ Forschungsfragen F1-F5 (Frascati-qualifiziert)

# Forschungsfrage Unsicherheit
F1 V7GUID-Lookup O(1) bei >10^6 Objekten im Shared Memory? Hash-Kollisionen, NUMA-Effekte
F2 NativeAOT-Code aus OSCAL/OPA-YAML binarkompatibel mit Memory-Layout? Schema-Evolution
F3 Typisierter Bus verbessert LLM-Ergebnisqualität vs. JSON-Text? Kein Benchmark existiert
F4 Cross-Container Shared Memory vereinbar mit GoBD? Mutabilität vs. Audit
F5 Energieverbrauch pro Compliance-Workflow messbar reduzierbar? Metriken fehlen

Relevanz für GCBoK

Das BSFZ-anerkannte Forschungsvorhaben belegt die wissenschaftlich-technische Neuartigkeit der GitCover-Kernarchitektur aus behördlicher Perspektive und stärkt die normative Autorität des GCBoK:

  1. V7GUID als patentiertes Identifikationssystem (N1)
  2. GCEP/GCAL als Lock-Koordinationsmechanismus (N3)
  3. AI Guard-Rails via deterministische Git-Strukturen (N2)

Diese dreifache Bestätigung (Patentanmeldung + BSFZ-Bescheinigung + Gebrauchsmuster) ist die empirische Grundlage für den GCBoK-Anspruch auf Positionierung als normative Begriffsautorität.

MADR-Relevanz über GoBD hinaus

MADRs (Markdown Any Decision Records) werden im GCBoK primär als GoBD-konforme Verfahrensdokumentation (§ 146, § 147 AO) geführt. Die F&E-Erkenntnis vom 21.08.2026 zeigt jedoch: MADRs sind nicht GoBD-exklusiv. In zahlreichen angrenzenden Standardwerken und Regularien werden Entscheidungs- und Kontrollstatus mit eigenen, teils widersprüchlichen Enums bzw. kind-Werten für "Status" definiert.

Status-Vokabular in OSCAL und Regularien

Quelle Status-Enum / kind-Wert Kontext
OSCAL implementation-status implemented \| partial \| planned \| alternative \| not-applicable NIST SP 800-53 / 800-53A Control-Implementation
NIST-Katalog operational \| under-development Control-State in Katalogen
BSI IT-Grundschutz entbehrlich \| bedingt entbehrlich \| umzusetzen \| erfüllt Baustein-Anforderungen
ISO 27001 Annex A applicable \| not-applicable (+ Statement of Applicability) Maßnahmenplan
DS-GVO implemented \| planned (TOM-Status) Art. 32 Technische Org.-Maßnahmen
ISO 15489 active \| superseded \| deprecated Records-Lifecycle
PCI-DSS in-place \| not-in-place \| not-applicable Control-Status

Erkenntnis: Die hiesige Obsoleszenz-Vokabel (active | superseded | deprecated | obsolete | review_required) deckt ausschließlich den post-aktiven Lebenszyklus ab. Ein Status vor active (noch nicht entschieden, blockiert, in Erwägung) ist nirgends erfasst.

Erweiterter Lifecycle (pre-active Stati)

Um Überlegungen ("we need more information/funds/community to decide") abzubilden, wird die Vokabel um vier pre-active Stati ergänzt:

flowchart TD A[planned] --> B[in_consideration] B --> C[decision_pending] C --> D{blocked?} D -->|ja| E["blocked
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 Bedeutung
planned Geplant, noch nicht in Bearbeitung
in_consideration In Erwägung / fachliche Prüfung läuft
decision_pending Entscheidung ausstehend (z. B. GVB/FA-Beschluss abwartend)
blocked Blockiert; blocked_reason: needs_info \| needs_funds \| needs_community \| needs_decision

Mapping-Regel für GCBoK

Bei der Übernahme fremder Status-Vokabeln (OSCAL, NIST, BSI, ISO, DS-GVO, PCI-DSS) in die GCBoK-Taxonomie gilt:

  1. Fremde "planned/not-applicable/entbehrlich"-Werte → auf planned / in_consideration mappen (pre-active).
  2. Fremde "implemented/operational/erfüllt/in-place"-Werte → auf active mappen.
  3. Fremde "partial/under-development/bedingt entbehrlich"-Werte → auf decision_pending oder review_required mappen (je nach Reifegrad).
  4. Fremde "alternative/not-applicable"-Werte → kontextabhängig: superseded (wenn ersetzt) oder deprecated (wenn verworfen).

Dieses Mapping sichert die GoBD-Auditierbarkeit (§ 147 Abs. 6 AO, Z3-Zugriff), ohne die fremden OSCAL-/Regularien-Vokabeln zu verlieren — ein zentraler Beitrag der GCBoK-Forschung zur interoperablen Compliance-Dokumentation.

Phase 2 - AI Safety Research (ab 2026)

Ab 2026 erweitert sich der Fokus auf die Sicherheit von KI-Infrastrukturen. Die Forschungsthese: Deterministische Git-Strukturen (V7GUID) können als physikalische Guard Rails für autonome KI-Agenten dienen - anstelle von stochastischen, injizierbaren Prompts.

Abgrenzung zum Alt-Vorhaben

Dimension Alt-Vorhaben (2025–2026) Neu-Vorhaben (ab 2026/2027)
Gegenstand Identitätsmanagement, IdP, PGP/V7GUID, GPG-Keyring-Langfristverifizierbarkeit, GoBD/DSGVO KI-Governance, Guardrails statt Prompts, MCP-Agent
Technische Unsicherheit Kontext-Manipulation der Identität Determinismus vs. Stochastik der KI-Steuerung; Prompt-Injection-Resistenz via Git-Gate
Baustein im GCBoK Identitäts- & Compliance-Kern Tooling- & Guardrail-Schicht (GCUCB)
Bezugsrahmen ISO/IEC 24773 OWASP LLM Top 10, Harness Engineering, MCP

Die inhaltliche Verlagerung vom Thema „Gitea als IdP" auf „Git-Repos als KI Guardrails anstelle von Prompts" via GCUCB erfordert eine eigenständige BSFZ-Bescheinigung als neues Forschungsvorhaben. Die Abgrenzung auf Arbeitspaketebene stellt sicher, dass beide Vorhaben sauber getrennt bleiben und die Forschungszulage-Anerkennung nicht gefährdet wird.

Forschungsfragen (Phase 2)

  1. Determinismus vs. Stochastik: Inwiefern lässt sich die Steuerung eines KI-Agenten durch ein versioniertes Git-Guardrail-Repo deterministisch fassen, so dass Abweichungen von der Policy build-zeit (nicht erst prompt-zeit) erkannt werden?
  2. Prompt-Injection-Resistenz: Wie weit schützt eine Git-native Guardrail-Schicht (signiert, unveränderlich, per Git-Hook/OPA erzwungen) gegen die „lethal trifecta" (private Daten + untrusted content + Exfiltration)?
  3. MCP als Policy-Enforcement-Point: Kann ein MCP-Server mit UI-Ressource und iframe-UI als Policy-Gate wirken, das nur freigegebene (signierte) Tools/Kontexte exponiert?
  4. Auditierbarkeit: Ist der Git-Commit-Verlauf des Guardrail-Repos als GoBD-konformer Audit-Trail für KI-Entscheidungen verwendbar?

Hinweis: Die Forschungs- und Prototypen-Entwicklungen von AFJD (Axel Franz Johann Druschel) werden eigenbetrieblich außerhalb der GCC-Arbeitszeit durchgeführt. Das IP verbleibt bei AFJD; der GCC wird auf vertraglicher Basis zur Nutzung überlassen. Die Trennung sichert die Gemeinnützigkeit der GCC (kein verdeckter wirtschaftlicher Geschäftsbetrieb).

Siehe auch: FZulG-Anträge und Finanzplanung auf der GCC-Landingpage.