Respuesta directa
Cada decisión tiene un identificador persistente y una versión inmutable. La creación, entrada en vigor, suspensión, retirada, corrección, caducidad y sustitución se guardan como eventos añadidos sin borrar el registro anterior. Cada evento contiene identificador, momento, actor, autoridad, motivo, estado previo, estado nuevo, pruebas y versión de destino. El estado actual se deriva de estos eventos autorizados; no sustituye al historial de eventos.
En lenguaje claro
Piense en un extracto bancario. El saldo de hoy aparece como un número, pero se conservan los abonos y cargos para ver cómo se obtuvo. El estado actual de una decisión se calcula del mismo modo a partir de su historial de eventos.
Por qué importa
Sobrescribir un único campo de estado destruye las pruebas de quién cambió la decisión y por qué. El sistema puede entonces tratar como vigente una decisión antigua, suspendida o retirada.
No confundir
- El identificador de decisión designa la misma familia de decisiones; el identificador de versión designa un contenido concreto.
- Un evento registra un cambio autorizado en el estado de la decisión.
- El estado actual es una vista derivada de eventos; el historial de eventos es la cadena de pruebas.
- La corrección repara contenido inexacto; la sustitución muestra que una decisión nueva reemplaza a otra anterior.
- La suspensión es un estado operativo temporal; la retirada es el final autorizado de la decisión.
Qué hacer
- Defina un identificador persistente de decisión, un identificador inmutable de versión y un esquema explícito.
- Registre cada cambio de ciclo de vida con un identificador de evento separado y una marca temporal fiable.
- Haga obligatorios los campos de identidad del actor, función, autoridad, motivo, pruebas, estado anterior y estado nuevo.
- Restrinja las transiciones de estado válidas y prohíba las inválidas mediante reglas verificables por máquinas.
- Vincule en ambas direcciones las relaciones de corrección, retirada y sustitución sin borrar la versión anterior.
- Genere y recalcule la vista de estado actual a partir del flujo de eventos mediante reglas deterministas.
- Publique el evento a los sistemas posteriores y añada a la decisión pruebas de entrega, aplicación y lectura.
Cómo auditarlo
- ¿Son únicos, persistentes y versionados los identificadores de decisión y evento?
- ¿Se sobrescribió contenido de una decisión anterior o un evento?
- ¿Contiene cada evento momento, actor, autoridad, motivo y pruebas?
- ¿Se bloquean las transiciones de estado inválidas o no autorizadas?
- ¿Pueden seguirse en ambas direcciones los vínculos de corrección, retirada y sustitución?
- ¿Puede regenerarse la vista de estado actual a partir de los eventos conservados?
- ¿Alcanzaron realmente los destinos posteriores el mismo estado actual?
Límite
Un registro de solo anexión refuerza la inmutabilidad y la trazabilidad; no demuestra por sí solo que un evento fuera correcto o autorizado. También se necesitan controles fiables de tiempo, identidad, autoridad e integridad.
Recuérdalo en una frase
El estado actual no borra el pasado; surge de eventos autorizados ocurridos en ese pasado.
Fuentes de este registro
- S14DataCite, *Versioning*Infraestructura de identidad
- S15DataCite, *Connecting Versions with Related Identifiers*Infraestructura de identidad
- S26NIST SP 800-53 Rev. 5, *Security and Privacy Controls*Estándar
- S35W3C, *PROV-O: The PROV Ontology*Estándar
- S36W3C, *Trace Context*Estándar
- S37OpenTelemetry, *General Trace Semantic Conventions*Documentación de estándar y proyecto

