DS01 — Das Textform-Erfordernis und die freie Beweiswürdigung

Auslöser S1

Die Alleingesellschafterin (Platzhalter E1 als Unternehmer, Organisation ORG-1) fasst einen Gesellschafterbeschluss (GVB) — etwa die Genehmigung einer Aufwandsentschädigung. Die Satzung verlangt Beschlussfassung in Textform. E1 fragt: Kann ich das im Git-Repo tun — und wie sieht ein Beschluss aus, den ein Prüfer später als "in Textform gefasst" anerkennt?

Was § 126b BGB verlangt

§ 126b BGB (Textform): "Ist durch Gesetz die schriftliche Form nicht vorgeschrieben, sondern die Textform vorgesehen, so kann die Textform durch jede geeignete Form der elektronischen Übermittlung ersetzt werden, sofern (1) die Person, für die das Dokument bestimmt ist, mittels der vom Empfänger angegebenen Anschrift Zugriff auf das Dokument hat, (2) das Dokument für andere zugänglich gemacht und zur Wiedergabe als Wortlaut auf einem Bildschirm geeignet ist und (3) die Person, die das Dokument abgibt, das Dokument zur Wahrung der von ihr vertretenen Interessen als ihr stammend kenntlich gemacht hat."

Drei Voraussetzungen, drei GitCover-Deutungen:

§ 126b BGB	GitCover-Deutung
(1) Zugriff über Empfänger-Anschrift	Das Tenant-Repo (Gitea) ist die Anschrift; der Empfänger (Gesellschafter, GF) hat Lese-Zugriff
(2) Zugänglich, Wortlaut-wiedergabefähig	Markdown-Doc ist Wortlaut — `cat`, Typora, jeder Browser rendert es
(3) Herkunfts-Zuordnung ("als ihr stammend kenntlich gemacht")	Der Signatur-Doc weist das Dokument erkennbar dem Zeichner zu: Name + Rolle + Facsimile-Verweis in einem SHA-256-verankerten JSON-Artefakt (DS02)

Punkt (3) verlangt keine qualifizierte Signatur. Er verlangt eine kenntliche Herkunfts-Zuordnung: Der Empfänger muss erkennen können, wer das Dokument abgibt. Genau hier setzen der Signatur-Doc (DS02) und der Signatur-Vorgang (DS03) an.

Freie Beweiswürdigung (§ 286 ZPO)

Zivilprozessrechtlich ist die Textform-Urkunde kein streng beweisbedürftiges Ereignis — sie fällt unter die freie Beweiswürdigung. Das Gericht würdigt, ob die vorliegenden Beweismittel "eine Überzeugung nach freier Überzeugung bilden". Das heißt:

Es gibt keine starre Form, die "genügt" — es gibt nur mehr oder minder überzeugende Nachweise.
Ein lückenloses, revisionsicher dokumentiertes Verfahren (wer gab wann mit welchem Schlüssel/welcher Grafik das Dokument ab, wie ließ sich Integrität verifizieren) überzeugt eher als ein einziger "Signatur-Bon".
Umgekehrt: Ein einmaliger Screenshot einer Mail-Unterschrift überzeugt kaum; ein SHA-256-gestütztes, katalogisiertes Artefakt-Set schon.

GitCover übersetzt das in eine beweiswürdigungsfreundliche Kette:

Integrität: SHA-256 des Quell-Dokuments, des Signatur-Docs, des Sidecars.
Herkunfts-Zuordnung: Signatur-Doc identifiziert Zeichner (Name, Rolle, Schlüssel-/Grafikverweis) und verknüpft per SHA-256 an das Quell-Dokument.
Zeitliche Ordnung: uuidV7-Zeitstempel in jedem Artefakt (RFC 9562).
Katalogisierung: V7GUID-Class-Taxonomy im Sidecar; Prüfer kann Artefakt-Typ ohne Kontextwissen erkennen.
Revisionssicherheit: Git-Historie ist nicht das einzige Beweismittel — die Kette ist auch ohne Git (mit jq, sha256sum, beliebigem Editor) prüfbar.

§ 371a ZPO — die private Urkunde mit elektronischer Form

§ 371a ZPO: "Private Urkunden mit elektronischer Form haben die Beweiskraft privater Urkunden mit schriftlicher Form, wenn die Ausstellerin oder der Aussteller ihren Namen beifügt und die Abgabe der Erklärung der elektronischen Form anzeigt, oder wenn sie in einer qualifizierten elektronischen Signatur oder einem vergleichbaren beglaubigten Siegel versehen sind."

Drei Beobachtungen für den GitCover-Weg:

Namensbeifügung + Form-Anzeige genügen — der Signatur-Doc (DS02) tut genau das: Name/Rolle des Zeichners + explizite Form-Anzeige ("Abgabe der Erklärung in elektronischer Form").
QES ist die eiserne Alternative — wenn ein Vertrag als private Urkunde mit QES beweiskräftig sein soll, dockt die FES-Qualifikation an (Teil II). Die Textform-Basis bleibt aber auch dann die Repo-Ebene.
Der Beweiswert liegt in der Kette — nicht in einem einzelnen Merkmal. DS04 zeigt die vollständige Verifikationsroutine.

Der häufigste Fehler: Die Mail-Signatur

Die Praxis-Konstellation, die GitCover vermeiden will:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart LR A["PDF gedruckt"] --> B["Handschrift
unterschrieben"] B --> C["Gescannt"] C --> D["Per Mail
gesendet"] D --> E["Mail-Verzeichnis
im Postfach"] E --> F["Prüfung: Wo ist die
Original-Unterschrift?"] style F fill:#f3d9d9,stroke:#8b2635

Nachweisbrüche: Kein SHA-256, kein Zeitstempel, keine Rollen-Zuordnung, keine Revisionssicherheit — das "Original" wandert zwischen Drucker, Scanner und Mail-Client. Ein GitCover-Doc vermeidet das, indem jede Stufe ein Artefakt im Repo ist.

Zusammenfassung

§ 126b BGB verlangt Zugriff + Wortlaut + Herkunfts-Zuordnung — MD-Doc + Signatur-Doc erfüllen das Git-nativ.
Bei freier Beweiswürdigung überzeugt die lückenlose Kette (SHA-256 + Zeit + Rollen + Katalogisierung) mehr als ein externer Signatur-Bon.
§ 371a ZPO bestätigt: Namensbeifügung + Form-Anzeige genügen für die Beweiskraft privater Urkunden; QES ist die eiserne Alternative, kein Muss für Textform.
Der nächste Artikel (DS02) definiert den Signatur-Doc als JSON-Schema.

Erstellt: 260913 | Teil I, Artikel DS01 | Serie: digital-signage