This approach seemed logical, sensible, and straightforward, but failed miserably in practice. Most decision trees for human use are ineffective procedures. They suggest what to do, but are typically based upon a simplified view of network function that is understandable to a human. The typical tree addresses a few failure modes and makes assumptions about the precedences between tasks and couplings between components that may not be true in practice.
Perhaps these limitations of a decision tree arise from its real (and perhaps hidden) purpose.
Proposition 1: A decision tree is not an embodiment of technical knowledge, but rather a statement of operating policy[9].It is a description of what a human should ``try first'', not necessarily what must ``work first''. The order of tests and actions to be taken are tempered not by physical dependencies, but by service expectations and site mission. For example, `Rebooting' might be a routine expedient at an academic site, but not at a bank!
Thus one must consider any decision tree not as an effective procedure, but merely a theory of what to do when. One does not interpret such a tree literally, but instead bases a course of action upon the information in the tree. In practice, this is what we really do with our own troubleshooting procedures; we `jump around' within the tree, executing the steps not in order of tree appearance, but in order of their likelihood of causing the problem we have detected.