A record says your audit-log retention rule passed six months ago. What must it capture to still mean anything?

## A pass is a claim about a pair Every gate decision is a statement of the form: *this input, judged by these rules, produced this outcome*. A record that keeps only the outcome has thrown away two thirds of the statement. Six months later, the person reading it — an auditor, or an engineer working backwards from an incident — has to answer a specific question, and the record either supports the answer or it does not. ### 1. Which rules were in force Rule sets are living code. Thresholds get raised, selectors get widened, a rule that used to warn starts to block, an exception baked into the rule expires. Take a minimum-retention rule on an audit log. Last year it required thirty days; this quarter it requires ninety. A stored `pass` from February is a true statement about the thirty-day rule and says nothing whatsoever about the ninety-day one. If you present old passes as evidence for the current control, you are backdating a guarantee that was never evaluated. So the record needs an identifier for the rule set as a whole — a version, a revision, a bundle identity — and that identifier has to be resolvable to the rule text later. This is why rule sets belong in version control with an immutable identity per release, and why a gate that pulls the latest rules from a mutable location makes its own history uninterpretable: it can tell you a decision was made, but not what the decision was made against. ### 2. What the engine actually saw The commit is not the input. Engines almost always evaluate something *derived* from the commit: a rendered manifest, an execution plan, a resolved configuration with variables and upstream state folded in. The same commit can render differently depending on tool version, input variables, and the state of things it references. Recording the commit alone leaves you unable to say which datastore definition was judged, or whether the resource in question was even present in the evaluated input. This matters most for the resources that are *missing* from an evaluation. If a plan-time evaluation covered eleven resources and the datastore was created by a twelfth path the gate never saw, the record still says pass, truthfully, about eleven other things. Only an identifier for the evaluated input — and ideally the list of resources it contained — makes that visible. ### 3. An explicit decision, not an empty list Most engines report violations. When they report nothing, two very different situations produce the same output: - the resource was in scope, the rule was evaluated against it, and it complied; and - no rule in the set selected that resource at all, so nothing was ever evaluated. That second case is the policy author's classic blind spot. A rule that does not match produces no result rather than an approval; nothing rejected the change, but nothing endorsed it either. If a record only stores an empty violation list, it cannot separate *checked and clean* from *never in scope*. Recording which rules were evaluated against which resources — even as counts — separates them, and it is the difference between a record that can answer a coverage question and one that cannot. ## Putting it together A record that carries these three things supports a real claim: *at this time, the rule set at revision R was evaluated against this input, rule X applied to this datastore, and the outcome was allow.* A record that carries only `{commit, pass}` supports the much weaker claim that a pipeline once emitted the word pass. There is a governance consequence too. Once the rule version is pinned in every decision, you can answer questions that are otherwise unanswerable: which changes were only ever judged by the old threshold, how long the estate ran under the looser rule, whether the tightening was applied retroactively to existing resources or only to new ones. Those are exactly the questions that follow a threshold change, and they are impossible if every historical record just says pass. ## The trap of confusing this with a re-run None of this is the same as being able to reproduce the decision. Reproducing means re-executing the old rules on the old input, which needs both preserved and needs the engine's behaviour to be stable. Pinning identities is weaker and much cheaper: it lets you *interpret* the record — to know what claim it makes — even when you cannot re-execute anything. Most of the time, interpretation is what is actually being asked for.