Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Design hierarchy levels by what question each answers…
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.
Test each hierarchy level by removal — if promoting…
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.
Restructure at the friction point, in the moment…
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 depth, try flattening + tags first — deep…
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.
Three levels deep is the maximum — any level…
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.
Use four organizational mechanisms together
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 content appears in 3+ contexts, extract a single…
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.
Map schema dependencies in both directions…
For each important schema, map both its prerequisites (what it depends on) and its dependents (what depends on it), then flag schemas appearing most frequently as dependencies for regular review.
Limit knowledge graph relationship types to 5-7 — more…
When building knowledge graphs, limit relationship type taxonomies to 5-7 types rather than attempting comprehensive ontological coverage, because classification overhead beyond this threshold produces diminishing informational returns while increasing maintenance cost.
Bridge domains through structural patterns, not surface…
When creating bridge nodes between domains, link to structural patterns (diminishing returns, feedback delays, threshold effects) rather than surface metaphors (companies as bodies), because only structural correspondence enables valid inference transfer across contexts.
Typed edges enable AI reasoning; embeddings only find…
When AI systems traverse your knowledge graph, maintain typed relationship labels with explicit predicates rather than relying on semantic similarity alone, because typed edges enable logical reasoning while embeddings only surface associative proximity.
When opening a hub note, check backlinks for 2 minutes…
When opening a hub note (one you reference frequently), immediately check its backlinks panel and spend two minutes reading the incoming references to surface connections you had forgotten.
If you can't articulate the link in a complete sentence…
When building connections between notes, test each link by asking whether you can articulate the relationship in a complete sentence—if you cannot, delete the link rather than inflating density metrics artificially.
Invest quarterly maintenance in your top 5% most-connected…
Identify your top 5% of notes by connection count and schedule quarterly reviews where you verify each hub note is current, accurate, and well-linked, investing maintenance effort proportional to structural importance.
Distinguish real hubs (genuine cross-domain centrality)…
Distinguish real hubs (concepts earning centrality through genuine cross-domain relationships) from artificial hubs (index pages linking to everything in a category) by testing whether removing the hub would sever meaningful conceptual pathways or merely convenience pathways.
A bridge node must generate insights in BOTH connected…
Test each bridge node by verifying it generates novel predictions or actionable insights in both connected domains—if it only produces a sense of similarity without bidirectional inference, demote it to metaphor status or delete it.
Find your three densest knowledge clusters by internal…
Identify your three densest knowledge clusters by examining which groups of notes link heavily to each other but sparsely to the rest of the graph, then label each cluster based on observed structure rather than imposed categories.
If a cluster only exists because you forced links…
When a cluster appears only after you force-link unrelated notes to create it, delete those artificial connections because imposed clusters destroy the diagnostic value of emergent structure.
When your graph's clusters contradict your self-narrative…
When your graph's cluster structure contradicts your self-narrative about expertise, trust the cluster structure because it reflects actual linking behavior while self-assessment is systematically distorted.
For each pair of clusters with no bridge, identify…
List your major clusters and for each pair ask what connects them; when the answer is 'nothing' or 'one weak edge,' write down the bridge concept that should connect them as your next learning target.
Show your graph to domain experts and ask what's missing…
Show a portion of your knowledge graph to someone with domain expertise and ask what's missing to detect unknown unknowns that your graph's topology cannot reveal through internal inspection alone.
Start your knowledge graph now with five nodes — five…
Start building your knowledge graph with your current five nodes rather than waiting for critical mass, because a graph with five nodes and eight edges already delivers more value than five hundred isolated notes.
Use Shneiderman's overview-first protocol for graph…
Apply Shneiderman's three-phase visualization protocol to graph exploration: overview first without reading labels, zoom and filter to examine specific clusters, then details-on-demand for individual nodes.
Use AI for structural gap detection — ask it to find…
Use AI to identify conspicuously absent concepts that would bridge multiple existing graph nodes rather than generic topic recommendations.