Skip to content

Hysteresis Management

Account for path-dependent thresholds so returning a system to a prior or safer state requires different actions than leaving it.

The Diagnostic Story

Symptom: A system entered a changed state under pressure and is now toggling around the same threshold every few weeks: intervention, apparent improvement, removal, relapse, re-intervention. Stakeholders argue about whether conditions have really returned to normal because the same evidence that triggered entry is being used to justify exit. Past commitments, accumulated load, lost trust, or changed infrastructure make the return path much harder than the original entry.

Pivot: Separate the logic of entry from the logic of exit. Define what state the system is actually in, what evidence would demonstrate genuine stability rather than disappearance of the trigger, what specific state memory needs to be addressed, and what support is required for the transition rather than just for the stay.

Resolution: Premature reversals and repeated reentries become rarer because exit requires its own evidence of stability, not just absence of the original trigger. Transitions are safer and the hysteresis band prevents unstable switching without hiding the possibility of real recovery. Decision accountability improves because entry and exit are separately justified.

Reach for this when you hear…

[intensive care medicine] “Weaning from the ventilator is not just reversing intubation — the lungs have changed and the patient needs a proper extubation readiness protocol.”

[central banking] “You can cut rates faster than you raise them, but normalizing after emergency accommodation takes years because the economy has built around cheap money.”

[software incident response] “We declared the incident closed the moment errors dropped, but we never checked whether the underlying queue debt was gone — it came back the next morning.”

Mechanisms / Implementations

  • Thermostat Hysteresis Rule: Slug: thermostat_hysteresis_rule Mechanism type: procedure Uses separate on/off thresholds so a controller does not switch states repeatedly around a single boundary.
  • Separate Entry/Exit Criteria: Slug: separate_entry_exit_criteria Mechanism type: checklist Documents different criteria for entering and leaving a state so reversal is not treated as a mirror image of activation.
  • Staged De-escalation Protocol: Slug: staged_deescalation_protocol Mechanism type: protocol Returns a system gradually through intermediate states instead of immediately restoring the prior state.
  • Reentry Criteria Review: Slug: reentry_criteria_review Mechanism type: workflow Requires explicit review before a person, service, team, or subsystem returns to normal operation after a changed state.
  • Relapse Prevention Plan: Slug: relapse_prevention_plan Mechanism type: document Names warning signs, supports, and response steps that prevent return to an undesired prior state after apparent recovery.
  • Lock-In Exit Program: Slug: lock_in_exit_program Mechanism type: program Reduces switching costs and provides transition support so a system can leave a history-created lock-in.
  • Cooldown Period Rule: Slug: cooldown_period_rule Mechanism type: procedure Requires a minimum settling time before a state can be reversed or a control can be disengaged.
  • Debt Workout Plan: Slug: debt_workout_plan Mechanism type: program Creates a different recovery path for accumulated obligations than the original path by which the obligation was incurred.
  • Phase Recovery Checkpoint: Slug: phase_recovery_checkpoint Mechanism type: test_or_assessment Tests whether the system has enough stability, capacity, and evidence to move to the next recovery stage.
  • Support Taper Schedule: Slug: support_taper_schedule Mechanism type: workflow Gradually reduces extra support only as stability evidence accumulates.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

Also references 10 related abstractions

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Hysteresis Band Design · subtype · recognized

Design separate activation and deactivation thresholds so the system does not switch repeatedly around a single boundary.

Asymmetric Recovery Management · temporal variant · recognized

Plan a return path that differs from the entry path because the changed state created accumulated damage, altered capacity, or changed expectations.

Lock-In Exit Management · subtype · candidate

Manage exit from a history-created lock-in by mapping switching costs, creating supports, and protecting against relapse into the old path.

Relapse-Sensitive Hysteresis Management · domain variant · recognized

Manage transitions where apparent recovery is fragile and return to the undesired state is likely without ongoing supports.