The only proof your encryption-at-rest gate passed is a file in the gated team's own repo. What does it prove?

## Custody is the question, not content When a record is offered as proof that a control operated, the first question is not what it says but **who could have written it, and who could have changed or removed it**. A policy result sitting in the repository of the team the policy constrains fails that question on every axis. The party being measured is the sole author, sole editor and sole custodian of the measurement. That is not an accusation of dishonesty. Ordinary, well-intentioned engineering produces the same weakness: - Someone runs the check locally to debug it and commits the output, so the file records a laptop run against whatever rules were checked out at the time. - The pipeline writes results only on success, because the failure path errors out before the write, so the store contains a tidy history of green. - A results directory gets cleaned up during a repository reorganisation and nobody notices which decisions vanished. - A rule set is pointed at a local override during an urgent fix, and the resulting pass looks like every other pass. Any one of these is enough to make the store uninformative, and none of them leaves a trace inside the store itself. ## The indeterminate outcome Gate outcomes are usually taught as three: allow, deny, or deny-then-override. Reconstruction adds a fourth, and it is the one that actually shows up: **indeterminate** — the available evidence cannot distinguish a passing evaluation from an evaluation that never happened. A self-controlled store manufactures indeterminacy in both directions. A present record could be a real decision or an artifact of any of the situations above. An absent record could mean the gate never ran, or that a record existed and was deleted, or that the writing step failed silently. Because the same party controls both possibilities, neither presence nor absence moves you. This is why the honest answer to the post-incident question — *did the encryption-at-rest rule run on the commit that created this datastore?* — is often "we cannot tell". Saying that plainly is a stronger professional position than manufacturing a confident story from a green build, because it names a concrete, fixable capability gap rather than a guess about the past. ## What makes a decision record load-bearing Three properties, roughly in order of how much they buy you: **1. Written by the enforcement point.** The decision should be emitted by the thing that could actually have blocked the change — the admission point, the pipeline stage the merge or deploy genuinely depends on — not by a step that runs alongside it. A record from a developer's local run is useful feedback and useless evidence: it proves someone evaluated something on a laptop, not that the change that reached production had to pass anything. **2. Stored where the gated party cannot write.** Separation of duties, applied to records rather than actions. The team should be able to read their decisions freely; they should not be able to add, alter or remove them. In practice that means a store owned by a different party — the platform or security function — with the gated team's pipeline holding, at most, append credentials that its own members cannot use to rewrite history. **3. An independent expectation of what should exist.** Presence alone is not enough, because absence is the interesting case. Something outside the gated repository must be able to enumerate the changes that ought to have decisions behind them — merges to a protected branch, deployments to production — and reconcile that list against the decisions actually recorded. Once a missing decision is a finding, a silently disabled gate has a lifetime measured in days rather than quarters. With those three, the questions a reader wants to ask become answerable: did the gate run on this commit; what did it decide; and are there changes where it did not run at all. ## What you can still say when it is missing When an incident review lands on a commit with only a self-stored green file, the useful output is a clear statement and a remediation, not a verdict: - **Statement:** the gate's behaviour on this change is indeterminate; the record is self-reported and its absence would be equally unobservable, so the gate can be neither credited nor blamed here. - **Scope:** the same limitation applies to every change gated the same way, so this is not a one-commit problem, and the number of affected changes is itself unknown. - **Remediation:** move the decision emission to the enforcement point, move the store out of the gated team's write path, and add reconciliation so that a change with no decision is visible. Notice what the remediation is not. It is not tightening the rule, and it is not adding more checks. The rule may have been perfect; the failure being fixed is that nobody can tell whether it ran. Distinguishing a policy problem from an evidence problem is most of the judgment this question is testing. ## The counter-argument worth taking seriously Teams will say their pipeline is defined in code and reviewed, so the results can be trusted. That is a genuine improvement and still not a record: a reviewed definition shows intent at review time, not what executed on a given commit, and the same team can change the definition, supply different inputs, or commit results selectively afterwards. Review of the process is evidence about the process. A decision record is evidence about the decision, and only the second one answers questions about a specific change.