Workspace isolation

• Connections and their stored authorisations.
• Workspace memory.
• Conversations and their context.
• Usage and credit accounting.
• Members and roles.

• The workspace identity is resolved explicitly on every request.
• Queries are filtered by workspace, so records cannot be returned by omission.
• An unresolvable workspace fails closed rather than defaulting.
• Memory retrieval never mixes candidates across workspaces.

1. 1Store a distinctive fact in workspace A.
2. 2Switch to workspace B and ask OpenFeather about it.
3. 3Confirm there is no trace of it in workspace B.
4. 4Repeat with a connection rather than memory, since connections are the stronger test.

• One workspace per client or legal entity.
• Check the switcher before every sensitive question.
• Start a new conversation when switching workspaces.
• Never share a connection across workspaces; connect it separately in each.

Isolation failure is treated as a serious fault rather than a cosmetic bug. If a workspace can observe another workspace's records, the exposed data may already have appeared in an answer, a citation, or an export.

1. 1Stop sending requests in the affected workspace so nothing further is retrieved.
2. 2Capture the workspace, the request, and the time so the report is actionable.
3. 3Revoke connections if the exposure involved connected data.
4. 4Report it with the reproduction steps, and do not paste the exposed content into a chat or ticket.

Public documentation is global and unscoped by design: every visitor may read it. Private workspace content is the opposite case and never enters a public index. Public articles, the sitemap and the machine-readable exports contain only product documentation — no conversation content, no workspace records, no account data.

That separation is why asking OpenFeather "how do I create a team?" can be answered from the documentation knowledge base, while asking it "what did my last team meeting decide?" must come from authorised workspace records instead.