Sorry for the late bump.

We implemented a solution to address audit concerns by:

1. Creating an internal tool to define:

A. Schema of tables of audit interest and their related look up tables (to capture lookup values at trigger execution... As raw foreign key values can have their relevant values changed (lookup table's state Id = 1 state name could be changed from 'Arizona' to 'Texas'))

B. Provide 'Friendly' field names and relationships.

2. Create an end user tool which creates high performance, hard coded field name triggers which capture end user specified audit information.

3. End user tool to view and mark 'reviewed' status of information.

This strategy places the ball in the client's court to define relevant audit information. Generally, an intermediate developer can be tasked with updating the schema and then the client becomes wholly responsible for audit.

Any thoughts?