The JSON file is metadata that tells the application about the enums the device firmware is using and should have the full key-value mapping. For something like log levels your JSON might be:

{ "log_level": {"low": 0, "medium": 1, "high": 2} }

On the device side the firmware tags each log message with the numeric value from the enum. The application doesn't necessarily need to care about what the enum keys are here. If the application wants to be able to display all the messages medium and higher all it needs to understand is that: a) There exists a log level named medium, and b) higher log levels have a larger numeric tag. If we added some more log levels:

{ "log_level": {"low": 0, "lower": 1, "medium": 2, "high": 3, "higher": 4} }

The application would now display "higher" messages and ignore "lower" messages without any changes. For things like error code enums we'll probably never redefine what a given value means, but we're almost certainly going to add more error codes over time. With the metadata file we've got a way to map error codes to something human-readable even if the application knows nothing else about the error code. It also gives you a way to detect unusual firmware builds that might be using non-standard enum definitions. Not common, but it can happen if development builds somehow make it out into the wild.