Idea principal

El gesto natural, cuando una regla cambia, es actualizar el documento que la contenía. Dos años después de haber escrito "francés e inglés por defecto, otros idiomas bajo condición de facturación firmada", el equipo que decide traducir automáticamente los idiomas secundarios con revisión humana en los recorridos críticos abre el archivo y corrige la frase.

Ese gesto destruye exactamente lo que el documento servía para conservar. Una decisión no es un estado, es un par: una elección y el contexto que la hacía razonable. Reescribir no sustituye solo la elección antigua: elimina el contexto antiguo, es decir, el coste de traducción de entonces, la calidad alcanzable entonces, las herramientas del soporte de entonces. Lo que queda es una regla actual sin pasado, indistinguible de una regla que siempre hubiera sido esa.

La forma correcta es, por tanto, la acumulación: la decisión antigua se queda donde está, marcada como sustituida, y apunta a la que toma el relevo. La antigua explica por qué la empresa se había negado; la nueva explica por qué esa negativa ya no encaja. Ninguna de las dos dice que la otra estuviera equivocada.

La misma forma vale para la descripción de un objeto, y por una razón añadida. Cuando un objeto de un producto se repiensa de arriba abajo, no se modifica su ficha: se crea una nueva, y la antigua se queda. No sirve solo para explicar lo que se pensaba en su momento: sigue siendo necesaria para interpretar los datos y los intercambios anteriores al cambio, que siguen existiendo y se leen según el modelo antiguo.

Capa aportada por "Escribí la ontología de un producto. Tres veces creí haber terminado." (2026-08-11).

Capa aportada por "Ontology-Driven Design: ¿y si la ontología se convirtiera en la red de seguridad del código generado por IA?" (2026-10-29). La regla se extiende a las evoluciones de una ontología de negocio mantenida frente al código. Un concepto renombrado no debe convertirse en dos conceptos independientes, y una regla de negocio eliminada —"todo pedido procede de un presupuesto", en un ERP— debe seguir vinculada a la decisión que justificó su desaparición, por ejemplo en un pequeño registro inspirado en los ADR. La evolución del modelo debe ser tan trazable como la del código.

Por qué es importante

Impide un uso corriente y poco confesable de los documentos de decisión: reescribirlos para tapar un cambio de posición, lo que da a la organización la apariencia retrospectiva de haber tenido siempre razón.

También aporta el material que nadie piensa en conservar —la serie de contextos sucesivos— y que es la única forma de saber a qué velocidad caducan los supuestos de una empresa.

Matices y límites

La acumulación tiene un coste de lectura: varias decisiones superpuestas sobre el mismo tema obligan a saber cuál está en vigor, lo que supone un marcado disciplinado que nada garantiza.

Y no todas las correcciones son sustituciones: arreglar una errata o precisar una formulación ambigua no cambia la decisión y no exige un documento nuevo.

Preguntas abiertas

• ¿Al cabo de cuántas sustituciones sucesivas deja de ser legible una serie de decisiones sobre el mismo tema, y qué hay que hacer entonces con ella?