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

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

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 their own place per document, namely 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) changes 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: a Signature Artifact per Document (*.gcsig.md)

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

• 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 an entertainment receipt), the OCR provenance (ocr, TrustVector bit vector), the signature block (signature, with facsimile), and an integrated Sidecar block (source) — thus, for signed receipts, it replaces the separate .gc.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.
• Can exist already in the draft (phase draft); signer/gpg are set only 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 its own lifecycle step). 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 cycle-free from the subject identity (document base name/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 — because it is identity-based rather than content-based — is stable. Status, process, and events are located exclusively in the signature artifact and/or GCPN.

Distinction from Neighboring Artifacts

The GCSIG as Sidecar — and the Transition .gc.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 Sidecar: it then carries (like a .gc.md) the content anchor (SHA-256), the docUid, and the metadata and the signature lifecycle in one artifact. A separate .gc.md is not mandatory for this.

2. Transition .gc.md → .gcsig.md (signed PDF). If a PDF (or similar) is signed, the cataloging .gc.md can transition into a .gcsig.md. In this process, no information is lost — the Sidecar content (anchor, docUid, class, metadata) is migrated 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). There must be no competing Sidecars existing alongside one another — the content is migrated, 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 of a .gc.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), however, 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 information; 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 .gc.md may transition into a .gcsig.md — no loss of information (migrate content), but changed Ur-Doc status/use; no competing Sidecars.

Cross-references

• Part I — Text form — Ur-Doc, Sidecar, signature doc, and 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