What do you want to achieve?

All audit changes are valid by themselves. For example if I have access to the codebase I can modify it however I want and it would be a valid action. If I delete the code it would be a valid action still, just malicious.

If, on the other hand, the codebase has some classes which I'm allowed to modify and some I'm not (so modifying them would be an invalid action), that should be resolved on the roles stage (by separating the code into two different databases and giving me write access only to the one db I should be able to modify).

Essentially, user should be allowed to perform only valid actions and audit exists to check for malicious actions.

Using audit for additional validity checks is not recommended because audit does not serve this purpose.

Great answer, but I'd like to add that there are two distinct cases for working with XDatas:

  1. Where XData itself is an object of work (for example generating a part of WSDL spec and saving it in a class XData).
  2. Where XData is just a container for miscellaneous data (for example a template with placeholders).

The code above works for the first case, but for the second case it might be preferable to create an independent copy of an XData stream so that no locking happens - this prevents XData object access/modification errors, especially in Dev environments. Furthermore objectless way of getting XData contents would be faster.

I usually use this method to get streams if my XData work falls into the second category:

ClassMethod getClassXData(className, xdataName) As %Stream.Object
{
    set stream = ##class(%Stream.TmpCharacter).%New()
    for i=1:1:$$$comMemberKeyGet(className,$$$cCLASSxdata,xdataName,$$$cXDATAdata) {
        do stream.WriteLine($$$comMemberArrayGet(className,$$$cCLASSxdata,xdataName,$$$cXDATAdata,i))
    }
    quit stream
}

This code can be further improved for most use cases by replacing a stream with a string.