It's a great question, and one worth pursuing a good answer for, IMO.  I have run into this before and basically come up with the answer that I'd have to write a lot of potentially unpleasant code for this or create a more enhanced auditing framework on top of something that is already a bit convoluted in some ways, and have landed on this: if you want methods to track health on a more frequent basis than you are willing to deal with the creation of new, possibly duplicate audit tasks, you might be better off handling this through other means than audits.  And if you're going to be actually creating tasks for audits, those tasks should have some weight to them.  They should have SLAs and governance, and reporting to show whether they are being addressed.  They shouldn't be just another way to look at how we're doing with our data completeness/correctness.  And if looking at it like that makes you (or your customers!) cringe at the thought of having all of these tasks land in their plate "on top of all the other work they have to do" maybe also consider narrowing the criteria of your audit so that at least you are only selecting the "top offenders" or most critical business impact areas as a target for your scripted audits.