High-dependency schemas need slower revision — each update…

When This Fires

• When revising a schema that many other beliefs, habits, or decisions depend on
• During schema portfolio management when prioritizing what to review
• When a foundational belief needs updating and you need to plan the cascade
• When pace-layer guidance suggests frequent review but dependencies suggest caution

Common Failure Mode

Revising a foundational schema quickly because the evidence is compelling, without mapping or migrating dependents. You update "my core career goal is [X]" and immediately feel clarity — but your daily routines, commitments, relationships, and tools all still serve the old goal. The schema changed; nothing downstream changed. Dissonance accumulates until either the downstream dependencies drag you back to the old schema or the system collapses from misalignment.

The Protocol

When revising a high-dependency schema: (1) Count the downstream dependents: how many habits, decisions, commitments, or other schemas does this one support? (2) If >5 dependents → treat this as infrastructure-level revision. Slow down. (3) Plan the cascade: for each dependent, what changes? (Map all downstream dependencies before updating a schema…). (4) Test backwards compatibility: does the revision break any cases where dependents were working correctly? (Before finalizing a schema update, verify the new version…). (5) Implement gradually: update the schema, then migrate dependents one at a time rather than all at once.