Item titles and document bodies, with BM25 relevance ranking. The query syntax is
SQLite FTS5: plain keywords, "exact phrases", prefix*, and the
boolean operators AND, OR, NOT.
Searching is not the same as enumerating. When the question is what is there? rather than where is it?, use the listing view, which always reports a total.
It is, and it is a real regression if you are coming from a grid editor. Simplicity comes at a cost here. There are no plans for a grid editor.
Two things take the edge off it. The editor toolbar has a 4×4 grid for
inserting a table skeleton, and KF accepts a .csv block — paste
comma-separated rows and they render as a table, which is usually easier than
maintaining pipes and dashes by hand. See
the Markdown reference.
Drag it onto the editor, or paste it from the clipboard. There is also a file picker below the text area. Duplicate uploads are detected and stored once.
Yes — that is one of the three supported deployment modes, alongside desktop and web. One caveat: simultaneous editing of the same item should be avoided, because only the last write is retained.
The chain of codes from the item up to Home. Because codes are optional, the path skips items that do not carry one — so it is a readable trail rather than a literal rendering of every level. See knowledge inheritance.
No. It has features that are useful for requirements work — immutable document versions, partial documents, hierarchical data views — but it lacks others, notably dependency links between requirements, versioned files, and variables.
Yes, for Part 3: hazard analysis and risk assessment. Hazardous events are events, safety goals are actions, and ASIL is calculated from S/E/C by the risk matrix — the same model used for every other FMEA in KF, so a HARA and a conventional component FMEA can live in one database with a matrix each. See ISO 26262.
KF ships with presets for AIAG/VDA Action Priority, SAE J1739 RPN and ISO 26262 ASIL. The generic view shows a three-colour scale (green, orange, red) derived from severity and occurrence, with configurable thresholds.
Any item's Risk model page shows which matrix scored it, the scales it was read on, and the rules in the order they were applied — so a rating can always be traced back to the ruler that produced it. Configuration is covered in risk configuration.
The application interface is in English. The volume of interface text is small — a menu and a handful of tab labels — so this is rarely an obstacle in practice.
The product manual and this FAQ are available in English and Spanish.
In: CSV, Excel, and KF packs. Out: CSV, Excel, JSON, OGDL, SVG, MS Project XML,
iCalendar, and PDF through the print views. Importing a CSV whose code
column matches existing items updates them rather than duplicating, which is
what makes a round trip through a spreadsheet safe. See
import and export.
Not as resource management. KF can order actions and produce a Gantt, but people and resources cannot be allocated to them other than in the text. That is deliberately out of scope.
Items do carry roles and signatures, which is a different thing: a record of who is accountable, not a scheduling input.
For this purpose, yes. The signature exists to detect accidental change and to give a revision a stable fingerprint — not to resist a determined forger.
The probability of an accidental collision across n documents is
P = 1 - exp(-n² / 2¹²¹). At a million documents that is
vanishingly small: far less likely than the storage silently corrupting the file you
were trying to protect.
MD5 is not collision-resistant against an adversary who controls the content, and no part of KF's design assumes otherwise. If your threat model includes deliberate forgery, the signature is not the control you want — access control and the audit trail are.