DS02 — Der Signatur-Doc als Datentyp (JSON-Schema)

Auslöser S1, Fortsetzung

E1 hat einen Beschluss (GVB) in Markdown gefasst. Nun braucht er ein Artefakt, das kenntlich macht: Ich, E1, zeichne dieses Dokument am Datum X in meiner Rolle als Y. Das Artefakt muss maschinenlesbar, schema-geprüft und revisionssicher sein — ein JSON-Artifact nach GCBoK-Regel 1 ("JSON-First") und Regel 4 ("Schema-First").

Der Datentyp `signature-1.0`

Das JSON-Schema definiert eine Signatur als eigenständiges Dokument im Repo — nicht als Anhang, nicht als Mail-Text. Kernstruktur (vereinfacht):

{
  "$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"
  }
}

Die Pflichtfelder im Einzelnen

Feldgruppe	Pflicht	Zweck
`uuidV7`	ja	Deterministische ID aus Zeitmarke + doc-sha256 (gen-doc) — guid-Stempel für "accepted"/"signed"
`subject`	ja	Zeichner: Name, Rolle, Vertretungsbefugnis, Körperschaft
`target`	ja	Quell-Dokument: Titel, SHA-256, UNC-Pfad — die Signatur hängt an einer konkreten Fassung
`procedure`	ja	Verfahren: textform/FES, Rechtsnorm, Form-Anzeige (§ 371a ZPO)
`evidence`	ja	Facsimile-Verweis (SHA-256 + guid-Stempel der Signatur-Grafik), Zeitstempel
`signing_key_ref`	optional	Nur in Teil III (PII/GPG-Kreis) — Schlüssel-Verweis, nicht in Teil I/II

Schema-First-Regel: Vor jeder Erfassung prüfen, ob ein Schema existiert; fehlt es, wird es erstellt. Der Signatur-Doc folgt demselben Muster wie diary-entry, v7g-sidecar und GCPN-Container.

V7GUID-Katalogisierung

Der Signatur-Doc erhält eine eigene V7GUID-Class-Taxonomy im Sidecar (ähnlich wie SIGNATURE_GRAPHIC für die Grafik-Assets):

Class	用途
`SIGNATURE_DOC`	Der Signatur-Doc selbst (JSON-Artefakt)
`SIGNATURE_GRAPHIC`	Die Facsimile-Grafik (PNG/SVG) — bereits 260913 registriert
`SIGNATURE_EVENT`	Der Signatur-Vorgang (Accept/Deny/Sign) — DS03

Jede Klasse ist ein Promote-Kandidat für den OSS-Normative-Root (work/OSS/TOP/.gitcover/dictionaries/classes.json), analog zum 260821-Pilot (HR_REGISTER_DOC, RECEIPT_DOC etc.).

Warum die Signatur ein eigenes Dokument ist

Drei Design-Entscheidungen, die die Saga treibt:

Trennung von Inhalt und Willenserklärung — das Quell-Dokument bleibt unverändert (Immutable-Doc); die Signatur ist ein separates Artefakt, das sich per SHA-256 an die konkrete Fassung hängt. Ein Tippfehler im Quell-Dokument invalidiert nicht die Signatur-Ebene; eine neue Fassung erzeugt eine neue Signatur.
Mehrfach-Signierung — mehrere Zeichner erzeugen mehrere Signatur-Docs auf dasselbe Quell-Dokument (z. B. GVB mit zwei Unterschriftenlinien). Die Verifikation prüft alle Signatur-Docs gegen dieselbe Quell-Dokument-SHA.
FES-Andockbarkeit — die FES-Signatur (Teil II) ersetzt nicht den Signatur-Doc, sondern ergänzt ihn: Der Signatur-Doc bleibt die Repo-Ebene, das FES-Doc (Envelope-Report, PDF) wird als weiteres Artefakt referenziert.

Facsimile-Verweis (nicht Einbettung)

Wichtig für die Saga-Qualität: Der Signatur-Doc bettet die Signatur-Grafik nicht physisch ein. Er verweist auf sie — über SHA-256 und guid-Stempel (E1.Signature.transparent.FES.svg, sha256 8fcffe0b…, guid 01a09b48-4580-76f9-b789-024691b989c5). Das macht die Kette leicht: Grafik, Quell-Dokument und Signatur-Doc sind unabhängig prüfbar; der Beweiswert liegt in der Verifikation, nicht in der Einbettung.

Die physische Einbettung (Facsimile im PDF-Layer, DocuSign-artig) ist Teil II — dort, wo die FES-Signatur ein eigenes PDF-Doc erzeugt.

Zusammenfassung

Der Signatur-Doc ist ein JSON-Artefakt (Schema signature-1.0) mit Pflichtfeldern subject, target, procedure, evidence.
Er hängt per SHA-256 an einer konkreten Fassung des Quell-Dokuments.
Facsimile-Grafik wird referenziert (SHA-256 + guid-Stempel), nicht eingebettet — Einbettung ist FES-Stoff (Teil II).
Nächster Artikel (DS03): der Signatur-Vorgang als Event.

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