R-03 · 5 min
The Policy Versioning Problem
Published Jul 31, 2026
Abstract
A decision is only defensible against the rule that was in force when it was made. Almost no institution can produce that rule on demand.
Learning objectives
- 01Explain why a decision must cite the version of the policy that governed it.
- 02Describe the difference between document revision and authority versioning.
- 03Design a retention rule for superseded authority artifacts.
Concept
Ask an institution what its policy was on a Tuesday eighteen months ago and you will usually get a current PDF, a changelog written by a person, and an apology. The policy exists; the state of the policy at a point in time does not.
Why documents cannot version
- Amendments arrive as prose describing edits to other prose, not as diffs against a structure.
- A single clause change can silently alter the meaning of clauses elsewhere with no dependency graph to consult.
- Effective dates, transition periods and grandfathering rules live in footnotes rather than in the model of the policy itself.
- Multiple valid versions frequently coexist for different populations, and documents have no way to express that.
What versioned authority requires
An authority artifact should be content-addressed and immutable: publishing a new version never mutates the old one. Every decision record cites the exact artifact identifier that produced it. Temporal validity is a first-class field, not commentary. And migration between versions is explicit — the artifact states which decisions carry forward and which must be re-evaluated.
artifact eu-ai-act@1.0.0 (the real one, live on the NOMOS Exchange) digest c86b56fd…e718fb in force 2026-07-28 → present supersedes none — first published version
The payoff is quiet but structural: an audit becomes a lookup instead of an investigation. This particular artifact has not needed a version 2 yet — when it does, the old one stays retrievable unchanged, and every decision made under 1.0.0 keeps citing exactly that.
Framework
Version binding
- 01Policy issued and versioned
- 02Artifact compiled and hashed
- 03Decision binds to artifact hash
- 04Policy amended, new version issued
- 05Historic decisions still resolve to the old artifact
Case study
The retrospective audit
Three years after a refusal, an appeal is filed. The current policy text has been amended twice. The institution can produce the current document and a changelog, but cannot reconstruct the exact rule set applied on the day.
With versioned artifacts, the decision record cites a hash. The artifact is retrieved, re-executed against the original inputs, and produces the same outcome — or reveals that it does not.
Exercise
Pick a policy that has been amended at least twice and reconstruct its history.
- 01List each version and its effective date.
- 02Identify which clauses changed behaviour rather than wording.
- 03Determine whether any live decision still depends on a superseded version.
Artifact
policy.version
id: procurement.threshold versions: 1.0.0 effective 2022-01-01 threshold: 50000 1.1.0 effective 2023-07-01 threshold: 75000 2.0.0 effective 2025-01-01 threshold: 75000, exemption added resolution: decision.date -> effective version
Further reading
From Regulation to Execution
Where versions are produced.
The Future of Governance Infrastructure
Registries and exchange.
Cite this
This is a field in formation; this page will be revised. Cite the version date below, not the day you happen to be reading this.
Suggested citation
SafeHaven (2026). The Policy Versioning Problem. Computable Authority Research Library, version of 2026-07-31. https://www.computableauthority.com/research/the-policy-versioning-problem
BibTeX
@misc{computableauthority-the-policy-versioning-problem,
author = {SafeHaven},
title = {The Policy Versioning Problem},
howpublished = {Computable Authority Research Library},
year = {2026},
note = {Version of 2026-07-31},
url = {https://www.computableauthority.com/research/the-policy-versioning-problem},
}Next entry
The Definitions Problem →