¿Cómo sabe un sistema que el conocimiento ha cambiado?

Conocimiento y sistemas — 02

Se actualiza un documento. La nueva versión se carga en el sistema. La siguiente respuesta ya utiliza esa versión.

A primera vista, parece que el conocimiento se ha actualizado. Sin embargo, la versión anterior puede seguir viviendo en otros lugares: en una caché, en un resumen generado antes, dentro de otro registro o como fundamento de una decisión pasada.

Por eso, un cambio en el conocimiento es una cuestión más amplia que detectar que un archivo ha cambiado.

¿Cómo sigue el sistema lo que cambió y los usos afectados por ese cambio?

Al trabajar en KLM y nage, encuentro esta pregunta en dos niveles: cómo registrar el rastro del conocimiento y cómo debe comportarse el sistema que lo utiliza.

¿Qué ha cambiado exactamente?

Pensemos en un ejemplo sencillo e hipotético.

Supongamos que las directrices de una institución establecen un plazo de diez días para las solicitudes. Las nuevas directrices reducen ese plazo a siete días y lo hacen efectivo a partir de una fecha determinada.

No solo cambió el texto. También cambiaron las condiciones de validez de una regla.

Las directrices anteriores pueden seguir siendo necesarias para explicar una actuación realizada mientras estaban vigentes. Una nueva solicitud, en cambio, debe responderse utilizando las nuevas directrices.

Por tanto, el sistema necesita más que un único campo de «documento actual». Debe distinguir qué versión de qué fuente conserva, cuándo es válida y en qué operaciones se utilizó.

Además, no todos los cambios tienen el mismo peso. Una corrección ortográfica, un cambio de fecha y una modificación de una condición de decisión pueden tener consecuencias diferentes.

Cuando cambia el resumen criptográfico de un archivo —su hash— podemos detectar que el contenido es distinto. Determinar el significado y el impacto de esa diferencia requiere otra evaluación.

KLM: hacer legible el rastro del cambio

KLM es un trabajo de desarrollo de un contrato para registrar explícitamente las relaciones entre conocimiento, afirmaciones y evidencias que sustentan una respuesta.

Aquí importa poder distinguir la versión concreta de la fuente utilizada, además de conservar su dirección.

Si un enlace apunta hoy a otro documento, quizá ya no permita saber en qué se apoyó una respuesta anterior. Registrar la identidad de la fuente, su versión o su hash permite hacer esa distinción.

La especificación de KLM define el inicio y el fin de validez, la versión y una relación de sustitución de una unidad de conocimiento anterior. Así, un nuevo registro puede expresar qué registro antiguo reemplaza.

Estos campos no forman por sí solos un mecanismo que detecte cambios de significado. La aplicación debe establecer por separado cómo detecta el cambio y con qué fundamento rellena esos campos.

Lo que aporta KLM aquí es un marco donde conservar el rastro de una decisión sobre un cambio.

¿Una nueva versión exige borrar la anterior?

Si eliminamos por completo las directrices antiguas del ejemplo, puede resultar difícil explicar una respuesta pasada. Si utilizamos las antiguas y las nuevas juntas sin distinguirlas, queda poco claro qué regla debe regir una nueva respuesta.

Conservar la historia y establecer las condiciones del uso actual deben abordarse conjuntamente.

Una unidad de conocimiento puede estar activa, haber sido sustituida, haber caducado o haber sido revocada. Son estados diferentes.

KLM contempla estas distinciones del ciclo de vida. Cuando se afirma que una fuente se ha eliminado, también exige indicar el alcance de esa eliminación. Un registro retirado del almacén de conocimiento puede seguir presente en cachés, registros de inferencia o resultados derivados.

La palabra «eliminado» no debería implicar que la misma operación se ha completado en todo el sistema.

nage: llevar una decisión registrada al sistema en funcionamiento

En nage, la pregunta se extiende a cómo mantener esas distinciones durante la operación.

La incorporación de nuevo conocimiento puede implicar varias operaciones: crear el registro de la fuente, procesarlo, hacerlo consultable y habilitar su uso. Cada una puede fallar en un punto distinto.

¿Qué versión usará el sistema si la nueva ya está escrita en el almacén, pero el índice de búsqueda no se ha actualizado? ¿Qué ocurre si la antigua está archivada, pero permanece en la caché? Si llegan dos actualizaciones simultáneas, ¿cuál se considera la versión activa?

En el diseño de nage, las unidades de conocimiento gestionadas se tratan junto con sus fuentes, versiones, ciclos de vida y capacidades disponibles. Que un documento exista, pueda buscarse y haya sido aceptado para su uso son estados separados.

Reducir esta distinción a una única marca de «listo» puede hacer que una operación incompleta parezca utilizable.

La pregunta operativa es:

¿Cómo verificamos las condiciones en las que puede utilizarse la nueva versión?

La aceptación del ciclo de vida a escala de todo el producto sigue siendo un área de trabajo abierta en nage. Por eso, este texto describe el comportamiento que debe probarse; no afirma que se hayan completado todos los escenarios de actualización y eliminación.

¿Hasta dónde llega el cambio de una fuente?

Supongamos que una afirmación concreta de una respuesta se apoyaba en las directrices antiguas. Esa respuesta pudo resumirse después y el resumen utilizarse en otro trabajo.

Cuando cambia la fuente, el impacto no termina en la primera respuesta.

Por eso importa poder seguir el rastro desde las fuentes hasta los resultados: ¿qué afirmaciones utilizaron esta versión? ¿Qué resultados se derivaron de ellas?

Las relaciones de evidencia y derivación de KLM ofrecen una base para registrar ese rastro de impacto. Sin embargo, encontrar un registro afectado no equivale a declararlo automáticamente incorrecto.

Una respuesta producida conforme a una regla válida en el pasado puede seguir siendo correcta en su contexto histórico. La misma respuesta puede no ser adecuada para una nueva actuación hoy.

El sistema necesita una política que distinga esos usos. Algunos registros pueden reevaluarse, otros conservarse como históricos y otros cerrarse a nuevos usos.

El registro de relaciones hace visible qué registros debe abarcar esa decisión.

¿Qué desconocemos sobre la vigencia?

Que una fuente entre hoy en el sistema no demuestra necesariamente que su contenido sea válido hoy. Un archivo de fecha reciente también puede transmitir una regla más antigua.

El momento de incorporación, el de modificación y el de entrada en vigor de una fuente aportan información diferente.

Si alguno se desconoce, esa ausencia debe permanecer explícita. El enfoque de KLM de conservar las señales desconocidas junto con sus motivos también importa aquí. Asignar un número a una vigencia no medida no elimina la falta de información.

Al volver a la pregunta inicial, «el sistema entiende» se divide en varias tareas concretas: detectar el cambio, vincular el registro nuevo con el anterior, establecer las condiciones de uso y encontrar los resultados afectados.

Cada tarea debe tener su propio fundamento y sus límites.

Al evaluar una actualización del conocimiento, también debemos preguntar:

Añadimos el conocimiento nuevo; ¿podemos ver dónde sigue utilizándose el antiguo?

---

Nota sobre las fuentes — 15 de octubre de 2026: El artículo se basa en las secciones sobre el ciclo de vida del conocimiento y el linaje de impacto de la especificación de KLM, y en los documentos de diseño e implementación actual de nage. El ejemplo de las directrices es hipotético. No se presenta ningún nuevo resultado de implementación ni de pruebas de aceptación.

Página del proyecto KLM · Página del proyecto nage · ¿Por qué lo desconocido no es cero?