Skip to main content
Shakewell

Field Guide

Publishing Documents That Change on a Date

Rules, rates, policies, procedures: documents that take effect on a date, expire on a date, and must answer for what they said on any date in between. Files can't do this. Systems can.

The Problem

Three Tenses, One Document

A regulated document lives in three tenses at once. The current version binds everyone today. A future version is already finished — approved, typeset, waiting for its commencement date, and in some regimes legally forbidden from public view until then. And the past versions can never really leave, because audits, disputes, and compliance histories all hinge on what was in force when. A single procedure can easily have eight or nine versions that must all remain reachable, each with its exact period on record.

Managed as files, this becomes the folder everyone recognizes: near-identical PDFs distinguished by filename conventions, a calendar reminder to swap them at midnight, and no trustworthy answer to “what did clause 12 say last March?” The failure isn't carelessness — it's that files have no concept of time, and this content is made of time.

The Mechanism

Versions With Clocks Attached

Long-lived systems under continuous revision
Every version carries its period in force — so 'what applied on March 3rd' is a lookup, not an archaeology project.

Effective-dated publishing gives every version two timestamps: the date it takes effect and, once superseded, the date it ended. The delivery platform serves whichever version the calendar says is current; the reader can step backward through the timeline; and the future version sits complete inside the system, invisible to the public until its start date arrives — at which point the handover happens automatically, to the day, with the audit trail recording all of it. We've run exactly this machinery for a national rules body for years: versions prepared and numbered in the structured authoring system, pre-staged with their dates, released by the clock rather than by a person at midnight.

The prerequisite is treating versions as managed things rather than files — which is the same foundation that gives you branching (the future version is a branch with a commencement date) and a delivery platform that can answer for any point in time, to humans and to the machine consumers who increasingly ask. If your organization publishes anything that commences, expires, or supersedes, this is the difference between managing time and hoping about it.

FAQ

Questions We Hear

What is effective-dated publishing?

Publishing where every version of a document carries the dates it is in force — a start date and, once superseded, an end date — and the system serves the right version for any point in time. Readers land on what is current today; the version taking effect next month is finished, approved, and waiting on its date; the eight prior versions remain available with their exact periods on record. One document, one place, its whole timeline intact.

How do you prepare a future version without publishing it early?

This is the case that breaks file-based workflows, because some publishers are legally barred from showing future rules ahead of their commencement. The mechanism: the future version is completed and versioned inside the system, gated by its start date. Until that date the public sees only the current version; on the date, the current one gains its end date and the new one goes live — automatically, at midnight, with no human pushing a button and no early leak possible.

Why keep superseded versions online at all?

Because someone acted under them. Compliance decisions, contracts, and audits all turn on what the rule said on a given date — not what it says now. A library that overwrites old versions can't answer 'what was in force on March 3rd,' and organizations that manage this with filenames end up with eight near-identical PDFs and no reliable answer. Time-travel through versions is the point, not a luxury.

Can this work with our existing website?

Yes — the pattern is a delivery platform that owns the documents and their dates, with the main website linking into it (typically on a subdomain). The CMS keeps doing pages; the platform does versions, dates, search, and the APIs that let other systems — including AI tools — ask for the version in force at any moment.

Get In Touch

Publishing on a Deadline?

If your documents commence, expire, and supersede — and your process is filenames and midnight calendar reminders — we've built the machinery that replaces it.