As regards software error, we do so many things (standard style guides, pair programming, code reviews) to limit error, yet give so little thought to where and how errors come to be. And specifically, what methods would best combat them.
This article and the procurement process it documents is a great example of "intentional but mistaken actions". Which is to say the actions taken were intentional, the actions were realized as intended, but the original formulation was flawed.
Reason notes these errors tend to thrive in overly compartmentalized, deep, bureaucratic environments. Everyone is doing their job, but there's no one keeping an eye on the big picture when the train heads off the rails.
The difficulty, according to him, is that higher-cognitive checks needed to short circuit these kinds of errors tend to be less effective (than lower, more primitive ones). IOW, we delude ourselves that everything is fine as often as we recognize the issue.
I expect this is part of the secret effectiveness of pass/fail unit testing. It's hard to rationalize a red indicator into a green one.
[1] https://www.amazon.com/Human-Error-James-Reason/dp/052131419...
I'm not sure how comprehensive / modern it is (not my subfield), but I enjoyed it. And it provided at least one framework to think about error.
Specifically, that most errors can and should be categorized by the states necessary for their happening. Because the unique characteristics of each state (of which there are many) all suggest very different approaches to resolving or eliminating them. To bring it back to the example in question here, remediating the procedure to eliminate a lack of knowledge of failure cases or risk would not have prevented either of these accidents (both were well-informed). However, technical solutions to physically prevent unacceptably risky "bypass" procedures would have.