At Dropbox, we have so many herald rules, that figuring out why herald did something is a huge pain - our herald transcripts are extremely long (on the order of 10 screen lengths) and mostly consist of rules that were not matched. And not all actions herald takes are equally important (it's fairly normal for herald to cc a mailing list based on which repository is being edited, which is not interesting); on the other hand, we also have herald rules that add blocking reviewers - and it's way more important to know why a blocking review was added than most things that herald had done. This is such an annoyance for some of my coworkers, that one of them wrote a chrome extension just to parse our herald transcript for the reason that a security review was added: https://chrome.google.com/webstore/detail/heraldsplainer/djkffgblckgfgjknbgcjnbffoocnhbcj
The current process for figuring out why herald did what it did looks like this:
1. for a diff with lots of back and forth, expand all the old comments to find the link to the herald transcript
2. on the herald transcript... it tells you what actions it took, and what rule numbers (e.g. H101), but not what those rules are. Scroll down and hope to find the PASS rules in the sea of FAILED. Or better yet, ctrl+f for "passed".
3. Hope the rules are well-named so you can tell which action corresponded to which rule, and why it matched.
It would be helpful if matched herald rules could be surfaced more prominently for why blocking reviews are added - ideally like the chrome extension does, just below the test plan of the diff (or something functionally similar, that isn't prone to be buried in the comment stream). This way it's easy to see, at a glance, why your review (or some group of reviewers) was added to the diff.
Such an improvement could probably be generalized to any reviewers added by herald, with no loss of usefulness. Having all herald matches surfaced like this, though, would be noisy, because some herald rules match a large portion of diffs but aren't very important to the author or any reviewers / subscribers (like emailing code review mailing lists).