Axis 7: Governance
GCC Articles of Association
The GCBoK is published by GitCover Commons gUG (GCC). GCC is a non-profit corporation under § 60a Abs. 1 AO, recognized by the Tax Office Bad Homburg v. d. H. (notice dated 27.05.2026).
The purposes of the Articles of Association (§ 52 Abs. 2 Satz 1 AO):
- Science and Research (No. 1)
- Education, general and vocational education (No. 7)
- Consumer advice and consumer protection (No. 16)
- International outlook and international understanding (No. 13)
Complete Articles of Association, recognition notice and donation information: on the GCC landing page.
GCC Community Rules
The GCBoK follows open-source principles:
- OSS-first - All specifications are open source
- CC BY-SA 4.0 (targeted) - Free distribution with attribution
- Apache 2.0 - For code components
- Community review - Contributions via Gitea pull requests
- No vendor lock-in - Vendor-neutral reference
GCBoK Amendment Procedure
Changes to the GCBoK follow a defined process:
- Proposal - Issue in the Gitea repo
gcbok-content - Review - Community discussion, technical review
- Draft - Pull request with proposed changes
- Approval - Review by GCC management
- Merge - Integration into main branch
- Release - Versioned release tag
From Private Opinion to Verifiable Result
Governance here does not mean opinion in the document, but a verifiable result in the record. The personal specifications of the releasing person—private assessments, weightings, balancing criteria—are the input material: they are protected, are not versioned, and do not appear in the documentation record. What emerges is the decision result: an ADR, a template, a rulebook, or evidence.
For the chain of evidence, this means: the Git record documents what was decided and how it is verifiable—not how it was weighed internally. This separation simultaneously protects the privacy of the acting person and the evidentiary value of the file.
Agent rule: observe specifications, document results—neither quote nor reproduce the assessment itself as long as the HITL has not expressly released it.
Versioning
The GCBoK uses Semantic Versioning (MAJOR.MINOR.PATCH):
| Component | Meaning |
|---|---|
| MAJOR | Incompatible conceptual changes |
| MINOR | New chapters, new definitions (backward-compatible) |
| PATCH | Corrections, clarifications |
Git-native self-referential
The GCBoK is versioned in Git—the reference work on Git-native compliance is itself hosted in Git. This is a deliberate self-reference: the work about the work is versioned in the work.
Strategic Framework: IP Usage Right
AFJD (Axel Franz Johann Druschel) is, as a natural person, applicant, inventor and permanent holder of all protective rights. The IP remains with AFJD—it is made available to GCC for use on a contractual basis (no transfer of ownership).
| Aspect | Transfer of ownership (not chosen) | Right of use by contract (chosen) |
|---|---|---|
| IP holder | GCC | natural person |
| GCC as licensor? | Yes -> non-profit status endangered | No -> GCC non-profit status secure |
| Protection against takeover | Low | High (IP remains with natural person) |
Full details: See Protective Rights.
PII Separation: Personal Data Central, References in Tenants
Personal data (PII, DSGVO/GDPR) are not scattered across tenant repos. Each legal entity
maintains all PII in a central PII repo (top root, e.g. REPOS/AFJD/PII/) — master and
contact data, blocking notices, retention/deletion notes, consents and specially
protected data. In the tenant/OSS/work repos there are only references: the uuidV7 of the person
as person_uid (the type uuidV7, not a property name) plus local reference info (function/role, rights).
Why: data minimization (DSGVO Art. 5), unambiguous identification (the real name is not unambiguous) and actually enforceable data subject rights (access/erasure/portability) — a PII fact exists once; all other locations reference it. Raw scans (ID documents/signatures) remain outside Git.
Tooling: the solution GitCover.PII (self-management UI analogous to a Google account: GDPR mandatory aspects,
blocking notices, retention, contact data) integrates GitCover.IdP (IAM) and GitCover.Ledger (evidence).
Normative SSoT:
OSS/TOP/.gitcover/specs/pii-separation.md.
Order & Standardization: Processing operations are first determined according to the GDPR provision (legalBasis, Art. 6/9 DSGVO) and then via the reference (where/through what) — legalBasis is the anchor (not a free list of purposes). Permissions ("permission by user") are documented technically as GCPN and only referenced. The DSGVO matters are standardized as ENUMs/UNIONs in GCBoK; an OSCAL catalog + OPA artifact sets (SSoT: .gitcover/policy/pii-gdpr.catalog.json, pii_legal_basis.rego) is consumed by the GitCover.PII feature (Policy-as-Code).
Data Sovereignty Instead of Vendor Lock-In: The facts arising in PII should optionally replace M365-/MS-User-Account-Graphs — personal data are kept not in a cloud platform but in the Git repo. This enables Git-native compliance (audit-proof, self-referential) and full data sovereignty of the user without vendor lock-in. The PII facts are at the same time the data basis for the OU feature (GitCover.Discovery/plans/ADR-005), which supplies System.DirectoryServices (Microsoft Active Directory) with OU structure/provisioning — persons there only via person_uid; GitCover.IdP remains the authorization server.