Your policy engine major and your rule library both need upgrading. Which moves first, and why?

## The question behind the question An interviewer asking this is not looking for `engine first` or `rules first`. They are checking whether you know that both orders create a period in which the guardrail is not doing what its owners believe it is doing, and whether you would surface that period or let it pass unmentioned. ## What each order costs **Engine first — new engine, old rules.** Everything the major removed or changed now applies to a rule library nobody has revalidated. The good outcome is a loud one: the rules fail to load and the enforcement point is obviously broken. The bad outcome is quiet: they load, they evaluate, and a subset of them now decides differently. You also inherit the enforcement point's behaviour when rules cannot load at all — which for a blocking gate can mean everything stops, and for a non-blocking one can mean nothing is checked. Neither is a state you want to meet unplanned. **Rules first — old engine, new rules.** Rules authored against the new major may use constructs the old engine does not have, so the library will not load and you are back to the same two bad states, only now you have broken a working system with a change that was supposed to be preparation. **Both at once.** Tempting, because it is one change and one window. It is the worst option, because when something decides differently you cannot attribute it: the engine and the rules moved together, and bisecting means unpicking two upgrades under time pressure. ## The sequence that usually wins Aim for a **simultaneously-valid pair** and move one variable at a time: 1. **Rewrite the rule library to the intersection** — the subset of constructs that both engine majors accept. This is a rule-only change, verified on the old engine, and it can ship on a normal schedule with no window at all. 2. **Bake it.** Let the intersection library run in production on the old engine long enough for the estate's real traffic to exercise it. Rule-side regressions surface here, cheaply, with the engine held constant. 3. **Upgrade the engine, rules unchanged.** Now any behaviour change is attributable to the engine alone, and rollback is a single, well-understood step. 4. **Adopt new-engine-only constructs afterwards**, as ordinary rule work. Step 1 does the hard part: it turns an unavoidable mismatch into a period where both sides are valid. When no such intersection exists — the major genuinely removed something with no equivalent — the fallback is to run both pairs concurrently: the old pair keeps enforcing while the new pair evaluates the same inputs and only records, and you cut over when their decisions agree over real traffic. That costs infrastructure and decision latency, so it is for the rules you cannot afford to have off, not for the whole library. Overlay the usual environment progression on whichever order you pick — non-prod, then one willing team's scope, then the estate — so the first evidence of a mismatch arrives somewhere cheap. ## Naming the window, which is the part people skip Every plan here has an interval where enforcement is degraded or absent. The principal-level behaviour is to state it in advance, in writing, with a start and an end: - **Say which rules are affected and how.** `For roughly two hours the deprecated-API deny-list is not evaluated on new workloads` is a sentence someone can make a decision about. `There may be brief disruption` is not. - **Decide: accept or compensate.** Compensations are cheap and unglamorous — freeze the change types the gate protects against, require a named approver for changes in that scope during the window, or keep the old pair enforcing in parallel. Accepting is also legitimate at 3am on a Sunday with a two-hour window; it just has to be a decision with an owner rather than a silence. - **Record it where the control's evidence lives.** Someone will eventually ask whether this control operated for the whole period. A known, bounded, approved gap that you wrote down is a manageable answer; an unrecorded gap discovered later is a much worse conversation, and a claim of continuous operation that the change log contradicts is the worst one. - **Tell the people who depend on it**, including the teams whose changes the gate normally catches — the ones most likely to ship exactly the thing it would have caught, not maliciously but because nothing stopped them. ## What you verify on the other side Before the window, replay the estate's objects through the new pair and diff decisions against the old pair. After it, watch the denial rate: a rule that fired weekly and now fires never is telling you the upgrade broke it. And keep at least one deliberately non-compliant input per rule flowing through the real enforcement path, so that if the new pair matches nothing you learn it from a failing check rather than from an audit.