Declare information bankruptcy when backlog exceeds daily processing capacity — archive everything and reset rather than attempting incremental catch-up

Why This Is a Rule

When a queue's inflow exceeds its processing outflow, the backlog grows every cycle. If you process 50 emails per day but receive 55, you fall 5 behind daily — 25 behind after a week, 100 behind after a month. Incremental catch-up is mathematically impossible because today's processing can't exceed today's capacity, and tomorrow brings another 55 new items. The backlog only grows.

The only solution to a structurally growing backlog is discontinuous intervention: archive the entire backlog and start fresh with an empty queue. This is "information bankruptcy" — the acknowledgment that the accumulated debt cannot be repaid incrementally and must be written off. The archive preserves the items (if something was truly critical, it will resurface through follow-up or consequence), but the queue returns to zero, restoring the system's ability to function.

The 10% threshold is where incremental catch-up becomes mathematically infeasible within a reasonable timeframe. At 10% daily deficit, catching up requires dedicating an entire extra day just to reduce the backlog — and new items keep arriving during that extra day. The longer you wait to declare bankruptcy, the larger the archive-and-reset operation and the more guilt accumulates around the growing pile.

When This Fires

• When any information queue (email inbox, reading list, notes inbox, task list) is growing faster than you can process it
• When the inbox count has been increasing for 2+ weeks despite regular processing
• After vacations, illness, or other periods that created processing gaps
• Complements Process inboxes sequentially top-to-bottom, never cherry-picking — skipping difficult items creates a permanent maybe pile (sequential processing) by resetting the queue when sequential processing can't keep up

Common Failure Mode

Guilt-driven incremental attempts: spending entire weekends trying to process a 500-item backlog, getting through 200, feeling exhausted, and returning Monday to find 50 new items. By Friday, the backlog is back to 350. The incremental attempt consumed a weekend and produced zero net reduction. Bankruptcy would have taken 5 minutes and produced a clean slate.

The Protocol

(1) Measure your queue: how many items are in the backlog? How many new items arrive daily? How many can you process daily? (2) If daily inflow > daily processing capacity → bankruptcy is needed. The deficit will only grow. (3) Select all items in the backlog. Archive them in a dated folder: "Email Bankruptcy 2026-03-30." Do not review individual items (During triage, scan surface indicators only — opening and reading collapses sorting into reactive processing — scanning during reset defeats the purpose). (4) Start fresh with an empty queue. From this moment, process new items as they arrive at the daily rate. (5) If something from the archived backlog was genuinely important, it will resurface: someone will follow up, a deadline will trigger a reminder, or you'll remember and search the archive. The 95% that doesn't resurface was safely ignorable.