Part I — Text Form

Trigger S1/S2: A GVB is to be drawn up in text form; afterwards, an auditor asks about the authenticity. Part I defines 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	The Text Form Requirement and Free Assessment of Evidence	What does § 126b BGB actually require — and what suffices under free assessment of evidence?
DS02	The Signature Doc as a Data Type (JSON Schema)	How do we describe "signature" as a machine-readable artifact in the repo?
DS03	The Signature Process (Accept/Deny/Sign)	How is a signing process documented deterministically and in an audit-proof manner?
DS04	Sidecar Cataloging and Verification Chain	How does an auditor verify authenticity and integrity — without reading the Git history?
DS05	The GCPN Signature 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 (.v7g.md, SHA-256 + V7GUID cataloging), and, for business transactions, a GCPN container. The signature docks onto exactly this pattern:

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

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

Why No DocuSign from the Start?

Three reasons against the premature integration of external signature services:

Cost & friction: The majority of an SME's everyday documents (GVB, internal procedure documentation, receipts) does not need a qualified signature — text form suffices (§ 126b BGB: "may be replaced by text form").
Evidence chain breaks: Every external service creates its own history (envelope IDs, audit trails in the provider's cloud). The chain of evidence leaves the repo — precisely where GitCover promises GoBD audit security.
One-third threshold of evidentiary force: Under free assessment of evidence (§ 286 ZPO), a well-documented internal chain (SHA-256 chain + timestamps + identified signer role) often carries more weight than a "signature receipt" from a provider whose procedure is not disclosed.

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

Legal Framework (Short Quotes)

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

Disclaimer: No legal advice. The assessment in each individual case remains subject to free assessment 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 assessment of evidence.
DS02 — The JSON schema of the signature doc (the "signature" data type in the filesystem).
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