Parte I — Forma textual
Desencadenante S1/S2: Una GVB debe redactarse en forma textual; después, un auditor pregunta por la autenticidad. La Parte I fija el nivel de documento: MD-Doc
- artefactos JSON en el repo, sin servicios de firma externos.
Visión general de los artículos (DS01–DS05)
| Art. | Título (DE) | Pregunta central |
|---|---|---|
| DS01 | El requisito de forma textual y la libre valoración de la prueba | ¿Qué exige realmente el § 126b BGB — y qué basta en la libre valoración de la prueba? |
| DS02 | El Doc de firma como tipo de dato (JSON-Schema) | ¿Cómo describimos la "firma" como artefacto legible por máquina en el repo? |
| DS03 | El proceso de firma (Accept/Deny/Sign) | ¿Cómo se documenta un proceso de firma de manera determinista y auditable? |
| DS04 | Catalogación sidecar y cadena de verificación | ¿Cómo verifica un auditor la autenticidad y la integridad — sin leer el historial de Git? |
| DS05 | El contenedor de firma GCPN | ¿Cómo acoplamos todos los artefactos (documento fuente, FES-Doc, proceso) a un documento MD? |
La idea básica: las firmas como artefactos del repo
Un documento en el sistema GitCover no es un archivo, sino un conjunto de artefactos:
el archivo MD (documento fuente), un sidecar (.v7g.md, SHA-256 + catalogación mediante V7GUID),
en transacciones comerciales un contenedor GCPN. Precisamente a este patrón se acopla
la firma:
Quell-Dokument (MD) .v7g.md Sidecar GCPN-Container
│ │ │
│ sha256 │ sha256(Quell-Dokument) │ referenziert alle
│ │ V7GUID │ Artefakte des Vorgangs
▼ ▼ ▼
Signatur-Doc (JSON) ──── Accept/Sign-Event ──────── GCPN-Signatur-Container
Cada artefacto sigue un JSON-Schema (regla Schema-First del GCBoK),
cada relación es una referencia SHA-256, cada proceso es un evento describible
de forma determinista. Un auditor puede verificar con sha256sum y jq toda
la cadena — sin historial de Git, sin herramientas propietarias.
¿Por qué no DocuSign desde el principio?
Tres razones contra la conexión prematura de servicios de firma externos:
- Costos y fricción: La mayoría de los documentos cotidianos de una pyme (GVB, documentaciones internas de procedimientos, recibos) no necesita una firma cualificada — basta la forma textual (§ 126b BGB: "puede sustituirse por la forma textual").
- Rupturas de la cadena de prueba: Cada servicio externo genera su propio historial (Envelope-IDs, Audit-Trails en la nube del proveedor). La cadena de prueba sale del repo — justo donde GitCover GoBD promete seguridad de auditoría.
- Umbral del tercio de la fuerza probatoria: En la libre valoración de la prueba (§ 286 ZPO) una cadena interna bien documentada (cadena SHA-256 + marca de tiempo + rol del firmante identificado) suele pesar más que un "recibo de firma" de un proveedor cuyo procedimiento no se revela.
La conexión FES (Parte II) entra en juego exactamente cuando un socio contractual externo la exige — no como fin en sí misma.
Marco jurídico (cita breve)
| Norma | Contenido | Interpretación GitCover |
|---|---|---|
| § 126b BGB | Forma textual: "aquella forma de transmisión electrónica mediante la cual el documento se hace accesible a terceros y es apto para su reproducción como texto literal en una pantalla" | El archivo MD en el repo es reproducible como texto literal; el Doc de firma hace identificable la voluntad |
| § 371a ZPO | Los documentos privados con firma electrónica se consideran debidamente firmados "cuando la otorgante o el otorgante añade su nombre" | El nombre en el Doc de firma + la referencia de clave/gráfico cumple la adición del nombre |
| Reglamento eIDAS Art. 50–51 | Firma electrónica avanzada (AdES/AdEE), firma electrónica cualificada (QES) | Parte II: el acoplamiento FES como nivel por encima de la forma textual |
| § 286 ZPO | Libre valoración de la prueba | La cadena interna (SHA-256 + tiempo + roles) es un medio de prueba pleno |
Descargo de responsabilidad: No es asesoramiento jurídico. La valoración en el caso concreto queda reservada a la libre valoración de la prueba y, en su caso, al asesoramiento letrado.
Orden de lectura
Los artículos se construyen unos sobre otros:
- DS01 — Por qué basta la forma textual y qué significa "suficiente" en la libre valoración de la prueba.
- DS02 — El JSON-Schema del Doc de firma (tipo de dato "firma" en el sistema de archivos).
- DS03 — El proceso de firma como esquema de eventos (Accept/Deny/Sign).
- DS04 — Verificación sidecar: cómo comprueba el auditor la cadena.
- DS05 — El contenedor de firma GCPN: documento fuente + FES-Doc + proceso en un solo artefacto.
Creado: 260913 | Parte I de la serie digital-signage