Respuesta directa
Inventaríe primero cada destino posterior directo e indirecto que utiliza la decisión. Envíe la corrección como un evento único e idempotente. Cada destino genera pruebas de recepción, aplicación y lectura independiente del estado actual. Para destinos críticos, pruebe el comportamiento real y no solo la igualdad de campos. Un destino inaccesible o externo no está completo; manténgalo abierto con responsable y vía de reintento.
En lenguaje claro
Imagine que corrige su domicilio en un hospital. No basta con que recepción diga «He enviado el cambio». Debe comprobar que el laboratorio, la farmacia y facturación utilizan realmente la nueva dirección.
Por qué importa
Si una decisión antigua sobrevive en una caché, exportación o aplicación conectada, la persona puede seguir encontrándose con el resultado equivocado. Una propagación parcial recrea un error que parecía corregido.
No confundir
- Un acuse de recibo confirma que el evento llegó al destino; un acuse de aplicación confirma que se procesó el cambio.
- Lectura de comprobación significa leer de forma independiente el estado actual del destino.
- La igualdad de campos prueba el mismo valor, la equivalencia semántica el mismo significado y la equivalencia conductual la acción correcta.
- Un destino directo recibe primero la decisión; un destino indirecto queda afectado a través de otro.
- Un destino externo puede quedar fuera del control directo; esa limitación no puede ocultarse marcándolo como completo.
Qué hacer
- Inventaríe todos los destinos directos, indirectos, cachés, exportaciones, informes y terceros que reciben la decisión.
- Asigne a cada destino criticidad, responsable, actualización esperada y método de verificación.
- Publique un evento de corrección o retirada único, versionado, ordenable e idempotente.
- Recopile acuses de recepción y aplicación con el identificador de decisión y la versión de destino.
- Lea de nuevo el estado del destino de forma independiente y pruebe la convergencia en campos, significado y comportamiento crítico.
- Gestione destinos fallidos, retrasados y externos con estado abierto, responsable y fecha de reintento.
- No declare completa la propagación hasta verificar todos los destinos requeridos.
Cómo auditarlo
- ¿Están realmente presentes en el inventario todos los destinos directos e indirectos?
- ¿Es el evento único, versionado, ordenable y seguro para aplicarlo más de una vez?
- ¿Se distinguieron recepción y aplicación?
- ¿Se volvió a leer el estado actual directamente desde el sistema de destino?
- ¿Se comporta correctamente un destino crítico o solo coincide el valor del campo?
- ¿Se cerraron como completos destinos fallidos o externos?
- ¿Puede un sistema posterior recrear después la decisión antigua?
Límite
Una organización no puede garantizar cuándo se actualizará un tercero fuera de su control. Puede notificar, conservar pruebas, reintentar y supervisar; una convergencia no verificada debe permanecer explícitamente UNRESOLVED.
Recuérdalo en una frase
Enviar no es propagar; propagar es verificar el cambio en el destino.
Fuentes de este registro
- 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
- S41NCSC y organismos asociados, *Guidelines for Secure AI System Development*Guía oficial de seguridad multiinstitucional
- S42NIST SP 800-61 Rev. 3, *Incident Response Recommendations and Considerations for Cybersecurity Risk Management*Guía institucional voluntaria orientada a estándares