The Executor cannot be argued with

Bellwether has models that think and one program that acts. The models can be persuaded; the program cannot. This is the whole design, and it is worth understanding before you trust the system with a book.

What the Executor is

The Executor is deterministic Python. There is no model inside it, no prompt, nothing that reads free text and decides what it means. It is the only process that holds broker credentials, and it is the only process that can place, change or cancel an order. The PM (shown as Analyst on screen), the Critic and Consult run as separate processes that hold no broker credentials and are given no shell, no file-write tools and no web-fetch tools. They read the book through read-only tools and write proposals, notes and suggestions to the database. That is the entire interface between thinking and acting.

What the policy is

Every order (proposed by the PM, approved by you, an exit the Executor itself triggers, even the re-pricing of that exit as it chases the bid down) passes through one function. The function is pure: no network, no database, no clock, no logging. It takes typed numbers in and returns a verdict. It runs every check (18 today) in a fixed order. It runs all risk checks in a fixed order and reports every one, and the first failure decides: approve, reject, or halt. In order the checks are: environment matches, market open and outside the no-trade window, tradability screen, long-only side, limit day order, limit price near the quote, quote fresh, order size cap, position size cap, gross exposure cap, orders per day, the pattern-day-trader rule, earnings blackout, daily loss (halts), drawdown (halts), no duplicate order, and last the approval threshold, which never rejects and only decides whether the order waits for you. The risk checks has the table with defaults; you can see every badge for a real proposal under Agent › proposal checks. Requests to change an order that is already working (move a limit, tighten a stop, cancel) go through a second, shorter list in the same file, numbered from 101 so the badges cannot be confused: a stop may only ever tighten, a model may not cancel a protective exit the Executor placed or move its limit anywhere but lower (check 109), and a model may not disarm a stop by cancelling the guard; it can tighten it or exit the position, never remove the protection (check 110). The one path that skips the function is Flatten, and only a person with an authenticator code can request it (the kill switch).

That file carries 100% branch coverage and every change to it must come with new tests. A rule that cannot be exercised by a test does not ship.

What the models can do

Agents only ever propose. A proposal is a row in a table with a symbol, a side, a quantity and a limit price. It has no way to say "skip the checks"; the Executor evaluates the row, not the reasoning. A model that has been talked into a bad idea produces a bad proposal, and the policy rejects it the same way it rejects any other.

Steering can only tighten. A hard constraint you write compiles into an Executor rule that can reject a buy and nothing else: it never approves, never touches a sell, a stop or an exit, and the risk checks still run on everything it lets through. When the set of active constraints changes, the Executor also sweeps what is already out: buy orders resting at the broker that the new constraint forbids are cancelled (newest first, until the book fits a tighter gross cap) and queued or waiting buy cards that violate it are rejected with the constraint as the reason. A screen on Algorithms (on servers that declare them) works the same way: it can refuse a buy with its reason, never wave one round the policy. Consult has no order tool at all: it records suggestions (a steering note, a watch item, a research or analysis request, a settings change) and nothing happens until you confirm the card; even then the result is a note, a request or an audited setting edit, never an order.

What a person must do

Loosening any limit is a ceremony: the change is shown against its code default and its allowed range, you type a phrase that names what you are doing (MORE RISK for a limit, the preset's name for a posture, MORE AUTONOMY for the dial), you enter your authenticator code, and an audit row is written. The server checks the code itself; a loosening that arrives without a fresh code check is refused whatever the browser claims. Nothing in the agent path can perform those steps. Resuming after a halt, removing a name from the denylist, raising autonomy, enforcing an algorithm and flattening each need your authenticator code too.

What the code itself guarantees

• Every limit has a floor and a ceiling in code. The console moves a value only inside them, the API refuses a value outside them, and a stored value outside them is ignored in favour of the code default.
• Defaults only get stricter. A deployment that starts with a limit looser than the code default refuses to start unless the operator explicitly allows it at deploy time.
• A limit tightened at deploy time stays authoritative; the console can tighten it further but cannot undo it.
• The kill switch is re-read, uncached, before every single submission. A halt you click is honoured by the next order, not the next minute. A halted book is also reduce-only in the policy itself: even if a buy somehow reached the function while halted, check 4 refuses it.
• Protection only ratchets one way. An entry that fills at or below its own stop is treated as a stop hit at the fill and exited at once; a buy whose working price would land on top of its stop is not placed at all; a protective exit that fails is retried, and one that cannot be placed pages you rather than going quiet.

So when a proposal is rejected and the card says why, that is the end of it. The PM can propose something else that fits; it cannot negotiate. Start at Risk to see the rules it is fitting into.