We do heavy sub-typing of AuditEvents where we add a lot of different AuditEvent subtypes with a lot of different event fields.
This makes generic AuditEvent processing more or less impossible.

My understanding was always that we have security related AuditEventTypes and system change related AuditEventTypes. For change we have Write and Call. Regarding the representation of the information passed for Write and Call, we can have generic event fields for the service parameters. Subtypes would define the scope but not add event fields.

But if I look at Part 9, most of the AuditEventTypes repeat the InputArgument content already available on the AuditUpdateMethodEventType as individual event fields.

It would be painful for a central audit log client to subscribe for all possible combinations and impossible for a central subscriber using standardized PubSub DataSets.