The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
Assign a unique identifier to every note before writing any content, treating the addressing decision as the first step that enables all subsequent linking and referencing.
Store evidence with full methodological metadata (sample size, control conditions, limitations) as independent nodes rather than as decorative citations on claims, to enable proportionality assessment and multi-argument reuse.
Match note granularity to retrieval frequency and question complexity: create fine-grained atomic notes (single claims) for domains where you need precise retrieval, and coarser aggregated notes for domains where you need high-level orientation.
When using AI systems with your knowledge base, maintain multiple granularity levels of the same material (fine-grained for precise retrieval, coarse-grained for contextual reasoning) rather than forcing a single chunk size, because different query types require different resolutions.
Store well-formed questions as first-class atoms in your knowledge system with the same structural treatment (unique identifiers, bidirectional links, metadata) as claims and answers, because questions organize attention and generate persistent search filters.
When building knowledge systems that will interface with AI, treat every link you create as infrastructure that future graph traversal algorithms will follow, prioritizing explicit relationship encoding over implicit semantic similarity because GraphRAG systems require edges to perform multi-hop reasoning.
Index only processed permanent notes in AI-searchable systems while keeping unprocessed inbox captures outside retrieval scope, because AI systems cannot distinguish epistemic status and will retrieve raw captures with equal confidence to verified knowledge.
Schedule quarterly depreciation reviews where you scan captured notes and bookmarks for information that has exceeded its useful life, then either update with current data, archive with context, or delete entirely to prevent outdated information from corrupting current decisions.
Document the purpose each category serves by completing the sentence 'this category exists to [do what] for [whom]' to distinguish functional infrastructure from inherited furniture.
When a binary classification hides multiple distinct failure modes or reasons within a single bucket, decompose it into separate dimensions that can be evaluated independently.
For every pair of categories in a classification system, verify that no item can legitimately belong to both (mutual exclusivity test), and verify that no domain item falls outside all categories (collective exhaustiveness test).
Design multi-class classification systems with mutually exclusive categories when items can only be one type, and multi-label systems when items can legitimately belong to multiple categories simultaneously.
When items consistently resist classification in your system (you hesitate, force-fit, or leave uncategorized), map what those resistant items have in common to diagnose missing categories that represent dimensions you care about but haven't encoded.
When a 'Miscellaneous' or 'Other' category grows faster than named categories, it signals that your classification dimensions are missing a meaningful distinction that reality contains.
Before creating or reorganizing any hierarchical structure, ask what question each level answers—top level for domain identification, leaf level for specific item selection, and intermediate levels for navigation steps between.
For each intermediate level in a hierarchy, test whether removing it and promoting its children one level up would lose meaningful organization—if not, flatten it, because unnecessary levels are pure navigational tax.
Distinguish structural hierarchy depth (encoding real containment or inheritance) from bureaucratic depth (added for perceived tidiness) by asking what would break if you removed each level—keep only levels whose removal would destroy actual functional boundaries.
When multiple children override the same inherited property, restructure the hierarchy rather than accumulating individual overrides, as clustered overrides indicate the parent's assumption is systematically wrong.
Override properties rather than identities—preserve the child's relationship to its parent category while modifying specific inherited traits, as overriding identity signals you need a different category, not an override.
Restructure hierarchies at the specific node causing friction during the moment you feel the friction, rather than conducting proactive system-wide reorganizations, to keep restructuring costs small and diagnostic signals fresh.
Before adding another level of nesting, first attempt to flatten the hierarchy one level and use tags or links to preserve relationships, as deep hierarchies are more expensive to maintain than flat hierarchies with rich cross-references.
When navigation to any item requires remembering a path more than three levels deep, audit whether each nesting level provides unique decision-making value—if you cannot explain what decision a level enables, eliminate that level as noise.
Combine hierarchical folders (for coarse structure), tags (for cross-cutting themes), explicit links (for semantic relationships), and maps of content (for curated entry points) rather than relying on any single organizational mechanism, as each hierarchy type makes different questions answerable.
When documenting information longer than one page, structure it in three disclosure layers: single-sentence summary (Layer 1), paragraph-per-section abstracts (Layer 2), and full detail (Layer 3), with each layer independently meaningful.