DS10 — The FES container package (gcpn.zip)

Trigger S4, completion of Part II

The auditor (or business partner) wants to see the chain — not just a summary. They receive no repo, no Git access, no history. They receive a package: *.gcpn.zip — the physical verification set of the signing process.

Manifest and ZIP archive — two separate tasks

Text-based artifacts (.json, .txt, .md, .gc.md) live in the .gcpn.md (MD fences) — in the ZIP they are shown as individual files (extractable). Binary artifacts (PDF, PNG, SVG, …) cannot live in the MD file — they are included in the ZIP as separate files; as a rule, they are already referenced in the JSON artifact data structures or identified as an SHA-256 hash (e.g. evidence.facsimile_ref.sha256) — the hash is the identification, the ZIP supplies the body.

The package structure

GCPN-SIG-260913-001.gcpn.zip
│
├── container.gcpn.md                      ← Manifest + textbasierte Artefakte (JSON-Fences) + .gc.md
│                                            (identisch mit der Form im Git-Repo)
├── MANIFEST.json                          ← maschinen-lesbares Verzeichnis (alle SHA-256, package_sha256)
│
├── source/                                ← textbasiert: Quell-Dokument, aus dem Container extrahierbar
│   ├── gvb.md                             ← Quell-Dokument (referenced_doc)
│   └── gvb.md.gc.md                      ← Sidecar
├── signature/                             ← textbasiert: Signatur-Doc + Events (aus MD-Fences)
│   ├── signature-doc.json                 ← Signatur-Doc (DS02) + .gc.md
│   ├── event-offered.json                 ← Events (DS03) + .gc.md
│   ├── event-accepted.json
│   ├── event-signed.json
│   ├── facsimile.svg                      ← BINÄR: Grafik physisch (Standard) — im JSON nur als SHA-256 referenziert
│   ├── facsimile.png                      ← BINÄR: Fallback
│   └── facsimile.sha256                   ← Checksums
├── fes/                                   ← binäre FES-Artefakte
│   ├── fes-envelope-report.json           ← Envelope-Report (DS09) + .gc.md (textbasiert)
│   ├── contract-signed.pdf                ← BINÄR: signiertes PDF (PAdES)
│   ├── certificate-of-completion.pdf      ← BINÄR: Dienst-Report
│   └── pdfsig-report.txt                  ← Krypto-Prüfung (externes Tool)
└── README.md                              ← Verifikations-Anleitung (DS04-Routine)

Reading: The manifest (.gcpn.md) names every artifact with SHA-256 — the ZIP supplies the corresponding bodies. Text-based artifacts are contained in the manifest itself (and additionally extracted in the ZIP as individual files); binary artifacts are physically present only in the ZIP, but fully identified in the manifest by their SHA-256. An auditor can therefore verify every body against the hash specification in the manifest.

The verification manifest

MANIFEST.json bundles all SHA-256 values of the package:

{
  "$schema": "https://gitcover.org/schemas/gcpn-manifest-1.0.schema.json",
  "docUid": "<deterministische uuidV7>",
  "package": "GCPN-SIG-260913-001",
  "created_at": "2026-09-13T16:45:00Z",
  "created_by": "E1",
  "artifacts": [
    {"path": "container.md", "sha256": "…"},
    {"path": "source/gvb.md", "sha256": "…"},
    {"path": "signature/signature-doc.json", "sha256": "…"},
    {"path": "signature/event-offered.json", "sha256": "…"},
    {"path": "signature/event-accepted.json", "sha256": "…"},
    {"path": "signature/event-signed.json", "sha256": "…"},
    {"path": "signature/facsimile.svg", "sha256": "8fcffe0b…1006"},
    {"path": "signature/facsimile.png", "sha256": "d330348e…81fef"},
    {"path": "fes/fes-envelope-report.json", "sha256": "…"},
    {"path": "fes/contract-signed.pdf", "sha256": "7a054fa5…272b"}
  ],
  "verification_routine": "siehe README.md (DS04-Routine)",
  "package_sha256": "<SHA-256 des ZIP selbst>"
}

The Facsimile rule: physical for FES, reference otherwise

Important (Saga core rule):

The difference is intentional: In text form, the asset remains where it is maintained in a GoBD-relevant manner (PII directory, sidecar, SHA verification); for FES it is copied — the package is the complete version (originals remain unchanged in the repo; SHA-256 proves identity).

The verification routine in the package

README.md guides the auditor through the routine (DS04, package-native):

# 1. Manifest-Integrität
sha256sum -c <(jq -r '.artifacts[] | "\(.sha256)  \(.path)"' MANIFEST.json)
# 2. Kette prüfen (Quell-Dokument → Signatur-Doc → Events)
jq -r '.target.sha256' signature/signature-doc.json   # = sha256(source/gvb.md)
# 3. Event-Kette
jq -r '.prev_event_sha256' signature/event-*.json     # Verkettung prüfen
# 4. Facsimile
sha256sum signature/facsimile.svg                     # = 8fcffe0b…1006 (Tabelle)
# 5. PDF-Signatur (externes Tool, optional)
pdfsig fes/contract-signed.pdf                        # VALID, PAdES-B-T

Export ZIP vs. Git repo: manifest definition

Two representation forms of the same container:

Is the manifest definition therefore valid? Yes — in both forms: In the Git repo, the .gcpn.md fulfills the manifest function (it lists every artifact with SHA-256, the verification routine checks against the embedded details); in the export ZIP, the same manifest function is additionally physically included as MANIFEST.json, so that the recipient can verify without an MD parser (sha256sum -c). Both forms are equivalent — the SHA-256 of the contained artifacts is the identification (always and everywhere).

The saga closes Part II

The circle is closed:

1. Part I: Text-form chain (source document, signature doc, events, sidecars, GCPN-container) — § 126b BGB, free assessment of evidence.
2. Part II: FES docking (eIDAS-levels, Facsimile layer, signature plate, envelope report, physical package).
3. Part III (planned): PII/GPG cycle — key management, signing identity JSON schemas, SSH vs. OpenPGP mechanics, trust registry.

The saga shows: GitCover does not replace signature services — it anchors them. The repo remains the evidence level; external procedures dock on without breaking the chain.

---

Created: 260913 | Part II, Article DS10 | Series: digital-signage