High-dependency schemas need slower revision — each update cascades through all dependents

Why This Is a Rule

A schema with ten downstream dependents is like a library function called by ten modules: changing it means cascading updates through all ten. The update cost scales with dependency count, not with the schema's pace layer. A commerce-layer schema (normally reviewed monthly) that twenty other schemas depend on should be revised more slowly and deliberately than a standalone commerce-layer schema — because every revision triggers twenty cascading updates.

This modifies Map review frequency to pace layer: weekly for fast-changing, annually for governance, anomaly-only for foundational (pace-layer review cadences) by adding a dependency multiplier. Pace layer determines the base review frequency; dependency count adjusts it upward (more cautious). A foundational schema that many others rely on needs higher confidence before revision, more careful testing of the revision (Before finalizing a schema update, verify the new version handles five cases where the old one worked backwards compatibility), and explicit migration of all dependents (Map all downstream dependencies before updating a schema — behavior does not auto-align with new beliefs).

The practical implication: don't revise high-dependency schemas quickly or frequently. When you do revise them, treat it as a major infrastructure change that cascades through the system, not a routine 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 — behavior does not auto-align with new beliefs). (4) Test backwards compatibility: does the revision break any cases where dependents were working correctly? (Before finalizing a schema update, verify the new version handles five cases where the old one worked). (5) Implement gradually: update the schema, then migrate dependents one at a time rather than all at once.