Archive is retrievable recovery, not deletion

What it is

Archive takes content off the daily surface to reduce noise, while the object remains: searchable (when archive is included), openable, restorable to active. Delete removes the object; even with a trash, the end state is gone. If archive is deletion under another name—unsearchable, unopenable, gone in a few days—people refuse it and the active list swells forever. Soft delete and trash are a destruction path. Archive is dormancy in the lifecycle, not a prelude to destruction, unless the product joins the two and says so.

Why it happens

The active list is valuable as “in use.” Leaving unused-but-maybe-needed objects there drowns what is in use. Archive is a third path: not in front of you, not dead. If the archive cannot be searched, dormancy is disappearance, and people keep the object active or copy it elsewhere. If open-after-archive is read-only with no restore, archive reads as a one-way door and people will not walk it. Sharing one button with delete, distinguished only by a second confirm, turns a mis-tap of dormancy into destruction. Default search excluding archive is reasonable (old drafts should not pollute daily search), but Include archived must exist, or “searchable” lives only in a help article.

Studying it

Give a batch that is no longer daily but might still be asked for. Compare delete-only, archive that cannot be searched, archive that can be searched and restored.

Independent variables: searchable after archive, openable, whether restore is explicit, whether the delete entry is separate. Dependent variables: choosing archive over delete, retrieval success after archive, treating archive as delete.

A lab that says “you can still get it back from archive” measures compliance. The capability should be read off the UI. Do not count trash items as archive success.

Where it stops holding

Records that law requires destroying at a date will leave archive into delete; that stretch is retention and must be written as such, not only called archive. If personal trash already does “hide it first,” the product can skip archive, but should not run both with identical behavior. Encrypted objects still need a key that opens after archive, or restore is fake. A read-only audit library may forbid restoring to writable and should still allow search and open.

Applying it

• Split archive and delete. Archive copy: “taken off the main list; still searchable and restorable.”
• Search offers Include archived; the archive itself has a list and open.
• Restore brings the object back to the active stage, not only a downloaded copy.
• Verify: after archiving, main search without the include may omit it; with the include, or inside the archive, it opens and restores. Delete still lives elsewhere, and does not destroy an archived item with no extra prompt.

Related

• Within the group: H8.14.1 Lifecycle stages from create to archive need explicit names · H8.14.3 Auto-archive rules must be announced before items vanish · H8.14.4 Inactive cleanup balances storage cost against later retrieval
• Adjacent: H3.08 Soft Delete and Trash · H8.13 Content Search and Location · H8.05 Save for Later
• Search terms: archive versus delete · restore from archive · dormant content