Thanks! A time window is a reasonable way to do it too. We went with "consecutive, reset on any delivery" instead: a mailbox that was full for a day gets one delivery afterwards and starts from zero, however long ago the bounces were. A window mostly matters when a contact is mailed rarely, where seven sends can span months.
On the audit question: not on the suppression row itself. That row keeps the category (hard bounce, complaint, unsubscribe, manual), where it came from, and an optional note. The raw SMTP code and the server's reply text live on the send/bounce event that caused it, so an audit goes suppression → source event → the exact response. Fully agree it's worth keeping. Most of the false-bounce fixes in the post were found by reading those raw replies, not the categories.
StackShortlist
Proof Over Promises.
Nice that you call out the cost of over-suppressing. A soft bounce counter with a time window (say 3 soft bounces across 14 days before suppression) avoids killing addresses that just had a full mailbox for a day. Do you also store the raw SMTP code with each suppression? It makes later audits much easier.