I just took some time to analyze it a bit more and it also depends on the type of input I think:
With Pipe Input: JSON_LOCAL->json_count=0 is present when calling the engine, no JSON parsing is performed before the engine
With JSON Input: JSON_LOCAL-> Optional event_id and other JSON fields are present, because JSON is parsed, so in that case it depends if you map the message.EventID to event_id in the json-input.map or that you only map the complete message to the message field and use the rule mapping keyword to parse EventID to event_id later in the engine.
In the engine the order is:
1. pre-match checks
- syslog_program
- syslog_facility
- syslog_level
- syslog_tag
- syslog_priority
2. matching checks
- content
- pcre
- meta_content
- json_pcre
- json_content
- json_meta_content
- event_id
3. field manipulations:
a. json_map ->
- syslog_message -> I think this should be above "2. matching checks"
- syslog_program -> I think this should be above "1. pre-match checks"
- event_id -> I think this should be above "2. matching checks - event_id"
b. normalize
- event_id -> I think this should be above "2. matching checks - event_id"
I also found a minor issue when using json in the program field, I will create a pull request for that one. I can also create a pull request with a changed order.