The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types and 2 molecules
For each candidate enabling relationship, articulate the specific mechanism through which one condition creates another; if you can only state correlation ('they go together') rather than mechanism, treat it as association not enabling.
Before attempting to resolve any contradiction between beliefs, construct the strongest possible version of each side that the most informed advocate would recognize and endorse.
When evaluating confidence in a belief, count only genuinely independent lines of evidence—sources that do not share origins, methods, or assumptions—rather than total source count, because correlated sources compound confidence on a single foundation.
Connect each abstract concept in your knowledge system to at least three concrete examples from different domains, because single examples invite surface-feature overgeneralization while multiple examples force attention to shared structural patterns.
Intervene in causal chains at the deepest link where you have both ability and authority to act, as fixes at deep links prevent the entire chain from firing while surface fixes only address symptoms.
After drawing a complete relationship map, write three to five sentences describing the structural story—focusing specifically on what was invisible before you drew the map rather than summarizing what you already knew.
When a relationship type is mathematically transitive (like 'is greater than' or 'is ancestor of'), you can safely infer the endpoint connection from a chain; when it is not transitive (like 'is friend of' or 'is close to'), you must verify endpoint relationships directly rather than inferring them.
Before assuming organizational hierarchy makes strategic priorities transitive, verify alignment at each reporting level independently, as 'reports to' relationships do not make 'shares priorities with' transitive.
When validating redundancy in human systems, test backup paths during normal operations rather than waiting for primary failure, as untested redundancy often fails precisely when needed due to skill atrophy or outdated procedures.
When two systems appear redundant but share a common power source, network segment, authentication service, or human operator, treat them as a single point of failure with cosmetic duplication rather than genuine redundancy.
Before beginning any communication, writing, or presentation, state in one sentence what you are trying to accomplish, then use that purpose statement to select the appropriate level of abstraction.
When stuck on a problem for more than 30-60 minutes at your current level of abstraction, force yourself to spend at least 5-10 minutes at an adjacent level (one step more abstract or one step more concrete) before continuing.
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 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.