Truke KF is a knowledge management platform — a wiki with a built-in system for learning from mistakes. Any team that documents work, tracks problems, and wants the lessons from each project to automatically inform the next can benefit from it. Engineering teams use it for formal failure analysis, risk assessment, and compliance with industry standards; the underlying mechanism of knowledge inheritance applies to any domain where experience accumulates over time.
The fundamental building block in KF is the item. An item can represent anything that matters: a component, a document, a process, a failure event, or an action. Items are not isolated — they can link to each other, forming hierarchies like bills of materials, fault trees, and document structures.
Items belong to types — but unlike a classification system, a KF type is an open knowledge source. Any item can draw from any other item as its type, and an item can have multiple types simultaneously. The relationship reads as learn from, not is a kind of: a component can draw from an automotive product type, a material standard, and a circuit-level lessons-learned base at the same time. Failure modes, corrective actions, and expected outcomes defined on a type propagate automatically to all its instances. Define a well-structured type once; every future item built on it inherits the accumulated experience.
KF integrates failure analysis directly into the item model. Events — failure modes, issues, or problems — are annotated on the items they affect. Once annotated, KF can display a failure report and a fault tree at any time, automatically including events from sub-components.
The report uses a 4-column format: Item, Event (failure mode, cause, and effect stacked vertically), Action, and Risk. This structure preserves the reasoning chain of a traditional FMEA without requiring wide, fragmented spreadsheets.
The format is compatible with standard methodologies: traditional FMEA, IEC 60812, and the VDA/AIAG FMEA Handbook (2019). It also accommodates DRBFM (change-driven design review: new concerns from a changed design appear as instance-specific events against the reference-design type) and DRBTR (test-driven review: concerns surfaced by test results become events linked to their test outcomes).
KF's risk system is built around three fields on each event: Severity (S), Occurrence (O), and Detection (D). From these, KF calculates a numerical risk value and a discrete risk class (low / medium / high). Both are updated in real time as events and actions are added.
For safety-critical contexts, KF supports the ISO 26262 methodology. Items can be tagged with ASIL classifications, and the corresponding risk matrices are applied automatically. For non-automotive use, the VDA/AIAG Action Priority system and custom configurable matrices are available. The risk model follows ISO 31000: both threats and opportunities can be associated with an event, using negative severity values to represent positive outcomes.
KF also supports before/after evaluations — displaying how planned or implemented actions are expected to reduce the associated risk.
A recurring question in ASPICE and ISO 9001 audits is: how do you assure that lessons learned from past projects are actually applied to new ones? KF answers this structurally rather than procedurally.
The direct checklist answers the conformance question: has this instance applied everything its types require? Each expected action or outcome is either present (done, pending, or not applicable) or flagged as missing — a prompt to add it. No separate register to maintain; the requirement lives in the type.
The inverted checklist answers the propagation question: for each action on this instance, has it been generalised back to the type so future instances inherit it? Actions that exist only on a single instance — lessons learned that were never promoted — are surfaced as gaps. Together the two directions close the knowledge cycle: lessons flow down from types to instances, and back up from instances to types.
Actions in KF can be ordered by dependency and displayed as a Gantt chart. The Gantt works in relative time — weeks of effort, not calendar dates — so it captures the shape of a plan: what runs in sequence, what runs in parallel, and roughly how long each phase takes. Because it carries no calendar anchors, a Gantt defined on a type is reusable: it encodes the accumulated experience of how long similar work actually takes, and becomes an immediate, experience-grounded baseline for any new project of the same kind. Calendar anchoring is available when a project moves from estimation into planning, but it is a label change, not a rebuild of the schedule.