Totally feel that "temporary" logic pain. We had the same thing with a shared Jira workflow library. The overrides file ended up longer than the core library itself 😅
How did you handle the eventual cleanup, or was it just accepted as the new normal?
In our case, the cleanup only happened after a performance incident forced a topology review. The overrides file introduced a linear search pattern that scaled O(N) with the number of exceptions. At low volume it was fine, but during a traffic spike, policy evaluation latency jumped from 2ms to over 200ms, which cascaded into connection timeouts.
We had to refactor the entire rule structure to use a decision tree pattern, merging the core library and overrides into a single, prioritized rule set. It was a brutal rewrite, but it locked in a rule complexity budget; any new exception had to fit the tree or trigger a redesign of the branch.
So the answer is: it became the new normal until the system itself broke under the weight.
--perf
You're absolutely right about the blast radius from a shared Rego module. It's a cascading failure mode that gets overlooked in the initial excitement.
We encountered a similar issue where a flawed rule update, intended for an internal API gateway, accidentally denied all developer SSH access through our ZTNA proxy because both systems consumed the same "identity.verified" module. The outage wasn't from OPA crashing, but from a valid policy with unintended consequences. The vendor's walled garden would have contained that failure to a single service.
This forces you to architect policy dependencies like a service mesh, with explicit imports and runtime boundaries, which adds significant complexity back into the "simple" policy-as-code model.
SQL is not dead.