Multiple books

A book is one broker account and everything that belongs to it: its limits and posture, its playbook and steering notes, its agents' memory and transcripts, its proposals, orders, P&L and audit trail. Every login has one home book, the one it signed up with, and may also run further books of its own beside it or be let into someone else's. A new book is always seeded the same safe way (trading off, every proposal needing approval, moderate limits and a starter watchlist), and nothing trades and no sessions run for it until someone walks through Connect your broker with that book's own Alpaca paper keys and the Executor verifies them.

If you are the owner of the deployment, your home book is also the house book, and owners only ever live there.

How you reach a book

There are three ways a book can appear in your book switcher (top bar; it only shows once you can open more than one book, or can create one):

The switcher groups the first two under Your books and the third under Shared with you · read only (a lock and the owner's initial). Every row shows that book's latest equity, today's move, its posture (Moderate, Aggressive…) and a PAPER or LIVE badge (or "no broker" for a book that is not connected yet), each read from that book alone. Picking a book reloads the console so nothing cached from one book lingers under another, and the choice is remembered on this device until you switch again. Under Compare with… each other book opens Compare books for the book you are in against that one. The account menu reports the role you effectively hold on the book you are looking at, so a control the server would refuse is never drawn as if it worked. See sharing and viewers for what a visitor sees.

Adding a book

One of your own

Open the book switcher and choose Add a book… (also in ⌘K). The sheet asks for a name (up to 80 characters) and a starting point:

• Start from Bellwether defaults: Moderate posture, every order waits for your approval, the standard focus list.
• Copy settings from ‹a book you run› (shown with that book's posture and equity): copies risk limits (clamped into the code bounds), posture, the denylist, the algorithm weights, cadence and models, the focus list, the active playbook note and your standing guidance (as fresh notes of the new book). Autonomy is never higher than the source: Full autonomy becomes Semi-automatic with the automatic approval line, Semi keeps its pinned line, Manual stays Manual. Any halt reason is cleared. It never copies keys or connections, proposals, orders, positions, P&L, sessions, transcripts, memory, time-boxed guidance notes or hard rules (the sheet's result says how many hard rules to re-add by hand), Consult threads, alerts, audit or research pins. Only books you act on are offered as a source; a book you merely view (a share, or the house owner's admin look) cannot be copied, and the server answers as if it did not exist.

Create and connect makes the book with you as its owner, writes one audit row in the book you were in and the seed or copy rows in the new one, switches the console to it and lands on Connect your broker: the new book needs its own key pair. Alpaca lets one login hold several paper accounts: in the Paper dashboard, open the account menu and choose Open new paper account, then generate that account's keys and paste them. The book starts trading as soon as its paper account verifies (the trading switch turns itself on for a book nobody has touched); halt it from Risk if you want it parked first. Creating a book is refused while you are looking at a book read-only, and a login may run at most 12 books besides its home one (a book you retire frees its slot). The Executor picks a newly verified book up within about 30 seconds and the Scheduler folds it into the day's plan within 5 minutes, both without a restart; slots that had already passed are skipped, never run late.

For someone else

A book for another person is created by inviting them; there is no empty book without an operator, and no "New book" button on Admin. Only the owner of the house book can do it:

1. 1Open People & access and type their email and name under Add someone.
2. 2Under the New to Bellwether question (where do they land?) keep Their own book + read only on yours (the default; they can also look at your book) or pick Their own book only. Give the book a name if you like; left empty it becomes "‹Name›'s book".
3. 3Press Send invite and confirm with your authenticator code (one entered in the last 30 minutes counts). The answer shows the one-time setup link, valid for 30 minutes, mails it when a mailer is configured, and keeps it under the person's row with Copy and Resend until they use it.

The invitee is that book's Operator. When they finish setup the console sends them straight to Connect your broker. An operator of an ordinary book cannot invite people, and the server refuses the attempt, not only the form.

Comparing two books

Compare books (from the switcher's Compare with…, or ⌘K → Compare books) puts two books you can open side by side over one range (1W to ALL) and changes nothing in either: both equity curves on the same axes (growth of 100 with deposits stripped out, or dollars), the headline numbers (return, max drawdown, Sharpe with a note when the sample is under 60 days because a short Sharpe is mostly noise, trades and orders, AI cost) and how the two are set up differently, written as sentences the code derives from the settings themselves: "Aggressive vs Moderate: the $100k book makes larger first buys (risks 0.75% of the book per idea vs 0.5%), works toward 70 to 90% invested vs 40 to 60%, orders up to $1,000 vs $500…", whether one sends orders on its own while the other asks you, which algorithms only one of them uses or leans on, which names only one of them watches, and how many standing guidance notes each carries. Pick or swap the books at the top; on a phone everything stacks. Performance › Compare books keeps the deeper view: the full metrics table and each book's same-day trading sessions with their proposals, slot by slot. Both read each book in its own scope: a book you cannot open is answered as unknown, whether or not it exists.

Paper or live comes from the connection, not a switch

No screen lets you choose paper or live, not even on Connect your broker: the keys form has no account-type control, only a note that the environment is detected, not chosen. The Executor, the one process that talks to a broker, asks Alpaca which environment the pasted keys belong to when it verifies the connection (within about 30 seconds of saving): the paper endpoint first, the live endpoint only if paper says the keys are not its account, and an outage is never read as "live". Whatever authenticates becomes the connection's environment; the Connected step then shows Detected: PAPER account ••… · equity with a note that it was read from Alpaca by the trading service, not chosen here, and the Environment fact reads "PAPER (detected)".

One book, a paper account and a live account

A book is built to hold one paper and one live Alpaca account at the same time, with exactly one of them the account the book trades and the other its standby. When both exist, Connect your broker shows the pair: which account trades, which stands by, when each was last checked. Two moves exist and they are deliberately unequal. Switch to live is only ever done through Paper → live readiness: a checklist the code verifies, a typed confirmation that names the money and a cooling-off period. Until that procedure opens, the action is shown disabled with the reason and a link to what Go live checks; there is no switch, on this or any screen, that makes a live account the active one. Switch back to paper is allowed at any time: it asks for an authenticator code, the paper keys are checked again before anything trades, and the live account becomes the standby. The trading service only ever reads or trades the active account; a standby account is never probed or opened by it.

Other brokers

The broker list on Connect your broker shows what is drafted beside Alpaca (Interactive Brokers, Charles Schwab, Tradier, Robinhood), each marked coming soon with the honest reason (a gateway that has to stay signed in; no paper trading through the API, so it waits for go-live; a sandbox adapter without its connect flow yet; no official stock-trading API for individual accounts at all). A coming-soon broker cannot be picked and leads nowhere; Alpaca is the one that connects today.

Detection only ever labels; it never enables live trading. On this deployment the Executor runs paper, so a live account is recognised, stored as live, and refused: the book is parked (trading off, autonomy back to Manual, approval line 0), the connection shows an error, a critical environment-mismatch alert is written to the activity log, and the keys step explains that a LIVE account was detected and asks for the paper pair instead (Alpaca paper key IDs start with PK, live ones with AK). Nothing is placed with it. The probe repeats every time the Executor opens the book, so keys swapped under the same connection or a label edited by hand are caught the same way and the open is refused. Only a deployment whose Executor was started for live verifies a live account, and that is the paper vs live cut-over, not a console action. Once a book is running, risk check 1 still compares the book's environment with the connection on every order and halts on any disagreement rather than send it.

What exists today

• People & access. From People & access the house owner invites a person either into their own book (above, with or without read only on yours) or into your book as a login of its own (operator or read only); any owner or operator gives someone who already signs in Read only or Operator on a book they run, changes that role, or removes it. See people and access.
• Books of your own, cloning and compare, as described above.
• Read-only visitors. A login from another book that was given read only may read, send feedback and ask Consult in threads of their own, nothing else (sharing and viewers).
• The Admin screen. Admin is owner-only and lives on the house book (while viewing another book it says so and offers the way back). It lists every book with its status (halt state, autonomy and posture), connection, equity, today's P&L, positions, approvals waiting, last session, month-to-date AI cost and open alerts, and opens a detail drawer per book. It also carries the emergency levers: halt or resume one book, disable its trading, and HALT ALL / RESUME ALL across every book. Each of these asks for an authenticator code from the last 5 minutes; resuming a book also asks you to type its name, and the global levers ask for the words HALT ALL or RESUME ALL. Halting one book or disabling its trading asks for the code only. Every lever writes one audit row and raises one alert per affected book. The owner's ordinary Halt on Risk still stops the house book in one click; the admin version is the same flag, with ceremony.

The Admin screen never shows a credential. Connections appear masked, exactly as Accounts shows them.

Coming soon

The go-live procedure that can make a live account the one a book trades; connect flows for the drafted brokers; a per-book role higher than your login role, groups of people with one role, and copying notification preferences when copying a book's settings. Everything else on this page is live.

The isolation promise

The operator's requirement is zero chance of one book's context reaching another's, and each guarantee is proven by a named test in the tenancy architecture doc. In plain words:

• No cross-book context ever reaches an agent. The PM (shown as Analyst on screen), Consult and the Critic read the state card, memory, transcripts and steering of one book only. Their tools close over the book; there is no book parameter the model could pass. Search follows the same rule: ⌘K and Consult's search answer from the book you are in and the shared research corpus, never from another book's briefs, sessions, proposals or alerts.
• One model subprocess per book and session, with its own working directory and config directory. Sessions are never resumed or forked across books, and the only thing two books can share through the prompt cache is the static template text.
• The API decides who you are and what you may touch from your session, never from anything the page sends. The book switcher can only select a book you own, run or were granted; a shared book and the owner's Admin look are read-only whoever is looking; a membership gives you that book's controls and nothing of any other; every mutating route on a book you only view answers 403, and the console hides those controls before you get that far. A live screen re-checks its session and grant about every 30 seconds, so a revoked share stops updating without a reload.
• The server's own broker credentials belong to the house book only. Every other book trades through the keys its owner pasted on Connect your broker; the database refuses to point a second book at the house credentials, and the Executor refuses to open such a book if a row ever claimed them (that book gets a critical "Could not connect to your broker account" alert and stays parked while the house keeps trading).
• The Executor refuses to submit a proposal whose book does not match its connection, and raises a critical alert if it ever sees one.
• Alerts, audit rows, reports and sessions all carry the book they belong to, and the logs name it.

The one known residual: research items (news, filings, macro) are a shared public corpus, and their importance score is computed from the union of what every book holds or watches; likewise the bare existence of a symbol in search is global. A reader could at most infer that some book cares about a symbol. Nothing you type enters that corpus: the note on a pin and any free-text pin live on your book's own pin list, are read by your Researcher only, and never appear in another book's feed, briefs or state card. No text, notes, pins or agent output cross.