Policy Versioning

After this lesson, the reader should understand:

• 01Bind a decision to the artifact version in force at the time.
• 02Distinguish issuance date from effective date.
• 03Handle retrospective amendment correctly.

The retrospective amendment

A rule is amended with effect from a past date. What happens to decisions already made?

With versioned artifacts the question is answerable: identify every decision bound to the superseded version whose facts fall inside the amended window^[1], re-execute against the new version, and report the delta. Without versioning, the institution can only estimate. Retrospectivity is a policy choice; the ability to compute its consequences is an engineering property. The NOMOS reference implementation gives each policy a canonical record with an ordered history of immutable, sealed version snapshots and a fixed lifecycle — draft, in review, approved, active, deprecated, archived. Activating a version auto-deprecates the previous active one and repoints the marker that says which version is in force; a deprecated version stays valid for verifying the decisions made under it, and is distinct from a version that has been revoked. Every transition is written to an append-only log. Because a decision record cites the exact version hash it bound to, replaying a superseded version against its original inputs is a lookup and a re-execution, not a reconstruction. The strongest objection is that making retrospective change easy to compute makes it easy to do, and retrospective rules are among the oldest objections to arbitrary power. Legal philosophy lists non-retroactivity among the conditions without which a system of rules fails to be law at all^[2]: people cannot be guided by a rule that did not exist when they acted. The objection is right about the danger and wrong about the cause. Computing the consequences of an amendment does not decide whether to apply it; it lets the decision be made knowing who would be affected — the forty refunds owed, the three approvals that would now fail. An institution that cannot compute the consequences will still amend retrospectively when it chooses to; it will simply do so blind. Where retrospectivity favours the people affected, as a corrected entitlement often does, the computation is what makes the remedy possible. The limit is less obvious. Replay needs the old runtime semantics as well as the old artifact. If the evaluator's behaviour has changed since — a fix to how a boundary value is compared, a change in how two matching rules are resolved — then re-running a 2024 artifact on a 2026 evaluator may not reproduce the 2024 decision, even with identical facts. Versioning the artifact is necessary; versioning, or freezing, the semantics of the thing that executes it is the other half. This is why legislative databases publish law as it stood on a given date rather than only its current consolidated text^[3], and why the same discipline has to reach the runtime.

• Should artifacts ever be amended in place?
• How long must superseded versions remain executable?
• Who decides that a change is material?
• If a retrospective amendment can be computed in minutes, does that make it more or less legitimate to apply?
• When the evaluator itself changes, which decisions need to be replayed — and against which version of the evaluator?

No responses yet. Be the first to answer one of the questions above.

Design a version scheme for one instrument.

1. 01Define what constitutes a material change.
2. 02Define the identity and numbering rule.
3. 03Define the retention period for superseded versions.
4. 04Describe the replay procedure.
5. 05State how you would pin the evaluator's behaviour so a replay in five years reproduces today's decision.