The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
When search returns results from your information system, evaluate each candidate by reading only the bolded or highlighted passages from progressive summarization rather than scanning full text.
Write note titles using the natural-language words you would type when searching for that information, not abstract labels or jargon, to maximize searchability.
Flatten folder hierarchies by moving contents of folders containing fewer than 5 items up one level, as such folders are structural overhead with minimal retrieval benefit.
Bold 10-20% of a note's text on first revisit by selecting only passages that capture core ideas, making subsequent scans 5-10x faster than reading full text.
From bolded passages, highlight 10-20% that are most relevant to your current purpose on subsequent revisits, creating a second layer of compression targeted to your active needs.
Write an executive summary of 3-5 sentences at the top of a note only after it has been revisited 3-4 times, as this frequency indicates the note has proven its importance through actual use.
Apply progressive summarization layers only to notes you revisit for specific purposes, never in batch processing sessions, to ensure layers reflect actual utility rather than speculative importance.
Lay out multiple notes simultaneously in parallel visual access rather than reading them sequentially, because synthesis requires holding multiple ideas in working memory or visual space at the same time.
During synthesis, look for structural parallels and shared dynamics across inputs rather than topical overlaps, because topical overlaps produce aggregation while structural parallels produce synthesis.
Test synthesis output by asking whether it makes a claim that could not be found in any individual source - if it could be produced by listing inputs, you have aggregated rather than synthesized.
When you cannot explain a concept in simple terms to someone with zero shared context, treat this as diagnostic evidence that your processing is incomplete rather than a labeling problem.
When information backlog in any queue exceeds your daily processing rate by more than 10%, declare that queue a bankruptcy candidate requiring immediate archive-and-reset rather than incremental catch-up.
Start new information processing habits with a minimal version (processing 5 items, 2-3 minutes) for five consecutive days before expanding to full sessions, because initiation barriers determine habit formation more than execution quality.
Operate information processing on four nested cadences: daily triage (20-30 min), weekly review (catch drift), monthly audit (source quality), and quarterly purge (accumulated sediment).
Choose one information processing tool by defining 5 minimum requirements, selecting the first that meets them, and committing for 90 days before re-evaluation, rather than maximizing across all available options.
Track daily whether you completed your information processing session (yes/no) rather than optimizing configuration, because consistent execution of a mediocre tool outperforms sporadic use of a perfect one.
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.
When information pipeline maintenance consumes more cognitive resources than the pipeline saves, the system economics have inverted and simplification is required, not optimization.
Annotate each output type in your taxonomy with its approximate half-life (hours, weeks, months, years) to calibrate appropriate investment in durability, structure, and polish.
For each output type, define both 'good enough' criteria and explicit over-investment thresholds to prevent perfectionism from consuming effort that belongs to higher-stakes work.
Position quality verification between 'I think this is done' and delivery as a mandatory pause point with an explicit checklist, not as optional review when time permits.
Limit output checklists to five-to-nine items targeting errors that are both frequent and consequential, ordering from most catastrophic to least to enable partial execution under time pressure.
Build checklists from your documented error history rather than hypothetical failures, promoting an error to checklist status only after it has occurred in actual deliverables.
Embed checklists at the physical or digital location where delivery occurs, making them harder to skip than to use by integrating them into templates, pull request forms, or pre-send screens.