Archive only the final delivered version — drafts go in a separate subfolder labeled non-canonical, if preserved at all

Why This Is a Rule

Archives containing multiple versions of the same output create a retrieval hazard: which version is the one that was actually delivered? The draft with "final" in the name? The one with the latest date? The one in the root folder vs. the one in the subfolder? Version confusion in archives is insidious because you typically discover you used the wrong version only after you've already referenced it, sent it to someone, or based a decision on it.

The final-only rule eliminates version confusion by ensuring the archive contains exactly one version of each output: the version that was actually delivered. This version is the canonical reference — the definitive, authoritative copy. When you search the archive and find an output, you know without checking that it's the delivered version, not a draft, not a "final-but-not-really" version, not a revision that was superseded.

The exception clause (drafts in a separate subfolder, clearly labeled) handles regulatory or legal requirements that mandate draft preservation. The structural separation (subfolder) and labeling (non-canonical) prevent the confusion that mixing drafts and finals in the same folder creates.

When This Fires

• When deciding what to archive after delivering an output
• When your archive contains "Report-final.docx," "Report-final-v2.docx," and "Report-FINAL-FINAL.docx"
• When someone pulls the wrong version from the archive because multiple versions coexist
• Complements Two-minute archiving ritual after every delivery: file to archive with metadata immediately — archiving is closure, not a deferred task (archiving workflow) and Name archived files as [YYYY-MM] [Type] — [Descriptive Title] — enables chronological sort, category filter, and keyword search in the filename alone (naming convention) with the version-selection policy

Common Failure Mode

The draft hoard: archiving every draft, revision, and iteration alongside the final version. The archive for one report contains: outline, first draft, second draft, "final draft," "revised final," and "delivered version." Future retrieval is a guessing game among 6 files, and the "final" one may not be the one that was actually delivered.

The Protocol

(1) When archiving an output, archive only the version that was actually delivered to the recipient. (2) Delete or don't archive working drafts, intermediate revisions, and pre-delivery versions. They've served their purpose and are now clutter. (3) If legal, regulatory, or contractual obligations require draft preservation → create a subfolder within the archive entry: [Output]/drafts/. Store drafts there. (4) Label the subfolder contents clearly: "Draft 1 — pre-review," "Draft 2 — post-review." The main folder level should contain only the canonical final version. (5) When in doubt about whether to keep a draft: if deleting it would violate a legal obligation, keep it in the drafts subfolder. If the only reason to keep it is "I might want to reference it" — you won't. Delete it.