The kill switch

The kill switch is the crimson Halt button in the top bar. It is on every screen, it is one click plus a confirm, and it never asks for a code. Stopping must always be easier than starting.

Halt

Where to halt: the top bar, on every screen. That button is the control; everything else mirrors it.

1. 1Click Halt in the top bar (or choose "Halt trading" in the ⌘K palette). The Kill switch card and the page header on Risk carry the same button and open the same dialog.
2. 2Confirm in the dialog. No authenticator code is asked for.

Viewers and reviewers see the button but it is disabled; only an owner or operator can halt. The kill switch· Halt (top bar) · Risk header has no other home: no agent has a tool that halts or resumes trading; only a person, or the Executor's own halt rules below, can.

The Executor loops every 5 seconds and caches the halt flag for at most 5 seconds, so a halt is in force within about 5 seconds of your click. It also re-reads the flag without the cache immediately before each proposal it is about to process, so there is no window in which an order slips out after you clicked.

While halted, a banner sits across the top of every screen with a Resume button and says why and who: amber and calm ("Trading paused · ‹your reason› · set by you 14:20 CT") when a person paused trading, crimson when a risk rule tripped ("Trading halted by a risk rule · daily loss limit: …") or the Executor stopped itself on an error ("Trading halted: executor error · …"). The market chip goes grey meanwhile: MARKET OPEN is the exchange session, not your book. On Risk the one Kill switch card shows the same state with who set it and when, the flatten request, and a history of halts, resumes and flatten requests in plain words ("Drawdown halt · equity $10,000 vs high-water $20,000 (−50%, limit 8%) · Sep 8 16:56 CT · executor"); a halt that a later data correction explains is struck through and marked corrected: data issue.

Three kinds of halt

Every halt means the same thing to the Executor (reduce-only, below). They do not mean the same thing to you, so the banner tells them apart by colour and wording. The API works out the kind from who set the halt and what the Executor recorded as the cause; you never pick it.

A person's halt is always an operator pause, whatever you type as the reason: typing "daily loss" in the dialog does not make it a risk-rule halt. A halt the Executor set that cannot be classified (an old row from before the cause was recorded, say) is shown as a fault, the louder of the two, on purpose. Whoever set it, only an owner or operator can resume, always with a fresh authenticator code; no halt of any kind clears itself.

One more annotation appears in the history, not the banner: "corrected: data issue, not a real drawdown", muted and struck through, on a halt that turned out to be bad data rather than a loss (the day-zero drawdown halt of Sep 8, when the high-water mark was seeded wrong, is the one example so far). A halt is marked corrected only when a data-fix audit row written within 7 days names it (by its audit id, its calendar day, or the rule that tripped) or when the halt's own record says so. An unrelated correction the same week never mutes a real halt. If you or your operator record a data fix for a spurious halt, put the halt's day or id in it, or the history will keep showing it in crimson.

What a halt does

A halt makes the book reduce-only: nothing that adds risk goes out, anything that takes risk off still can. Your Halt, the kill switch a deployment starts with, a halt the Executor raises by itself (below) and the broker circuit breaker all mean the same thing. On the Executor's next loop, and again on every loop while the halt stands:

• No new buys. Buy proposals the PM (shown as Analyst on screen) has queued, and any that arrive while halted, are not run through the checks; they are closed with status blocked and the halt as the reason. On Agent the pill reads "Rejected · halted: …"; the idea was not judged wrong, the system was stopped. Order-management requests from the PM (move a limit, cancel, re-arm a stop) are blocked the same way while halted.
• Approval never outranks a halt. A buy you already approved but that had not yet been sent is blocked when the Executor reaches it. A card still waiting for your decision stays in the Inbox until its window ends; approving a buy while halted only gets it blocked.
• Working buy orders are cancelled at the broker. Every buy order still resting at the broker is cancelled in the same loop (never a sell). Its proposal closes as cancelled (or partial, if some shares had already filled) with a note that the halt cancelled it, and an alert line records each cancel under Activity › Alerts. If the broker cannot be reached at that moment, a warning says so and the cancel is retried on every loop until it lands.
• Sells still go out. A sell the PM proposed (a trim, a close), a sell card you approve during the halt, and the exits the Executor writes itself when a stop or target is hit are still evaluated and sent. They run the full risk checks; the daily-loss and drawdown checks pass a sell with a note instead of blocking it, because the halt they would raise is already on record. A protective exit that is already working keeps being re-priced toward the bid while halted (see the Executor).
• Open positions are kept. A halt cancels resting buys and lets sells through; it does not sell anything by itself. Selling everything is Flatten, below.
• One exception: the broker circuit breaker. While the breaker is open nothing can reach the broker at all, so the buy cancels and the sells wait until a person resumes and the broker answers again.

Halts that happen by themselves

The Executor halts on its own, with the cause written as the reason you see on Risk and in the banner, and as a critical alert under Activity › Alerts (posted to Slack too when a webhook is configured). The first two below show as a risk-rule halt, the other three as an executor fault:

• Daily loss: today's loss reached MAX_DAILY_LOSS_USD ($150 by default).
• Drawdown: the account fell MAX_DRAWDOWN_PCT (8% by default) below its high-water mark.
• Broker circuit breaker (broker_circuit_open): five consecutive retryable broker failures. There is no automatic retry probe; a person decides when the broker is back.
• Environment mismatch: the environment flag says one of paper or live and the running process says the other (risk check #1, broker_env_matches_process). See paper vs live.
• Broker authentication failure (broker_auth_error): the credentials stopped working.

The first cause stays on record: a later condition is logged but never overwrites the reason. If the database cannot be reached at the moment a halt is needed, the halt is kept pending and retried every loop, and nothing is processed until it lands.

Resume

1. 1Press Resume in the banner, the top bar, the Kill switch card on Risk or the ⌘K palette. It carries a small lock: resuming asks for your authenticator code. It is the same action for all three kinds of halt.
2. 2The dialog shows what you are clearing (the state, the reason and who set it), then Confirm and resume asks for your code. The server checks the code itself; a resume without a fresh code is refused. Viewers and reviewers cannot resume.

Confirming clears the halt reason, sets trading enabled, writes an audit row under Activity › Config changes, and resets the broker circuit breaker if it was open. Proposals that were blocked during the halt stay blocked and buy orders the halt cancelled stay cancelled; the PM proposes afresh at its next session, and anything new goes through the risk checks as usual. A halt that was caused by a limit trips again on the next loop if the condition still holds, so read the reason before you resume. If a flatten request was still pending when you resumed (it had not managed to run yet), the Executor drops it with a warning alert rather than sell a book you have just re-opened; request it again if you meant it.

Halt and Flatten

Pause trading and flatten is the section inside the Kill switch card on Risk. The button is disabled when there are no open positions. Pressing it opens a dialog that asks you to type the number of open positions and then for your authenticator code. Confirming does two things at once: it halts trading (if it was not halted already) and records a flatten request, which is audited and shown as a requested badge on the card and as a row in the kill-switch history. The console never talks to the broker; the Executor does the selling.

The Executor looks for the request at the start of every loop, so it acts within about 5 seconds. Flatten is the one sanctioned path that bypasses proposal → policy → submit (the risk checks, the no-trade windows and your approval threshold do not apply to it), so it is deliberately small and loud. It:

1. 1Refuses to touch the broker if the environment flag and the running process disagree (the same rule as risk check #1); the request stays flagged, a critical alert says why, and it is retried every loop.
2. 2Sets the halt again with the flatten as its reason (that is the reason Risk shows from then on), plus an audit row and a critical "flatten started" alert.
3. 3Cancels every open order at the broker, buys and sells alike.
4. 4Submits one limit sell per long position for the whole quantity, priced at the bid minus MAX_LIMIT_DEVIATION_PCT (1% by default) so it is marketable but still a limit order, and records each order under Activity › Orders.

When every cancel and every sell has been placed, the request is cleared in the same step as a "flatten executed" audit row under Activity › Config changes, the requested badge goes away, and an alert reports how many orders were cancelled and how many sells were placed. Trading stays halted until you resume; the sells are marketable limits, so watch Overview for the fills.

If any step fails (a quote could not be read, the broker refused or did not answer for one symbol), the sells that could be placed are placed, the request stays flagged with what went wrong, a critical alert lists the failed steps, and the whole routine runs again with fresh order ids after a growing pause (30 seconds at first, up to 10 minutes). It never gives up silently: from the third failed attempt the alert tells you to sell the rest by hand at the broker while it keeps retrying. While the broker circuit breaker is open nothing can reach the broker, so the request waits and a critical alert says so on every loop; the breaker itself only closes when you resume (or the Executor process is restarted), and resuming drops a pending request. So once the broker is healthy again, resume and press Flatten a second time, or sell at the broker yourself.