Privacy boundary: chat data vs. knowledge
DioscHub holds two kinds of files, and they are not the same kind of data. A document you load into a knowledge base is shared reference material — a product manual, a policy — meant to be read by anyone the assistant serves. A file a user uploads inside a chat is that user’s private data. DioscHub keeps these in separate stores with different access rules, because conflating them is exactly the kind of leak a privacy review exists to catch.
Two stores, one line between them
Section titled “Two stores, one line between them”Chat uploads and knowledge-base documents live in physically separate tables. They do not share a schema, and one cannot be reached through the other’s code path:
| Chat files | Knowledge-base files | |
|---|---|---|
| What it is | A user’s private uploads in a conversation | Shared reference documents |
| Whose data | One individual user | The organization, for an audience |
| Reached by | The user’s own conversation | Any user of a linked assistant |
| Managed in the admin portal | No | Yes |
The two are keyed in disjoint namespaces — a knowledge-base file is addressed by its knowledge base, a chat file by the assistant-and-user that owns it — so there is no key that resolves across the boundary.
Chat files are private to the user who uploaded them
Section titled “Chat files are private to the user who uploaded them”When the assistant searches a user’s chat files, the lookup is scoped to that user’s own files. A search by file id succeeds only when the id and the owner match; an id alone will not read another user’s file. That closes the obvious cross-user read: knowing (or guessing) a file id is not enough to reach a file you do not own.
A subject-access search — used to find a person’s data across a system — is likewise scoped to a single assistant. It returns content from within that assistant’s boundary, not across every assistant in the deployment.
The admin portal manages shared knowledge, not private chat data
Section titled “The admin portal manages shared knowledge, not private chat data”Knowledge bases are an admin surface: an operator creates them, uploads documents, and links them to assistants. Chat files are not on that surface. No admin screen or admin endpoint reads a user’s chat uploads — the admin tooling reaches the shared knowledge store only. An operator administering knowledge bases is working with shared reference data, never one user’s private files.
This is the boundary a compliance review cares about: shared reference data an audience is meant to see is one thing; a single user’s private uploads are another, and the platform does not let the first surface expose the second.
What erasure does at the boundary
Section titled “What erasure does at the boundary”The two stores are handled differently on erasure, and for a reason:
- A user’s chat files are erased with the user. Erasing a subject removes the files they own — the blob, its search index, and the record — from the private store. See Data erasure & GDPR.
- Knowledge-base documents are not swept by a subject erasure. They are shared organizational data, not owned by any one user; erasing one person must not delete a manual the rest of the organization still relies on. Knowledge-base content is removed deliberately, by an operator, when it is retired — not as a side effect of erasing a user.
Next: Licensing & tiers.