Checklists are a practical tool for implementing lessons learned by ensuring that key insights and best practices are consistently applied in future activities. When you create a new item in KF (like a project, task, or product) and you say "this is based on" another item (its type), KF automatically builds a checklist for you. This checklist helps you make sure you don’t forget any important steps or learnings from the past. Among other things, it brings in from the type:
So it’s like KF is saying:
“Hey, last time you did something like this, here’s what you had to do, what you had to deliver, and what went wrong — maybe check these things again.”
The checklist of an item is a two-column table.
| Left column | the item and its components — actual and possible, recursively |
| Right column | for each entry on the left, its tasks — actual and possible |
Actual means present in the item’s own structure. Possible means declared by one of the item’s types, at any level of the type hierarchy, and not present in the item.
Everything is listed, present or not. A checklist is the complete statement of what an item is and what it owes — not a list of open points. So every entry on the left gets a row even if it owes nothing: an empty right-hand cell is the answer “this component has no checks”, which is information, not a reason to hide the component.
A task is anything the item is obliged to: an action to perform, or an object or a document to produce. What makes it a task is the link, not the kind of item it is. Tasks reach an item in two ways — directly, or through an event (a failure, issue or risk). Both count the same; the event is provenance, it says why the work is owed. A lesson learned is exactly that: a task that came from an event.
Take a bicycle whose frame is of a type that requires a paint inspection, and whose brakes owe a task recorded after a field failure:
| Item | Tasks |
|---|---|
| Bicycle Model A | Homologation dossier [pending] 2/3 |
| Frame | Paint inspection [missing] ← Frame type |
| Brakes | Re-torque the caliper bolts [done] ← Brake fade |
| Wheels and tires | |
| Battery (missing) ← Bicycle type | Cell qualification report [missing] |
Every component is a row — including the one that owes nothing (Wheels and tires) and the one the bicycle does not even have yet (Battery, required by its type: both it and everything it owes are missing). The paint inspection is possible, not actual. The re-torque is actual and arrived through an event, shown as its provenance.
This asymmetry is what keeps the two columns from collapsing into each other.
The left column is decomposition: an item splits into its components, and each of those into theirs, as deep as the structure goes. The right column does not. A task is one cell. It is never broken open into its sub-tasks, and if it has a breakdown of its own — an action with the steps or tools it needs — that breakdown does not climb into the left column. Otherwise a torque wrench would end up sitting next to real components, as though the bicycle were made of it.
Nothing is lost, because a task is itself an item, and every item has a checklist. The breakdown of a task is one click away: open the task and read its checklist. Depth is reached by navigating, not by flattening.
A task that is never split could hide an arbitrary amount of work behind one innocuous line. An ISO clause listed as a single row may decompose into four concrete obligations, and a reader would have no reason to click.
So each cell carries a roll-up of everything beneath it: Part 10 (Improvement)
[missing] 0/4. The number on the cell is exactly what the page behind the cell reports. A
pending task whose subtree is entirely done or not applicable counts as done — though an
explicit judgment always stands, so a task marked done with 1/2 beneath it keeps saying
done and keeps showing the tally, putting the contradiction on the page rather than
hiding it.
Each task carries one of five statuses:
A type’s not applicable is carried down verbatim: if a type declares a task and marks it not applicable, its instances do not owe it — they show not applicable, not missing. Mark it once on the type and it is settled for every instance, present and future.
A type’s resolved is carried down the same way, and it is the other half of that idea. Resolved means the type has met the obligation itself, for all its instances at once — a homologation obtained once for the product line, an analysis performed centrally. An instance that lacks the task shows resolved, not missing: the work exists, it is simply not the instance’s to repeat.
A type’s done does not carry down, and the contrast is the point: done says the work
was finished for that item alone and says nothing about anyone else, while resolved says
“finished, and it counts for my instances too”. Everywhere else the two behave alike —
resolved closes its cell and counts as done. The exemption applies node by node: a
resolved task whose sub-task is still pending arrives as resolved with 0/1 beneath it,
because the type answered for what it answered for.
Components are counted differently from tasks, by presence rather than progress: a component the item has is done, one its type declares and it lacks is missing. A component is never pending — “we have a battery” is not half an answer.
The compliance checklist is the same table restricted to a single type: only what that type contributes and the item still lacks.
It answers “does this item comply with that standard?”, where the plain checklist answers “what does this item owe, from all its types at once?”
Everything so far propagates lessons downwards, from a type to its items. That only works for lessons that are already in a type. Look again at the bicycle: the re-torque task on Model A’s brakes came from a real field failure, and it sits on Model A alone. Model B’s brakes will never hear about it. No checklist will ever mention it. A lesson that stays on one item is a lesson lost.
The inverted checklist runs the same relationship backwards:
| Direction | Question | |
|---|---|---|
| Checklist | type → item | Does this item have what its types require? |
| Inverted checklist | item → type | Is what this item has reflected in its types? |
For each task on the item the answer is yes or no:
There is no third answer — in particular, there is no such thing as a lesson generalized to the wrong type. Nothing in KF ranks an item’s types against each other.
Cells behave exactly as they do in any checklist: a task is one cell, never split, so it carries the roll-up of everything beneath it. When a task is not generalized, nothing beneath it is either.
On an item — every type of the item may answer. The question is “is what this project learned captured at all?” This is the view to use while the work is live and the lessons are still being learned.
On a type — lists the tasks of every item of that type, and only that type’s hierarchy may answer: what it declares, what it inherits from its own types, and what its components declare. The question is the sibling question: Model A’s brakes learned something — do Model B’s brakes, of the same type, get it? Only if the lesson reached the shared type, because that is all the two bicycles have in common.
So a lesson generalized to some other type Model A happens to have is real, and the item view credits it — but it does not reach Model B, and the type’s view reports it as the gap it is. This is the mirror of the compliance checklist: both are restricted to the one type you asked about.
Some lessons are genuinely one-offs — a particular supplier, a situation that will never recur. There is a clean way to settle one: generalize it to the appropriate type anyway, then mark it not applicable there. The gap closes for every item at once, because a type’s not applicable is carried down verbatim. The judgment is documented, and the lesson stays visible in the type’s history without imposing work on anyone.
Mark it resolved instead when the lesson does apply to every instance but the work answering it is done once at the type level rather than repeated by each one: the instances inherit that answer rather than a gap. The two are not interchangeable — not applicable says nobody owes this, resolved says it is owed and already met — so an audit can tell a waived requirement from one that was satisfied centrally.
A recurring question in ASPICE and ISO 9001 audits is “how do you assure that all lessons learned are covered by the design process?” The usual answer is a register, a review gate, a procedure — mechanisms that rely on people remembering to consult them.
The two checklists answer it from the structure itself. The checklist shows that known lessons are being applied to current work; gaps there are action items. The inverted checklist shows that what current work is learning is making it back into the type system; gaps there are lessons to promote to a type, or to mark not applicable. Together they close the cycle — down from types to items, and back up from items to types.