The irreducible epistemic atoms underlying the curriculum. 2,888 atoms across 3 types and 2 molecules
For each major domain where you make decisions, explicitly write down the single deepest assumption everything else depends on, then list 5-10 decisions that would change if that root were different to verify you've found an actual root.
State the negation of any root concept you identify and ask what you would do differently if the opposite were true, not to believe the negation but to break the structural lock that makes the original feel inevitable.
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.
Before assuming you understand someone's reasoning, externalize your reading of their underlying schema and verify it directly rather than debating conclusions that may stem from invisible schema divergence.
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.
When a contained item appears in three or more contexts requiring synchronization, extract it into a referenced shared source with a single canonical version rather than maintaining multiple copies.
Position your system prompt's most important instructions in the first 20% of tokens, because transformer attention mechanisms allocate disproportionate processing to early sequence positions through positional encoding and causal masking.
When a schema triggers defensiveness at the suggestion of testing it, treat that emotional response as a diagnostic signal of high psychological investment requiring especially rigorous validation.
Rewrite personal identity schemas as behavioral predictions with specified conditions and thresholds to convert unfalsifiable identity claims into testable hypotheses.
When adjusting a schema after disconfirming evidence, require the adjustment to generate new testable predictions rather than merely explaining away the original failure.
Before acting on a schema in any consequential way, test it through concrete action at the smallest possible scale first and observe actual results against pre-stated predictions.
When an edge case breaks your schema, extract the implicit boundary condition that the edge case revealed rather than dismissing the edge case as an irrelevant exception.
Before explaining your schema to another person, frame your request as 'tell me where this breaks' rather than 'do you agree' to shift the conversation from validation theater to genuine testing.
Validate each atomic component of a compound schema independently before trusting the complete structure, because compound failures provide no diagnostic information about which component broke.
When using indirect evidence, assess whether indicators are genuinely independent by checking if they could agree for reasons other than the schema being true—if all evidence shares a common causal source, it counts as single evidence despite multiple data points.
After accumulating multiple validation records, analyze them as a set to identify recurring patterns in how your schemas fail—same blind spot, same overconfidence direction, same boundary condition—that no single test reveals.
Reformulate validated schemas with explicit boundary clauses that specify the conditions under which they were tested and the conditions under which they remain untested.