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. Hay dos excepciones, que se heredan literalmente: una tarea que T marca como not applicable (nadie la debe) o como resolved (T la ha cumplido en nombre de sus instancias) llega a A con ese estado, y no como missing.
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 tarea 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 tareas y las acciones asociadas a eventos de toda la jerarquía de tipos, y comprueba si la instancia tiene cada una. 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 dos columnas:
| Columna | Contenido |
|---|---|
| Ítem | El componente o ítem raíz al que se aplica la tarea, con una cadena de origen (flechas ←) que muestra qué tipo — y qué evento, si lo hay — ha originado la tarea. |
| Check | El título de la tarea con un icono de estado. |
El evento no es una columna propia. Una tarea es una tarea medie o no un evento entre ella y su ítem; el evento indica por qué se debe ese trabajo, así que se muestra como procedencia dentro de la celda del ítem, junto al tipo. Véase Listas de verificación para el modelo completo.
Cada tarea tiene uno de cinco estados:
| Estado | Significado |
|---|---|
| Done | La tarea ha sido completada — solo para este ítem. El done de un tipo no dice nada sobre sus instancias, así que no se hereda. |
| Resolved | Completada, y completada en nombre de las instancias: trabajo hecho una sola vez en el tipo para todas ellas, como una homologación obtenida para toda una línea de producto. Una instancia que no tiene la tarea hereda resolved en lugar de missing. En todo lo demás cuenta como completada. |
| Not applicable | La tarea existe en la instancia pero se ha marcado como no relevante para este caso. |
| Pending | La tarea existe en la instancia y está en curso. Es el estado por defecto. |
| Missing | Definida por la jerarquía de tipos pero aún no presente en esta instancia. |
Las tareas en estado Missing incluyen un botón Add que crea la tarea en la instancia con un solo clic, con el nombre tomado del tipo.
El checklist es accesible desde la pestaña Tasks (todas las tareas 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 tarea de esta instancia, ¿está generalizada en un tipo?
| 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:
Los dos niveles juzgan las mismas tareas, pero no hacen la misma pregunta — la diferencia está en qué tipos pueden responder.
Nivel de instancia — para una instancia concreta, lista todas sus tareas con su estado de generalización. Puede responder cualquier tipo de la instancia: la pregunta es ¿está recogido en algún sitio lo que este proyecto ha aprendido? Útil durante el trabajo en un proyecto, para asegurarse de que sus lecciones están llegando al sistema de tipos.
Nivel de tipo — cuando se ejecuta desde un tipo, lista las tareas de todas las instancias de ese tipo, y solo puede responder la jerarquía de ese tipo: lo que él declara, lo que hereda de sus propios tipos y lo que declaran sus componentes. La pregunta es la de los hermanos: ¿ha llegado una lección aprendida en el proyecto A al proyecto B del mismo tipo? Solo si la lección llegó al tipo compartido, porque es todo lo que ambos proyectos tienen en común. Una lección generalizada a algún otro tipo que A tenga es real, y la vista de instancia se lo reconoce, pero no llega a B — así que el mapa del tipo la señala como la carencia que es. Es la vista más útil para auditorías, y es el reflejo de la lista de conformidad: ambas se restringen al único tipo por el que se pregunta.
La restricción no es un juicio sobre cuál de los tipos de una instancia es mejor hogar para una lección — nada en KF los ordena. El tipo se singulariza porque es aquel por el que se pregunta.
Las tareas que aparecen como Missing en el checklist invertido no tienen equivalente en los tipos que podían responder. Cada una es un punto abierto: revisarla y promoverla al tipo correspondiente, para que las instancias futuras la hereden. Si no debe generalizarse — un proveedor puntual, una situación que no volverá a darse — promoverla igualmente y luego marcarla como not applicable en el tipo: la carencia queda cerrada para todas las instancias a la vez, porque el not applicable de un tipo se hereda literalmente, y la decisión queda registrada en la estructura. Marcarla como resolved cuando la lección sí se aplica a todas las instancias pero el trabajo que la resuelve se hace una sola vez en el tipo, en lugar de repetirlo en cada una: las instancias heredan esa respuesta en lugar de una carencia. Los dos estados no son intercambiables: not applicable dice que nadie la debe, resolved dice que se debe y ya está cumplida, y una auditoría puede así distinguir un requisito exceptuado de uno satisfecho de forma centralizada.