You ship the same product again: a new generation, a new variant, a new customer programme. Truke KF makes the failure modes found on the last one arrive on the next one by themselves — not because somebody remembered to look.
The AIAG/VDA handbook is explicit about this: step 1 of a new FMEA is to start from the Base FMEA for the product family, so the analysis begins with everything already known rather than from scratch.
In practice the Base FMEA is a file. It gets copied into the new programme, and from that moment it stops knowing anything. When a warranty return three months later proves that a cause everyone rated occurrence 2 happens rather often, that lesson lands in one engineer's copy. The other eleven programmes that inherited the same optimistic rating never hear about it, because nothing connects them — they are copies, not instances. Why an Excel FMEA doesn't learn →
This is not a documentation problem. Most suppliers document diligently, because their customers require it. It is a reuse problem, and it costs the same money twice.
KF earns its place in some engineering organisations and not others. The difference is not the industry — it is whether you build the same kind of thing more than once.
A reference design carries what the family has learned. A variant is an instance of it, and inherits that automatically — including lessons written after the variant already existed. Nothing is copied; the picture is derived every time it is read. How Experience Inheritance works →
HARA, AIAG/VDA, J1739 and IEC 60812 are the same activity in different words, so KF implements one model and configures it per standard. Action Priority and ASIL ship as presets, not as bespoke code.
ISO 26262 AIAG / VDA FMEA SAE J1739 IEC 60812 ISO 9001
Each page carries a clause-by-clause mapping, and the AIAG/VDA one ends in a compliance table with the gaps marked as gaps. There is a row in it that reads process control plan — not supported. If a table like that is useful to you rather than alarming, we are probably a good fit.
Two of these were run as tests rather than demonstrations: acceptance criteria written down before the work started, and what failed recorded next to what worked. Each one produced a database you can open.
An electric power steering HARA: item definition, malfunctions, operational situations, hazardous events classified S/E/C, ASIL determined, safety goals derived. Ten of ten reference S/E/C→ASIL vectors reproduced with no code changes — and a HARA and a conventional component FMEA in one database, each with its own matrix.
An 8D cycle as a reusable type, with one question put to it: when a team learns something on Monday, does it reach the programmes that started last year? Yes, and retroactively — a preventive action promoted to a type appeared as an open checklist row on an instance typed before the lesson existed, with nothing written to that instance.
We are not asking you to replace anything. Requirements stay wherever they live, meeting notes stay in the wiki, tickets stay in Jira, and the BOM stays in the system that owns it. KF takes the knowledge that currently falls between those tools — failure modes, causes, corrective actions, the obligations a programme has taken on — and keeps it connected to the products it belongs to.
A component tree imports from CSV or XLSX and round-trips back out with a provenance header. Everything KF stores is reachable over a documented REST API, and an MCP endpoint lets an AI assistant answer from your failure history rather than from the internet. KF alongside a wiki →