Put schema reviews on your actual calendar — subjective feelings of uncertainty are unreliable triggers

Why This Is a Rule

"I'll reconsider this when it stops working" is subjective trigger scheduling — and it fails for the same reason all subjective triggers fail: schemas that need review don't feel like they need review. Confirmation bias makes working schemas feel correct and drifting schemas feel "a bit off but probably fine." By the time the subjective feeling of uncertainty reaches the action threshold, the schema has been wrong for weeks.

Calendar scheduling converts review from a subjective-trigger system to a time-trigger system. The review happens on the scheduled date regardless of how the schema feels. This catches the silent drift that subjective triggers miss — the gradual divergence between schema and reality that accumulates below the threshold of conscious uncertainty.

This is the same principle as scheduled maintenance for physical systems: you don't wait for the car to break down to change the oil. You schedule changes at fixed intervals because preventive maintenance catches degradation before failure.

When This Fires

• After determining review cadences for your schemas (Map review frequency to pace layer: weekly for fast-changing, annually for governance, anomaly-only for foundational, High-dependency schemas need slower revision — each update cascades through all dependents, In complex or chaotic domains, review schemas more frequently — unpredictability generates more anomalies)
• When schemas are reviewed "whenever I feel uncertain" (subjective trigger)
• When past schema failures could have been caught by regular scheduled review
• During any setup of epistemic maintenance infrastructure

Common Failure Mode

Scheduling the reviews but not protecting the time: "I'll review quarterly, but only if I have time." The review gets pushed by more urgent work — every quarter. Calendar scheduling only works if the time is protected. Treat schema reviews like dental appointments: scheduled, non-negotiable, and if you skip one, the cost compounds.

The Protocol

(1) For each schema review tier (weekly, monthly, quarterly, annual from Map review frequency to pace layer: weekly for fast-changing, annually for governance, anomaly-only for foundational), create a recurring calendar event. (2) During each event: review all schemas assigned to that cadence. Check: does the schema still predict accurately? Have environmental assumptions changed? Have anomalies accumulated? (3) Protect the time. If the review is consistently skipped → the cadence is wrong (too frequent) or the schema portfolio is too large (needs pruning). Either fix the root cause or accept that unreviewed schemas will silently drift.