DS04 — Catalogación de sidecar y cadena de verificación

Disparador S2, continuación

El auditor está frente a la pantalla — sin cliente Git, sin permisos de acceso al historial del repositorio, solo el directorio de trabajo del repositorio del tenant (o una exportación de este). Quiere comprobar: ¿Es auténtico el documento, quién lo firmó, está intacta la cadena?

El conjunto de verificación

En el directorio del expediente se encuentran:

260825-shareholder-meeting-resolution.md         (Quell-Dokument)
260825-shareholder-meeting-resolution.md.gc.md  (Sidecar Quell-Dokument)
260913_signature-doc.json                                  (Signatur-Doc, DS02)
260913_signature-doc.json.gc.md                           (Sidecar Signatur-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")-Grafik)
E1.Signature.transparent.FES.svg.gc.md                  (Sidecar Grafik)

La rutina de verificación

Paso 1: Integridad del documento fuente

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

Una discrepancia = el documento fuente se modificó después de crear el sidecar → la cadena se rompe.

Paso 2: Referencia al documento de firma

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

El documento de firma está vinculado a una versión concreta — no a «el documento de cualquier manera».

Paso 3: Cadena de eventos

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

Paso 4: Gráfico de facsímil

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

El hash SHA-256 ES la prueba de originalidad — no el sello GUID. El SHA-256 identifica el gráfico siempre y en todas partes: los documentos fuente (y los gráficos) pueden migrar (archivo movido, copiado, guardado con otro nombre) — la identificación se mantiene mediante el código SHA-256, porque se calcula a partir del contenido y es independiente de la ruta y del nombre. El sello GUID (01a09b48-4580-76f9-b789-024691b989c5), en cambio, es solo una característica adjunta: reproducible de forma determinista a partir de ts+sha (gc-v7guid gen-doc) y útil como referencia documentada — pero la originalidad y la identificación las sustentan únicamente el SHA-256 (y la cadena SHA-256 de los artefactos), no el sello GUID.

Paso 5: Catalogación de sidecar

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

La cadena de verificación como diagrama

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

¿Por qué sin historial de Git?

Tres razones para la verificación independiente del historial:

Escenarios de exportación — el auditor recibe una copia del directorio (ZIP, paquete de contenedor, DS10), no el repositorio. El historial no estaría incluido.
Trazabilidad de GoBD — la cadena probatoria debe mantenerse incluso cuando la herramienta ya no sea habitual dentro de 10 años. SHA-256, JSON y Markdown son resistentes al paso del tiempo.
Independencia de los niveles de prueba — el historial de Git es una prueba adicional, no la única. La cadena (sidecars + eventos + gráfico) se sustenta por sí misma.

Casos de error y su significado

Hallazgo	Significado	Consecuencia
SHA-256 del documento fuente ≠ sidecar	Documento fuente modificado posteriormente	La cadena se rompe; documento fuente inválido para esta firma
El documento de firma remite a una SHA incorrecta del documento fuente	Firma sobre una versión incorrecta	Documento de firma inválido (nueva versión → nuevo documento de firma)
Cadena de eventos incompleta (falta prev o es inconsistente)	Expediente incompleto	Valor probatorio reducido; falta la prueba del estado intermedio
SHA del gráfico ≠ tabla en SIGNATURE_BLOCK.md	Gráfico incorrecto/manipulado	Facsímil inválido — afecta al nivel de firma
Sidecar `obsolescence.status ≠ active`	El artefacto está obsoleto/sustituido	El auditor comprueba el artefacto sucesor (`superseded_by`)

Resumen

La rutina de verificación es independiente del historial (sha256sum + jq son suficientes) y resistente al paso del tiempo (JSON, SHA-256, V7GUID — sin dependencia de herramientas).
Cada desviación de un eslabón de la cadena tiene un significado y una consecuencia definidos.
El SHA-256 es la prueba de originalidad e identificación — siempre y en todas partes, incluso cuando los documentos fuente/gráficos migran (independiente de la ruta y del nombre); el sello guid es solo una característica de referencia documentada y reproducible de forma determinista.
Próximo artículo (DS05): el contenedor de firma GCPN agrupa todos los artefactos.

Creado: 260913 | Parte I, artículo DS04 | Serie: digital-signage