DS04 — Sidecar-Katalogisierung und Verifikationskette

Auslöser S2, Fortsetzung

Der Prüfer sitzt am Bildschirm — kein Git-Client, keine Repo-Zugriffsrechte auf die Historie, nur das Arbeitsverzeichnis des Tenant-Repos (oder ein Export davon). Er will prüfen: Ist das Dokument authentisch, wer hat es signiert, ist die Kette intakt?

Das Verifikations-Set

Im Verzeichnis des Vorgangs liegen:

260825-shareholder-meeting-resolution.md         (Quell-Dokument)
260825-shareholder-meeting-resolution.md.v7g.md  (Sidecar Quell-Dokument)
260913_signature-doc.json                                  (Signatur-Doc, DS02)
260913_signature-doc.json.v7g.md                           (Sidecar Signatur-Doc)
260913_event-accepted.json                                 (Event 1, DS03)
260913_event-signed.json                                   (Event 2, DS03)
260913_event-signed.json.v7g.md                            (Sidecar Events)
E1.Signature.transparent.FES.svg                         ([Facsimile](../../glossar.html#facsimile "Facsimile-Unterschrift — Glossar")-Grafik)
E1.Signature.transparent.FES.svg.v7g.md                  (Sidecar Grafik)

Die Verifikationsroutine

Schritt 1: Quell-Dokument-Integrität

sha256sum 260825_GVB_*.md
# → muss mit .sha256 im Sidecar 260825_*.md.v7g.md übereinstimmen
jq -r '.sha256' 260825_*.md.v7g.md

Abweichung = Quell-Dokument wurde nach Sidecar-Erstellung geändert → Kette bricht.

Schritt 2: Signatur-Doc-Verweis

jq -r '.target.sha256' 260913_signature-doc.json
# → muss mit der Quell-Dokument-SHA (Schritt 1) übereinstimmen

Der Signatur-Doc hängt an einer konkreten Fassung — nicht an "dem Dokument irgendwie".

Schritt 3: Event-Kette

for f in 260913_event-*.json; do
  jq -r '"\(.event) | \(.uuidV7) | prev=\(.prev_event_sha256)"' "$f"
done
# Kette prüfen: prev von ev2 == sha256(ev1)?

Schritt 4: Facsimile-Grafik

sha256sum E1.Signature.transparent.FES.svg
# → muss mit evidence.facsimile_ref.sha256 im Signatur-Doc und im Event übereinstimmen
# → muss mit der Tabelle in PARTNER-ORG-repo/top/signature-block.md übereinstimmen

Der SHA-256-Hash IST der Beweis für Originalität — nicht der GUID-Stempel. Der SHA-256 identifiziert die Grafik immer und überall: Quell-Dokuments (und Grafiken) können wandern (Datei versetzt, kopiert, unter anderem Namen abgelegt) — die Identifikation bleibt über den SHA-256 Code bestehen, weil er aus dem Inhalt berechnet wird und pfad-/namensunabhängig ist. Der GUID-Stempel (01a09b48-4580-76f9-b789-024691b989c5) ist dagegen nur ein beigefügtes Merkmal: deterministisch aus ts+sha reproduzierbar (gc-v7guid gen-doc) und als dokumentierter Verweis nützlich — aber die Originalität und Identifizierung tragen allein der SHA-256 (und die SHA-256-Kette der Artefakte), nicht der GUID-Stempel.

Schritt 5: Sidecar-Katalogisierung

jq -r '.v7g_taxonomy[].taxonomy' *.v7g.md | sort | uniq
# → Klassen der beteiligten Artefakte (SIGNATURE_DOC, SIGNATURE_EVENT, SIGNATURE_GRAPHIC)
jq -r '.obsolescence.status' *.v7g.md
# → alle "active"? Abweichung = Artefakt ist obsolete/superseded

Die Verifikationskette als Diagramm

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TB A["Quell-Dokument (MD)
sha256 T"] --> B["Sidecar Quell-Dokument
sha256(T)"] A --> C["Signatur-Doc
target.sha256 = T"] C --> D["Sidecar
sha256(C)"] C --> E["Event offered
prev=null"] E --> F["Event accepted
prev=sha(E)"] F --> G["Event signed
prev=sha(F)"] G --> H["Facsimile-Grafik
sha256 + guid-Stempel"] D -.-> I["Prüfer: sha256sum + jq
alle Referenzen prüfen"] B -.-> I H -.-> I style I fill:#e8eef7,stroke:#2c5282

Warum ohne Git-Historie?

Drei Gründe für die historie-unabhängige Prüfung:

Export-Szenarien — der Prüfer erhält eine Verzeichnis-Kopie (ZIP, Container-Paket, DS10), nicht das Repo. Die Historie wäre nicht dabei.
GoBD-Nachvollziehbarkeit — die Nachweiskette muss auch dann bestehen, wenn das Werkzeug in 10 Jahren nicht mehr üblich sein sollte. SHA-256, JSON und Markdown sind zeitbeständig.
Unabhängigkeit der Beweisstufen — Git-Historie ist ein zusätzlicher Beweis, nicht der einzige. Die Kette (Sidecars + Events + Grafik) trägt sich selbst.

Fehlerbilder und ihre Bedeutung

Befund	Bedeutung	Konsequenz
SHA-256 des Quell-Dokuments ≠ Sidecar	Quell-Dokument nachträglich geändert	Kette bricht; Quell-Dokument ungültig für diese Signatur
Signatur-Doc verweist auf falsche Quell-Dokument-SHA	Signatur an falscher Fassung	Signatur-Doc ungültig (neue Fassung → neuer Signatur-Doc)
Event-Kette lückenhaft (prev fehlt/inkonsistent)	Vorgang unvollständig	Beweiswert reduziert; Nachweis des Zwischenzustands fehlt
Grafik-SHA ≠ Tabelle in SIGNATURE_BLOCK.md	Falsche/manipulierte Grafik	Facsimile ungültig — Signatur-Ebene betroffen
Sidecar `obsolescence.status ≠ active`	Artefakt ist obsolete/superseded	Prüfer prüft Nachfolger-Artefakt (`superseded_by`)

Zusammenfassung

Die Verifikationsroutine ist historie-unabhängig (sha256sum + jq genügen) und zeitbeständig (JSON, SHA-256, V7GUID — keine Werkzeug-Abhängigkeit).
Jede Kettenglied-Abweichung hat eine definierte Bedeutung und Konsequenz.
Der SHA-256 ist der Beweis für Originalität und Identifizierung — immer und überall, auch wenn Quell-Dokuments/Grafiken wandern (pfad-/namensunabhängig); der guid-Stempel ist nur ein dokumentiertes, deterministisch reproduzierbares Verweis-Merkmal.
Nächster Artikel (DS05): der GCPN-Signatur-Container bündelt alle Artefakte.

Erstellt: 260913 | Teil I, Artikel DS04 | Serie: digital-signage