Truke KF

Supported norms

Truke KF is, at its core, a simple tool, but thanks to its flexibility and internal data structure it can quickly evolve into a complex network of interconnected items. To maintain clarity and usability, it's recommended to keep things simple, especially for items that will be used as types for other items. Here are a few key points to keep in mind.

Inheritance rules for types

Items inherit from their types two things: events and actions. Object structures are not inherited (you are offered the option to copy them from other objects).

Inheritance means:

• events from types appear in the event (failure) analysis report.
• to-do actions from types appear in the action checklist
• outcomes from types appear in the outcome checklist

This happens recursively, i.e., a type also inherits from its types and so on. Let's image some scenarios:

• An item P1 has a to-do action A1 that is of type A0. A0 has some outcomes.
• P1 has a component P2 of type P0. P0 has an event (failure mode) E1 that needs a mitigation action A3.

To-do actions vs. action components

There are two possible Gantt charts for each item. One is the Gantt chart of to-do (or done) actions that are below the Action tab, and another is available to show the actions that are components of a particular action (which appear below the Components tab). An action may have a structure, that is, it may be composed of other actions, and those actions are in Components.

KF is not an ERP

While KF supports object trees (components), Truke KF is not intended to maintain precise BOM (bill of materials) as it lacks attributes like quantity or units, and all the associated logic. KF should always be considered as a knowledge management tool, not more. Expect some inevitable information duplication from other systems.