Transfer from temporary capture to canonical source within 24 hours — longer delays turn temporary locations into de facto second sources of truth

Why This Is a Rule

Capture points (notebooks, voice memos, quick-capture apps, email drafts, sticky notes) are designed for speed, not permanence. Their value is in lowering the friction of capturing an idea in the moment — When two tools hold the same data, designate one canonical source of truth — demote the other to capture-point or read-replica to prevent sync drift designates them as temporary holding areas, not authoritative sources. But when captured information sits in a temporary location for more than 24 hours, a subtle shift occurs: you start consulting the temporary location directly ("Let me check my notebook"), treating it as a reference rather than a staging area. It becomes a de facto second source of truth that When two tools hold the same data, designate one canonical source of truth — demote the other to capture-point or read-replica to prevent sync drift was designed to prevent.

The 24-hour transfer window prevents this drift by establishing a clear expiration on temporary storage. Information captured today must be transferred to its canonical home by tomorrow. This maintains the capture point's role as a staging area (information passes through, never stays) rather than allowing it to evolve into a permanent reference that fragments your information architecture.

The 24-hour window also preserves context: the notes you took in a meeting today make sense tomorrow. A week later, the abbreviations, references, and context-dependent notes become cryptic. Transfer while the context is fresh ensures accurate canonical entries.

When This Fires

• After any capture event (meeting notes, voice memos, quick-capture app entries, paper notes)
• During daily processing sessions (Four nested processing cadences: daily triage (20-30 min), weekly review (drift), monthly audit (source quality), quarterly purge (sediment)'s daily triage)
• When capture locations start accumulating un-transferred items
• Complements When two tools hold the same data, designate one canonical source of truth — demote the other to capture-point or read-replica to prevent sync drift (canonical designation) and Two-minute archiving ritual after every delivery: file to archive with metadata immediately — archiving is closure, not a deferred task (archiving workflow) with the transfer timing

Common Failure Mode

The accumulating notebook: capturing notes in a physical notebook with the intention of transferring "later." Later never comes. The notebook fills with 3 months of un-transferred notes, becomes a de facto reference system, and now you have two sources of truth — the notebook and the canonical system — with no way to know which is more current.

The Protocol

(1) After any capture event, the captured material has a 24-hour transfer deadline. (2) During your daily processing session, include "transfer captured items" as a standard step. (3) For each captured item: transfer to the canonical system (When two tools hold the same data, designate one canonical source of truth — demote the other to capture-point or read-replica to prevent sync drift), process as appropriate (Route actionable items to your task system and reference items to your reference system — never store both in the same location routing: action → task system, reference → reference system), and discard the temporary capture. (4) If transfer isn't possible within 24 hours (travel, illness), mark the capture point with the date and transfer at the first opportunity. (5) Audit: if your capture locations (notebook, app, etc.) contain items more than 48 hours old, the transfer habit has broken. Reset by doing a bulk transfer, then reinforce the 24-hour habit.