A shared graph is only safe if it respects the boundaries already in your tools. Fivo's rule is simple: you see in the graph what you could already see at the source. Nothing more.
The principle
Fivo indexes material once for the whole organization, but applies permissions when someone reads. Every fact remembers which documents and resources it came from, and each reader gets the projection their permissions justify.
So if a report is shared with you later, or you are added to a Slack channel, its facts light up for you immediately. If you leave the channel, they go dark. Nothing is re-processed.
Meeting reports and documents
You can read in the graph what you could open in Fivo: reports where you were a participant, reports shared with you, and reports in a space you belong to. If a fact was corroborated by two reports and you can only open one, you see the fact through the report you can open. If a fact only exists in reports you cannot read, you do not see it, and you do not see that it exists.
The organization owner can read everything that came from organization sources, including all reports in the organization.
Connected tools
Each connection has a scope.
- Personal sources are visible only to the person who connected them. Not even the organization owner can see them. Email is always personal.
- Organization sources are visible to the people who can see that resource at the origin: the members of the Slack channel, the people with access to the Jira project. Slack and Jira report this membership to Fivo. Some tools cannot (Notion, GitHub, Discord, Airtable, Intercom, Zendesk, Stripe, Telegram); their material is visible to the owner and to the people recorded as authors or participants.
Only the organization owner can connect a source with organization scope, and a scope cannot be changed once material has been ingested. Reconnecting with a new scope is an explicit choice. See Connect your tools.
Names and summaries
A name can be content ("Acquisition of Acme for 10M"). A node that you can only reach through a fact you are not allowed to read does not appear at all. A node's written summary mixes everything the graph knows about it, so you only see it when you can read all of its sources; otherwise the node is described by the facts you can see.
The same applies to member cards: a colleague's card is built from meetings and documents, and if your account cannot open them, only their identity is shown.
One person across tools
The graph needs to know that "@ada" on GitHub, a Slack user id and [email protected] are the same colleague. Fivo resolves this in order:
- The email a tool reports matches an active member of your organization. This alone is proof.
- The person declared that handle as their own in Fivo.
- The same handle is already resolved in another connected tool.
- A name looks similar to a member. This only proposes a match; an owner or admin confirms or rejects it.
A confirmed identity is never overwritten by a guess. Someone who matches no member is an external contact (a client, a contractor) and gets their own node so their interactions accumulate in one place.
Roles
An organization has an Owner, who manages the Brain and billing, and members with Admin, Member or Viewer roles. Admins can confirm identities and manage the team, but connecting the Brain and claiming organization sources belong to the owner. See Spaces and members.
Across companies and AIs
Each company's graph is isolated, hosted in the EU, encrypted in transit and at rest, and never used to train models. No query crosses from one company's graph to another's.
When Claude or ChatGPT reads the graph over MCP, it acts as you, with your permissions. An assistant can never see more than its user. See Connect Fivo to your AI with MCP.
- brain
- permissions
- privacy
- security