Jorel Fermin

Both good points. The guard is in the app; it just wasn't in the article. Worth saying why it has to be a compile-time check rather than a test: Cargo builds test and bench targets with unwinding no matter what the profile says, because libtest needs to catch the panic to report the failure. So a test that asserts the scan survives a panicking rule passes even in a tree where a profile sets panic = "abort" and every guard is inert. The build is the only place that mistake is visible. The visibility point is the one I would push further than you did. It isn't really a logging decision; it's about what the customer can conclude from the report. They're looking at a cost report to decide what to turn off. If rule 57 died on one EBS volume and all they see is no EBS finding, they conclude that volume is fine and move on. The report has quietly told them something false. A line naming the check and the resource turns that into a known gap they can act on, and for an air-gapped customer who can't just ask us, it's the difference between an incomplete answer and a wrong one.