When keeping a copy is the wrong choice

If the purpose of a task is to erase information, making another copy can defeat it. “Archive first, delete second” is useful advice for protecting work from an accidental destructive change. The decision about whether to retain the information comes first.

For anyone managing project files or entrusted data, these are separate decisions: whether the information should be kept, and how to protect it while it is needed.

A backup you can use

Imagine a designer replacing an old project directory with a reorganized one. The old directory contains source files, exported images and notes about a decision that is still relevant. Keeping that material is permitted and serves the continuing project.

Before removing the old working copy, the designer checks the backup. Can the source files be opened? Are the linked assets included? Does the copy contain the latest revisions? A folder with the expected name is insufficient if it holds only the exported images and omits the editable work.

Once the permitted recovery copy has been verified, the obsolete working directory can go. The archive should have an owner, suitable access restrictions and a decision about how long it is needed.

The bad version of this story starts with a cleanup tool reading “project finished” in a summary and deleting the only copy of a later revision. An old status label has become permission for a destructive action. The archive-first habit is meant to interrupt precisely that sequence: check what would be lost and establish that it can be recovered before removing it.

When the copy is the problem

Take a different hypothetical task. A team received an export containing private information it was never meant to receive. The authorized response is to remove that information from the team’s systems. Placing the export in an ordinary archive before deleting the working copy spreads the information to another location. The task remains undone.

Here the recommended action changes. Follow the deletion requirements, including how retained copies are handled. Don’t create an extra archive because a general housekeeping rule says to. If there is a conflicting preservation obligation, establish what applies before acting; the word “archive” doesn’t resolve the conflict.

Keeping everything indefinitely also makes later deletion harder to reason about. A copy can outlive the purpose for which it was made. A restore can bring back data that a later decision removed. A recovery plan therefore needs to account for deletions as well as additions: after restoring an older copy, how will the team avoid reintroducing information that should no longer be there?

Evidence of a deletion can be retained separately when appropriate. A record of the authorized action and its verification needn’t reproduce the private content being erased. Even that record should contain only the information needed for its purpose.

Proposed wording

The qualification belongs in the principle itself:

Make destructive changes recoverable when retention is appropriate. Do not preserve information that must be erased.

This is a proposed revision, not a change to the signed manifesto.

Before removing a working copy

Decide what the task is meant to accomplish. Reorganizing a project usually calls for preserving useful work. Removing information that must not be retained calls for a different process. Establish the applicable requirements before choosing between them.

When a recovery copy is appropriate, verify that it can restore the material you intend to protect. Then remove the exact obsolete copy you have identified. When erasure is required, verify the deletion against its actual scope. A successful command, on its own, doesn’t establish that every relevant copy was covered.