An auditor asks which ruleset was live for each of last quarter's sweeps — what do you show?

## What the auditor is really asking When someone asks which ruleset was live, they are testing whether your description of the control matches the thing that executed. Everything downstream depends on it: a beautifully written control description is worth nothing if the enforcer was running something else. Answering well means producing a chain that someone who does not trust you can follow. ## The two-sided binding **Forward — every result names its ruleset.** Each sweep record carries the digest of the ruleset that was loaded for that run. Not a version string somebody typed, not the git branch it was supposed to come from: a digest over the content the enforcer actually held. A version label is an intention; a digest is an observation. **Backward — every digest resolves to content.** An archive of published rulesets, addressed by digest and written append-only, so any digest in any record can be exchanged for the exact rule text months later. Without this half, the digests in your records are opaque strings. You can prove the ruleset did not change between March and May, and still be unable to say what it contained. The two halves fail independently, and organisations routinely have one without the other. ## The publish log makes the sequence legible Digests alone give you a set of points. The publish log — who published, when, resulting in which digest — turns them into a story with no gaps: every digest that appears in a sweep record traces to a publish event, and every publish event traces to a reviewed change. Two things should draw attention immediately. A digest that appears in run records with no corresponding publish event means something reached the enforcer outside the pipeline. A publish event whose digest never appears in any run means what you shipped is not what is running. ## Why the rule repository's history is not the answer Candidates reach for the source repository first, and it is the wrong artifact. Repository history is evidence about the *source*: what was proposed, reviewed and merged. What the enforcer loaded came from the *distribution point*. Between the two sits a publishing step, and that step is precisely where they can diverge — a build that packaged a stale working tree, a job that published from the wrong branch, a hand-placed object, a compromised credential. Offering commit history is asserting that source and served content matched, when the whole question is whether they did. Digests recorded at both ends turn that assertion into a comparison. ## The failure modes that make this unanswerable - **Mutable names.** The distribution point serves one object under a name like `current` and each publish overwrites it. You may still have digests in your records, but the content behind the old ones no longer exists anywhere. - **Results without identity.** Sweep output stored findings and timestamps but never the ruleset. Now you are reconstructing from deployment history and hoping. - **Retention shorter than the audit period.** Run records aged out after thirty days while the question covers ninety. - **Digests over the wrong thing.** A digest computed over the archive you built rather than the content the enforcer loaded — it proves what you published, not what ran. ## What to do when you do not have it Say so, precisely, and bound the claim: name the period you can attest to, describe what is missing and why, and state the change you are making so the next quarter is answerable. Auditors deal with imperfect evidence constantly; the thing that damages you is an overstated claim that unravels under one follow-up question. If a gap appears in the sequence — a digest with no publish record — investigate it as an unexplained change to a control and report the outcome, rather than leaving it as a blank in the table. ## What this evidence does and does not support It supports one specific sentence: *for each sweep in the period, the ruleset loaded was this one, and here is its text*. It does not establish that the rules were correct, that they covered every control you claim, or that the enumeration reached the whole estate. Those are separate claims needing separate evidence, and volunteering that boundary yourself reads as competence rather than weakness.