Loss is budgeted before it is taken

T3 Trade enforces risk limits in code rather than relying on model instructions. Each mission has a fixed cumulative-loss ceiling, a 14-item checklist before any position increase, a persistent block when that budget is exhausted, and protective stops on the exchange. Seven user controls can reduce or remove exposure even when the provider process is unavailable.

The ceiling is arithmetic, not opinion

Fourteen questions, in an order that matters

Before any position-increasing action is signed, it runs the §16.3 checklist: 14 items in their listed order, each with its own rejection reason, plus two exit-only items apps/server/src/trading/TradingPreviewService.ts:40-70. The service is pure validation over already-loaded state: it reads no exchange and mutates no tables apps/server/src/trading/TradingPreviewService.ts:10-15. The checklist order affects safety apps/server/src/trading/TradingPreviewService.ts:444.

An exit runs the nine checks about executing it correctly and drops every check about whether more exposure should be permitted. Those entry rules once blocked exits when risk was already elevated. A blocked mission, disabled entries, or an exhausted budget could each prevent the action needed to reduce exposure apps/server/src/trading/TradingPreviewService.ts:462-483. The exit list also drops the exchange minimum, because refusing to close a dust position is the minimum inverted apps/server/src/trading/TradingPreviewService.ts:515-523.

When the budget is gone, the mission stops

Exhaustion is a computed flag, not a judgement: exhausted when remaining budget is at or below zero packages/trading-contracts/src/lossAccounting.ts:135. What happens next is a fixed sequence run by the execution guard, and it runs to the end regardless of who is watching.

Ceilings in dollars, and they only tighten

Stops that live on the exchange

Emergency close follows a bounded sequence

The emergency close runs when full protection cannot be confirmed inside the reconciliation window. §17.5 calls it a deterministic safety action, not a strategy decision: it runs without the harness, in a fixed order, a fixed number of times, and never waits for anyone to wake up and help apps/server/src/trading/TradingEmergencyCloseService.ts:4-7. The order is the specification, and each step exists because of the failure it prevents apps/server/src/trading/TradingEmergencyCloseService.ts:9-32.

The outcome is a narrow three-way union: flat, open, or unknown, with remainingSize: null whenever the canonical size could not be confirmed apps/server/src/trading/TradingEmergencyCloseService.ts:63-117. One rendering, describeEmergencyCloseOutcome, is shared by every caller so the three reactor call sites cannot disagree (RC04) apps/server/src/trading/TradingEmergencyCloseService.ts:119-133. The full anatomy of an order's path to the exchange is on the Execution page.

Seven controls that do not ask the model

None of the §14.7 controls may require a harness turn: a user who wants out of a position must be able to get out while the provider process is dead, the session is unreachable, or the model is mid-thought apps/server/src/trading/TradingControlService.ts:2-8. The risk-reducing controls therefore take the preview-free reduce-only path, which is safe for a different reason: the exchange itself will not let a reduce-only order open or extend a position apps/server/src/trading/TradingControlService.ts:10-17.

Each control action leaves a persistent result

Before RC06, the outcome of a risk-control press lived only in server logs: a dispatched command proved the request was accepted, and the reactor's exchange work finished later where nobody could see it apps/server/src/persistence/Migrations/094_TradingControlResults.ts:9-12. The fix is the append-only trading_control_results table, one row per applied control with the control name, a completed, failed, or unknown status, the composed summary, per-market facts as JSON, and the sequence of the request event it answers apps/server/src/persistence/Migrations/094_TradingControlResults.ts:15-23. A trading.mission.control-result event rides the same stream as the doorbell that tells the client to refetch.

The same honesty rule appears at every layer of this page: the budget states what is left, the guard states which side of the gate an action fell on, the emergency close states flat, open, or unknown, and the control strip states that no final result means the outcome is unknown. Where the screens live is covered in Web & desktop; the stories behind these rules are in Failure stories, and the invariants they protect are collected in Safety invariants.

Go deeper

Neighbouring pages: where the reconciled budget inputs come from is Reconciliation; what the guards wrap is Execution; the wire types that carry all of it are Contracts; the missions these budgets bound are Missions watches wakes.