Axe 6 : Modèles

Modèle de catalogue OSCAL

Le GCBoK définit les taxinomies de conformité allemandes en tant que catalogues OSCAL — une première sur le marché :

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"

Modèle de politique OPA

Exemple de politique Rego pour la validation de pièces justificatives :

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
}

Schéma V7GUID

Le schéma canonique de métadonnées V7GUID :

v7guid: "0197a3b2-f3c0-7b00-8001-000000000042"
class: INVOICE          # PERSON | INVOICE | PAYMENT | CONTRACT | ...
sha256: "7d4e2f..."
prev_sha256: "3f2a1c..."  # null für Genesis-Beleg
gpg_fingerprint: "ABCD1234..."
timestamp_iso: "2026-06-14T11:18:00+02:00"
gobd_periode: "FY2026"

Profondeur de conformité → Hiérarchisation du schéma V7GUID

Selon la profondeur d'intégration du dépôt Git et l'exigence de conformité, différents schémas JSON V7GUID sont nécessaires. Le GCBoK définit une hiérarchisation de schémas (modèle par niveaux), liée à VariantId, kind et status :

Principe : « Finalement, seuls les dépôts Git subsistent » — le repli lors des contrôles/audits est constitué d'artefacts de code + des registres/dictionnaires .gitcover au format JSON/JSONL. Le paquet de vérification HTML n'est qu'une présentation ; la forensique, c'est le dépôt Git (voir Procédures : Prêt pour l'audit et dérivé gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt).

Les fichiers de schéma sont versionnés dans .gitcover/schemas/ du dépôt principal et rendus résolubles via others.json.

Modèle de conteneur DMS

Le conteneur .v7g.zip pour GCDMS (étendue selon le cas d'usage) :

document.v7g.zip
├── .v7g.md          # Metadaten, ggfs. mit Strukturinformationen in Markdown Artefakten (JSON/YAML/XML, SHA256 Hash des Urdokuments, etc.)
├── .v7g.sig         # GPG-Signatur
├── document.pdf     # Originaldokument (Urdokument)
├── document.json    # Maschinenlesbare Extrakte
├── document.xml     # Maschinenlesbare Extrakte (z.B. X-Rechnung)
└── attachments/     # Anhänge

Choix de format selon le cas d'usage

Modèle de sidecar V7GUID

Sidecar canonique (*.v7g.md) pour un document original numérique. Schéma : https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json ; les métadonnées d'instance suivent record-metadata-1.0.schema.json (ISO 15489).

DocID = uuidv7 (identifiant d'instance) vs. v7guid (identifiant de classe/contenu). Les deux sont gérés dans le sidecar et liés via composite_key ({v7guid}:{uuidv7}). Contenu minimal : sha256 du document original.

# V7G Sidecar - {original_filename}

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

```json
{
  "$schema": "https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json",
  "uuidV7": "{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}"
}
```

Attribution du DocID : Lorsqu'un document est nouvellement enregistré dans le DMS, l'outil sidecar génère une UUIDv7 à partir d'un argument de timestamp en tant que DocID (uuidV7). La source par défaut est la mtime du fichier ; si le nom de fichier ou le contenu fournit une date métier, celle-ci est utilisée (voir Axe 5 : Procédures).