DS04 — Sidecar Cataloging and Verification Chain

Trigger S2, Continuation

The auditor sits at the screen — no Git client, no repo access rights to the history, only the working directory of the tenant repo (or an export thereof). They want to verify: Is the document authentic, who signed it, is the chain intact?

The Verification Set

The case directory contains:

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)

The Verification Routine

Step 1: Source Document Integrity

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

Deviation = source document modified after sidecar creation → chain breaks.

Step 2: Signature Doc Reference

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

The signature doc is tied to one specific version — not to "the document somehow".

Step 3: Event Chain

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)?

Step 4: Facsimile Graphic

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

The SHA-256 hash IS the proof of originality — not the GUID stamp. The SHA-256 identifies the graphic always and everywhere: source documents (and graphics) can migrate (file moved, copied, stored under a different name) — identification persists via the SHA-256 code, because it is computed from the content and is path-/name-independent. The GUID stamp (01a09b48-4580-76f9-b789-024691b989c5), by contrast, is only an attached attribute: deterministically reproducible from ts+sha (gc-v7guid gen-doc) and useful as a documented reference — but originality and identification are carried solely by the SHA-256 (and the SHA-256 chain of the artifacts), not by the GUID stamp.

Step 5: Sidecar Cataloging

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

The Verification Chain as a Diagram

%%{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

Why Without Git History?

Three reasons for the history-independent verification:

Export scenarios — the auditor receives a directory copy (ZIP, container package, DS10), not the repo. The history would not be included.
GoBD traceability — the chain of evidence must hold even if the tool should no longer be in common use in 10 years. SHA-256, JSON and Markdown are durable over time.
Independence of the levels of evidence — Git history is an additional proof, not the only one. The chain (sidecars + events + graphic) stands on its own.

Error Patterns and Their Meaning

Finding	Meaning	Consequence
SHA-256 of the source document ≠ sidecar	Source document subsequently modified	Chain breaks; source document invalid for this signature
Signature doc references wrong source document SHA	Signature on the wrong version	Signature doc invalid (new version → new signature doc)
Event chain has gaps (prev missing/inconsistent)	Case incomplete	Evidential value reduced; proof of the intermediate state is missing
Graphic SHA ≠ table in SIGNATURE_BLOCK.md	Wrong/manipulated graphic	Facsimile invalid — signature level affected
Sidecar `obsolescence.status ≠ active`	Artifact is obsolete/superseded	Auditor checks the successor artifact (`superseded_by`)

Summary

The verification routine is history-independent (sha256sum + jq suffice) and durable over time (JSON, SHA-256, V7GUID — no tool dependency).
Every chain-link deviation has a defined meaning and consequence.
The SHA-256 is the proof of originality and identification — always and everywhere, even when source documents/graphics migrate (path-/name-independent); the guid stamp is only a documented, deterministically reproducible reference attribute.
Next article (DS05): the GCPN signature container bundles all artifacts.

Created: 260913 | Part I, Article DS04 | Series: digital-signage