DS10 — The FES Container Package (gcpn.zip)

Trigger S4, Conclusion of Part II

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

Manifest and ZIP Archive — Two Separate Tasks

Task Carrier Content
Manifest the .gcpn.md itself Lists all artifacts with SHA-256 (verification table + embedded JSON artifacts) — it identifies what belongs to the process
ZIP archive *.gcpn.zip The physical files for delivery: the text-based artifacts (extracted from the .gcpn.md as .json/.txt/.md/.v7g.md) plus the binary artifacts as separate files

Text-based artifacts (.json, .txt, .md, .v7g.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 or identified as a SHA-256 hash in the JSON artifact data structures (e.g. evidence.facsimile_ref.sha256) — the hash is the identification, the ZIP provides the body.

The Package Structure

GCPN-SIG-260913-001.gcpn.zip
│
├── container.gcpn.md                      ← Manifest + textbasierte Artefakte (JSON-Fences) + .v7g.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.v7g.md                      ← Sidecar
├── signature/                             ← textbasiert: Signatur-Doc + Events (aus MD-Fences)
│   ├── signature-doc.json                 ← Signatur-Doc (DS02) + .v7g.md
│   ├── event-offered.json                 ← Events (DS03) + .v7g.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) + .v7g.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 its SHA-256 — the ZIP provides the bodies for them. Text-based artifacts are contained in the manifest itself (and additionally extracted as individual files in the ZIP); binary artifacts exist physically only in the ZIP, but are fully identified in the manifest by their SHA-256. An examiner can therefore verify every body against the hash stated 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",
  "uuidV7": "<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 (core saga rule):

Procedure Facsimile in the Package Rationale
Text form (Part I) Reference (SHA-256 + guid stamp) The graphic resides in the PII directory of the tenant repo; the chain references it, the package documents the reference
FES (Part II) Physical (SVG + PNG) The package is the complete delivery; the examiner needs the graphic for verification, without repo access

The difference is intentional: with text form, the asset remains where it is maintained in a GoBD-relevant manner (PII directory, sidecar, SHA verification); with 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 examiner 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 representations of the same container:

Form Name Role
In the Git repo <Referenced-Doc-Basisname>.gcpn.md The container itself — its embedded JSON artifacts + verification table are the manifest (the repo shows the content directly; ZIP files cannot be represented in Git)
As export <Referenced-Doc-Basisname>.gcpn.zip Physical delivery (ZIP) — additionally with MANIFEST.json (all SHA-256 + package_sha256) as a machine-readable directory

Is the manifest definition thus valid? Yes — in both forms: in the Git repo, the .gcpn.md fulfills the manifest function (it lists every artifact with SHA-256, and the verification routine checks against the embedded details); in the export ZIP, the same manifest function is additionally included physically 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).

Suffix Meaning
.gcpn GitCover PrimaNota container (business matters bundled)
.md Markdown-based (JSON artifacts in MD fences, Typora-compatible) — manifest function in the repo
.zip Export form (physical delivery, MANIFEST.json attached)

The Saga Concludes Part II

The circle is closed:

  1. Part I: Text-form chain (source document, signature doc, events, sidecars, GCPN container) — § 126b BGB, free evaluation of evidence.
  2. Part II: FES docking (eIDAS levels, facsimile layer, signature plate, envelope report, physical package).
  3. Part III (planned): PII/GPG circle — 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 layer; external procedures dock on without breaking the chain.


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