Achse 14: Zertifizierung (vorläufig)
Hinweis: Dieses Kapitel beschreibt Planungen für Phase 3 (Q2–Q4 2027). Die hier skizzierten Zertifizierungstauglichkeiten sind vorgesehen bzw. geplant. Ihr Erreichen ist abhängig vom Community-Erfolg und der Akzeptanz des GCBoK. Zum jetzigen Zeitpunkt (2026) kann das niemand ernsthaft vorhersagen.
Ziel
Ein Zertifizierungsschema für Git-native Compliance auf Basis des GCBoK zu etablieren, das die Strukturvorgaben von ISO/IEC 24773 (BoK als Grundlage für Zertifizierungsschemata) erfüllt — sofern die Community das GCBoK als normativen Referenzstandard annimmt.
Materialquellen für das Zertifizierungsschema (vorgesehen)
Für den Aufbau der Zertifizierungsprogramme liefern die beiden GCC-Stränge das Material:
- GCC (Organisation/Compliance-Praxis): Satzung/§ 60a-Rahmen, Aktivitäten, Projekte, Förderung — sowie die Erfahrungsberichte/Lessons Learned der GCC-Website als technische Fakten (theming, i18n, Rendering-Verträge) ohne Marketing-Anspruch.
- GCBoK (Wissenswerk): Achsen-/Kompetenzstruktur, Learning Outcomes, Assessment-Kriterien und Kompetenzstufen — siehe die Competency-Gruppen dieser Achse.
Vorgesehen ist, diese Quellen systematisch auf die Competency-Gruppen abzubilden und die Erfahrungsberichte als Anwendungsbeispiele in die Assessment-Kriterien aufzunehmen.
Status: vorgesehen/geplant — kein bestehendes Programm. Zertifikate werden erst nach erfolgreichem Aufbau (Phase 3) und Community-Akzeptanz angeboten; es besteht kein Anspruch auf Zertifizierung.
ISO/IEC 24773 — Strukturvorgaben (Kurzüberblick)
ISO/IEC 24773 definiert, wie ein Body of Knowledge (BoK) aufgebaut sein muss, damit es als Basis für Zertifizierungsschemata dienen kann. Kernforderungen:
| Ebene | ISO/IEC 24773 Begriff | GCBoK-Entsprechung (Status) |
|---|---|---|
| 1 | Knowledge Areas (KAs) | 14 Achsen (01–14) — vorhanden |
| 2 | Competencies pro KA | vorgesehen — pro Achse definieren |
| 3 | Learning Outcomes | geplant — messbare Lernziele je Competency |
| 4 | Assessment Criteria | vorgesehen — Bewertungsmaßstäbe für Prüfungen |
| 5 | Professional Roles | geplant — Rollen-Zuordnung (z. B. Compliance Engineer, Auditor) |
| 6 | Competency Levels | vorgesehen — Stufen (Entry / Practitioner / Expert) |
Geplante Vorgehensweise (Phase 3, Q2–Q4 2027)
1. Competency-Definition pro Achse (vorgesehen)
Für jede der 14 Achsen sollen 2–4 Competencies formuliert werden. Beispiel (Achse 02 — Konzepte):
| Competency ID | Titel (Arbeitstitel) | Beschreibung (geplant) |
|---|---|---|
GCBOK-02-C1 |
V7GUID-Klassifikation anwenden | L1–L6 Hierarchie + erweiterte Kennfelder (RepositoryId, ProcessTypeId, GatewayId, VariantId) deterministisch zuordnen |
GCBOK-02-C2 |
Beleg-Ketten (Evidence Chains) konstruieren | prev_sha256-Verkettung, GPG-Signaturen, V7GUID-Belegketten für GoBD-Nachweise aufbauen |
GCBOK-02-C3 |
Cryptographic Evidence Chain validieren | Git-Commit-Hash + GPG-Signatur + V7GUID als O(1)-Prüfbarkeit verifizieren |
1a. Neue Kompetenzgruppe — Onboarding, Chat-Workflow und Harness (möglicher Pilot)
Die Themen des aktuellen AFJD-/GCUV-Onboarding-Prototyps werden als mögliche Competency-Gruppe für spätere Partner-Assessments vorgemerkt:
| Competency ID | Titel (Arbeitstitel) | Beschreibung (geplant) |
|---|---|---|
GCBOK-05-C4 |
Revisionssicheres KMU-Onboarding | Einen bestehenden Workspace als Legal-Tenant/Group-OU erfassen und vor Migration mit Git-Baseline, Identity und Recovery-Struktur ausstatten |
GCBOK-03-C4 |
Chat-Workflow und Agentenprotokoll | Vorgaben, Fragen, Antwortoptionen, Antworten, Entscheidungen, Tool-Aktionen, Artefakte und Gates als chat-workflow-1.0 abbilden |
GCBOK-04-C4 |
Deterministische Harness-Gates | Schema-, SHA-, Policy-, Test-, HITL-, Write- und Commit-Gates korrekt durchführen und blockierende Zustände erkennen |
GCBOK-02-C4 |
Wiederherstellbare Migration | Checkpoints, Zustandsvergleiche und Restore-Pläne erstellen; Korrekturen ohne History-Rewrite dokumentieren |
GCBOK-06-C4 |
Fachmodul-Übergabe | Onboarding-Ergebnisse an Ledger, DMS, Portfolio und weitere GitCover-Module über Referenzen übergeben |
Diese Gruppe ist Planungsstand, keine Anerkennung, Akkreditierung oder Zertifizierung.
2. Learning Outcomes je Competency (geplant)
Pro Competency 2–3 messbare Learning Outcomes (Bloom-Taxonomie: Remember → Create).
Beispiel GCBOK-02-C1:
| LO ID | Formulierung (geplant) | Bloom-Stufe |
|---|---|---|
GCBOK-02-C1-LO1 |
Die sechs Hierarchie-Ebenen (L1–L6) und ihre 4-Bit-Breite erklären können | Understand |
GCBOK-02-C1-LO2 |
Für einen gegebenen Beleg die korrekte class-Notation (L1_L2_L3_L4_L5_L6) bestimmen |
Apply |
GCBOK-02-C1-LO3 |
Eine fehlerhafte V7GUID-Klassifikation anhand der Dictionary-Regeln erkennen und korrigieren | Analyze |
Beispielhafte Learning Outcomes für GCBOK-05-C4 (geplant)
| LO ID | Formulierung (geplant) | Bloom-Stufe |
|---|---|---|
GCBOK-05-C4-LO1 |
Legal-Tenant, Group-/OU-Top und verbundene Gesellschaften unterscheiden | Understand |
GCBOK-05-C4-LO2 |
Vor einer Migration Git-Repo, .gitcover/, Baseline-Snapshot und Wiederherstellungspunkt anlegen |
Apply |
GCBOK-05-C4-LO3 |
Eine Migration über Chat-Workflow, HITL-Gate, Validation-Gate und Checkpoint nachvollziehbar durchführen | Create |
GCBOK-05-C4-LO4 |
Einen früheren bestätigten Zustand über einen Restore-Plan wiederherstellen und die Integrität prüfen | Analyze |
3. Assessment Criteria (vorgesehen)
| Kriterium | Beschreibung (vorgesehen) |
|---|---|
| Theoretische Prüfung | Multiple-Choice / Kurzantwort zu Konzepten, Definitionen, Normen |
| Praktische Übung | In einer Test-Git-Umgebung: V7GUID erzeugen, Sidecar anlegen, Beleg-Kette validieren |
| Fallstudie | Gegebenes Compliance-Szenario (z. B. GoBD-Jahresabschluss) mit GCBoK-Mitteln lösen |
4. Professional Roles Mapping (geplant)
| Rolle | Relevante Achsen (Beispiel) | Zertifizierungsstufe (vorgesehen) |
|---|---|---|
| Compliance Engineer | 01, 02, 04, 05, 06 | Practitioner |
| Git-native Auditor | 01, 02, 05, 07, 14 | Expert |
| Developer (GitCover Stack) | 02, 03, 04, 06 | Entry → Practitioner |
| PMO / Governance Lead | 01, 05, 07, 10, 14 | Practitioner → Expert |
5. Competency Levels (vorgesehen)
| Stufe | Bezeichnung | Voraussetzungen (vorgesehen) |
|---|---|---|
| Entry | Grundlagenverständnis | Theoretische Prüfung bestanden; GCBoK-Kapitel 01–06 gelesen |
| Practitioner | Anwenderkompetenz | Entry + praktische Übung + 1 Fallstudie; mind. 1 Jahr Projekterfahrung |
| Expert | Gestalterkompetenz | Practitioner + mehrere Fallstudien; Community-Beitrag (PRs, Reviews, Übersetzungen); mind. 3 Jahre Erfahrung |
Möglicher Partner-Zertifizierungspfad (Planung)
Für GitCover-Partner kann später ein praxisorientiertes Assessment vorgesehen werden:
- Onboarding Readiness: Repo-Bootstrap, Legal-Tenant-/OU-Modell und Baseline.
- Workflow Literacy:
chat-workflow-1.0, Dialoge, Entscheidungen und Quellen. - Harness Operation: deterministische Guards, HITL- und Write-Gates, Validation.
- Migration Evidence: Checkpoints, SHA-Manifeste, Sidecars und Restore-Plan.
- Module Handover: Übergabe an Ledger/DMS/Portfolio ohne Verlust der Provenienz.
- Review: unabhängige Beurteilung eines anonymisierten Falles durch Prüfer/Reviewer.
Das Assessment wäre ein möglicher Zertifizierungsvorschlag. Es ersetzt weder eine Akkreditierung noch eine unabhängige fachliche, steuerliche oder rechtliche Prüfung.
Abhängigkeiten und Risiken
| Faktor | Einfluss auf Zertifizierung |
|---|---|
| Community-Akzeptanz | Ohne breite Nutzung des GCBoK als Referenzwerk keine Nachfrage nach Zertifizierung |
| Tool-Reife | Webstatic, OPA, OSCAL-Tooling müssen stabil und dokumentiert sein |
| Partner-Ökosystem | BSI/ENISA-Partnerschaften (Roadmap Phase 3) als Glaubwürdigkeitsanker |
| Rechtliche Rahmenbedingungen | Zertifizierungsschemata in DE/EU benötigen Akkreditierung (DAkkS o. ä.) |
Nächste Schritte (vorläufig)
- Community-Feedback einholen (Gitea Issues, Discussions) — ist Bedarf da?
- Pilot-Competencies für 2–3 Achsen (z. B. 02, 04, 05) ausarbeiten und reviewen
- Learning-Outcome-Workshop mit potenziellen Trainern/Prüfern
- Assessment-Tooling prototypisch (webstatic-basiert? OSCAL-Export?)
- Entscheidung: Weiterverfolgung nur bei positivem Community-Echo
Referenzen
- ISO/IEC 24773:2019 — Software and systems engineering — Certification of software and systems engineering professionals
- GCBoK Kapitel 00 (Index) — Positionierung als BoK
- GCBoK Kapitel 10 (Roadmap) — Phase 3: Zertifizierungsschema (ISO/IEC 24773)
- GCBoK Kapitel 11 (Referenz GCC) — Gemeinnützigkeit und normative Autorität