Part I — Text Form

Trigger S1/S2: A GVB is to be drawn up in text form; afterwards an auditor asks about authenticity. Part I establishes the document level: MD doc

JSON artifacts in the repo, without external signature services.

Overview of the articles (DS01–DS05)

Art.	Title (DE)	Core question
DS01	Das Textform-Erfordernis und die freie Beweiswürdigung	What does § 126b BGB really require — and what suffices under free evaluation of evidence?
DS02	Der Signatur-Doc als Datentyp (JSON-Schema)	How do we describe "signature" as a machine-readable artifact in the repo?
DS03	Der Signatur-Vorgang (Accept/Deny/Sign)	How is a signing process documented deterministically and in an audit-proof manner?
DS04	Sidecar-Katalogisierung und Verifikationskette	How does an auditor verify authenticity and integrity — without reading the Git history?
DS05	Der GCPN-Signatur-Container	How do we attach all artifacts (source document, FES doc, process) to an MD document?

The basic idea: signatures as repo artifacts

A document in the GitCover system is not a file but an artifact set: the MD file (source document), a sidecar (.gc.md, SHA-256 + V7GUID cataloguing), and, for business transactions, a GCPN container. This is exactly the pattern the signature attaches to:

Quell-Dokument (MD)                .gc.md Sidecar            GCPN-Container
   │                           │                          │
   │ sha256                    │ sha256(Quell-Dokument)           │ referenziert alle
   │                           │ V7GUID                   │ Artefakte des Vorgangs
   ▼                           ▼                          ▼
Signatur-Doc (JSON) ──── Accept/Sign-Event ──────── GCPN-Signatur-Container

Every artifact follows a JSON schema (schema-first rule of the GCBoK), every relationship is a SHA-256 reference, every process is a deterministically describable event. An auditor can verify the entire chain with sha256sum and jq — without Git history, without proprietary tools.

Why not DocuSign from the start?

Three reasons against prematurely connecting external signature services:

Cost & friction: Most of an SME's everyday documents (GVB, internal procedure documentation, receipts) do not need a qualified signature — text form suffices (§ 126b BGB: "can be replaced by text form").
Breaks in the chain of evidence: Every external service creates its own history (envelope IDs, audit trails in the provider's cloud). The chain of evidence leaves the repo — exactly where GitCover promises GoBD audit security.
One-third threshold of probative value: Under free evaluation of evidence (§ 286 ZPO), a well-documented internal chain (SHA-256 chain + timestamp + identified signer role) often carries more weight than a provider's "signature bonus" whose procedure is not disclosed.

FES integration (Part II) comes into play precisely when an external contractual partner requires it — not as an end in itself.

Legal framework (short citation)

Norm	Statement	GitCover interpretation
§ 126b BGB	Text form: "that form of electronic transmission with which the document is made accessible to others and is suitable for reproduction as wording on a screen"	The MD file in the repo can be reproduced as wording; the signature doc makes the intent identifiable
§ 371a ZPO	Private documents with an eS are deemed properly signed "if the issuer adds their name"	The name in the signature doc + key/graphic reference fulfils the addition of the name
eIDAS Regulation Art. 50–51	Advanced eS (AdES/AdEE), qualified eS (QES)	Part II: FES integration as a stage above text form
§ 286 ZPO	Free evaluation of evidence	The internal chain (SHA-256 + time + roles) is a fully valid piece of evidence

Disclaimer: No legal advice. Assessment in the individual case remains subject to free evaluation of evidence and, where applicable, legal counsel.

Reading order

The articles build on one another:

DS01 — Why text form suffices and what "sufficient" means under free evaluation of evidence.
DS02 — The JSON schema of the signature doc (data type "signature" in the file system).
DS03 — The signature process as an event schema (Accept/Deny/Sign).
DS04 — Sidecar verification: how the auditor checks the chain.
DS05 — The GCPN signature container: source document + FES doc + process in one artifact.

Created: 260913 | Part I of the digital-signage series