Version the policy, not just the code

Ask your team to produce the exact rules that governed a decision your system made three months ago — the eligibility criteria, the thresholds, the branching logic that turned inputs into an outcome — as they stood at that instant, not as they stand today. In most organizations this request cannot be satisfied. The code that ran is in version control, tagged and diffable and recoverable to the commit. The policy that actually governed the outcome is not. It lived in a config file edited in place, in a rules console with no history, in a spreadsheet a governance lead keeps current, in prompt text someone changed without a commit. The rule has been overwritten, and it left no version behind. Code has git; policy has amnesia. Fix the amnesia, because it is your amnesia — you own the rules, and you have been treating the most consequential artifact in the system as if it were furniture.

The premise worth making explicit is that the policy is not a description of the decision system — it is the decision system, in every respect that matters to the person affected by it. The model estimates; the code executes; but the rules decide who qualifies, what counts as enough, where the line falls. Those rules are the operating parameters, and the operating parameters are moral choices wearing technical clothes. You would never let a function that governs consequential outcomes ship without a commit, a review, and a way to recover exactly what ran. Yet the rule that governs the same outcome routinely ships as an in-place edit to a field in a console, and no one can later reconstruct what it said. The rigor you already apply to source belongs, unaltered, to the policy — and it belongs there more urgently, because the policy is the part a regulator, a court, or an affected party will actually ask about.

Code has git; policy has amnesia

Consider what in-place editing destroys. When a threshold lives as a mutable value that operators change directly, each change silently overwrites the last, and the system retains only the current state — never the sequence of states it passed through. The same is true of a rules interface that presents the live configuration with no history behind it: you can see what the rule is, never what it was. So when a decision from last spring is questioned, and you go to answer the first and most basic question — which rule governed this? — there is nothing to retrieve. The rule that governed it has been replaced by a rule that did not exist yet. You are left doing archaeology: reading change tickets, interviewing whoever remembers, inferring from adjacent decisions what the policy must have been. Archaeology is not evidence. It is a guess wearing a lab coat, and it is what you are reduced to whenever the governing rule was allowed to vanish on being changed.

This is not a small operational gap; it is the difference between a decision you can account for and one you can only apologize for. A record that carries the inputs and the outcome but cannot state the rule that connected them has recorded everything except the thing that did the governing. The whole point of a decision record is to make a past decision answerable now, without trusting anyone's memory of it — and that answerability collapses the moment the policy in force is unrecoverable. You cannot replay what you cannot reconstruct, and you cannot reconstruct a rule that was overwritten and left no version behind.

A rule you can edit without leaving a version behind is not a policy. It is a rumor with authority — binding on the people it governed, and gone by the time they think to ask what it was.

Give policy a version, stamp it into the decision

The directive has two halves, and neither works alone. First, give the policy a version identity. Every effective rule set — the complete set of rules, thresholds, and eligibility criteria in force together — gets an immutable, timestamped, attributable version, the way each release of your code gets a tag. It carries an effective-from moment and, once it is superseded, an effective-until moment, so that any instant in time maps unambiguously to exactly one governing version. Immutable is the load-bearing word. A version you can quietly amend after the fact is not a version; it is the same amnesia with a version number painted on it. Once a rule set has governed a single real decision, it is frozen; a change produces a new version, never an edit to the old one.

Second — and this is the half most teams skip even when they have the first — stamp the policy version into the decision record at the moment the decision is made. It is not enough to be able to reconstruct, by careful cross-referencing of timestamps, which version was probably live when a decision ran. Bind the version identifier into the record itself, so that the record carries its own governing rule set by reference and the question which rule governed this? is answered by reading the record, not by reconstructing the state of the world around it. A decision record that names its policy version has turned the hardest forensic question into a lookup. A decision record that omits it has left that question to archaeology, no matter how immaculate your version history is — because a version history nobody bound to the decisions is a library with no catalog card in any of the books.

Govern the change, not just the rule

Versioning the rule set answers what the policy was. It does not, by itself, answer whether the change to it was legitimate, and that second question is where a governance lead's ownership actually lives. Make policy changes reviewable and attributable the way you already make code changes reviewable and attributable. Every change to an effective rule set should record who changed the threshold, when, with what stated rationale, approved by whom. A policy change is a decision — usually a more consequential one than most of the code changes it sits beside — and a decision made without an author, a reason, and an approver on the record is a decision no one has agreed to defend. The review gate you would insist on for a schema migration is the least you should insist on for moving a line that reallocates who bears the cost of the system's errors.

Do this, and you separate two questions the record must never conflate. The first is did this decision follow the policy that was in force? — a question of conformance, answerable by replaying the pinned version against the recorded inputs. The second is was that policy the right one? — a question of judgment, answerable only by examining the rule set on its merits and the rationale behind the change that produced it. These are different questions with different remedies: the first exposes a decision that broke its own rules, the second exposes a rule that should never have governed. But you can ask either only if the policy in force is itself a recorded, pinnable fact — a version you can name, freeze, and hold up. When the governing rule is unrecoverable, both questions collapse into the same helpless shrug, and the shrug is the sound of a governance function that cannot account for the thing it exists to govern.

This is your work, precisely because the parameters are yours. The engineer versions the code because code is the engineer's material. The policy is your material — the thresholds and eligibility rules that are moral choices wearing technical clothes — and it deserves the same discipline from you that the engineer already gives the code. Give the policy a version, freeze it once it governs, stamp it into every decision it rules, and gate every change to it behind an author and a reason. Then, when someone asks which rule governed a decision last spring, the answer is a version identifier and a frozen rule set — not a shrug, and not a guess.

— Dispatches · Summit Cognitive