So I looked over the PR and I (as well as others) agree there are some changes in it that have merit that we'd like to definitely integrate, particularly the idea of inverting the instanceof changes and delegating it to the strategy. That definitely makes it far more flexible in the future for "other" strategies.

In my brief review of the PR, I noticed you added two strategy methods where one is meant to handle the inverted instance-of scenario by initializing the strategy and the other is meant to add the additional columns you speak. What I fail to see based on the PR is how exactly is it that you intend to source/populate those additional columns once they're added to the audit schema row?

For argument sake, lets say you're using a database trigger or custom event listener to populate the values. Is it safe to assume these columns are similar to REVEND/REVEND_TSTMP where they're never fetched but just stored in the database row itself for external tools, queries, etc to make use of those as needed, never to be returned as part of any entity instance?