DS02 — The Signature Doc as a Data Type (JSON Schema)

Trigger S1, Continued

E1 has adopted a resolution (GVB) in Markdown. Now he needs an artifact that makes identifiable: I, E1, sign this document on date X in my role as Y. The artifact must be machine-readable, schema-validated, and revision-safe — a JSON artifact according to GCBoK rule 1 ("JSON-First") and rule 4 ("Schema-First").

The Data Type `signature-1.0`

The JSON schema defines a signature as a standalone document in the repo — not as an attachment, not as mail text. Core structure (simplified):

{
  "$schema": "https://gitcover.org/schemas/signature-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7 aus ts+doc-sha256>",
  "type": "signature",
  "subject": {
    "name": "Erich Mustermann",
    "role": "Geschäftsführer",
    "capacity": "handelnd unter Befreiung von § 181 BGB",
    "entity": "PARTNER-ORG"
  },
  "target": {
    "kind": "gvb",
    "title": "GVB 260825 — GF-Vertrag: Selbständigkeit",
    "sha256": "<sha256 des Quell-Dokuments>",
    "location": "\\\\vm1\\data\\org1\\repo-top\\res\\260825-shareholder-meeting-resolution.md"
  },
  "procedure": {
    "form": "textform",
    "statute": "§ 126b BGB",
    "legal_basis_ref": "GVB 260825, TOP 'Beschlussfassung in Textform'",
    "expression": "Abgabe der Erklärung in elektronischer Form (§ 371a ZPO)"
  },
  "evidence": {
    "facsimile_ref": {
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "guid_stamp": "01a09b48-4580-76f9-b789-024691b989c5"
    },
    "timestamp_utc": "2026-09-13T15:00:00Z",
    "timestamp_source": "uuidV7-RFC9562"
  }
}

The Mandatory Fields in Detail

Field Group	Required	Purpose
`uuidV7`	yes	Deterministic ID from timestamp + doc-sha256 (gen-doc) — guid stamp for "accepted"/"signed"
`subject`	yes	Signatory: name, role, power of representation, corporation
`target`	yes	Source document: title, SHA-256, UNC path — the signature attaches to one concrete version
`procedure`	yes	Procedure: textform/FES, legal norm, form notice (§ 371a ZPO)
`evidence`	yes	Facsimile reference (SHA-256 + guid stamp of the signature graphic), timestamp
`signing_key_ref`	optional	Only in Part III (PII/GPG circle) — key reference, not in Parts I/II

Schema-First rule: Before each entry, check whether a schema exists; if it is missing, it is created. The signature doc follows the same pattern as diary-entry, v7g-sidecar, and GCPN containers.

V7GUID Cataloguing

The signature doc receives its own V7GUID class taxonomy in the sidecar (similar to SIGNATURE_GRAPHIC for the graphic assets):

Class	Purpose
`SIGNATURE_DOC`	The signature doc itself (JSON artifact)
`SIGNATURE_GRAPHIC`	The facsimile graphic (PNG/SVG) — already registered on 260913
`SIGNATURE_EVENT`	The signature process (Accept/Deny/Sign) — DS03

Each class is a promote candidate for the OSS normative root (work/OSS/TOP/.gitcover/dictionaries/classes.json), analogous to the 260821 pilot (HR_REGISTER_DOC, RECEIPT_DOC, etc.).

Why the Signature Is a Document in Its Own Right

Three design decisions that drive the saga:

Separation of content and declaration of intent — the source document remains unchanged (immutable doc); the signature is a separate artifact that attaches itself via SHA-256 to the concrete version. A typo in the source document does not invalidate the signature layer; a new version creates a new signature.
Multiple signing — several signatories create several signature docs on the same source document (e.g., a GVB with two signature lines). The verification checks all signature docs against the same source document SHA.
FES dockability — the FES signature (Part II) does not replace the signature doc but complements it: the signature doc remains the repo layer, and the FES doc (envelope report, PDF) is referenced as a further artifact.

Facsimile Reference (Not Embedding)

Important for the saga quality: the signature doc does not embed the signature graphic physically. It references it — via SHA-256 and guid stamp (E1.Signature.transparent.FES.svg, sha256 8fcffe0b…, guid 01a09b48-4580-76f9-b789-024691b989c5). This keeps the chain light: graphic, source document, and signature doc are independently verifiable; the probative value lies in the verification, not in the embedding.

The physical embedding (facsimile in the PDF layer, DocuSign-style) is Part II — there, where the FES signature creates its own PDF doc.

Summary

The signature doc is a JSON artifact (schema signature-1.0) with the mandatory fields subject, target, procedure, evidence.
It attaches via SHA-256 to a concrete version of the source document.
The facsimile graphic is referenced (SHA-256 + guid stamp), not embedded — embedding is FES subject matter (Part II).
Next article (DS03): the signature process as an event.

Created: 260913 | Part I, Article DS02 | Series: digital-signage