Map all downstream dependencies before updating a schema — behavior does not auto-align with new beliefs

Why This Is a Rule

Updating a schema without migrating its downstream dependencies produces the belief-behavior gap: you hold the new belief but your habits, commitments, tools, and routines still serve the old one. "I now believe in deep work" while your calendar, Slack habits, notification settings, and meeting commitments all reflect the old "always available" schema.

The gap persists because behavior doesn't auto-align with belief. Each downstream dependency — a recurring meeting, a notification permission, a social commitment, a workspace layout — was designed for the old schema and must be explicitly migrated to serve the new one. Without migration, the environment continues supporting the old schema, and behavioral reversion is inevitable.

Mapping dependencies before implementation prevents the common pattern of updating the belief, experiencing a honeymoon period where motivation overrides environmental friction, then reverting when motivation fades and the old-schema environment reasserts itself.

When This Fires

• After deciding to update a significant operating schema
• When a belief change isn't translating into behavioral change
• Before implementing any major shift in how you work, relate, or think
• When previous belief updates reverted because "life got in the way"

Common Failure Mode

Expecting automatic behavioral alignment: "I've updated my belief about time management, so my behavior should follow." It won't — every habit, commitment, and environmental cue was configured for the old schema. Without explicit migration, the environment pulls behavior back to the old pattern.

The Protocol

When updating a schema: (1) List all downstream dependencies: habits that serve the old schema, commitments made under the old schema, tools configured for the old schema, relationships that assume the old schema, routines built around the old schema. (2) For each dependency, determine: does this need to change to support the new schema? (3) Prioritize high-friction dependencies first — the ones that will most strongly pull behavior back to the old schema if not migrated. (4) Migrate systematically: change the calendar, reconfigure notifications, renegotiate commitments, redesign the workspace. The schema update is complete only when the environment supports the new belief, not just when the belief itself changes.