Axis 14: Certification (preliminary)

Note: This chapter describes plans for Phase 3 (Q2–Q4 2027). The certification capabilities sketched here are intended or planned. Their achievement is dependent on the community success and acceptance of the GCBoK. At the present time (2026), nobody can seriously predict that.

Goal

To establish a certification scheme for Git-native compliance based on the GCBoK that fulfills the structural requirements of ISO/IEC 24773 (BoK as a basis for certification schemes) — provided that the community adopts the GCBoK as a normative reference standard.

ISO/IEC 24773 — Structural Requirements (Brief Overview)

ISO/IEC 24773 defines how a Body of Knowledge (BoK) must be structured in order to serve as a basis for certification schemes. Core requirements:

Level ISO/IEC 24773 Term GCBoK Equivalent (Status)
1 Knowledge Areas (KAs) 14 axes (01–14) — in place
2 Competencies per KA intended — to be defined per axis
3 Learning Outcomes planned — measurable learning objectives per competency
4 Assessment Criteria intended — evaluation standards for examinations
5 Professional Roles planned — role assignment (e.g., Compliance Engineer, Auditor)
6 Competency Levels intended — levels (Entry / Practitioner / Expert)

Planned Approach (Phase 3, Q2–Q4 2027)

1. Competency Definition per Axis (intended)

For each of the 14 axes, 2–4 competencies are to be formulated. Example (Axis 02 — Concepts):

Competency ID Title (Working Title) Description (planned)
GCBOK-02-C1 Applying V7GUID classification Deterministically assign the L1–L6 hierarchy + extended key fields (RepositoryId, ProcessTypeId, GatewayId, VariantId)
GCBOK-02-C2 Constructing evidence chains Build prev_sha256 chaining, GPG signatures, V7GUID evidence chains for GoBD records
GCBOK-02-C3 Validating the Cryptographic Evidence Chain Verify Git commit hash + GPG signature + V7GUID as O(1) verifiability

2. Learning Outcomes per Competency (planned)

Per competency, 2–3 measurable learning outcomes (Bloom's taxonomy: Remember → Create). Example GCBOK-02-C1:

LO ID Formulation (planned) Bloom Level
GCBOK-02-C1-LO1 Be able to explain the six hierarchy levels (L1–L6) and their 4-bit width Understand
GCBOK-02-C1-LO2 Determine the correct class notation (L1_L2_L3_L4_L5_L6) for a given evidence item Apply
GCBOK-02-C1-LO3 Recognize and correct an incorrect V7GUID classification based on the dictionary rules Analyze

3. Assessment Criteria (intended)

Criterion Description (intended)
Theoretical examination Multiple-choice / short answer on concepts, definitions, standards
Practical exercise In a test Git environment: generate a V7GUID, create a sidecar, validate an evidence chain
Case study Solve a given compliance scenario (e.g., GoBD annual financial statements) using GCBoK means

4. Professional Roles Mapping (planned)

Role Relevant Axes (Example) Certification Level (intended)
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 (intended)

Level Designation Prerequisites (intended)
Entry Foundational understanding Theoretical examination passed; GCBoK chapters 01–06 read
Practitioner User competence Entry + practical exercise + 1 case study; at least 1 year of project experience
Expert Design competence Practitioner + multiple case studies; community contribution (PRs, reviews, translations); at least 3 years of experience

Dependencies and Risks

Factor Influence on Certification
Community acceptance Without broad use of the GCBoK as a reference work, no demand for certification
Tool maturity Webstatic, OPA, OSCAL tooling must be stable and documented
Partner ecosystem BSI/ENISA partnerships (Roadmap Phase 3) as credibility anchors
Legal framework conditions Certification schemes in DE/EU require accreditation (DAkkS or similar)

Next Steps (preliminary)

  1. Gather community feedback (Gitea Issues, Discussions) — is there demand?
  2. Draft and review pilot competencies for 2–3 axes (e.g., 02, 04, 05)
  3. Learning outcome workshop with potential trainers/examiners
  4. Assessment tooling as a prototype (webstatic-based? OSCAL export?)
  5. Decision: continue only in case of positive community feedback

References