How does a policy enforcer establish that it loaded the intended ruleset and not a substituted one?

## Two claims, often conflated A decision point that fetches its rules from somewhere is making two different assertions when it starts evaluating, and interviews reward candidates who separate them. **Integrity**: what I loaded is exactly what was published, byte for byte, and it came from a party I am willing to take rules from. This is what a digest and a publisher signature give you. **Identity**: what I loaded is the *particular* ruleset I was supposed to be running — not an older one, not a valid-but-different one someone else published. A signature alone does not give you this: a correctly signed ruleset from an authorised publisher can still be the wrong ruleset, or an authorised publisher's credential in the wrong hands. ## Digest the set, not the files Compute the digest over the complete ruleset as a unit — all rule text, any data it depends on, and its metadata — rather than verifying each file independently. The reason is deletion. Per-file verification proves that the files present are intact; it says nothing about the file that is no longer there. Removing the encryption-at-rest rule is the cheapest way to disable it, and it leaves every remaining file verifying perfectly. A single digest over the whole set changes the moment a rule disappears, so *the rule is gone* becomes as detectable as *the rule was edited*. ## Where the expected value comes from This is the part candidates most often get wrong. Verification is only as good as the independence of the expected value. If the enforcer fetches the ruleset and its expected digest from the same location, using the same credential, an attacker with write access to that location controls both sides of the comparison and the check becomes decoration. The expected value should ride in on the enforcer's own configuration path — its deployment manifest, its configuration management, something governed by a different credential and a different review than the rule distribution point. You then have two write paths that both must be compromised rather than one. Where a pinned digest is impractical, the weaker but still useful form is an expected *publisher identity*: the enforcer refuses content not vouched for by that identity, which narrows the attack from `anyone who can write to the store` to `whoever holds the publishing credential`. ## What to do on a mismatch An integrity or identity failure means the enforcer does not know what rules it has. The one outcome that must never happen is reporting the run as a pass. For a periodic detective sweep, that means marking the run failed and alerting, not emitting `0 violations`. Whether the engine additionally keeps serving the last ruleset it verified, refuses to serve decisions at all, or exits is engine-specific behaviour and a separate design question; the invariant here is that an unverifiable ruleset never produces green output. The same logic applies to a fetch that fails entirely. `Could not verify` and `could not download` are both `no assurance`, and neither is `allow`. ## Record what you loaded Verification before the run is half the value. The other half is emitting the digest with every result the enforcer produces, so that later — during an incident, or when someone asks what was enforced last Tuesday — the question is answered by a recorded fact instead of an inference from deployment history. This turns a one-time check into a durable, comparable trail, and it is what makes out-of-band reconciliation possible at all. ## The limits of a matching digest A digest match proves you loaded exactly what you asked for. It proves nothing about whether those rules are correct, whether they cover the controls you claim to enforce, or whether the expected value you pinned was ever the right one. A verified digest of an empty ruleset verifies flawlessly. Integrity and correctness are independent problems, and conflating them — `it verified, so we are covered` — is the reasoning error this whole area exists to prevent.