How can a policy engine get a fact, such as an approved-region list, that the change never carries?

## The problem A rule says instances may only be created with an approved type, in an approved region. The proposed plan supplies the type and the zone. It cannot supply the approved lists, because those are organisational facts, not properties of the change. So the fact has to reach the engine somehow, and there are exactly three shapes for that. Choosing between them is a policy-author decision with consequences that outlive the rule. ## Route 1: replicate the fact ahead of time The approved-types and approved-regions lists are maintained somewhere, and a copy is published to the engine, arriving with or alongside the rules that use it. - **Freshness**: as current as the last publish. If the list is republished nightly and someone adds a region at 10:00, changes evaluated before the next publish are judged against yesterday's list. - **Failure mode**: the engine keeps deciding even if the source system is down, because it is not consulted at decision time. The risk is not unavailability but silent drift, a copy that has stopped being refreshed while everyone assumes it is current. - **Reviewability**: the strongest of the three. The fact is a published artifact with an identity, so "which list decided?" has an answer, and changes to the list can go through review the same way rule changes do. - **Fits**: slow-moving facts of modest size. Allow-lists, ownership maps, environment classifications. ## Route 2: pass it in with the change Whatever assembles the request gathers the fact and puts it in the same document as the change, so the engine receives one self-contained input. - **Freshness**: exactly as fresh as the moment the caller collected it, which is usually seconds before the decision. - **Failure mode**: the caller's problem. If the fact cannot be collected, the caller decides whether to proceed, retry, or refuse, and it does so where a human can see it rather than deep inside rule evaluation. - **Reviewability**: good, because the fact that decided travels in the same document as the thing it decided about, so what the engine saw is a single object. - **Cost**: every caller now has to know which facts the rules need. Add a rule that needs a new fact and you are changing the caller too, which is a coupling worth being deliberate about. - **Fits**: facts specific to this request, and facts too large or too volatile to replicate wholesale. ## Route 3: look it up during evaluation The engine reaches out to another system while deciding. - **Freshness**: the best available. The answer reflects the source at the instant of the decision. - **Failure mode**: the worst. A gate that calls another system inherits that system's availability and latency on every decision, and "the approvals service is slow" becomes "deployments are blocked", or worse, "deployments are allowed", depending on how the enforcer handles an error. - **Reviewability**: the weakest. The verdict now depends on something outside the recorded input, so two runs over the identical change can legitimately disagree and nothing kept says why. - **Fits**: genuinely time-sensitive facts, such as a break-glass exemption that must take effect immediately, and even then it should be a narrow, bounded call rather than the general way facts arrive. ## Choosing Sort your facts by how fast they move and how badly a stale answer hurts. | Fact | Moves | Stale answer costs | Route | | --- | --- | --- | --- | | Approved regions | Rarely | A new region rejected for a few hours | Replicate | | Approved instance types | Occasionally | A new type rejected until republish | Replicate | | This request's requester and branch | Per request | Wrong decision entirely | Pass in | | An emergency exemption just granted | Minutes | The fix for a live incident stays blocked | Look up, narrowly | Two things fall out of the table. First, most facts a gate needs move slowly, so most facts should be replicated, and the instinct to reach for a live lookup is usually the expensive answer to a cheap problem. Second, the question is never "is stale data acceptable?" in the abstract. It is "how stale, and who notices?" Every route is stale by some amount, including the live lookup, which is stale by exactly the network round trip and by however long the source system took to learn the fact itself. ## Make the staleness visible Whichever route you pick, the fact set that decided should be identifiable in the outcome: which published revision of the approved-regions list, or which snapshot the caller collected. A denial reading "eu-south-2 is not in approved-regions revision 47" tells the blocked engineer that their region was added after revision 47 and that they need a republish, not an argument. The same denial without that identity tells them only that the robot said no, which is how gates acquire the reputation that eventually gets them switched off.