DS03 — The Signature Process (Accept/Deny/Sign)
Trigger S2
Once the signature doc (DS02) is defined, the examiner asks the right question: What has actually been decided? A signature doc only says: "E1 signs Doc X." The process — acceptance (Accept), rejection (Deny), signing (Sign), withdrawal (Withdraw) — is an event in its own right with its own chronology.
State machine of the signature process
A process passes through a deterministic state machine:
Every state change is an event artifact in the repo — a JSON
document according to 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"
}
}
The chaining: prev_event_sha256
Every event references its predecessor event — the signature history
forms a SHA-256 chain (GCPN principle prev_sha256, here at event level):
offered (event 1) ──► accepted (event 2) ──► signed (event 3)
│ │ │
sha256 sha256 sha256
└── prev=null ─────────┴── prev=sha(ev1) ───┴── prev=sha(ev2)
An examiner can verify the entire history with three commands:
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?
The event types
| Event | Meaning | Evidentiary value |
|---|---|---|
offered |
Signature requested (document presented for signing) | Starting point of the deadline, procedural fairness |
accepted |
Recipient has taken note (text-form access confirmed) | § 126b (1): access proven |
denied |
Recipient declines (with justification) | Documents the refusal — important in case of contradictory versions |
sign |
Signatory signs (Facsimile/key reference) | § 371a ZPO: affixing of name + form notification |
withdraw |
Signatory withdraws (before forfeiture) | Audit-proof withdrawal instead of silent deletion |
No silent-deletion principle: An event is never deleted or overwritten. A withdrawal is a
withdrawevent — the history remains complete (GoBD principle: traceability).
Multi-signature: Two signatories, one source document
In a GVB with two signature lines, each signatory generates their own event chain on the same source document:
Quell-Dokument (sha256 T)
├── E1: offered → accepted → signed (Kette A)
└── PARTNER-1: offered → accepted → signed (Kette B)
The verification (DS04) checks both chains independently — and the GCPN container (DS05) bundles both under one container ID.
Determinism
Every event is deterministically describable: uuidV7 from timestamp +
SHA-256 of the event, a state machine without indeterminate transitions, no
free text apart from the statement declaration. That is the saga quality:
the process can be retraced by any examiner repeatedly and without
contextual knowledge.
Summary
- The signature process is a state machine (drafted → offered → accepted/denied → signed → withdrawn).
- Every state change is a JSON event (schema
signature-event-1.0) with a SHA-256 chain (prev_event_sha256). - Events are never deleted — withdrawal is an event, not a deletion.
- Next article (DS04): the examiner's verification routine.
Created: 260913 | Part I, Article DS03 | Series: digital-signage