My semi–informed guess: even with automation you need the message to be decipherable by human eyes. Also: you'd now have to keep your data dictionary in sync b

My semi–informed guess: even with automation you need the message to be decipherable by human eyes. Also: you'd now have to keep your data dictionary in sync between your version of the product and whatever third party log analyzer you're using. It isn't impossible, but it doesn't seem to be in anyone's particular interest to solve. I used to write error messages for IBM RACF (a security product for MVS), circa 1990-1992. Mainframe stuff (the O/S, products, etc) emit messages and codes of various sorts. Most are inhaled by automation systems, but all are semi–legible to humans, because sometimes the automation systems throw up their digital hands. The first hard lesson I learned is: once a message is in the system, you can never change it. You can replace it (with a completely different message identifier and text), but you can't change the typos you find (they're 20 years old at this point) or lowercase the all–uppercase messages to make them look pretty (I didn't do this, but someone briefly on my team did). When I moved on to doing web stuff, I hacked my copy of NCSA to emit a simplified access log, timestamps were Unix epoch, I skipped the "user" fields, error codes were in hex (ie, not "200" but "C8" for Document OK). Thought I was a genius, saving space and all that. But every tool assumed what we now call "common log" format and it meant that you couldn't just look at a snippet of log at a glance to see what was going on. So I ended up reverting back to common log format after a couple of months.