Una pregunta recurrente en las auditorías ISO 9001 y similares es: ¿cómo se garantiza que las lecciones aprendidas en proyectos anteriores se aplican realmente en los nuevos? La respuesta habitual —un registro de lecciones aprendidas, una revisión formal, un procedimiento que obliga a los ingenieros a consultar el trabajo anterior antes de comenzar— es frágil. Depende de que las personas recuerden consultar, de que el registro esté actualizado y de que el conocimiento sea localizable en el momento en que se necesita.
KF adopta un enfoque diferente: las lecciones aprendidas están integradas en la propia estructura de datos y se propagan automáticamente a través del sistema de tipos. No hay ningún proceso adicional que recordar. Las dos vistas de checklist —directa e invertida— hacen visible y auditable esta propagación.
KF implementa esto con una sola funcionalidad: cualquier ítem puede declarar otro ítem como su tipo. Ese es todo el mecanismo — todo lo demás se deriva de ahí.
Cualquier ítem puede declarar uno o más ítems como sus tipos, en la pestaña Types. El tipo actúa como un contenedor reutilizable de conocimiento. El ítem que se vincula a un tipo es una instancia.
Un ítem puede tener varios tipos, y los tipos pueden tener a su vez sus propios tipos. A diferencia de la noción cerrada de tipo en los lenguajes de programación —donde un tipo es una clasificación y un objeto pertenece exactamente a una clase— los tipos en KF son fuentes de conocimiento abiertas. La relación se lee como aprender de, no como es un tipo de. Un componente electrónico, por ejemplo, puede tomar conocimiento de un tipo de producto automotriz (para prácticas de ingeniería), de un tipo de electrónica de potencia (para lecciones a nivel de circuito) y de una norma de materiales — acumulando conocimiento de todos ellos de forma independiente.
La pestaña Types de cualquier ítem muestra tanto sus tipos (hacia arriba) como sus instancias (hacia abajo), cada uno con un enlace al checklist correspondiente.
Cuando KF construye el checklist para la instancia A del tipo T, recoge de T y de todos sus tipos ancestros:
Todo lo que ya existe en A (identificado por su vínculo de tipo) se muestra con su estado actual. Lo que no existe en A se muestra como Missing (faltante) — un aviso para añadirlo.
El origen de cada elemento heredado se rastrea y se muestra como una cadena de flechas (por ejemplo, OBC Platform ← Automotive product ← Missing 3D clearance and creepage analysis), de modo que siempre queda claro de dónde viene una acción y por qué es necesaria.
Por defecto, la herencia recorre toda la cadena de tipos. Esto funciona bien en jerarquías poco profundas, pero se convierte en un problema en jerarquías profundas: un cambio en un tipo genérico de alto nivel se propaga a todas las instancias del sistema, incluidas las que no deberían verse afectadas.
Un tipo de referencia es un tipo etiquetado con reference. Actúa como límite en el recorrido: KF recoge todo lo que hay en el tipo de referencia y por debajo (hacia la instancia), pero se detiene ahí — no continúa hacia los tipos padre del tipo de referencia.
Esto crea un corte estable y deliberado. Los equipos pueden enriquecer y refinar el conocimiento en el nivel genérico (por encima del tipo de referencia) sin que esos cambios fluyan automáticamente hacia las instancias de producción. El tipo de referencia representa un límite intencionado: heredar hasta aquí, no más allá.
En la práctica, dada la cadena instancia A → tipo T1 → tipo T2 (referencia) → tipo T3:
Para marcar un ítem como tipo de referencia, añadir la etiqueta reference en el campo de etiquetas del ítem. Aparecerá un distintivo Reference junto al título, y el ítem se mostrará en negrita en el árbol de tipos.
La vista Type tree (`/item/{id}/types-tree`, accesible también mediante el icono de árbol en la pestaña Types) muestra la jerarquía completa de tipos como un grafo dirigido:
Esta vista es útil para comprender de un vistazo la cadena completa de herencia y para detectar conexiones inesperadas o jerarquías demasiado profundas.
El checklist directo responde a la pregunta de conformidad: ¿ha aplicado esta instancia todo lo que sus tipos requieren?
Recorre todas las acciones, resultados y acciones asociadas a eventos de toda la jerarquía de tipos, y comprueba si la instancia tiene cada uno. Es una vista descendente, de tipo a instancia: el sistema de tipos define lo que debe existir; el checklist muestra lo que falta.
La tabla tiene tres columnas:
| Columna | Contenido |
|---|---|
| Ítem | El componente o ítem raíz al que se aplica la acción. Incluye una cadena de origen (flechas ←) que muestra qué tipo y evento la han originado. |
| Evento | El modo de fallo o evento al que está asociada la acción, si lo hay. Vacío para acciones directas. |
| Acción | El título de la acción con un icono de estado. |
Cada acción tiene uno de cinco estados:
| Estado | Significado |
|---|---|
| Done | La acción ha sido completada. |
| Not applicable | La acción existe en la instancia pero se ha marcado como no relevante para este caso. |
| Possibly applicable | Heredada de un tipo pero su aplicabilidad es incierta — requiere revisión. |
| Pending | La acción existe en la instancia y está en curso. |
| Missing | Definida por la jerarquía de tipos pero aún no presente en esta instancia. |
Las acciones en estado Missing incluyen un botón Add que crea la acción en la instancia con un solo clic, con el nombre tomado del tipo.
El checklist es accesible desde la pestaña Actions (todas las acciones heredadas) y desde la pestaña Types (la contribución de un tipo concreto a esta instancia).
El checklist directo solo funciona para lecciones que ya han sido generalizadas — promovidas a un tipo. Una lección que existe en una sola instancia, vinculada a un proyecto específico, es invisible para todas las demás instancias. Nunca aparecerá en ningún checklist. Una lección que permanece en una instancia es una lección perdida.
El checklist invertido responde a la pregunta complementaria: para cada acción de esta instancia, ¿está generalizada en alguno de sus tipos?
| Dirección | Pregunta | |
|---|---|---|
| Checklist directo | Tipo → instancia | ¿Tiene esta instancia lo que sus tipos requieren? |
| Checklist invertido | Instancia → tipo | ¿Está reflejado en los tipos lo que esta instancia ha aprendido? |
Juntos cierran el ciclo del conocimiento: las lecciones fluyen hacia abajo desde los tipos a las instancias (el checklist directo garantiza su aplicación) y hacia arriba desde las instancias a los tipos (el checklist invertido pone de manifiesto lo que necesita ser promovido).
El checklist invertido (accesible mediante el icono de portapapeles en la pestaña Types, o en `/item/{id}/icheck`) puede consultarse en dos niveles:
Nivel de instancia — para una instancia concreta, lista todas sus acciones con su estado de generalización. Útil durante el trabajo en un proyecto para asegurarse de que las lecciones aprendidas en ese proyecto se están incorporando al sistema de tipos.
Nivel de tipo — cuando se ejecuta desde un tipo, agrega los datos de todas las instancias de ese tipo. Esto produce un mapa completo de propagación: qué han aprendido colectivamente todas las instancias, qué lecciones ya están en el tipo y cuáles no. Es la vista más útil para auditorías — responde directamente a si una lección aprendida en el proyecto A ha llegado al proyecto B del mismo tipo.
Las acciones que aparecen como Missing en el checklist invertido no tienen equivalente a nivel de tipo. Cada una es un punto abierto: revisarla y bien promoverla al tipo correspondiente (para que las instancias futuras la hereden), bien marcarla como `not applicable` en el tipo (para documentar que deliberadamente no se generaliza). Ambas opciones cierran la brecha. En cualquier caso, la decisión queda registrada en la estructura.