You're right: it's not so clear-cut. Maybe the same constraints and cascade rules of normal entities manipulation should be applied. If I delete an entity audit history and there is an "on delete cascade" association, envers may delete on cascade too, otherwise, the same rule can be applied as when one delete a normal entity referenced by other entities: the caller must first delete explicitly all the other audits that reference this audit, or an exception is thrown.

Another way to manage this situation is the following: if I'm right there are no FK constraints between audit tables, apart from the FKs towards the central revision table: so I think it would be reasonable to remove some audit history from an entity leaving the historical references to it and, when one query for historical data that references the erased data, the Envers API might treat such broken relations as "lost data", returning null and empty collections or some other sentinel object. After all, it is the developer's responsibility to manage such events and give user with the appropriate information.