Principles
2,201 principles · page 37 of 46
Document the specific conditions under which a schema…
Document the specific conditions under which a schema was validated, as the boundary of tested conditions defines the boundary of warranted confidence.
Reformulate schemas with explicit boundary clauses…
Reformulate schemas with explicit boundary clauses that separate validated conditions from untested extrapolations.
When transferring a schema to a new domain, treat…
When transferring a schema to a new domain, treat the transfer as a new hypothesis requiring independent validation rather than an extension of existing validation.
Treat scale transitions as requiring revalidation…
Treat scale transitions as requiring revalidation, as schemas validated at one scale often encounter emergent properties at different scales that invalidate their predictions.
Distinguish epistemic confidence (grounded in evidence)…
Distinguish epistemic confidence (grounded in evidence) from psychological confidence (grounded in identity and familiarity) by requiring an external validation trail for the former.
Test schemas where you feel most certain first, as high…
Test schemas where you feel most certain first, as high confidence without testing history signals the highest risk of unwarranted certainty.
Design tests that can genuinely fail by specifying…
Design tests that can genuinely fail by specifying in advance what observations would falsify the schema, not merely what would confirm it.
Document falsifications more thoroughly than confirmations…
Document falsifications more thoroughly than confirmations, as falsification provides boundary information, revision constraints, and exposure of hidden assumptions that confirmation cannot reveal.
Reframe invalidation as the highest-value epistemic event…
Reframe invalidation as the highest-value epistemic event rather than as personal failure, treating moments when schemas break as the richest learning opportunities.
Match schema review cadence to the actual rate of change…
Match schema review cadence to the actual rate of change in each domain rather than applying uniform revision intervals across all knowledge areas.
Treat unexpected outcomes as automatic triggers for schema…
Treat unexpected outcomes as automatic triggers for schema re-validation, as surprise signals that at least one schema in your stack has drifted out of calibration.
Identify beliefs where being wrong would have the greatest…
Identify beliefs where being wrong would have the greatest impact and prioritize validating those schemas first, as high-stakes beliefs with thin evidence represent maximum epistemic risk.
Schedule regular schema audits to detect drift before…
Schedule regular schema audits to detect drift before catastrophic failure, because unmonitored schemas degrade without signaling their obsolescence.
Frame belief revision as model calibration rather…
Frame belief revision as model calibration rather than personal failure to reduce identity-threat responses that block updating.
Limit revision scope to single-schema updates rather…
Limit revision scope to single-schema updates rather than wholesale worldview overhauls to stay within working memory capacity and enable accurate evaluation.
Maintain a revision queue where you capture schema anomalies
Maintain a revision queue where you capture schema anomalies as they occur rather than trying to fix everything immediately, enabling prioritized processing.
Log schema revisions in real-time rather…
Log schema revisions in real-time rather than retrospectively, because delayed documentation becomes narrative construction rather than accurate provenance.
Categorize revision triggers by type (data, experience…
Categorize revision triggers by type (data, experience, authority, social proof, emotion) to build meta-knowledge about your own epistemic patterns.
Archive old schema versions rather than deleting…
Archive old schema versions rather than deleting them, preserving the complete trajectory of your thinking for comparison and potential rollback.
When a schema stops fitting reality, formally mark…
When a schema stops fitting reality, formally mark it as deprecated with full documentation rather than patching it indefinitely with exceptions and workarounds.
Every deferred schema update accumulates interest payments…
Every deferred schema update accumulates interest payments in the form of suboptimal decisions, failed predictions, and wasted effort compounding until the schema is corrected.
Build schema update triggers based on surprise…
Build schema update triggers based on surprise and prediction failure rather than calendar schedules, because surprise is the natural signal of model-reality divergence.
When updating a schema, catalog every downstream…
When updating a schema, catalog every downstream dependency—habits, commitments, tools, relationships, routines—and migrate them systematically rather than expecting behavior to automatically align with the updated belief.
Execute schema migrations in order of friction—start…
Execute schema migrations in order of friction—start with dependencies that generate the most daily conflict between old infrastructure and new understanding to reduce the highest-cost misalignments first.
Before deploying a new schema, verify it correctly handles…
Before deploying a new schema, verify it correctly handles every case the old schema handled successfully—a schema update that drops coverage of previous successes is a regression, not an upgrade.
Inventory specific situations where your old schema produced
Inventory specific situations where your old schema produced accurate predictions, then test whether your new schema also handles those cases before replacing the old model.
Archive old schemas with documentation of what they handled…
Archive old schemas with documentation of what they handled well rather than deleting them, because they encode information about what works under specific conditions that new schemas should incorporate.
Interpret the physical discomfort of encountering evidence…
Interpret the physical discomfort of encountering evidence that contradicts a deeply held schema as the cost of cognitive growth rather than as proof the evidence is flawed.
Separate the documentation of disconfirming evidence…
Separate the documentation of disconfirming evidence from your emotional response to it by externalizing each in parallel columns, creating objects you can examine rather than a fused defensive reaction.
Set explicit tolerance windows when encountering…
Set explicit tolerance windows when encountering schema-threatening evidence—start with sixty seconds of sitting with discomfort before rushing to resolution—because premature resolution favors existing schemas over new evidence.
Expect a second wave of discomfort after initial schema…
Expect a second wave of discomfort after initial schema update when you realize the full implications for past decisions—this delayed recognition is where most people abandon updates and revert to old schemas.
Define observable trigger conditions for schema review…
Define observable trigger conditions for schema review before anomalies accumulate rather than waiting for subjective feelings of uncertainty to prompt reconsideration.
Track prediction accuracy against pre-defined thresholds…
Track prediction accuracy against pre-defined thresholds rather than relying on intuitive assessment of model quality, because humans systematically underweight evidence that contradicts their existing beliefs.
Set calendar-based schema review schedules independent…
Set calendar-based schema review schedules independent of observed performance, because temporal drift occurs whether or not conscious errors are detected.
Accumulate and threshold anomalies rather than evaluate each
Accumulate and threshold anomalies rather than evaluate each contradiction individually, because isolated anomalies can be dismissed while clusters reveal systematic model failure.
Create anomaly logs separate from regular notes, because…
Create anomaly logs separate from regular notes, because anomalies require dedicated collection systems to prevent dismissal through rationalization or burial in routine information.
Assign faster review cadences to schemas in complex…
Assign faster review cadences to schemas in complex or chaotic domains than their pace-layer position alone suggests, because unpredictability generates more frequent invalidating evidence.
Review high-dependency schemas more slowly and deliberately…
Review high-dependency schemas more slowly and deliberately than peripheral schemas, because revising foundational schemas requires updating all dependent schemas in a cascading revision process.
Change shared schemas through shared experiences rather…
Change shared schemas through shared experiences rather than shared information presentations, because behavioral coordination requires updated local models built from practice, not stated agreement.
Create boundary objects that embody new schemas in visible…
Create boundary objects that embody new schemas in visible artifacts, because people adopt schemas they can see and use rather than schemas they were told about.
Map what a shared schema currently supports before proposing
Map what a shared schema currently supports before proposing changes, because schemas embedded in coordination patterns create dependencies that must be managed during transitions.
Distinguish between increasing complexity that improves…
Distinguish between increasing complexity that improves explanatory power and complexity that merely preserves a failing model, because the latter signals the need for architectural replacement rather than parameter tuning.
Replace schemas when the framework cannot formulate…
Replace schemas when the framework cannot formulate questions that reality demands, because inability to express necessary questions reveals incommensurability between model and domain.
Generate multiple alternative frameworks rather than jumping
Generate multiple alternative frameworks rather than jumping to a single replacement, because competitive testing between candidate models produces better selection than loyalty contests.
Write forward-looking predictions from each candidate schema
Write forward-looking predictions from each candidate schema to create testable competition, because prospective prediction testing reveals model quality better than retrospective fit evaluation.
Delayed schema updates impose compounding costs because…
Delayed schema updates impose compounding costs because the gap between your model and a changing reality widens incrementally over time, making each decision progressively less optimal.
When expertise becomes locked into a familiar schema…
When expertise becomes locked into a familiar schema, attentional resources get captured by schema-consistent features, making genuinely better alternatives perceptually invisible even when they are objectively present.
Apply the zero-base test to detect schema rigidity
if you would not adopt the same belief as a newcomer encountering the situation fresh today, the schema persists through inertia rather than current validity.