DS03 — Der Signatur-Vorgang (Accept/Deny/Sign)

Auslöser S2

Nachdem der Signatur-Doc (DS02) definiert ist, stellt der Prüfer die richtige Frage: Was wurde denn nun entschieden? Ein Signatur-Doc sagt nur: "E1 zeichnet Doc X." Der Vorgang — Annahme (Accept), Ablehnung (Deny), Zeichnung (Sign), Rücknahme (Withdraw) — ist ein eigenes Ereignis mit eigener Chronologie.

Zustandsmaschine des Signatur-Vorgangs

Ein Vorgang durchläuft eine deterministische Zustandsmaschine:

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% stateDiagram-v2 [*] --> drafted: Quell-Dokument erstellt drafted --> offered: Signatur angefordert offered --> accepted: Empfänger nimmt zur Kenntnis (Accept) offered --> denied: Empfänger lehnt ab (Deny) accepted --> signed: Zeichner zeichnet (Sign) signed --> withdrawn: Zeichner zieht zurück (Withdraw, vor Frist) denied --> [*] withdrawn --> [*] signed --> [*]

Jede Zustandsänderung ist ein Event-Artefakt im Repo — ein JSON-Dokument nach Schema signature-event-1.0:

{
  "$schema": "https://gitcover.org/schemas/signature-event-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7>",
  "type": "signature-event",
  "event": "sign",
  "actor": {
    "name": "Erich Mustermann",
    "role": "Geschäftsführer",
    "capacity": "handelnd für PARTNER-ORG"
  },
  "on": {
    "signature_doc_sha256": "<SHA-256 des Signatur-Docs (DS02)>",
    "target_doc_sha256": "<SHA-256 des Quell-Dokuments>"
  },
  "prev_event_sha256": "<SHA-256 des vorherigen Events, null beim ersten>",
  "statement": "Ich zeichne das Dokument in der angegebenen Funktion und bestätige den in der Textform übermittelten Wortlaut.",
  "evidence": {
    "facsimile_ref": {
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "guid_stamp": "01a09b48-4580-76f9-b789-024691b989c5"
    },
    "timestamp_utc": "2026-09-13T15:20:00Z"
  }
}

Die Verkettung: `prev_event_sha256`

Jedes Event verweist auf sein Vorgängerevent — die Signatur-Historie bildet eine SHA-256-Kette (GCPN-Prinzip prev_sha256, hier auf Event-Ebene):

offered (event 1) ──► accepted (event 2) ──► signed (event 3)
     │                      │                     │
   sha256                 sha256                sha256
     └── prev=null ─────────┴── prev=sha(ev1) ───┴── prev=sha(ev2)

Ein Prüfer kann mit drei Befehlen die gesamte Historie verifizieren:

sha256sum ev1.json                       # stimmt mit prev in ev2?
jq -r '.event' ev*.json | sort           # Zustandsfolge korrekt?
jq -r '.actor.name' ev*.json | sort -u   # Zeichner konsistent?

Die Event-Typen

Event	Bedeutung	Beweiswert
`offered`	Signatur angefordert (Dokument zum Zeichnen vorgelegt)	Startpunkt der Frist, Verfahrens-Fairness
`accepted`	Empfänger hat zur Kenntnis genommen (Textform-Zugriff bestätigt)	§ 126b (1): Zugriff nachgewiesen
`denied`	Empfänger lehnt ab (mit Begründung)	Dokumentiert die Ablehnung — wichtig bei widersprüchlichen Fassungen
`sign`	Zeichner zeichnet (Facsimile-/Schlüssel-Verweis)	§ 371a ZPO: Namensbeifügung + Form-Anzeige
`withdraw`	Zeichner zieht zurück (vor Verwirkung)	Revisionssichere Rücknahme statt stiller Löschung

Kein Silent-Lösch-Prinzip: Ein Event wird nie gelöscht oder überschrieben. Eine Rücknahme ist ein withdraw-Event — die Historie bleibt vollständig (GoBD-Grundsatz: Nachvollziehbarkeit).

Multi-Signatur: Zwei Zeichner, ein Quell-Dokument

Bei einer GVB mit zwei Unterschriftenlinien erzeugt jeder Zeichner seine eigene Event-Kette auf dasselbe Quell-Dokument:

Quell-Dokument (sha256 T)
   ├── E1: offered → accepted → signed (Kette A)
   └── PARTNER-1: offered → accepted → signed (Kette B)

Die Verifikation (DS04) prüft beide Ketten unabhängig — und das GCPN-Container (DS05) bündelt beide unter einer Container-ID.

Determinismus

Jedes Event ist deterministisch beschreibbar: uuidV7 aus Zeitmarke + SHA-256 des Events, Zustandsmaschine ohne unbestimmte Übergänge, kein freier Text außer der statement-Deklaration. Das ist die Saga-Qualität: Der Vorgang kann von jedem Prüfer wiederholt und ohne Kontextwissen nachvollzogen werden.

Zusammenfassung

Der Signatur-Vorgang ist eine Zustandsmaschine (drafted → offered → accepted/denied → signed → withdrawn).
Jede Zustandsänderung ist ein JSON-Event (Schema signature-event-1.0) mit SHA-256-Kette (prev_event_sha256).
Events werden nie gelöscht — Rücknahme ist ein Event, kein Löschvorgang.
Nächster Artikel (DS04): die Verifikationsroutine des Prüfers.

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