Eje 6: Plantillas
Plantilla de catálogo OSCAL
El GCBoK define taxonomías de cumplimiento alemanas como catálogos OSCAL, una novedad en el mercado:
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"
Plantilla de política OPA
Ejemplo de una política Rego para la validación de documentos:
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
}
Esquema V7GUID
El esquema canónico de metadatos 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"
Profundidad de cumplimiento → Jerarquización del esquema V7GUID
Según la profundidad de integración del repositorio Git y el requisito de cumplimiento,
se necesitan diferentes esquemas JSON de V7GUID. El GCBoK define una
jerarquización de esquemas (modelo por niveles) vinculada a VariantId, kind y status:
| Nivel | Requisito de cumplimiento | Campos de esquema requeridos | VariantId |
kind |
status |
|---|---|---|---|---|---|
| T1 | Solo GoBD/AO (mínimo) | v7guid, class, sha256, prev_sha256, gpg_fingerprint, timestamp_iso, gobd_periode |
10 (conservación de 10 años §147 AO) |
INVOICE, RECEIPT, CONTRACT |
ACTIVE |
| T2 | PII / DSGVO | T1 + tenant_id, org_unit_id, data_category (Art. 9 DSGVO), retention_legal_basis |
11 (nivel de protección DSGVO) |
PERSON, HR_DATA |
ACTIVE |
| T3 | NIS2 (infraestructuras críticas) | T2 + risk_level, incident_reporting_obligation, supply_chain_tier |
12 (clase de riesgo NIS2) |
INFRASTRUCTURE, LOG_DATA |
ACTIVE |
| T4 | ISO 27001 (completo) | T3 + control_id (ISO 27001 Anexo A), asset_classification, treatment_plan_ref |
13 (IFRS/HGB + ISO) |
POLICY, AUDIT_EVIDENCE |
ACTIVE |
Principio: «Al final solo quedan repositorios Git» — el recurso de respaldo en
revisiones/auditorías son artefactos de código + registros/diccionarios de .gitcover
en formato JSON/JSONL. El paquete de verificación HTML es solo presentación; la
forense es el repositorio Git (véase Procedimientos: Preparación para auditoría y el derivado gcbok-audit-evidence-docs/docs/02-audit-website-als-pruefungsartefakt).
Los archivos de esquema se almacenan con control de versiones en .gitcover/schemas/ del repositorio principal
y se hacen resolubles a través de others.json.
Plantilla de contenedor DMS
El contenedor .v7g.zip para GCDMS (alcance según el caso de uso):
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
Selección de formato según el caso de uso
| Formato | Uso |
|---|---|
.v7g.json |
Legible por máquina, políticas OPA, exportación OSCAL |
.v7g.md |
Hipervínculos, legible por humanos, interfaz web de Git |
.v7g.yaml |
Archivo de configuración, editable por humanos |
Plantilla de sidecar V7GUID
Sidecar canónico (*.v7g.md) para un documento original digital. Esquema: https://gitcover.org/schemas/v7g-sidecar-1.0.schema.json; los metadatos de instancia siguen record-metadata-1.0.schema.json (ISO 15489).
DocID =
uuidv7(identificador de instancia) vs.v7guid(identificador de clase/contexto). Ambos se gestionan en el sidecar y se vinculan a través decomposite_key({v7guid}:{uuidv7}). Contenido mínimo:sha256del documento 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}"
}
```
Asignación de DocID: Cuando el documento se incorpora por primera vez al DMS, la herramienta de sidecar genera una UUIDv7 a partir de un argumento de marca de tiempo como DocID (uuidV7). La fuente predeterminada es la mtime del archivo; si el nombre del archivo o el contenido proporciona una fecha de negocio, se utiliza esta (véase Eje 5: Procedimientos).