Failure Mode Taxonomy

A failure mode taxonomy is the named, agreed list of ways a system is known to go wrong, used so that failures can be counted rather than merely described. Without one, every problem is recorded as bad output, which means the log of failures is a pile rather than a dataset: you cannot tell whether last month's most common problem improved, because last month's problems were never sorted into kinds. The taxonomy comes out of error analysis rather than out of a design session. Categories invented before anyone has read a hundred real failures tend to describe what the team feared rather than what happens, and they are then hard to abandon because reporting has been built on them. The better sequence is to read failures, write the causes in ordinary language, notice which phrases keep recurring, and promote those into names. Four to eight categories is usually the useful range: fewer and the counts hide the thing you would act on, more and nobody can classify consistently. Three properties make a taxonomy usable. Categories should be distinct enough that two people classifying the same failure agree most of the time, which is worth testing rather than assuming. Each should point at an owner or a fix, since a category nobody can act on is a label rather than a diagnosis. And there should be an explicit other bucket, watched deliberately: a growing other is the signal that the system has begun failing in a way the taxonomy predates, which is exactly when it needs revising. Review it on a schedule and treat it as a living document, because a taxonomy that has not changed in a year is either describing a very stable system or has stopped describing this one. Keep the definitions written down beside the names, with one real example each. The most common way a taxonomy decays is not disagreement about which categories exist but quiet drift in what each one means, which shows up as a trend that reverses when a new person starts classifying.