Who can see what: mapping access in a small company
Ask five people in a ten-person company who can read a particular message, and you will get five answers. Most will be guesses. At least one will be wrong in the direction that causes trouble later.
This is not carelessness. It is what happens when visibility gets decided tool by tool, over two years, by whichever person happened to set each tool up. The rules exist. Nobody has ever written them on one page, so nobody holds all of them at once.
The fix is smaller than it sounds. You do not need a policy. You need a map: one page that says, for each place work lives, who can see it. A policy is a promise about behaviour. A map is a description of the system, and a description can be checked.
What the map has to answer
A useful map answers four questions for every part of the company, in plain words.
Who can see this by default. Who can be added, and by whom. What happens to it when somebody leaves the group, or the company. And whether anyone in an elevated role can see it anyway.
That last question is the one people actually want answered and rarely ask directly. It sits underneath every hesitation before somebody types something honest. Answer it once, in writing, and a lot of quiet caution goes away.
Messages, direct and group
Start here, because this is where the guessing is worst.
Opitor has direct and group messages. The deployed revision is unknown, and production administrator/non-member checks across all private-message read paths remain pending. It does not establish a complete visibility rule for direct or group messages.
For each message surface, record who can open it, search it, export it, and read its attachments. Test with a member, a non-member, and an administrator against the current production build before describing any boundary as verified.
This has a practical consequence worth naming on the map. Adding a person to a group is a real act with a real effect, so it deserves a moment of thought rather than a reflex. Small teams tend to over-add, on the theory that more context is always better. It is not, and a map makes that trade-off visible.
Todos and deadlines
Opitor includes a Todo List and calendar views of deadlines. The evidence reviewed here does not establish who can read or change each todo across roles, or whether administrative access differs.
List the owner, participants, workspace, and administrative roles for each relevant read surface. Check the calendar separately: seeing an item in one view does not prove which roles can retrieve the underlying record elsewhere.
Memory and retention
The site’s materials describe a Memory feature, but the evidence reviewed here does not verify how records are created or used, who can read them across roles, or how deletion affects stored data and backups. Reviewed screenshots showed manually entered records, not proof of an AI-proposed confirmation flow.
Do not assume that memory is personal-only, used only after confirmation, or permanently deleted. Record creation, model access, role-based visibility, deletion, retention, and backup behavior as separate questions and verify each against the current production system.
The company’s quarterly goals
One part of the map is deliberately not private, and it should be marked as such.
The product materials describe quarterly goals as administrator-managed. That does not establish which roles can view each goal or its related details in production. Verify visibility by role before labeling this a shared layer.
A map with nothing shared on it describes a company where nobody knows what anyone is for. A map with everything shared describes one where nobody says anything honest. Drawing the line between them explicitly is most of the work.
What is known about administrator access
An administrator’s ability to manage accounts or settings does not, by itself, establish data access.
Administrator access to messages, todos, and memory is still being verified. The deployed revision and administrator/non-member behavior across production read surfaces remain unknown. Do not promise either that administrators can or cannot read a record until the relevant production tests are complete.
Walk a new person through it on day one
Here is the part most companies skip, and it is the cheapest item on the list.
When somebody joins, review the map together. Separate verified access rules from questions still being tested. Do not describe a message, todo, or memory as private until the role-specific read paths have been checked.
It also has a side effect worth having. Explaining the map out loud is how you find out whether your company actually agrees on it.
What your chief of staff reads
The chief of staff’s model context is a separate question from which user interface can open a record. A source-level membership check on one message-read route does not establish which content is passed to each model, or what each provider receives. Those routes and providers must be documented and verified separately.
Where Opitor fits
Opitor’s public materials describe messages, todos, deadlines, quarterly goals, and a Memory feature. The deployed revision and administrator/non-member behavior across all read surfaces remain unknown; Memory access and deletion, and model context, are also unverified. Use this page as an access-review checklist, not as a guarantee of Opitor’s production permissions. The questions and answers page and what is an AI chief of staff page should be read with those limits in mind.
Updated 2026-09-25