Axe 6 : Modèles

Modèle de catalogue OSCAL

Brouillon

Le GCBoK définit des taxonomies de conformité allemandes comme catalogues OSCAL — une nouveauté 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

Brouillon

Exemple d'une politique Rego pour la validation des justificatifs :

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

Brouillon

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

{
  "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 est l'une de PERSON | INVOICE | PAYMENT | CONTRACT | ... ; prev_sha256 vaut null pour le justificatif de genèse.

Profondeur de conformité → hiérarchisation des schémas V7GUID

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

Principe : « À la fin, seuls des dépôts Git restent » — le repli lors des contrôles/audits consiste en artefacts de code + registres/dictionnaires .gitcover au format JSON/JSONL. Le package de vérification HTML n'est que présentation ; la forensique est le dépôt Git (voir Procédures : préparation à l'audit et le 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 TOP et sont rendus résolubles via others.json.

Modèle de conteneur DMS

Le conteneur .gc.zip pour GCDMS (ampleur selon le cas d'usage) :

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

Ordre dans le conteneur : Le manifeste (document.gc.md) figure en premier et porte le SHA-256 du document original ; les entrées suivent de manière déterministe (manifeste, signature, document original, extraits, annexes). Ainsi, le conteneur est lisible sans registre et reste en même temps lié à l'object_id DMS (= docUid du sidecar).

Choix du format selon le cas d'usage

Modèle de sidecar GitCover

Sidecar canonique (*.gc.md) pour un document original numérique. Schéma : https://gitcover.org/schemas/v7g-sidecar-2.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/contexte). Les deux sont portés dans le sidecar et reliés via composite_key ({v7guid}:{uuidv7}). Contenu minimal : sha256 du document original.

# 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}"
}
```

Attribution du DocID : Lorsqu'un document est nouvellement intégré au DMS, l'outil sidecar génère une UUIDv7 à partir d'un argument d'horodatage comme DocID (uuidV7). La source par défaut est le 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).