To be sure, there are limits to one's sanity when over-applying this principle, but I also would apply it far past where many would stop. A simple explanation that doesn't quite fit needs yet more inquiry. Normally, the application pre-limits the number of things that may go wrong, and you can use that to save some effort. For example, I may not know if a pressure sensor's wiring diagram is correct enough to squelch Cthulhu's call, but since that has not bearing on if the vaccuum system's gases are pure, I also don't care. (That's the sort of thing HR and Operations to worry about.)

Usually this meant digging in deep, questioning really basic stuff like "Are we sure this model is normally open or closed? Did the manufacturer forget to tell us?", and normally there would be clues or evidence to hint at the next round of questions. Eventually you'll have enough information that the evidence fits the questions, and there's no clear line of inquiry left. Life experience and just volume of work teaches one the limits of inquiry (old engineers can be shockingly good at this, to the point of appearing sloppy :)

I once spent 6 hours overnight troubleshooting a confusing gas non-leak that ended up being the result of a default setting changing on a valve being replaced off-the-record by not-the-usual-guy. It gave me the confidence that this process does eventually get to the bottom of it, but it was a long, meandering path from miswired panels to out of date schematics in the wrong language to noting how clean the part was to know someone replaced it. All to dig out the missing tribal and undocumented information, proving the PLC was actually correct to interlock the whole machine out. (It's like knowing your program will halt - you can't prove it, but you can still be damn sure it will. At least until it doesn't ;)