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

Desencadenante S2, continuación

El auditor está sentado ante la pantalla — sin cliente Git, sin derechos de acceso al repo para el historial, solo el directorio de trabajo del repo del tenant (o una exportación de este). Quiere verificar: ¿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.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)

La rutina de verificación

Paso 1: Integridad del documento fuente

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

Desviación = el documento fuente fue modificado tras la creación del sidecar → la cadena se rompe.

Paso 2: Referencia del 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 alguna 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 Facsimile

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 desplazarse (archivo reubicado, copiado, guardado bajo otro nombre) — la identificación se mantiene gracias al 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 un atributo añadido: 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 recaen únicamente en el SHA-256 (y en la cadena SHA-256 de los artefactos), no en el sello GUID.

Paso 5: Catalogación de sidecars

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

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 repo. El historial no estaría incluido.
Trazabilidad GoBD — la cadena de prueba debe seguir siendo válida incluso si la herramienta dejara de ser habitual dentro de 10 años. SHA-256, JSON y Markdown perduran en el 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 sostiene por sí sola.

Patrones 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 apunta a un SHA del documento fuente incorrecto	Firma sobre una versión errónea	Documento de firma inválido (nueva versión → nuevo documento de firma)
Cadena de eventos con lagunas (falta prev/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	Facsimile inválido — nivel de firma afectado
Sidecar `obsolescence.status ≠ active`	El artefacto está obsolete/superseded	El auditor verifica el artefacto sucesor (`superseded_by`)

Resumen

La rutina de verificación es independiente del historial (bastan sha256sum + jq) y perdurable en el tiempo (JSON, SHA-256, V7GUID — sin dependencia de herramientas).
Cada desviación en 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 se desplazan (independiente de ruta y nombre); el sello guid es solo un atributo de referencia documentado y reproducible de forma determinista.
Siguiente artículo (DS05): el contenedor de firmas GCPN agrupa todos los artefactos.

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