DS03 — The Signature Process (Accept/Deny/Sign)

Trigger S2

After the Signature Doc (DS02) is defined, the auditor 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 a separate event with its own chronology.

State Machine of the Signature Process

A process runs through a deterministic state machine:

%%{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 --> [*]

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",
  "docUid": "<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",
      "docUid": "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 auditor 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 rejects (with reasons)	Documents the rejection — important for conflicting versions
`sign`	Signer signs (Facsimile/key reference)	§ 371a ZPO: name addition + form indication
`withdraw`	Signer 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 withdraw event — the history remains complete (GoBD principle: traceability).

Presentation (`offered`/presented): Stage original docs + commit message

When presenting for signing, the relevant original docs are staged in the Git repo (git add) — so the Git index clearly delimits what is to be signed, separate from the rest of the working state. For this, a German commit message is prepared that lists the original docs to be signed with SHA-256 (HITL and contract text are in German).

gc-docsign present <ur-doc.md> … --repo <dir>          # stagt Ur-Docs, schreibt .git/PRESENTED-COMMIT-MSG.txt
gc-docsign gcsig --doc "<ur-doc.md>" --phase presented  # Phase `presented` setzen

No commit by the tool (NO-AUTO-COMMIT): the scoped, GPG-signed commit is made by the signer (see GCSIG).

Multi-Signature: Two Signers, One Source Document

For a GVB with two signature lines, each signer creates their own event chain for 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, state machine without indeterminate transitions, no free text except the statement declaration. That is the saga quality: the process can be traced by any auditor 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 auditor's verification routine.

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