Knowledge for the Owner and for a customer
Both audiences use the same source records, the same authority ladder and the same ranking in a reply. What differs is at the edges: a customer workspace supplies text rather than having media read for it, its lookup preview is a simpler containment search, and it never touches the operator's provider credentials. Isolation between workspaces is absolute in both directions.
One body, two doors#
Knowledge is not implemented twice. The storage, the authority levels, the injection scan, the contradiction check, the passage builder and the ranking are one module that both routers call. A customer session and an operator session take different API paths to it, and the difference between them is a matter of what each route exposes, never a second version of the feature.
That matters for a specific practical reason. When behaviour differs between the two audiences, the cause is almost always the route rather than the capability — a path not yet exposed on one side, not a feature that exists for one and not the other. The pattern is set out in one implementation, two audiences.
What is identical#
- The authority ladder, and what each level may prove.
- Scopes, and the way a scope keeps internal material out of a customer reply.
- The status vocabulary —
active,needs_review,disabled,error— and the rule that onlyactiveis read. - Integrity hashing of a stored file, and the re-check at retrieval time.
- The injection scan, the contradiction check and the fingerprinted risk review.
- Ranking in a real reply, and the sufficiency gate that decides whether a claim may be made.
- The character budgets on a live call: four Knowledge entries and 2,000 characters, whoever the workspace belongs to.
Where the customer path is deliberately narrower#
| Area | Customer workspace | Reason |
|---|---|---|
| Media extraction | Reported as manual: text is supplied rather than read out of PDFs, images and video | Extraction runs on the operator's provider credentials, which a customer session must never reach |
| Embeddings | Reported as lexical, with zero dimensions | No customer text is sent to an embedding service; ranking runs on the words themselves |
| The lookup preview | Lists sources whose title or text contains the phrase, at a uniform score | A coverage check rather than a ranking simulation; the reply path still ranks properly |
| Provider settings | Not visible, not editable | Model configuration is platform-managed and hidden from customer sessions by design |
| Allowance | Scoped by the workspace's plan | The operator's own workspace has no plan and therefore no allowance |
The isolation underneath#
A source belongs to exactly one workspace and is read through three independent layers: the allowlist in the middleware that decides which routes a customer session may call at all, the workspace kernel that scopes every query, and row-level security in PostgreSQL, forced on the scoped tables. Any one of the three failing still leaves two.
The direction people ask about least is the interesting one: the platform operator has no reading route into a customer's Knowledge. There is no shared bank, no pooled corpus and no cross-workspace fallback when a customer's material is thin — a missing answer stays missing rather than being filled from somebody else's documents.
Checking both sides of a change#
Make the change and confirm it on the operator screens.
Result Sources, authority, status and search all behave as documented here.
Repeat the same check as a customer.
Result If a screen or an action is missing on that side, the first suspect is the route allowlist, not the feature. A capability that works for one audience and refuses for the other is the single most common asymmetry in this product.
Read what each audience now sees, and say so.
Result A report about one workspace is a question about both. The habit of answering for both is what keeps this page short.
Questions#
Can a customer workspace upload a PDF at all?
Sources are stored, hashed, scoped and ranked identically for both audiences. What the customer path reports as manual is the extraction step — reading prose out of media with a model. Where that is not available, supply the text and the source behaves exactly like any other.
Does the operator see how much Knowledge a customer has?
Platform-level counts exist for running the service — the number of sources and passages in a workspace — because a plan and a support conversation need them. The contents do not travel with them: a count is not a read.
Why does my lookup show every result with the same score?
That is the customer-side preview, which answers whether a phrase is present rather than what would rank. Ranking in an actual reply is unaffected. To see real ranking behaviour, look at the citations recorded against replies that have already gone out.