A practical design for permission-safe RAG in a company wiki
A company wiki and system is being designed with as the and Qdrant as a rebuildable search store. When a document is uploaded, it goes through a Redis queue, gets split into smaller chunks, is saved in with audit records and an outbox job, then a worker creates and adds the chunks to Qdrant.
Each chunk in Qdrant carries the organization units allowed to read it, its sensitivity label, and its lifecycle state. When someone asks a question, the system calculates that person’s allowed organization scope, searches Qdrant with that filter, then checks the top results again in for lifecycle state, sensitivity clearance, and tenant before sending anything to the LLM.
Other designs were rejected because they could create too many , add too much delay, or lose useful matching. The main weak point is changes: revoking access or moving an organization subtree may require rewriting many affected chunks, and 10,000 or more documents could create a sudden processing spike.
Key points
- stays authoritative, while Qdrant is treated as a rebuildable .
- Each chunk stores allowed organization units, sensitivity label, and lifecycle state in Qdrant.
- Search first filters in Qdrant, then re-checks the top results in before using the LLM.
- Separate Qdrant per organization unit were rejected because they could grow out of control.
- Large or organization changes could force many chunks to be rewritten at once.