A recurring question in ISO 9001 and similar audits is: how do you assure that lessons learned from past projects are actually applied to new ones? The usual answer — a lessons learned register, a review gate, a procedure requiring engineers to consult past work before starting — is fragile. It depends on people remembering to look, on the register being maintained, and on knowledge being findable at the moment it is needed.
KF takes a different approach: lessons learned are embedded in the data structure itself and propagate automatically through the type system. There is no separate process to remember. The two checklist views — direct and inverted — make this propagation visible and auditable.
KF implements this with a single feature: any item can declare another item as its type. That is the entire mechanism — everything else follows from it.
Any item can declare one or more other items as its types, on the Types tab. The type acts as a reusable knowledge container. The item that links to a type is an instance.
An item can have multiple types, and types can themselves have types. Unlike the closed notion of type in programming languages — where a type is a classification and an object belongs to exactly one class — KF types are open knowledge sources. The relationship reads as learn from, not is a kind of. An electronic component, for example, might draw from an automotive product type (for engineering practices), a power electronics type (for circuit-level lessons), and a material standard — accumulating knowledge from all of them independently.
The Types tab of any item lists both its types (upward) and its instances (downward), each with a link to the corresponding checklist.
When KF builds the checklist for instance A of type T, it collects from T and all its ancestor types:
Anything already present in A (matched by its type link) is shown at its actual status. Anything absent from A is shown as Missing — a prompt to add it.
The origin of each inherited item is tracked and displayed as an arrow chain (for example, OBC Platform ← Automotive product ← Missing 3D clearance and creepage analysis), so it is always clear where an action came from and why it is required.
By default, inheritance walks the full type chain. This works well in shallow hierarchies, but becomes a problem in deep ones: a change to a generic top-level type propagates to every instance in the system, including ones that should not be affected.
A reference type is a type tagged reference. It acts as a boundary in the walk: KF collects everything from the reference type and below (toward the instance) but stops there — it does not continue to the reference type's own parent types.
This creates a stable, curated cut-off. Teams can enrich and refine knowledge at the generic level (above the reference type) without those changes flowing automatically into production instances. The reference type represents a deliberate boundary: inherit up to here, no further.
In practice, given instance A → type T1 → type T2 (reference) → type T3:
To mark an item as a reference type, add the tag reference in the item's tag field. A Reference badge appears next to the title, and the item is rendered in bold in the type tree.
The Type tree view (`/item/{id}/types-tree`, also reachable via the tree icon on the Types tab) renders the full type hierarchy as a directed graph:
This view is useful for understanding the full inheritance chain at a glance and for spotting unexpected connections or overly deep hierarchies.
The direct checklist answers the conformance question: has this instance applied everything its types require?
It collects all actions, outcomes, and event-driven actions from the entire type hierarchy and checks whether the instance has each one. This is a top-down, type-to-instance view: the type system defines what should exist; the checklist shows what is missing.
The table has three columns:
| Column | Content |
|---|---|
| Item | The component or root item the action applies to. Includes an origin trail (← arrows) showing which type and event contributed it. |
| Event | The failure mode or event the action is associated with, if any. Empty for direct actions. |
| Action | The action title with a status icon. |
Each action carries one of five statuses:
| Status | Meaning |
|---|---|
| Done | The action has been completed. |
| Not applicable | The action exists in the instance but has been marked irrelevant for this case. |
| Possibly applicable | Inherited from a type but applicability is uncertain — review required. |
| Pending | The action exists in the instance and is in progress. |
| Missing | Defined by the type hierarchy but not yet present in this instance. |
Missing actions include an Add button that creates the action in the instance with a single click, pre-named from the type.
The checklist is reachable from the Actions tab (all inherited actions) and from the Types tab (the contribution of one specific type to this instance).
The direct checklist only works for lessons that have already been generalized — promoted to a type. A lesson that exists on a single instance, attached to one specific project, is invisible to every other instance. It will never appear in any checklist. A lesson that stays on one instance is a lesson lost.
The inverted checklist answers the complementary question: for each action on this instance, is it generalized to any of its types?
| Direction | Question | |
|---|---|---|
| Direct checklist | Type → instance | Does this instance have what its types require? |
| Inverted checklist | Instance → type | Is what this instance has learned reflected in its types? |
Together they close the knowledge cycle: lessons flow down from types to instances (direct checklist ensures application) and back up from instances to types (inverted checklist surfaces what needs promotion).
The inverted checklist (accessible via the clipboard icon on the Types tab, or at `/item/{id}/icheck`) can be viewed at two levels:
Instance level — for one specific instance, lists all its actions with their generalization status. Useful during project work to ensure that lessons from this project are being captured in the type system.
Type level — when run from a type, aggregates across all instances of that type. This produces a complete propagation map: what all instances have collectively learned, which lessons are already in the type, and which are not. This is the view most useful for audits — it directly answers whether a lesson learned on project A has reached project B of the same type.
Actions that appear as Missing in the inverted checklist have no type-level counterpart. Each one is an open item: review it and either promote it to the appropriate type (so future instances inherit it) or mark it `not applicable` on the type (to document that it is deliberately not generalized). Both paths close the gap. Either way, the judgment is recorded in the structure.