How do you make a waiver's expiry date enforced by the engine rather than documentation?

## The difference between a date and an enforced expiry Almost every exception process has a date on it. Very few of them enforce it. The distinction is simple and it is entirely mechanical: is that date read by the thing that makes the decision, or by a human who was supposed to remember? An enforced expiry means the exception record is data the engine loads while deciding, and the match on that record includes a time condition. Conceptually the rule says: this violation is allowed if there is an exception record whose scope covers this resource **and** whose expiry is still in the future relative to now. The instant that stops being true, the exception is simply not there any more, and the rule reaches the same conclusion it would have reached if no one had ever filed a waiver. That property — the exception evaporating on its own, back to the pre-waiver behaviour — is the whole point. It converts "we will revisit this" from an intention into the default outcome. ## What "now" means, and why it matters The comparison has to be against the time of the decision, from a clock the engine controls. Two practical consequences: - **Use absolute UTC timestamps** in the record. A date with no timezone is an argument waiting to happen when a deployment fails at 01:00 local on the day of expiry. - **The evaluation time is the deciding moment, not the authoring moment.** The same unchanged configuration can pass in the morning and fail in the afternoon, and that is correct behaviour rather than flakiness. Be ready to explain that to the team it happens to, because "nothing changed and now it fails" is exactly what an expiry is supposed to produce. ## Fail closed on malformed records The interesting edge case is the record whose expiry is missing, empty, or not a timestamp the engine can parse. There are two possible designs and only one of them is safe. If an unparseable expiry is treated as "no limit", then the easiest way to get a permanent exception is to fumble a field — and that is a defect an attacker or a hurried engineer can both reach. Treat an exception record without a valid expiry as an invalid record: it does not load, it does not match, the rule denies. Enforce the same thing earlier with a schema check on the record itself, so a waiver that would be inert never gets merged in the first place. ## Do not make the expiry a surprise Enforcement is necessary but it is not the whole design. A waiver expiring at midnight on a Friday, discovered by the on-call engineer at 09:00 Monday when a deploy is suddenly blocked, is technically correct and organisationally corrosive. Because the expiry is a field in a record you already own, you can act on it without any new machinery: enumerate the records, find the ones expiring in the next two weeks, and notify the owner team named in the record. The notification is advisory; the enforcement is still the timestamp. Nobody can extend anything by ignoring a message. A short grace period is a design choice you should be able to argue both ways. Against: a grace period is just a longer expiry with a friendlier name, and it teaches people that the date is soft. For: on a rule whose violation is low-severity, a few days of warning-only after expiry keeps a deploy pipeline from becoming an incident. If you allow one, make it a property of the rule's severity, not something a requester can ask for. ## Keep the expired record When an exception expires, do not delete the record. The interval during which a control was knowingly not enforced for a given workload is exactly what someone will ask about later, and the record is the only thing that answers it. Archive it — the same store, marked expired — so the history shows the scope, the justification and the window. Renewing should create a new decision, not resurrect the old row in place. ## Worked shape Take an allowed-regions rule that requires all resources to be created in an approved set of regions, excepted for one workload that must run near a partner's data centre. The record scopes the exception to a single account and a resource-name prefix and expires in eight weeks, because that is when the partner's regional endpoint is due. On the day, the rule stops finding a live exception for that prefix, the next plan carrying an out-of-region resource is denied, and the owning team either has the endpoint or has to come back and say why not. Nothing about that sequence depended on anybody remembering. ## The failure this replaces The alternative most places actually run is a review meeting: a list of exceptions, a quarterly slot, and a room of people who have no independent way to check whether each condition still holds. Every item gets waved through because the cost of arguing is high and the cost of agreeing is zero. Enforced expiry inverts that: doing nothing removes the exception, and keeping it costs an action.