Paper vs live

Everything starts in paper. Paper is the default environment in the code, the example env files, the container definitions, the infrastructure and the service units, and the default broker is the built-in simulated one. No console setting switches to live: Connect refuses live keys unless the deployment explicitly enables live connections, the Executor refuses to start live against the simulated broker at all, and it refuses to start when the keys it is given are paper keys under live or live keys under paper. Going live is a separate deployment with a separate key, done by a person, after evidence.

The environment pill

The pill at the left of the top bar says which world the book is in:

• PAPER: outlined. A paper account; no real money.
• LIVE: filled orange and pulsing. A real brokerage account.
• ENV MISMATCH: amber. The environment flag and the Executor process disagree.

A mismatch is not cosmetic. Risk check #1 (broker_env_matches_process) compares the flag with the running process before anything else and halts on the first proposal it sees until they agree. Accounts then answers "Can it trade now? No" in one sentence that names both sides (the book is set to real money, the trading service is on paper money, so every order is refused until the book's owner sets them the same), links here, says paper or live changes only through the go-live procedure, and offers no button.

The readiness scorecard

Go live is owner-only (there is a link to it from Performance). It scores a fixed set of gates from what the system already records (the page says how many) and opens with where the book stands: a verdict, one sentence that says whether the book can trade real money yet and whether anything is wanted from you, how many gates pass today, the passing days in a row out of the 5 required, and a sparkline of the last 10 trading days. Beside it (under it on a phone) the gates are a table (Gate, Now, Needs, Looks at) that leads with the ones that need work and folds the passing ones behind a Show all rows button that says how many there are (every gate and one row shown for information). The thresholds they are held to are on the second tab, Thresholds, under the same names. A gate passes, passes but could be better (above the level to aim for), fails or is not measured yet, and a gate that cannot be measured yet never passes. One more row, the AI cost per filled order, is shown, not counted: dollars per fill would punish a desk that rightly sat out.

The gates, with their code-default thresholds:

A decision, for the cost-per-decision gate, is a proposal, a reasoned decision not to trade a name (counted once per name per day) or an automatic exit that acted, so a desk that reads the tape and rightly sits out is not scored as expensive. The running-cost gate takes what the models cost over the trading days the book has existed in the window, annualizes it, and divides by the average end-of-day book: that is the number an investor compares with a fund fee, which is why real money needs it under 1%.

Each gate shows its figure, what it needs and where it looks. A gate that cannot be measured yet says in a sentence what it waits for. One fold per row holds the rest: Why on a measured gate (the sentence and the numbers behind it), Details on one that is not measured yet. The three AI-cost rows open onto the model spend by role for the window (brief, premarket, intraday, close, critic, consult) so you can see where the dollars went. The deployment can tighten a threshold; an attempt to loosen one is ignored. The page measures and never switches anything (there is deliberately no button), and it keeps scoring the paper history after a cut-over, so it stays your "was the paper record real?" reference.

The ceremony

Accounts states which world the book trades in as a word on the summary, and its Going live panel says in one sentence that going live is a separate checklist and never a switch on that screen, and links to the go-live checklist; it shows no steps, settings or buttons. The procedure itself (this manual calls it the ceremony) has four parts:

1. 1Readiness evidence: every acceptance item checked by you after reading its evidence.
2. 2Live account: active and funded as the broker reports it, with a separate live key in Secret Manager the console never reads.
3. 3Arm the flag: set the environment flag to live behind a typed GO LIVE and your authenticator code. On its own this trades nothing: the Executor is still on paper, the pill reads ENV MISMATCH and check #1 halts everything.
4. 4Redeploy the Executor with its own environment set to live. This is done in the deployment on the trading machine, not in the console. The mismatch clears when the process reports live.

None of it happens in the console: the API does not compute the readiness-evidence checklist yet and has no route that arms the flag. The cut-over itself is three separate acts on the VM: a reviewed code change that adds the live profile, a config change on the machine that sets the Executor's environment to live (never in the repository), and a typed confirmation, for which the Executor is to print the live account and refuse to run until a person types the exact sentence back. That confirmation gate is planned, not built, and the runbook may not be run until it lands. Nothing in the repository, API or console flips the environment for you.

Rolling back to paper needs no ceremony and nothing has to be green: halt, set the Executor's environment back to paper in the deployment, restart. It is always allowed.

Why it is never one click

Each step is a different act by a different mechanism (evidence you read, an account the broker vouches for, a flag and a process that must agree, a sentence you type on the machine), and any one alone does nothing. The first live week runs on tiny limits set on Risk › Limits and Risk › Halts (the runbook says at most $100 an order, 5% a position, 25% gross and 2 orders a day, with the halts at a $50 daily loss and 4% drawdown), with the approval threshold at $0 and autonomy on manual on Strategy › Profile, so every order waits in the Inbox. Performance for the live book is compared with the paper week before anything is loosened, and then only one notch at a time, each behind code check and audit, never more than one loosening a day, and only after five clean live days.