The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
When the same action-level failure recurs weekly for three weeks, treat it as definitive evidence of system design failure rather than execution failure and shift to structural redesign.
Before sharing a reflection, write three sentences clarifying what type of support you want—not a solution, but a specific form of assistance like 'hearing how this sounds' or 'identifying what I might be missing.'
Maintain a personal map of 2-5 thinking partners, documenting for each: what topics they're suited for, what topics are inappropriate due to competing interests or power dynamics, and what type of support they naturally provide.
When you skip a reflection prompt or write something safe instead of what you actually got stuck on, treat the skipped topic as the most valuable reflection target for that session.
Conduct a 'resistance audit' by listing topics from the last five reviews, then separately listing topics that were active in your life but absent from your reflections, then writing for ten minutes on the highest-discomfort absent topic.
When reviewing old reflections that contain errors or embarrassments, do not edit or delete them—the archive's value lies in preserving what you actually thought at the time, enabling detection of belief evolution and systematic biases.
When reflection quality plateaus after months of practice, change the focus of your practice by shifting from events to systems, from behavior to beliefs, from solo to dialogic reflection, or by retiring stale prompts and designing new ones targeting the next depth level.
Match tool evaluation effort to irreversibility, not complexity or anxiety—allocate maximum deliberation to tools where switching costs are high (years of data, muscle memory, workflow dependencies) and minimal deliberation to tools where switching is cheap.
When two tools in your stack both maintain authoritative copies of the same data type, designate one as canonical (single source of truth) and demote the other to either capture-point (temporary holding before transfer) or read-replica (displays data but cannot edit) status to prevent sync drift.
Automate the single highest-frequency manual data transfer in your tool stack first, verify it works reliably for one week, then iterate to the next highest-frequency transfer—sequential automation prevents building a fragile web of interdependencies that becomes unmaintainable.
Choose tools that store data in open, portable formats (Markdown, CSV, JSON, plain text) over proprietary formats even if the proprietary tool has more features, because migration cost compounds daily with every new piece of data added to a locked format.
Define the specific job you're hiring a tool to do in one concrete sentence before evaluating candidates—vague category labels ('note-taking app') produce feature-based comparison while specific job definitions ('capture ideas on phone, retrieve on laptop at night') produce fitness-based selection.
Limit active tool candidates to two or three options maximum before evaluation—evaluating more options increases decision time logarithmically while decreasing satisfaction regardless of whether you choose objectively better tools.
Match deep tool mastery investment to usage frequency times behavioral impact—invest months of deliberate practice in tools you use daily for consequential work, limit learning to competence for infrequent or low-stakes tools.
Conduct a monthly depth audit of your primary tool by identifying ten capabilities you've never used, rating their potential value, practicing the top three for one week, then integrating the useful ones—compound learning beats sporadic feature discovery.
Designate one tool as hub for all thinking and synthesis work, then connect other specialized tools as spokes that feed into or draw from the hub—hub-and-spoke architecture minimizes integration complexity (N connections not N²) while preserving single source of truth.
Transfer captured information from temporary locations (notebooks, voice memos, quick-capture apps) to canonical sources within 24 hours—longer delays allow the temporary location to become a de facto second source of truth through repeated consultation.
When a tool's advanced features would save time but require learning investment, calculate break-even: if the feature saves X minutes per use and requires Y hours to master, invest if (frequency × X) > Y within 90 days—shorter payback windows justify learning effort.
Choose task management tools that support if-then implementation intentions and context tagging over feature-rich project management tools when your primary need is execution not coordination—simpler tools with behavior-triggering structure beat complex tools optimized for planning.
Map your tool stack visually with tools as nodes and data transfers as edges, labeling each edge as manual/automated and daily/weekly/monthly—this diagram reveals bottlenecks (high-frequency manual transfers) and redundancies (overlapping functions) that narrative inventory cannot surface.
Test whether a tool is earning its place in your stack by temporarily removing it for one week—if you don't consciously miss specific capabilities (not just habit), the tool is redundant and should be permanently removed to reduce maintenance surface.
When two tools provide overlapping functionality, consolidate to the tool that integrates better with your stack even if the eliminated tool has superior standalone features—integration quality dominates feature quality in compound workflows.
When migrating tools, run both systems in parallel for 2-4 weeks with new data going to the new tool and old data accessed from the old tool, ending only when the parallel period confirms the new tool handles your daily needs.
Before migrating any tool, test the destination by importing 20-50 representative items and examining every imported item in detail for formatting survival, metadata preservation, and link integrity.