Sharing and viewers
What each role can do, what a read-only visitor actually sees (and may ask Consult), how a role on a book you run is capped by your login, and how access is taken away again. Inviting and sharing themselves live in People & access.
- Who it is for
- Everyone on the book
- Reading time
- 7 min read
- Updated
Two things decide what a person can do in Bellwether: their role, which travels with their login, and how they reach the book they are looking at. On your home book your role applies in full. On a book you run beside it (a membership, see multiple books) you act with the membership's role, never above your own. On a book that is only shared with you, you can read and ask, never change anything, whatever your role.
Roles
| Role | Can | Cannot |
|---|---|---|
| Owner | Everything, plus invite and disable users, reissue setup links, read the mail outbox, mint API tokens, and use the Admin over every book | Exist outside the house book; a second owner can only be created from the server, never from the invite dialog |
| Operator | Approve and reject, , resume and , change limits, and , steer, edit the , connect the broker, share the book, create books of their own, use and the Lab, send feedback | Manage users, read the outbox, mint API tokens, open the Admin screen |
| Read everything, use Consult and the Lab, send feedback | Approve, steer, change a limit, halt. Retired for new invites; existing reviewers keep it | |
| Read only (a "viewer" login) | Read everything, manage their own password, , sessions and devices | Anything that changes the book, including feedback and Consult |
On your own book, controls your role cannot use render greyed with an "Owner/operator only" hint, and the server refuses the call regardless. Under a membership the effective role is the lesser of the two: an owner login with an operator membership is an operator on that book, and a viewer login with any membership still writes nothing. Admin rights never come from a membership.
Inviting someone, sharing your book
Both live in one place now: People & access (account menu, or ⌘K "people" / "invite" / "share"; owner or operator, on a book you run). Its Add someone form takes an email and decides for you: someone who already signs in gets Read only or Operator on your book straight away; someone new gets an invite (the house owner only) into a book of their own, optionally plus read only on yours in the same step, or into your book with a role. One sentence under the form says which before you press the button. The People and access article walks through it, including the setup link that now stays under a pending person's row with Copy and Resend.
What has not changed: you confirm with an (one from the last 30 minutes counts; resending a link and disabling a login want one from the last 5); a setup link works once and expires after 30 minutes; the person chooses their own password and enrols their own authenticator, nobody is ever handed a preset one; when the deployment sends mail (through Resend) the link is emailed and otherwise it is only recorded, and either way it is shown to the owner.
Once you have given someone read only on your book, it appears in their book switcher under Shared with you · read only, with a lock and your initial. Picking it reloads the console so nothing cached from their own book lingers, shows a persistent bar under the top bar (Viewing ‹your book› · read-only · ← Back to my book) and shows them what you see: positions, sessions, research, reports, activity. Notes they leave through the land in your feedback log with their name and a read-only tag. The house owner can look at any book the same way, and is read only there too.
An Operator role on your book for someone who has their own book (a membership: they run yours beside theirs) is the other option on the same form; it is capped by their login's own role, and Admin rights never come from it.
What a viewer can and cannot do
"Viewer" covers two people who end up with a hands-off view: a login you invited into your book with the Viewer role, and anyone looking at your book through a share (a visitor; this includes the house owner, whose own role does not carry over). The server decides both from the session, never from the page, and answers 403 to anything outside the list below. The console handles the two differently on purpose: a Viewer-role login sees controls greyed with a hint, while a visitor never meets a control that would fail: every button, slider, switch and form that writes is hidden for them, edit-only screens turn into read-only summaries, and Lab and Settings drop out of the rail (opened by address they show one line, "You are viewing ‹book› read-only", and a Back to my book button).
| Viewer role on your book | Visitor on a shared book | |
|---|---|---|
| Read every screen: Overview, Inbox, Research, Agent sessions and the PM's and 's transcripts, Strategy, Risk, Reports, Activity, Accounts (masked) | Yes | Yes |
| Approve or reject a card, Halt, Resume, Flatten | No: buttons greyed, "Owner/operator only" | No: the buttons are not shown; where a decision would sit the card says "Read only" and that only this book's owner can decide |
| Change posture, autonomy, limits, halts, playbook, , steering notes, modes, notifications, scheduled reports | No: refused on save | No: the controls are hidden and scheduled reports is not reachable; nothing to press |
| Connect, re-verify or disable the broker connection | No | No |
| Ask Consult a question | No | Yes, in threads of their own. A visitor's Consult lists only the threads they opened on your book (marked "‹name› · visitor" in your list); your own conversations and Consult's transcripts are invisible to them. Answers use the read tools only, run on the default model, and never carry a card to confirm, so no steering note, , analysis or setting can come out of a visitor's question. At most 12 questions per visitor per book per day (they spend your book's model budget); the 13th says "That's today's questions for this book". You can read what they asked; you cannot reply inside their thread (the composer says so); answer in a thread of your own |
| Run the Lab | No | No: Lab is not in their rail; by address it shows the read-only screen |
| Send a note with the Report button | No | Yes, if their role on their own book allows it (owner, operator, reviewer); it lands in your feedback log with their name and a read-only tag |
| Act on a finding (make it a steering note, dismiss, reopen) | No (greyed) | No (hidden); Discuss opens Consult in a visitor thread, which answers but drafts nothing |
| Create a book of their own with Add a book… | No | Not while viewing yours (refused); back on their own book, yes if they are an owner or operator there |
| Share the book onward, stop a share, invite or disable users, open Admin | No: the menu entries are not shown | No: not shown while switched; the house owner gets Admin back on returning to their own book |
| Email or share a performance report | No | No: the actions are hidden |
| Manage their own password, authenticator, passkeys, sessions and remembered browsers | Yes | Yes: these stay per person, not per book (from their own book's Settings) |
| Read a broker key | Never: nobody can, on any book | Never |
Two differences worth remembering: a Viewer-role login cannot send feedback or ask Consult at all, while a visitor usually can do both; and a visitor's whole console carries the read-only bar, whereas a Viewer-role login sees ordinary-looking settings screens whose saves the server turns away. Sessions keep re-checking the login and the share about every 30 seconds, so a revoked share or a disabled login stops a screen that is already open. An API token minted on one book and pointed at another is read-only there as well.
Reviewer feedback never reaches the PM
Notes from a reviewer or a visitor go to the feedback log and the operator, never to the PM (shown as on screen). There is no path from a Report to a steering note, a lesson or a prompt; the operator reads it, decides, and only then changes something. The same holds for a visitor's Consult questions: they live in threads no member can post into and that never produce a card, and no role searches Consult transcripts, so a visitor's words cannot end up in a conversation that changes the book. Expert input is discussed, not ingested.
Revoking
- Remove access: in People & access click the person's Read only · ‹your book› or Operator · ‹your book› chip (or the row's ⋯ menu) and choose Remove access. No code needed; it takes effect on their next request, and a live screen they already have open stops updating within about 30 seconds. The chip through which a book's owner reaches their own second book cannot be removed here, and neither can your own access.
- Disable a login: the row's ⋯ menu → Disable login (house owner; a code from the last 5 minutes). Their sessions and remembered browsers end immediately and any open live screen closes within about 30 seconds; nothing is deleted, and you can enable them again later.