The Threshold That Isn't a Frequency
"Just remember it exists" is the standard answer when something happens rarely enough that building a system for it feels like overkill. Renew the cert manually. Check the backup by hand once a quarter. Keep a mental note that this one config drifts and needs a glance before deploy. The implicit model behind all of this is a frequency threshold: below some rate of occurrence, a human holding the fact in their head is cheaper than code holding it for them. Above that rate, automate.
The model is wrong, and not in a subtle way. Frequency isn't the variable that decides whether the rule holds. Cost of a single miss is. And those two variables only look like the same thing because frequency is easy to count and miss-cost usually isn't, until the day it is.
Run the actual arithmetic. The decision to automate something is a bet: one-time cost of building the system against the expected cost of relying on memory, which is roughly (probability of missing it) times (cost when you do). Frequency only enters that equation as a multiplier on the number of chances you get to miss. If the per-miss cost is trivial, high frequency just means you pay a small tax often, and automating saves you the accumulated small taxes. Fine, that's the case the rule was built for. But if the per-miss cost is severe, the rate at which the thing occurs barely matters, because you only need one miss to blow past the one-time price of automating. A thing that happens twice a decade and ruins a weekend when it's missed was worth automating from the first decade. A thing that happens daily and costs nothing when missed might never be worth automating at all. Frequency was never load-bearing in that comparison. It just happened to correlate with it in the cases people usually reach for when they're explaining the rule to themselves.
The reason this is easy to get backwards is that frequency is the only half of the equation you can see before anything goes wrong. You can count how often a task comes up. You cannot look at a thing that has never failed and read off what failing it would cost. That number doesn't exist yet. It's generated by the failure, after the fact, in the form of however bad the incident turns out to be. So the calibration people actually do, the one that feels rigorous because it involves a number, is calibration on the wrong axis. "This only comes up twice a year" sounds like due diligence. It's really just a report that the visible half of the bet looks small, said with no information at all about the invisible half.
This is also why the failures that come from trusting the rule too long tend to look the same shape every time. Someone decided a thing was rare enough to hold in memory. The cost of forgetting it sat invisible, untested, for however many cycles the rule happened to work. Then one cycle it didn't, and the cost that had been zero every prior time turned out to have been a fixed number the whole time, just unmeasured, and it landed all at once instead of amortized. Nobody updated their estimate of the risk because there was nothing to update it with. The rule looked validated by every success it had, right up to the point it wasn't, and the validation was never real validation, it was just an absence of sampling the tail.
The fix isn't "automate everything," which just relocates the judgment call rather than resolving it, now you're deciding what's worth the engineering cost instead of what's worth the memory cost, same problem, different currency. The fix is asking the right question when you're tempted to say "just remember it." Not how often does this come up. What does it cost me, specifically, the day I don't remember. If you can't answer that because it's never happened, that's not evidence the cost is low. That's evidence you haven't paid it yet.
Frequency is the number you have on hand. Miss-cost is the number that actually decides the bet, and it only shows up once, uninvited, after you've already made the call.