An applied rule set removed the applier's own right to change a store's rules — how do you make the rules changeable again?

## Why the apply succeeds This is the part that surprises people. The set that locks you out is a perfectly valid set, and the applier holds every right needed to install it at the moment it does. Nothing fails. The store enforces the new rules from that point on, and one of those rules is that this identity may no longer change rules. The failure surfaces at the **next** apply — hours or weeks later, usually attached to some unrelated change — and it presents as a permission error that makes no sense to whoever is on call, because the applier "has always been able to do this". The same shape has two variants worth recognising: - The applier loses its own right, and nobody else has one either — the rules are now frozen. - The applier loses its right while some human path survives — recoverable, but only if anyone remembers it exists. ## Recovery must sit outside the rule system The defining property of this failure is circularity: the thing that repairs access is the thing access was taken from. Editing the declared file changes nothing, because applying it is what you can no longer do. So the way back has to be a path the rule set does not govern, and it has to have been arranged **before** the lockout. Designs genuinely differ here, and it is worth knowing which your store offers: - an administrative credential established when the store was set up, held offline and not routinely used; - a recovery that requires several holders to act together, so no one person can use it quietly; - an identity or rule the store will not let an applied set alter, so the escape can never be legislated away; - nothing of the sort, in which case restoring the store's earlier state is the only route — which brings back the old rules and loses everything written to the store since that point, a cost the team usually discovers at the worst possible moment. ## Preventing it at preview time The control that catches this is the one that also catches the over-wide grant: an effect preview computed from the proposed set. A lockout is trivially visible there — it is a **loss** in the delta, on the applier's own row. Two guards follow directly: 1. The applier refuses to apply a set under which it loses its right to change rules. 2. The rules that protect the escape path are outside what an applied set may alter, so the guard cannot be removed by the same mistake it is guarding against. Neither guard requires knowing what the rule change was for. They are mechanical checks on the delta, which is why they survive a reviewer having a bad day. ## What makes a recovery path real 1. **It existed before.** A path invented during the incident is not a path. Establishing one usually requires the very right you have just lost. 2. **It does not depend on the thing that broke.** If it needs the applier, the declared source, or the rule set to work, it is not outside the system. 3. **More than one person can use it, and no one person can use it alone unnoticed.** Otherwise it is a single point of failure in one direction and an unattributable super-power in the other. 4. **It has been exercised.** An escape that has never been opened is a belief. Exercising it on a schedule is what converts it into a capability, and it is also how you discover that the credential expired, the holder left, or nobody knows where it is. ## Why this is asked It is a compact test of whether someone has actually operated a rule-change path rather than read about one. The candidate who says "the apply would fail and protect me" has not; the one who says "the apply works, and the next one doesn't, so the first thing I want to know is what we arranged in advance and when we last tried it" has.