Axis 6: Templates

OSCAL Catalog Template

Draft

The GCBoK defines German compliance taxonomies as OSCAL catalogs - a market novelty:

oscal_catalog:
  groups:
    - id: "gobdControls"
      title: "GoBD - Nachvollziehbarkeit"
      controls:
        - id: "GOBD-01"
          title: "Progressive Navigation"
          description: "Jeden Geschäftsvorfall rückwärts verfolgbar"
    - id: "bsiControls"
      title: "BSI IT-Grundschutz Module"
      controls:
        - id: "APP.3.1.A1"
          title: "Datensicherung"
    - id: "dsgvoControls"
      title: "DSGVO Anförderungen"
      controls:
        - id: "DSGVO-Art.17"
          title: "Recht auf Vergessenwerden"

OPA Policy Template

Draft

Example of a Rego policy for document validation:

package gitcover.compliance

deny[msg] {
    input.class == "INVOICE"
    not input.prev_sha256
    msg := "INVOICE muss prev-hash referenzieren"
}

deny[msg] {
    input.class == "PAYMENT"
    not input.gpg_fingerprint
    msg := "PAYMENT muss GPG-signiert sein"
}

allow {
    count(deny) == 0
}

V7GUID Schema

Draft

The canonical V7GUID metadata schema:

{
  "v7guid": "0197a3b2-f3c0-7b00-8001-000000000042",
  "class": "INVOICE",
  "sha256": "7d4e2f...",
  "prev_sha256": "3f2a1c...",
  "gpg_fingerprint": "ABCD1234...",
  "timestamp_iso": "2026-06-14T11:18:00+02:00",
  "gobd_periode": "FY2026"
}

class is one of PERSON | INVOICE | PAYMENT | CONTRACT | ...; prev_sha256 is null for the genesis document.

Compliance Depth → V7GUID Schema Tiering

Depending on the integration depth of the Git repository and the compliance requirement, different V7GUID JSON schemas are needed. The GCBoK defines schema tiering (a tiered model) that is linked to VariantId, kind and status:

Principle: “In the end, only Git repos remain” — the fallback for reviews/audits is code artifacts + .gitcover registries/dictionaries in JSON/JSONL format. The HTML audit package is only presentation; the forensics is the Git repo (see Procedures: Audit Readiness and derivative gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt).

The schema files are stored versioned in the .gitcover/schemas/ of the TOP repo and are made resolvable via others.json.

DMS Container Template

The .gc.zip container for GCDMS (scope depends on use case):

document.gc.zip
├── document.gc.md   # Metadaten (SHA-256 des Ur-Dokuments, docUid, v7guid, Taxonomie)
├── document.gc.sig  # GPG-Signatur des Manifests
├── document.pdf     # Originaldokument (Urdokument)
├── document.json    # Maschinenlesbare Extrakte
├── document.xml     # Maschinenlesbare Extrakte (z.B. X-Rechnung)
└── attachments/     # Anhänge

Order in the container: The manifest (document.gc.md) comes first and carries the SHA-256 of the original document; the entries follow deterministically (manifest, signature, original document, extracts, attachments). This makes the container readable without a registry while remaining bound to the DMS object_id (= sidecar docUid).

Format Selection Depending on Use Case

GitCover Sidecar Template

Canonical sidecar (*.gc.md) for a digital original document. Schema: https://gitcover.org/schemas/v7g-sidecar-2.0.schema.json; the instance metadata follow record-metadata-1.0.schema.json (ISO 15489).

DocID = uuidv7 (instance identifier) vs. v7guid (class/context identifier). Both are maintained in the sidecar and linked via composite_key ({v7guid}:{uuidv7}). Minimum content: sha256 of the original document.

# GitCover Sidecar - {original_filename}

**SHA-256:** `{sha256}`
**Tenant:** {tenant}
**Kategorie:** {category}
**Sphäre:** {sphere}
**Tags:** {tags}

```json
{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-2.0.schema.json",
  "docUid": "{uuidv7}",
  "sha256": "{sha256}",
  "title": "{original_filename}",
  "original_filename": "{original_filename}",
  "locations": [
    { "unc_path": "./{tenant}/{path}", "from": "{YYMMDD}", "to": null, "note": "Primärspeicherort" }
  ],
  "v7g_taxonomy": [
    { "v7guid": "{v7guid}", "taxonomy": "{tenant}/{taxonomy}", "valid_from": "{YYMMDD}", "valid_to": null }
  ],
  "gcpn": { "prima_nota_ref": null, "journal_entry_ref": null },
  "obsolescence": { "status": "active", "superseded_by": null, "last_checked_at": "{ts}", "last_checked_by": "{user}" },
  "verification": { "verified_at": "{ts}", "verified_by": "auto", "method": "sha256_file", "intact": true },
  "tags": ["{tag}"],
  "sphere": "{sphere}"
}
```

DocID assignment: If the document is newly added to the DMS, the sidecar tool generates a UUIDv7 from a timestamp argument as the DocID (uuidV7). The default source is the file mtime; if the filename or content provides a business date, that date is used (see Axis 5: Procedures).