State both the exception AND the return date

Why This Is a Rule

Boundaries need flexibility — rigid boundaries break under legitimate pressure (Three components of an effective boundary). But flexibility without a return timeline is erosion. "I'll make an exception for this emergency" without a stated end date creates a precedent with no expiration: the "exception" quietly becomes the new normal because nobody specified when the original boundary would resume.

The communication structure — both the adjustment and the return — prevents erosion by making the temporary nature explicit. "I'll attend evening meetings this week because of the product launch, and my no-evening-meetings boundary resumes Monday" has two components: the adjustment (evening meetings this week) and the return (Monday). Both parties now know the exception has an expiration date.

This is Define triggers for mode transitions in both directions…'s mode transition triggers applied to boundaries: you need explicit triggers for both the degradation (when to flex the boundary) and the restoration (when to restore it). Without the restoration trigger, the boundary degrades permanently because the return never gets explicitly scheduled.

When This Fires

• When a genuine emergency or changed circumstance warrants a temporary boundary exception
• When you want to be flexible without eroding the boundary permanently
• When previous temporary exceptions have quietly become permanent — this structure prevents recurrence
• Complements Enforce boundaries consistently — inconsistent… (consistent enforcement) by showing how to flex without breaking

Common Failure Mode

Exception without expiration: "I'll help with this." When does "this" end? Without a stated end date, the exception runs indefinitely. The other person reasonably assumes the boundary has been relaxed because no return was communicated. By the time you try to reinstate the original boundary, weeks have passed and the "exception" has normalized.

The Protocol

(1) When a legitimate reason warrants a boundary adjustment, state both components in the same communication: Adjustment: "I'll [modified behavior] because [legitimate reason]." Return: "This applies through [specific date/milestone]. After that, [original boundary] resumes." (2) The return date must be specific — "Friday," "end of sprint," "when the client launch is complete" — not vague ("when things calm down," which never arrives). (3) When the return date arrives: reinstate the boundary. Communicate the reinstatement if needed: "As discussed, my [boundary] is back in effect starting today." (4) If the legitimate reason extends beyond the original return date → explicitly renegotiate with a new return date. Never let the extension happen silently.