____12DS — Das Schema gcpn-container-1.0: Übersicht

Auslöser S6

Der erste echte Signatur-Vorgang (GVB-Zeichnung) erzeugte zunächst eigenständige .json-Dateien im res/-Verzeichnis — eine Arbeitsweise, die das Git-Repo aufbläht (AP-Befund: "das bloated das Git-Repo unnötig auf"). Der Befund führte zur Korrektur: Alle JSON- Artefakte in EIN Container-Doc (.gcpn.md, dauerhafte Extension), und der Container selbst wird zum normativen JSON-Schema — gcpn-container-1.0.

Das Schema im Überblick

{
  "$schema": "https://gitcover.org/schemas/gcpn-container-1.0.schema.json",
  "container_id": "GCPN-SIG-YYMMDD-NNN",
  "uuidV7": "<deterministisch aus ts + doc-sha256>",
  "kind": "signature-process",
  "tenant": { … },
  "referenced_doc": { … },
  "actor": { … },
  "attendees": [ … ],
  "persons": { … },
  "retention": { … },
  "signature": { … },
  "events": { … },
  "summary": { … },
  "prev_container": null,
  "next_container": null,
  "sidecar": "<Referenced-Doc>.gcpn.md.v7g.md"
}

Artefakt-Eindeutigkeit (Erkenntnis AP1)

Jede Entität wird genau einmal beschrieben:

Die Regeln, die aus dem Befund folgen

1. JSON immer eingebettet (MD-Fence im Container) — keine eigenständigen .json-Dateien im Repo-Baum (Bloating vermeiden).
2. Ergänzen statt neu anlegen: Jeder neue Prozessschritt setzt ein Flag, bettet das neue Artefakt ein, aktualisiert summary — bereits eingebettete JSON-Artefakte bleiben immutable.
3. Revisionssicherheit durch Git: Die Container-Historie liegt in der Git-Historie des Repos (Commit-Hash = Integritätsnachweis).
4. Mutable Doc, immutable JSON-Artefakte: Das Container-MD ist editierbar (wächst mit dem Vorgang); die JSON-Inhalte sind unveränderlich — Änderung = neues Artefakt mit neuem SHA.
5. Commits nur durch E1 (NO-AUTO-COMMIT).

Das Quell-Dokument ist über das Sidecar-Schema katalogisiert

Ein separates „Ur-Doc-Schema" ist nicht nötig: Das Schema v7g-sidecar-1.0 (.v7g.md) ist das eigentliche JSON-Schema für ein digitales Ur-/Quell-Document — es katalogisiert das Quell-Doc über sha256 (Dokument-ID, identifiziert immer und überall, auch beim Wandern), locations (UNC-Historie), v7g_taxonomy (Klasse) und obsolescence/ Retention. Der Container (referenced_doc) verweist darauf — zwei Schema-Ebenen, keine Redundanz: Sidecar = Quell-Doc-Katalogisierung, Container = Vorgang/Prozess.

Wozu die zwei Kennungen — V7GUID als Doc-Type-Register, uuidV7 als Ref-Doc-UID

Damit wird auch klarer, wozu die zwei Kennungen jeweils benötigt werden:

Diese auf den ersten Blick scheinbare Komplexität (zwei Kennungen statt einer) ist gerade der Hebel für Git-Repo-basierte Compliance ohne Vendor Lock-In: Alles lässt sich aus den Repos herleiten (deterministisch bestimmen) — nicht nur Doc-Zustände (SHA-256-Kette, Flags-Ausdruck), sondern auch Historie und Veränderungen (Git-Historie des Containers: welche Schritte wann ergänzt wurden; Sidecar-Historie: Klassifizierungs-Akte mit Zeitmarken). Kein proprietäres System speichert den Zustand — das Repo selbst ist der Zustand, und jeder Prüfer kann die Ableitung mit offenen Werkzeugen wiederholen.

Verifikation ohne Redundanz

Die Verifikationsroutine (DS04) bleibt — sie arbeitet mit dem Manifest im Container: sha256sum je Artefakt gegen events.flags_set[].sha256 bzw. referenced_doc.sha256; Kette über chain_valid; Facsimile-SHA gegen die Tabelle in SIGNATURE_BLOCK.md.

Forschungsgewinn-Protokoll (AP)

---

Erstellt: 260913 | Teil III, Artikel ____12DS | Serie: digital-signage