Retention policy must be stated

What it is

History is not infinite. Products drop old snapshots by time, count, or plan. Stating the retention policy means people know, before they lean on history, how far back a snapshot still opens, and which acts delete snapshots early (clear history, downgrade, moving a file out of a team). This is how long the past can be counted on. Browse-and-compare and undoable restore both assume the snapshot is still there; an unstated policy lets those fail silently one day. Compacting a long list into a readable summary is a different mechanism—the objects may still exist.

Why it happens

People treat history as insurance. With no exclusions written, they plan as if it lasts forever: edit boldly, check days later, restore instead of keeping their own copy. When a backend trims at 30 days or 100 rows, the policy expires without them. Discovery is late—something breaks, they open history, the list stops at a date. Stating it turns the recoverable window into the same kind of expectation as a trash retention period: finish the check inside the window, or export. Plan differences that live only on a pricing page are invisible to the person editing, which is the same as unstated. Auto-cleanup during a trip should not be discovered as “last week’s draft is gone” on return.

Studying it

Have people use a versioned document and depend on one restore, then delete older snapshots under the policy without prior warning. Observe when and how they notice, and whether save habits change. Compare policy written at the top of the history pane, only in a help article, and nowhere.

Independent variables: whether day or count limits are visible at the history entry, notice before cleanup, whether a plan change restates the new window. Dependent variables: attempts to restore what is gone, delay until the gap is noticed, later exports or external backups.

A lab cannot wait 30 days; a compressed clock (“the system will drop versions older than 7 days,” then do it) tests expectation, but is not a calendar. Do not count “the list is too long to read” as a retention failure—that is compaction, and the objects are still there.

Where it stops holding

Regulated work may require a longer keep than the product prefers; the stated window is the legal one. A local file with no cloud history has the policy “this copy is all there is,” which must be said when history is absent, not implied as cloud insurance. User-deleted versions and system expiry should be written separately, or people will think they cannot delete a row. In an encrypted space the server cannot see plaintext and may still drop wrapped snapshots by time; the copy must not imply support can retrieve the words.

Applying it

• Write the rule at the top of the history pane: “versions from the last 30 days can be opened; older ones are removed” or “the most recent 100 versions.”
• Notify once before cleanup, without blocking editing. When a downgrade shortens the window, restate the rule before it takes effect and offer export.
• Mark the policy edge at the end of the list (“older versions were removed under the retention rule”), not a missing number that looks like a load failure.
• Verify: ask someone in the middle of editing whether last Tuesday’s version still opens. If they cannot name the window, or the list ends with no explanation, the policy was not stated. Run a cleanup and see whether anyone looks for a snapshot they were never told would vanish.

Related

• Within the group: H8.06.1 History must be browsable and comparable · H8.06.2 Restoring an old version must itself be undoable
• Adjacent: H8.11 Version History and Rollback · H8.14 Content Lifecycle and Archiving · H3.08 Soft Delete and Trash
• Search terms: version retention · history policy · snapshot expiry