Scale versioning to stakes: full (named versions + changelogs) for high-stakes, date-stamped for medium, none for low — match overhead to value
For high-stakes outputs with long lifecycles, implement full versioning with named versions, changelogs, and archived copies; for medium-stakes outputs, use lightweight date-stamped versioning; for low-stakes outputs, skip active versioning entirely to match overhead to value.
Why This Is a Rule
Version control has real costs: maintaining changelogs, archiving copies, naming conventions, storage management. These costs are justified for a policy document that will be updated over years by multiple people — the cost of NOT versioning (confusion about which version is current, inability to roll back bad changes, lost audit trail) far exceeds the maintenance overhead. But the same costs are wasteful for a one-time internal email that will never be updated.
The three-tier system matches versioning rigor to output value: Full versioning (high-stakes, long lifecycle): named versions (v1.0, v1.1, v2.0), detailed changelogs documenting what changed and why, archived copies of each version. This is git-level rigor for outputs that justify it: policies, contracts, published guides, product specifications. Date-stamped versioning (medium-stakes, moderate lifecycle): filename includes date (Report-2026-03-30), new versions save alongside old ones without formal changelogs. Simple, low-overhead, sufficient for reports, plans, and documentation that gets updated occasionally. No active versioning (low-stakes, short lifecycle): emails, messages, meeting notes. These are produced, delivered, and either consumed or archived. No version tracking needed because they're never updated.
When This Fires
- When deciding how to handle version management for a new output type
- When version control overhead is consuming time disproportionate to the output's value
- When a critical output has no versioning and a bad update causes problems
- Complements Annotate each output type with its half-life (hours/weeks/months/years) — calibrate investment in durability and polish to actual lifespan (half-life annotation) by adding the versioning dimension to output type management
Common Failure Mode
Uniform versioning: either full versioning for everything (massively over-engineering low-stakes outputs) or no versioning for anything (losing the ability to track changes in critical documents). Both extremes waste resources — one through excessive overhead, the other through preventable disasters.
The Protocol
(1) Classify each output type by stakes and lifecycle: High (published, contractual, policy, multi-year lifespan) → full versioning. Medium (reports, plans, documentation, months lifespan) → date-stamped. Low (messages, notes, one-time deliverables, days lifespan) → none. (2) For full versioning: establish naming convention (v1.0, v1.1), maintain changelog ("v1.1: Updated pricing per Q2 review"), archive all previous versions in accessible storage. (3) For date-stamped: include date in filename or header, save new versions alongside old without overwriting. (4) For no versioning: produce, deliver, move on. Don't create overhead for ephemeral outputs. (5) If uncertain about the tier, start with date-stamped — it's low-overhead and can be upgraded to full versioning if the output proves more important than expected.