DS04 — Sidecar cataloguing and verification chain

Trigger S2, continued

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 of it). They want to check: Is the document authentic, who signed it, is the chain intact?

The verification set

The following are located in the directory of the case:

260825-shareholder-meeting-resolution.md         (source document)
260825-shareholder-meeting-resolution.md.gc.md  (sidecar source document)
260913_signature-doc.json                                  (signature doc, DS02)
260913_signature-doc.json.gc.md                           (sidecar signature doc)
260913_event-accepted.json                                 (event 1, DS03)
260913_event-signed.json                                   (event 2, DS03)
260913_event-signed.json.gc.md                            (sidecar events)
E1.Signature.transparent.FES.svg                         ([Facsimile](../../glossar.html#facsimile "Facsimile-Unterschrift — Glossar") graphic)
E1.Signature.transparent.FES.svg.gc.md                  (sidecar graphic)

The verification routine

Step 1: Source document integrity

sha256sum 260825_GVB_*.md
# → must match the .sha256 in the sidecar 260825_*.md.gc.md
jq -r '.sha256' 260825_*.md.gc.md

Deviation = source document was changed after sidecar creation → chain breaks.

Step 2: Signature doc reference

jq -r '.target.sha256' 260913_signature-doc.json
# → must match the source document SHA (step 1)

The signature doc is attached 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
# Check chain: prev of ev2 == sha256(ev1)?

Step 4: Facsimile graphic

sha256sum E1.Signature.transparent.FES.svg
# → must match evidence.facsimile_ref.sha256 in the signature doc and in the event
# → must match the table in PARTNER-ORG-repo/top/signature-block.md

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) — the 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 characteristic: deterministically reproducible from ts+sha (gc-v7guid gen-doc) and useful as a documented reference — but originality and identification are borne solely by the SHA-256 (and the SHA-256 chain of the artefacts), not by the GUID stamp.

Step 5: Sidecar cataloguing

jq -r '.v7g_taxonomy[].taxonomy' *.gc.md | sort | uniq
# → classes of the artefacts involved (SIGNATURE_DOC, SIGNATURE_EVENT, SIGNATURE_GRAPHIC)
jq -r '.obsolescence.status' *.gc.md
# → all "active"? Deviation = artefact is obsolete/superseded

The verification chain as a diagram

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#FBFAF7','primaryTextColor':'#0F1B33','primaryBorderColor':'#6B7280','lineColor':'#6B7280'}}}%% flowchart TB A["Source document (MD)
sha256 T"] --> B["Sidecar source document
sha256(T)"] A --> C["Signature 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 graphic
sha256 + guid stamp"] D -.-> I["Auditor: sha256sum + jq
check all references"] B -.-> I H -.-> I style I fill:#e8eef7,stroke:#2c5282

Why without Git history?

Three reasons for 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 up even if the tool is no longer common in 10 years. SHA-256, JSON and Markdown are durable over time.
Independence of the evidence levels — Git history is additional evidence, not the only evidence. The chain (sidecars + events + graphic) is self-supporting.

Error patterns and their meaning

Finding	Meaning	Consequence
SHA-256 of the source document ≠ sidecar	Source document changed after the fact	Chain breaks; source document invalid for this signature
Signature doc references wrong source document SHA	Signature on wrong version	Signature doc invalid (new version → new signature doc)
Event chain incomplete (prev missing/inconsistent)	Process incomplete	Evidentiary value reduced; proof of the intermediate state missing
Graphic SHA ≠ table in SIGNATURE_BLOCK.md	Wrong/manipulated graphic	Facsimile invalid — signature level affected
Sidecar `obsolescence.status ≠ active`	Artefact is obsolete/superseded	Auditor checks the successor artefact (`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 merely a documented, deterministically reproducible reference characteristic.
Next article (DS05): the GCPN signature container bundles all artefacts.

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