Teil I — Textform

Auslöser S1/S2: Eine GVB soll in Textform gefasst werden; danach fragt ein Prüfer nach der Authentizität. Teil I legt die Dokument-Ebene: MD-Doc

JSON-Artefakte im Repo, ohne externe Signaturdienste.

Übersicht der Artikel (DS01–DS05)

Art.	Titel (DE)	Kernfrage
DS01	Das Textform-Erfordernis und die freie Beweiswürdigung	Was verlangt § 126b BGB wirklich — und was genügt bei freier Beweiswürdigung?
DS02	Der Signatur-Doc als Datentyp (JSON-Schema)	Wie beschreiben wir "Signatur" als maschinenlesbares Artefakt im Repo?
DS03	Der Signatur-Vorgang (Accept/Deny/Sign)	Wie wird ein Signier-Vorgang deterministisch und revisionssicher dokumentiert?
DS04	Sidecar-Katalogisierung und Verifikationskette	Wie prüft ein Prüfer Authentizität und Integrität — ohne Git-Historie zu lesen?
DS05	Der GCPN-Signatur-Container	Wie docken wir alle Artefakte (Quell-Dokument, FES-Doc, Vorgang) an ein MD-Dokument an?

Die Grundidee: Signaturen als Repo-Artefakte

Ein Dokument im GitCover-System ist keine Datei, sondern ein Artefakt-Set: die MD-Datei (Quell-Dokument), ein Sidecar (.v7g.md, SHA-256 + V7GUID-Katalogisierung), bei Geschäftsvorfällen ein GCPN-Container. Genau an dieses Muster dockt die Signatur an:

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

Jedes Artefakt folgt einem JSON-Schema (Schema-First-Regel des GCBoK), jede Beziehung ist ein SHA-256-Verweis, jeder Vorgang ist ein deterministisch beschreibbarer Event. Ein Prüfer kann mit sha256sum und jq die gesamte Kette verifizieren — ohne Git-Historie, ohne proprietäre Tools.

Warum kein DocuSign von Anfang an?

Drei Gründe gegen die premature Anbindung externer Signaturdienste:

Kosten & Reibung: Der Großteil der Alltagsdokumente eines KMU (GVB, interne Verfahrensdokumentationen, Quittungen) braucht keine qualifizierte Signatur — Textform genügt (§ 126b BGB: "kann durch Textform ersetzt werden").
Nachweisbrüche: Jeder externe Dienst erzeugt seine eigene Historie (Envelope-IDs, Audit-Trails in der Cloud des Anbieters). Die Nachweiskette verlässt das Repo — genau dort, wo GitCover GoBD Revisionssicherheit verspricht.
Drittel-Schwelle der Beweiskraft: Bei freier Beweiswürdigung (§ 286 ZPO) trägt eine gut dokumentierte interne Kette (SHA-256-Kette + Zeitstempel + identifizierte Zeichner-Rolle) oft mehr Gewicht als ein "Signatur-Bon" eines Anbieters, dessen Verfahren nicht offengelegt ist.

Die FES-Anbindung (Teil II) kommt genau dann ins Spiel, wenn ein externer Vertragspartner sie verlangt — nicht als Selbstzweck.

Rechtlicher Rahmen (Kurzzitat)

Norm	Aussage	GitCover-Deutung
§ 126b BGB	Textform: "diejenige Form der elektronischen Übermittlung, mit der das Dokument für andere zugänglich gemacht und zur Wiedergabe als Wortlaut auf einem Bildschirm geeignet ist"	MD-Datei im Repo ist als Wortlaut wiedergabefähig; der Signatur-Doc macht den Willen identifizierbar
§ 371a ZPO	Private Urkunden mit eS gelten als ordnungsgemäß unterschrieben, "wenn die Ausstellerin oder der Aussteller ihren Namen beifügt"	Der Name im Signatur-Doc + Schlüssel-/Grafikverweis erfüllt die Namensbeifügung
eIDAS-VO Art. 50–51	Fortgeschrittene eS (AdES/AdEE), qualifizierte eS (QES)	Teil II: FES-Andock als Stufe über der Textform
§ 286 ZPO	Freie Beweiswürdigung	Die interne Kette (SHA-256 + Zeit + Rollen) ist ein vollwertiges Beweismittel

Disclaimer: Kein Rechtsrat. Die Bewertung im Einzelfall bleibt der freien Beweiswürdigung und ggf. anwaltlicher Beratung überlassen.

Lese-Reihenfolge

Die Artikel bauen aufeinander auf:

DS01 — Warum Textform genügt und was "ausreichend" bei freier Beweiswürdigung bedeutet.
DS02 — Das JSON-Schema des Signatur-Docs (Datentyp "Signatur" im Filesystem).
DS03 — Der Signatur-Vorgang als Event-Schema (Accept/Deny/Sign).
DS04 — Sidecar-Verifikation: Wie der Prüfer die Kette prüft.
DS05 — Der GCPN-Signatur-Container: Quell-Dokument + FES-Doc + Vorgang in einem Artefakt.

Erstellt: 260913 | Teil I der Serie digital-signage