Yes I can see how FaultCat should be very useful to support arm-waving about the need for r2r and design for repair with something closer to evidence.
I’m no expert on the terminology but isn’t “root cause” analysis about understanding (and potentially trying to stop/minimise impact of recurring problems) what caused the fault - so it’s more relevant to design for repair, whereas “fault” is what actually needs fixing, which is more directly relevant to fixers.
Is that right?
Root cause might be that user dropped their laptop, or it got rained on, or a bearing achieved its design life and wore out on the hard drive/fan, or the user installed a second AV on top of the first one, or unknown. The resulting fault could be on the system board, storage, or configuration or Operating System, … or on several of these. So I disagree that there must be only one fault - yes there often is only one but no reason there can’t be multiple - if that worn out fan made the power supply overheat that could have also blown the system board and storage, for example. I suppose what I’m saying is that the definition of “fault” here (i.e. for a repairer facing a non-working item) is “what has to be fixed for the item to work”.
There is only one root cause, though, so we need to be careful about terminology, and we aren’t attempting to attribute root cause in FaultCat.
But don’t get me wrong, because FaultCat is simply brilliant - and it could be even better if we had better data going into it - and if we could collect more info then perhaps @Monique and the team could work on RootCauseCat