Truke KF es una plataforma de gestión del conocimiento — una wiki con un sistema integrado para aprender de los errores. Cualquier equipo que documente su trabajo, registre problemas y quiera que las lecciones de cada proyecto lleguen automáticamente al siguiente puede beneficiarse de ella. Los equipos de ingeniería la utilizan para el análisis formal de fallos, la evaluación de riesgos y el cumplimiento de estándares industriales; el mecanismo subyacente de herencia del conocimiento es aplicable a cualquier ámbito donde la experiencia se acumula con el tiempo.
El elemento fundamental de KF es el ítem. Un ítem puede representar cualquier cosa relevante: un componente, un documento, un proceso, un evento de fallo o una acción. Los ítems no están aislados — pueden vincularse entre sí formando jerarquías como listas de materiales, árboles de fallo y estructuras documentales.
Los ítems pertenecen a tipos — pero a diferencia de un sistema de clasificación, un tipo en KF es una fuente de conocimiento abierta. Cualquier ítem puede tomar como tipo a otro ítem, y un ítem puede tener varios tipos simultáneamente. La relación se lee como aprender de, no como es un tipo de: un componente puede tomar como referencia un tipo de producto automotriz, una norma de materiales y una base de lecciones aprendidas a nivel de circuito al mismo tiempo. Los modos de fallo, las acciones correctivas y los resultados esperados definidos en un tipo se propagan automáticamente a todas sus instancias. Define un tipo bien estructurado una sola vez; cada ítem futuro construido sobre él hereda la experiencia acumulada.
KF integra el análisis de fallos directamente en el modelo de ítems. Los eventos — modos de fallo, incidencias o problemas — se anotan en los ítems a los que afectan. Una vez anotados, KF puede mostrar en cualquier momento un informe de fallos y un árbol de fallo, incluyendo automáticamente los eventos de los subcomponentes.
El informe utiliza un formato de 4 columnas: Ítem, Evento (modo de fallo, causa y efecto apilados verticalmente), Acción y Riesgo. Esta estructura preserva la cadena de razonamiento del AMFE tradicional sin necesidad de hojas de cálculo extensas y fragmentadas.
El formato es compatible con las metodologías estándar: AMFE tradicional, IEC 60812 y el Manual FMEA de VDA/AIAG (2019). También permite aplicar DRBFM (revisión de diseño orientada al cambio: las nuevas preocupaciones de un diseño modificado aparecen como eventos propios de la instancia frente al tipo de diseño de referencia) y DRBTR (revisión orientada a ensayos: las preocupaciones surgidas de los resultados de ensayo se convierten en eventos vinculados a dichos resultados).
El sistema de riesgos de KF se basa en tres campos de cada evento: Severidad (S), Probabilidad (O) y Detección (D). A partir de ellos, KF calcula un valor numérico de riesgo y una clase discreta (bajo / medio / alto). Ambos se actualizan en tiempo real a medida que se añaden eventos y acciones.
Para contextos de seguridad crítica, KF es compatible con la metodología ISO 26262. Los ítems pueden etiquetarse con clasificaciones ASIL y las matrices de riesgo correspondientes se aplican automáticamente. Para usos no automotrices, están disponibles el sistema de Prioridad de Acción de VDA/AIAG y matrices configurables personalizadas. El modelo de riesgos sigue la ISO 31000: tanto amenazas como oportunidades pueden asociarse a un evento, utilizando valores de severidad negativos para representar resultados positivos.
KF también admite evaluaciones antes/después — mostrando cómo se espera que las acciones planificadas o implementadas reduzcan el riesgo asociado.
Una pregunta recurrente en las auditorías ASPICE e ISO 9001 es: ¿cómo se garantiza que las lecciones aprendidas en proyectos anteriores se aplican realmente en los nuevos? KF responde a esto de forma estructural, no procedimental.
El checklist directo responde a la pregunta de conformidad: ¿ha aplicado esta instancia todo lo que sus tipos requieren? Cada acción o resultado esperado está presente (realizado, pendiente o no aplicable) o marcado como faltante — un aviso para añadirlo. No hay ningún registro separado que mantener; el requisito vive en el tipo.
El checklist invertido responde a la pregunta de propagación: para cada acción de esta instancia, ¿ha sido generalizada de vuelta al tipo para que las instancias futuras la hereden? Las acciones que existen solo en una instancia — lecciones aprendidas que nunca fueron promovidas — afloran como brechas. Juntas, las dos direcciones cierran el ciclo del conocimiento: las lecciones fluyen hacia abajo desde los tipos a las instancias, y hacia arriba desde las instancias a los tipos.
Las acciones en KF pueden ordenarse por dependencias y visualizarse como un diagrama de Gantt. El Gantt trabaja en tiempo relativo — semanas de esfuerzo, no fechas de calendario — de modo que captura la forma de un plan: qué se ejecuta en secuencia, qué en paralelo y cuánto tiempo lleva aproximadamente cada fase. Al no tener anclaje en el calendario, un Gantt definido en un tipo es reutilizable: codifica la experiencia acumulada sobre cuánto tarda realmente un trabajo similar, y se convierte en una base inmediata y fundamentada en la experiencia para cualquier nuevo proyecto del mismo tipo. El anclaje al calendario está disponible cuando un proyecto pasa de la estimación a la planificación, pero es un cambio de etiquetas, no una reconstrucción del plan.