One resource-limits rule runs in a pre-commit hook, CI and admission — why do the three copies drift?

## One rule, three installations A policy rule sounds like a single object — "every container must declare CPU and memory requests and limits" — but nothing enforces a sentence. What enforces it is a copy of the rule, loaded into some process, at some version. If the same rule runs as a pre-commit hook, as a pipeline check, and again on the cluster's admission path, you are operating **three installations of one versioned artifact**, not one rule in three places. ## How each copy gets its version The mechanisms are genuinely different, which is why they drift: - **The pre-commit hook** lives on a developer's machine. Its version is whatever was fetched the last time that developer installed or refreshed hooks — which may have been at onboarding, a year ago. - **The CI check** resolves the library when the job starts, from a version named in a file in the repository. If that file pins `2.1.0`, the job uses `2.1.0` until someone edits the file. If it names a floating range, the job silently changes behaviour whenever the library is published to. - **The admission-time ruleset** is loaded by a component the platform team deploys or refreshes. It changes when that deployment or refresh happens, not when the library is published. Publishing is not installing. That single fact is the whole answer at this level. ## What drift looks like concretely Suppose the container-resources rule at v1.9 required only that `requests` be set, and v2.0 extended it to require `limits` as well. A manifest with requests and no limits is *correct* under v1.9 and *rejected* under v2.3. A developer whose hook is pinned at v1.9 gets a green local run and a red CI job on the same file, with no change to the file in between. Nothing is broken; two different versions of one rule disagreed, exactly as they were written to. A related but separate concern is that the three enforcers may not even be handed the same document — a hook sees source, a later gate may see rendered output. That belongs to a different discussion. Here, assume all three see the identical manifest: version drift alone is enough to make them disagree. ## The direction of the lag is what matters Drift is not symmetric, and this is the point a candidate should reach even at a junior level: - A **local, advisory copy that lags** costs developer time. Work that the current rules reject gets caught later than it could have — annoying, never dangerous. - A **local copy that runs ahead** of the gate blocks work the gate would have allowed. Also annoying, also never dangerous. - An **enforcing gate that lags** is the one that matters. It admits changes that the current published ruleset would reject, so the organisation believes a control is in force at a strictness it is not actually applying. So the copies are not equal, and "keep everything in lockstep" is not the design goal. ## Making the drift visible You cannot manage a spread you cannot see. The cheap mechanism is to have every decision point record the rule library version alongside its verdict — in the CI job log, in the hook's output, in whatever the admission path emits — and collect those. That turns "our hooks are probably old" into a number: which consumers are behind, and by how many releases. A second, static source is the repositories themselves: the pinned version sits in a checked-in file, so an inventory across repositories tells you the CI side without waiting for a run. ## Bounding rather than eliminating With copies installed independently, some divergence window is permanent — you can shrink it, not close it. The workable target is a **bounded and measured** window: a stated maximum lag for advisory copies, automatic version bumps raised as pull requests so upgrades are routine rather than projects, and a hard rule that the authoritative gate is never the laggard. Teams that instead chase perfect lockstep end up either freezing the library or floating every consumer, and floating every consumer means one publish can turn every pipeline in the estate red at once, with no way to reproduce yesterday's verdict. ## The common wrong answer The weak answer is "one of the engines must be buggy". Two correct evaluators, given the same input and different rule versions, are supposed to disagree. The first diagnostic move is always to compare versions, not to suspect the tooling.