Rules
1,053 rules · page 8 of 22
Reporting hierarchy does not make priorities transitive…
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.
Test backup paths during normal operations — untested…
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.
Shared dependencies make redundancy cosmetic — two systems…
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.
State your purpose in one sentence before writing…
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.
Stuck for 30+ minutes? Switch abstraction levels — go one…
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.
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.
Identify the deepest assumption in each decision domain…
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.
Negate your root assumption and explore the implications…
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.
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.
Externalize your reading of someone's reasoning and verify…
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.
Clustered overrides mean the parent's assumption is wrong…
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 traits, not identity — if you are overriding…
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 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.
Structure long documents in three disclosure layers
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 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.
Put critical instructions in the first 20% of system…
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.
Defensiveness about testing a schema IS the signal…
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.
Convert 'I am X' identity claims into 'In situation Y, I…
Rewrite personal identity schemas as behavioral predictions with specified conditions and thresholds to convert unfalsifiable identity claims into testable hypotheses.
Schema revisions must generate new predictions, not just…
When adjusting a schema after disconfirming evidence, require the adjustment to generate new testable predictions rather than merely explaining away the original failure.
Test schemas at the smallest possible scale first…
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.
Edge cases that break your schema reveal boundary…
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.
Ask 'tell me where this breaks' not 'do you agree' — get…
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.
Test each component of a compound schema independently…
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.
Check if indirect indicators could agree for reasons other…
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.
Analyze validation records as a set — recurring failure…
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.
Add boundary clauses to validated schemas
Reformulate validated schemas with explicit boundary clauses that specify the conditions under which they were tested and the conditions under which they remain untested.
Match review frequency to volatility
Schedule schema reviews at cadences matched to environmental volatility: weekly/biweekly for high-change contexts, monthly/quarterly for stable contexts, plus triggered reviews when surprises occur.
Surprise = automatic schema review — do not wait…
Treat surprising outcomes as automatic triggers for schema review rather than waiting for scheduled validation cycles, as surprise signals that at least one schema in your stack has drifted from reality.
Include external ratings alongside self-assessment…
When validating schemas about personal capability or performance, include external observer ratings alongside self-assessment to detect systematic overconfidence blind spots that introspection cannot reveal.
Pre-mortem your critical schemas
Run a pre-mortem on each critical schema by specifying what the early warning signs would look like if that model is becoming obsolete, then check whether you have already seen some of those signs.
Defuse identity from belief
Before attempting to update a deeply-held schema, explicitly restate it as 'I hold the belief that [X]. This belief is a model I use. It is not who I am.' to create cognitive distance between identity and the belief.
After updating a belief, find one decision the new model…
After updating a belief, identify one downstream decision where the revised model produces a different recommendation than the old one to ensure the update becomes operational rather than merely verbal.
Map all downstream dependencies before updating a schema…
When updating a schema, map all downstream dependencies (habits, commitments, tools, relationships, routines) before implementation and migrate high-friction dependencies first.
Before finalizing a schema update, verify the new version…
Before finalizing any schema update, list five situations where the old schema produced accurate results and verify the new schema handles all five to ensure backwards compatibility.
Sit with cognitive dissonance for 60 seconds before…
Set a tolerance window of at least sixty seconds to sit with cognitive dissonance before attempting resolution, as premature resolution systematically favors existing schemas over new evidence.
Pre-commit to prediction failure thresholds (X out of Y)…
Set prediction failure thresholds as numeric ratios (X failures out of Y recent predictions) for each schema before observing prediction outcomes to trigger review when the threshold is crossed.
For each schema, list its key assumptions…
Define environmental change triggers by listing key assumptions underlying each schema and specifying observable indicators that each assumption no longer holds.
Accumulate anomalies on a running list — trigger schema…
Accumulate anomalies (observations that don't fit the schema) in a running list and trigger full schema review when the count reaches a pre-defined threshold, rather than treating each anomaly as requiring immediate action.
Keep a separate anomaly log with three fields
Create a dedicated anomaly log separate from regular notes where each entry records what you expected, what happened, and which schema generated the expectation.
Map review frequency to pace layer
Assign review cadences to schemas based on their pace layer—weekly to monthly for fashion/commerce layers in complex domains, quarterly for infrastructure layer, annually for governance layer, and only on anomaly for culture/nature layers with high dependency depth.
High-dependency schemas need slower revision — each update…
When a schema has many downstream dependencies, apply slower and more deliberate revision cadences than its pace layer alone suggests, because updating foundational schemas requires cascading updates to all dependent schemas.
In complex or chaotic domains, review schemas more…
In complex or chaotic Cynefin domains, increase schema review frequency beyond what the pace layer suggests because unpredictability generates more frequent anomalies requiring evaluation.
Put schema reviews on your actual calendar — subjective…
Schedule schema reviews on actual calendars at the assigned cadence rather than relying on subjective feelings of uncertainty to prompt reconsideration.
Shift team schemas through shared experiments…
When attempting to shift a shared team schema, create low-cost experiments where the team uses the new schema on one real decision, rather than presenting the new framework in slides or documents.