Stop Conditions: Writing the End of a Run Before It Starts

A stop condition says when to stop a bot without a discussion, and it has five fields: the signal it watches, the window that signal is measured over, the threshold that counts as crossed, the action that follows, and the person who owns executing it. Written before the run, it is a rule. Written during the run, it is a rationalisation for whatever you already wanted to do.

The reason to write stop conditions early has nothing to do with foresight. It is that the version of you who opens a run and the version who watches it degrade are different operators, and only the first one can make this decision honestly. Everything below is about getting the first one to leave usable instructions for the second.

Why the rule has to predate the run

Mid-run, three pressures push in the same direction. Sunk cost makes stopping feel like wasting what has been spent. Optimism about the next few minutes is systematically higher than it should be, because you are watching and it feels like watching helps. And the discomfort of an uncertain reading is relieved faster by continuing than by ending, because ending makes the loss definite.

None of those pressures exist while you are planning. That is the entire argument. The plan-time operator can weigh a bad outcome against a wasted budget without feeling either of them, which is exactly the state in which such trade-offs should be made. The run-time operator's job is narrower: recognise that a condition is met, and execute.

There is a second reason, which is that a written condition is falsifiable. When a run ends because a rule fired, you can ask afterwards whether the rule was set well, and adjust it deliberately. When a run ends because somebody felt it was time, there is nothing to adjust, and the next run inherits the same unexamined instinct.

The five fields of a stop condition

Each field closes a specific gap that would otherwise be argued about while the condition is firing.

1. Signal. Named precisely enough that two people reading the same screen would agree on the value. "Failures are high" is not a signal; "confirmed share of submitted transactions, read from chain" is.
2. Window. The span the signal is measured across. Without it, every disagreement about whether the rule fired becomes a disagreement about which window was meant.
3. Threshold. The line, plus one sentence on why that side of the trade suits this run. The sentence is what lets you revise the number sensibly later.
4. Action. Which rung: pause, stop or abort. A condition whose action is "reassess" has not decided anything and will not help you.
5. Owner. The named person permitted to execute the action, and the only person permitted to override it. Ambiguity here produces conditions that are met and not acted on.

Four categories of stop

Conditions fall into four groups by what they protect. Most runs need at least one from each, and a sheet that is entirely from one category usually means the others were never considered.

Integrity conditions deserve their harsher treatment. Every other category is a judgement about how much of something is acceptable. Integrity conditions are binary: either the run is operating on the thing you intended or it is not, and there is no threshold that makes trading the wrong address acceptable for a while longer.

Hard stop, soft stop and pause

Three endings with different costs, and confusing them is the most common structural error on a stop sheet.

A pause holds the run in place: no new work starts, in-flight work completes, state is preserved so that resuming is possible. It is the right action when you need to diagnose something and the cost of a delay is bearable. Its hidden cost is optionality decay, because a market does not wait for your diagnosis, and a run resumed forty minutes later is running under conditions the plan never described.

A soft stop ends the run in an orderly way: new work stops, in-flight work is allowed to settle, then close-out begins. This is the default action for budget and market conditions, because it protects the ledger. It costs you the settlement window, during which you are still exposed to whatever you were exposed to.

A hard stop or abort ends the run without waiting. Some work may be half-completed, reconciliation will be harder, and you accept that in exchange for immediacy. Reserve it for integrity conditions and for situations where the mechanism producing the problem is still producing it. An abort is a decision to trade a clean ledger for a fast exit, and it should be written down as that trade rather than reached for by reflex.

Too tight and too loose

Every threshold has two failure directions and no neutral setting. The desk does not publish values, because the right value depends on the size of your budget relative to the cost of an interruption, and that ratio is private to you. What can be laid out is what each direction actually costs.

Write the answer to the deciding question next to the threshold. A number with a reason attached can be revised intelligently between runs; a bare number gets either defended out of habit or abandoned in a bad moment.

Writing rules that survive pressure

The audience for a stop sheet is a tired person on a small screen who has already been watching for an hour. That audience cannot parse nested conditions, cannot hold two windows in mind, and will not follow a rule that requires arithmetic to evaluate.

• One clause per rule. If a condition contains "and" or "unless", split it into two conditions, or accept that it will not be evaluated correctly.
• Readable directly from a source you have. A rule that depends on a number you would have to compute is a rule that will be skipped.
• Stated in the direction of the action. Write what makes you stop, not what makes you comfortable. Rules phrased as reassurance are read as reassurance.
• Ordered by severity. Integrity first, budget second, everything else after. Under pressure people read the top of a list.
• Short enough to fit on one screen. Four to six conditions. A sheet with twelve rules is a document, and documents do not get consulted at minute seventy.

Testing the stop path

A stop condition is only as good as the mechanism that executes it, and that mechanism is almost never exercised until the moment it matters. Test it deliberately: on a small run, with a small budget, trigger the stop the same way you would in earnest and observe what happens to work already in flight.

Three things are worth confirming. Whether queued work is discarded or completed. Whether the stop is confirmed by anything other than the interface reporting it. And how long the gap is between pressing stop and the last transaction actually settling, because that gap is a window during which the run is still doing things and your attention has usually already left.

If the run is carried by an automated Solana volume bot you did not build, this test is more important rather than less, because you have no source to read and no way to infer the behaviour. Trigger the control once on a small run and write down what you observed, then keep that note with the stop sheet.

Verifying from outside the tool is the part people skip. Note the newest transaction signature before you stop, then check whether anything newer appears afterwards; the wallet view on a public explorer will show activity regardless of what your tool reports. If you want to reason about how long an in-flight transaction can still be included, the client documentation at docs.anza.xyz is the place to start, and the account and program references at solana-program.com help when you need to tell a routing failure from an account state problem.

Time-based and budget-based stops

These two are the easiest conditions to write and the most reliably useful, because neither requires you to interpret anything. They fire on quantities that only move in one direction, which makes them immune to the second-reading problem entirely.

Illustrative arithmetic, with invented inputs. Suppose you decide before a run that you are willing to commit a total budget B, and that you want the run to stop if it has consumed three quarters of B before completing half of its planned actions. That is a single comparison of two ratios, both of which you can read, and it catches the specific failure where cost per unit of work has quietly doubled. Substitute your own B and your own fractions; the structure is what transfers.

Elapsed-time stops are worth pairing with them. A run that has passed the duration you planned is, by definition, no longer the run you planned, whatever the other readings say. The condition costs nothing to evaluate and catches the slow drift that no single reading is sensitive to, which is the failure mode that most often ends with an operator saying they lost track of the time.

The override log

Overrides happen. The question is whether they are recorded. An override log is three columns and it changes behaviour more than any other artefact described on this site, because it makes a pattern visible that is invisible one incident at a time.

The values above are placeholders illustrating the shape, not a record of anything. The pattern they illustrate is the one to look for: a condition overridden twice in an hour is not a condition, and the honest response is either to change the threshold between runs or to remove the rule and admit you do not intend to follow it.

Two rules make the log work. Write the reason at the time of the override, not afterwards, because the reconstructed reason is always more flattering than the original. And review the log between runs rather than during them, because the point is to change the rules deliberately, not to argue with yourself while a run is open.

Who owns a stop

Ownership is the field that most sheets omit and the one that determines whether anything happens. A condition with no named owner is met by everybody and executed by nobody, particularly during a handover, where each person can reasonably assume the other has authority.

Ownership needs to transfer explicitly. When a run changes hands, the incoming operator either holds the authority to stop or does not, and both cases are workable as long as one of them is true and written down. The failure case is ambiguity: an operator who believes they need permission, watching a condition fire, waiting for someone who is asleep.

If a run will outlast one person's attention, decide in advance whether it may run unattended at all. Some runs can, because their stop conditions are automated and their failure modes are bounded. Others cannot, and for those the honest condition is that the absence of an available operator is itself a stop.

The stop sheet

Four to six lines, written in the planning session, printed or pinned where the run is watched. This checklist is not the conditions; it is the test that the conditions are finished.

• Every condition has all five fields: signal, window, threshold, action, owner.
• At least one condition exists in each category that applies: budget, integrity, market, operational.
• No condition contains "and", "unless" or a calculation.
• Each threshold has one sentence saying which direction of cost you chose and why.
• The stop path has been exercised at least once on a small run, by the person who owns it.
• The behaviour of in-flight work under pause, stop and abort is written down, not assumed.
• An override log exists and the last run's overrides have been reviewed.
• It is clear whether the run may continue when no operator is available.

When a condition does fire, the work is not over. A stopped run still has transactions settling, balances moving and accounts to account for, and the discipline of the next hour decides whether the run produces a result you can use or a set of numbers that never quite reconcile.