¿Cómo debería cambiar un registro canónico de identidad cuando cambia…

Respuesta directa

Un cambio no debería limitarse a sustituir un valor antiguo por uno nuevo. Registre qué cambió, por qué, cuándo entró en vigor, las pruebas que lo respaldan, quién lo aprobó y las superficies a las que se propagó. Trátelo como un evento de cambio versionado.

En lenguaje claro

Cuando una casa cambia de propietario, no se finge que la escritura anterior nunca existió. Se conservan las fechas del estado anterior y el actual, así como el documento que acredita la transmisión. Un registro de identidad debe mostrar el presente sin borrar el pasado.

Por qué importa

Sin historial, una corrección, un cambio de nombre, una fusión, un cierre o el nacimiento de una nueva entidad pueden confundirse con otro acontecimiento. Los sistemas que utilizan información antigua no pueden entender por qué se produjo el cambio.

No confundir

Una corrección ortográfica y un cambio en el mundo real son distintos.
Un cambio de nombre no siempre crea una entidad nueva.
Una fusión o división puede exigir nuevas relaciones de identidad, no solo la actualización de un campo.

Qué hacer

Clasifique el tipo de cambio.
Registre los valores anterior y nuevo, la fecha de entrada en vigor y las pruebas.
Decida si continúa la identidad estable.
Cree una lista de propagación para HTML, datos estructurados, JSON y registros externos.
Después de actualizar, realice una lectura de comprobación y una prueba de conflictos.

Cómo auditarlo

¿Puede verse todavía el estado anterior en el historial?
¿Existe un registro que apruebe y demuestre el cambio?
¿Se mantuvo indebidamente una identidad antigua cuando era necesaria una entidad nueva?
¿Se actualizaron todas las superficies?
¿Existe una redirección o relación correcta desde la URL y la identidad anteriores?

Límite

Actualizar un registro técnico no crea por sí mismo los efectos jurídicos del cambio. Las consecuencias jurídicas dependen de los documentos autorizados, los registros y los hechos del caso.