Part VI — Git-signed Documents: the Signature Artifact (GCSIG)

Trigger S6: A contract is to be signed Git-natively. But even before the signing, it must be traceable to whom the document was presented when, when it was approved, and when it was signed. Where is this recorded if the Ur-Doc itself must remain unchangeable?

The Problem: Events Need a Place

Parts I–III show how a document (Ur-Doc), its metadata (sidecar), its signature docs/events, and the process (GCPN) interact. But one sore point remains open: the events of an individual document — presentation (presented), approval (accepted), signing (signed) — need a place of their own per document, and indeed from the draft onward.

The Ur-Doc itself must not carry this place. Once it is signed, it is immutable: any later change (even of a mere status flag) alters its SHA-256 and thereby invalidates a signature that has already been made. Even the draft can be the final version; accordingly, no status, no history, no process note belongs in the Ur-Doc.

The Solution: One Signature Artifact per Document (*.gcsig.md)

Every .md Ur-Doc intended for signature has, from the draft onward, a signature artifact {name}.gcsig.md:

• V7GUID class GCSIG, schema gcsig-1.4. Since 1.4, the GCSIG can embed the Ur-Doc content (content, e.g. business-meal-receipt-1.0 for a hospitality receipt), the OCR provenance (ocr, TrustVector bit vector), the signature block (signature, with facsimile), and an integrated sidecar block (source) — thereby, for signed receipts, it replaces the separate .v7g.md (see below). 1.3/1.2/1.1/1.0 remain valid legacy schemas.
• Mutable phase container (like the GCPN): The signature lifecycle is maintained as a 32-bit phase bit vector; state changes are simple bit operations.
• Content anchor: subject.sha = SHA-256 of the Ur-Doc. The artifact is thereby bound to the specific version and is history-rewrite-proof.
• Already in the draft (phase draft) it can exist; signer/gpg are only set at signing.

Creation (tool gc-docsign):

gc-docsign gcsig --doc "<ur-doc.md>"            # ab Entwurf, Phase draft
gc-docsign gcsig --doc "<ur-doc.md>" --phase presented
gc-docsign gcsig --doc "<ur-doc.md>" --phase accepted
gc-docsign gcsig --doc "<ur-doc.md>" --phase signed --key <fingerprint>

The Phase Bit Vector

The bits accumulate via OR in phases.phases_result; current_phase is derived by precedence (revoked > superseded > … > draft). verified is an orthogonal modifier (not a lifecycle step of its own). This flag semantics corresponds to the specification "events as bit vector" (no union type, since cumulative).

The Signature Block in the Ur-Doc

The Ur-Doc remains immutable but, after the signature block, receives an explanatory section ## Signatur (GCSIG) that names the associated signature artifact:

## Signatur (GCSIG)

Diese Vereinbarung ist für **GC-Signatur** erstellt. …

- **Signatur-Artefakt (GCSIG):** `<uuidV7>`      ← der „Name" (docUid)
- **Titel:** `<basename>.gcsig.md`               ← Dateiname
- **Verfahren:** Textform (§ 126b BGB) mit Facsimile; GC-Signatur (GPG / signierter Git-Commit)
- **Zeichner:** <Name> (Rolle)

The uuidV7 (= docUid of the GCSIG) is derived in a cycle-free manner from the subject identity (document basename/contract ID) — not from the SHA of this document — so that it may appear in the Ur-Doc without making the signature anchor unstable. A mere filename reference would be possible; however, the cited uuidV7 makes the artifact identifiable by name and is — because it is identity-based rather than content-based — stable. Status, process, and events reside exclusively in the signature artifact and/or GCPN.

Distinction from the Neighboring Artifacts

The GCSIG as Sidecar — and the Transition .v7g.md → .gcsig.md

The signature artifact is not a mere supplementary document. Two cases must be distinguished:

1. Sidecar function (native MD Ur-Doc). If the signed Ur-Doc is present natively as Markdown — no scan, no PDF, no photo — the *.gcsig.md can also serve as a sidecar: it then carries (like a .v7g.md) the content anchor (SHA-256), the docUid, and the metadata and the signature lifecycle in one artifact. A separate .v7g.md is not mandatory for this.

2. Transition .v7g.md → .gcsig.md (signed PDF). If a PDF (or similar) is signed, the previous, cataloging .v7g.md can become a .gcsig.md. In the process, no information is lost — the sidecar content (anchor, docUid, class, metadata) is transferred into the signature artifact. But the status of the Ur-Doc and its use change: a merely cataloged receipt becomes a signed Ur-Doc with its own signature lifecycle (phase bit vector). No competing sidecars may exist side by side — the content is transferred, not duplicated.

In short: the GCSIG is the one place where the signature of this document lives — whether as a pure signature artifact, in a sidecar role, or as the successor to a .v7g.md.

The signature artifact is referenced by the GCPN via the tree edge (GCSIG:{docUid}); conversely, it names its process via gcpn_ref. For Git objects (commit/tree/tag/PR), by contrast, the GCSIG remains an immutable artifact (gc-docsign gcsig <repo> --commit <sha>).

Rules (normative)

1. For each Ur-Doc intended for signature, a *.gcsig.md is created from the draft onward (schema gcsig-1.4); without this artifact, the events cannot be recorded.
2. The Ur-Doc remains immutable: no status, no process/history/self-hash details; only the ## Signatur (GCSIG) block with a filename reference.
3. Status/events live in the signature artifact and/or GCPN.
4. A *.gcsig.md from a gc signature (commit signature) is an immutable Ur-Doc; the per-document artifact (document), by contrast, is a mutable phase container.
5. For a native MD Ur-Doc, the *.gcsig.md can also be a sidecar (metadata + lifecycle in one artifact). For a signed PDF, the previous .v7g.md may become a .gcsig.md — no loss of information (transfer the content), but a changed Ur-Doc status/use; no competing sidecars.

Cross-references

• Part I — Text Form — Ur-Doc, sidecar, signature doc, GCPN.
• Part II — FES & Facsimile — FES docking, facsimile layer.
• Part IV — PII, GPG & Governikus — key level.
• Tool and schema: work/OSS/gc-docsign (docs/gcsig.md), schema gcsig-1.4 (OSS normative root .gitcover/schemas/).

---

Created: 261008 | Publisher: ORG-1 (placeholder) | Series: digital-signage