Public technical writing on failure analysis, risk and organisational learning — written to be useful whether or not you ever install anything of ours.
Engineers discount marketing claims, correctly, and we would rather not make any. So everything published here carries the same things:
The last two are the point. A case study with no limits in it is an advertisement, and you would be right to discount it.
An argument in eight movements about what the standard actually guarantees: the paradox of a simulation that does not simulate, the factor of two, safety goals that were already the requirement, and metrics that depend on the thing they are meant to measure.
Three workflows run as tests rather than demonstrations. Each produced a database, and each write-up says what failed.
Does a lesson learned on Monday reach a project that started last year? 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.
An electric power steering hazard analysis: 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 with different matrices.
65 requirements verdicted. The finding worth reporting was not a seeded gap: 16 requirements had evidence present and no link to it. And the honest answer to whether an audit can run on structured data alone — partly.
Mappings between the standards and one underlying model, each ending in a compliance table with the gaps marked as gaps.
AIAG/VDA and its seven steps, SAE J1739, IEC 60812, ISO 26262 and ISO 9001 — including the rows that read not supported.
Where a spreadsheet stops being the right tool, and where it does not. Includes what Excel still does better and the case in which structuring an analysis returns nothing.
The auditor's question about lessons learned, why a procedure is a thin answer, and what a derived register can show instead — with what it still cannot prove.
This library is new and it is short. It will grow in the direction of the work — DRBFM and DRBTR in practice, fault trees from real failure data, lessons-learned methods that are not just a register, and the failure-analysis patterns that recur across industries.
If there is something you keep having to explain to colleagues and cannot find written down properly, tell us. That is a better guide to what to write next than our own guesses.