Escalation Stop Workflow¶
An event-driven enforcement process — instantiates Plateau Detection and Switching
Fires the moment marginal response crosses a preset stop line — pausing further input, notifying an owner, and forcing a switch-or-revalidate decision so a plateau can't be quietly ignored.
Escalation Stop Workflow is the mechanism that turns a noticed plateau into an unavoidable decision. Detection produces a signal; a dashboard makes it visible; but signal and visibility still get overridden by momentum and optimism. This workflow closes that gap by being event-triggered and binding: when marginal response crosses a stop threshold, it automatically halts further escalation, pings a named owner, and blocks resumption until someone explicitly chooses to switch, revalidate, or override on the record. Its distinguishing property is that inaction is not an option — the default flips from "keep spending unless someone stops it" to "spending is paused until someone justifies restarting it."
Example¶
A recruiting team has an open staff-engineer requisition that has consumed sourcing spend and recruiter hours for weeks with a flat trickle of qualified candidates. An Escalation Stop Workflow watches the marginal signal — qualified candidates per sourcing-hour — against a stop line agreed at kickoff: if it stays below threshold for two consecutive weeks, the workflow fires. It pauses the outbound spend, posts to the hiring channel, and creates a decision task assigned to the hiring manager: switch the approach (loosen the level, open the location, engage an agency), revalidate the current path with a concrete reason to expect it to unstick, or override and keep going with an explicit owner. The requisition can't just drift for another month — the pause forces the choice into the open, with a name attached to whichever branch is taken.
How it works¶
- Bind a stop line to the signal. A preset threshold on marginal response, agreed before the effort starts, defines the trip point — no renegotiating it in the heat of the moment.
- Trip on the event, not the calendar. The instant the signal crosses and persists past the threshold, the workflow fires; it doesn't wait for a scheduled review.
- Pause by default and assign an owner. Further input is halted and a named person is notified, so the plateau has an accountable decision-maker.
- Force an explicit branch. Resumption requires a logged choice — switch, revalidate, or override — so continuing is a decision, not a drift.
Tuning parameters¶
- Threshold level — where the stop line sits. Tight lines stop spent paths quickly but trip on noise; loose lines tolerate real flattening too long.
- Persistence requirement — how many consecutive periods below the line before firing. More periods reject false alarms but bleed resource; fewer are twitchy.
- Pause hardness — whether the trip is a hard freeze or a soft flag. Hard freezes guarantee attention but can halt something that only briefly dipped; soft flags are ignorable.
- Override friction — how much justification an override demands. High friction curbs momentum-driven "just keep going"; too high, and teams route around the workflow entirely.
When it helps, and when it misleads¶
Its strength is defeating the drift that lets a known plateau consume resource indefinitely — it is the structural answer to escalation of commitment, the tendency to pour more into a failing course precisely because so much is already sunk into it.[1]
Its failure mode is firing on a false plateau: a hard stop tripped by two noisy weeks can kill a path that was about to turn, and repeated false trips train teams to reflexively override, hollowing the workflow out. It can also be gamed in reverse — an owner who wants to kill a project can set the stop line where it's sure to trip. The discipline is to route a trip into a genuine decision rather than an automatic kill (revalidate is a first-class branch), to require persistence before firing, and to pair the stop line with a validity check so the pause opens an inquiry rather than pronouncing a verdict.
How it implements the components¶
Escalation Stop Workflow fills the governance-and-enforcement subset — it converts detection into an unignorable stop:
escalation_stop_rule— its core: the binding rule that halts further input once the threshold is crossed.plateau_threshold— the specific stop line the rule trips on, fixed in advance.switch_trigger— the forced decision point that turns the stop into a switch-or-revalidate choice with an owner.
It does not measure the margin or judge whether the plateau is real (marginal_response_metric, false_plateau_check → Diminishing Returns Detection, Controlled Experiment After Plateau), and it does not choose the replacement path (alternative_strategy → Strategy Switch Decision Tree).
Related¶
- Instantiates: Plateau Detection and Switching — it is the governance step that stops blind escalation once a plateau is confirmed.
- Consumes: Diminishing Returns Detection supplies the marginal signal the stop line trips on.
- Sibling mechanisms: Plateau Review Cadence · Diminishing Returns Detection · Marginal Gain Dashboard · Controlled Experiment After Plateau · Ad Fatigue Switching · Training Plateau Adjustment · Product Growth Plateau Response · Process Redesign After Plateau · Saturation-Aware Resource Allocation · Strategy Switch Decision Tree · Expert-Governed Modality Change
Notes¶
The event-driven half of a pair: this workflow trips when a threshold is crossed, whereas Plateau Review Cadence revisits paths on a fixed schedule. Use both — the workflow catches a fast collapse between reviews; the cadence catches the slow flattening that never quite trips a line.
References¶
[1] Escalation of commitment — the documented tendency to invest more in a failing course of action because of what has already been sunk into it. This workflow is a structural countermeasure: it makes continuing the choice that must be justified, rather than the default. ↩