The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
Use multiple classification dimensions (tags, categories, relationships) rather than forcing knowledge into single-parent tree structures when concepts legitimately belong to multiple parent categories.
Test hierarchical organizations by attempting to retrieve items via all their legitimate access paths, treating retrieval failures as structural defects in your organization system.
Choose depth-first traversal when you need any solution quickly; choose breadth-first when you need the optimal solution.
Build broader, shallower hierarchies for novices exploring unfamiliar domains; build deeper hierarchies for experts navigating familiar paths.
Every task must decompose to the level where done-state is clear, no clarification is needed, and completion fits in a single focused session.
Separate meta-work on system structure from actual leaf-level work; track time spent on each to prevent mistaking organization for output.
Externalize root assumptions as explicit, testable statements; trace which decisions inherit from each root to make dependency visible.
Test root concepts by negating them and asking what would change; if everything changes, you've found a genuine root.
Design intermediate navigation levels to answer questions users actually ask during search, not categories that made sense during filing.
Each intermediate level should reduce options to 5-12 items; if a level presents more, split it; if it presents fewer, consider removing the level.
Default to three-level hierarchies (root, intermediate, leaf); each additional level requires explicit justification for the structural information it preserves.
Distinguish structural depth (encodes real containment, scope, or inheritance) from bureaucratic depth (added for appearance of organization); remove all bureaucratic levels.
When AI generates hierarchies, verify you can navigate them without AI assistance; if not, the structure serves the tool rather than your cognition.
Design containers to provide interpretive context that items inside them cannot or should not carry independently.
Store properties at the highest applicable hierarchical level and let inheritance distribute them to avoid redundant specification.
Audit inherited properties for context-fitness rather than accepting them automatically, marking properties that create friction as override candidates.
Design inheritance chains to be shallow rather than deep to minimize fragility when parent-level properties change.
Make every override explicit by documenting which inherited property differs and why, rather than maintaining implicit mental exception lists.
Track override frequency as diagnostic data—when multiple children override the same parent property, restructure the hierarchy rather than accumulating exceptions.
Restructure hierarchies at the point of friction rather than proactively across the entire system to keep costs small and signals fresh.
Flatten hierarchies before deepening them—add nesting levels only when flat organization with rich cross-references proves insufficient.
When cross-cutting concerns dominate your hierarchy, reorganize along a different axis rather than forcing items into categories they only partially fit.
Design your primary hierarchy to optimize for the access pattern you use most frequently, then use tags, links, or AI search to surface alternative organizations on demand.
Generate alternative hierarchical organizations of the same data periodically to identify blind spots in your default structure.