DS05 — The GCPN Signature Container: Source Document, FES Doc, Process

Trigger S2, Conclusion of Part I

E1 now has three separate artifacts: the source document (MD), the signature doc (JSON), the events (JSON). The auditor asks: How does this fit together? The answer is the GCPN signature container — a variant of the GitCover PrimaNota container (GCPN) that bundles all artifacts of a signature process under one container ID.

GCPN — the Container Principle

GCPN (GitCover PrimaNota) links all documents of a business transaction in the records system: original document, sidecars, posting logic. The signature container transfers the principle to the signature process:

GCPN-Container (sign)
   ├── Quell-Dokument (MD) + Sidecar
   ├── FES-Signatur-Doc (JSON) + Sidecar        ← referenziert
   ├── FES-Output (PDF/HTML, physisch)          ← nur bei FES-Verfahren
   ├── Events (offered/accepted/signed) + Sidecar
   ├── Facsimile-Grafik-Verweis (SHA-256 + guid-Stempel)
   └── Verifikationsmanifest (SHA-256 aller Glieder)

The Container File

The container itself is a Markdown document with an embedded JSON artifact (like all GitCover docs):

{
  "$schema": "https://gitcover.org/schemas/gcpn-signature-1.0.schema.json",
  "docUid": "<deterministische uuidV7>",
  "type": "gcpn-signature",
  "kind": "signature-process",
  "container_id": "GCPN-SIG-260913-001",
  "scope": {
    "tenant": "GCC",
    "entity": "ORG-1",
    "matter": "[GVB](../../glossar.html#gvb "Gesellschafterversammlungsbeschluss — Glossar") 260825 — GF-Vertrag: Selbständigkeit, Ehrenamt",
    "sphere": "wirtschaftlich"
  },
  "artifacts": [
    {
      "role": "source",
      "kind": "markdown",
      "location": "..\\260825-shareholder-meeting-resolution.md",
      "sha256": "<SHA-256>",
      "sidecar": "..\\260825_*.md.gc.md"
    },
    {
      "role": "signature-doc",
      "kind": "json",
      "location": "260913_signature-doc.json",
      "sha256": "<SHA-256>",
      "sidecar": "260913_signature-doc.json.gc.md"
    },
    {
      "role": "event",
      "kind": "json",
      "events": ["offered", "accepted", "signed"],
      "location": "260913_event-*.json",
      "sha256": "<SHA-256 je Event>",
      "sidecar": "260913_event-*.json.gc.md"
    },
    {
      "role": "facsimile-ref",
      "kind": "ref",
      "file": "E1.Signature.transparent.FES.svg",
      "sha256": "8fcffe0b313f8a1e5b44c1c33cd8073e699b338b6450aa1ba9f33f5587501006",
      "docUid": "01a09b48-4580-76f9-b789-024691b989c5",
      "note": "Verweis, nicht Einbettung — Grafik liegt im [PII](../../glossar.html#pii "Personally Identifiable Information — Glossar")-Verzeichnis"
    },
    {
      "role": "fes-doc",
      "kind": "pdf",
      "location": "260913_FES_Envelope-Report.pdf",
      "sha256": "<SHA-256>",
      "note": "Nur bei FES-Verfahren — physisch im Container-Paket (Teil II)"
    }
  ],
  "prev_container": null,
  "next_container": null,
  "verification": {
    "method": "sha256 + jq routine (DS04)",
    "verified_at": "2026-09-13T16:00:00Z",
    "verified_by": "E1"
  }
}

"Initially without Predecessor/Successor" — the Design Stage

Important for saga quality: The container has the fields prev_container/next_container, but they are null. This is intentional — two development stages:

The fields already exist so that later chaining is possible without breaking the schema. A container remains immutable — chaining creates a new container with prev_container = sha256(alt).

The Container in Three Roles

HTML Output and the Container Package

For HTML output (GCBoK website, preview), the container is delivered physically as a package:

<container-id>.gcpn.zip
   ├── container.md              (dieser Container)
   ├── source.md + .gc.md
   ├── signature-doc.json + .gc.md
   ├── event-*.json + .gc.md
   ├── facsimile.svg             (bei FES: physisch, sonst Verweis)
   └── fes-envelope-report.pdf   (nur bei FES)

The package is self-verifying: The auditor unpacks it and runs the routine from DS04 — without repo access, without Git.

Summary

• The GCPN signature container bundles all artifacts of a signature process under one container ID with a verification manifest.
• prev_container/next_container are prepared (schema-fixed), but initially null — chaining is Stage 2.
• The FES Doc is referenced; the physical FES version (PDF) is in the container package (Part II).
• Part I concludes here. Part II connects FES: eIDAS fundamentals, facsimile graphic in the PDF layer, envelope report, container package.

---

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