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:
- Part I: Text-form chain (source document, signature doc, events, sidecars, GCPN container) — § 126b BGB, free evaluation of evidence.
- Part II: FES docking (eIDAS levels, facsimile layer, signature plate, envelope report, physical package).
- 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