Filtering exceptions: every one needs an expiry date

Five things, and the fifth is the one nobody writes down.

What is exempted. The narrowest accurate description: this URL path, this form field, this client. A scope recorded loosely will be read loosely a year later by somebody deciding whether it still applies.

Why. The specific case, not the category. «Support form rejects error messages containing HTML» survives; «false positives» does not, because it describes every exception ever made and therefore distinguishes none of them.

Who owns it. A person or a team who would notice if it were removed. Exceptions without an owner are the ones that survive reorganisations untouched, because removing them is nobody's risk to take.

When it ends. A date. Either the exception expires then, or somebody looks at it then, and record which of the two it is.

What would make it unnecessary. The condition under which the hole can close: a form that stops accepting raw HTML, an integration that starts signing its HTTP requests, a rule adjusted upstream. This field is what turns a list of exceptions into a list of work, and without it the review below has nothing to decide with.

Lifetime is the useful way to sort them, because it determines what you do next rather than how the exception looks.

Incident exceptions, added while something is on fire. These have the shortest legitimate life and the highest survival rate, which is the whole problem. Anything added during an incident should carry an end date measured in days and be revisited when the incident review happens rather than whenever somebody remembers.

Launch and migration exceptions, added to get something out of the door. These live for weeks and end when the thing they unblocked is stable. Their characteristic failure is that the launch succeeds, everybody moves on, and the exception is the only trace of a temporary state that no longer exists.

Integration exceptions, describing a partner, a provider callback, or an internal system. These have no natural end, and pretending otherwise produces an expiry date that gets extended without thought every time it arrives. Give them a review date instead, and treat the review as a check that the integration still exists and still behaves the way the exception assumes.

Content collisions, where your own legitimate content trips a rule. These should be the shortest-lived of all, because an exception here is a workaround for a mismatch that can usually be corrected at the rule or in the form. Left permanently, they are the class most likely to widen, since the next similar collision is easiest to solve by extending the exception that already exists. Finding these in the first place is the subject of false positives.

Some exceptions are permanent, and the honest thing is to say so rather than to set a date nobody intends to honour.

A permanent exception is not dangerous because it is old. It is dangerous because its scope drifts: the integration it describes gains new endpoints, the client identifier it names is reused by something else, the route it covers is reorganised so that the exception now applies to more than it did. Age is a proxy for that drift, which is why review dates work even for things that will never be removed.

Two habits keep them honest. Recording the scope in terms that fail loudly when the world changes, rather than terms that quietly widen. And reviewing them against the thing they describe rather than against the exception itself: the question is whether that integration still works this way, not whether the exception still looks reasonable.

Deleting an exception is a change to filtering behaviour, and it deserves the same care as adding one.

The safe sequence is to stop enforcing the removal before making it: put the affected traffic back under observation, watch what would now be refused, and confirm it is what you expect before the exception actually goes. That is the same discipline as monitor mode, applied in the opposite direction, and it turns a removal from a guess into a measurement.

Two things not to do. Do not remove several exceptions at once: if something breaks, you will have no way to attribute it, and attribution is the entire value of doing this deliberately. And do not remove them during a period when traffic matters most, such as a sale or a launch, because the failure mode of a wrong removal is refusing customers at exactly the moment there are most of them.

Where a removal does cause refusals, reinstate the exception first and investigate afterwards. The information is still there an hour later; the customers are not.

A standing review, on whatever cadence you already use for other configuration.

Go through the list, and for each entry ask the three questions the record already contains: does the reason still hold, does the owner still exist, and has the condition that would make it unnecessary been met. Entries that fail the first two are candidates for removal today. Entries where the third is now satisfied are the work the review exists to find.

The list itself is the deliverable. An exception that is not on it is not managed, whatever its expiry date says, and the most common reason a review finds nothing is that the exceptions being added are not reaching the list at all.