Haha. Indeed.

Another take: if we don't hung up on the surface-level form of rules and rule-following, but instead consider in terms of I am trying to engineer this system to behave in the way that I want then we get a more actionable sense of what rules means: if I apply feedback of type x on schedule a, I get one result; y on b leads to another. Rules are simply a way to encode this.

Framed this way, it's a matter not of blind adherence to rule-following, but more-optimal engineering or design. Appropriate rules produce the results you want. The letter and the spirit are one, if the domain is tight.