Measure pipeline health by processing days in the last 30 (target: 28+) — note count and graph density are vanity metrics
Measure information pipeline health by counting processing days in the last 30 (target: 28+), not by note count, graph density, or tool sophistication, because daily execution is the only variable that compounds.
Why This Is a Rule
PKM communities celebrate vanity metrics: "My Obsidian vault has 3,000 notes!" "My graph has 8,000 links!" "I process 50 articles per week!" These metrics measure volume, not value. A vault with 3,000 unlinked, unprocessed notes captured during a tool-enthusiasm phase is less valuable than a vault with 200 well-processed, interconnected notes used daily. Graph density means nothing if you never traverse the graph.
The processing days out of 30 metric cuts through vanity by measuring the only variable that actually compounds: consistent daily execution. A system used 28 of 30 days has been receiving daily input, daily maintenance, and daily retrieval — the three operations that produce compounding value. A system used 10 of 30 days, regardless of how many notes it contains or how sophisticated its structure, is producing intermittent value that doesn't compound.
The 28/30 target (93%) allows for 2 rest or travel days per month while maintaining the consistency that produces compounding. Below 20/30 (67%), the system is effectively intermittent and should be simplified until daily execution is achievable (Start processing habits tiny: 5 items in 2-3 minutes for 5 consecutive days — initiation barriers determine formation more than execution quality). Between 20-28, there's room for improvement but the habit exists. Above 28, the habit is robust and can sustain expansion.
When This Fires
- During monthly system health reviews when evaluating whether your PKM system is "working"
- When you feel your system should be providing more value despite having many notes
- When comparing your practice to others' — focus on execution days, not note count
- Complements Track daily completion (yes/no) not tool configuration — consistent execution of a mediocre tool outperforms sporadic use of a perfect one (daily tracking) with the monthly health evaluation framework
Common Failure Mode
Measuring inputs instead of execution: "I added 100 notes this month!" But adding notes is capturing, not processing. If you added 100 notes but processed (transformed, linked, applied) on only 8 days, your pipeline is accumulating raw material without producing refined output. The metric should track processing days, not capture volume.
The Protocol
(1) At the end of each month, count how many days you completed at least one processing session (triage, review, synthesis, or retrieval). (2) Score: 28-30 days → excellent, system is compounding well. 20-27 days → adequate, look for the pattern in missed days and address structural barriers. 10-19 days → struggling, simplify the system (When pipeline maintenance costs more than the pipeline saves, the economics have inverted — simplify, don't optimize) until daily execution is achievable. Under 10 → system has effectively failed as a daily practice. Reset with Start processing habits tiny: 5 items in 2-3 minutes for 5 consecutive days — initiation barriers determine formation more than execution quality's minimal version. (3) Do not count capture-only days: passively saving articles or bookmarking pages isn't processing. Processing requires active transformation, routing, or retrieval. (4) Use this metric as your primary health indicator. All other metrics (note count, link density, tool features) are secondary and only meaningful if execution days are at 28+. (5) If your score declines over consecutive months, the system needs simplification, not more features.