Scale versioning to stakes
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.
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… (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.