State both the exception AND the return date
When adjusting a boundary for legitimate contextual reasons (genuine emergency, changed circumstances), explicitly state both the adjustment and the return timeline: 'I'll help with this through Friday, and then the original boundary resumes'—to prevent temporary exceptions from becoming permanent erosion.
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.