DS01 — The Text Form Requirement and Free Assessment of Evidence
Trigger S1
The sole shareholder (placeholder E1 as entrepreneur, organisation
ORG-1) adopts a shareholders' resolution (GVB) — for example, the approval
of an expense allowance. The articles of association require resolutions to be passed in
text form. E1 asks: Can I do this in the Git repo — and what does a
resolution look like that an auditor will later recognise as "passed in text form"?
What § 126b BGB Requires
§ 126b BGB (Text Form): "If the written form is not prescribed by statute but the text form is provided for, the text form may be replaced by any suitable form of electronic transmission, provided that (1) the person for whom the document is intended has access to the document via the address indicated by the recipient, (2) the document is made accessible to others and is suitable for reproduction as the literal wording on a screen, and (3) the person submitting the document has clearly marked the document as originating from them in order to safeguard the interests they represent."
Three requirements, three GitCover interpretations:
| § 126b BGB | GitCover interpretation |
|---|---|
| (1) Access via the recipient's address | The tenant repo (Gitea) is the address; the recipient (shareholder, managing director) has read access |
| (2) Accessible, capable of reproducing the literal wording | The Markdown doc is the literal wording — cat, Typora, any browser renders it |
| (3) Attribution of origin ("clearly marked as originating from them") | The signature doc recognisably attributes the document to the signatory: name + role + facsimile reference in a SHA-256-anchored JSON artefact (DS02) |
Point (3) does not require a qualified signature. It requires a clear attribution of origin: the recipient must be able to recognise who is submitting the document. This is precisely where the signature doc (DS02) and the signature process (DS03) come in.
Free Assessment of Evidence (§ 286 ZPO)
Under civil procedure law, a text form document is not an event requiring strict proof — it falls under free assessment of evidence. The court weighs whether the available evidence "forms a conviction according to free conviction". This means:
- There is no rigid form that "suffices" — there are only more or less convincing proofs.
- A gapless, audit-proof documented process (who submitted the document, when, with which key/which graphic, and how integrity could be verified) is more convincing than a single "signature receipt".
- Conversely: a one-off screenshot of an email signature is hardly convincing; a SHA-256-backed, catalogued artefact set is.
GitCover translates this into a chain that is friendly to the assessment of evidence:
- Integrity: SHA-256 of the source document, the signature doc, the sidecar.
- Attribution of origin: the signature doc identifies the signatory (name, role, key/graphic reference) and links to the source document via SHA-256.
- Temporal ordering: uuidV7 timestamps in every artefact (RFC 9562).
- Cataloguing: the V7GUID class taxonomy in the sidecar; an auditor can recognise the artefact type without contextual knowledge.
- Auditability: the Git history is not the only piece of evidence — the chain can also be verified without Git (using jq, sha256sum, any editor).
§ 371a ZPO — the private document in electronic form
§ 371a ZPO: "Private documents in electronic form have the evidentiary force of private documents in written form if the issuer attaches their name and indicates that the declaration is submitted in electronic form, or if they are provided with a qualified electronic signature or a comparable certified seal."
Three observations for the GitCover approach:
- Attaching the name + indicating the form suffice — the signature doc (DS02) does exactly that: the signatory's name/role + an explicit form indication ("submission of the declaration in electronic form").
- QES is the iron-clad alternative — if a contract is to have evidentiary force as a private document with a QES, the FES qualification attaches (Part II). Even then, however, the text form basis remains at the repo level.
- The evidentiary value lies in the chain — not in a single feature. DS04 shows the complete verification routine.
The Most Common Mistake: The Email Signature
The practical constellation that GitCover wants to avoid:
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
Breaks in the chain of proof: no SHA-256, no timestamp, no role attribution, no auditability — the "original" wanders between printer, scanner and mail client. A GitCover doc avoids this by making every step an artefact in the repo.
Summary
- § 126b BGB requires access + literal wording + attribution of origin — the MD doc + signature doc fulfil this natively in Git.
- Under free assessment of evidence, the gapless chain (SHA-256 + time + roles + cataloguing) is more convincing than an external signature receipt.
- § 371a ZPO confirms: attaching the name + indicating the form suffice for the evidentiary force of private documents; the QES is the iron-clad alternative, not a requirement for text form.
- The next article (DS02) defines the signature doc as a JSON schema.
Created: 260913 | Part I, Article DS01 | Series: digital-signage