Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Run simplified systems for two full cycles before…
Validate simplified systems by running them for at least two full cycles before declaring success, as one cycle cannot distinguish between successful simplification and lucky conditions.
When debt grows despite repayment, simplify the system…
When a system's operational debt register grows despite consistent repayment, shift from maintenance to simplification rather than increasing maintenance effort.
Eliminate first, simplify second, automate last — never…
Follow the automation hierarchy of eliminate-simplify-automate in strict order, because automating waste entrenches it and automating complexity makes it brittle.
Start automation with checklists and templates before…
Start automation at the lowest-tech level that solves the problem (checklists, templates, calendar events) before considering platforms or scripts, because simplicity reduces maintenance burden.
Execute cuts during the audit session itself — deferral…
Execute all identified cuts during the audit session itself rather than creating a deferral list, as audit outputs are decisions implemented immediately not intentions documented for later.
For each category, complete
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.
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.
Structural depth encodes real boundaries; bureaucratic…
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 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.
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.
When an agent fires below 80% after 30 days, simplify…
When an agent fires below 80% of expected opportunities over 30 days, reduce it to the simplest executable version before adding any complexity, because unreliable agents cannot be improved through sophistication.
Start every new agent at under two minutes with zero…
Design minimal viable agents to execute in under two minutes with zero preparation before attempting multi-step sequences, because automaticity requires low activation energy and activation energy must be minimized before sophistication is added.
Radical simplification to 1-2 priorities is an emergency…
Treat simplification to one or two priorities as an emergency protocol to execute during overwhelm, not as a permanent lifestyle—scale back up to your full three-to-five item stack once capacity recovers.
Limit recurring low-stakes decisions to 3-7 options…
Cut recurring low-stakes decision domains to 3-7 options maximum, because this range matches working memory capacity for effective comparison without overload.